Приветствую друзья!
17 месяцев блин, вот так вот... И не бросил) Как вы наверное заметили, я каждые 3 месяца публиковал маленький отчет по развитию в ИБ (офенсив часть). По понятным причинам, я не стал делать публикацию в мае, в связи с происходящими событиями. Подумал что нужно время и мне и вам, чтоб все уложилось и наступило принятие ситуации. Знаю, что на ресурсе есть ребята которые наблюдают за моим развитием, поэтому пишу сейчас)
И так поехали.
Что с поставленными изначально целями?
На работу я пока не устроился, но уже в процессе. Я с самого начала допустил ошибку с английским. Нужно было сразу за него садится, уча параллельно с пентестом, тогда бы я наверное уже устроился бы, или как минимум активно подавал заявки на собес. Я этот момент прое...л( Теперь приходится терять темп и учить. ) Из хорошего то, что мы таки переехали с семьей в Европу и на инглише тут говорят почти все, разве что старички не говорят. Поэтому возможностей практиковать значительно больше чем в Украине. Фильмы в кино тоже на английском, так что все неплохо, учусь)
Периодически перечитывая свои посты, я понял что была допущена еще одна грубейшая ошибка, а именно попытка развиваться в разных областях офенсив части. Мне нравится Веб и мобайл по части тестирования API, но так же я хочу уметь инфраструктуру. Моя политика развития как разностороннего пентестера была разбита в пух где-то в апреле. В чем собственно проблема?
Изначальной целью было трудоустройство. То есть элементарная попытка попасть в ИБ хоть в качестве кого-то. И если у вас сейчас такая же цель, то попробуйте услышать то, что я попытаюсь донести. Я потратил 1.5 года на развитие в нескольких направления придя к тому, что вроде знаниями оброс, но при любом раскладе умеешь мало в каждом из них) Нужно было развиваться в одном, устраиваться и уже в свободное время ковырять еще что-то. Таким образом стаж идет, опытом обрастаешь, знания подтягиваешь. И параллельно развиваешься еще в чем-то, чтобы со временем сменить профиль деятельности.
Идеальным вариантом в наступательной части является вебчик и мобайл (реверс или API тестинг). Устроится проще, вакансий больше. Соответственно вероятность попасть в ИБ выше. тобишь двигаться нужно было по пути наименьшего сопротивления... Я сглупил, признаю...
В общем в апреле месяце на ровне с английским я засел за вебчик и "О, Боги!", я вообще не понимаю что происходит) Пришло понимание, что со всеми пройденными курсами, лабами, записями и заучиваниями, я не могу ровным счетом не хрена(
В общем пройдя через легкую фазу фрустрации, я собрался с силами и принялся учить все по новой.
Пример того как это происходит сейчас:
1. При изучении той или иной уязвимости, я делаю заметки по ней так:
- Тип уязвимости (Клиент, Сервер, Сервис)
- Как уязвимость возникает?
- Влияние?
- Варианты ее эксплуатации?
- Как ее закрыть?
2. Теория
- Протоколы L7,L6
- Веб-сервера (основные и их настройка. Для почитать инфу про защиту веб-сервером)
- Методы
- Заголовки
- API и его архитектуры
- Архитектура веб приложений
Имея такой вот шаблон, получается неплохо добавлять информацию по уязам в достаточно комфортной структуре для чтения.
Следующая проблема которая возникла у меня, это отсутствие опыта работы с реальным приложением. Как оказалось это критический важный пункт в развитии. Я собирал (и продолжаю) списки лаб и старался все их проходить для усвоения знаний. Но все это разлетается в щепки, когда перед тобой боевая приложуха и чистый блек-бокс. То есть уже нет цели найти SSRF, так как лаба об этой уязвимости. Теперь нужно искать хоть что-то. В общем, главной шибкой было то, что я максимально оттягивал момент боевого опыта( Идеальный вариант для этого это ББ.) Вопрос не стоит в денежках, вопрос в реальном опыте. В общем я начал искать программы и бегать между ними не понимая что вообще мне делать. В какой-то момент было ощущение отчаяния и безнадежности... Немного помог мне @r0hack, только подтвердив мою догадку, что все решает ОПЫТ. Чем его больше, тем уверенней ты себя чувствуешь в бою. Поэтому я решил отбросить все лабы и изучение нового, и сосредоточится на практике с реальным приложением. Пока я плотно изучаю разведку.
Если вы решили связать себя с вебом, то я могу порекомендовать следующее:
1. Разведка: Nahamsec. Все что у него есть, все учите и смотрите. Вы точно научитесь из мало делать много. Изучите тулз amass, эта тулза умеет очень многое и будет экономить вам кучу времени.
Чем больше я углубляюсь в Recon, тем больше я понимаю насколько все взаимосвязанно и как сложно ребятам из Блю тима. Вариантов войти огромное кол-во.
2. Читайте отчеты из ББ программ. Я читаю эти! На опыте других, мы можем учится и узнать что выход на уязвимость может быть иногда на столько не очевидным, что многие просто пройдут мимо. Кстати, я понял, что тут работают даже самые безумные идеи. Так что главное смело пробовать.
3. Подписывайтесь на каналы сильных ребят (Даже инглишь). Читая материалы сильных ресерчеров, мы учимся быстро и главное правильно!
Немного историй из жизни!
Могу сказать, что вебчик я прям полюбил в момент, когда начал знакомится с уязвимостями бизнес логики. Именно эта уязвимость дала мне полную картинку как нужно тестировать, какими вопросами задаваться и глубоко погружаться в логику той или иной функции. И хоть эта уяза не занимает места в OWASP top 10 (2017-2021), голову даю на отсечение она есть везде. Чем сложнее приложение, чем оно больше, тем выше вероятность что разработчики не учли чего-то в логике.
ПРОСТОЙ ПРИМЕР
Допустим форма авторизации принимает только имя пользователя и его мыло. Отправив валидные данные, пользователю на мыло летит ссылка с токеном, перейдя по которой его редиректит в личку. Получается такая двухфакторка. Но если, к примеру разрабы не учли того факта, что вместо запроса с токеном, следующим прилетит запрос с конечной точкой на которую должно редиректить, можно просто обойти эту проверку и попасть в личку. Это конечно очень сырой пример и не факт что мы с таким столкнемся в жизни, но он хорошо демонстрирует уязвимость бизнес логики.
Когда я изучал этоту уязвимость, мне вспомнилась ситуация из жизни, где я с этой уязой сталкивался и эксплуатировал. Это было еще в далеком 2006 году, когда я устроился работать в шикарный ресторан в Киеве. Тогда только зарождалась тема отказа от бумажных чеков и стали применять терминалы, где официант вел стол гостя. Вбивал заказы, отправлял встречки (писульки с заказом на кухню и бар). В основном все использовали систему R-keeper, но сеть в которой я работал использовала свою разработку (не помню названия). В общем ближе к уязе)
У нас (стаф) было свое меню в этой системе и браслеты с денежкой. Логика такая:
Если я хочу есть, я вхожу в системе в меню персонала, выбираю что хочу и нажимаю кнопку отправить. В этот момент система просит меня поднести браслет и проверяет мой баланс (но не списывает). Если денег достаточно встречка едет на кухню. Бага была следующая. Если я хотел кушать, но денег не хватало, я вбивал кусок хлеба стоимостью 50 коп. и отправлял заказ. Система запрашивала баланс, я его подтверждал и на кухню летел заказ на кусочек хлеба. Но... Система не рассчитала меня оставив стол активным. И когда я добивал туда всякие блюда, проверка баланса уже не требовалась))) В общем так я питался (в долг) 4 месяца))) Потом меня спалили (удивляет почему так долго) и уволили, перед этим попросив рассказать как я это сделал. Понятно что за найденную багу мне не заплатили, а с ЗП вычли стоимость долга. Вот такой баг-хантинг в 2006 году)
Вторая уяза которую я изучал и тоже сталкивался в реальной жизни, это Race conditions или Состояние гонки. Скудно, но ознакомится можно
Ссылка скрыта от гостей
История случилась со мной в 2010 году, как раз когда на Украине уже затихала паника вызваная финансовым кризисом. В тот момент, достаточно большое кол-во людей пытались спасти сбережения от инфляции и уже по традиции денежки двигались в валюту. Но тогда вышел запрет на продажу валюты и все искали способы как наеб...ть судьбу. Кто-то впрыгивал на всю котлету в электронику, а кто-то открываал счета у разного рода сомнительных брокеров где-то на Кипре. Я был одним из тех, кто шел по второму сценарию. Так как переводы ограницены были только суммами в день, можно было открыть валютный счет у иностранного брокера и ежедневно ходить в банк и отправлять суточный максимум с конвертаций в валюту. У меня не было много денег, поэтому я справился за два похода. На счету были 2500 баксов. Все что оставалось, просто ждать пока паника уляжется и курс начнет замедлять свое ралли.
В общем обождав пару месяце, я решил изъять денежку, получив порядка 35% бумажной доходности. Я подал заявку на снятие в своем личном кабинете указав вебмани счет. Из-за отсутствия опыта, я обратил внимание что статус заявки не изменился и я повторно отправил заявку на снятие тех же 2500 уе. Вечером открыв кошелек я видел 5000 уе))) Я быстро вошел в ЛК и увидел -2500 уе на своем брокерском счете. Возвращать не стал, поблагодарил)
Теперь, немного изучив что такое race conditions, я понимаю что как раз там это и сработало. Приблизительно это было так:
Когда я отправил заявка1=2500 уе, она уходила на автомат с проверкой баланса. если сумма снятия <= остатка на счету, то одобрить и отправить в фин отдел. Я же сформировал заявка2 = 2500 уе, до того как прошла проверка заявка 1. Получилось что в момент проверки остатка на проверку пришли 2 одинаковые заявки отвечающие условии = True, и обе они были одобрены и отправлены в фин отдел. Фин отдел же (как мне кажется), не особо вдавался в проверку одобренных заявок и тупо пропускал все))) Но тут еще как я понимаю есть и ошибка бизнес-логики, так как система разрешила отрицательный баланс. Вообщем как бы там не было, рекомендую изучить эту уязвимость и научится искать условия для ее тестирования.
В общем могу однозначно сказать, что вебчик я полюбил и буду развиваться дальше. Устроившись на работу, я по чутку начну учить инфру. Постепенно двигаясь дальше к Ред-тиму. Может мне это и не удастся, но я как минимум попробую))
С Уважением!
Последнее редактирование модератором:
