Содржина[Крие][Прикажи]
Log4Shell, интернет ранливост, неодамна зафати милиони машини. Log4j, нејасно, но речиси сеприсутно парче софтвер, го предизвикува.
Log4j се користи за евидентирање на сите дејства што се случуваат зад сцената во различни компјутерски системи.
Се заснова на библиотека за логирање со отворен код што ја користат бизнисите, па дури и владините организации во повеќето апликации.
Со оглед на тоа што е една од најлошите дупки за сајбер безбедност што некогаш биле откриени, од клучно значење е да ги заштитите вашите системи од оваа ранливост. Но како?
Ајде детално да ја истражиме ранливоста на Log4j и сите можни решенија за поправка за неа.
Што е Log4j?
Log4j е ан со отворен код рамка за евиденција која им овозможува на развивачите на софтвер да снимаат различни податоци во рамките на нивните апликации. Тоа е компонента на проектот Apache Logging Services, кој го води Apache Software Foundation.
Стотици веб-локации и апликации користат Log4j за извршување на критични операции како што се евиденција на податоци за дебагирање и други намени.
Кога внесувате или кликнете на лоша онлајн врска и добивате известување за грешка 404, ова е чест пример на Log4j на работа. Веб-серверот што го води доменот на веб-врската до која се обидовте да пристапите ве информира дека таква веб-страница не постои. Исто така, го евидентира настанот во Log4j за системските администратори на серверот.
Низ софтверските програми, се користат слични дијагностички сигнали. Во онлајн играта Minecraft, на пример, серверот користи Log4j за да евидентира активност како што е вкупната искористена RAM меморија и корисничките упатства испратени во конзолата.
Како се јавува ранливоста?
Пребарувањата се нова функција воведена во Log4j 2.0, која помага да се вклучат дополнителни информации во записите во дневникот. Едно од овие пребарувања е пребарувањето JNDI (Java Naming and Directory Interface), кое е Java API за комуникација со услуга на директориуми.
Користејќи го овој пристап, внатрешните кориснички ID може да се мапираат со вистинските кориснички имиња. Ова барање ја изложува новооткриената RCE ранливост, бидејќи еден од типовите на податоци обезбедени од LDAP серверот е URI што покажува кон Java класа, која потоа се вчитува во меморијата и работи од примерот Log4j.
Поради слабост во валидацијата на влезот на библиотеката Log4j, можно е да се инјектира произволен LDAP сервер од недоверлив извор. Бидејќи програмерите претпоставуваат дека податоците испратени до дневниците ќе се постапуваат како обичен текст, не се презема дополнителна валидација на влезот, а опасниот кориснички внес влегува во дневниците.
Изјавата за дневник може да изгледа вака:
Злонамерен корисник сега ќе вметне пребарување JNDI што се однесува на непријателски LDAP сервер во параметарот на URL-то. Пребарувањето на JNDI би било како што следува:
Библиотеката Log4j потоа разговара со овој LDAP сервер на attacker.com за да добие информации за директориумот, вклучувајќи вредности за Java Factory и Java Codebase.
Овие две вредности ја вклучуваат класата Java на напаѓачот, која потоа се вчитува во меморијата и се извршува од примерот Log4j, со што се комплетира извршувањето на кодот.
Кој е изложен на ризик?
Ранливоста на Log4j е неверојатно широка, што влијае на деловните апликации, вградените уреди и нивните потсистеми. Засегнатите апликации вклучуваат Cisco Webex, Minecraft и FileZilla FTP.
Сепак, ова во никој случај не е цела листа. Недостатокот влијае дури и на мисијата на хеликоптер Ingenuity Mars 2020, која користи Apache Log4j за снимање настани.
Безбедносната заедница состави а листа на ранливи системи. Од клучно значење е да се забележи дека овие списоци постојано се ажурираат, па ако одредена програма или систем не е прикажана, не претпоставувајте дека не е засегната.
Изложеноста на оваа ранливост е доста веројатна, па дури и ако е одредена технолошки оџак не ја применува Java, директорите за безбедност треба да очекуваат дека тоа ќе го сторат критичните системи на добавувачи, добавувачите на SaaS, давателите на облак хостинг и давателите на веб-сервери.
Како да се провери за ранливоста на Log4j?
Првиот чекор е да се утврди дали веќе се случил напад. Можете да го направите тоа со проверка на системските дневници за фрагменти од RCE носивост.
Ако пребарувањето за термини како „jndi“, „ldap“ или „$::“ даде логови, безбедносните истражувачи треба дополнително да истражат за да видат дали станува збор за легитимен напад или само земање отпечатоци.
Откриени се многу напади во дивината кои не донесоа никакви штетни товари. Сепак, тие беа спроведени од безбедносни експерти за да утврдат колку апликации се ранливи на овој напад.
Следниот чекор е да се користи библиотеката Log4j за да се идентификуваат сите проекти. Ако се користат верзии помеѓу 2.0-beta9 и 2.14.1, проектот може да биде подложен.
Со оглед на тешкотијата во одредувањето каде постои оваа ранливост, може да се претпочита да се претпостави дека проектот е подложен и дека ажурирањето на библиотеката е најдобриот начин на дејствување за отстранување на опасноста од извршување на кодот.
Проектот не е ранлив ако користената верзија е помала од 2.0-бета 9, иако библиотеката Log4j сè уште треба да се надгради бидејќи верзиите во опсегот 1.x се стари и повеќе не добиваат ажурирања.
Без разлика дали е откриен чувствителен проект, се препорачува да се провери за да се види дали некоја информација евидентирана со Log4j содржи информации што корисникот може да ги промени. УРЛ-адреси, параметри за барање, заглавија и колачиња се примери за овие податоци. Ако некој од нив е најавен, проектот е во опасност.
Ова знаење може да ви помогне понатаму да истражувате во системските дневници и да одредите дали вашата веб-апликација е веќе нападната.
Постојат бесплатни онлајн алатки кои можат да откријат дали веб-апликацијата е ранлива. Една од овие програми е Ловец Log4Shell. Тој е со отворен код и е достапен на GitHub.
Доколку се открие ранлива област на код во онлајн апликацијата, носивоста обезбедена од откриената алатка може да се користи за да се вбризга во веб апликацијата. Алатката за тестирање ќе ги открие врските направени помеѓу вашата веб-апликација и нивниот LDAP-сервер доколку ранливоста се експлоатира.
Решенија за поправка на ранливоста на Log4j
Првиот чекор е да го ажурирате Log4j, што можете да го направите со користење на нормалните менаџери на пакети или со преземање директно од ова страница.
Исто така, можно е да се намали експлоатибилноста на ранливоста со поставување на променливата на околината FORMAT MSG NO LOOKUPS на точно. Оваа контрамерка, сепак, е применлива само за верзии на Log4j поголеми или еднакви на 2.10.
Сега да ги разгледаме алтернативните опции.
1. Работни решенија за Log4j верзија 2.17.0
Дефинитивно се препорачува да се користи Log4j верзијата 2.15.0 за заштита од Log4Shell, но доколку тоа не е можно, достапни се и други решенија.
Верзии 2.7.0 и понови на Log4j: Изводливо е да се заштити од каков било напад со менување на форматот на настаните што треба да се евидентираат користејќи ја синтаксата процент m nolookups за податоците доставени од корисникот. Ова ажурирање бара уредување на конфигурациската датотека Log4j за да генерира нова верзија на програмата. Како резултат на тоа, пред да се имплементира оваа нова верзија, мора да се повторат техничката и функционалната валидација.
Log4j верзии 2.10.0 и понови: Исто така, можно е да се заштитите од каков било напад со поставување на конфигурацискиот параметар log4j2.formatMsgNoLookups на true, на пример, кога ја стартувате Java виртуелната машина со опцијата -Dlog4j2. formatMsgNoLookups = точно, Друга опција е да се отстрани класата JndiLookup од аргументот classpath, со што ќе се отстрани главниот вектор за напад (истражувачите не ја исклучуваат можноста за друг вектор за напад).
Веб-услугите на Амазон обезбедуваат хотпеч што „треба да се користи на ваш сопствен ризик“. Објавени се и други „техники“, како што е Logout4Shell, која „ја користи оваа ранливост против себе“. Безбедносниот експерт ја доведува во прашање законитоста на овој потег, кој вклучува „хакирање на машина за да се поправи“.
2. Проблемот е решен во Log4j v2.17.0.
За верзии поголеми од 2.10: Log4j2.formatMsgNoLookups треба да се постави на точно.
За верзии од 2.0 до 2.10.0: Извршете ја следнава команда за да ја отстраните класата LDAP од Log4j.
Log4j2.formatMsgNoLookups треба да се постави на true во системските поставки.
Ублажување во JVM
Ублажувањето со параметрите на JVM веќе не е опција. Другите методи за ублажување продолжуваат да бидат успешни. Ако е можно, надградете на Log4j верзија 2.17.0. Достапно е водич за миграција за Log4j v1.
Ако ажурирањето не е можно, проверете дали компонентите од клиентската и од серверот имаат -Dlog4j2.formatMsgNoLookups = множество на вистински системски својства.
Имајте предвид дека Log4j v1 го достигна својот крај на својот животен век (EOL) и повеќе нема да добива поправени грешки. Други RCE вектори се исто така подложни на Log4j v1. Оттука, ве повикуваме што поскоро да ја надградите на Log4j 2.17.0.
3. Мерки за ублажување
Тековните експлоатирања не можат да работат дури и ако Log4j е подложен во некои случаи, како на пример ако машината домаќин работи Java верзија повисока од 6u212, 7u202, 8u192 или 11.0.2.
Ова се должи на подобрата заштита на далечинската класа за вчитување на Java Naming and Directory Interface (JNDI) во тековните верзии, што е неопходно за да функционира нападот.
Понатаму, со верзии на Log4j поголеми од 2.10, проблемот може да се избегне со поставување на системската вредност formatMsgNoLookups на true, обезбедување на аргументот JVM -Dlog4j2.formatMsgNoLookups = точно или бришење на класата JndiLookup од класата патека.
Во меѓувреме, додека не се поправат ранливите случаи, ранливоста може да се реши со помош на техниките подолу:
- Поставете ја карактеристиката на системот log4j2.formatMsgNoLookups на true за >=2.10.
- Поставете ја опцијата за животна средина LOG4J FORMAT MSG NO LOOKUPS на true за >=2.10.
- Отстранете го JndiLookup.class од classpath за 2.0-beta9 до 2.10.0: zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class
Една од препорачаните најдобри практики е да се ограничи излезниот сообраќај кон интернет само на соодветните пристаништа.
Иако повеќето напади на терен се испорачуваат преку HTTP, ранливоста може да се експлоатира преку кој било протокол што ги евидентира влезните податоци од корисникот користејќи Log4j.
Сепак, ажурирањето на log4j 2.17.0 е најдобриот лек бидејќи некој може да открие дополнителен пристап кон проблемот. Понатаму, многу издавачи и производители најавија подобрувања на нивните услуги или апликации.
4. Закрпа за ранливост на Log4Shell
Log4j е сеприсутен, особено сега кога ранливоста се искористува. Да резимираме, сè што треба да направите е да ги вклучите следните знаци во дневниците проверени од Log4j.
И ова ќе ја преземе и изврши датотеката Java што се наоѓа на крајот од URL-то. Тоа е исто толку едноставно толку и драматично.
Како што знаете, од клучно значење е да се надгради log4j на верзија >= 2.17.0 за да се отстрани оваа ранливост на Log4Shell (CVE-2021-44228).
Ако ова не е можно:
За апликации кои користат Log4j библиотека верзии 2.10.0 и понови, исто така е можно да се заштити од каков било напад со поставување на параметарот за конфигурација log4j2.formatMsgNoLookups на true, на пример, додека ја стартувате Java виртуелната машина со -Dlog4j2.formatMsgNoLookups = true опција.
Друга опција е да се избрише класата JndiLookup од аргументот classpath, што ќе го отстрани примарниот вектор за напад (истражувачите не исклучуваат постоење на друг вектор за напад).
забелешка
Организациите кои се колебаат или не сакаат да направат прилагодувања на чувствителните системи (или кои сакаат да инсталираат дополнителни заштитни мерки) треба да размислат за:
- Осигурете се дека целиот сообраќај е насочен преку iSensor/WAF/IPS. Ова може да го спречи нападот да добие пристап до системот.
- Ограничување на количината на сообраќај што може да стигне до подложниот систем Ако системот не треба да биде поврзан на интернет, ограничете го пристапот до основните и доверливи IPS и опсези.
- Намалување на одобрениот појдовен сообраќај на домаќинот. Бидејќи овој напад работи со поврзување со непријателски сервер, сите излишни IP адреси и порти треба да бидат блокирани на заштитен ѕид.
- Ако услугата повеќе не е потребна, треба да се оневозможи додека не се подготви поправка.
Заклучок
Недостатоците на Log4j ја шокираа нашата заедница и не потсетија на сите колку се потпираме на софтвер со отворен код.
Log4j е единствен. Ниту е оперативен систем, ниту прелистувач, ниту пак софтвер. Наместо тоа, тоа е она што програмерите го нарекуваат библиотека, пакет или код модул. Тоа служи само за една цел, односно водење евиденција за тоа што се случува на серверот.
Луѓето кои пишуваат код претпочитаат да се концентрираат на она што го прави нивниот софтвер карактеристичен. Тие не се заинтересирани за повторно измислување на тркалото. Како резултат на тоа, тие се потпираат на многу постоечки библиотеки со кодови, како што е Log4j.
Модулот Log4j е изведен од Apache, најкористениот софтвер за веб-сервер. Затоа може да се открие на милиони сервери. Оттука, зголемување на безбедносните закани.
Се надевам дека горенаведените решенија ќе ви помогнат да ги зачувате вашите уреди безбедни.
Останете со HashDork за повеќе корисни информации од технолошкиот свет.
Оставете Одговор