Введение
Здравствуйте, уважаемые читатели. Сегодня на повестке дня у нас небольшое тестирование —
первых ?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,64% от общего числа)
Тестирование #2
Дата: 21 марта 2017 года
Кол-во тестируемых сайтов: 99991 (тот же лист сайтов, что и в первый раз)
Открытых Git-репозиториев: 599 (0,60% от общего числа)
Примечательно, что время работы утилиты на домашнем ноутбуке (при скорости интернет-соединения в 20 мбит/с) составило около 16-ти минут, что совсем не много.
Итак, за 100 дней кол-во «открытых» репозиториев (из моей выборки) сократилось на 40 штук. Это порядка 6% от изначального количества.
Много ли разработчиков одумалось? Нет, не похоже (такими темпами только через года 4-5 можно ожидать исправления проблем на данной выборке).
В целом, конечно, процент открытых репозиториев небольшой. Но с другой стороны, взяв выборку скажем в один миллион сайтов — это уже порядка 10 000 сайтов с подобной брешью.
При том нужно понимать, что это самые популярные сайты по версии Alexa Rank, а значит они обязаны быть защищенными. Предположительно, чем дальше по списку — тем чаще будут попадаться открытые репозитории.
Среди найденных сайтов были обнаружены сайты с весьма большой аудиторией (> 1кк уникальных/сутки), а также ресурсы различных учебных заведений (включая российские ведущие вузы, среди них некоторые выпускают по направлению веб-безопасности) и организаций. Этим грешит даже сайт одного небезызвестного архиватора.
(* Пример полученных исходных кодов. Обратите внимание на SQL дампы и лист авторизации)
Вариант вектора атаки
Чтобы читатели лучше понимали опасность данной оплошности разработчиков, накину один из возможных сценариев по взлому сервера:
- Найден открытый Git-репозиторий
- Получен доступ к исходным кодам сайта путем дампа гита
- Среди исходников найдены файлы с именами вроде config.php / database.php
- В файлах найдена чувствительная информация. А именно — данные для подключения к базе данных сайта (допустим, СУБД MySQL)
- На сайте также обнаружена phpMyAdmin — подключились к БД, используя данные из пунктов выше
- Нашли пару логин-пароль от админки (вероятно, предварительно расшифровав хеш пароля)
- Через админку исполнили вредоносный код на сервере / залили шелл / etc
- Как результат — что угодно. Зависит от целей и возможностей которые предоставились
И это ещё не самый простой сценарий, требующий определенного стечения обстоятельств.
Весьма печально, но зачастую разработчики любители держать бекапы БД прямо в репозитории. Тогда остается только скачать его и, выяснив чувствительную информацию, применить её против сервера.
Также, изучив исходники, можно найти другие уязвимости (например, sql injection) или пути до исполняемых файлов, позволяющих администрировать ресурс. Либо просто «слить» все доступные исходники. Вариантов масса.
Самое интересное, что практически весь процесс (от добычи url'ов сайтов до получения исходников) можно автоматизировать. Более того, подобные решения уже существуют, и злоумышленники успешно монетизируют ваши ресурсы.
Списки проверяемых сайтов и файлы результатов я, разумеется, не привожу. При желании вы сможете взять ТОПы сайтов, и протестировать их самостоятельно.
Как защититься?
Резюмируя, отмечу основные этапы для приватности вашего git-репозитория:
- Полностью закрывайте доступ на директорию репозитория из веба (если уж он туда смотрит), в т.ч. на чтение файлов и субдиректорий (как это сделать — зависит от веб-сервера). Убедитесь, что нельзя прочитать такие файлы /.git/config, /.git/index и остальные (даже без этих файлов, имея доступ к папке /.git/objects/ можно слить исходники путем перебора адресов — поэтому закрывайте абсолютно все от чужих хитрых глаз и рук).
- С помощью, например, .gitignore настройте игнорирование файлов с чувствительной информацией (бэкапы, конфиги и остальное) из репозитория — они там совершенно не нужны, и предоставляют собой серьезную угрозу безопасности. При выполнении данного пункта, даже если злоумышленник проникнет в ваш репозиторий, он ничего существенного сделать не сможет (за исключением того что
увидит ваш bad-style программированиясможет увести ваши исходники).
Соблюдая эти правила, вы сможете избежать вышеописанных ситуаций. Но вам также не стоит забывать о других типах атак на веб-приложения (и не только) — но в рамках данной статьи мы говорить о них не будем, т.к. с репозиториями они не связаны.
С вами был Петр,
спасибо за внимание.
Комментарии (35)
antonksa
22.03.2017 04:35+3Кол-во тестируемых сайтов: 99991 (тот же лист сайтов, что и в первый раз)
Открытых Git-репозиториев: 599 (0,0060% от общего числа)0,6%
TrogWarZ
22.03.2017 09:00+1Для чего вообще может быть нужно держать в паблик-директории сервера весь проект и иметь извне доступ к чему-либо кроме public/web/...?
В моём опыте этого не нужно было никогда делать, но, судя по посту, такое иногда делают (пусть даже закрыв git/svn). В каких случаях?
ParadoxFilm
22.03.2017 09:01Часто такое бывает в виде дефолтной конфигурации. Зачем это делать? Действительно причин не сильно много.
neck_varentsov
22.03.2017 23:52могу предположить, что это способ деплоя, ручное обновление кода из репозитория
docomo
28.03.2017 10:27Не обязательно ручное, хуки на обновление при пушах никто не отменял. Это ленивый деплой, конечно же.
justmara
22.03.2017 09:21+3взяв выборку скажем в один миллион сайтов — это уже порядка 10 000 сайтов с подобной брешью
агануда
ParadoxFilm
22.03.2017 09:27+5Дабы подкрепить это утверждение, я только что поставил на проверку первые миллион сайтов из топа. Вечером сообщу результаты.
esemi
23.03.2017 00:00+2Как оно там?
ParadoxFilm
23.03.2017 09:49+2Извините за задержку с ответом, поздно вернулся домой. Итак, товарищ justmara был прав — моя оценка была некорректна. На выборке из миллиона я нашел лишь порядка 5 000 репозиториев, что в два раза меньше моей оценки. Таким образом, распределение примерно линейное (вне зависимости от посещаемости сайта).
vadamlyuk
22.03.2017 09:29По поводу защиты:
На самом деле, хранение git-репозитария внутри рабочей директории сама по себе плохая практика by design.
Хорошая практика:
git init --separate-git-dir=/special/folder/for/git/<project-name> git clone --separate-git-dir=/special/folder/for/git/<project-name> <orig-repository>
И т.д.
В этом случае внутри рабочей директории будет храниться только файлик .git с содержанием вида:
gitdir: /special/folder/for/git/<project-name>
MasMaX
22.03.2017 09:33+4Это всё от лени. Вместо того чтобы клонировать сайт куда-либо в закрытое место, потом архивировать его исключая .hg и .git папки, многие разработчики просто делают «git pull» прямо на рабочем сайте и не заморачиваются.
selivanov_pavel
22.03.2017 18:43+1Почему нет? Выкладку может быть проще делать напрямую из репозитория через git fetch/git pull. Достаточно закрывать
.gitв конфиге веб-сервера и все счастливыesemi
22.03.2017 21:38+2Вообще нет нужды закрывать её в конфиге, если вебрут ниже корня репы, разве нет?
selivanov_pavel
22.03.2017 21:47Так не во всех проектах. Поэтому имхо проще всюду один раз закрыть, чем лишний раз думать где можно, где нельзя
ellrion
22.03.2017 09:56+4А ведь всё было бы так хорошо имей эти сайты в проекте просто отдельную паблик директорию, в которую бы уже и смотрел веб сервер. И эта проблема бы ушла и десяток других по сокрытию приватных файликов проекта.
polearnik
22.03.2017 11:09на некоторых фреймворках типа ларавела все так и происходит. Есть папка public в которой только index.php и папки с стилями скриптами и картинками
iborzenkov
22.03.2017 12:12+1Не на некоторых, а на почти всех фреймворках есть public директория с точкой входа а весь код лежит выше.
Весь проект в корне — это обычно CMS, которые устанавливаются путем копирования по ftp, разумется про git там не слышали. Так что собственно поэтому у нас всего 0.6%
Evengard
22.03.2017 11:31+53 Используйте систему деплоя, которая за вас пересоберёт для продакшна проект и корректно экспортирует в публичную папку.
sspat
22.03.2017 12:14+1Лучше всетаки бороться с первопричиной и выносить файлы гита за пределы публичной папки веб-сервера, так гораздо меньше шансов забыть про что-то и допустить ошибку, чем при попытках закрывать доступ на них по отдельности. Паролям, сертификатам и любым другим аутентификационным данным, ровно как и бекапам баз данных содержащим такие данные под версионным контролем делать нечего.
Bo0oM
22.03.2017 14:25Вот только я не понял, как в статье оказался скрин веб-шелла (пример полученных исходных кодов). Вы через админку залазили и заливали (судя по варианту вектора атаки)? :)
//ждем статьи про mercurial?ellrion
22.03.2017 14:27я думаю, имя доступ к исходникам (проектов такого качества), найти дыру позволившую залить шелл труда не составило)
ParadoxFilm
22.03.2017 15:27Это шелл на моем личном сервере, используется, в частности, как удобный файловый менеджер.
dartraiden
22.03.2017 15:54Этим грешит даже сайт одного небезызвестного архиватора.
Они как-то отреагировали на сообщение? Потому что я только что попробовал (дальше .git/index не ходил) — всё по-прежнему доступно.ParadoxFilm
22.03.2017 23:22Я отправил им письмо касательно искомого. Пока ответа и/или исправлений не поступало.
RFL
24.03.2017 12:59-1Прошли уже сутки, а .git/index все равно доступен… Интересно, сколько появится клонов этого небезызвестного сайта в сети, благодаря Хаброэффекту?
ParadoxFilm
24.03.2017 13:08Он доступен уже очень давно, и, судя по всему, будет доступен и далее. Причина, в частности, в том, что на сервере нет особо секретной информации.
Отвечая на ваше предположение по поводу «хаброэффекта», могу сказать, что клонов появится ±0 штук. Ибо это никому не надо. А если бы было надо, то для этого не обязательно залезать в чужой репозиторий (моя субъективная оценка).
laviro
Когда то давно, лет 5 назад, а может и больше, была статья на хабре, человек собирал такую же статистику, только для svn.
Идут года, технологи меняются, проблемы остаются :)
encyclopedist
Это было в 2009: Были получены исходники 3300 глобальных интернет-проектов. Более того, эта статья возглавляет список "лучших за все время".
laviro
ого, давно было.
Это какая то печаль, я начал думать что уже старый.