Раскрытие информации о PHP на Yahoo
Сложность: Средняя
Url: http://nc10.n9323.mail.ne1.yahoo.com/phpinfo.php
Ссылка на отчет: https://blog.it-securityguard.com/bugbountyyahoo-phpinfo-php-disclosure-2/23
Дата отчета: 16 октября 2014
Выплаченное вознаграждение: n/a
Описание: Хотя этот отчет не может похвастать большой выплатой, как некоторые другие уязвимости, я включил его (за него на самом деле заплатили $0, что удивительно!), и это один из моих любимых отчетов, поскольку он помог мне осознать важность сканирования сети и автоматизации.
В октябре 2014 Патрик Ференбах (которого вы должны помнить по интервью Hacking Pro Tips #2 отличный парень!) обнаружил сервер Yahoo с доступным файлом phpinfo(). Если вы не знакомы с phpinfo(), это чувствительная к безопасности команда, которая никогда не должна быть доступна в продакшене, поскольку, будучи доступной в публичном доступе, она раскрывает огромное количество информации о сервере.
Сейчас вы можете удивиться как Патрик нашел http://nc10.n9323.mail.ne1.yaho я удивился. Оказалось, что он пинговал yahoo.com, который вернул 98.138.253.109. Затем он передал этот адрес в WHOIS, и обнаружил, что Yahoo владеет следующим:
NetRange: 98.136.0.0 98.139.255.255 CIDR: 98.136.0.0/14 OriginAS: NetName: A-YAHOO-US9 NetHandle: NET-98-136-0-0-1 Parent: NET-98-0-0-0-0 NetType: Direct Allocation RegDate: 2007-12-07 Updated: 2012-03-02Ref: http://whois.arin.net/rest/net/NET-98-136-0-0-1
Обратите внимание на первую строку Yahoo владеет массивным диапазоном ip-адресов, от 98.136.0.0 до 98.139.255.255, или 98.136.0.0/14, что является 260,000 уникальных IP-адресов. Это множество потенциальных целей.
Далее Патрик написал простой bash-скрипт, который искал доступный файл phpinfo:
#!/bin/bash
for ipa in 98.13{6..9}.{0..255}.{0..255}; do
wget -t 1 -T 5 http://${ipa}/phpinfo.php; done &
Запустив его, он нашел этот случайный сервер Yahoo.
[ad name=»Responbl»]
Выводы
При поиске уязвимостей учитывайте всю инфраструктуру компании, если они не говорят вам, что она вне зоны поиска уязвимостей. Хотя этот отчет не принес вознаграждения, я знаю, что Патрик применил подобный подход, чтобы получить значительные четырехзначные выплаты.
Кроме того, вы заметите, что было 260,000 потенциальных целей, которые просто невозможно было бы просканировать вручную. При выполнении подобного тестирования автоматизация чрезвычайно важна и обязательно должна использоваться.
9. Голосование за Hacktivity на HackerOne
Сложность: Средняя
Url: https://hackerone.com/hacktivity
Ссылка на отчет: https://hackereone.com/reports/13750324
Дата отчета: 10 мая 2016
Выплаченное вознаграждение: Вещи с симоликой компании
Описание:
Хотя технически это не уязвимость в безопасности, этот отчет является отличным примером нестандартного мышления.
Примерно в конце апреля/начале мая 2016 HackerOne разработали для хакеров функциональность, позволяющую голосовать за отчеты через их ленту Hacktivity. Был простой способ и сложный способ узнать о доступности функциональности.
Простой способ, GET-запрос к /current_user, будучи залогиненным, возвращал hacktivity_voting_enabled: false. Сложный способ немного интереснее, он и содержал уязвимость, и именно из-за него я включаю этот отчет в книгу.
Если вы посетите hacktivity и просмотрите код страницы, вы заметите, что он довольно немногословен, всего несколько div и нет реального контента.
HackerOne Hacktivity Page Source
Теперь, если вы не знакомы с их платформой и у вас не установлен плагин вроде wappalyzer, простой взгляд на исходный код страницы должен сказать вам, что содержимое рендерится через javascript.
Помня об этом, если вы откроете инструменты разработчика в Chrome или Firefox, вы сможете увидеть исходный код javascript (в Chrome нужно перейти в sources, затем слева, top->hackerone.com->assets->frontend-XXX.js). Инструменты разработчика Chrome идут в комплекте с удобной кнопкой {}, которая позволяет сделать минифицированный код javascript читабельным. Вы также можете использовать Burp и посмотреть ответ, возвращающий этот файл Javascript.
И здесь причина включения этого отчета в книгу, если вы поищете по Javascript на предмет POST, вы найдете кучу путей, используемых HackerOne, которые могут быть не совсем очевидны, в зависимости от ваших прав доступа и того, что отображается вам в качестве контентыа. Вот один из них:
Hackerone Application Javascript POST Voting
Как видите, у нас есть два пути для функциональности голосования. На момент написания этого отчета, вы можете совершать по ним запросы и голосовать за отчеты.
Это один из способов найти функциональности в отчете хакер использовал другой способ, перехватывая ответы от HackerOne (вероятно, используя инструмент вроде Burp), и меняя значения возвращаемых значений с false на true. Это действие показывало элементы, позволяющие голосовать по клику, осуществляя тем самым POST и DELETE запросы.
Причина, по которой я провел вас по Javascript, в том, что взаимодействие с JSON-ответами не всегда может обнаружить новые HTML-элементы. В результате, навигация по Javascipt может раскрыть “скрытые” в другом случае точки взаимодействия.
[ad name=»Responbl»]
Выводы
Исходный код Javascript приходит вам с непосредственным исходным кодом от цели, которую вы можете исследовать. Это здорово, потому что ваше тестирование происходит переходит из черной коробки, где вы не имеете представления о том, что происходит на бэкенде, в белую (хотя и не совсем), где вы можете просмотреть, как выполняется код. Это не значит, что вы должны читать каждую строку, POSt-запрос в этом случае был обнаружен на строке 20570 простым поиском по запросу POST
Итоги
Уязвимости, основанные на аутентификации, не обязательно подразумевают внедрение кода. Вместо этого, их использование зачастую требует внимательных глаз и еще больше нестандартного мышления. Всегда обращайте внимание на другие инструменты и сервисы, которые могут быть использованы сайтами, поскольку они могут оказаться новым векто
ром атаки. Это может включать Javascript-библиотеку, которую сайт использует для отображения контента.
Скорее чаще, чем реже, обнаружение таких уязвимостей потребует использования прокси-перехватчика, который позволит вам поэкспериментировать со значениями, прежде чем отправлять их исследуемому сайту. Попробуйте изменять любые значения, которые кажутся вам относящимися к идентификации вашего аккаунта. Возможно, вам потребуется два разных аккаунта, чтобы иметь два набора валидных данных для доступа, которые точно будут работоспособными. Так же ищите скрытые/необычные точки, которые могут обнаружить функциональность, которая не должна быть доступна по тем или иным причинам.
Кроме того, каждый раз при совершении какого-либо вида транзакции помните, что всегда существует вероятность, что разработчики не приняли во внимание race conditions на уровне базы данных. Таким образом, их код может помешать вам, но если вы сможете выполнить код так быстро, как это возможно, словно он выполняется почти одновременно, вы можете наткнуться на race condition. Убедитесь, что вы провели несколько тестов при поиске этой уязвимости, поскольку она может быть обнаружена далеко не с первого раза, как в случае с Starbucks.
И, наконец, не пропускайте выход новой функциональности — она часто предоставляет новые области для тестирования! И если/когда возможно, автоматизируйте тестирование, чтобы использовать свое время с большей пользой.
