Системы контроля версий хранят в себе очень много данных — практически все изменения, которые были совершены. Это дает нам возможность получить и исходники существующего приложения, и то, что было когда оно только создавалось: DEV-пароли, захардкордженные ключи и еще много чего интересного!
Системы контроля версий (а-ля Git или SVN) используются сейчас повсе местно в хоть сколько-то организованных проектах. Очень часто с помощью их накатываются/обновляются и веб-проекты. Это, в свою очередь, может породить ряд проблем, если веб-сервер некорректно (во многом по умолчанию) настроен.
Вся основная проблема появляется тогда, когда специальные папки и файлы (.git, .svn, CVS…) оказываются в директориях веб-сервера, то есть доступны через веб-сервер. Ситуация реально вполне типовая, а поэтому эксплуатация ее нам интересна.
Но для начала важно помнить, что системы контроля версий хранят в себе очень много данных — практически все изменения, которые были совершены. Это дает нам возможность (не всегда, правда) получить и исходники существующего веб-приложения, и то, что было, когда оно толь-
ко создавалось (а значит, и тестовые, временные учетки, которые когда-то были захардкожены в приложении, у нас тоже есть возможность получить).
Хотелось бы отметить, что не раз уже «всплывали» дисклозы исходников в крупных проектах. Так что этой типичной мисконфигурацией стоит воспользоваться.
Можно выделить две основные типовые проблемы: когда директория с метаинформацией доступна через веб и когда для нее еще включен листинг. Второй вариант, конечно, проще и понятнее (можно просто все скачать), но и с первым проблемы решаются, если известен алгоритм хранения данных системы контроля версий (да и тулзы соответствующие есть). Давай разберем основные из систем, чтобы было понятно, как обстоят дела внутри.
Первый пример — SVN до версии 1.7. В ней директории .svn находятся в каждой директории проекта. Один из самых интересных файлов — entries, в котором содержатся имена файлов и директорий проекта. Имея их, мы можем к ним напрямую обращаться. Кроме того, копии всех файлов хранятся в /.svn/text-base/. Например, /.svn/text-base/config.txt.svn-base, то есть мы еще и отсюда их можем получить. При этом важно помнить, что в зависимости от конфигурации расширение svn-base может не учитываться, что может не дать возможность скачать исполняемые файлы типа PHP.
И еще раз подчеркну, что .svn в каждой директории, а потому и entries, и данные, возможно, потребуется с каждой сливать. Второй вариант — SVN начиная с версии 1.7 и выше. Здесь многое изменилось: директория .svn присутствует только в корне проекта, а не в каждой директории. Файла entries нет, зато появился wc.db, который представляет собой базу данных SQLite 3, в которой и хранится основная метаинформация о проекте. Кроме того, теперь файлы с исходничками лежат в одной папке /.svn/pristine/. Но, чтобы не было проблем с одинаковыми именами в разных папках (а может, и еще какие причины были), полный путь до файла представляет собой значение SHA-1 от имени файла и директорию с первыми двумя буквами хеша. Например, /.svn/pristine/bb/bb6499b8e938f92a3695fff1afe57edea4b9efb7.svn-base.
Один из больших плюсов для нас заключается в том, что пропадает расширение из имени файла, таким образом мы обходим проблему исполнения таких файлов, как PHP.
Сами хешики и соотношения с путями до файлов можно взять как раз из wc.db следующей командой:
sqlite3 wc.db 'select local_relpath, checksum from NODES'
И последний вариант — Git. Вся информация хранится только в корне, в директории /.git/. Но структура хранения данных там значительно более специфичная. Во многом потому, что в Git файлы, директории, коммиты представляют собой объекты, которые и хранятся уже в файловой системе в директории /.git/objects со значениями хеша SHA-1 в качестве поддиректории и имени. Так что я позволю себе опустить это описание.
В итоге мы имеем то, что чисто вручную распарсить — дело затруднительное, разве что файл /.git/index может дать нам перечень имен файлов. С другой стороны, есть различные тулзы, которые нам могут помочь.
Например, dvcs-ripper (goo.gl/tqRFJ2) или модуль в OWASP ZAP (goo.gl/ahL86n).
Самое приятное, что в результате мы можем получить у себя полностью рабочий Git-репозиторий и просмотреть актуальные исходники, а также «историю» коммитов, то есть произведенных изменений в коде.
