През последните дни в мрежата се говори много за уязвимостта на Log4j, в който са открити различни вектори на атака и различни функционални експлойти също са филтрирани, за да се използва уязвимостта.
Сериозността на въпроса е, че това е популярна рамка за организиране на регистъра в Java приложения., което позволява да се изпълнява произволен код, когато специално форматирана стойност се записва в системния регистър във формат "{jndi: URL}". Атаката може да се извърши върху Java приложения, които регистрират стойности, получени от външни източници, например чрез показване на проблемни стойности в съобщения за грешка.
И нападателят прави HTTP заявка към целева система, която генерира лог с помощта на Log4j 2 Което използва JNDI, за да направи заявка към контролирания от атакуващия сайт. След това уязвимостта кара експлоатирания процес да пристигне на сайта и да изпълни полезния товар. При много наблюдавани атаки параметърът, който принадлежи на нападателя, е DNS регистрационна система, предназначена да регистрира заявка на сайта за идентифициране на уязвими системи.
Както вече сподели нашият колега Исак:
Тази уязвимост на Log4j позволява да се използва неправилно валидиране на входа към LDAP, което позволява дистанционно изпълнение на код (RCE) и компрометиране на сървъра (поверителност, целостта на данните и наличността на системата). В допълнение, проблемът или важността на тази уязвимост се крие в броя на приложенията и сървърите, които я използват, включително бизнес софтуер и облачни услуги като Apple iCloud, Steam или популярни видеоигри като Minecraft: Java Edition, Twitter, Cloudflare, Tencent, ElasticSearch, Redis, Elastic Logstash и long и т.н.
Говорейки по въпроса, наскоро пусната софтуерна фондация Apache чрез пост резюме на проекти, които се занимават с критична уязвимост в Log4j 2 което позволява произволен код да се изпълнява на сървъра.
Засегнати са следните проекти на Apache: Archiva, Druid, EventMesh, Flink, Fortress, Geode, Hive, JMeter, Jena, JSPWiki, OFBiz, Ozone, SkyWalking, Solr, Struts, TrafficControl и Calcite Avatica. Уязвимостта засегна и продуктите на GitHub, включително GitHub.com, GitHub Enterprise Cloud и GitHub Enterprise Server.
През последните дни има значително увеличение на дейността, свързана с експлоатацията на уязвимостта. Например, Check Point регистрира около 100 опита за експлоатиране на минута на своите фиктивни сървъри своя връх и Sophos обяви откриването на нов ботнет за копаене на криптовалута, формиран от системи с непоправена уязвимост в Log4j 2.
Относно информацията, която беше пусната за проблема:
- Уязвимостта е потвърдена в много официални изображения на Docker, включително couchbase, elasticsearch, flink, solr, storm изображения и др.
- Уязвимостта присъства в продукта MongoDB Atlas Search.
- Проблемът се появява в различни продукти на Cisco, включително Cisco Webex Meetings Server, Cisco CX Cloud Agent, Cisco
- Разширено отчитане на уеб сигурността, Cisco Firepower Threat Defense (FTD), Cisco Identity Services Engine (ISE), Cisco CloudCenter, Cisco DNA Center, Cisco. BroadWorks и др.
- Проблемът присъства в IBM WebSphere Application Server и в следните продукти на Red Hat: OpenShift, OpenShift Logging, OpenStack Platform, Integration Camel, CodeReady Studio, Data Grid, Fuse и AMQ потоци.
- Потвърден проблем в платформата за управление на космическата мрежа Junos, Northstar Controller / Planner, Paragon Insights / Pathfinder / Planner.
- Много продукти от Oracle, vmWare, Broadcom и Amazon също са засегнати.
Apache проекти, които не са засегнати от уязвимостта Log4j 2: Apache Iceberg, Guacamole, Hadoop, Log4Net, Spark, Tomcat, ZooKeeper и CloudStack.
Потребителите на проблемни пакети се съветват спешно да инсталират пуснатите актуализации за тях отделно актуализирайте версията на Log4j 2 или задайте параметъра Log4j2.formatMsgNoLookups на true (например добавяне на ключа "-DLog4j2.formatMsgNoLookup = True" при стартиране).
За да заключите системата е уязвима, до която няма директен достъп, беше предложено да се използва ваксината Logout4Shell, която чрез извършване на атака разкрива настройката на Java "log4j2.formatMsgNoLookups = true", "com.sun.jndi .rmi.object. trustURLCodebase = false "и" com.sun.jndi.cosnaming.object.trustURLCodebase = false "за блокиране на по-нататъшни прояви на уязвимостта в неконтролирани системи.