Тысячи сайтов Рунета могут быть взломаны
16 сайтов из топ-1000 самых посещаемых сайтов Рунета подвержены простой уязвимости, позволяющей получить доступ к исходникам проекта. Более 2 922 сайтов содержат ошибку конфигурации десятилетней давности. В рамках исследования компания ITSOFT проанализировала более полумиллиона сайтов русскоязычного интернета.
Проблематика
«Всё новое — это хорошо забытое старое». Уязвимость, речь о которой пойдёт ниже, появилась не сегодня и известна давно, как минимум с начала двухтысячных. Но результаты исследования показывают, что актуальная она и сейчас, равно, как и поднимаемые ею проблемы: качества и безопасности разработки интернет-проектов, уровня специалистов на рынке и халатности.
Раньше системы контроля версий использовались лишь на крупных проектах для решения проблем совместной разработки. Время шло, предпочтения менялись, все большее количество разработчиков начало использовать VCS и далеко не всегда по назначению. В 2008 году появился GitHub и к началу 2010-х годов большинство разработчиков перешло на Git.
За это время сменились поколения разработчиков, но отношение к вопросам безопасности системно не сильно изменилось. Информационная безопасность, в контексте её базовых аспектов для широкой аудитории, всё так же находится в зачаточной стадии, хотя после утечек данных о покупках в интернет-магазинах и HeartBleed всё большее количество людей начинают о ней задумываться.
Тем не менее, простая ошибка конфигурации и человеческий фактор, который приводил к масштабным последствиям десять лет назад, всё так же актуален.
Уязвимость
Специфика систем контроля версий подразумевает наличие на файловой системе скрытых служебных папок, хранящих информацию о файлах проекта и их изменениях. При неверной конфигурации сервера данная информация становится доступна публично всем пользователям, что позволяет получить доступ к исходникам всего проекта и открывает широкий простор для поиска дальнейших уязвимостей.
По умолчанию Git использует каталог «.git» в папке проекта, в котором хранится информация о всех изменениях файлов проекта. SVN, в свою очередь, содержит подобную информацию в папке «.svn».
Веб-серверы Nginx и Apache по умолчанию не ограничивают доступ к этим папкам, несмотря на то, что файлы и папки, начинающиеся с точки, в UNIX-like системах являются скрытыми, а Apache и сам использует служебные файлы «.htaccess».
Поскольку проблема очень распространенная — разработчики CMS и фреймворков рано или поздно вносят запрет на отображение подобных файлов в свои сборки, например как со временем сделал 1С-Битрикс в своем Веб-окружении. Но разработчики веб-серверов подразумевают, что предоставляют базовый инструмент, гибкость которого должна быть использована системными администраторами в зависимости от их задач, перекладывая ответственность.
В результате — существует огромное количество сайтов, предоставляющих свободный доступ к своим исходным кодам, а как следствие — базам данных, серверам, логам, бэкапам и чувствительной информации (в зависимости от каждого конкретного случая).
Статистика и анализ
Спустя семь лет после того, как подобная уязвимость была обнаружена у таких крупных IT-компаний, как Яндекс, Mail.ru, Rambler, Opera (правда тогда речь шла только про SVN), — рассчитывать на повторение истории с теми же участниками не приходилось. Однако, за это время новые ресурсы завоевали свою популярность, количество сайтов в Рунете увеличилось, равно как и пользователей, на смену SVN во многом пришёл Git и уже новое поколение разработчиков создавало эти проекты и переделывало старые. Поэтому количество уязвимых сайтов известных брендов довольно велико: от крупных телекоммуникационных компаний и производителей техники до медицинских клиник и федеральных порталов.
Для иллюстрации мы взяли данные статистики LiveInternet для сайтов Рунета и проверили, какое количество среди них содержат данную уязвимость. Результатом анализа топ-1000 самых посещаемых стали 16 проектов с совокупной аудиторией в 34 231 732 пользователей в месяц.
Решив не останавливаться на достигнутом, мы собрали информацию по 559 411 сайтам рейтинга LiveInternet, получив в результате 2 922 уязвимых.
За прошедшие годы распространенность систем контроля версий увеличилась, и теперь их можно встретить не только на крупных проектах, а повсеместно, что можно увидеть на графике. Из смещения распределения для SVN вправо можно сделать вывод о том, что разработчики крупных сайтов в своё время выучили урок или просто перешли на Git. Огорчает тот факт, что системно опыт не был накоплен и передан новому поколению разработчиков, которое, уже используя другие инструменты, совершает те же ошибки на крупных проектах. Результат: количество уязвимых сайтов в разы выше при приближении к первому месту в рейтинге посещаемости.
Соотношение количества уязвимых проектов, использующих Git и SVN, повторяет результаты рейтинга систем контроля версий. Это может говорить о том, что вероятность ошибок безопасности не зависит от инструмента и условно-постоянна.Примечательно, что есть проекты, у которых доступны обе скрытые папки.
Само по себе раскрытие информации, хранящейся в скрытых папках, может не привести к серьёзным последствиям, если в репозитории находятся только файлы, относящиеся к фронтенд-части проекта. Однако, на практике мы имеем: пароли в открытом виде от удаленных хостингов репозиториев проектов, пароли от баз данных, бэкапы, пароли от других серверов, чувствительную информацию пользователей, ключи доступа к сторонним сервисам; не говоря о том, что доступ к исходникам серверной части проекта позволяет обнаружить уязвимости в коде.
Как проверить и исправить
Для того, чтобы узнать, уязвим ли ваш проект, достаточно лишь ввести в адресной строке браузера http://domain.ru/.git/HEAD или http://domain.ru/.svn/entries для Git и SVN соответственно. Если вы увидели что-то отличное от сообщения о ненайденной странице — стоит задать вопрос разработчикам.
Закрыть брешь можно настроив веб-сервер на запрет доступа к скрытым файлам и папкам. Но, по моему мнению, лучше всего не использовать Git/SVN на production-сервере, осуществляя deploy корректными методами.
Ядрён-батон, галактико опасносте! Ну, мы то в надежных руках? Ведь правда, ведь верно?
А у нас нет гитхаба. Мы не практикуем параллельную разработку командами — у нас в ходу классический способ Step-by-step, при этом каждый шаг делает один разработчик.
Ффууу… отлегло. Хотя, мне лично бояться, вроде, нефиг, однако ж, этот факт греет.)))
Этим не стоит гордиться.
Система контроля версий предназначена для протоколирования изменений в программных файлах.
На примере Git:
git init — создает папку .git в текущей дирректории
git add *.sh — помечает для отслеживания все файлы bash скриптов
git commit -am «добавил функцию X» — протоколирует все изменения в файлах *.sh с момента предыдущего commit, с меткой «добавил функцию X»
Программой qgit можно посмотреть список всех измененных файлов, кем, когда и какие были внесены изменения.
А команда git checkout «индекс требуемого коммита» вернет все измененные файлы проекта в состояние указанного коммита.
Таким образом git позволяет перейти в любой закоммиченный момент жизни проекта, что дает отличный инструмент для поиска ошибок, когда накопилось много изменений, а затем обнаружился непонятный глюк.
Это всё понятно. Но реальность отнюдь не так светла, как представляется.
Из stable точек один хрен снимаются бэкапы, посмотреть диффы из бэкапов нет проблем, а выяснять, кто делал коммиты, при однопоточной разработке в одно лицо — просто нет необходимости, это и так известно.
Системы контроля версий критически нужны тогда, когда разработка ведется параллельно большой командой, что сопровождается вечными дрязгами «кто испортил мой код» и «у меня всё работало». В небольшой команде это просто потеря времени, а для однопоточной разработки VCS вообще не нужны.
И она не так светла не из-за git, а по причине разгильдяйского отношения к настройкам доступа.
Нет, дело не в этом. Я подозреваю, что ты еще под стол пешком ходил, и никакого Git вовсе не было, когда я коммитил большие проекты (сотни тысяч строк кода на C++) в SourceSafe. Поэтому применение VCS в проектах разного размера я прочувствовал на практике. Как всякий инструмент, VCS не панацея и не лекарство от бардака в головах разработчиков.
Хуже того — любой VCS приносит с собой собственный оверхед и издержки. В том числе и Git. Поэтому бездумно тыкать его везде, в любой проект, без анализа hits and losses — неправильно.