Хабрахабр

Записки pentester’а: случаи на охоте

image
— Ребята, вы круты! Так нас еще никто не опускал!
— Мы старались.

За прошедший год мы выполнили более пятидесяти тестов на проникновение в разные компании и, надо сказать, повидали всякое. Да, жизнь охотников за уязвимостями полна специфических комплиментов от заказчиков и не менее специфических ситуаций. Сегодня расскажем о наиболее интересных за последнее время внешних пентестах, когда мы должны были проникнуть во внутренний периметр заказчика, имея только список его внешних IP-адресов и доменных имен. Один пароль ко всем учеткам и системам, открытое хранение паролей в базе данных, остатки отладочного функционала в боевой среде… Поэтому, когда наши коллеги из JSOC CERT поведали несколько историй по расследованию киберинцидентов, мы в отделе пентеста решили не отставать и показать другую сторону «баррикад»: инфраструктуру заказчика глазами хакера.

Одын, совсем одын

Понедельник:
— Ребята, стартуйте быстрее с пентестом — у вас всего 3 недели, чтобы нас взломать. Но учтите, что ваши шансы минимальны: нас так каждый год проверяют и никаких зацепок не находят.

Не может такого быть! Спустя 4 часа:
— Мы уже внутри.
— Да ладно? Сейчас проверим логи…

Как так-то?! Пятница:
— Блин, и правда. Но раз время не вышло, может, вы еще что-то поищете?
— Да не вопрос.

Сканируя периметр организации, мы наткнулись на хост, на котором крутилось 4 веб-приложения, FTP-сервер, а также висела админка phpMyAdmin. И мы стали искать. В какой-то момент переключились на FTP — и вот тут было уже интереснее: на сервере был открыт анонимный доступ, но только на чтение.
image
В течение нескольких дней мы изучали содержимое сервера и нашли несколько странных строк в логах — несколько неправильно введенных паролей для одной из админок веб-приложения. Анализ веб-приложений не выявил там каких-либо критичных уязвимостей (например, к SQL-инъекциям, XXE, RCE и т.п.), которые бы позволили нам получить доступ к серверу. Решили попробовать его же для phpMyAdmin, и — о, чудо — он тоже подошел. image
Основываясь на неправильных вариантах, мы сделали предположение, как должен выглядеть пароль, и он подошел. Дальше дело было за малым — загрузить шелл, получить доступ во внутреннюю сеть, закрепиться там и развиваться уже внутри.

image
Вот так обычная лень (а как еще объяснить нежелание заводить разные пароли к каждой из админок?) прокладывает хакерам дорогу во внутреннюю сеть организации.

Зачем debug в боевой среде?

Большая часть наших пробивов происходит через web-приложения, и нередко мы натыкаемся на любопытные «останки» времен разработки и тестирования. Часто находим логи, какие-то куски debug-режимов, но не всегда с их помощью у нас получалось провести RCE (remote code execution).

Проводя анализ приложения, мы обнаружили остатки тестов, которые, видимо, использовались на этапе разработки. У одного из наших клиентов в ходе работ мы обнаружили CRM-систему, на которую было решено потратить чуть больше времени (и, надо сказать, оно потом окупилось). Пять минут поиска и чтения стандартной документации — и у нас в руках имя встроенной учетной записи суперпользователя. В них совершенно чУдным образом происходила аутентификация: проверялись только имя пользователя и факт передачи параметра, содержащего какой-нибудь пароль. На старте проекта мы запустили рекурсивный брутфорс поддоменов и оставили. Заливка шелла была уже делом техники.
image
Другой пример. Это легковесное приложение для администрирования баз данных, в старых версиях которого, при неправильных настройках можно без пароля взаимодействовать с SQLite-базой. Через некоторое время на наше удивление набрутился поддомен пятого уровня test.debug.application.client.ru, на котором мы нашли веб-приложение с установленным там Adminer'ом.

То, что в этой базе не было никаких данных, было не важно — ведь в SQLite можно создать базу данных по произвольному пути с простеньким веб-шеллом внутри, тем самым получив возможность удобно управлять сервером и исполнять на нем команды с веб-страницы.

Тут нам помогла всеми «любимая» CMS'ка 1С-Битрикс, которая в сообщении об ошибке с удовольствием поделилась с нами, где она расположена. Оставалось только узнать полный адрес web-приложения на сервере. Далее оставалось только залить шелл и заканчивать проект.
image
Работу с SQLite БД можно посмотреть по ссылке.

Нашел логи? Пароли в подарок!

К нам обратился заказчик с просьбой провести пентест веб-приложения. Три предыдущих года он проводил пентесты с другой командой и, вероятно, успел залатать часть дыр на периметре, поэтому быстрого успеха мы не ждали.

В логе отображалось время и логин пользователя, вошедшего в приложение. В ходе fuzzing’а веб-приложения мы нашли страничку, на которой велось логирование авторизации пользователей. По прошествии нескольких дней нам удалось собрать порядка сотни логинов. Мы написали скрипт, который раз в пару минут опрашивал данную страничку, парсил ответ и записывал найденные логины в файлик. Решили запустить подбор паролей — для 5 логинов они нашлись в списке ТОП-500 худших паролей.

С таким удобным инструментом отладки поиск уязвимостей и эксплуатация найденной Boolean-Timebased SQL-инъекции стали уже тривиальной задачей. Получив доступ в приложение, мы продолжили его анализировать и нашли другой интересный файл — в нем реальном времени отображались все запросы к БД.

Пользуемся этим и найденной SQL-инъекцией и получаем учетку администратора, с которой залить web-shell и открыть доступ во внутреннюю сеть организации не составило больших трудов. Несмотря на то, что на дворе уже 2019 год, люди все еще считают, что хранить пароли в базе данных в открытом виде — это хорошая идея.

Пометки на полях

Во-первых, проводите периодические тестирования на проникновение — они помогут вам найти тонкие места, которые вы могли пропустить на стадии разработки или при переходе с тестовых сред на боевые.

Да-да, админы тоже этим грешат. Во-вторых, всегда учитывайте человеческий фактор: людям бывает просто лень менять пароли, и они очень даже могут использовать один пароль на нескольких сайтах.

В-третьих, убирайте режимы отладки в боевых средах.

P.S.

Вообще будни отдела пентеста полны всяческих «развлечений» и, разумеется, внешние тесты — не единственное из них. Заказчик может пожелать провести проверку на уязвимости внутреннего периметра (внутренний пентест), или анализ защищенности веб- и мобильных приложений, а также WiFi-сетей, или устроить сотрудникам проверку методами социальной инженерии.

И занимаемся багбаунти (куда ж без этого). В свободное от проектов время мы постигаем дзен ищем новые уязвимости, улучшаем наши тулы и техники проведения работ.

Обо всем многообразии наших «приключений» вы узнаете в следующих постах.

Теги
Показать больше

Похожие статьи

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

Кнопка «Наверх»
Закрыть