Приступаем к работе

Замечание: эта глава никогда не будет 1,2,3 пошаговым руководством по хакингу. Вместо этого, она предоставит основное руководство, основаное на моём опыте, достижение цели нахождения уязвимостей. Информация здесь основана на моём опыте и интервью, которые я брал у некоторых крутых хакеров. Я настоятельно рекомендую вам использовать эту главу вместе с руководством от OWASP и книгой Web Application Hacker’s Handbook

OWASP Testing Guide

Учитывая всё вышесказанное, когда вы новичок и только начинаете, я не рекомендую вам нацеливаться на сайты, такие как Uber, Twitter, GitHub, и т.д. До тех пор, пока вы найдёте уязвимость, которую никто ещё не нашёл, вы потратите много времени на ничего и это очень расстраивает.

Мой непрошгенный совет: когда начинаете, попробуйте найти маленькие программы, где вы будете иметь огромные шансы на успех. Это может быть программа, которая не выплачивает вознаграждения, новая программа или старая программа среднего размера, которая только что выпустила новые функциональные возможности. Также, если вы хотите работать в рамках уже устоявшейся программы, мыслите нестандартно и пройдитесь по тем участкам, по которым другие не проходили. Это то, что работает для меня на HackerOne и Twitter.

https://www.owasp.org/index.php/OWASP_Testing_Project

Сеть, Поддомен и сбор ключевой информации

Взлом является чем-то большим, чем просто взаимодействие с сайтом - вы можете тестировать API, мобильные приложения, права доступа к фалам и сетевую инфраструктуру компании. Когда вы начинаете работать с новой целью, всегда полезно собрать информацию. И OWASP и Web Application Hacker’s Handbook рекомендуют начинать с этапа разведки.

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

Отличное место с чего можно начать - нацеливание на сеть компании. Для маленьких сайтов, это может быть только 1 сервер с 1 IP адресом, но скорее всего, могут существовать поддомены, дополнительные IP адреса, стейджинговые сервера, и так далее.

Отличный способ отобразить всё это - использовать инстру-

менты типа Nmap, Recong-ng, KnockPy и Whois.Arin.

Nmap

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

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

Если вам повезёт, вы можете найти сервера публично доступные сервера Continuous Integration со стандартными паролями или устаревшим ПО.

Recon-ng

Recon-ng набор инструментов, который сделает вашу жизнь проще при взломе. Опять же, обьяснение всего функционала Recon-ng находится за рамками этой книги, но проводя этап разведки, вы можете использовать Recon-ng для поиска в Google, Bing, Baidu, и других поисковиках поддоменов вашей цели.

Это отличный способ расширения вашей цели и нахождения новых участков для атаки. Джейсон Хэддикс с BugCrowd имеет отличный инструмент, который делает это намного проще: https://github.com/jhaddix/domain

Его инструмент будет искать поддомены используя Reconng, проводя поиск в Google, Bing, Baidu, Yahoo, и т.д. Когда вы только начинаете, я рекомендую использовать его, чтобы сделать вашу жизнь проще, но в конце концов стоит изучить, как использовать Recon-ng самостоятельно.

KnockPy

KnockPy умеет не так уж много. Опять же, используя словарь, KnockPy быстро идентифицировать существующие поддомены, которые вы можете проверить лично. У меня есть видео-руководство, которое доступно на моём Youtube-канале https://youtube.com/yaworsk1

TODO: ADD: - Whois.Arin, Open Ports - Dirbuster, fuzzing files, etc

Просмотр и понимание приложения

После того как вы составили карту сетевого уровня, определили ПО используемое на открытых портах и получили список поддоменов, пришло время посмотреть сайты. Лучший способ сделать это - через прокси-сервер, такой как Burp, который будет запоминать все пути, которые вы посетили и поможет составить карту сайта.

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

Обычно я начинаю с логики веб-приложения, так что мы начнём с этого в качестве примера.

Когда я тестирую новый сайт, первое с чем я взаимодействую - это логика, так что я обычно тестирую: - Силу пароля и лимит попыток: Обеспечивает ли сайт надежный пароль и имею ли я бесконечные попытки на ввод пароля, если я знаю имя пользователя? - Безопасные и HTTP only куки: Безопасны ли куки, идентифицирующие пользователя, отправляются ли они токо через HTTPS? Являются они читабельными через Javascript? - Восстановление пароля: Насколько сильны токены восстановления пароля? Можно ли их использовать повторно? - Реализация двухфакторной авторизации: Сколько попыток мне нужно предпринять, чтобы угадать токен? Насколько длинный этот токен? Могу ли я узнать этот токен любым способом?

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

позволял только 3 попытки, чтобы угадать токен. Как всегда, если вы повторно отправите себе токен, количество попыток обнулится без изменения токена. В результате, у меня было бесконечное число попыток, чтобы угадать 2FA токен, так что если бы я знал пароль жертвы, я мог бы обойти 2FA, дважды предположив токен, потом отправить его заново и снова сделать две попытки угадать, и так до бесконечности.

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

•Вставку XSS кода, чтобы увидеть отображаются ли двойные кавычки или угловые скобки

•Тестирование HTML5 атрибутов, таких как onload, onerror, и т.д. в элементах, таких как тег img

•Поиск CSRF токенов и их тестирование - можете ли вы удалить содержимое, это делается через GET или POST запррос? Если GET, то может не быть CSRF защиты.

•Передается ли идентификатор аккаунта как параметр в POST-запросе? Можете ли вы изменить это, чтобы получить доступ к другому профилю?

•Берёт ли сайт URL параметр для загрузки ресурса, например, www.victim.com?id=4 - можно ли изменить 4 и загрузить файл, такой как ../../etc/passwd?

Список безграничен и возможности огромны.