Почему Яндекс отказался от подтверждения сайтов txt-файлом

2016-02-07 в 14:30, admin, рубрики: txt-файл, Yandex, информационная безопасность, Я.Вебмастер

Эта история про забавное стечение обстоятельств и один крошечный баг, который до недавнего времени имел место быть в сервисе Я.Вебмастер. Хронология и некоторые моменты, изложенные тут, немного изменены, для более складного повествования. Но тем не менее, суть, остаётся не изменной.

Почему Яндекс отказался от подтверждения сайтов txt-файлом - 1

Началось всё с того, что я заметил странную особенность 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.):
...