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

    image

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


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

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


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

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

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

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

    image

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

    image

    Основываясь на неправильных вариантах, мы сделали предположение, как должен выглядеть пароль, и он подошел. Решили попробовать его же для phpMyAdmin, и — о, чудо — он тоже подошел. Дальше дело было за малым — загрузить шелл, получить доступ во внутреннюю сеть, закрепиться там и развиваться уже внутри.

    image

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

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


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

    У одного из наших клиентов в ходе работ мы обнаружили CRM-систему, на которую было решено потратить чуть больше времени (и, надо сказать, оно потом окупилось). Проводя анализ приложения, мы обнаружили остатки тестов, которые, видимо, использовались на этапе разработки. В них совершенно чУдным образом происходила аутентификация: проверялись только имя пользователя и факт передачи параметра, содержащего какой-нибудь пароль. Пять минут поиска и чтения стандартной документации — и у нас в руках имя встроенной учетной записи суперпользователя. Заливка шелла была уже делом техники.

    image

    Другой пример. На старте проекта мы запустили рекурсивный брутфорс поддоменов и оставили. Через некоторое время на наше удивление набрутился поддомен пятого уровня test.debug.application.client.ru, на котором мы нашли веб-приложение с установленным там Adminer'ом. Это легковесное приложение для администрирования баз данных, в старых версиях которого, при неправильных настройках можно без пароля взаимодействовать с SQLite-базой.

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

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

    image

    Работу с SQLite БД можно посмотреть по ссылке.

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


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

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

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

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

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


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

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

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

    P.S.


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

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

    Обо всем многообразии наших «приключений» вы узнаете в следующих постах.
    • +47
    • 12,5k
    • 7
    Ростелеком-Солар
    316,21
    Безопасность по имени Солнце
    Поделиться публикацией

    Комментарии 7

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


      А еще лучше проводить периодический аудит кода и инфраструктуры. Т.е. давать аудиторам возможность работы методом белого, а не черного, ящика. И дешевле, и результативнее.
        0
        А если например тот же интернет-магазин сделан на том же UMI? Там доступа к коду очень мал и не зависит от компании
        0
        у нас недавно тоже тесты делали, а может и не делали, прислали список проблем, где только название атаки и всё, типа если хотите подробнее это за дополнительную плату :D
        не знаю сколько это стоило, но такой список и я бы мог составить, особенно если учесть что ничего серьёзного не нашли, может надо «русских хакеров» порекомендовать нашим, надо только выяснить есть ли правильный сертификат у таких тестеров
          +1

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

            +1
            Хороший комментарий, но к сожалению не все зависит от нас. Потому что часть работы должна быть выполнена внутренней службой ИБ.

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

            К сожалению да, иногда встречаются случаи когда не фиксят уязвимости найденные в прошлом году.
            +1
            Было бы интересно узнать статистику.

            В скольких из тех тестирований были получены максимальные привилегии, преодолен периметр и т.п.? Были ли какие-то случаи, когда ничего сделать не получалось? Может какая-то разбивка по векторам: веб\социальная инженерия\атаки на перебор.
              +2
              Поделиться внутренней статистикой я не смогу, ее надо полноценно готовить.

              Могу поделиться исследованием Rapid7 (https://www.rapid7.com/research/report/under-the-hoodie-2019/), в нем есть статистика, и она, в принципе, будет похожа на нашу.

              Если говорить про остальное, то:
              >В скольких из тех тестирований были получены максимальные привилегии, преодолен периметр и т.п.?
              В целом, можно сказать 100%, правда это будет не совсем правдой, т.к. не всегда перед нами ставится задача пройти периметр. Иногда это были задачи по получению доступов к определенным серверам на внешнем периметре.
              Если говорить про максимальные привилегии в проектах по внутреннему тестированию на проникновение, то всегда, правда, были проекты, где это было не нужно, и мы получали доступы на сервера обозначенные клиентом почти с минимальными правами.

              >Были ли какие-то случаи, когда ничего сделать не получалось?
              Чтобы прям совсем ничего — нет, бывали случаи, когда мы не закрывали все цели из списка задач клиента.
              В целом надо понимать, что проект по пентесту длится ограниченное время и с ограничениями в используемых подходах (например, нельзя использовать эксплойты на определенных серверах).

              >Может какая-то разбивка по векторам: веб\социальная инженерия\атаки на перебор.
              По векторам ответил выше ссылкой.
              Но если ответить кратко, то будет как-то так:
              1) да, чаще всего это уязвимости web — sqli\file-upload\торчащие админки
              2) плохие парольные политики и реиспользование паролей, причем это характерно как для внешних, так и для внутренних тестов
              3) устаревшее ПО и отсутствие патчей, нередки ситуации, когда патчатся известные уязвимости (ms17-010), но на внешнем периметре может находиться редкий веб-сервер, для которого есть rce 2-3 летней давности

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

            Самое читаемое