|
Professor Seleznov
|
Всем привет! Меня зовут Сергей и ядиректор Центра Исследования Киберугроз в Angara Security. Занимаюсь и руковожу пентестами и редтимами всю свою сознательную ИБ-карьеру.
Хочу с вами, наши дорогие и уважаемые читатели, поделиться своими мыслями насчет подмены понятий в услугах по анализу защищенности. Очень часто я видел (да и сейчас часто вижу), как пентест называют "сканированием уязвимостей" или в понятие Red Team закладывают самый обычный пентест, пусть и с элементами "противодействия".
Не вдаваясь в подробности моей мотивации, я решил сделать цикл статей, где на основе своего опыта и опыта моих коллег постараюсь разложить весь offensive, с примерами и объяснениями действительно важных моментов, которые влияют на качество, длительность и стоимость таких работ, с разбором реальных кейсов из моей практики и прочими вещами. Сразу оговорюсь, я постараюсь это сделать в легком, ненапряжном формате, чтобы чтение этих статей не превратилось в унылое занятие и читателям не захотелось бы вместо чтения пойти «позалипать в рилсы» или заняться более полезными вещами. Ждать от статей какого-то рокетсаенса и разборов хардкорных техник не стоит. Наоборот, это будет скорее простой и разжеванный материал на более широкую и менее погруженную аудиторию.
Спойлер для тех, кто все-таки хочет вдаться в подробности мотивации
И все же, что меня сподвигло. Приведу один короткий, но показательный пример из моей реальной практики:
Суровые будни лида пентестеров...
Слева - мой давний товарищ и очень зрелый эксперт из Defensive Secuirty, от которого такой вопрос получить было, мягко говоря, неожиданно. Справа - рабочий чат с одним из клиентов в процессе проекта. Несмотря на отсутствие контекста, суть проблемы эти переписки отражают. Я бы понял и не обращал на это внимание, если бы это был 1 случай на 20-30 проектов. Но такое встречается с завидной регулярностью по сей день.
С одной стороны, это может быть не критично. Особенно, когда и заказчик и исполнитель ожидают от работ одного и того же. С другой стороны, такая "синхронизация" встречается не так часто, как хотелось бы. И это приводит не просто к недопониманию на уровне оперативного общения, а скорее и чаще к тому, что одна сторона (заказчик) ожидает одного результата, а другая сторона (исполнитель) выдает совсем другой результат. А иногда это "недопонимание" происходит на уровне анализа ТЗ и пресейла. Одни не понимают, почему это стоит дороже и проводится дольше ожидаемого, а другие не понимают почему условия в ТЗ противоречат сложившейся практике или что хочет от них заказчик в принципе. В конечном итоге никто не получает желаемого.
В связи с этим у меня (и не только) возникает непреодолимое желание рассказать миру, как все-таки понять этот нелегкий мир услуг offensive security, выделить для себя отличия в этих услугах и сделать вывод о пользе того или иного подхода, решая свои задачи. Конечно же, я далеко не первый (и не последний), кто пытается сделать то же самое. В сети есть определенное количество крутых статей, подкастов, видео-материалов, где так или иначе рассказывается все то же самое, и мои коллеги с «красной стороны » действительно сделали крутую работу, недооценивать которую я не хочу и не имею права (привет и респект ребятам из PT, Kaspersky, BI.Zone, Cicada8, УЦСБ, Singleton и множества других компаний). Вместе с этим, в каждом из этих материалов так или иначе (как минимум мне) не хватает каких-то нюансов для охвата всей картины: где-то техники, где-то организационки, где-то банальной базы, потому что расчет был на достаточно зрелую аудиторию. И чтобы сложить всю картину у себя в голове, нужно не только пересмотреть/перечитать/послушать все, но и местами даже самому заняться изучением вопроса. Это драгоценное время, которое у нас всегда в дефиците.
Начать цикл статей я бы хотел с цитаты французского мыслителя Вольтера:
Вольте́р, Франсуа́-Мари́ Аруэ́
французский писатель и философ, один из главных представителей просветительской мысли XVIII века
«Тот, кто не знает прошлого, не знает ни настоящего, ни будущего, ни самого себя»
Что-то слишком пафосно... В общем, давайтеначнем с истории offensive security на нашем рынке. Я надеюсь, что знание того, с чего все начиналось, в дальнейшем поможет понять те или иные нюансы современных пентестов и редтимов. К тому же такой краткий экскурс будет интересен молодым перспективным безопасникам, а олды поностальгируют и, возможно, даже смахнут скупую слезу.
Итак, поехали!
История offensive-услуг
Вернемся в (уже) далекий конец 00-х, начало 10-х годов 21 века. Информационная безопасность только набирала обороты, пентест как таковой еще не был так популярен как сейчас. Предлагали эту услугу немногие компании (навскидку я вспомнил только Информзащиту, ДиалогНаука, и Диджитал Секьюрити), а о внутренних пентест-командах в крупных компаниях было известно чуть меньше, чем ничего. Качество работ определялось уровнем энтузиазма пентестеров и количеством выполненных проектов. Усредненный процесс пентеста (например, внутреннего) на тот момент был примерно следующим:
- Приезжаем на объект;
- Проводим сетевые атаки типа ARP Spoofing или VLAN-hopping. Может быть, если кто-то был знаком с Responder (да-да, первый коммит на Github датируется аж 12 февраля 2013 года) - NBT-NS/LLMNR spoofing;
- Запускаем легендарный «сине-зеленый» сканер уязвимостей или пресловутый Xspider на все доступные подсети;
- Cмотрим результаты:
- Нашлось что-то? Супер, пробуем это эксплуатировать, вручную считаем CVSS, думаем над рекомендациями;
- Не нашлось - штош, идем писать про «Уровень защищенности - высокий»;
Примерный флоу любого внутряка тех времен
Спойлер для тех, кто мог бы обидеться...
Я не хочу сказать, что так делали все. Это усредненный пример, который варьировался от исполнителя к исполнителю. Поэтому пока отложите свои тапки, которыми хотите запустить в меня 
С внешним пентестом было примерно то же самое, только вышеупомянутый сканер дополнялся еще одним «бело-красным» сканером версии 10.5 для веб-приложений (помните, как он стал клиент-серверным?). Атаки на Kerberos? AD CS? Kubernetes? Нет, тогда этого еще не было. Хотя в 2017 году сильно нашумела история с ShadowBrokers и уязвимостью EternalBlue и с тех пор в арсенале у расторопных пентестеров, помимо metasploit'а, появилась своя виртуалочка с FuzzBunch.
Почему это было именно так? Для себя я выделил следующие причины:
- Отсутствие достаточного опыта на рынке.
Пентест, как методичная и формализованная активность, только созревал. Это нормально, никогда не получается сразу «сделать красиво».
- Уровень развития технологий и универсальность.
В то время не было разделения экспертов на направления, как это сейчас. Пентестеры были своего рода универсалами-ремесленниками, которые умели и «апрспуфинг» провести, и кавычку в форму веб-приложения пихнуть. Ну и, справедливости ради, на тот момент и веб был не таким тяжеловесным и по большей части серверсайдным, не было такого количества JavaScript-фреймворков, средства защиты еще не были такими «злыми», как сегодня, а наше комьюнити еще так глубоко не изучиловинду и Active Directory. Быть универсалом на тот момент было в какой-то степени нормой.
- Отсутствие адаптированной методической и практической базы.
Опытныебезопасники мне, конечно, могут возразить: «Сережа, ты не прав! Был тогда и OWASP, и NIST 800-115, и PTES». Не спорю, были, но есть небольшой нюанс, и на этом пункте давайте остановимся подробнее.
Действительно, все эти стандарты и методики на тот момент были, но не у нас. Не секрет, что мировые тренды до наших краев доходят с некоторой задержкой. Сейчас эта задержка, безусловно, сократилась до недель. Но мы же говорим про 10-е года. Попробуем найти аргументов в пользу этого и пройдемся по стандартам, которые чаще всего на слуху, могут быть практически применены и вы их видели (или даже сами писали) в отчетах по пентесту: OWASP, PTES, OSSTMM.
OWASP Testing Guide
История этого гайда начинается в 2004 году. Однако его более-менее используемым он стал примерно со второй версии, которую зарелизили в 2007 году. К нам он дошел ближе к началу 10-х годов. Была даже глобальная кампания по переводу этого гайда на разные языки мира, включая русский. Об этом писали на Хабре. Обратим внимание на дату - 2014 год.
Сам гайд содержит 270+ страниц и применить на практике его, как некий читшит, было (да и есть) достаточно сложно.
Поэтому некоторые пентестеры делали свои локальные читшиты на основе этого гайда и своего опыта. Впоследствии появился отдельный проект OWASP Cheat Sheet, который уже более-менее стал утилитарным. Правда, он появился только к 2018 году И, что немаловажно, данный гайд был полезен для тестирования приложений, но не покрывал «инфраструктуру» в достаточной мере.
PTES
Данный стандарт впервые был опубликован в 2009 году, и в отличие от того же OWASP Testing Guide больше описывал этапы процесса и рекомендуемые инструменты (список которых часто копипастился в «Перечень используемых инструментов» в тех же отчетах по пентесту). Опять же, использовать его как читшит или мануал было достаточно сложно, потому что текст PTES не подразумевает конкретики по тому или иному действию, а местами даже общая информация отсутствует.
Шел 2026 год...
OSSTMM
Еще один зарубежный стандарт, первая версия которого появилась в конце 2000 года (для тех, кто хочет посмотреть одну из первых версий - сюда), а третья версия (ныне актуальная) - в конце 2010 года. Опять же, если обратиться к тексту стандарта, то вы вряд ли найдете подробную информацию, например, как и чем эффективно выполнить фаззинг веб-приложения или как корректно сделать ARP spoofing, чтобы не завернуть весь трафик подсети через свой интерфейс и не положить сетку всего этажа офиса Заказчика на некоторое время. (опытным пентестерам должна быть знакома эта ситуация) Скорее, вы больше там увидите концепцию подхода к тестированию, начиная от определений (безопасности, комплаенса, границ, контролей и т.д) и заканчивая требований к результату, то есть что вы должны написать в отчет и в каком виде.
Не похоже на те отчеты, что вы писали или получали, правда?
Был еще ряд других стандартов, методик и справочников (например, IDART, PCI DSS Penetration Testing Guidance или RTFM), но все они были по большей части скорее формальными документами и имели мало отношения к практической реализации пентеста. Да, я знаю что были уже тогда и наши отечественные стандарты и методики (привет 15408, 27001, СТО БР ИББС и другие), но они были куда более формальными, чем вышеперечисленные документы.
Но это все "бумажная теория". Чтобы убедиться в своих выводах, я еще года 3 назад провел небольшой опрос среди своих друзей-знакомых, кто в те времена был рядовым пентестером.
Пациент номер раз
Пациент номер два (опечатался, бывает...)
Второй, кстати, верно замечает еще одну немаловажную вещь. Помимо методик и чек-листов, на тот момент не было такого разнообразия тренировочных площадок или образов для самостоятельного изучения азов хакинга. Я навскидку вспомнил лишь RootMe, bWAPP и Metasploitable . Ну и, конечно же, множество CTF-соревнований на CTFtime.org. (но мы-то знаем, насколько «близки» условия CTF к реальной жизни...)
На сегодняшний день существует просто несметное количество блогов, читшитов, курсов и площадок, посвященных пентесту и редтиму. Перечислять их здесь не буду, ибо времени на это может не хватить. Да, раньше были курсы и от EC-Council (тот же CEH), и от eLearn Security. Но они стоили денег, в отличие от общедоступных и бесплатных блогов и Github-репозиториев.
Результат таких работ - отдельный вид искусства. Давайте посмотрим на скриншот части реального отчета 2015 года одной уважаемой ИБ-компании:
Ууух, RCE в винде...
Но если посмотреть на описание этой же уязвимости в результатах вышеупомянутого «сине-зеленого» сканера уязвимостей...
Хмм...
...то станет ясно, что раздел отчета - это перевод-калька описания уязвимости из сканера. И в отчетах того времени было достаточно много таких разделов. (припоминаете, да, кто в те времена покупал пентест?)
Оттуда примерно и пошел этот стереотип, что пентестеры без сканера уязвимостей не работают. Кого-то устраивал (а может, даже и устраивает по сей день) такой результат. В этом нет ничего плохого, такое и сейчас можно встретить. Только это будет не отчет о пентесте, а скорее отчет о сканировании уязвимостей.
Итого, что имеем в итоге:
- Было не так много боевого опыта.
- Методическая база была, но не применима на практике.
- Практическая база у каждого была своя и уровень её экспертности зависел от энтузиазма пентестера.
- Пентестеры были «универсалами».
- Технологии на тот момент времени были не такими сложными.
Разница услуг тогда и сейчас
Вернемся в наше время. Если вы посещали известные конференции, где на большой площади стоит караван стендов с предложениями по услугам и продуктам, то однозначновидели буклеты с описанием всех предлагаемых услуг. И сегодня информация об offensive-услугах зачастую не помещается на одной стороне листка формата А5. Там будут такие предложения, как:
- Сканирование уязвимостей;
- Внешний пентест;
- Внутренний пентест;
- Анализ приложений (веб и мобильных);
- Соц.инженерия;
- Анализ Wi-Fi сетей;
- Физический пентест;
- CPT (он же Continuous Penetration Testing);
- Red Team;
- Purple Team;
- Киберучения.
Для сравнения, предложения тех времен насчитывали примерно 3 услуги:
- Пентест;
- Комплексный пентест;
- Анализ защищенности.
И каждая современная услуга по сути стала самостоятельной, со своими требованиями, ограничениями и особенностями. Оно и логично. Технологии стали куда сложнее (только контейнеры и облачные инфраструктуры чего стоят), времени на изучение/анализ конкретного куска инфраструктуры уходит больше, количество угроз и известных уязвимостей с каждым днем только увеличивается. Это все еще сверху сдабривается уровнем зрелости и разнообразием средств защиты, что, безусловно, усложняет и удорожает атаку, но никогда не сводит ее вероятность к нулю. Отсюда и выходит, что на каждый тип работ нужны свои компетенции, свои временные рамки и другие нюансы. Приведу пару примеров для аргументации своих мыслей, а если еще мои коллеги по цеху в комментариях подтвердят (или опровергнут) приведенные примеры - будет вообще здорово.
Внутренний пентест
Пример ранних внутренних пентестовя уже приводил выше. На тот момент не было известно и/или найдено такого количества уязвимостей, позволяющих полностью скомпрометировать всю инфраструктуру. Навскидку, из наиболее пробивных я могу вспомнить MS08-067 и MS17-010. Да и, откровенно говоря, в арсенале пентестера-инфраструктурщика было достаточно иметь сканер уязвимостей, metasploit и пару-тройку утилит типа Responder, THC-Hydra или bettercap, чтобы разломать инфраструктуру среднестатистического Заказчика.
Однако, после нашумевшего EternalBlue и выхода на сцену российского пентеста пресловутого Kerberoasting'а, (хотя официально он опубликован аж в 2014 году на Derbycon 2014, но первый коммит в Impacket скрипта GetUserSPNs.py был сделан в мае 2016 года, а до нас он докатился чуть позже) количество уязвимостей и атак на инфраструктуру Windows начало стремительно расти. К тому времени уже использовались ныне известные атаки типа UD/CD/RBCD, атаки на WSUS, ADCS, SCCM, Pre-2K атаки и т.д.
В процессе написания этого текста я решил воспользоваться благами технического прогресса и попросил нейросеть собрать мне такую статистику за последние 15+ лет. Что получилось:
Спасибо ЧатуЖПТ за кривую, но наглядную статистику
Спойлер для любознательных и недоверчивых
Дабы не грузить вас полным текстом ИИ-изысканий, поделюсь просто своим начальным промптом для тех, кто хочет сравнить результат с графиком выше:
Подготовь мне статистику выявленных уязвимостей в ОС Windows и Active Directory за период 2010-2025 год. В статистику должны попасть только те уязвимости, которые относятся к классу RCE и Relay, активно эксплуатировались в реальных атаках и имеют публичные инструменты и описания в блогах исследователей по безопасности. Дополни статистику перечнем атак на windows и Active Directory, которые мог быть не присвоен идентификатор CVE, но все равно использовались в реальных атаках и имеют публичное описание и инструменты эксплуатации. Например, атаки на Kerberos, LDAP, WSUS, SCCM и другие. То есть нужно определить, в какой год появилась та или иная атака и добавить эту информацию в статистику. В качестве источника таких атак можно использовать mindmap от Orange Cyberdefence (https://orange-cyberdefence.github.io/ocd-mindmaps/), но не ограничиваться только им. Для каждой уязвимости/атаки должна быть приведена ссылка на ресурс с описанием, а также ссылки на публично доступные инструменты и PoC.
Статистика должна быть представлена в следующих видах:
- Таблица с колонками "Год", "Названия уязвимостей", "Номера CVE", "Номера MS" (к примеру MS08-067), "Ссылки", где каждая строка - год публикации уязвимости/атаки
- Кумулятивный график обнаружения уязвимостей по годам, где ось X - годы, ось Y - количество уязвимостей
С того момента (то есть где-то с 2017-2018 годов) арсенал пентестера уже далеко вышел за рамки метасплоита. Там уже начали появляться и Impacket, и BloodHound, и всякие ntlmrelayx c certyfy/certipy, и многое-многое другое. С того же момента уже физически один среднестатистический offensive-эксперт не мог удержать в голове информацию и по приложениям, и по инфраструктуре. Ну и времени на выполнение качественного внутреннего пентеста стало уходить пропорционально больше, что в совокупности с остальным и сделало его из «этапа» в самостоятельную экспертную услугу.
Анализ приложений
Общая картина аналогична инфраструктурному пентесту. На заре оффенсива веб-приложения были преимущественноserver-side'ными. Всю логику и безопасность обеспечивал сервер, а JavaScript в подавляющем большинстве случаев отвечал только за интерпретацию данных на стороне клиента. Впоследствии, когда грубо говоря XSS-ки начали активнее эксплуатировать ITW, разработчики стали уделять больше внимания client-side'у и ответственнее применять всякие SOP/CORS/CSP и прочие механизмы, которые также к сегодняшнему дню драматически усложнились.
Также в сложности в работу веб-пентестеров добавили, конечно же, фреймворки и языки программирования. Опять же, если обратиться к публичной статистике появления языков и фреймворков для разработки приложений (пусть даже не совсем точной и собранной нейросеткой), то можно увидеть динамику роста зоопарка разнообразия технологий, с которыми приходится сталкиваться веберу. И чем свежее эта технология, тем вероятнее всего она разрабатывалась Secure by Design, а еще больше усложняет поиск уязвимостей в таком продукте. Приправим это сверху концепцией «многослойности».
Современное приложение - это уже не просто пачка PHP-файлов на файловойсистеме сервера, а целый комбайн из технологий типа Kubernetes, S3, gRPC, GraphQL и т.д., который еще и работает за реверс-прокси. Да, можно справедливо заметить, что множество используемых технологий в некотором виде шаблонизированы и стандартизованы. Но отсюда только и вырастает сложность, так как при исключении простых уязвимостей типа SQL-инъекций, XXE или небезопасных десериалиазиций, появляются более сложные баги, поиск которых требует не только знания базовых вещей «на зубок», но и понимания работы той или иной технологии на уровне профессионального разработчика.
И не стоит упускать тот факт, что в целом культура безопасной разработки за последние 15 лет выросла и не идет в сравнение с тем, что было в начале 10-х годов.
Спасибо (еще раз) ЧатуЖПТ за кривую, но наглядную статистику
Спойлер для любознательных и недоверчивых
Также делюсь своим начальным промптом, который я слегка подтюнил последующими вопросами:
Собери мне статистику появления языков программирования и фреймворков для разработки приложений, начиная с 2010 года и заканчивая 2025 годом. В статистике должны быть учтены популярные современные продукты, на основе которых сейчас разрабатывают веб и мобильные приложения. Статистика должна быть в двух видах:
1) Таблица с разбивкой по годам
2) Кумулятивный график появления продуктов, где ось X - годы, ось Y - количество продуктов
Такие же примеры можно привести и для внешних пентестов, и для «вайфаев», и других услуг, но тогда чтение этой статьи превратится в унылое занятие. В общем, суть вы уловили.
Спойлер для тех, кто потянулся за тапком
Я намеренно здесь не учитываю прогресс как самих средств защиты, так и зрелости ИБ-процессов в компаниях по причине того, что правильному пентесту, по-хорошему, не должны противодействовать. Но эту мысль я раскрою подробно в следующих статьях, не переживайте.
Как с этим жить
Скорее всего, у части читателей этой статьи возник вопрос: «И что дальше? Ну усложнилось всё, а мне что с этим дальше делать?». Справедливо, у меня бы тоже он возник. На этот и многие другие вопросы я отвечу в следующих статьях, где постараюсь подробно разобрать каждый из видов offensive-услуг в сравнении с другими.
Возможно, у вас есть и другие вопросы, которые вам было бы интересно разобрать в следующих материалах. Не стесняйтесь, пишите их в комментарии, а я постараюсь разобрать максимальное количество этих вопросов.
А пока, этим текстом мне хотелось погрузить читателя в очень краткий, местами субъективный экскурс offensive-услуг, который в дальнейшем поможет вам посмотреть немного под другим углом на те услуги, которые есть сейчас на рынке, и, я надеюсь, немного скорректировать ваше видение и понимание.
Stay tuned, до встречи в следующих статьях!-Источник
|
