- PVSM.RU - https://www.pvsm.ru -
Здравствуйте, уважаемые читатели. Сегодня на повестке дня у нас небольшое тестирование —
первых ≈100 тысяч по популярности сайтов в интернете (ранжирование на основе статистики посещаемости с Alexa Rank [1]). Стоит отметить, что оное тестирование будет достаточно узконаправленным, а именно — проверим каждый сайт на предмет существования и открытости Git-репозитория без аутентификации прямо из веба по url-адресу искомого. Напомню, что такая брешь в безопасности зачастую позволяет прочитать актуальные исходные коды на сервере, получить чувствительную информацию (файлы конфигов, структуру системы и т.д.) и, в последствии, получить определенного рода права на сервере. Рай для различного рода негодяев, да и только :)
Совершенно аналогичную проверку я делал для себя порядка 100 дней назад, и сегодня мы сделаем это ещё раз, посмотрим что изменилось и что с этим делать.
Разумеется, использовать будем список сайтов, полученный в рамках первого тестирования.
Для заинтересовавшихся милости прошу под кат.
*Вся информация, описанная в статье, предоставлена исключительно с исследовательско-ознакомительной целью.
Итак, для начала нужно понимать, что кол-во сайтов не самое маленькое, и проверку вручную, разумеется, сделать невозможно. Решение — напишем автоматизированную утилиту для проверки.
Вообще говоря, на практике достаточное условие проверки очень простое:
Будем считать, что Git-репозиторий является открытым и доступным из веба без авторизации, если доступен на чтение файл конфигов по адресу http(s)://sitename.com/.git/config (забавно, что иногда в этом файле также содержатся данные для подключения к git-серверу, но нам это совершенно не обязательно).
Тут основной момент в том, что многие разработчики закрывают доступ на просмотр директории /.git/, но забывают закрыть доступ на сами файлы/директории внутри оной. Таким образом, если нам удалось прочитать конфиг — то практически всегда мы сможем прочитать и файл /.git/index (список, содержащий все файлы), и, собственно, сможем прочитать и все доступные исходники (из директории /.git/objects/, преобразовав blob-объекты [2] в исходное представление файлов). Для этого можно использовать любой git-дампер (например этот [3]), или написать свой.
Оперируя этой информацией, и написав утилиту (основной код можно глянуть тут [4]) для проверки на вышеописанный предмет, получаем следующее:
Тестирование #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кк уникальных/сутки), а также ресурсы различных учебных заведений и организаций.
Чтобы читатели лучше понимали опасность данной оплошности разработчиков, накину один из возможных сценариев по взлому сервера:
И это ещё не самый простой сценарий, требующий определенного стечения обстоятельств.
Весьма печально, но зачастую разработчики любители держать бекапы БД прямо в репозитории. Тогда остается только скачать его и, выяснив чувствительную информацию, применить её против сервера.
Также, изучив исходники, можно найти другие уязвимости (например, sql injection [7]) или пути до исполняемых файлов, позволяющих администрировать ресурс. Либо просто «слить» все доступные исходники. Вариантов масса.
Самое интересное, что практически весь процесс (от добычи url'ов сайтов до получения исходников) можно автоматизировать. Более того, подобные решения уже существуют, и злоумышленники успешно монетизируют ваши ресурсы.
Списки проверяемых сайтов и файлы результатов я, разумеется, не привожу. При желании вы сможете взять ТОПы сайтов, и протестировать их самостоятельно.
Резюмируя, отмечу основные этапы для приватности вашего git-репозитория:
Соблюдая эти правила, вы сможете избежать вышеописанных ситуаций. Но вам также не стоит забывать о других типах атак на веб-приложения (и не только) — но в рамках данной статьи мы говорить о них не будем, т.к. с репозиториями они не связаны.
С вами был Петр,
спасибо за внимание.
Автор: ParadoxFilm
Источник [9]
Сайт-источник PVSM.RU: https://www.pvsm.ru
Путь до страницы источника: https://www.pvsm.ru/bezopasnost/250388
Ссылки в тексте:
[1] Alexa Rank: https://ru.wikipedia.org/wiki/Alexa_Internet
[2] blob-объекты: https://git-scm.com/book/ru/v1/Git-%D0%B8%D0%B7%D0%BD%D1%83%D1%82%D1%80%D0%B8-%D0%9E%D0%B1%D1%8A%D0%B5%D0%BA%D1%82%D1%8B-%D0%B2-Git
[3] этот: https://gist.github.com/firsov/734b98c7ac7d74a5cdf72eb83b9b607b
[4] тут: https://github.com/ParadoxFilm/GitChecker
[5] MySQL: https://ru.wikipedia.org/wiki/MySQL
[6] phpMyAdmin: https://ru.wikipedia.org/wiki/PhpMyAdmin
[7] sql injection: https://en.wikipedia.org/wiki/SQL_injection
[8] .gitignore: https://git-scm.com/docs/gitignore
[9] Источник: https://habrahabr.ru/post/324530/
Нажмите здесь для печати.