Проблема действительно масштабна и требует обсуждения. Далее сама статья. Пару месяцев назад нами была обнаружена уязвимость, присущая в основном большим интернет-проектам (вроде Рамблера, Мейла, Яндекса, Оперы и пр.). Удалось получить доступ к файловым структурам известнейших сайтов (в общей сложности 3320 сайтов) и в ряде случаев их полные исходные коды. Казалось бы, что в XXI веке трудно найти подобную уязвимость. Кажется, что уже всё найдено, а то что не найдено, сидит где-то очень очень глубоко. Оказалось, что корнем сегодняшнего зла является вполне повседневная вещь. Наверняка каждый из вас когда-нибудь имел дело с системой контроля версий SVN. SVN является продвинутым средством для организации совместной разработки десятков, а то и сотен разработчиков. В силу особенностей архитектуры, SVN хранит в каждой директории проекта свои метафайлы, аккуратно сложенные в скрытую директорию .svn. В одном из файлов под названием entries находится список всех файлов и директорий, расположенных в той же папке, что и .svn. Так же там находится информация о расположении репозитория, размере файлов, даты их изменения и логины пользователей, работающих над проектом. Уже не плохо, правда? Объясню, получается, если проект разрабатывается с помощью SVN, то заглянув по адресу http://draftcopy.ru/.svn/entries мы увидим файловую структуру корня проекта с авторами, последними изменениями, ссылкой на основную ветку репозитория итп. Но можно пойти и далее. В той же папке .svn находится директори text-base, в которой лежат последние версии всех файлов, находящихся в репозитории. Картину дополняет так же и то, что файлы имеют не стандартное расширение (например .php), которое позволяет их сразу отправить на интерпретатор, а дополнительное расширение .svn-base, благодаря которому файл отдается запросившему его человеку «как есть», т.е. голый исходный код! draftcopy.ru/.svn/text-base/index.php.svn-base Стоит заметить, что описанная картина является идеальной и хоть она и была таковой в большинстве случаев, все же большой процент исходных кодов не удалось получить по тем или иным причинам. Впервые осознав, что обнаруженная уязвимость присуща большинству проектов последние девять лет, было решено полностью просканировать рунет чтобы посмотреть чем живут интернет-проекты и получить интересную статистику. Но перед историей о том как это было, следует рассказать седым админам, как защищаться от подобного… Защита от уязвимости Уязвимость можно обойти несколькими путями. Путь в лоб — запретить обращаться к метадиректориям SVN по 80-ому порту, т.е. средствами вебсервера. Решение для nginx Code: location ~ /.svn/ { deny all; } Глобальных локейшенов в nginx`е нет, поэтому прийдется подписывать для каждой server области. Чтобы правило имело силу, необходимо загружать его до других локейшенов с регулярным выражением. Универсальный способ — первым локейшеном. Решение для Apache Code: <Directory ~ ".*\.svn"> Order allow,deny Deny from all Satisfy All </Directory> Тут немного проще, дописываем это в httpd.conf и на всех проектах под управлением apache чтение из директории .svn будет недоступно. Решение средствами SVN Защита от уязвимости средствами вебсервера — лечение болезни. Любой доктор скажет, что профилактика проще, легче и менее затратней, чем лечение. Поэтому лучшим решение будет отсутствие этих самых метадиректорий в корне проекта. Добиться этого можно средствами svn export из основной ветки. История исследования Как я уже было сказано, было решено просканировать весь рунет на наличие подобной уязвимости. Были подняты прокси-сервера, написан парсер и получена свежая база доменов в зоне ru. Первая версия скрипта работала две недели, получая сайт за сайтом в один поток. К завершению сканирования, база насчитывала более 3000 уязвимых сайтов и занимала более ста гигабайт исходных кодов. Проблемой первого сканировния было то, что скачивались все сорцы без разбора, не зависимо от того, отдавали они 200 или 500 код, а так же закачивалась графика и js-скрипты. А так же часто веб-сервера были настроены таким образом чтобы отдавать 200 код, даже если файл на самом дела отсутствовал. Вторая версия скрипта была уже шустрее, работала в несколько потоков с двух серверных машин и правильно различала коды ответа содержимое полученных страниц. Мы обошли весь рунет за 4 дня. Дальнейшими планами была база доткомов. Стало очевидно, что при текущих ресурсах обход был бы выполнен как минимум за пару лет (зона com сейчас насчитывает более 700 млн доменов (против 2 млн ru)). К дел был привлечен отличный си-программист Андрей Сатеренко, который написал быстрого демона, который сумел бы в пару раз сократить наши временные затраты. Но, к сожалению, к этому моменту лето кончилось, навалилилась работа. Грандиозные планы было решено свернуть. Прежде чем публиковать открыто информацию об уязвимости, необходимо было предупредить всех пострадавших. В первую очередь письма были разосланы гигантам (yandex.ru, rambler.ru, mail.ru, opera.com, rbk.ru, 003.ru, bolero.ru, habrahabr.ru, итого 19 адресов), затем, сегодняшней ночью, письма получили остальные 3000+ сайтов. Выпуск этой статьи был задержан ожиданием пока opera.com закроет уязвимость на всех своих серверах. Немного статистики Просканировано доменов: 2253388 Уязвимых: 3320 Статистики по оповещениям пока нет, возможна она будет опубликована через пару недель. Из крупных порталов, ответили шестеро. Самым оперативным оказался Яндекс, прислав ответное письмо ночью в воскресенье. Десять проектов никак не прореагировали на наши письма, три проекта закрыли уязвимость не поблагодарив. Мы не злопамятные, мы запишем их имена… Несколько интересных фактов: 1. Киберсквотеры полюбили SVN, как и оптимизаторы; 2. Единый CSS для календарей яндекса собирается из десятка CSS средстами $make из консоли 0_0; 3. На проектах Рамблера пользуются сервисами Яндекса 0_0, найдены файлы «подтверждения домена» для сервисов Яндекса; 4. РБК использует и сервисы яндекса и сервисы гугля и очень любят «сложные» пароли; 5. Опера уважает MySQL, но сайт у них на голом html с реальными директориями и поддиректориями; 6. Блондинка уважает CodeIgniter; 7. PostgreSQL уважают движок wikimedia => PostgreSQL уважают MySQL ;-) 8. Все проекты Футурико (и Лепра) написаны на perl. 9. Порядка 10 сайтов со словами в домене типа «hack» и «secure» уязвимы; 10. Многие уверены, что назвав директорию с phpmyadmin примерно «__xpma123uff__» но сохранив пароль в конфиг, это хорошая защита; 11. Многие до сих пор хранят конфиги в inc файлах, без расширения .php, которые открываются как текст в браузере. (c) habrahabr p.s. первая мысль, парсер+гигабитка
na xa6re procgital i w sgoke tozge 6il. a skol'ko nepaxannogo to, xotia 6ag wrode esge w ianwarre pro nego pisali
Мда, ещё один повод вспомнить о том что когда пишеш непробиваемую защиту, нехрен нацарапывать пароли на системнике
google => inurl:"*.*.svn/text-base" Code: Результаты 1 - 10 из примерно 610 000 для inurl:"*.*.svn/text-base". (0,22 секунд)
Да интересно, но не так тут все уж и критично. не всегда можно прочитать php файлы, т.к .php.svn-base - выполняется как php код, потому что тип файла .svn-base apache не знает.
google: inurl:"*.gov*.svn/text-base" Code: Результаты 1 - 10 из примерно 5 990 для inurl:"*.gov*.svn/text-base". (0,19 секунд) хы)
Задолбаешься все последствия продумывать Вот представим: пишется софт. Сначала все просто - пару функций, переменные держатся в голове. Постепенно объемы увеличиваются, идет переключение между темами, если работа в команде - обработка стыков модулей. И постепенно возникает пару багов. Программа просто не работает так как надо. Значит, все усилия - на фикс багов. Ну, это оттого, что они видны. А те, что не видны, фиксятся после - на этапах тестирования и уже использования коммерческими пользователями. Кароче, развел я тут околесицу. Суть: за всем не уследишь.
То есть какбе получить и слить файловую структура яндекса, мейла, рмблера, оперы, хабра, лепры и кучи других крупных сайтов - шум и пыль? Сгинь, школота.
Ты лично, что слил стоящего и как этим воспользовался? Это грубо названый "баг" не что иное как бакланизм разработчиков, и не больше, разводить слюни по этому поводу я не вижу смысла, да целых 0,15% рунета подвержены этой скажем "инфо-атаке" и пусть среди них есть крупные порталы, уязвимость чуть более интересна чем нахождение phpinfo, давайте просканируем по рунету наличие его, а еще лучше config.inc и раструбим на весь инет а? зыж. и за базаром следи упырь, школоту в зеркале увидишь.
