1 августа 2011 в 13:42

Аудит. «Черный ящик»

В данной статье я предложу вам технику аудита «черного ящика», которую можно освоить не обладая особыми знаниями и применить ее относительно своих ресурсов.

Естественно, статью можно перевести и в технику взлома ресурсов. Но чтобы знать, как защищать — надо знать, как взламывать. Ответственность за приобретенные знания вы берете на себя ;)

И если вы, как разработчик, будете знать хотя бы некоторые принципы и техники, что используют хакеры — думаю вам станет чуть спокойнее за них (ресурсы) и результат вашей деятельности приобретет более высокий уровень

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




Общая сводка о ресурсе


Перед этим блоком следует обратиться к моей предыдущей статье, так как в ней я отобразил очень удобные и эффективные бесплатные инструменты, которые нам помогут.

Естественно, все начинается с общего анализа целевого ресурса. В этом нам поможет Nmap. Один момент, запускать его следует с какой-нибудь внешней машины, а не локально. Чаще всего фаирволл сконфигурирован так, чтобы дать доступ ко всему с локальной сети, но корректно фильтрует пакеты из вне. А нам нужна объективная оценка.

nmap -A -T4 host

И получим что-то типа

Starting Nmap 5.51 ( nmap.org ) at 2011-08-01 11:38 NOVST
Nmap scan report for host (12.34.56.78)
Host is up (0.020s latency).
Not shown: 994 closed ports
PORT STATE SERVICE VERSION
22/tcp open ssh OpenSSH 5.3p1 Debian 3ubuntu7 (protocol 2.0)
80/tcp open http nginx 0.7.65
81/tcp open http Apache httpd 2.2.14 ((Ubuntu))
|_http-methods: No Allow or Public header in OPTIONS response (status code 200)
111/tcp open rpcbind 2 (rpc #100000)
443/tcp open http Apache httpd 2.2.14 ((Ubuntu))
|_http-title: 404 Not Found
8000/tcp open http Icecast streaming media server
|_http-title: Icecast Streaming Media Server
Service Info: OSs: Linux, Unix


Пока мы будем разбирать результаты Nmap'a, можно параллельно запустить Nessus с политикой «Web app tests». Он даст нам схожую сводку, а еще параллельно проверит по своей базе сервисы на сплоиты (имхо, одна из приоритетных его «фишек», не забывайте обновлять базу!). Зачем нам два раза проверять одно и тоже? Как показывает практика — иногда Nmap может раскрыть сервисы, которые не раскрывает никто из подобного рода утилит.

И так, видим сразу же ненастроенный фаирволл (81 — очевидный web-backend, который не закрыт). Установку ПО через пакетный менеджер ((Ubuntu) после имен сервисов. Кстати, теперь мы знаем, что там — Ubuntu).
Еще мы определили, что там за веб-бэкенд. Но обычно его версия раскрывается с помощью https, а тут и этого не потребовалось.

По поводу строки Not shown: 994 closed ports — по умолчанию Nmap проверяет 1000 распространенных портов, на которых обычно работают сервисы, для более быстрой выдачи результата. Нашел порт — минус 1 из тысячи.

Да простят меня ребята из Positive Technologies, но тут бы я еще параллельно посоветовал запустить XSpider, к примеру версии 7.7, который общедоступен в крякнутом варианте (собственно за это и извиняюсь).

Основная его цель у нас будет — это проверка на распространенные пароли (особенно в случае наличия ftp). Нет, конечно, есть еще очень много утилит для этого, но у нас начальный уровень аудита, который предполагает отсутствие словарей, навыков и знания подобных техник. Да и может чего сам XSpider нам расскажет интересного (хотелось бы отметить его очень редкие ошибки при анализе)

«Почекали» ресурс и там, и здесь. Можно переходить к более детальному «освоению» доступных нам сервисов. Если Nessus все еще проверяет, то перейдем к ручному поиску сплоитов. Более-менее актуальными являются базы:
и другие. Обычно другие сайты занимаются поиском эксплоитов на соседних сайтах, и так чуть ли не до рекурсии, как в «Ералаше», кто у кого списал :]

