Содержание статьи
Тестирование на проникновение (penetration testing) — метод оценки безопасности компьютерных систем или сетей средствами моделирования атаки злоумышленника. Для кого-то это хобби, для кого-то — работа, для кого-то — стиль жизни. На страницах нашего журнала мы постараемся познакомить тебя с профессией настоящего хакера на службе корпорации, с задачами, которые перед ним ставятся, и решениями этих задач.
Intro
Каждый пентестер, если вдруг не передумает по дороге, проходит путь от pentest monkey до Advanced — именно так, с большой буквы. И, конечно, каждый на этом пути совершает ошибки, большие и маленькие. Их корень чаще всего лежит в отсутствии опыта и знаний в предметной области. В своей практике я встречаю много пентестерских ошибок, и большинства из них можно было бы избежать, руководствуясь лишь одним принципом: «делай только то, в чем уверен».
Агрессивный ARP Spoofing
В тестировании на проникновение нередко приходится прибегать к атакам канального уровня, таким как ARP spoofing. Эта атака до сих пор эффективна, если нет соответствующей защиты. Как ты наверняка понял, атаки канального уровня обычно используются на этапе внутреннего тестирования на проникновение.
Находясь со своим ноутбуком в офисе заказчика, многие не брезгуют отравлять ARP кэш сразу целым диапазоном /24, а то и /23. И если ноут не справляется с нагрузкой, можно воспользоваться физическим доступом. Да-да, никто не отменял атаки на канальный уровень в том случае, если ты, преодолев сетевой периметр заказчика, развиваешь атаку внутри сети. Тогда, запустив ettercap/cain/intercepter-ng на захваченном хосте, можно круто обломаться и навсегда потерять доступ не только к хосту, но и к сети.
Причины просты — тормоза на уровне сети возникнут не только у тебя, но и у легитимных пользователей. Это заметят администраторы, которых наверняка в крайне строгой форме попросят объяснить, почему и как произошел подобный инцидент. С большой вероятностью точку входа во внутреннюю сеть закроют, пентест или атака перестанет быть секретом, администраторы будут внимательнее — и это все не говоря об организационной составляющей вопроса, ведь подобные действия серьезно мешают доступу к ресурсам.
Кейс кажется фантастикой? Как бы не так. Когда я был начинающим пентестером, схожая ситуация произошла со мной во время подготовки к работе с реальными заказчиками. Подключившись к своему рабочему компьютеру через VPN, я без задней мысли запустил Cain и врубил ARP spoofing. Перед тем, как соединение разорвалось, я успел лишь подумать, что утро — лучшее время для сбора доменных учеток, ведь все приходят на работу и начинают логиниться в домен. Это, пожалуй, была моя первая и последняя грубая ошибка в подходе к проведению пентеста.
Сетевой дестрой продолжался на протяжении получаса, после чего я сумел найти своего человека в организации, который обезвредил рабочий компьютер, выдернув из него шнур питания. Естественно, администраторы нашли по MAC-адресу мой компьютер, но тут их ждал сюрприз — он был выключен. Никто не подумал, что MAC можно подменить (я тоже об этом тогда не подумал, если честно), его включили и залогинились под учетной записью администратора домена (!), чтобы найти улики. И, конечно, нашли их.
Тогда все вместе посмеялись и продолжили работать, но после этого мне некоторое время было неловко общаться с админами. А ещё после этой истории я думал, что можно было бы установить себе на машину кейлоггер и получить учетную запись администратора домена — этакая ловля на живца. Однако все это осталось теорией, которую не пришлось проверять на практике.
Нестабильные эксплоиты
Для решения некоторых задач, будь то получение паролей из конфигурационных файлов или проведение ARP спуфинга, пентестеру необходимы максимальные привилегии в системе. В большинстве случаев они получаются через эксплуатацию уязвимостей в ядре.
Как известно, публичные эксплоиты — это скорее продвинутые proof-of-concept с возможностью выплевывать рутовый шелл, нежели отлаженные программы. Сужу по себе — все мои эксплоиты работают, но я не тестирую и не отлаживаю их ради стабильности. Если на следующей системе эксплоит не срабатывает, тогда-то я его и доработаю. Уверен, логика тебе понятна.
В ночной погоне за рутом несложно забыть, что эксплоит не стабилен, и что не следует его запускать без предварительного согласования с заказчиком. Но адреналин и желание достичь цели любым путем делают своё дело. Ты надеешься, что всё будет окей, но если есть ощущение риска, то лучше не спешить. Желание удивить заказчика своим мастерством — это хорошо, но малейшая вероятность нарушить доступность ресурса должна охладить тебя и остановить от рискованной попытки.
Конечно, эксплуатация эксплуатации рознь. Одно дело, когда сервис выдает ошибку отказа в обслуживании после попытки запустить кернел эксплоит, загруженный с exploit-db. Другое — отказ в обслуживании из-за того, что пентестер был стеснен во времени, не имел полного доступа к сети и вслепую запустил только что написанный им непротестированный эксплоит. Второй вариант, безусловно, выглядит куда более благородным, несмотря на схожий результат.
Один мой знакомый как-то попал в такую ситуацию и уронил сервис из-за некорректного шеллкода в своем эксплоите. Он не растерялся и предъявил заказчику примерно следующее: «Вы знаете, что у вас сервер X недоступен? Мы тут работаем и у нас время ограничено, срочно решите проблему!» Социальная инженерия на практике! Через пару минут уязвимый сервис снова стал доступен; за это время знакомый успел поправить шеллкод. В результате он получил доступ к серверу со второго раза. Однако рассмотренная ситуация — скорее исключение из правил, ведь знакомый был уверен, что шеллкод на этот раз отработает как надо.
Халатность, наглость, отсутствие осторожности
Эта троица — главные друзья правосудия, которое пытается настигнуть незадачливого хакера, ступившего на темную сторону. Но чего бояться белым шляпам? Оказывается, все того же.
Халатность
Представь, что ты развиваешь вектор атаки из большой сети DMZ во внутреннюю сеть организации. Вдруг ты понимаешь, что ты наткнулся на вероятную точку входа и ошибочно полагаешь, что она может быть не единственной. Эта мысль небезосновательна — сканирование сети DMZ идет своим ходом, а ты не хочешь терять время даром и начинаешь анализировать найденные сервисы и ресурсы. Отмечу особо — ни в коем случае не прибегай к подходу «Халк крушить» и думай, что делаешь. То, что тебя не заметили на этапе проникновения в DMZ, еще не говорит, что за ИС никто не следит. Не стоит расслабляться и забывать об осторожности.
Именно с такой беспечностью я однажды и столкнулся. К серверу на периметре DMZ и внутренней сети был получен доступ на исполнение команд через уязвимое веб-приложение, запущенное от рута. Хеши были сдамплены и скормлены JTR. Результат не заставил долго ждать и команда пентестеров успешно получила пароль к SSH. Далее же произошел настоящий факап — кто-то инициировал подключение по SSH к серверу в DMZ с целью проверить валидность логина и пароля. Зачем? Вероятно, ради красивого скриншота в отчете. Не стану томить — доступ к DMZ был потерян менее чем через час.
Оказалось, что сервер был единственным связующим звеном между внутренней сетью организации и DMZ. Администраторы внимательно за ним следили: одному из них по факту логина по SSH приходили SMS с идентификатором пользователя и IP адресом его хоста. Халатность привела к тому, что действия команды обнаружили. Проект перестал быть секретом для администраторов, действовать стало ещё сложнее. И, что оказалось для команды печальнее всего, нам пришлось работать неделю на выезде в маленьком областном городке в холодных стенах огромной организации.
Наглость
В практике каждого пентестера бывают моменты, когда хочется наперекор интуиции и здравому смыслу подключиться к VNC, Radmin или RDP компьютера администратора в его рабочее время. С одной стороны, это необходимость — в большинстве случаев администраторы выключают свои рабочие станции и уносят с собой ноутбуки. С другой стороны, это очень рискованный и зачастую опрометчивый шаг.
Если администратор не хранит пароли к сетевым устройствам на рабочем столе, риск не будет оправдан. Многие админы не покидают рабочее место на время обеда — для айтишника нормально провести перерыв за компьютером. В этой ситуации возникает вопрос: стоит ли дразнить администратора? Пентестер прекрасно понимает, что пользователь на удаленном хосте активен и малейшее воздействие на его интерактивный сеанс заметят. Наглеть или нет — личное дело каждого. В худшем случае вторжение будет обнаружено.
Я слышал огромное количество пентестерских историй о том, как кто-то влез в сеанс админа. Не буду скрывать, я сам проделывал такое пару-тройку раз. Но обычно это приносит уйму эмоций и совсем немного профита.
Чаще всего события разворачиваются так: ты подключаешься к компьютеру админа через Radmin и видишь, как тот набирает документ. После подключения в районе трея появляется всплывающее окно, которое уведомляет его о новом сеансе. Ты понимаешь, что это привлекло внимание человека за рабочей станцией. Он перестает набирать текст, курсор в документе мигает на белом фоне. Ты осознаешь, что администратор уже понимает: что-то происходит, кто-то вломился в его уютный домик. Ты пытаешься представить себе его лицо, его чувства.
Эти три секунды кажутся бесконечностью. Выброс адреналина на обоих концах соединения. Последнее, что ты видишь — указатель мыши на удаленном рабочем столе скользит в правый нижний угол экрана, кликает на иконку Radmin и терминирует все сессии.
Всплеск эмоций, лулзы, и абсолютно никакого профита. Прежде чем пойти на это, адекватно расставь для себя приоритеты в рамках проекта и просчитай все возможные риски. Если без нахрапа не прорваться, то будь готов к тому, что твое присутствие в ИС будет обнаружено.
Блокировка учетных записей
Брутфорс — неотъемлемая часть любого тестирования на проникновение. Пожалуй, следующую ошибку, о которой я расскажу, можно свалить на халатность. А дело вот в чем. Брутфорс часто используется для получения доступа к домену AD, и я встречал несколько случаев, когда пентестер в радостной спешке ориентировался на вывод команды net accounts /domain, исполненной не в той консоли. В результате он принимал свою локальную парольную политику за парольную политику домена, радовался тому, что значение счетчика блокировок учетных записей равно нулю, и начинал брутфорс доменных учеток по словарю. Надеюсь, ты понимаешь, к чему это приводит? В лучшем случае — пара заблоченных на пятнадцать минут учеток, в худшем — более 10% учетных записей заблокировано, вторжение обнаружено, доступность ИС грубо нарушена.
Плохая подготовка инструментария
От правильного инструментария зависит очень многое. Рабочий лэптоп пентестера должен, на мой взгляд, ломиться от всевозможных дистрибутивов и утилит всех мастей. Без правильных средств пентестер не сможет сделать абсолютно ничего. На практике же из-за банальной лени или отсутствия опыта многие пентестеры в первый день работ по внутреннему тестированию на проникновение не могут сделать ничего лучше, чем сканировать сеть, используя недавно установленный nmap. Выглядит это плачевно, драгоценное время уходит впустую.
Я совершал сходную ошибку как минимум однажды, когда был новичком. Чего я не ожидал увидеть, придя к заказчику, — так это череду баз данных Oracle. Конечно, ни транспорта, ни клиента для них у меня не было. День в итоге был потрачен на сканирование nmap, поиск уязвимостей в веб-приложениях и выявление стандартных учетных записей на устройствах.
Не повторяй подобных ошибок, будь готов ко всему. Как минимум имей в арсенале транспорты для всевозможных сервисов.
Дресс-код
Большинство пентестеров, вероятно, понимают, о чем пойдет речь. Как бы это глупо ни звучало, но иногда внешний вид бывает очень важен. Например, чтобы попасть на территорию какой-нибудь трансгалактической организации, занимающейся добычей минеральных ресурсов на Марсе, придется внешне соответствовать некоторым стандартам, очень нелегким для начинающего пентестера. Если не хочешь тратить время впустую, одевайся правильно. Интересуйся дресс-кодом заранее, и избежишь ряда проблем.
В моей практике была забавная история, когда мне и моим коллегам (к слову, тоже крутым пентестерам) довелось около часа дожидаться открытия магазина «Одежда для мужчин» в одной из провинций нашей необъятной родины. Не горю желанием об этом рассказывать, но там не оказалось зауженных брюк для худых молодых людей. К счастью для моих коллег, худым был только я, и смотрелся я в широких брюках, подшитых в соседнем ателье, очень комично. В итоге у меня есть замечательный «лук», но мы потеряли около трех часов рабочего времени. В условиях командировки и в первый день работ это очень много. Не переживай — неурядицы не помешали нам отлично справиться с задачей.
Отсутствие знаний об используемом инструментарии
Незнание или непонимание того, как конкретно работает та или иная утилита из твоего арсенала, может в один прекрасный момент сыграть с тобой очень злую шутку. Уверен ли ты, что сканер для автоматизированного поиска уязвимостей в веб-приложениях случайно не дропнет БД сайта, если найдет на нем SQL-инъекцию? Я на твоем месте ничего бы не утверждал, не погоняв сканер на тестовом стенде. Это поможет понять заложенную в него логику, и, если исходный код закрыт, это единственный способ проверки.
Я сталкивался с ситуацией, когда из-за использования sqlmap в режиме hack it, I don't care дропнули БД на копии продакшена, что привело к потере ценных человекочасов. Тебе может повезти меньше, чем тому незадачливому пентестеру. Вообще, ты должен быть готов отвечать за каждый процесс, который запускаешь в отношении ИС заказчика.
Отсутствие данных для отчета
Party time для пентестера подходит к концу сразу после того, как достигнута конечная цель, поставленная заказчиком. AD под контролем, сетевое оборудование под колпаком — отлично. Наступает этап подготовки отчета. Но в большинстве случаев начинающие пентестеры, дорвавшись до «мяса», не любят писать отчеты. Это можно понять. Сложнее понять другое. Начинаешь подготовку отчета, а скриншотов нет, логов нет, таймлайна атаки — нет. Мораль: никогда не ленись документировать все свои сколько-нибудь значимые действия, связанные с пентестом. Иначе можешь попасть в неприятную ситуацию, когда ты выполнил работу на «отлично», заказчик воодушевлен результатом и ждет подробнейший отчет. И что он увидит? Короче, не расстраивай заказчика, документируй!
Я знаком с этой ошибкой исключительно по опыту работы в команде. Иногда попадаешь в ситуацию, когда кто-то из твоей команды не делал скриншоты на протяжении всего проекта, или же скриншоты внезапно куда-то пропали. Причина отсутствия не так важна, но факт остается фактом — ошибка встречается. Если ты работаешь в команде, не забывай напоминать коллегам, что нужно документировать процесс, и подавай им хороший пример.
Outro
Не надо начинать после всего прочитанного бояться совершать ошибки. Все учатся на ошибках: кто-то на своих, кто-то на чужих. Эта колонка написана для того, чтобы можно было поучиться на чужих. Кстати, практически то же самое ты делаешь, когда выявляешь слабые места ИС и помогаешь их закрыть. Stay tuned.
WWW
Полезная информация
Ссылки по теме
The First Few Months of Penetration Testing: What They Don't Teach You in School
The Common Mistakes Every Newbie Pentester Makes
Общая теория по пентестам
Vulnerability Assessment
Open Source Security Testing Methodology Manual
The Penetration Testing Execution Standard
Немного практики
PentesterLab
Penetration Testing Practice Lab
В закладки
Open Penetration Testing Bookmarks Collection
