Мок-собес на пентестера вживую

Собеседование на пентестера: ход мысли важнее заученного ответа

На техническом собеседовании на пентестера (специалиста по тестированию на проникновение) редко идут по заранее написанному списку вопросов. Хороший собеседующий держит единый флоу: от внешней разведки до действий внутри сети, и ветвит вопросы от того, что кандидат только что ответил.

Грейды различаются не набором фактов, а уровнем самостоятельности. Джуниор при затыке идёт за помощью к мидлу или сеньору, мидл сам выбирает инструменты и в консалтинге может вести проект в одиночку, а сеньор обычно лид команды и общается не только с заказчиком, но и с другими командами.

На собеседовании оценивают не столько правильный ответ, сколько рассуждение.

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

Каких-то заготовленных вопросов не бывает никогда. Если вы приходите на собеседование и у вас спрашивают явно заготовленные вопросы, вполне возможно, человек сам не очень хорошо разбирается в том, что спрашивает.

Иван Спиридонов

Разведка веб-приложения и забытые дев-окружения

Пентест веб-приложения начинается с внешнего периметра. Один домен на входе означает сбор активов: поддомены, айпишники, доступные веб-приложения, записи DNS, сертификаты, возможные сервисы и тестовые окружения. От домена двигаются к возможному вектору атаки.

Отдельное внимание дев-окружениям. За ними следят хуже: часто нет WAF, остаются аккаунты с дефолтными паролями, включены отладочные функции. Дев-стенд полезно сверить с продакшеном.

Дефолтные учётки из теста нередко уезжают и в прод, потому что их просто забыли поменять.

Уязвимость IDOR и перебор учётных записей

Разобравшись с архитектурой приложения, смотрят точки ввода и доступ к чужим объектам. Классическая уязвимость IDOR (небезопасная прямая ссылка на объект): в профиле виден идентификатор вроде ID=101, его меняют на 104, и если сервер не проверяет права, он отдаёт чужой заказ или чужие данные. Защита простая по идее: проверять по токену, есть ли у пользователя право на конкретный объект или страницу.

Чтобы играть с чужими данными, сначала нужно понять, какие учётки существуют. Подсказку даёт сам интерфейс: формы регистрации и восстановления пароля часто отвечают по-разному на существующий и несуществующий адрес. По этой разнице перебором собирают список настоящих учёток, а дальше пробуют подменять параметры уже для них.

XSS, CSRF и CORS: как защищают веб-приложение

XSS (межсайтовый скриптинг) бывает трёх основных видов. Хранимая: вредоносный скрипт попадает в поле ввода, например в комментарий, сервер сохраняет его в базе, и у каждого, кто открывает страницу, скрипт исполняется в браузере. Отражённая: жертва переходит по подготовленной ссылке, скрипт возвращается в ответе и срабатывает. DOM-based живёт целиком на стороне клиента. Максимум, что обычно вытягивают через XSS, это сессионные куки.

CSRF (подделка межсайтового запроса) заставляет браузер авторизованного пользователя тихо отправить запрос на приложение. Чтобы это сработало, нужны три условия: пользователь залогинен, приложение принимает запрос только по кукам без дополнительного подтверждения, и известна форма запроса. Защищаются CSRF-токеном: он зашит в форму, и без него приложение помечает запрос как подделку.

Если токена нет или он настроен криво, помогает атрибут куки SameSite. В режиме Strict куку не отдают даже при небольшом отличии домена, Lax отдаёт при обычных переходах, None требует включённого secure. Рядом стоят SOP и CORS. Политика одного источника не даёт скрипту одного origin читать содержимое с другого, где origin это связка схемы, домена и порта. CORS аккуратно разрешает такое взаимодействие нужным источникам.

Отсутствие твоего origin в CORS от CSRF не спасает: сам запрос всё равно уходит, просто ответ прочитать не получится.

SQL-инъекция и SSRF: путь во внутреннюю сеть

Точку SQL-инъекции находят по необычной реакции сервера на кавычку. Дальше определяют тип: union-based, error-based (когда в текст ошибки удаётся подмешать данные из базы), blind по булевой логике (сервер по-разному отвечает на истину и ложь) и blind по времени задержки, когда ничего другого не остаётся. Чтение базы это не потолок: в части случаев SQL-инъекция доводится до удалённого исполнения команд, и тогда атакующий работает уже не с базой, а с сервером.

SSRF (подделка запроса на стороне сервера) появляется там, где сервер по параметру сам ходит на переданный URL. Через неё обращаются к localhost и внутренним адресам, составляют карту внутренних сервисов, а в облаке дёргают служебный адрес метаданных 169.254.169.254, откуда иногда утекают ключи. Прямой localhost часто фильтруется, тогда в ход идут сокращения записи адреса и редиректы через подконтрольный домен. Если ответ не виден, SSRF подтверждают вслепую: по колбэку на свой сервер или по времени отклика.

Нередко SSRF или цепочка уязвимостей выводит на внутреннюю админку: Jenkins, GitLab, систему мониторинга. Там ищут то, ради чего всё затевалось: креды к репозиториям, переменные окружения, ssh-ключи. CI/CD интересен тем, что держит много чувствительных данных в одном месте.

