Admin
Администратор
Поиск утечек в Shodan
В один прекрасный день среди потока статей, ссылки на которые появляются в моем твиттере, я поделился статьей Avinash'а об утечках данных. Параллельно я как раз работал над тем, чтобы укрепить периметр своих ресурсов, и эта статья была как никогда кстати. Результат моей работы вылился в то, что вы читаете сейчас.Читая оригинальную статью от Avinash, я обратил внимание на дорки, которые опубликовал автор - среди них были запросы в Shodan для поиска машин с Jenkins и SonarQube. Если работа с дорками не составляет для меня особого труда, то с этими системами я столкнулся впервые, и это меня очень сильно заинтересовало. Я начал с ручного поиска в Shodan и получил в ответе от сервиса более 5000 результатов для Jenkins и еще около 2000 для SonarQube. Проверив пару штук вручную, я приступил к тому, что делаю лучше всего - автоматизация! Пусть машины делают то, что у них получается лучше всего : P)
В итоге я получил 5000 URL-адресов, на каждый из которых можно было свободно зайти, увидеть панель управления Jenkins и проверить ее на предмет наличия утечек. Так как я не знал, где и какая утечка может быть, я проверил вручную несколько URL-адресов, чтобы понять примерно то, что мне нужно искать. Но никаких особых признаков я не обнаружил, которые можно было бы легко детектировать при проверке ссылок скриптом. Единственное, что я мог сделать - продолжить поиски, заходя на страницы и искать какую - либо интересную информацию, вроде имен или чего - нибудь еще.
Вот следующий этап автоматизации, «заскриншоть их все». У меня уже был подобный опыт, когда я использовал chrome_shots для скриншота большого количества страниц. Теперь, имея на руках ~ 2000 скриншотов, я, очевидно, начал просматривать их - один за другим.
В конце концов я наткнулся на экземпляр, который собирал билды для компании, которую я не имею права называть (в дальнейшем будем называть ее «redacted.com»). С надеждой я начал штудировать журналы консоли. Хотя Jenkins и скрывает большинство секретных данных звездочками, всегда есть надежда найти какие - нибудь баги. В результате я обнаружил accessToken и данные для входа от root-пользователя:
Проверив их на валидность и убедившись в наличие соответствующих прав доступа, я попытался получить список каналов и пользователей из каталога Slack и у меня это получилось. Всего было около 1000 каналов и 200 сотрудников. После этого я собрал список их конференций и выгрузил часть переписок с использование Slack API (в том числе сообщения из той, что упоминается на скриншоте выше - mstats_dev_alerts). Собрав все данные воедино, я понял, что о них лучше сообщить их владельцам.
Тем временем я начал оценивать глубину своего подвига. Как вы можете видеть из скриншота выше, там могло было быть довольно много «интересных» каналов с конфиденциальной информацией. Я вытащил оттуда парочку сообщений, содержащих данные от aws, отправленные ботом пользователю. Люди даже делились «паролем Wi-Fi» на «общем» канале! Это было действительно глупо.
Используя найденные учетные данные, я мог собрать информацию об их амазоновских корзинах и даже читать / записывать в них любые данные, при этом, в некоторые из них была записана кодовая база клиентского приложения.
Вывод
- Автоматизируйте все, что можете - пусть машины восстанут (только в мирных целях)! Помимо того, что я автоматически создавал скриншоты, я также автоматически проверял Jenkins на наличие RCE (т.е. искал экземпляры Jenkins с открытой Script Console, и их было довольно много)
- Не думайте, что ничего нельзя найти: да, Jenkins заменяет секреты звездочками, но он не может замаскировать вывод работающего инструмента, и, как в этом случае, пропустить критические данные.
- Ни для кого не секрет: ошибки просты, но именно настойчивость является ключом к победе.
