Как успешно пройти любой пентест (вредные советы)
Если требуется вам срочно провести пентест,
Вы при этом не хотите по затылку получать,
То тогда быстрей смотрите приготовленный для вас
Список удивительных советов — он, конечно, вас спасет.
Этот пост написан в юмористическом ключе с целью продемонстрировать, что даже пентестеры, чья работа должна быть интересной и увлекательной, могут страдать от излишней бюрократии и нелояльности заказчиков.
Представим ситуацию: вы — специалист по информационной безопасности и знаете, что выстроенная вами защита — полная чушь. Возможно, вы этого и не знаете, но проверять особо не желаете, ведь кому хочется выходить из зоны комфорта и дополнительно что-то предпринимать, внедрять средства защиты, смягчать риски, отчитываться за бюджет?
Неожиданно в вашем тридевятом царстве, в тридесятом государстве возникает потребность провести пентест против вашей воли, например, что-то причудилось начальству, или нагрянуло новое требование законодательства. Вам очевидно, что стоит найти «шарашкину контору», которая сделает имитацию работ и напишет, что всё хорошо, и дело с концом, но ситуация усложняется. Ваша компания решает разыграть конкурс и сделать это максимально эффективно: написать разумное ТЗ, предъявить высокие требования к команде пентестеров (наличие сертификатов, участие в Bug bounty) и т.п. В общем, все сделали за вас, а ваша ответственность — только курировать работы.
Итак, команда найдена, договор подписан, уговорить спецов провести пентест спустя рукава не получилось. Ребята толковые, начнут работы с понедельника и разнесут вашу ИБ к чертям, после чего вы отхватите по шапке, и ваша некомпетентность будет раскрыта. Ситуация кажется вам максимально плачевной, но не тут-то было! Вот вам вредные советы, как устранить или хотя бы минимизировать эту головную боль.
Совет 1: согласовывайте каждый шаг.
Согласовывайте все: какие инструменты могут использовать пентестеры, какие атаки они будут проводить, какими рисками это обернется для вашей системы ИБ. Еще лучше запросить детальный (чуть ли не почасовой) план тестирования на каждый день. Будьте уверены: пентестеры вас возненавидят. Они-то думают, что у них творческая работа, но вы укажете им, что от них не требуется ничего, кроме тривиального выполнения работ. И помните: ваше оружие — время, тяните согласование максимально на каждом шагу. Аргументируйте это тем, что у вас крупная компания, и нужно получить множество одобрений: от владельцев систем, от ИТ, от офицеров безопасности и т.п. Если даже таких и нет, то можно что-то приукрасить.
Реально ли было?
Да, крупный и зрелый бизнес и в особенности эффективные менеджеры, сами того не желая, настолько часто перебарщивают с согласованиями, что это демотивирует всю команду. У людей не остается «драйва» на работы, желания креативить и что-то действительно взломать. Особенно странно, когда согласовывают только этап «поднятие привилегий» на конкретном сервере во вторник с 15:00 до 18:00 (это ведь так легко и естественно).
Совет 2: добавьте больше ограничений.
Добавляйте ограничения на проводимые работы: по количеству одновременных сканирований, по разрешенным IP-адресам, по эксплуатации и допустимым атакам. Запрещайте сканировать случайные IP-адреса из подсетей, объясняя это риском нарушить важные бизнес-процессы. Либо, наоборот, разрешайте сканировать только некоторые адреса и утверждайте, что результаты сканирования одного из сервисов можно экстраполировать на все остальные в подсети.
Реально ли было?
Очень часто на внутреннем пентесте вместо того, чтобы дать возможность пентестерам пройтись по всем локальным подсетям (192.168/16, 172.16/12, 10/8), заказчики просят исключить тот хост, ту подсеть и этот сегмент: «Здесь нужно протестировать только один из 500 хостов как типовой, а эти хосты только с 5 вечера до 9 утра — не более 300 TCP-сессий в секунду на хост». То, что работы рассчитаны на 5 дней, никого не волнует. Для исполнителя это выглядит ужасно: нельзя сделать нормальную автоматизацию, нужно постоянно контролировать, что инструменты не выходят за разрешенные границы, и приходится подкручивать кучу «костылей» ко всему инструментарию. Пока что-то где-то просканируешь и соберешь список сервисов, выяснится, что львиная доля времени уже потрачена. Также во время развития по сети видишь: вот он — сервис, на котором предположительно есть привилегированная учетная запись… Но его исключили из сканирования.
Совет 3: чаще просите отчитываться.
Согласования уже обговорили, а как насчет отчетности? Дать возможность людям спокойно заниматься работой и предоставить отчет в конце? Нет! Просите отчеты каждую неделю, день, полдня. Сошлитесь на негативный опыт предыдущих лет и на желание контролировать процесс, за который заплатили. Ух, как это «вставит палки в колеса».
Реально ли было?
Такое часто бывает. Даже спустя 5 минут начинают подходить из-за плеча и спрашивать: «ну что там, уже взломали?». В мессенджере дергают статус работ каждый час, а к концу дня ждут чуть ли не итоговый результат для руководства, красиво оформленный в Word-документе. В итоге специалист фокусируется на том, как написать отчет, а не на качестве тестирования.
Совет 4: просите записывать дамп трафика и писать экран.
Дополнительно потребуйте, чтобы пентестеры записывали экран и писали дамп сетевого трафика. Обоснуйте это тем, что вы переживаете за утечку конфиденциальной информации или оставление бэкдора.
Реально ли было?
Некоторые заказчики включают режим «параноик» и контролируют каждый твой шаг. По правде говоря, если будет очень нужно, пентестер точно найдет, как обойти запись экрана или сгенерировать необходимый трафик, и толку от этих мер довольно мало, а вот проведению работ они действительно сильно мешают.
Совет 5: общайтесь через трех менеджеров.
Общайтесь через 3+ менеджеров, тем самым играя в сломанный телефон и увеличивая сроки. Старайтесь не доводить требования напрямую до реальных исполнителей, общайтесь через посредников, особенно без опыта в прикладной части. В итоге получится такой паровоз, что информация будет доходить либо измененной, либо будет идти очень долго.
Реально ли было?
В крупных проектах это, скорее, правило, чем исключение. Работы заказывает ИБ-шник, курирует офицер безопасности, а общается с пентестером менеджер, причем иногда даже не напрямую, а через его менеджера. В итоге, даже убирая все остальные факторы, любой запрос достигает цели спустя полдня и возвращает ответ на какой-то другой вопрос.
Совет 6: ударьте по тщеславию.
Помните, что главное — это люди. Поэтому для снижения качества работ лучше всего бить прямо по ним, а точнее по их тщеславию. Спросите, как бы они тестировали малоизвестную технологию, а потом скажите, что ожидали большего. Добавьте, что пару лет назад предыдущие пентестеры взломали вашу компанию за 2 часа. Не важно, что тогда система была другая и СЗИ не было, да и вы работали в другом месте. Главное — сам факт: раз пентестеры не взломали за 2 часа, то и уважать их не за что. Видите, что пентестеры поплыли, — требуйте замены команды без увеличения сроков.
Реально ли было?
Истории про старые взломы мы действительно часто слышим, и это не имеет никакого отношения к текущей инфраструктуре и процессам ИБ. Вопросы про то, насколько безопасна вот эта «ноунейм» технология, тоже не редкость, приходится быстро разбираться и давать сжатый ответ, что не всегда достаточно.
Еще один интересный кейс: у нас в команде есть девушка-пентестер, и когда она приезжает делать внутренний пентест, заказчики сначала относятся с недоверием, а потом ходят посмотреть на неё как на экспонат. Работать в таких условиях захочет не каждый.
Совет 7: сократите удобства.
Работа в темной каморке, где не ловит сотовая связь? Работа в шумном коворкинге? Сломанный и скрипучий стул? Сломанный кондиционер? Для того, чтобы сходить в туалет и попить воды, нужен сопровождающий? Думаю, вы уже поняли, что нужно делать.
Реально ли было?
Да, и еще раз да. Отчаянных случаев было мало, но ситуаций, когда думаешь не о работе, а о том, как побыстрее свалить отсюда из-за внешних условий, хватает.
Совет 8: оставьте все проактивные средства защиты включенными.
Переходим к техническим приколам. Пускай PCI DSS и другие методологии рекомендуют отключать некоторые проактивные СЗИ для большей проработки тестирования — вам нужно сделать наоборот. Пусть люди мучаются в поисках решения, как в короткий срок протестировать корпоративную сеть, где их всё время блокируют.
Сразу погасите порт на коммутаторе, в который воткнулся пентестер. А потом громко кричите, что пентест провален и выгоняйте ненавистных хацкеров с объекта.
Реально ли было?
Мы уже привыкли к тестированию при включенных проактивных СЗИ (IPS, WAF). Плохо, что в таком случае львиная доля времени уходит на проверку СЗИ, а не на тестирование самой инфраструктуры.
Совет 9: посадите в специальный vlan.
Предоставьте нереальный сетевой доступ, который не соответствует типовому пользовательскому доступу. Пусть в той подсети ничего и никого не будет. А правила фильтрации будут deny\deny или близкие к этому.
Реально ли было?
Да, как-то нам предоставили доступ к подсети с одним принтером и в сетевой изоляции от других сетей. Все работы свелись к тестированию принтера. Как технические специалисты мы, конечно, всё отразили в отчете, но это ничего не изменило. Была и обратная ситуация, когда мы через принтер взломали половину компании, но это совсем другая история.
Совет 10: проводите работы через VPN.
Проводить внутренний пентест в реальном помещении, где пентестер может получить кучу дополнительной информации (настройки корпоративного телефона, принтера, подслушать живой разговор сотрудников, увидеть оборудование глазами), — это не ваш случай. Вам нужно провести работы, как бы эмулирующие «внутреннего нарушителя», и вот это «как бы» трактуйте, как вам удобно. Поэтому предоставьте доступ только через VPN и лучше пустите его не самым коротким маршрутом. Вдобавок сделайте только L3-доступ, ведь сетевые атаки на уровне L2 не актуальны [сарказм]. Обосновать это можно экономией средств: зачем людям к вам лишний раз ездить, занимать рабочие места, мешать работникам, если и так нормально.
Реально ли было?
Да, вполне нормальная ситуация — проводить пентест организации через недо-VPN L3. Всё виснет, канал забивается, инструменты воспринимают задержки как недоступность сервисов, а про невозможность широковещательных атак и MITM и говорить нечего. Да и после нормальных внутренних пентестов с выездом пентест по VPN как бег по песку в коньках.
Совет 11: никакого серого ящика.
Никаких учетных записей, никакой документации, никакой дополнительной информации давать пентестерам не следует, даже если этого требует договор. Чего доброго, им это пригодится быстрее добиться результатов. Обоснуйте тем, что реальный хакер (образ, навязанный в СМИ) придет и сразу всё взломает. Пристают — давайте документацию десятилетней давности.
Реально ли было?
Вроде бы все люди «в теме» понимают, что злоумышленник, настроенный серьезно, не будет садиться и пытаться взломать систему топорно, он сначала проведет разведку, соберет доступную информацию, пообщается с людьми. Если это внутренний нарушитель, то он уже знает, кто, что и где. Работник находится внутри процессов и имеет багаж знаний. Но все равно 80% пентестов — это «черный ящик», где ты должен за 5 минут прийти, сам во всем разобраться и взломать, иначе не «тру-хакер».
Совет 12: не разрешайте обмениваться информацией между различными направлениями (внутрянкой, внешкой и социалкой).
Регламентируйте разрозненное проведение работ, лучше разными специалистами и строго без передачи информации между направлениями. Обоснуйте это тем, что вам нужно точно определить риски для каждого направления.
Если на внешнем периметре для взлома была задействована «инсайдерская» информация (полученная изнутри), то ни в коем случае не засчитывайте такие работы, говорите, что это вам не интересно и не соответствует заявленным работам. Если для внутреннего пентеста пригодилась информация, полученная после «социальной инженерии», тоже говорите, что это не считается.
Реально ли было?
Это фактически подход классического пентеста, результаты каждого тестирования действительно требуются независимо, как будто реальный злоумышленник и правда так поступает. Но по факту APT-группировки так не работают.
Совет 13: сообщите всем в компании, что у вас пентест.
Объявите на всю компанию, что у вас пентест. Пусть все уберут стикеры с учетными данными, никто не открывает вложения в почте и не вставляет найденные флешки в USB. Работники с привилегированными правами доступа пусть уйдут в отпуск или на обучение и отключат свои компьютеры, но самое главное — сменят свой пароль «qwerty» на случайный (хотя бы на время проведения пентеста). В общем, активность внутри компании должна быть максимально снижена, а бдительность повышена. Таким образом вы значительно снизите возможность атак, направленных на работников и развитие внутри сети.
Реально ли было?
Ну конечно, было. Начинаешь работы и видишь, что люди предупреждены, пароли недавно поменяли, относятся к тебе с подозрением. Часть компьютеров проверить нельзя, потому что люди на обучении — «чистая случайность».
Совет 14: мониторьте пентестеров.
Бросьте все свои обычные дела и просто мониторьте пентестеров. Даже если у вас нет мониторинга — пытайтесь. Как только видите, что они что-то нашли, тут же блокируйте доступ, меняйте права, удаляйте учетку, гасите порты. Если очень нужно — «увольняйте» людей.
Реально ли было?
О, это вообще «любимое». Говоришь заказчику: «мы будем проводить пентест и обо всём критичном сообщать вам, только вы ничего не меняйте, мы ведь помогаем найти не просто конкретный недостаток, а вскрыть плохие процессы». И как только что-то сообщаешь, тут же в короткий срок это «случайно» меняется. Вот несколько реальных случаев.
- Обнаружена учетная запись на SMB-ресурсе, не менявшемся 5 лет, которая предположительно дает доступ к «администратору домена» в два шага. Предупреждаешь заказчика, что будешь дальше работать с учетом этих данных — тут же чудесным образом файл удаляется, словно его не было.
- В пятницу получен список учетных записей, на выходных проведен офлайн-анализ. Становится понятно, что есть почти «домен админ». В понедельник выясняется, что учетная запись заблокирована, а администратор якобы уволен. «Так совпало».
- В понедельник просканирован хост, потенциальную уязвимость RCE не успели проэксплуатировать, во вторник утром соответствующие порты уже фильтруются, либо хоста нет и в помине.
Совет 15: запретите эксплуатацию уязвимостей!
Если по каким-то причинам пентестерам всё-таки удалось найти уязвимость, и они запрашивают у вас согласование на её эксплуатацию, не соглашайтесь; обоснуйте нарушением доступности. Этот ноутбук для презентаций — критичный бизнес-сервис!
Реально ли было?
Да, это тоже бывает постоянно. Видно, что на сервере есть критичные данные и есть уязвимость, а заказчик не согласовывает эксплуатацию. В итоге исполнитель теряет точку входа, которая могла потянуть за собой целый ворох проблем вплоть до компрометации всей компании. А если не согласовали, в отчете просто пишется: «эксплуатация не согласована», и фактически ничего интересного в отчете нет.
Совет 16: чаще приостанавливайте работы.
На все инциденты ИТ говорите, что это из-за пентеста, и приостанавливайте работы. Если инцидента нет, то придумайте его. Просите предоставить логи всего, что делал пентестер позавчера с 14:00 до 15:00 — пусть разбирает свой трафик и вспоминает, какую из сотни проверок каким инструментом и куда запускал.
Реально ли было?
От этого страдают не только пентестеры, но ИБ в целом. Как только начинаешь проводить работы, любой инцидент в организации сразу приводит к необходимости их остановить и разобраться. Сервер стал недоступным — это пентестеры; у пользователя вылез вирус — это пентестеры; сломалась кофеварка в буфете — это пентестеры. Мы к этому относимся с юмором и терпением, но время знатно съедает.
Совет 17: запретите анализировать файловые диски и почту.
Запретите пентестерам после получения доступа к файловым дискам и почте анализировать их содержимое. Обоснуйте это «ну очень конфиденциальной информацией».
Реально ли было?
Конечно, есть 20 почтовых ящиков администраторов, а читать письма нельзя. Впрочем, на практике мы множество раз извлекали дополнительные пароли именно в почте, и они сильно помогали в компрометации компании. И да, реальный хакер, конечно же, выгрузил бы всю почту и никого не спросил.
Совет 18: попросите проанализировать вендорское ПО.
Скажите, что из всей инфраструктуры в целом вы бы хотели, чтобы специалисты проанализировали вендорское ПО, особенно, если оно сильно распространенное и это почти «коробочная версия» без дополнительной конфигурации.
Реально ли было?
Бывает, что просят взломать чистую Cisco ASA или нечто похожее. Мы говорим, что это продукт широко распространен и, скорее всего, много кем был протестирован, можем проверить «misconfiguration», но фаззить всё во время пентеста нет смысла. Это фактически поиск 0day, и лучше проводить тестирование на стенде в совокупности с обратным реверс-инжинирингом. Заказчики кивают и все равно просят протестировать во время пентеста, что успеем. Почти всегда это пустая трата времени.
Совет 19: скорректируйте финальный отчет.
Самое сладкое: если всё-таки взлом осуществлен и пентестеры предъявили вам первую версию отчета, просто попросите убрать критичные моменты из него. Это же бизнес, и вам должны выдать отчет, за который вы заплатили.
Реально ли было?
Бывают забавные моменты, от которых хочется смеяться и плакать. То «уберите почту генерального директора из отчета», то «вот этот сервер нужно убрать», то «кто вас просил заходить на компьютеры службы ИБ — быстро уберите». Иногда правят формулировки, благодаря которым один и тот же факт из ужасного становится вполне приемлемым.
Совет 20: настройте лютую дичь на сетевых устройствах.
А почему бы и нет? Если у вас стальные яйца кулаки и есть техническая возможность, то создайте хаос. Например, пусть каждый 27 tcp-пакет, возвращаемый пентестеру, приходит битым. Главное, чтобы никто не заметил.
Реально ли было?
Пока что не было, но это не точно. Может, аномальное поведение сканера в одном из 100 случаев и было последствием подобных мер.
Заключение
В отчете никто не пишет про миллион проблем, возникших в ходе работ: что доступ предоставляли 5 часов, что согласовывали эксплуатацию 2 дня, что был стул без спинки, дуло из форточки и т.п. Всё это остается «за кадром», а по результатам работ выдается сухой технической отчет, взглянув на который, независимый человек просто не поймет, сколько боли за ним стоит.
В Центре информационной безопасности «Инфосистемы Джет» мы работаем со средним и крупным бизнесом. Часть данных советов выполняются заказчиками в фоновом режиме по причине внутренних особенностей организации, критичности информационных систем и большого количества ответственных. Это нормальные процессы для минимизации риска влияния работ по анализу защищенности на бизнес-процессы. Впрочем, по большей части у нас развязаны руки и выстроены дружественные отношения с заказчиками. Мы можем сами предлагать правильные подходы и взаимодействие, удобное обеим сторонам. Даже в сложных забюрократизированных организациях всегда можно найти гибкое решение и провести качественные работы, если правильно договориться с заинтересованными людьми.
