Введение
Здравствуйте, уважаемые читатели. Сегодня на повестке дня у нас небольшое тестирование —
первых ≈100 тысяч по популярности сайтов в интернете (ранжирование на основе статистики посещаемости с Alexa Rank). Стоит отметить, что оное тестирование будет достаточно узконаправленным, а именно — проверим каждый сайт на предмет существования и открытости Git-репозитория без аутентификации прямо из веба по url-адресу искомого. Напомню, что такая брешь в безопасности зачастую позволяет прочитать актуальные исходные коды на сервере, получить чувствительную информацию (файлы конфигов, структуру системы и т.д.) и, в последствии, получить определенного рода права на сервере. Рай для различного рода негодяев, да и только :)
Совершенно аналогичную проверку я делал для себя порядка 100 дней назад, и сегодня мы сделаем это ещё раз, посмотрим что изменилось и что с этим делать.
Разумеется, использовать будем список сайтов, полученный в рамках первого тестирования.
Для заинтересовавшихся милости прошу под кат.
*Вся информация, описанная в статье, предоставлена исключительно с исследовательско-ознакомительной целью.
Что происходит?
Итак, для начала нужно понимать, что кол-во сайтов не самое маленькое, и проверку вручную, разумеется, сделать невозможно. Решение — напишем автоматизированную утилиту для проверки.
Вообще говоря, на практике достаточное условие проверки очень простое:
Будем считать, что Git-репозиторий является открытым и доступным из веба без авторизации, если доступен на чтение файл конфигов по адресу http(s)://sitename.com/.git/config (забавно, что иногда в этом файле также содержатся данные для подключения к git-серверу, но нам это совершенно не обязательно).
Тут основной момент в том, что многие разработчики закрывают доступ на просмотр директории /.git/, но забывают закрыть доступ на сами файлы/директории внутри оной. Таким образом, если нам удалось прочитать конфиг — то практически всегда мы сможем прочитать и файл /.git/index (список, содержащий все файлы), и, собственно, сможем прочитать и все доступные исходники (из директории /.git/objects/, преобразовав blob-объекты в исходное представление файлов). Для этого можно использовать любой git-дампер (например этот), или написать свой.
Тесты и анализ
Оперируя этой информацией, и написав утилиту (основной код можно глянуть тут) для проверки на вышеописанный предмет, получаем следующее:
Тестирование #1
Дата: 11 декабря 2016 года
Кол-во тестируемых сайтов: 99991
Открытых Git-репозиториев: 639 (0,0064% от общего числа)Тестирование #2
Дата: 21 марта 2017 года
Кол-во тестируемых сайтов: 99991 (тот же лист сайтов, что и в первый раз)
Открытых Git-репозиториев: 599 (0,0060% от общего числа)
Примечательно, что время работы утилиты на домашнем ноутбуке (при скорости интернет-соединения в 20 мбит/с) составило около 10-ти минут, что совсем не много.
Итак, за 100 дней кол-во «открытых» репозиториев (из моей выборки) сократилось на 40 штук. Это порядка 6% от изначального количества.
Много ли разработчиков одумалось? Нет, не похоже (такими темпами только через года 4-5 можно ожидать исправления проблем на данной выборке).
В целом, конечно, процент открытых репозиториев небольшой. Но с другой стороны, взяв выборку скажем в один миллион сайтов — это уже порядка 10 000 сайтов с подобной брешью.
При том нужно понимать, что это самые популярные сайты по версии Alexa Rank, а значит они обязаны быть защищенными. Предположительно, чем дальше по списку — тем чаще будут попадаться открытые репозитории.
Среди найденных сайтов были обнаружены сайты с весьма большой аудиторией (> 1кк уникальных/сутки), а также ресурсы различных учебных заведений и организаций.
Вариант вектора атаки
Чтобы читатели лучше понимали опасность данной оплошности разработчиков, накину один из возможных сценариев по взлому сервера:
- Найден открытый Git-репозиторий
- Получен доступ к исходным кодам сайта путем дампа гита
- Среди исходников найдены файлы с именами вроде config.php / database.php
- В файлах найдена чувствительная информация. А именно — данные для подключения к базе данных сайта (допустим, СУБД MySQL)
- На сайте также обнаружена phpMyAdmin — подключились к БД, используя данные из пунктов выше
- Нашли пару логин-пароль от админки (вероятно, предварительно расшифровав хеш пароля)
- Через админку исполнили вредоносный код на сервере / залили шелл / etc
- Как результат — что угодно. Зависит от целей и возможностей которые предоставились
И это ещё не самый простой сценарий, требующий определенного стечения обстоятельств.
Весьма печально, но зачастую разработчики любители держать бекапы БД прямо в репозитории. Тогда остается только скачать его и, выяснив чувствительную информацию, применить её против сервера.
Также, изучив исходники, можно найти другие уязвимости (например, sql injection) или пути до исполняемых файлов, позволяющих администрировать ресурс. Либо просто «слить» все доступные исходники. Вариантов масса.
Самое интересное, что практически весь процесс (от добычи url'ов сайтов до получения исходников) можно автоматизировать. Более того, подобные решения уже существуют, и злоумышленники успешно монетизируют ваши ресурсы.
Списки проверяемых сайтов и файлы результатов я, разумеется, не привожу. При желании вы сможете взять ТОПы сайтов, и протестировать их самостоятельно.
Как защититься?
Резюмируя, отмечу основные этапы для приватности вашего git-репозитория:
- Полностью закрывайте доступ на директорию репозитория из веба (если уж он туда смотрит), в т.ч. на чтение файлов и субдиректорий (как это сделать — зависит от веб-сервера). Убедитесь, что нельзя прочитать такие файлы /.git/config, /.git/index и остальные (даже без этих файлов, имея доступ к папке /.git/objects/ можно слить исходники путем перебора адресов — поэтому закрывайте абсолютно все от чужих хитрых глаз и рук).
- С помощью, например, .gitignore настройте игнорирование файлов с чувствительной информацией (бэкапы, конфиги и остальное) из репозитория — они там совершенно не нужны, и предоставляют собой серьезную угрозу безопасности. При выполнении данного пункта, даже если злоумышленник проникнет в ваш репозиторий, он ничего существенного сделать не сможет (за исключением того что
увидит ваш bad-style программированиясможет увести ваши исходники).
Соблюдая эти правила, вы сможете избежать вышеописанных ситуаций. Но вам также не стоит забывать о других типах атак на веб-приложения (и не только) — но в рамках данной статьи мы говорить о них не будем, т.к. с репозиториями они не связаны.
С вами был Петр,
спасибо за внимание.
Автор: ParadoxFilm
