Как найти в сайте дырку

Как багхантеры ищут уязвимости: лайфхаки и неочевидные нюансы

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

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

Дисклеймер

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

Статья будет интересна прежде всего багхантерам-новичкам. Начнем с XSS-уязвимостей: стандартные инструменты (взять хотя бы консоль браузера) помогут найти брешь немного нестандартным способом. С хранимыми XSS, когда полезная нагрузка выглядит не сложнее, чем '"><img src=x onerror=alert();>,все предельно понятно. В месте, где нет фильтрации, достаточно вставить этот JavaScript-код — и XSS сработает. Однако бывает так, что в результате действий пользователя полезная нагрузка может оказаться в теге <script>, заранее расположенном на странице. Такие XSS видно не сразу, поэтому приходится использовать payload типа '-alert()-' либо "-alert()-" (или другие, нужно смотреть по ситуации). Я детектирую подобные XSS-уязвимости с помощью стандартного веб-инспектора Safari, что сильно упрощает поиск.

Если вы вставили полезную нагрузку и веб-инспектор показывает ошибку JavaScript, значит, есть огромная вероятность найти XSS-уязвимость. Все просто: '"><img src=x onerror=alert();>, добавленный в существующий тег <script>, нарушает синтаксис языка своими кавычками, и JavaScript выдает ошибку.

Что касается SSRF-уязвимостей, которые позволяют отправлять запросы от имени сервера, то для их проверки я люблю использовать payload https://0/, который эквивалентен https://localhost или https://127.0.0.1. Максимально просто, но про этот способ исследователи безопасности почему-то всегда забывают. Еще больше таких же интересных полезных нагрузок можно найти здесь.

Самый нестандартный метод поиска логических уязвимостей предложил исследователь под ником @OldPassword. Ранее с этой техникой я не сталкивался, поэтому решил рассказать о ней в статье. Может быть, помните, как в одной популярной отечественной социальной сети была обнаружена уязвимость, позволяющая отмечать себя на фотографиях любых пользователей. До сих пор неизвестно, как она попала в сеть, но люди массово стали отмечаться на фотографиях знаменитостей. Брешь оперативно закрыли, и о проблеме быстро забыли. Пообщавшись с исследователем, который обнаружил эту уязвимость, я узнал, как именно он нашел небезопасную прямую ссылку на объект — IDOR. Багхантер не применял никаких инструментов вроде Burp Suite Professional, а воспользовался методом копирования кнопки. Он буквально скопировал кнопку «Отметить на фотографии» под той фотографией в соцсети, где такая кнопка была, и добавил ее под фотографию знаменитости, где, согласно логике работы приложения, ее быть не должно. Так у багхантера появилась возможность отмечать себя на фото: при нажатии кнопки вызывалась форма — все как положено.

Вот как выглядел код:

<a id="pv_tag_link" onclick="stManager.add(['phototag.js', 'phototag.css', 'tagger.css', 'tagger.js'], function() { Phototag.startTag(); })">Отметить человека</a>

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

Есть много способов обнаружения уязвимостей типа race condition (ошибка проектирования приложения, при которой его работа зависит от того, в каком порядке выполняются части кода). Как правило, их проверяют на одном из действий, например в функции вывода денежных средств. При запуске Intruder вместо одной выплаты оформляется две. Сейчас уже почти нет сервисов и приложений, где бы этот метод был рабочим. Результативен (пока!) похожий сценарий: имея положительный баланс веб-кошелька, можно одновременно совершить покупку и вывести средства. Race condition в этом случае может сработать несмотря на то, что в некоторых местах сайта уязвимость может быть исправлена ранее. Вы удивитесь, но обычный curl — излюбленный инструмент злоумышленников для проведения атак race condition, так как он самый быстрый и гибкий. Правильно заметил Исаак Дойчер, гениальность — в простоте.

