ITSOFT: Тысячи сайтов Рунета выложили свои исходники в публичный доступ

TL;DR

16 сайтов из топ-1000 самых посещаемых сайтов Рунета согласно статистике LiveInternet с совокупной посещаемостью в 34 231 732 пользователей в месяц подвержены простой уязвимости, позволяющей получить доступ к исходникам проекта. Более 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 корректными методами.

Добавить 12 комментариев

  • Ответить
    Владимир Мяу и компания

    Q: Как проверить и исправить

    A: Не использовать git.

    P. S. Про SVN бред какой-то? Она не пихает папки .svn так давно, что я даже навскидку не скажу, сколько лет с тех пор прошло.

  • Ответить
    Tvolod ВебЛаб

    Между уязвимым сайтом и сайтом с «открытым» (через Git/SVN) исходным кодом разница такая же как между «вор знает шифр от вашего сейфа» и «вор знает модель вашего сейфа», т.е. принципиально огромная, и чаще всего непреодолимая. Однако, поскольку из второго случая никакого исследования и статьи не получится, то формулировки подогнаны под первый случай, хотя вроде как автор нигде не соврал, и даже усилил статью абзацем про возможность обнаружить в открытом доступе пароли.
    В общем, молодец.

  • Ответить

    @Tvolod
    нет, вор не просто знает модель вашего сейфа, но и читает его конфигурационные файлы с доступом к базам данным, серверам кластера или проксисерверам, последнее даже еще опаснее, так как позволит dDOS-сить настоящий сервер, а не проксируемый на сервисе защиты.

  • Ответить

    «Но, по моему мнению, лучше всего не использовать Git/SVN на production-сервере, осуществляя deploy корректными методами.»

    ребят, а что такое деплой корректными методами?

  • Ответить

    Многие используют Git, чтобы одной командой получать обновления на production-сервер, при этом вся папка с проектом и служебными файлами находится в Document Root.

    В идеальном варианте, на production-сервер не должно попадать никаких «лишних» файлов/данных/настроек.

    Если существует причина, по которой наличие репозитория на сервере всё же необходимо, то размещать его стоит за пределами Document Root.

    git -bare init
    > hooks/post-receive
    git -work-tree=${WEB_DIR} clean -fd -exclude=
    git -work-tree=${WEB_DIR} checkout -force

    svn export

  • Ответить
    Владимир Мяу и компания

    ребят, а что такое деплой корректными методами?

    Не знаю, это в шутку вопрос или всерьез? Если всерьез, то кажется очевидным, что корректный метод — это такой (любой), при котором инженер, ответственный за развертывание, полностью отдаёт себе отчет в том, что при этом происходит и какие в точности файлы идут на боевую машину. По-моему, также совершенно очевидно, что, поскольку VCS — это своего рода расширения для файловых систем, добавляющие к файлам и папкам еще одно измерение — время, то эти расширения не могут быть бесплатными, и где-то они это «время» хранят внутри обычной файловой системы. Не знаю, у меня наверно синдром нездоровой въедливости что ли, я не могу расслабица и рукожопить, как многие вокруг, поэтому как само собой разумеющееся писал скрипт, рекурсивно выкусывающий все скрытые папки .svn еще в те годы, когда никаким web’ом не занимался и когда надо было просто дать кому-то пачку сорцов. А некоторые, похоже, ленятся и не интересуются, как работает вся эта шняга, на которой будут крутиться сорцы стоимостью от нескольких миллионов рублей. Да и правда что, зачем? При мне однажды у предприятия грохнулась бухгалтерия и оказалось, что никто не почесался сделать бекапы!!! А всё потому, что предприятие было очень продвинутым — там все увлекались делегированием и бест практисами.

    Вот эти цифры, которые в статье приведены, они конечно полный ахтунг. Потому, что это же топ-1000 проектов. Деплоем обычно занимается лид или его приближенный (ну не доверит же нормальный лид деплоить свою фанеру первому встречному ракообразному?). И если в «голове» такое, то что же в остальных местах? Уныло.

  • Ответить

    Зависит от. Частый сценарий — это именно что взяли опенсорс движок как он есть в репозитории, а конфигурировали уже на месте без коммитов. Т.е. никаких конфигураций баз данных, паролей и прочего уникального для конкретного сайта там нет.

  • Ответить

    «Частый сценарий» на основе каких данных?
    Несмотря на то, что данный вариант возможен, — в «дикой природе» замечен не был.
    Возможно это актуально для «сделанной вчера» тестовой поделки, но для публичных проектов, на мой взгляд, — редкость.
    Если разработчики используют Git — они будут использовать его не только для того, чтобы «взять движок», в противном случае — они банально скачают его архив.