Всем привет! Меня зовут Сергей и я директор Центра Исследования Киберугроз в Angara Security. Занимаюсь и руковожу пентестами и редтимами всю свою сознательную ИБ‑карьеру.

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

Спойлер для тех, кто все-таки хочет вдаться в подробности мотивации

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

Слева — мой давний товарищ и очень зрелый эксперт из 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 не подразумевает конкретики по тому или иному действию, а местами даже общая информация отсутствует.

OSSTMM

Еще один зарубежный стандарт, первая версия которого появилась в конце 2000 года (для тех, кто хочет посмотреть одну из первых версий — сюда), а третья версия (ныне актуальная) — в конце 2010 года. Опять же, если обратиться к тексту стандарта, то вы вряд ли найдете подробную информацию, например, как и чем эффективно выполнить фаззинг веб‑приложения или как корректно сделать ARP spoofing, чтобы не завернуть весь трафик подсети через свой интерфейс и не положить сетку всего этажа офиса Заказчика на некоторое время. (опытным пентестерам должна быть знакома эта ситуация) Скорее, вы больше там увидите концепцию подхода к тестированию, начиная от определений (безопасности, комплаенса, границ, контролей и т.д) и заканчивая требований к результату, то есть что вы должны написать в отчет и в каком виде.

Был еще ряд других стандартов, методик и справочников (например, IDART, PCI DSS Penetration Testing Guidance или RTFM), но все они были по большей части скорее формальными документами и имели мало отношения к практической реализации пентеста. Да, я знаю что были уже тогда и наши отечественные стандарты и методики (привет 15408, 27001, СТО БР ИББС и другие), но они были куда более формальными, чем вышеперечисленные документы.

Но это все «бумажная теория». Чтобы убедиться в своих выводах, я еще года 3 назад провел небольшой опрос среди своих друзей‑знакомых, кто в те времена был рядовым пентестером.

Результат таких работ — отдельный вид искусства. Давайте посмотрим на скриншот части реального отчета 2015 года одной уважаемой ИБ‑компании:

Но если посмотреть на описание этой же уязвимости в результатах вышеупомянутого «сине-зеленого» сканера уязвимостей...

...то станет ясно, что раздел отчета — это перевод‑калька описания уязвимо сти из сканера. И в отчетах того времени было достаточно много таких разделов. (припоминаете, да, кто в те времена покупал пентест?)

Оттуда примерно и пошел этот стереотип, что пентестеры без сканера уязвимостей не работают. Кого-то устраивал (а может, даже и устраивает по сей день) такой результат. В этом нет ничего плохого, такое и сейчас можно встретить. Только это будет не отчет о пентесте, а скорее отчет о сканировании уязвимостей.

Итого, что имеем в итоге:

1. Было не так много боевого опыта.

2. Методическая база была, но не применима на практике.

3. Практическая база у каждого была своя и уровень её экспертности зависел от энтузиазма пентестера.

4. Пентестеры были «универсалами».

5. Технологии на тот момент времени были не такими сложными.

Разница услуг тогда и сейчас

Вернемся в наше время. Если вы посещали известные конференции, где на большой площади стоит караван стендов с предложениями по услугам и продуктам, то однозначно видели буклеты с описанием всех предлагаемых услуг. И сегодня информация об 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+ лет. Что получилось:

Стого момента (то есть где‑то с 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-х годов.

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

Как с этим жить

Скорее всего, у части читателей этой статьи возник вопрос: «И что дальше? Ну усложнилось всё, а мне что с этим дальше делать?». Справедливо, у меня бы тоже он возник. На этот и многие другие вопросы я отвечу в следующих статьях, где постараюсь подробно разобрать каждый из видов offensive‑услуг в сравнении с другими.

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

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

Stay tuned, до встречи в следующих статьях!