И вот тут я обозначу важный момент. Если написано, что эсплоит подходит к данной версии ПО, что у вас запущена, не факт, что он (эксплоит) заработает! Вполне возможно, что у вас та версия ПО, что уже already patched.

Тут же подключим уже полученные нами знания (из предыдущей статьи) по использованию Autopwn в Metasploit. Особенно полезно, если версии и/или названия сервисов установить не удалось.

Я не буду приводить результаты поисков эксплоитов для нашего случая, я просто описываю общую технику анализа. А тут уже и Nessus должен был закончить, приплюсуем его результаты (с учетом тонкости подхода к эксплоитам) и на этом текущий этап в нашем варианте аудита закончен.

И так, что уже мы имеем? Общую информацию о системе, запущенных сервисах, анонимном доступе/распространенных паролях, подверженности к эксплоитам (что есть в паблике, не забывайте про underground ;])
Вполне возможно, что на каком-то из этих этапов ресурс уже будет скомпрометирован.

Web со его тонкостями


Чаще все же взлом происходит именно с этой стороны. Тут довольно сложно дать какую-либо инструкцию, так как тут уж очень разнятся ситуации. Так что просто общий подход.
Запускаем Acunetix, подключаем Nikto, ждем печальных результатов. Закрываем дырки, что они обнаружили.

Аудит скриптов на сервере

Проверяем, что используется у нас на сервере.
В случае кастомных скриптов — анализируем информацию, что дали сканеры и пробуем, пробуем ручками! Тут все зависит от вашего уровня.
Основной принцип: подмена входящих данных (таких как $_GET, $_POST, $_COOKIE...) на то, что они (по задумке разработчика) не ожидали.
Тут все зависит от вашего уровня, который вы можете повысить на личном опыте или почитав статьи, которыми полон интернет. А плюсом будет развитое дедуктивное мышление.

Что по скриптам сторонних разработчиков?
Нам следует определить их версии, чтобы подыскать для них сплоиты (в тех же базах, что я приводил выше).
  1. Обычно скрипты выводят свою версию в footer'e. Это нам сразу, как аудиторам момент. Стоит убирать вывод версии скрипта, чтобы однажды вас не было в результатах GHDB (Google Dorks, пример)
  2. Еще способы? 99% разработчиков зачем-то заливают папку /docs или аналогичную на сервер (человеческий фактор, незнание, непонимание). У вас есть phpbb? Или WordPress? А мы сейчас проведем небольшой опыт :)
    phpBB/docs/CHANGELOG.html
    wordpress/readme.html
    Вуаля, в 95% случаев мы сможем узнать актуальную версию скрипта.
  3. Знание структуры скрипта и различие версий. Все упирается в ваш опыт и знания, с помощью которых вы сможете проанализировать скрипт и понять, какая скорее всего используется версия.
Проверяем на сплоиты. Тут ситуация иная, нежели с сервисным ПО. Не так часто, что эксплоит не подходит к данной версии скрипта, очень редко кто патчит текущую, не обновляясь до следующей.
Но тут другой момент, иногда отключена регистрация, иногда запрещены нужные bb коды, все обусловлено данной конкретной ситуацией, по этому надо проверять все вручную. Но как possible vulnerability это уже имеет место быть.

Не нашли сплоитов, стоит последняя версия скрипта, можно успокоится? НЕТ
Почему мы тестируем вручную кастомные скрипты разработчика, но не делаем тоже самое с популярными скриптами, имеющих последнюю версию? Нужно избавиться от стереотипов, а в частности — что за вас уже все нашли, а вы не можете оказаться умнее или «удачливее» других

К чему я? Не так давно в своей лаборатории я занялся анализом PHPBB самой его последней версии на данный момент (3.0.9). Сейчас я выдам вам расскажу один прием, который не даст вам привилегий (разве в редких случаях префикс таблиц), это лишь показательный момент

Профиль -> Личные настройки -> Общие настройки
Поле «Формат даты». Вводим

