Sa mga huling araw sa net nagkaroon ng maraming usapan tungkol sa kahinaan ng Log4j kung saan natuklasan ang iba't ibang vector ng pag-atake at na-filter din ang iba't ibang functional exploit upang mapagsamantalahan ang kahinaan.
Ang kabigatan ng bagay ay na ito ay isang tanyag na balangkas para sa pag-aayos ng pagpapatala sa mga aplikasyon ng Java., na nagbibigay-daan sa arbitrary code na isagawa kapag ang isang espesyal na na-format na halaga ay isinulat sa registry sa format na "{jndi: URL}". Ang pag-atake ay maaaring isagawa sa mga aplikasyon ng Java na nag-log ng mga halaga na nakuha mula sa mga panlabas na mapagkukunan, halimbawa sa pamamagitan ng pagpapakita ng mga problemang halaga sa mga mensahe ng error.
At ang isang attacker ay gumagawa ng HTTP na kahilingan sa isang target na system, na bumubuo ng isang log gamit ang Log4j 2 Na gumagamit ng JNDI para humiling sa site na kinokontrol ng attacker. Ang kahinaan ay nagiging sanhi ng pinagsasamantalahang proseso na makarating sa site at isagawa ang payload. Sa maraming naobserbahang pag-atake, ang parameter na pag-aari ng umaatake ay isang sistema ng pagpaparehistro ng DNS, na nilayon upang magrehistro ng isang kahilingan sa site upang matukoy ang mga masusugatan na system.
Tulad ng ibinahagi na ng aming kasamahan na si Isaac:
Ang kahinaan ng Log4j na ito ay nagbibigay-daan sa pagsasamantala ng maling input validation sa LDAP, na nagpapahintulot remote code execution (RCE), at pagkompromiso sa server (pagiging kumpidensyal, integridad ng data at pagkakaroon ng system). Bilang karagdagan, ang problema o kahalagahan ng kahinaang ito ay nakasalalay sa bilang ng mga application at server na gumagamit nito, kabilang ang software ng negosyo at mga serbisyo sa cloud gaya ng Apple iCloud, Steam, o mga sikat na video game gaya ng Minecraft: Java Edition, Twitter, Cloudflare, Tencent , ElasticSearch, Redis, Elastic Logstash, at isang mahabang atbp.
Pinag-uusapan ang bagay, kamakailan inilabas ang Apache Software Foundation sa pamamagitan ng isang post isang buod ng mga proyektong tumutugon sa isang kritikal na kahinaan sa Log4j 2 na nagpapahintulot sa arbitrary code na tumakbo sa server.
Ang mga sumusunod na proyekto ng Apache ay apektado: Archiva, Druid, EventMesh, Flink, Fortress, Geode, Hive, JMeter, Jena, JSPWiki, OFBiz, Ozone, SkyWalking, Solr, Struts, TrafficControl, at Calcite Avatica. Naapektuhan din ng kahinaan ang mga produkto ng GitHub, kabilang ang GitHub.com, GitHub Enterprise Cloud, at GitHub Enterprise Server.
Sa mga nagdaang araw ay nagkaroon ng makabuluhang pagtaas ng aktibidad na nauugnay sa pagsasamantala sa kahinaan. Halimbawa, Naka-log ang Check Point ng humigit-kumulang 100 na pagtatangka sa pagsasamantala kada minuto sa mga fictitious server nito ang rurok nito, at inihayag ni Sophos ang pagtuklas ng bagong botnet sa pagmimina ng cryptocurrency, na nabuo mula sa mga system na may hindi natatakpan na kahinaan sa Log4j 2.
Tungkol sa impormasyong inilabas tungkol sa problema:
- Ang kahinaan ay nakumpirma sa maraming opisyal na mga imahe ng Docker, kabilang ang couchbase, elasticsearch, flink, solr, mga imahe ng bagyo, atbp.
- Ang kahinaan ay nasa produkto ng MongoDB Atlas Search.
- Lumilitaw ang problema sa iba't ibang produkto ng Cisco, kabilang ang Cisco Webex Meetings Server, Cisco CX Cloud Agent, Cisco
- Advanced na Web Security Reporting, Cisco Firepower Threat Defense (FTD), Cisco Identity Services Engine (ISE), Cisco CloudCenter, Cisco DNA Center, Cisco. BroadWorks, atbp.
- Ang problema ay nasa IBM WebSphere Application Server at sa mga sumusunod na produkto ng Red Hat: OpenShift, OpenShift Logging, OpenStack Platform, Integration Camel, CodeReady Studio, Data Grid, Fuse, at AMQ Streams.
- Nakumpirmang isyu sa Junos Space Network Management Platform, Northstar Controller / Planner, Paragon Insights / Pathfinder / Planner.
- Maraming produkto mula sa Oracle, vmWare, Broadcom, at Amazon ang apektado din.
Mga proyekto ng Apache na hindi apektado ng kahinaan ng Log4j 2: Apache Iceberg, Guacamole, Hadoop, Log4Net, Spark, Tomcat, ZooKeeper, at CloudStack.
Ang mga gumagamit ng may problemang mga pakete ay pinapayuhan na agarang i-install ang inilabas na mga update para sa kanila, hiwalay na i-update ang bersyon ng Log4j 2 o itakda ang parameter na Log4j2.formatMsgNoLookups sa true (halimbawa, pagdaragdag ng key na "-DLog4j2.formatMsgNoLookup = True" sa startup).
Upang i-lock ang system ay mahina kung saan walang direktang pag-access, iminungkahi na samantalahin ang Logout4Shell na bakuna, na, sa pamamagitan ng paggawa ng isang pag-atake, inilalantad ang setting ng Java na "log4j2.formatMsgNoLookups = true", "com.sun.jndi .rmi.bagay. trustURLCodebase = false "and" com.sun.jndi.cosnaming.object.trustURLCodebase = false "upang harangan ang karagdagang pagpapakita ng kahinaan sa mga hindi nakokontrol na system.