Тысячи сайтов Рунета могут быть взломаны

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 корректными методами.

Настоящий материал самостоятельно опубликован в нашем сообществе пользователем Postman на основании действующей редакции Пользовательского Соглашения. Если вы считаете, что такая публикация нарушает ваши авторские и/или смежные права, вам необходимо сообщить об этом администрации сайта на EMAIL abuse@newru.org с указанием адреса (URL) страницы, содержащей спорный материал. Нарушение будет в кратчайшие сроки устранено, виновные наказаны.

Читайте также:

новые старые
На почту
Slonik
Slonik

Ядрён-батон, галактико опасносте! Ну, мы то в надежных руках? Ведь правда, ведь верно?

Proper
Proper

А у нас нет гитхаба. Мы не практикуем параллельную разработку командами — у нас в ходу классический способ Step-by-step, при этом каждый шаг делает один разработчик.

Slonik
Slonik

Ффууу… отлегло. Хотя, мне лично бояться, вроде, нефиг, однако ж, этот факт греет.)))

ilya_r
ilya_r

Этим не стоит гордиться.
Система контроля версий предназначена для протоколирования изменений в программных файлах.
На примере Git:
git init — создает папку .git в текущей дирректории
git add *.sh — помечает для отслеживания все файлы bash скриптов
git commit -am «добавил функцию X» — протоколирует все изменения в файлах *.sh с момента предыдущего commit, с меткой «добавил функцию X»

Программой qgit можно посмотреть список всех измененных файлов, кем, когда и какие были внесены изменения.

А команда git checkout «индекс требуемого коммита» вернет все измененные файлы проекта в состояние указанного коммита.

Таким образом git позволяет перейти в любой закоммиченный момент жизни проекта, что дает отличный инструмент для поиска ошибок, когда накопилось много изменений, а затем обнаружился непонятный глюк.

Proper
Proper

Это всё понятно. Но реальность отнюдь не так светла, как представляется.

Из stable точек один хрен снимаются бэкапы, посмотреть диффы из бэкапов нет проблем, а выяснять, кто делал коммиты, при однопоточной разработке в одно лицо — просто нет необходимости, это и так известно.

Системы контроля версий критически нужны тогда, когда разработка ведется параллельно большой командой, что сопровождается вечными дрязгами «кто испортил мой код» и «у меня всё работало». В небольшой команде это просто потеря времени, а для однопоточной разработки VCS вообще не нужны.

ilya_r
ilya_r

И она не так светла не из-за git, а по причине разгильдяйского отношения к настройкам доступа.

Proper
Proper

Нет, дело не в этом. Я подозреваю, что ты еще под стол пешком ходил, и никакого Git вовсе не было, когда я коммитил большие проекты (сотни тысяч строк кода на C++) в SourceSafe. Поэтому применение VCS в проектах разного размера я прочувствовал на практике. Как всякий инструмент, VCS не панацея и не лекарство от бардака в головах разработчиков.

Хуже того — любой VCS приносит с собой собственный оверхед и издержки. В том числе и Git. Поэтому бездумно тыкать его везде, в любой проект, без анализа hits and losses — неправильно.