Log4HELL! Разбираем Log4Shell во всех подробностях - «Новости»

За­голов­ки новос­тей пес­трят ужас­ными сооб­щени­ями о том, что проб­лема охва­тыва­ет полови­ну компь­ютер­ного мира. А взло­мать через нее яко­бы мож­но всё — от сер­вера Minecraft тво­его соседа до круп­ных кор­пораций вро­де Apple.

На GitHub есть нес­коль­ко репози­тори­ев, нап­ример, Log4jAttackSurface или log4shell со спис­ками уяз­вимого ПО (с блэк­дже­ком и пру­фами, разуме­ется!). Даже в «Википе­дии» уже есть статья о Log4Shell!

Да­вай раз­бирать­ся так ли стра­шен черт, как его малю­ют, с чего все началось и почему баг получил такую огласку.

Как нашли уязвимость

Нач­нем с неболь­шой пре­амбу­лы. Баг был обна­ружен экспер­том Чен Чжа­оцзюнь (Zhaojun Chen) из коман­ды Alibaba Cloud Security. Детали уяз­вимос­ти были отправ­лены в Apache Foundation 24 нояб­ря 2021 года. В пуб­личный дос­туп они попали чуть поз­же — 9 декаб­ря. В твит­тере завиру­сил­ся пост, в котором была пара кар­тинок, изоб­ража­ющих резуль­тат успешной экс­плу­ата­ции — запущен­ный каль­кулятор. На пер­вом скри­не был затерт пей­лоад, но вто­рая кар­тинка и кусок кода из пер­вой намека­ли, где и что нуж­но искать. Помимо это­го в пос­те была ссыл­ка на pull-рек­вест с фик­сом, пря­мо ска­жем не слиш­ком удач­ным! Сей­час пост в твит­тере уже уда­лен и пос­мотреть мож­но толь­ко через Internet Archive.

В этот же день на GitHub по­явил­ся PoC с деталя­ми экс­плу­ата­ции. Ког­да уяз­вимость обза­велась собс­твен­ным иден­тифика­тором CVE-2021-44228, ре­пози­торий пере­име­нова­ли, а затем и вов­се уда­лили. Как видишь, уви­деть начало исто­рии сей­час мож­но толь­ко бла­года­ря архи­вам.

К сло­ву, баг получил мак­сималь­ный балл (10) по стан­дарту CVSS из‑за его прос­той экс­плу­ата­ции, не тре­бующей никаких прав, и серь­езности пос­ледс­твий для ата­куемой сис­темы.

Итак, экс­пло­ит получил рас­простра­нение и начал ухо­дить в мас­сы, люди ста­ли тес­тировать пей­лоады пов­семес­тно и обна­ружи­вать уяз­вимые про­дук­ты. Давай в деталях пос­мотрим, в чем при­чина уяз­вимос­ти, какие были обхо­ды и пат­чи и в каких про­дук­тах.

Найденные уязвимости

CVE-2021-44228 — зло­умыш­ленник, который может кон­тро­лиро­вать сооб­щения жур­нала или парамет­ры сооб­щений жур­нала, может выпол­нить про­изволь­ный код, заг­ружен­ный с сер­веров LDAP через JNDI. Проб­лема зат­рагива­ет вер­сии Apache Log4j2 2.0-beta9 до 2.15.0 (за исклю­чени­ем исправ­лений безопас­ности 2.12.2, 2.12.3 и 2.3.1) уяз­вимы к уда­лен­ному выпол­нению про­изволь­ного кода через JNDI.

CVE-2021-45046 — зло­умыш­ленник, кон­тро­лиру­ющий через Thread Context Map (MDC) динами­чес­кие дан­ные в сооб­щени­ях жур­налов событий, может соз­дать пей­лоад с исполь­зовани­ем JNDILookup, который при­ведет к утеч­ке информа­ции и уда­лен­ному выпол­нению кода в некото­рых кон­фигура­циях Log4j и локаль­ному выпол­нению кода во всех кон­фигура­циях. Проб­лема при­сутс­тву­ет из‑за не пол­ностью исправ­ленной уяз­вимос­ти CVE-2021-44228 в Log4j 2.15.0.