curl 'https://lpeyixg5xj735njqsh1pk6p9q0wrkj88.oastify.com' -H 'User-Agent: cur1' -H 'Cookie: _fl_sessionid={session_id}' --data 'authenticity_token={authenticity_token}&user%5Bemail%5D={email_address_7}' & curl 'https://lpeyixg5xj735njqsh1pk6p9q0wrkj88.oastify.com' -H 'User-Agent: cur1' -H 'Cookie: _fl_sessionid={session_id}' --data 'authenticity_token={authenticity_token}&user%5Bemail%5D={email_address_8}' & curl 'https://lpeyixg5xj735njqsh1pk6p9q0wrkj88.oastify.com' -H 'User-Agent: cur1' -H 'Cookie: _fl_sessionid={session_id}' --data 'authenticity_token={authenticity_token}&user%5Bemail%5D={email_address_9}' & curl 'https://lpeyixg5xj735njqsh1pk6p9q0wrkj88.oastify.com' -H 'User-Agent: cur1' -H 'Cookie: _fl_sessionid={session_id}' --data 'authenticity_token={authenticity_token}&user%5Bemail%5D={email_address_10}'

Без практики — никуда!

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

Приоткрою завесу тайны и расскажу лишь про те уязвимости, которые можно найти на сайте прямо сейчас (в дальнейшем буду добавлять новые). Сайт представляет собой простейший блог на PHP, посвященный космосу. Веб-страницы верстались с помощью Bootstrap. На сайте есть вход через Telegram, личный кабинет пользователя и фотогалерея. Несмотря на более чем скромную функциональность, там уже заложено десять уязвимостей.

XSS в редиректе

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

Если изучить ссылку, можно найти простейшую XSS-уязвимость, которая выглядит примерно так:

Такие уязвимости периодически встречаются в скоупах программ bug bounty, поэтому их стоит приносить и репортить. Давайте разберемся, почему она работает.

На скриншоте видно, что редирект осуществляется с помощью JavaScript. При этом нет валидации параметра $_GET['url']. Полезная нагрузка вида javascript:alert();// не работает в хедере Location, поэтому в будущем я рекомендую использовать его. В нашем случае код написан именно так, как делать не надо. Таким образом, имеет смысл всегда листать страницу до конца, потому что проблема может скрываться в самом последнем предложении.

Утечка Telegram ID

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

Если внимательно изучить код этого блока (выделен на скриншоте синим), можно заметить в нем атрибут userid, из-за которого происходит утечка ID пользователей, вошедших на сайт через Telegram. На момент публикации статьи я исправил эту уязвимость, чтобы ID не утекали.

IDOR на удаление фотографий

Вот где пригодится userid (ниже представлен запрос на удаление фотографий): GET- параметр userid может быть произвольным, а значит, пользователь может удалять чужие фотографии из галереи.

SSRF-уязвимости

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

В самой функциональности есть SSRF-уязвимость. Она эксплуатируется максимально просто, хотя и в два этапа. Я это сделал для того, чтобы исследователи могли поэкспериментировать с ней и приобрести необходимый опыт. На практике встретить уязвимость, позволяющую читать локальные файлы, достаточно сложно. Обычно SSRF дает доступ к внутренним узлам, а схема file:/// остается недоступной.

После этого в галерее появляется непрогрузившаяся фотография, которая выглядит так:

И содержимое фотографии, то есть содержимое файла /etc/hosts:

Логические уязвимости

Может быть ситуация, когда вход на сайт осуществляется с помощью Telegram-аккаунта, у которого нет логина. Тогда пользователь сам должен ввести короткое имя своего аккаунта. И в этом случае возникает ошибка (exception), указывающая, что username не может быть равен null.

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

DoS-уязвимости

Если с помощью Intruder рассылать запросы слишком быстро, можно проверить веб-сайт, например фотогалерею, на устойчивость к DoS-атаке. Intruder — это один из инструментов Burp Suite Professional, с помощью которого пользователи могут быстро отправлять запросы, делать перебор различных параметров в запросе. Галерея будет грузиться бесконечно долго и, возможно, не загрузится вовсе. За обнаружение уязвимостей этого класса чаще всего платят минимальное вознаграждение. Но, думаю, если речь будет идти о целом разделе сайта, можно рассчитывать на достойную награду. Например, один из багхантеров получил за найденную DoS-уязвимость 1000 $.

