Я забыл опубликовать эту статью 1 год назад, поэтому я опубликовал ее сейчас.

Давайте начнем с небольшого введения, как я это реализовал, а затем более технических деталей, чтобы вы лучше поняли.

Пишем 17 сентября 2018 года и я сижу дома за своим основным компьютером и готовлю презентацию на следующий день. Конечно, я провел небольшое исследование и посетил несколько других веб-сайтов, чтобы получить информацию. Во время исследования я заметил, что часть веб-страниц загружается некорректно. Вместо этого в браузере отображалась белая страница, и я получаю ошибку Chrome «не удалось загрузить». Это произошло потому, что реальный сайт, который я хочу посетить, был встроен в iframe, а заголовок x-frame-options имел значение «sameorigin» (реализовано с помощью Chrome DevTools). Это означает, что браузер будет блокировать запросы, когда я, например. хотите встроить https-вариант amazon.com на http-страницу, несмотря на то, что он был из того же источника.

К этому моменту я уже знал, что веб-сайты http были изменены случайным образом, поэтому был внедрен крипто-майнер, и фактический веб-сайт отображался в iframe со 100% высотой и 100% шириной в результате атаки «человек посередине». Но было неясно, была ли причиной этого моя сеть, мой компьютер, переходы маршрутизации или весь интернет-провайдер. Давайте создадим несколько тестовых случаев:

Эта команда будет получать и отображать содержимое веб-сайта amazon.com каждые 5 секунд и отображать его непосредственно в терминале. Итак, я обнаружил, что в итоге примерно каждый 15-й запрос был изменен. Это было очень удобно, потому что amazon.com, конечно же, не позволяет ему заходить на страницу напрямую через http в браузере. Они перенаправляют прямо на соответствующий вариант https. Я выполнил ту же команду на своем Raspberry PI (та же сеть), чтобы исключить заражение своего компьютера. И бум, та же проблема:

Итак, теперь давайте посмотрим на другие веб-страницы, если это также воспроизводится там. Итак, я проверил содержимое http-варианта amazon.com. И, как я и опасался, с самим amazon.com проблем не возникло. Это было воспроизведено на каждом веб-сайте, который использовал http://, например, ebay.com. Но amazon.com хорош для тестирования, потому что он установил заголовок, который запрещает встраивание в iframe (поэтому фактический вектор атаки не работает, да).

Другой возможной проблемой была моя локальная сеть. Поэтому я использовал внешний виртуальный сервер, чтобы снова проверить с помощью команды curl ответ http-варианта ebay и amazon. И это не было воспроизведено, как ожидалось.

На данный момент мы знаем, что это происходит только в моей сети. Поэтому после дальнейших исследований я выполнил трассировку до ebay.com и проверил переходы интернет-маршрутизации, которые пройдет мой запрос.

Первый переход, конечно же, мой локальный маршрутизатор. Следующие несколько, в данном случае 3, где скачки моего местного кабельного интернет-провайдера (ISP). После этого мы достигаем еще нескольких более крупных узлов и, в конце концов, проходим через маршрутизатор во Франкфурте прямо в инфраструктуру ebay в этом примере.

Как и на скриншоте выше (свернуть на amazon), мы увидели, что Mikrotik HttpProxy использовался для обслуживания запроса, мы обнаружили это через http-заголовок User-Agent. Так что я просто использовал curl в первых трех прыжках напрямую и получил тот же результат. Криптомайнер внедрялся с помощью запутанного JavaScript, и реальная страница отображалась в большом iframe размером 100% x 100%. Это также воспроизводилось за пределами моей сети, например. на виртуальном сервере.

Теперь я закончил более подробный анализ этой проблемы, поэтому я, например. использовали в этом случае другие браузеры и зашли на страницу ebay.com. В обоих браузерах загрузка процессора резко возросла, и процесс крипто-майнинга был очень активным. На этом снимке экрана видно, что Edge не может загрузить iframe из-за заголовка, но майнинг криптовалюты продолжается.

Это Chrome DevTools во время процесса крипто-майнинга. Порядок запроса был следующим:

Я напрямую связался со своим интернет-провайдером (TKN Deutschland), который стал жертвой такой атаки. Он исправил это напрямую, заменив маршрутизаторы Mikrotik в своей сети.

Для получения дополнительной информации ознакомьтесь со следующими ресурсами:

Я уже отправил отчеты о злоупотреблениях для доменов и могу успешно сказать, что они удалили srcip.com, который доставлял на 106 тысяч скомпрометированных маршрутизаторов Mikrotik.

Обновление от 16.10.2018: Некоторые хорошие хакеры удаленно пропатчили большинство уязвимых маршрутов Mikrotik через уязвимость CVE (статья в немецкой прессе).