CVE-2021-45105 — из‑за проб­лемы некон­тро­лиру­емой рекур­сии, зло­умыш­ленник спе­циаль­но сфор­мирован­ным сооб­щени­ем жур­нала событий может выз­вать отказ в обслу­жива­нии. Проб­лема зат­рагива­ет вер­сии Log4j2 начиная с 2.0-alpha1 и до 2.16.0 (за исклю­чени­ем 2.12.3 and 2.3.1).

CVE-2021-44832 — Зло­умыш­ленник, име­ющий дос­туп к изме­нению нас­тро­ек логиро­вания, может соз­дать такую кон­фигура­цию, через которую воз­можно уда­лен­ное выпол­нение кода. Для это­го исполь­зует­ся JDBC Appender с источни­ком дан­ных, ссы­лающим­ся на JNDI URI. Проб­лема зат­рагива­ет все вер­сии Log4j2 начиная с 2.0-beta7 и до 2.17.0.

Стенд

Те­атр, как извес­тно, начина­ется с вешал­ки, а тес­тирова­ние уяз­вимос­ти — со стен­да В качес­тве основной сис­темы я буду исполь­зовать Windows и IntelliJ IDEA для ком­пиляции и отладки.

Cоз­даем пус­той про­ект на Java с исполь­зовани­ем gradle. Добав­ляем в зависи­мос­ти уяз­вимую вер­сию Log4j, нап­ример, 2.14.1.

По­том соз­даем класс где аргу­мент, который мы переда­дим прог­рамме, будет логиро­вать­ся.

Те­перь ука­жем глав­ный класс, который дол­жен вызывать­ся при запус­ке.

Все готово, мож­но запус­кать. Парамет­ры в лог­гер переда­ем в качес­тве аргу­мен­тов с помощью фла­га --args:

Те­перь нас­тало вре­мя про­тес­тировать работу уяз­вимос­ти, для это­го возь­мем прос­той пей­лоад ${jndi:ldap://127.0.0.1/a} и переда­дим его в качес­тве парамет­ра. Толь­ко не забудь сна­чала пос­тавить на прос­лушку 389 порт.

Кон­нект при­ходит, а это зна­чит, что уяз­вимость успешно про­экс­плу­ати­рова­на. Это­го пока дос­таточ­но для даль­нейше­го пре­пари­рова­ния.

Детали уязвимости

Поп­робу­ем разоб­рать­ся, почему эта загадоч­ная конс­трук­ция вооб­ще выпол­няет­ся.

По сути, конс­трук­ции вида ${} исполь­зуют­ся в динами­чес­ких стро­ках, которые пре­обра­зуют­ся раз­ными реали­заци­ями клас­са StringSubstitutor. Да не осу­дят меня Java сень­оры, я буду счи­тать, что это прос­то перемен­ные.

Те­перь ска­чаем ис­ходни­ки нашей вер­сии биб­лиоте­ки Log4j. Инте­ресу­ющая нас обра­бот­ка логиру­емо­го события начина­ется в методе format клас­са MessagePatternConverter.

Этот цикл про­веря­ет наличие конс­трук­ции ${ в сооб­щении. Если она при­сутс­тву­ет, управле­ние переда­ется клас­су StrSubstitutor для даль­нейшей обра­бот­ки.

Здесь мож­но видеть ини­циали­зацию дефол­тно­го пре­фик­са (${) и суф­фикса (}). Далее по коду видим метод substitute.

Он сно­ва выпол­няет поиск таких конс­трук­ций (${ололо}) по содер­жимому логиру­емо­го события, толь­ко в этот раз про­веря­ет наличие суф­фикса }, что­бы опре­делить дей­стви­тель­но ли нуж­на даль­нейшая обра­бот­ка.

Ме­тод prefixMatcher.isMatch, как вид­но из наз­вания, находит начало конс­трук­ции, сим­волы ${. Про­вер­ка выпол­няет­ся методом isMatch.