Pull to refresh

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

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

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

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

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




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


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

Естественно, все начинается с общего анализа целевого ресурса. В этом нам поможет 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 и сообщит обо всем администратору ресурса. Так как ответственность теперь вся на вас.

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

Серия:
Tags:
Hubs:
+79
Comments 30
Comments Comments 30

Articles