Содержание статьи
Просканировать весь интернет
Решение
Интернет, как всем известно, очень большой. Даже больше, чем ты подумал. И как там обстоят дела, мало кто знает. Покопавшись в такой «кладовке», можно найти много интересных штук. Ну и для всякой статистики бывает полезно посканить что-нибудь по-настоящему большое.
Что нам требуется для этого? Желание, абузоустойчивый хостинг, немного тулз и сколько-то времени. И конечно, перечень диапазонов IP.
Warning!
Вся информация предоставлена исключительно в ознакомительных целях. Ни редакция, ни автор не несут ответственности за любой возможный вред, причиненный материалами данной статьи.
Начнем с конца. Как известно, не считая того, что перечень свободных диапазонов IPv4 кончился (то есть можно whois’ом узнать принадлежность любого из диапазонов), изначально диапазоны были разделены между регистраторами, что уже вносило территориальное разделение. Конечно, определенная степень погрешности есть, но фактически сейчас каждый диапазон «принадлежит» какой-то организации какой-то страны. И актуальные базы данных доступны бесплатно в интернете. Примеров масса: goo.gl/ezjgi9, worldips.info. Таким образом, мы можем «выдернуть» диапазоны какой-то страны и сканить их или сделать аналогичное по конкретной организации (здесь, правда, есть подводные камни, но об этом я уже писал в предыдущих номерах).
Почему не посканить весь инет — 0.0.0.0/0? Как минимум потому, что в данный диапазон попадает ряд специальных диапазонов (а-ля 127.0.0.1/8, 10.0.0.0/8, мультикасты и так далее), да и времени это займет много.
Далее — хостинг. Сканирование портов в зависимости от страны и провайдера может быть нежелательным, а то и незаконным действием. А если придется сканить что-то большое, то потребуется время, и это обязательно заметит провайдер и, возможно, примет меры. Конкретного совета не дам, лишь пара наблюдений. Между странами/континентами жалобы ходят реже/медленней (сканить Америку из Америки долго не получится, а вот даже из Европы — нормально). Крупные «игроки» обычно медлительней/либеральней меньших товарищей. Так, я больше года переписывался с индусами из Амазона, перед тем как они ввели хоть какие-то санкции на систематическое сканирование. Хотя тут все индивидуально. Например, Digital Ocean сначала заблочил акк и виртуалки, а потом стал разбираться, было ли это сканирование или еще что-то :).
Далее, тулзы и технологии. Конечно, чем сканить, сильно зависит от того, что мы хотим насканить. Если взять за основу сканирование портов, то можно взять и Nmap. Как ни странно, его можно настроить на приличный уровень скорости, и мы говорили об этом в прошлых номерах. Но все же лучше использовать более специализированные вещи, например ZMap или masscan. Оба сканера оптимизированы для быстрого сканирования крупных сетей:
- обработка TCP/IP-стека вынесена из ядра и реализована в пользовательском пространстве;
- запросы отправляются асинхронно (ПО не запоминает, куда и что было отправлено);
- общая оптимизация (один запрос на один порт) и допфичи (PF_RING).
Описывать, какой из них лучше, не буду. Могу лишь отметить, что ZMap более прост в использовании.
Несмотря на то что создатель masscan утверждает, что теоретически можно просканить весь интернет на один порт за несколько минут, фактически обнаруживается много подводных камней, влияющих либо на скорость, либо на точность информации.
Как ни странно, сканированием всего интернета (или его частей) люди занимаются систематически. А некоторые даже выкладывают итоги в Сеть. Так, веселый пример был в 2012 году, когда чел «похакал» с полмиллиона девайсов в интернете и заставил их просканить всю сеть на 700 портов (с детектом портов). Хаканье вроде как заключалось в небольшом подборе логина и пароля (root:root, admin:admin, без паролей и так далее). В итоге получилось 9 Тб общедоступных данных.
Компания Rapid7 (которая давно была известна сканированиями мира) наконец раскрыла свои данные и предложила проект Sonar. В рамках него она предоставила итоги сканирования десятка TCP- и UDP-портов (с баннерами — 2,4 Тб), обратные DNS PTR записи (50 Гб), данные SSL-сертификатов со всех 443 портов (50 Гб). А также предложила комьюнити делиться своими изысканиями и сканами. Так что у нас уже есть большая куча данных! Осталось теперь отпарсить и выискать интересуемое :).
Обойти SOP под Internet Explorer
Решение
Как ты, надеюсь, знаешь, SOP (Same Origin Policy) — одна из главных основ безопасности веба. Если сильно упростить, то взаимодействие между сайтами (ориджинами) в рамках браузера строго ограничено. Простейший пример: с помощью яваскрипта, загруженного с сайта Х, мы можем послать запрос на любой другой сайт, но получить ответ браузер нам даст, только если этим сайтом был Х.
По различным причинам SOP не представляет собой набор строгих правил, которые все соблюдают. Для различных технологий, имплементаций он может значительно отличаться. Microsoft, в силу бородатости и извращенности IE, здесь также выделяется на фоне других браузеров.
Сразу скажу, что там не все так плохо и «поломать весь веб» нам не удастся, но вкусности, которые помогут в трудную минуту, имеются. О некоторых из них мы и поговорим. Сразу упомяну, что, несмотря на падение количества пользователей, юзающих ИЕ (а следовательно, и потенциального импакта специфичных уязвимостей), общий процент их все же больше пятидесяти, а в корпоративном секторе так еще выше (до сих пор де-факто это стандарт). Для удобства я их разбил на несколько задачек.
Первый пример. Хотя и говорил выше о «сайтах», фактически в SOP речь идет об ориджинах. Под этим понимаются три составляющих: протокол (HTTP или HTTPS), доменное имя и порт. То есть http://example.com/test.html — это один ориджин, https://example.com:8080/test.html — другой (порт и протокол отличается). И в то же время http://www.example.com/ и http://example.com/page2/haha.xxx — один и тот же ориджин (отличие в path ни на что не влияет).
Все достаточно четко и просто, хотя и рождает ряд проблем для разрабов. Все браузеры придерживаются данной практики, за исключением Internet Explorer, как ты мог догадаться. Данный браузер пренебрегает номером порта — только протокол и домен. К чему это приводит? Например, в приведенном примере про отправку запросов IE разрешил бы нам получать ответы на запросы, посылаемые нами на тот же хост, но на другие порты.
Был случай на практике. У крупной корпоративной системы наружу торчало несколько веб-серверов (на разных портах). Один — главный с основным порталом, на который ходили пользователи, и несколько дополнительных административных. Так вот, в одном из админских сервисов была найдена хранимая XSS’ка. Им никто не пользовался, поэтому импакт был близким к нулю. Но, зная о специфике IE (о которой не знали разрабы), мы получили возможность атаковать пользователей основного портала. Наша XSS «на кривом порту» превратилась в приличную уязвимость всей системы.
Из практики могу сказать, что если в инете такие случаи редки (с несколькими веб-серверами/портами на одном домене), то в корпоративных сетях это распространенная ситуация.
Обойти SOP под Internet Explorer еще раз
Решение
Перейдем к двум другим примерам. Они достаточно новы: были представлены не так давно на конференции OWASP AppSec 2014 знаменитым хакером Ёсукэ Хасэгавой (Yosuke Hasegawa). Они на самом деле и просты, и угарны.
Первая фича основана на одном из компонентов ActiveX. Возможно, это покажется странным, но IE из коробки имеет приличный перечень активиксов, причем со свободным использованием их (нет ограничения по доменам, Safe for scripting, safe for init). Отказываться от этой подозрительной технологии они не собираются, да и не могут из-за обратной совместимости. И я не уверен, что все компоненты были копаны-перекопаны. Ведь на уровне ActiveX имеются возможности нарушать SOP, если потребуется.
Волнующий нас компонент — это Tabular Data Control (tdc.ocx, {333C7BC4-460F-11D0-BC04-0080C7055A83}). С его помощью мы получаем мини базу данных. Мы можем указать, где на сервере хранится информация (обычно в формате, похожем на CVS), как необходимо разбивать данные на поля и впоследствии иметь возможность доступа, отображения, сортировки полученных данных, как в таблице. Компонент появился аж в 4-й версии IE (хо-хоу, еще в прошлом веке!), а на сайте MS висит просьба не удалять его из новых версий, так как у кого-то приложения построены на этом компоненте… Самое интересное для нас — можно получать данные и с других сайтов (ориджинов).
Пример:
<meta http-equiv="x-ua-compatible" content="IE=10" >
<object id="tdc" ondatasetcomplete="show()" classid="clsid:333C7BC4-460F-11D0-BC04-0080C7055A83">
<param name="DataURL" value="http://victim_server.com/any_file.zxc"> </object>
<script>function show(){ var s = document.getElementById("tdc") .recordset.getString(); alert( s ); }</script>
Здесь мы инициализируем ActiveX, в DataURL указываем путь до файла. В функции show просто вытаскиваем данные. Yosuke указал в презентации необходимость в первой строчке, но, насколько я знаю, это если и необходимо, то только для IE11.
К сожалению, есть одно приличное ограничение для нас. Дабы сымитировать SOP, в компонент добавили требование — при доступе к файлам на другом сайте необходимо, чтобы в начале файла находилась следующая строчка: «@!allowdomains=имядомена», звездочки тоже работают (@!allow_domains=*). Имя домена, как ты понимаешь, — это место, откуда мы пытаемся сделать запрос.
Конечно, это сильно ограничивает наши возможности по краже данных, но без этого дыра была бы просто огромна. Таким образом, данные получится увести, только если мы можем контролировать первую строчку запрашиваемого файла. Не очень часто, но ситуации такие встречаются.
Причем заметь, они именно попытались имитировать SOP. Если файл хранится на том же домене, то первая строчка не нужна. Но подробности сверки доменов или протокола, не говоря уж о портах, неизвестны. Отмечу еще, что защититься на серверной стороне (если строчка все же может быть добавлена) непросто, так как ActiveX-компонент не воспринимает ни Content-Type, ни Content-Disposition.
И еще раз обойти SOP под Internet Explorer
Решение
Следующий трик основан на «полубаге». Как ты знаешь, SOP появился позже HTML’а, и у него есть ряд исключений. Так, картинки (тег img) мы можем свободно «таскать» с других сайтов. То же самое касается тега script. Мы можем указать путь в параметре src до скрипта на любом домене. Данный скрипт будет скачан и без проблем запущен, но уже в рамках нашего сайта.
Но есть исключения. Браузер может проверить Content-Type и при некорректном типе запретить исполнение JS. Плюс еще немного тонкостей.
Вообще, новых штук в этой области я давно не видел, но интересная находка была сделана в VBScript’е. Это некогда попытка MS создать конкурента для JavaScript, до сих пор счастливо существует в IE. И, соглашусь с Залевским, эта территория далеко еще не перекопана должным образом. Кто-то вообще занимался им глубоко? 🙂
Давай сначала покажу саму атаку, а потом ее разберем. Скрипт на нашей стороне:
<script> window.onerror = function( e ){ alert(e); } </script>
<script src="http:// victim_server.com /target.json" language="vbscript"> </script>
Содержимое target.json — классический JSON Array (массив):
[secret, data, here]
По коду все просто. В первом скрипте просто вешаемся на ивент для мониторинга появляющихся ошибок. А далее подключаем файл с атакуемого сервера.
Как думаешь, что произойдет?
Насколько я помню, такие баги были в браузерах лет пять назад… Да, мы получим доступ к данным, как к тексту возникшей ошибки «Несоответствие типа „secret, data, here“».
Здесь две причины. Во-первых, насколько я помню, IE не знает такого Content-Type, как application/json. Вроде только в IE11 добавили официально. Так как контент-тайп неизвестен, IE запускает процесс content-sniffing’а. Это такая технология (которая лет десять назад была актуальна из-за неразберихи с типами, веб-серверами и кодерами), по которой браузер различными способами пытается сам определить тип данных в получаемом ответе на запрос. У IE это анализ тела ответа и анализ расширения запрашиваемого файла (об этом я когда-то тоже писал). Во-вторых, ответ от сервера после некорректного определения его типа попадает в парсер VBScript’а. Далее все получается логично: парсер парсит, встречает первую ошибку, останавливается и возвращает ее.
На деле можно прочитать не только JSON массивы данных. Можно прочитать первую строку, цифру и так далее. Возможно, и еще что-то, но надо шарить в VBScript’е.
Замечу, что JSON-объект (те, что передаются в кривых скобках), прочитать не получится, так как в VBScript’е выражение не может начинаться с {.
Также интересный момент заключается в том, что это естественное поведение браузера и исправлять MS что-то не собираются.
Повысить привилегии в Windows через USB
Решение
Новые технологии — дело хорошее и полезное. А в нашей сфере они появляются с неимоверной скоростью, прям-таки размножение почкованием. Есть покрупнее и позаметнее (как HTLM5), а есть поменьше. И в современных серьезных проектах получается все большее и большее сплетение их. Но почти каждая технология как-то сказывается на информационной безопасности. Причем для крупных проектов становится трудно понять и просчитать все возможные последствия. Сейчас мы увидим это на небольшом примере.
Винда — она большая, и понятно, что уязвимости в ней систематически находят, хотя надо признать, что удаленные RCE уже редкость.
Одним из векторов атак на повышение привилегий всегда были разнообразные драйверы для оборудования. Это же касалось и USB. USB-порты есть на всех современных компьютерах, доступ к ним тоже, и было много ребят, которые пофаззили это дело. Итогом был ряд уязвимостей (как минимум DoS). Но микрософт не особо обращал на это дело внимание, не считал это дырами, так как для эксплуатации требовался физический доступ к хосту, возможность подключить к USB-порту свой девайс. А это, в свою очередь, нарушало одно из десяти правил ИБ (10 Immutable Laws of Security), которыми руководствуется MS. Но теперь кое-что изменилось.
Я думаю, каждому из нас знаком протокол RDP (Remote Desktop Protocol), который используется для удаленного доступа к винде. MS последние годы значительно расширяла его возможности. Они добавили возможности проброса периферийных устройств с клиента на сервер, serial-портов, возможность монтирования клиентских дисков. И казалось бы — вот теперь мы можем эксплуатировать баги удаленно! Подключаемся удаленно к серверу по RDP, «втыкаем» устройство в свой порт, прокидываем его и получаем повышение привилегий, например. Но нет, можно было пробрасывать только определенный набор устройств, причем это происходило на высоком уровне, после обработки драйверами на клиентской машине. Таким образом, проводить низкоуровневые атаки через USB было невозможно…
Но мир не стоит на месте, и Microsoft продолжает развивать RDP и службы терминалов. И в последних версиях серверной винды (Win 2008 R2 SP1, Win 2012) они добавили новую технологию — RemoteFX. На самом деле это не одна технология, а целый набор. Насколько я понимаю, своей целью Microsoft ставит устранить ограничения при использовании удаленного терминального доступа (когда он осуществляется с «тонкого» клиента) по сравнению с локальным пользованием компьютером. Так, с помощью RemoteFX имеется возможность работать с видео высокого разрешения, с 3D-графикой. Часть RemoteFX касается VoiceIP и поддержки мультитача. ИМХО, очень круто, с учетом роста количества планшетов и смартфонов такая технология будет очень востребована.
Но для нашей задачи самым интересным, конечно, будет «RemoteFX USB Redirection». Я думаю, что ты уже все понял. Она дает возможность низкоуровневого проброса USB на сервер. С помощью этой фичи пользователи могут пробросить на сервер любое USB-устройство. На клиенте даже не надо ставить дрова устройства, сразу на сервере. А мы же можем проводить наши атаки...
Пример такой атаки, да и сама идея эксплуатации через RemoteFX, были показаны на Black Hat 2014 Asia Энди Дэвисом (Andy Davis).
Интересно, что по умолчанию редирект USB отключен на клиентской части. Чтобы это поправить, надо зайти в групповые политики (команда mmc — Add/Remote Snap-In). Там по пути «Computer Configuration \ Administrative Templates \ Windows Components \ Remote Desktop Services \ Remote Desktop Connection Client \ RemoteFX USB Device Redirection» разрешить редирект. Далее выполняем gpupdate /force и перезагружаем комп.
С серверным же состоянием «по умолчанию» пока не ясно до конца. Вроде как все зависит от режима (роли) запуска терминального сервиса. Если это «стандартный» RDP — Remote Desktop Session Host, то отключено, а если Remote Desktop Virtualization Host (который используется для виртуализированных Hyper-V хостов) — включено.
Кстати, если тебя интересуют какие-то виды атак или технологии, о которых бы ты хотел узнать, либо ты хочешь исследовать что-то, поднять пентестерские скиллы — пиши на почту.
Спасибо за внимание и успешных познаний нового!