Не стоит забывать, что запросы отправляются еще и на сторонние сайты. Этим могут воспользоваться злоумышленники, чтобы скрыть свои реальные IP-адреса.

Охота за багами начинается… сейчас

Чтобы стать крутым багхантером, жизненно важен опыт. Цель моей работы состояла в том, чтобы помочь максимально просто и быстро получить опыт по поиску багов. На практике я рассмотрел самые популярные уязвимости. Тестовый стенд уже доступен. Более того, я дополнил его уязвимостями, не описанными в статье. Если хотите попрактиковаться, предлагаю начать прямо сейчас! Найденные уязвимости можете смело репортить в комментариях 🙂

Автор: yurasikkkkk

Советуем подписаться на его канал, посвященный багхантингу.

В своих прошлых статьях я нередко упоминал об различного рода уявимостях на сайтах. Это “Уязвимость в AdsManager на практике” и “Пример уязвимости в JCE”, а также более обобщенно в других материалах. Для тех, кто не знает чем бекдор отличается от XSS я посвящу уже следующую статью “Описание распространненых уязвимостей”.

Здесь я уделю внимание поиску дыр на сайте, а также некоторым советам, как их залатать от дальнейшего проникновения вирусов.

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

Как найти уязвимость по логам?

Допустим,что вирус уже проник на сайт. Мы успешно (наверно) удалили все вирусы с сайта и задумались над защитой от дальнейшего вторжения. Здесь могут помочь мои советы из статьи “Как защитить сайт от попадания вирусов”. Многие владельцы веб-страниц хотят знать, как вирус попал на сайт и как предотвратить заражение в дальнейшем. В таком случае требуется более детальный анализ появления вирусов на сайте. И я расскажу простой метод  поиска уязвимости, который поможет даже начинающему веб-мастеру.

Итак, для начала нам надо найти логи сервера. По умолчанию они находятся в отдельной папке logs выше директории сайта. Чаще всего имеют имена файлов access_log и error_log. Что делать, если не смогли найти их?

– Вариант первый, они у вас могут быть не включены в настройках сервера, поэтому стоит включить генерацию отчетов.

– Вариант второй, запросить логи у техподдержки, они подскажут, как вам поступить дальше.

Ищем шеллы на сайте!

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

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

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

Проникновение вирусов через POST запросы

Наверное главным недостатком логов будет проблемность обнаружить данные, передаваемые через POST. Многие вирусы стали достаточно хитрыми и маскируются под модули и плагины системы управления сайтом. Как результат, в логах обычные обращение к страницам, будь то главная или внутренние ссылки. В таких случаях необходимо устанавливать на сервер дополнительные модули захвата пост-данных, либо переключать логирование в уровни trace. При этом будьте готовы, что файлы логов станут занимать ну очень много места! При таком анализе и дешифровке кода можно восстановить полную ситуацию взлома на сайте. Однако многие хостинги с неохотой идут на уступки в выдаче необхрдимых логов. Поэтому этот вариант больше подходит для выделенных серверов.

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

Поиск уязвимостей аудитом безопасности

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

Тут два пути поиска потенциальных дыр на сайте. Первый из них анализ файлов и кода, а также компонентов и модулей. В первую очередь стоит проверять проверки загрузки файлов на сайт, а также фильтрацию всех входных данных. Это очень трудоемкое занятие, и явно не подходит рядовому пользователю. Тут могут справиться только настоящие асы.

Второй вариант подразумевает отсутствие доступов к сайту, и мы будем пытаться всеми методами взломать сайт. Тут можно воспользоваться сканерами уязвимостей. В итоге если мы обнаружим потенциальное место для взлома, тогда сможем задуматься об устранении дыры в сайте.

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

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