Повышение привилегий в Windows: первые шаги после shell

Повышение привилегий в Windows начинается с того, чтобы понять, кто ты на машине. Если пробили веб-сервис, скорее всего это сервисная учётка, а не система. Первые шаги после получения оболочки:

1. 1

   Контекст: whoami, свои привилегии, в домене машина или нет.

2. 2

   Привилегии в токене. Самые интересные: SeImpersonatePrivilege, SeAssignPrimaryTokenPrivilege, SeDebugPrivilege, SeBackupPrivilege. По SeImpersonate поднимаются до системы через семейство Potato: PrintSpoofer, JuicyPotato, GodPotato, RoguePotato. SeBackup даёт доступ к бэкапам данных, SeDebug тоже входит в типовой набор для повышения. Если привилегии в токене нет изначально, сам себе её не добавишь.

3. 3

   Когда нужных привилегий нет, учётки для бокового движения ищут на самой машине: реестр и соответствующие ветки, конфиги и шары SMB, история PowerShell, файлы в каталогах пользователя и программ, планировщик задач. Даже без админских прав так часто находят пользовательские секреты.

4. 4

   Когда учётки нет совсем, по SMB вынуждают пользователя обратиться к подконтрольной точке и перехватывают NTLM-хэш, чтобы потом брутить его оффлайн или релеить.

Пентест Active Directory: Kerberoasting, AD CS и перемещение по сети

Когда машина в домене Active Directory, информацию собирают не только BloodHound. Многое достаётся обычными LDAP-запросами. В собранных данных смотрят ACL: интересны права вроде GenericAll, GenericWrite, WriteDACL, AddMember, ExtendedRight, по которым можно дотянуться до нужного объекта.

Kerberoasting: находишь SPN, запрашиваешь TGS, получаешь хэш и брутишь его оффлайн, после чего выдаёшь себя за сервис. Рядом стоит AS-REP Roasting на учётках без преаутентификации. Найденную учётку в открытом виде или хэше прокидывают по сервисам, пробуют password spraying (один пароль на много учёток, в отличие от брутфорса, где много паролей на одну), аккуратно, чтобы не залочить аккаунты.

Хэши NetNTLMv2 быстро не ломаются: они зависят от челленджа и секретов, это не plaintext. Поэтому их чаще релеят, а мешает релею подпись (signing) на SMB и LDAP. AD CS это ещё один путь наверх: ищут шаблоны сертификатов, а не сами сертификаты, и крутят мисконфиги вроде ESC1 инструментом Certipy. Проблема там не в сертификате, а в том, что при настройке остаются дыры, выданным сертификатам удостоверяющий центр доверяет полностью, и мониторинг такое пропускает. Для перемещения по сети с учёткой берут WinRM, а также выполнение команд по SMB через psexec и wmiexec из Impacket.

Без практики вы просто будете с теорией плавать. Не будет единого флоу, что вы смотрите и в какой момент. Контекст внутрянки это переход от одного актива к другому.

Иван Спиридонов

Пост-эксплуатация в Linux, Docker и ценность для бизнеса

На Linux после первого доступа собирают то же окружение: процессы, сетевые соединения, установленные утилиты, sudo-права, оболочку, задачи cron, ssh-ключи. Отдельно смотрят Docker, потому что оболочку часто получают не на хосте, а в контейнере, и оттуда нужно выбраться.

Docker-сокет это канал управления демоном на хостовой машине. Сам по себе он побег не гарантирует, но даёт много: разведку соседних контейнеров, порты, иногда креды, а при проброшенной интеграции с хостом и путь наружу. Через CI/CD эскалируют так: в Jenkins встраивают свой шаг в пайплайн, который запустится с его привилегиями. На раннере смотрят логи и то, что запускается, ищут токены: в них нередко целая цепочка доступов к репозиториям.

Пентестер не обязан непременно взять домен-админа: цель показать импакт.

Импакт в том, что настройка позволяет переместиться за границы прав, что действие не мониторится, что возможен путь к чувствительным данным. Для бизнеса вес имеют не технические трофеи, а недопустимые события: финансовые потери, простой сервисов, утечка персональных данных и связанные с ней риски по регуляторике.

Как стать пентестером и подготовиться к собеседованию

Чтобы подготовиться к собеседованию на пентестера, теорию стоит закрывать практикой. Поднимать свои стенды, чтобы понимать, как сервис устроен изнутри, проходить лаборатории и CTF, собирать единый флоу действий вместо разрозненных приёмов. Без практики даже знание того, как работает Kerberos, остаётся плавающим.

Когда что-то изучаете, никогда не используйте копипаст. Пишите своими словами, всё перефразируйте, прямо с клавиатуры. Можно хоть в тетрадке. Это будет в разы эффективнее.

Иван Спиридонов

Начинать лучше с одного направления, веба или инфраструктуры, и довести его до приемлемого уровня, прежде чем браться за второе.

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