Becoming a web security expert, или Как я готовился и сдавал OSWE
Привет, Хабр! Меня зовут @killinem, и я работаю ведущим экспертом отдела анализа защищенности компании Angara Security. В этом посте я хочу рассказать о своем опыте прохождение курса AWAE и сдачи экзамена OSWE от Offensive Security. Это, пожалуй, ведущая на текущий момент международная сертификация, подтверждающая навыки и знания в области практического анализа защищенности веб-приложений.
В этом посте я расскажу:
какие знания и скиллы нужны для сдачи экзамена,
как к нему готовился лично я,
о процессе прохождения самого экзамена,
является ли сертификат пунктом, после которого можно сказать «я знаю о веб-хакинге все».
В первую очередь стоит отметить, что OSWE нацелен на анализ защищенности веб-приложений методом «белого ящика» — для обнаружения уязвимостей будет доступен код уязвимого приложения. В курсе есть кейсы хакинга приложений и «черным ящиком», однако в процессе эксплуатации работа все равно сводится к анализу кода, доступ к которому вы получаете после эксплуатации одной или цепочки уязвимостей. Выбор языков приятно порадовал — в процессе подготовки и во время самого экзамена мне удалось поанализировать код на PHP, Java, Python (Django и другие фреймворки), C#, Node.js и, конечно, JavaScript! Без анализа кода на client-side в курсе тоже не обошлось (да и как можно создавать курс по веб-хакингу без багов клиент-сайда), хотя конечным итогом разбора каждого кейса и целью эксплуатации машин на экзамене являлся полноценный RCE на сервере. Еще я разобрался как декомпилировать и дебажить веб-приложения для некоторых ЯП (используя утилиты типа jd-gui, dnspy, visual studio code и другие). Однако я бы не сказал, что пентестеры, занимающиеся анализом веб-приложений только методами «blackbox» и «graybox» не справятся с экзаменом, наоборот — курс и экзамен помогут им вырасти в этом направлении, а также повысят и эффективность работ без доступа к коду. Парадокс? Ни в коем случае — понимание, какие ошибки совершают разработчики веб-приложений, как они мыслят и о каких аспектах безопасности могут не знать или забыть, открыло мне новый взгляд в моих последующих проектах.
Во-вторых, важно понимать, что для успешной сдачи экзамена понадобятся навыки программирования на любом скриптовом языке. Наиболее удобным и популярным является, безусловно, Python (его использовал и я), однако можно выбрать любой на выбор студента (bash, ruby, go, etc). Типовая задача: на экзамене запрещен sqlmap, и сплойтить SQL-инъекции нужно «руками», написав подходящий эксплойт — для этого мне пригодились библиотеки для работы с веб-приложениями, парсинга вывода, работы с файловой системой (ну и понимание типов и техник эксплуатации самих «скулей»). Для меня это не стало откровением — работая в практической IT-безопасности, нельзя совсем не уметь кодить. Писать комплексные приложухи с ООП и серьезной бизнес-логикой, естественно, не требовалось.
Третье. Удастся ли пройти курс и сдать экзамен без каких-либо знаний о пентесте, хакинге, практической безопасности или безопасности веба? Нет. OSWE не является entry-level экзаменом (каковым уже многие считают OSCP), OSWE не про «загуглить эксплойт для версии используемого ПО и запустить его», чему быстро могут научиться скрипткидди. Я уже несколько лет занимаюсь анализом защищенности веб-приложений на реальных проектах наших заказчиков, поддерживаю уровень практических навыков на различных площадках, отслеживаю исследования новых уязвимостей и мощные репорты на багбаунти-платформах, поэтому курс мне дался гораздо легче, чем человеку без постоянной практики: чем меньше у студента опыта в безопасности веба — тем сложнее будет справиться с курсом. С другой стороны — тем большему можно научиться в процессе его прохождения, если все-таки поставить себе большую цель:)
Четвертое. Можно ли считать себя гуру веб-безопасности после сдачи экзамена и думать, что уже все знаешь? Конечно, нет. Мир web security слишком широк для того, чтобы уместить его в размер 400-страничной методички. Исследуемые в курсе уязвимости в основном удается показать на примере одного приложения (а значит и для одного ЯП), в то время как специфика эксплуатации этого же бага в другом ЯП уже будет отличаться. Та же самая небезопасная десериализация в Java и PHP уже отличается и имеет интересные особенности, а с десериализацией в Python я и вовсе не сталкивался до курса. Некоторые более специфические баги типа HTTP Request Smuggling, Web Cache Poisoning или Prototype Pollution вообще не разбираются в курсе, поэтому после получения долгожданного сертификата нужно оставаться голодным до знаний и скиллов.
Прохождение курса
Курс состоит из 10 модулей, в 9 из них полностью прорабатывается цепочка, что называется, from Zero to Hero — от открытия главной страницы веб-приложения до получения полноценного интерактивного шелла на сервере. В методичке используются реальные приложения, для которых на эти уязвимости зарегистрированы CVE. При этом Offensive Security делают акцент на объяснении деталей и причин возникновения уязвимости (недостаточная валидация кода, особенности работы механизмов, используемых в веб-приложениях), хотя большинство пентестеров в данном случае ограничились бы использованием готового эксплойта из exploit-db.com. Например, как работает сериализация объектов и почему она может превратиться в RCE, в каком случае XML-парсеры веб-приложений уязвимы к XXE-атакам)), какие опасные фичи у некоторых ЯП (привет, PHP Type Juggling). Рассказывается, по каким паттернам можно обнаруживать подобные уязвимости в исходном коде веб-приложений пентестеру или application security-специалисту. Важное примечание: в курсе не используются (а на экзамене запрещены) статические сканеры кода (SAST), при использовании самого популярного DAST BurpSuite разрешена только версия Community Edition. Использование любых плагинов, позволяющих автоматизировать поиск уязвимостей, также запрещено, поэтому моими лучшими помощниками стали grep и отладчик (в курсе используется visual studio code и dnspy). Изучите все их возможности — они невероятно велики.
Особое внимание в курсе уделяется постэксплуатации обнаруженных уязвимостей. Специалисту по информационной безопасности нужно уметь объяснить бизнесу, чем же так опасна XSS на вашем сайте и к какому ущербу она может привести. Что ему с вашего alert(document.domain)? А ведь кейсов постэксплуатации XSS предостаточно:
кража cookies для угона аккаунта жертвы,
получение пароля жертвы в открытом виде (в случае использования механизма автосохранения паролей),
осуществление запросов к приложению с правами жертвы с помощью AJAX-запросов (включая при необходимости обход защиты от CSRF),
веб-скрапинг страниц веб-приложения и получение доступа ко всему контенту жертвы в нем,
подмена содержимого сайта с целью проведения фишинговых атак,
etc.
На этом список не заканчивается. В курсе подробно рассматриваются такие техники, как:
докрут SQL-инъекций до полноценного RCE,
обход механизмов защиты в функционале загрузки файлов (запрет исполнения кода в загружаемых директориях с помощью конфигурационных файлов (например, .htaccess) или блэклисты расширений для загружаемых файлов),
техники обхода аутентификации в функционале восстановления паролей или формирования сессионных токенов.
Особенно меня впечатлил кейс раскрута Insecure Deserialization в одном из популярных фреймворков. Для экплуатации таких уязвимостей ресерчерами подготовлены специализированные тулзы (самые известные — ysoserial для Java, ysoserial.net для .NET-приложений, phpggc для PHP), в которые периодические добавляются новые так называемые gadget chains. Однако как это работает под капотом понимает уже далеко не каждый. Оффенсивы подробно объясняют, что же такое эти самые gadget chains; как находить гаджеты, позволяющие в цепочке нанести импакт приложению до file read, file write или remote code execution; как эти гаджеты вызвать, отслеживая stack trace приложения через отладчик.
Не стоит забывать о багах бизнес-логики приложений — именно они являются зачастую наиболее сокрушающими и наносящими критичный импакт. Помочь обнаружить такие недостатки может только полное понимание функционала работы приложения, ну и отладчик;)
В процессе прохождения курса я сформировал несколько принципов, которые позволили мне получить от него максимальную пользу и быть более подготовленным к экзамену. Вот они:
После получения доступа к коду приложения я не набрасывался на готовое решение в методичке. Вместо этого начинал анализировать приложение самостоятельно, как будто столкнулся с ним на экзамене. В общем, соблюдал принцип «TRY HARDER»!
Как только я понимал примерный вектор уязвимости, то бросал методичку и докручивал багу самостоятельно. Мне казалось, чем более сложные условия поставишь себе в рамках обучения, тем легче потом дастся экзамен, а за ним и задачи на реальных проектах. И я оказался абсолютно прав.
Я понял, что не стоить пытаться моментально найти скулю, или грепнуть «eval» в погоне за легким RCE — лучше разобраться в логике приложения, его функционале. Тогда оно перестает быть огромным массивом непонятного кода, вместо этого становясь «инструкцией по эксплуатации».
Я старался вести максимально подробные записи о паттернах всех обнаруживаемых уязвимостей в CherryTree (или Evernote, Obsidian — на ваш вкус и цвет), и благодаря этому точно знал, куда копать, когда в коде приложения на Java натыкался на функцию readObject (), а на Python — render_template ().
Я терпеливо пилил готовый эксплойт «под ключ» под каждую уязвимость — это то, без чего экзамен точно не сдать. Даже в случае обнаружения всех уязвимостей для получения RCE, но без автоматизации их эксплуатации, результатом работ станет 0 баллов за машину. Приятным бонусом получите ощущение, как набивается рука в скриптинге:)
После прохождения методички студента меня поджидали 3 кастомных веб-приложения, которые нужно было проанализировать и проэксплуатировать самостоятельно (2 — белым ящиком, 1 — черным), это подготовка к экзамену «в бою». Мне они очень понравились, и я строго рекомендую их раскурить. При этом в дальнейшем оказалось, что они действительно достаточно близки к экзаменационным машинам.
Не стоит надеяться на курс как полный и достаточный объем данных для подготовки к экзамену. Я строго рекомендую отдаваться на 110% и изучить как можно больше материала, используя в том числе и сторонние ресурсы для подготовки. Делюсь своим must have-списком:
Portswigger Web Security Academy — бесценный ресурс, качество образовательных материалов от создателей BurpSuite впечатляет, к тому же «академия» постоянно обновляется.
Root-Me, разделы Веб-клиент и Веб-сервер — площадка для оттачивания практических навыков эксплуатации уязвимостей.
HackTheBox OSWE-like machines — подбор близких к задачам на экзамене «коробок» с топовой площадки по обучению хакингу.
NetSPI SQL injection wiki — энциклопедия техник обнаружения, эксплуатации и пост-эксплуатации скулей разных типов в наиболее распространенных БД.
Javascript for Pentesters — курс, после которого начинаешь чуть меньше плеваться при виде кода на Javascript:)
Hacktricks — «Большая Советская Энциклопедия» для пентестера (и там далеко не только веб).
PayloadAllTheThings — незаменимый помощник для формирования верного пэйлоада для эксплуатации любой уязвимости.
Экзамен
Уже достаточно давно экзамены в Offensive Security сдаются с проктором — сотрудником Оффенсивов, который следит, чтобы студенты не списывали сдавали экзамен честно: задания вместо студента не решают более скилловые коллеги, не применяются запрещенные утилиты и сканеры уязвимостей, не воруется код экзаменационных машин. С этим надо быть осторожнее: формально даже перетаскивание заинтересовавших кусков кода себе в CherryTree (чтобы не забыть и позже проанализировать глубже) подпадает под пункт несанкционированного копирования кода. При первоначальном подключении я предъявил government issued id (имя в нем обязательно должно совпадать с именем регистрации при покупке экзамена), и «Поехали!» (не забывая уведомлять проктора о перерывах и прибытии после них). Очень важный момент — бронирование времени экзамена, его нужно сделать как можно раньше. Я забронировал слот за полтора месяца до даты экзамена, т.к. записаться на удобное время очень трудно, особенно если экзамен попадет на выходные. Мой экзамен начинался в 5 утра, и это было большой ошибкой — вялость чувствовалась весь первый день экзамена. Несмотря на это, мне удалось найти все уязвимости за первый день.
Время экзамена — 48 часов + 24 часа на написание отчета, можно делать перерывы и уходить поспать, когда это захочется. Решение не спать все 48 часов экзамена будет огромной ошибкой, продуктивность будет на нуле. Не мучайте себя и обязательно выделите время на сон.
На экзамене нужно было справиться с двумя веб-приложениями и получить на них полноценный шелл. Доступа к исходному коду и самим целевым машинам не было, но были предоставлены почти полные их копии, на которых можно было исследовать код и тестировать эксплойт. Да, для сдачи экзамена нужно написать готовый эксплойт, автоматизировано эксплуатирующий веб-приложение до получения шелла. В одной из моих экзаменационных машин для формирования нужного пэйлоада использовался специфичный код одной из библиотек на Java, переписать это на Python было достаточно трудоемко. В итоге в моем эксплойте на Python был код, создающий файл с кодом на Java, компилирующий его и исполняющий для формирования нужного пэйлоада. Немного костыльно, но работало!
Баллы за экзамен распределяются следующим образом:
35 баллов — за обход аутентификации и получения административного (или пользовательского) доступа в приложение,
15 баллов — за получение RCE с правами аутентифицированного пользователя,
Для успешной сдачи экзамена нужно получить не менее 85 баллов.
После каждого этапа эксплуатации вы получаете доступ к текстовому файлику, подтверждающему успешность шага (его содержимое нужно сдать в борду экзамена). Не забудьте сделать скрины для отчета!
В первый день (с 5:00 до 0:00) мне удалось запилить «под ключ» первую машину (вместе с написанием и тестированием готового эксплойта) и обнаружить все уязвимости, позволяющие в цепочке получить RCE во второй машине, после чего я удалился на заслуженный 8-часовой сон. На второй день я написал готовый эксплойт для второго приложения и сконцентрировался на внимательном сборе всех скриншотов, нужных позднее для написания отчета. Вместе со сном получилось «закрыть» экзамен за 38 часов, хотя можно было быстрее (состояние было в первый день не самое лучшее).
Не стоит расслабляться после окончания экзамена. Я старался написать качественный и понятный отчет, чтобы технически подготовленный читатель отчета мог понять, как и где были обнаружены уязвимости, и повторить шаги для их эксплуатации. Непоследовательность в изложении или отсутствие логики в обнаружении бага может привести к 0 баллов за машину и провалу экзамена. Я читал немало историй и о том, как студенты забывали сделать скриншот с фиксацией получения доступа к флагу и получали «баранку».
Через 4 дня после отправки отчета был получен заветный аппрув:
Заключение
Курс был крутым, интересным и пройден на одном дыхании. Позволил глубже погрузиться в white-box pentest и научил мыслить немного как разработчик, подсказывая, где может крыться очередная critical уязвимость. Удалось подробно погрузиться в природу формирования gadget chains для небезопасной десериализации и формирования пэйлоадов для различных шаблонизаторов (SSTI~RCE), а почетное звание «самого противного ЯП» твердо перешло от Java к Node.js:)
Строго рекомендую прохождение OSWE каждому эксперту, специализирующему на пентесте веб-приложений или application security инженеру.
