Как ты стал пентестером?
До Positive Technologies я занимался промышленной разработкой, но кибербезопасностью интересовался всегда: сидел на профильных ресурсах, следил за разными ИБ-компаниями, в том числе за «Позитивом». Увидел на Хабре, что РТ открывают стажировку, и решил поучаствовать. Послушал первую лекцию, попробовал сделать практическое задание и забрал весь сервер с задачками и флаги! Записал видео, отправил куратору стажировки, и меня пригласили на интервью. До этого я и не думал, что смогу попасть в крупную московскую ИБ-компанию, а тут появился повод... Так я оказался в Positive Technologies.
Поначалу я проводил аудит безопасности веб-приложений, а потом мне сказали: «По штатке ты пентестер, значит, иди пентесть!» Само собой, местами не хватало навыков, и многое приходилось наверстывать в процессе работы. Как говорится, улица — моя школа :) Во время выполнения проектных задач неминуемо получаешь новый опыт и развиваешься.
Почему ты выбрал светлую сторону?
Для меня неприемлемо нарушать закон. Когда ты белый хакер, ты в ситуации win-win: компании сами заинтересованы в исследовании инфраструктуры на предмет уязвимостей, мисконфигураций и т. д. Выигрывают обе стороны, а иногда даже больше: ведь если мы находим уязвимости в коробочном софте, информация уходит вендору. В конечном счете это выгодно всем, кто пользуется определенным ПО.
Как вендоры реагируют на ваши отчеты?
Не все хотят публичной огласки: получение идентификаторов уязвимостей (CVE ID или БДУ ФСТЭК) для многих до сих пор неприемлемо. Кроме того, сейчас западные вендоры обрабатывают репорты от российских специалистов не так быстро, как отечественные компании. Но справедливости ради замечу, что зачастую наше сотрудничество проходит очень конструктивно.
Например, сейчас мы в контакте с крупным зарубежным ИБ-вендором, который очень внимательно отнесся к уязвимости, найденной сотрудником нашей команды, и даже самостоятельно пересчитал ее CVSS-рейтинг на более высокий (то есть оценил ее как более критичную).
Как бороться с уязвимостями на периметре?
Практически в каждом периметре есть хотя бы одна критичная уязвимость, которая позволяет проникнуть в инфраструктуру компании. Возьмем, к примеру, статистику нашей команды: в прошлом году мы пробили 96% внешних сетевых периметров клиентов. Оставшиеся 4% выпали из-за наличия у компаний крепкой DMZ (демилитаризованной зоны), однако даже в этом случае сам периметровый хост был скомпрометирован. Причины просты: наличие уязвимостей в ПО на периметре (в первую очередь в веб-приложениях), слабая парольная политика и разного рода мисконфиги.
Трендовые уязвимости, как правило, долго на периметре не живут. О них узнают быстро — из постов в X (бывш. Twitter) [соцсеть запрещена на территории Российской Федерации] и из профильных ТГ-каналов, из блога Лукацкого и т. д. Другое дело, если уязвимость не получила огласки, — в этом случае ИТ-команды не торопятся ее патчить. Можно поресерчить и за день написать эксплойт, а потом использовать в пентесте против уязвимого хоста.
Практически в каждом внешнем сетевом периметре есть хотя бы одна критичная уязвимость, которая позволяет проникнуть в инфраструктуру компании.
Positive Technologies вы тоже пентестите?
Регулярно, но в разном масштабе. Иногда это полноценное From Zero To Hero, когда мы начинаем как внешний нарушитель и продвигаемся по внутренней сети. Либо это фрагментарные проекты — если нужно проверить конкретные сервисы или процессы.
В какой момент компании стоит привлекать команду внешних пентестеров?
Компания должна знать, что она хочет получить от проекта, и четко понимать свой уровень ИБ-зрелости. Пентест можно использовать как способ оценки защищенности, но не на первых порах. Для начала необходимо закрыть базовые задачи: провести инвентаризацию активов, понять, что находится на внешнем периметре, а что в DMZ, и выяснить, как правильно их разграничить. Если у компании нет DMZ, можно ли ее выделить, чтобы бизнес не остановился? Стоит ли провести сегментацию сети? Затем нужно подтянуть навыки ИТ-команды, нанять квалифицированных ИБ-специалистов и уже после настройки инфраструктуры приглашать пентестеров.
Компания должна знать, что она хочет получить от пентеста, и четко понимать свой уровень ИБ-зрелости.
Как часто нужно проводить пентесты, чтобы обеспечить защищенность компании?
Частота проверки зависит от уровня ИБ-зрелости. Одно я знаю точно: даже регулярные пентесты не повысят вашу защищенность, если вы просто будете патчить найденные уязвимости.
Некоторые компании мы ломаем из года в год. Почему? Потому что устранение уязвимостей и усложнение парольной политики — лишь одна сторона медали. Вторая — это попытка затруднить продвижение потенциального нарушителя к критичным участкам инфраструктуры компании. Этот путь должен усиленно мониторить SOC. Нужно развесить колокольчики в правильных местах: нарушитель задевает один из них, появляется алерт и начинается ретроспективное расследование. Фолз или настоящая сработка? Если настоящая, как нарушитель здесь оказался? И так далее, то есть речь идет о выстраивании процесса обеспечения информационной безопасности.
Как распределяются роли в команде пентестеров?
Как правило, на одном проекте работают от двух до пяти человек. Распределение ролей зависит от типа задачи. В классическом пентесте (без противодействия со стороны клиента) ребята ведут свободный поиск уязвимостей. В проектах red team координации больше, поскольку нужно уклоняться от противодействия ИБ-специалистов — то есть требуется не просто скомпрометировать инфраструктуру, а действовать так, чтобы тебя не заметили. Один из простых способов (хотя и не лишенный недостатков) — атаковать ночью, когда все спят. Но все же ночь не панацея, нужно уметь быть незаметным в любое время.
Инфраструктура клиента для нас — черный ящик, мы мало что о ней знаем. Как именно осуществляется мониторинг? Какие правила используются? Мы можем только предполагать, как работает детектирующая логика и на что смотрят защитники. Кроме того, у всех стоят антивирусы: если залить непроверенный файл, антивирусное ПО его съест и выдаст детект, а для атакующих это не очень хорошая история. Поэтому для сложных проектов особенно важна координация в команде. Нужно четко распределить задачи, роли и постоянно обмениваться актуальной информацией.
Расскажи про план пентеста. Как вы действуете?
Во-первых, нужно собрать скоуп: набор IP-адресов, блоков IP-адресов, доменов и поддоменов, которые относятся к инфраструктуре клиента и дочерним компаниям. Клиенты редко приходят со своим скоупом, тем более что мы зачастую находим больше ИТ-активов, чем указано в скоупе, который может предоставить заказчик. Чем шире поверхность атаки, тем выше вероятность обнаружить уязвимости. Затем скоуп нужно согласовать с заказчиком и подписать авторизационное письмо — указать сроки реализации проекта и объекты проверки. Это важный документ для белого хакера — та самая юридическая страховка, которая подтверждает, что мы действуем в интересах клиента и в рамках закона.
Далее мы проводим полное сканирование скоупа: идем по нашему чек-листу, пробуем эксплуатировать известные уязвимости. Уже на этом этапе можно получить первые результаты в виде пробива периметра или обнаружения уязвимостей высокой степени риска. Затем переходим к анализу веб-приложений — именно через них, по нашей статистике, осуществляются три четверти пробивов. Смотрим вебчик и брутим учетные данные: в первую очередь нас интересует возможность подбора доменных учетных данных на различных сервисах, доступных на внешнем периметре. Не у всех сервисов и учеток есть второй фактор, и иногда наличия даже одной валидной учетной записи достаточно для преодоления внешнего периметра.
Проломив периметр одним способом, мы не останавливаемся: смотрим, как еще можно попасть внутрь. Отмечу, что мы включаем в отчет все уязвимости, которые находим. Естественно, в первую очередь важны критичные, но, если обнаруживается что-то попроще, почему бы не добавить?
От чего зависит сложность проекта? Почему одни пробивы реализуются за 20 минут, а над другими можно работать месяцами?
Истории в формате «пришел — увидел — победил» характерны для компаний, которые не следят за патч-менеджментом. Ты просто находишь старый софт с известными уязвимостями — и все: считай, что прошел.
Наиболее сложные проекты — red team в большой зрелой компании, где тебе противостоят ИБ-специалисты, в том числе сотрудники SOC. Приведу пример приема, который мы используем в подобном случае: смотрим коробочный софт, достаем дистрибутивы и разворачиваем у себя. Назовем это «серым ящиком». Если находим уязвимости, пробуем их проэксплуатировать на периметре и провалиться внутрь. Но многое может помешать. Например, грамотно организованная DMZ: в этом случае придется делать еще один рывок, чтобы оказаться во внутренней корпоративной сети. Или, к примеру, на нашем пути может встать микросегментация: ты попал внутрь, но особо ничего не видишь. Такие истории способны сильно затормозить хакера.
Где белому хакеру прокачать свои навыки?
Времена, когда хакер был универсалом: и вебчик ломал, и реверс делал, и атаковал, — уходят в прошлое. Сейчас важнее глубина знаний по конкретной специализации. Я советую выбрать одно-два направления, в которых хочется расти. А для практики рекомендую киберполигон Standoff — это школа жизни. Он создан с учетом кейсов, которые мы видели в реальных компаниях.
Времена, когда хакер был универсалом: и вебчик ломал, и реверс делал, и атаковал, — уходят в прошлое.
Как ты относишься к Bug Bounty?
Для компаний это отличный способ закрывать уязвимости на периметре, а для хакеров — возможность попрактиковаться, повысить свою репутацию и заработать денег. Стоит ли в этом участвовать? Безусловно!
Есть мнение, что в публичных Bug Bounty искать нечего: «Да там уже все нашли…». Это не так. Во-первых, регулярно появляются новые программы, где все оказываются в равных условиях. Во-вторых, изучая ИТ-процессы, архитектуру и типовые ошибки, характерные для конкретной компании, ты формируешь насмотренность на эту программу Bug Bounty и постепенно начинаешь видеть уязвимости и мисконфиги, которые другие пропустили.
Сначала нужно зарекомендовать себя в открытых программах. В закрытые приглашают тех, кто хорошо ломает, находит много критичных уязвимостей и не присылает мусорные репорты.
Как начинающему пентестеру попасть к тебе в команду?
Как минимум у человека должен быть релевантный опыт в ИБ. Если он умеет ломать веб, это хорошо. Если ломает веб и внутрянку — отлично. Если у него есть свои исследования, CVE и БДУ ФСТЭК — шикарно. Главное — чтобы при этом он действовал в рамках закона.
Нам интересны и сами пентестеры, и более узкие специалисты — например, ресерчеры. Недавно мы сформировали команду исследователей софта, внутри которой есть разные направления — например, Web Security и Reverse. Есть и более узкие специализации, к примеру, эксперты, которые занимаются только задачами OSINT. Если чувствуете, что есть силы, приходите к нам на интервью.
