Пролог
Перед тем, как я расскажу о своем исследовании, объясню, чем оно было обусловлено. В мае мы запустили альфа-версию сканера интернета – Netlas.io. Этот сервис – наша собственная разработка, которой мы занимались последние месяцы.
В двух словах о том, что это. Netlas.io — это своеобразный технический атлас всей сети Интернет, который включает сертификаты, данные по доменам и поддоменам, ответы серверов по популярным портам и много другой полезной информации для исследователей безопасности. Иными словами — это российский аналог Shodan или Censys.
Альфа-тестирование продлится еще несколько месяцев, поэтому, кому интересно – ждем. На этот период сервис полностью бесплатный, но уже содержит много «плюшек» для тех, кто решит продолжить его использовать после альфы. Например, доступ к платному аккаунту на несколько месяцев.
На этой ноте вступительную часть объявляю закрытой, переходим к исследованию.
В марте Microsoft выпустил патч для уязвимостей Proxylogon (CVE-2021-26855, CVE-2021-26857, CVE-2021-26858, CVE-2021-27065), с тех пор в моих новостных подборках почти каждый день проскакивает новость про эти уязвимости. То кто-то пишет очередной детект, то очередная коммерческая группировка начинает атаки, то Microsoft заявляет о том, что не пропатченых осталось 5% версий, то другая компания заявит, что остался 82731 уязвимый хост, то они же, что осталось 69548, а другие вендоры - осталось 29796 уязвимых хостов.
В начале мая на один из моих ханипотов попался запрос, позволяющий определить точную версию Microsoft Exchange (с небольшой корректировкой, но об этом потом).
В середине мая мы запустили Netlas.io (о чем я написал в самом начале) с результатами сканирования всего интернета. Тут я решил, что пора провести маленькое исследование того, как обстоят дела с безопасностью Exchange и дать свою цифру уязвимых хостов (хотя меня больше интересуют проценты, так честнее на большой выборке).
Как мы раньше определяли версию Microsoft Exchange
Во многих тестах на проникновение на периметре организации торчит Microsoft Exchange (иногда это единственный доступный снаружи ресурс). Посмотрев на исходный код страницы /owa/auth/logon.aspx, легко найти версию. Увы, прошли славные времена Exchange 2010 и по этой версии уже ничего не понять.
src: url("/owa/auth/15.2.858/themes/resources/segoeui-regular.eot?#iefix") format("embedded-opentype"),<meta name="msapplication-TileImage" content="prem/15.2.858.12/resources/images/0/owa_browserpinnedtile.png"/>Мы часто видим версию 15.00.1497, но что с ней делать, какие эксплойты применять — вообще загадка. Можно посмотреть описание выхода версии или на официальном сайте (менее удобно)
По этим данным мы можем понять, что данная версия от июня 2019 до мая 2021. Что применять для взлома не понятно (или надо ли что-то применять вообще). Ситуация сильно усложняется, если есть любое защитное средство (начиная от антивируса, который удалит наш шелл, заканчивая NGFW, который не пропустит наш запрос).
Короче, знать версию очень полезно в нашем непростом деле!
Что нашлось
На ханипот пришёл запрос к
“/ecp/Current/exporttool/microsoft.exchange.ediscovery.exporttool.application”. Я люблю смотреть на редкие запросы на публично доступных ханипотах, поэтому довольно быстро обратил внимание и на этот (я их по длине сортирую, а этот вон какой длинный)). Запрос очевидно к Microsoft Exchange (там так написано)) и путь ecp тоже его).
Запрос был мне незнаком, и я его кинул на стенд с Exchange. К моему удивлению, сервер ответил мне диалогом на скачку файла, в файле xml, а в ней текущая запущенная версия Exchange!
<assemblyIdentity name="microsoft.exchange.ediscovery.exporttool.application" version="15.2.858.12" publicKeyToken="b1d1a6c4511418ce" language="neutral" processorArchitecture="Нахождение версии Exchange позволит сэкономить чуть-чуть времени при тестах на проникновение, а это приятно. Кидаю запрос на стенд с Exchange 2016 и тоже получаю версию! Кидаю на Exchange 2013 и ничего не получаю(
Разбираемся с версией Exchange 2013
Смотрим на запрос и видим слово “Current”. Логично предположить, что Microsoft с 2016 года ввело алиас на версию. Пробуем кидать верхнеуровневую версию (которую мы получили со страницы OWA) и ничего не получаем.
Версия Exchange 2010 и ниже
У меня нет стенда с такой версией Exchange, и она там не нужна. Как я писал выше, в таких версиях полная версия билда пишется на страничке /owa.
Получаем список Microsoft Exchange
Все знают, что чаще всего сервер с Exchange перекидывает обращение к / на /owa/. Поищем редирект на /owa, запрос для Netlas:
http.headers.location:"/owa/"Я получил 2,8 миллиона результатов и очевидно такого количества Exchange не может быть, а, значит, там много дубликатов (мы во время сканирования ходим по различным редиректам и результатов для одного адреса может быть больше одного, иногда прям сильно больше одного). Так же в изначальном запросе мы просто ищем слово “owa”, а оно может встречаться где угодно, например, редирект с /owa/ на /owa/auth/logon.aspx
Оптимизируем запрос, чтобы редирект был с /:
http.headers.location:"/owa/" AND path:"/"Получили 1.7 миллиона результатов, что тоже не правдоподобно много, смотрим в них и видим, что очень много результатов приходится на “MICROSOFT-CORP-MSN-AS-BLOCK”, это подсеть облака 365 от Microsoft. Когда я готовил данные для исследования, я думал, что облака нам не интересны, там же точно всё обновлено (я ошибался, но об этом дальше).
В итоге, я исключил из запроса эту подсеть и итоговый запрос был:
((http.headers.location:/owa/ AND path:"/") AND NOT asn.organization:("MICROSOFT-CORP-MSN-AS-BLOCK"))Я получил 677 тысяч результатов и это число меня устроило (на самом деле оно маловато и после следующего скана, оно должно увеличиться, так как мы добавили почти 2 миллиарда доменов, но еще не успели их отсканировать).
Качаем эти 677к результатов. Можно удобно скачать только нужные поля (меня интересовали: ip, домен, порт и страна).
Сканирование интернета
После удаление дублей в таргетах осталось 550к целей. Если кто-то когда-то сканировал 550к хостов в интернете, то он понимает, что сканить это синхронными методами (например, python с requests) будет очень долго (дней 10 примерно, при таймауте в 1 секунду). Поэтому я взял наш сканер (написан на Golang), написал в него модуль (когда-нибудь мы напишем отдельную большую статью про то, как мы сканируем интернет), который отдавал мне следующую информацию:
хост (ip, домен, порт)
версию на страничке /owa
версию Exchange (из файла microsoft.exchange.ediscovery.exporttool.application)
страну (копировал из исходного файла)
В результате получили около 400к результатов, за 2 часа работы, которые дальше будем анализировать.
Анализ результатов
Тут был сложный вопрос, как джойнить результаты, так как входные данные были вперемешку (ip и домены). Мы точно много раз получили результаты дважды (например, у нас есть хост с ip 1.1.1.1 и доменом mail.example.com). Более того, полно хостов, которые мы одновременно сканили по нескольким поддоменам, например, autodiscover.example.com, webmail.example.com и т.д. Кроме того, на одном ip-адресе может быть несколько разных доменов, например, mail.example.com, mail.example-corp.com, mail.example.net. Так как я не гонюсь за большими числами (мне интересен процент хостов), я произвёл джоин по ip-адресу и получил 146 тысяч уникальных адресов с Exchange серверами. Джойн по домену даёт около 200к результатов (имеется в виду объединение по длине домена -1 от изначального, т.е. mail.test.example.com даёт нам домен test.example.com и он не будет объединён с доменом mail.example.com).
При любом виде джойна получались хосты, у которых есть несколько версий (как оказалось, довольно часто у людей есть Exchange 2010 и Exchange 2016). В статистику по версии я занесу обе версии (таких хостов 557, версий около 600), максимально на одном хосте 4 разные версии.
Также есть 25к ip-адресов, для которых не удалось получить полную версию по нескольким причинам:
Заблокирован доступ ко всему сайту /ecp (или вообще выключен).
Для 2013 Exchange моя брутилка неэффективна (большинство без версий именно таких), об этом дальше будет подробнее (не настолько она неэффективна, надо просто больше данных).
Ошибка 503 - “Configuration file is not well-formed XML” тут вопросики к Microsoft конечно (при ошибке напишет внутреннее имя домена, но его и так несложно получить и пути установки).
Ошибка “нет места на жёстком диске” (тут наши полномочия всё, не думаю, что такое часто будет встречаться в бою).
В итоге, получилось следующий график по патчам:
Рисунок – распределение по патчам.
Уязвимых к Proxylogon (не имеющих мартовского, апрельского или майского патча) – почти 12% (или 14.5к), при этом очень грустно, что за месяц с выхода майского обновления обновилось только 35%, ещё более грустно, что апрельского патча (который закрыл CVE-2021-28480, CVE-2021-28481, CVE-2021-28482, CVE-2021-28483) не имеют более 45% серверов (45% это очень много, Карл).
Давайте теперь посмотрим какие версии вообще используются:
Тут я был сильно удивлён. Я знал, что 2016 Exchange много, но что его больше 50% —это удивительно (станет, пожалуй, основным стендом в тестировании). Однако то, что 2013 больше, чем 2019 — прям шок).
Сейчас будет ужасная диаграмма, она показывает распределение по всем версиям.
Забавно, что на 6 версий приходится более 50% (50.1, что конечно более 50)))). Также шокирует, что ни одна версия 2019 Exchange, которые продвигаются уже 2.5 года (с октября 2018), не попали в эти 50%. Но радует, что 2 самые популярные версии — это майский апдейт, и в топ 50 нет ни одной уязвимой версии к ProxyLogon.
В этот момент очень внимательный читатель (если ты такой, то я снимаю шляпу) должен сказать, что у меня ошибка! На версию 15.2.858.9 приходится 1.6% результатов, но такой версии Exchange не существует (по ссылкам с версиями)! Апрельский апдейт имеет номер 15.2.858.10, а по URL с XML нам отдаётся версия именно 15.2.858.9, её я и занёс в табличку, таких аномалий (тут тоже вопросик к майкрософт и к тому, как они собирают релизы. Я не представляю себе CI/CD процесс, в котором происходят такие косяки с версиями). Такая же проблема есть 15.1.2242.5 (4.4%!) результатов, тут вероятнее всего 15.1.2242.8 (другие версии в этом билде присутствует корректно). Разумеется, я поправил эти косяки от Майкрософт, когда делал распределение по апдейтам.
Также, возможно, именно с этим связано то, что для 2013 Exchange моя брутилка работала неэффективно. Я допускаю пропуск какого-то релиза, который почему-то назван иначе, хотя, вероятнее всего, я просто не дожидался ответов на бруте, так как файл microsoft.exchange.ediscovery.exporttool.application (смотри причину ошибки "нехватка места на жёстком диске") генерится при запросе заново, а я ждал всего 1 секунду. Если буду делать рескан для следующей громкой уязвимости в Exchange, то увеличу таймаут в бруте до 2 секунд.
Давайте посмотрим, как обстоят дела по странам. Для начала общее распределение по хостам, где удалось получить версию:
Тут из удивительного — 2 место у Германии с небольшим отставанием от Америки и то, что Австрия выше России. Попросили бы меня сказать топ 5 стран, я бы их и назвал (возможно, забыл бы Францию).
Теперь посмотрим на страны, которые проигнорировали мартовский патч:
Замечательный график, в котором мы (Россия) вырвались уже на 3 место, но справедливости ради он мало информативен, потому что показывает проценты в штуках, а не относительно количества Exchange в этой стране. Давайте перерисуем (уберём страны где меньше 100 Exchange, чтобы не получить пугающий результат) и построим табличку с долей уязвимых Exchange:
1 | China | 0.4398496241 |
2 | Azerbaijan | 0.3983739837 |
3 | Iran | 0.3683274021 |
4 | Kazakhstan | 0.3474576271 |
5 | Tunisia | 0.3282442748 |
6 | Jordan | 0.3051948052 |
7 | Egypt | 0.2795698925 |
8 | Hong Kong | 0.2784090909 |
9 | Morocco | 0.2748091603 |
10 | Belarus | 0.2688172043 |
11 | Brazil | 0.2406015038 |
12 | Kuwait | 0.2397660819 |
13 | Lebanon | 0.2326732673 |
14 | Russia | 0.2297514034 |
15 | Ukraine | 0.224789916 |
16 | Pakistan | 0.2058823529 |
17 | Saudi Arabia | 0.2058047493 |
18 | Mexico | 0.2054263566 |
19 | Serbia | 0.1989528796 |
20 | India | 0.196969697 |
21 | Bahrain | 0.1964285714 |
22 | United Arab Emirates | 0.1947743468 |
23 | Lithuania | 0.1904761905 |
24 | Ireland | 0.1826280624 |
25 | Cyprus | 0.1785714286 |
26 | Romania | 0.1783567134 |
27 | Portugal | 0.1705822268 |
28 | Hungary | 0.168161435 |
29 | Spain | 0.1670190275 |
30 | Bulgaria | 0.1563636364 |
31 | Bahamas | 0.145631068 |
32 | Italy | 0.1454955879 |
33 | France | 0.1375577367 |
34 | Turkey | 0.1275207592 |
35 | Latvia | 0.1203319502 |
36 | Iceland | 0.1185185185 |
37 | Israel | 0.1168341709 |
38 | Canada | 0.1126005362 |
39 | Greece | 0.1080508475 |
40 | USA | 0.1001739792 |
41 | Czechia | 0.0985452839 |
42 | Republic of South Africa | 0.09230769231 |
43 | Slovakia | 0.09207708779 |
44 | Poland | 0.08913043478 |
45 | Sweden | 0.08907446068 |
46 | Great Britain | 0.08891595615 |
47 | Croatia | 0.08881578947 |
48 | Slovenia | 0.07602339181 |
49 | Netherlands | 0.0718571039 |
50 | Denmark | 0.07004470939 |
51 | Switzerland | 0.05828904509 |
52 | Luxembourg | 0.05410447761 |
53 | Belgium | 0.05368289638 |
54 | Austria | 0.04895470383 |
55 | Estonia | 0.04301075269 |
56 | Norway | 0.04031007752 |
57 | Germany | 0.03809709876 |
58 | Liechtenstein | 0.0350877193 |
59 | Finland | 0.03225806452 |
Относительный топ раздолбаёв стран, которые не любят апдейты, куда показательнее. Я был удивлён, увидев на первом месте Китай! Далее со 2 по 7 идут страны ближнего востока.
В России мы имеем почти 23% хостов без мартовского патча, — это очень плохо (напоминаю, что мировой результат 11.9). Я посмотрел домены, там и госуха (в основном региональные), и универы, и военные подрядчики, кого там только нет (был бы у нас перечень субъектов КИИ, можно было с ним сравнить. Моя интуиция подсказывает, что там тоже были бы совпадения).
Лидер по количеству – Америка, имеет всего 10% хостов без патча. Была новость, что ФБР сами ломают и следят за действиями атакующих, такой вот ханипот из тех, кто не обновился). Второе место – Германия, которая показывает результат лучше – менее 4% уязвимых хостов. А лидером по установке патчей является неожиданно Финляндия. Тут тоже забавно, что больше всего следят за безопасностью страны из одного региона (назовём их викингами странами северной Европы).
В целом, можно накидать ещё кучу таблиц и диаграмм по имеющимся данным, но страниц и так много, если кому-то интересно – пишите в комментариях, я попробую построить.
«Уходите в облака. Это безопасно», - говорили они…
Я изначально исключил подсеть майкрософта, так как думал, что нет смысла сканить облака, но, возможно, я ошибался… Среди таргетов проскакивали облачные версии (639 раз с версиями) и знаете, у них не одна и та же версия у всех! Облачная версия имеет вид 15.20.xxxx.xx, 15.20 указывает, что это облако (вероятнее всего, оно работает на 2019 Exchange).
15.20.4173.33 | 1 |
15.20.4129.37 | 1 |
15.20.4150.33 | 1 |
15.20.4150.27 | 1 |
15.20.4150.34 | 1 |
15.20.4219.9 | 3 |
15.20.4173.32 | 4 |
15.20.4173.36 | 4 |
15.20.4195.21 | 6 |
15.20.4195.25 | 7 |
15.20.4195.20 | 11 |
15.20.4195.22 | 17 |
15.20.4219.13 | 17 |
15.20.4219.12 | 56 |
15.20.4195.23 | 57 |
15.20.4173.30 | 111 |
15.20.4195.24 | 341 |
Я честно не знаю, что означают эти цифры (но это очень похоже на версию! И оно находится в поле версии в xml!). Если гуглить эти цифры, то описание не находится, а находятся письма, где цифры идут после слова id. Но я буду считать, что это версия и говорить, что это очень странно, что есть:
Несколько параллельно живущих релизов (зачем??)
Самые популярные версии не самые последние!
Если принять, что 15.20.4195.24 версия с майским обновлением, то 23 – апрель, а 22 – март, то есть 20 и 21, которые должны быть уязвимы?
Уязвимы ли облачные версии Exchange к ProxyLogon?
Я сейчас в активном багаже имею крайне мало знаний об облачном Exchange (outlook, офис 365, Microsoft online) и эта тема требует отдельного большого ресёча (если кто-то хочет заняться — пишите, помогу с данными).
Немного ссылок на код
Накидал NSE для получения версии, пока без подписи, какая CVE (в будущем, наверное, доработаю) – ссылка на гитхаб
Если кто-то хочет воспроизвести результат – маленький питоновский скрипт (ссылка на гитхаб), который:
отправляет запрос в Netlas (можно редактировать сам запрос, количество получаемых записей и поля, которые хочется получить);
получает версию OWA и Exchange (нагрузку можно переписать под другое исследование);
пишет результат в csv (можете переписать в удобный вам формат).
Выводы
Очень жаль, что принятие обновлений безопасности в России ниже, чем в мире (говорю только про Exchange, но, думаю, и с другим софтом дела не лучше). Надеюсь, мы будем улучшать данный показатель, а значит, будет больше работы и рынок ИБ будет расти.
Надеюсь, что NSE-скриптик поможет много кому при пентесте, чтобы не проходить очевидно открытую дверь.
Надеюсь, что URL с версией добавят вендоры сканеров безопасности и жить станет ещё проще.
Много каких подводных камней явно забыл описать, если есть вопросы — пишите (можно в телегу, по нику @aaminin)
P.S. Если кто-то заинтересован в исследованиях на базе Netlas – пишите. Мы со своей стороны заинтересованы в развитии продукта и постараемся помочь Вам со сбором и выгрузкой необходимых данных при условии упоминания продукта в исследовании.