Эта история про забавное стечение обстоятельств и один крошечный баг, который до недавнего времени имел место быть в сервисе «Я.Вебмастер». Хронология и некоторые моменты, изложенные тут, немного изменены, для более складного повествования. Но тем не менее, суть, остаётся не изменной.
Началось всё с того, что я заметил странную особенность CMS Wordpress. Так, при при первом обращении, к моему сайту по адресу www.domain.com/non_existent_file.ext выводился заголовок «404 Not Found», а при повторном «200 OK». На тот момент казалось, что на это могут влиять мои правки в движке и различные прикрученные костыли. Но при диагностике, на этапе отключения плагинов, выяснилось, что причиной такого поведения является плагин «W3 Total Cache». Не разбираясь в деталях, с мыслью «допилят ещё», включил его снова и забыл.
Через пару месяцев решил добавить этот сайт в Я.Вебмастер. Сервис предоставлял несколько способов для подтверждения владения сайтом. На тот момент ими являлись:
Так как SSH соединение с сервером в то время было открыто, самым простым вариантом показался «txt-файл», который гласил, что для аппрува нужно:
Команда touch не заставила себя долго ждать и после нажатия кнопки «Проверить», мой сайт был успешно помещён в раздел «Мои сайты».
Являясь закоренелым любителем почитать логи, во время очередного просмотра, попались строки которые показывали как бот Яндекса проверяет наличие этого файла. Выглядело это следующим образом:
Мне стало интересно, а что если отдавать всегда «200 OK». Было принято решение немного «помучить» робота. Так, при возврате сервером кодов отличных от 200 и 404, писалось примерно следущее: «Для заданной страницы (или страницы, полученной после перенаправления) сервер возвращает код статуса http 502 (ожидался код 200).». Если же бот получал 200 постоянно, то так же об этом сообщал и проверка не проходила.
В процессе исследования, случайно, удалось получить подтверждение без наличия файла. Такого я никак не ожидал и стал разбираться с произошедшим.
Последовательность обращений в логе получилась такая:
Провернув трюк ещё раз для наглядности, вспомнил про вышеописанную особенность WordPress. Стало интересно, случается ли такое ещё где-то и как часто.
Был написан простенький чекер на PHP, который слал два запроса с несуществующим именем файла и записывал успешный результат. В качестве списка для тестирования был выбран «Alexa Top 1,000,000».
Не сказать, что результат получился грандиозным, но он был. Вышло около 1500 доменов в различных зонах. При осмотре полученного списка, стало понятным, что плагин «W3 Total Cache» сам по себе ни при чем, так как «проверку» проходили сайты с установленными плагинами QuickCache, MaxCache и другими. Сходство было только одно, большинство из них использовали WordPress. И как выяснилось позже, была ещё одна зависимость, это включенное кеширование в файлы. В W3TC опция называется «Disk (Enhanced)». К сожалению, я не большой любитель копания кода, поэтому причина такого поведения мне не известна.
Так же отмечу, что на некоторых сайтах следо�� вордпресса обнаружено не было. Возможно он искуссно замаскирован, либо подобный баг возникает ещё где-то.
Далее был отправлен отчёт в «Yandex Bug Bounty». C содержанием:
Это мой первый опыт участия в программе Яндекса и я был приятно удивлён оперативной реакцией сотрудников компании. В этот же день мне ответили и начали разбираться с моим репортом, а на следующий, присудили награду в размере 41337 рублей (примерно $700 в тот момент). Единственное, к чему могу придраться, на мой взгляд цифра 313373 смотрелась бы красивее. Но по большому счёту, это стечение обстоятельств не несло большой выгоды злоумышлен��икам. Для целевых атак оно не годилось по причине большого количества зависимостей. Извлечение какой либо материальной выгоды из этого, так же сложно представить. Разве что продажа XML лимитов. Поэтому я доволен наградой Яндекса, так как на момент отправки особенного ничего не ожидал.
В качестве морального баунти, через несколько дней после отправленного отчёта, судьба txt-фала была решена (R.I.P.):
...
...
P.S.
Надеюсь, что у него всё получилось :)
Началось всё с того, что я заметил странную особенность CMS Wordpress. Так, при при первом обращении, к моему сайту по адресу www.domain.com/non_existent_file.ext выводился заголовок «404 Not Found», а при повторном «200 OK». На тот момент казалось, что на это могут влиять мои правки в движке и различные прикрученные костыли. Но при диагностике, на этапе отключения плагинов, выяснилось, что причиной такого поведения является плагин «W3 Total Cache». Не разбираясь в деталях, с мыслью «допилят ещё», включил его снова и забыл.
Через пару месяцев решил добавить этот сайт в Я.Вебмастер. Сервис предоставлял несколько способов для подтверждения владения сайтом. На тот момент ими являлись:
— html-файл
— мета-тэг
— txt-файл
— через whois
— чере�� dns
Так как SSH соединение с сервером в то время было открыто, самым простым вариантом показался «txt-файл», который гласил, что для аппрува нужно:
1. Создайте txt-файл с именем yandex_59306eb68da05077.txt с произвольным содержимым (можно пустой)
2. Загрузите его в корневой каталог вашего сайта
3. Убедитесь, что загруженный файл открывается по адресу www.domain.com/yandex_59306eb68da05077.txt.
4. Нажмите на кнопку «Проверить»
Команда touch не заставила себя долго ждать и после нажатия кнопки «Проверить», мой сайт был успешно помещён в раздел «Мои сайты».
Являясь закоренелым любителем почитать логи, во время очередного просмотра, попались строки которые показывали как бот Яндекса проверяет наличие этого файла. Выглядело это следующим образом:
… «GET /yandex_0250d52d00c8a904.txt HTTP/1.1» 404 1362 "-" "… YandexWebmaster/2.0; +http://yandex.com/bots)"
… «GET /yandex_59306eb68da05077.txt HTTP/1.1» 200 0 "-" "… YandexWebmaster/2.0; +http://yandex.com/bots)"
… «GET /yandex_11c01dd326a98199.txt HTTP/1.1» 404 1362 "-" "… YandexWebmaster/2.0; +http://yandex.com/bots)"
Мне стало интересно, а что если отдавать всегда «200 OK». Было принято решение немного «помучить» робота. Так, при возврате сервером кодов отличных от 200 и 404, писалось примерно следущее: «Для заданной страницы (или страницы, полученной после перенаправления) сервер возвращает код статуса http 502 (ожидался код 200).». Если же бот получал 200 постоянно, то так же об этом сообщал и проверка не проходила.
В процессе исследования, случайно, удалось получить подтверждение без наличия файла. Такого я никак не ожидал и стал разбираться с произошедшим.
Последовательность обращений в логе получилась такая:
… «GET /yandex_2dd0e3403151c956.txt HTTP/1.1» 404 1362 "-" "… YandexWebmaster/2.0; +http://yandex.com/bots)"
… «GET /yandex_с220dу5d90c8a331.txt HTTP/1.1» 404 1362 "-" "… YandexWebmaster/2.0; +http://yandex.com/bots)"
… «GET /yandex_d43c048a7be5a791.txt HTTP/1.1» 404 1362 "-" "… YandexWebmaster/2.0; +http://yandex.com/bots)"
… «GET /yandex_d22193589eac5880.txt HTTP/1.1» 404 1362 "-" "… YandexWebmaster/2.0; +http://yandex.com/bots)"
… «GET /yandex_с220dу5d90c8a331.txt HTTP/1.1» 200 0 "-" "… YandexWebmaster/2.0; +http://yandex.com/bots)"
… «GET /yandex_6a5ec74b714c7856.txt HTTP/1.1» 404 1362 "-" "… YandexWebmaster/2.0; +http://yandex.com/bots)"
Провернув трюк ещё раз для наглядности, вспомнил про вышеописанную особенность WordPress. Стало интересно, случается ли такое ещё где-то и как часто.
Был написан простенький чекер на PHP, который слал два запроса с несуществующим именем файла и записывал успешный результат. В качестве списка для тестирования был выбран «Alexa Top 1,000,000».
Не сказать, что результат получился грандиозным, но он был. Вышло около 1500 доменов в различных зонах. При осмотре полученного списка, стало понятным, что плагин «W3 Total Cache» сам по себе ни при чем, так как «проверку» проходили сайты с установленными плагинами QuickCache, MaxCache и другими. Сходство было только одно, большинство из них использовали WordPress. И как выяснилось позже, была ещё одна зависимость, это включенное кеширование в файлы. В W3TC опция называется «Disk (Enhanced)». К сожалению, я не большой любитель копания кода, поэтому причина такого поведения мне не известна.
Так же отмечу, что на некоторых сайтах следо�� вордпресса обнаружено не было. Возможно он искуссно замаскирован, либо подобный баг возникает ещё где-то.
Далее был отправлен отчёт в «Yandex Bug Bounty». C содержанием:
Здравствуйте.
Метод подтверждения «txt-файл», для некоторых конфигураций сайтов, может позволить подтвердить сайт злоумышленникам.
Cвязано это, как мне кажется, с различными механизмами кеширования.
Так, в реализации кеширующего механизма, для популярной CMS Wordpress в связке с плагинами W3TC, Quick Cache, Max Cache и подобными. Сервер отдаёт заголовок 404 только при первом обращении к недоступному файлу, во второй раз ответ будет 200 ОК. Стоит отметить, что связка WP+кэш-плагины, сама по себе не подвержена, есть ещё некая зависимость, но для её выяснения нужно проводить исследование кода движка.
Вот так выглядит проверка яндекс ботом наличия «txt-файл»-а первый раз:
… «GET /yandex_2dd0e3403151c956.txt HTTP/1.1» 404 136 "-" "… YandexWebmaster/2.0; +http://yandex.com/bots)"
… «GET /yandex_с220dу5d90c8a331.txt HTTP/1.1» 404 136 "-" "… YandexWebmaster/2.0; +http://yandex.com/bots)"
… «GET /yandex_d43c048a7be5a791.txt HTTP/1.1» 404 136 "-" "… YandexWebmaster/2.0; +http://yandex.com/bots)"
А второй будет выглядеть уже так:
… «GET /yandex_d22193589eac5880.txt HTTP/1.1» 404 136 "-" "… YandexWebmaster/2.0; +http://yandex.com/bots)"
… «GET /yandex_с220dу5d90c8a331.txt HTTP/1.1» 200 0 "-" "… YandexWebmaster/2.0; +http://yandex.com/bots)"
… «GET /yandex_6a5ec74b714c7856.txt HTTP/1.1» 404 136 "-" "… YandexWebmaster/2.0; +http://yandex.com/bots)"
Несколько сайтов с подобным поведением и установленной Wordpress:
htmldoc.ru
laminortv.ru
www.comediatv.ru
А в этих случаях:
www.3dnews.ru
rutv.ru
tvkultura.ru
marker.ru
Действует какой-то другой механизм кеширования, но поведение идентично.
Стоит отметить так же этот отчёт: hackerone.com/reports/477. В тот момент, скорее всего, проверка «txt-файл»-а яндекс ботом была бы положительной. Кто знает, сколько ещё сайтов содержат подобный «функционал»?
Это мой первый опыт участия в программе Яндекса и я был приятно удивлён оперативной реакцией сотрудников компании. В этот же день мне ответили и начали разбираться с моим репортом, а на следующий, присудили награду в размере 41337 рублей (примерно $700 в тот момент). Единственное, к чему могу придраться, на мой взгляд цифра 313373 смотрелась бы красивее. Но по большому счёту, это стечение обстоятельств не несло большой выгоды злоумышлен��икам. Для целевых атак оно не годилось по причине большого количества зависимостей. Извлечение какой либо материальной выгоды из этого, так же сложно представить. Разве что продажа XML лимитов. Поэтому я доволен наградой Яндекса, так как на момент отправки особенного ничего не ожидал.
В качестве морального баунти, через несколько дней после отправленного отчёта, судьба txt-фала была решена (R.I.P.):
...
...
P.S.
Надеюсь, что у него всё получилось :)
