— Ребята, вы круты! Так нас еще никто не опускал!
— Мы старались.
Да, жизнь охотников за уязвимостями полна специфических комплиментов от заказчиков и не менее специфических ситуаций. За прошедший год мы выполнили более пятидесяти тестов на проникновение в разные компании и, надо сказать, повидали всякое. Один пароль ко всем учеткам и системам, открытое хранение паролей в базе данных, остатки отладочного функционала в боевой среде… Поэтому, когда наши коллеги из JSOC CERT поведали несколько историй по расследованию киберинцидентов, мы в отделе пентеста решили не отставать и показать другую сторону «баррикад»: инфраструктуру заказчика глазами хакера. Сегодня расскажем о наиболее интересных за последнее время внешних пентестах, когда мы должны были проникнуть во внутренний периметр заказчика, имея только список его внешних IP-адресов и доменных имен.
Одын, совсем одын
Понедельник:
— Ребята, стартуйте быстрее с пентестом — у вас всего 3 недели, чтобы нас взломать. Но учтите, что ваши шансы минимальны: нас так каждый год проверяют и никаких зацепок не находят.
Спустя 4 часа:
— Мы уже внутри.
— Да ладно? Не может такого быть! Сейчас проверим логи…
Пятница:
— Блин, и правда. Как так-то?! Но раз время не вышло, может, вы еще что-то поищете?
— Да не вопрос.
И мы стали искать. Сканируя периметр организации, мы наткнулись на хост, на котором крутилось 4 веб-приложения, FTP-сервер, а также висела админка phpMyAdmin. Анализ веб-приложений не выявил там каких-либо критичных уязвимостей (например, к SQL-инъекциям, XXE, RCE и т.п.), которые бы позволили нам получить доступ к серверу. В какой-то момент переключились на FTP — и вот тут было уже интереснее: на сервере был открыт анонимный доступ, но только на чтение.
В течение нескольких дней мы изучали содержимое сервера и нашли несколько странных строк в логах — несколько неправильно введенных паролей для одной из админок веб-приложения.
Основываясь на неправильных вариантах, мы сделали предположение, как должен выглядеть пароль, и он подошел. Решили попробовать его же для phpMyAdmin, и — о, чудо — он тоже подошел. Дальше дело было за малым — загрузить шелл, получить доступ во внутреннюю сеть, закрепиться там и развиваться уже внутри.
Вот так обычная лень (а как еще объяснить нежелание заводить разные пароли к каждой из админок?) прокладывает хакерам дорогу во внутреннюю сеть организации.
Зачем debug в боевой среде?
Большая часть наших пробивов происходит через web-приложения, и нередко мы натыкаемся на любопытные «останки» времен разработки и тестирования. Часто находим логи, какие-то куски debug-режимов, но не всегда с их помощью у нас получалось провести RCE (remote code execution).
У одного из наших клиентов в ходе работ мы обнаружили CRM-систему, на которую было решено потратить чуть больше времени (и, надо сказать, оно потом окупилось). Проводя анализ приложения, мы обнаружили остатки тестов, которые, видимо, использовались на этапе разработки. В них совершенно чУдным образом происходила аутентификация: проверялись только имя пользователя и факт передачи параметра, содержащего какой-нибудь пароль. Пять минут поиска и чтения стандартной документации — и у нас в руках имя встроенной учетной записи суперпользователя. Заливка шелла была уже делом техники.
Другой пример. На старте проекта мы запустили рекурсивный брутфорс поддоменов и оставили. Через некоторое время на наше удивление набрутился поддомен пятого уровня test.debug.application.client.ru, на котором мы нашли веб-приложение с установленным там Adminer'ом. Это легковесное приложение для администрирования баз данных, в старых версиях которого, при неправильных настройках можно без пароля взаимодействовать с SQLite-базой.
То, что в этой базе не было никаких данных, было не важно — ведь в SQLite можно создать базу данных по произвольному пути с простеньким веб-шеллом внутри, тем самым получив возможность удобно управлять сервером и исполнять на нем команды с веб-страницы.
Оставалось только узнать полный адрес web-приложения на сервере. Тут нам помогла всеми «любимая» CMS'ка 1С-Битрикс, которая в сообщении об ошибке с удовольствием поделилась с нами, где она расположена. Далее оставалось только залить шелл и заканчивать проект.
Работу с SQLite БД можно посмотреть по ссылке.
Нашел логи? Пароли в подарок!
К нам обратился заказчик с просьбой провести пентест веб-приложения. Три предыдущих года он проводил пентесты с другой командой и, вероятно, успел залатать часть дыр на периметре, поэтому быстрого успеха мы не ждали.
В ходе fuzzing’а веб-приложения мы нашли страничку, на которой велось логирование авторизации пользователей. В логе отображалось время и логин пользователя, вошедшего в приложение. Мы написали скрипт, который раз в пару минут опрашивал данную страничку, парсил ответ и записывал найденные логины в файлик. По прошествии нескольких дней нам удалось собрать порядка сотни логинов. Решили запустить подбор паролей — для 5 логинов они нашлись в списке ТОП-500 худших паролей.
Получив доступ в приложение, мы продолжили его анализировать и нашли другой интересный файл — в нем реальном времени отображались все запросы к БД. С таким удобным инструментом отладки поиск уязвимостей и эксплуатация найденной Boolean-Timebased SQL-инъекции стали уже тривиальной задачей.
Несмотря на то, что на дворе уже 2019 год, люди все еще считают, что хранить пароли в базе данных в открытом виде — это хорошая идея. Пользуемся этим и найденной SQL-инъекцией и получаем учетку администратора, с которой залить web-shell и открыть доступ во внутреннюю сеть организации не составило больших трудов.
Пометки на полях
Во-первых, проводите периодические тестирования на проникновение — они помогут вам найти тонкие места, которые вы могли пропустить на стадии разработки или при переходе с тестовых сред на боевые.
Во-вторых, всегда учитывайте человеческий фактор: людям бывает просто лень менять пароли, и они очень даже могут использовать один пароль на нескольких сайтах. Да-да, админы тоже этим грешат.
В-третьих, убирайте режимы отладки в боевых средах.
P.S.
Вообще будни отдела пентеста полны всяческих «развлечений» и, разумеется, внешние тесты — не единственное из них. Заказчик может пожелать провести проверку на уязвимости внутреннего периметра (внутренний пентест), или анализ защищенности веб- и мобильных приложений, а также WiFi-сетей, или устроить сотрудникам проверку методами социальной инженерии.
В свободное от проектов время мы
Обо всем многообразии наших «приключений» вы узнаете в следующих постах.