"""""

получаем
SQL ERROR [ mysqli ]
Data too long for column 'user_dateformat' at row 1 [1406]


Ошибка понятна, длина входящих данных проверяется еще до применения htmlentities(), а в базу запрос происходит уже с ним, получаем соответствующий результат.

Я рассказал вам это лишь для того, чтобы исключить у вас понятие авторитетности скриптов, ресурса, разработчиков и т.д.

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

Заключение


Я рассматривал здесь схему именно работы аудитора, совмещая ее с ситуацией, когда вы проверяете сами себя, по этому местами идет «перекрестная» ситуация и смешанные местоимения. Очень надеюсь, что кто решит использовать полученные знания и что-то найдет на стороннем ресурсе, выберет сторону WhiteHat и сообщит обо всем администратору ресурса. Так как ответственность теперь вся на вас.

Про «белый ящик» я тоже начал писать, но решил убрать, и так статья вышла довольна большая.
Если есть кому чего дополнить по аудиту «черного ящика» просьба писать в комментариях, а не выражать свое недовольство из-за парочки пропущенных моментов минусом статьи. И помним, это лишь основы аудита, с зацепками за тонкие моменты. Более профессиональный аудит подразумевает использование специальных локальных прокси серверов, которые будут подменять нужные нам данные и другие инструменты. Ну и некоторые специфичные техники и проверки на уязвимости или отказ в обслуживании.

Серия:
Sergey Belov @BeLove
карма
239,7
рейтинг 0,0
Пользователь
Похожие публикации
Самое читаемое Разработка

Комментарии (30)

  • +18
    Если бы не картинка, то я может быть и не зашёл бы сюда.

    Спасибо за интересную статью.
    • +6
      Глядя на картинку подумал, что будет разбор методов хака терминалов в Fallout. :)
    • +5
      картинку я выбирал не случайно.
      значит малый социальный инженеринг сработал)
      спасибо за отзыв :)
  • +5
    Какая картинка…
    /me пошел устанавливать Fallout 3.
    • +1
      Лучше сразу New Vegas.
      • +1
        New Vegas просто уже стоит… )
        • –1
          Тогда обычный и не нужен.
  • 0
    С нетерпением жду статьи по белому ящику :-)
  • 0
    Спасибо за статью!

    Сейчас пишу такой скрипт: запускатся по крону, пишет отчет в html. В конфиге servers.cfg указываются сервера, которые подвергаются аудиту, в конфиге packages.cfg указываются службы, которые надо проверять (mysql-server, php5, openssh, nginx и т.д.). Скрипт заходит на каждый сервер, проверяет текущую версию пакета, и версию в репозитории. После чего, выводит отчет с указанием версий, где подсвечены сервисы, которые нужно обновить.

    Кому-нибудь такое нужно, кроме меня? )
    • +1
      Может все-таки на серверах настроить автоматическое накатывание security updates, не?.. Зачем лишняя ручная работа?
      • 0
        Да просто чтобы видеть где какие версии стоят.
        Security updates это не отменяет.
        • 0
          Когда автообновление включено — смысл отчета с подсвеченными сервисами, которые нужно обновить — как-то пропадает…

          А так — я так понимаю, все сводится к чему-то типа:

          PACKAGES=$(cat packages.cfg)
          for I in $(cat servers.cfg); do
              ssh $I rpm -q $PACKAGES | sed 's/^/$I /'
          done
          

          rpm -q при необходимости заменяется на аналогичный вызов dpkg, pacman, pkg_info и т.п.
          • +2
            Забыл сказать: у меня целый зоопарк из FreeBSD и Ubuntu серверов. А мой скрипт проверяет универсально все сервера, не зависимо от типа (пока поддерживается только Ubuntu/Debian и FreeBSD).

            А автообновление — вещь не всегда уместная. Например, я только что накатил Security-апдейты на убунту-сервер и получил нерабочую VMware Server — она весьма чувствительна к ядру.
            • 0
              Практика показывает, что зверинцы надо уничтожать.
              • +1
                Ага. А если у вас есть молоток и отвертка, то отвертку можно выкинуть — шурупы ведь и молотком неплохо забиваются.
                • 0
                  неудачное сравнение. На текущий момент лично я не вижу причину держать freebsd. Все задачи прекрасно выполняются и в linux. Если вы используете ubuntu, смысл держать debian? Стабильность? Тогда смысл держать ubuntu. В общем если все искоренить нельзя, то как минимум надо минимизировать.
                  • 0
                    Даже яндекс использует Linux и FreeBSD. Причем, фря в приоритете (поиск на ней).
                    • 0
                      Уже нет. И да, то, что там было от Freebsd, именно что было. Очень много всего переделанно, многие драйверы для сетевых устройств были написанны с 0. Ну и еще раз, от freebsd yandex избавляется по мере возможности.
            • 0
              >> скрипт проверяет универсально все сервера, не зависимо от типа
              >> пока поддерживается только Ubuntu/Debian и FreeBSD
              улыбнуло.
  • 0
    >Более профессиональный аудит подразумевает использование специальных локальных прокси серверов, которые будут подменять нужные нам данные

    Можно поподробнее?
    • 0
      Да, конечно. ksavenkov упомянул об этомздесь
      Ссылка на сам прокси.
      Скажем так, упрощает работу, фильтрует (подменяет) нужные нам параметры при обмене с сервером.
      Стоит посмотреть скрины и все станет понятным :)
  • +4
    Мое глубокое убеждение, что в команде аудиторов должен быть хоть один программист для прстой скриптовой автоматизации, на выбор, кому что по душе Perl, PHP, Python, JavaScript… А вот C++, C#, Java для таких скриптов плохо подходят, на них сложнее писать оперативно, подход более основательный нужен, а для тестирования это не обязательно.
    Для разработчиков же (я имею в виду именно тех, кто пишет новые системы, а не прикручивает взятые из интернета готовые решения), вся защита сводится к очень короткому списку:
    • Валидируйте все входящие и исходящие данные по структуре и типам;
    • Не клейте SQL конкатенацией строк никогда, кроме случаев фреймворков (но во фреймворках можно и код более качественно писать, сделав дополнительную валидацию всех склеиваемых фрагментов);
    • Как можно чаще делайте кеширование чтобы избежать повторяющихся запросов и лишних нагрузок (кеш на диске, в памяти в специальных хеш-СУБД и т.д.);
    • Разделяйте систему для разработки (закрытую от внешнего мира) и продакшен систему (из которой нужно удалить половину, а оставшееся минифицировать и «утоптать» по максимуму);
    • Всегда предусматривайте блокировку запросов по IP, если с них идет странная активность (пользователь не сгенерирует 100 запросов в минуту и не будет долбить сервер 24 часа напролет, пользователи — люди, они едят и спят)
    • Определяйте попытки SQL-инъекций и XSS-инъекций, не просто их фильтруйте, а блокируйте IP
    • 0
      Я сошлюсь на ваш комментарий в одной из моих следующих статей, после аудита «белого ящика»
    • 0
      так как поддерживаю написанное Вами :-)
    • +2
      Люди, сидящие за NAT-ом (жители студенческих общежитий, например) будут вам невероятно благодарны за блокировку по IP.
      • +3
        Так задавайте для таких систем разумные лимиты на доступ. А для исключений еще и белый список можно иметь. Но вот на банковские платежные системы, например, такая защита даже в строгом виде имеет место быть.
  • +3
    Убираем из статьи воду:
    Анализ типа «черный ящик»:
    1. По прямым и косвенным признакам стараемся идентифицировать содержимое ящика
    2. Применяем перебор всех возможно шибочных входов
    3. Пытаемся придумать новый набор входных данных, которые могут вызвать ошибку.
  • +1
    Скоро я планирую написать статью про сервис websitedefender от Acunetix. Детали работы сервиса поддержка раскрывать отказалась, поэтому немного поправил их скрипт и пополняю логи. Анализ будет чуть позже ;)

    От себя замечу, что очень многие забывают про контроль самих файлов веб-приложения, концентрируясь на атаках извне через веб. Но есть же и шеллы, и вирусы, крадущие пароли от ftp из клиентов и пишущие потом iframe. А все это очень просто обнаруживается простейшим файловым монитором.

    В дипломе как раз такой прикручивал к phpids, чтобы получить phpips ;)

    Кстати, буду рад если кто подскажет, как можно повысить карму, чтобы статью потом можно было добавить в этот блог. Я на хабре пока только читаю в основном.
    • 0
      Кстати, буду рад если кто подскажет, как можно повысить карму
      В q&a упорно просить помогать людям и получать заслуженные плюсы.
  • 0
    Nessus вроде как сам использует nmap для сканирования открытых портов.

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