Я забыл опубликовать эту статью 1 год назад, поэтому я опубликовал ее сейчас.
Давайте начнем с небольшого введения, как я это реализовал, а затем более технических деталей, чтобы вы лучше поняли.
Пишем 17 сентября 2018 года и я сижу дома за своим основным компьютером и готовлю презентацию на следующий день. Конечно, я провел небольшое исследование и посетил несколько других веб-сайтов, чтобы получить информацию. Во время исследования я заметил, что часть веб-страниц загружается некорректно. Вместо этого в браузере отображалась белая страница, и я получаю ошибку Chrome «не удалось загрузить». Это произошло потому, что реальный сайт, который я хочу посетить, был встроен в iframe, а заголовок x-frame-options имел значение «sameorigin» (реализовано с помощью Chrome DevTools). Это означает, что браузер будет блокировать запросы, когда я, например. хотите встроить https-вариант amazon.com на http-страницу, несмотря на то, что он был из того же источника.
К этому моменту я уже знал, что веб-сайты http были изменены случайным образом, поэтому был внедрен крипто-майнер, и фактический веб-сайт отображался в iframe со 100% высотой и 100% шириной в результате атаки «человек посередине». Но было неясно, была ли причиной этого моя сеть, мой компьютер, переходы маршрутизации или весь интернет-провайдер. Давайте создадим несколько тестовых случаев:
- смотреть -n 5 завиток http://amazon.com
Эта команда будет получать и отображать содержимое веб-сайта 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 во время процесса крипто-майнинга. Порядок запроса был следующим:
- фактическая страница была загружена, но скомпрометирована атакой mitm. Через JavaScript был внедрен следующий файл: hxxps://srcip.com/src.js
- Этот JavaScript добавляет на страницу еще один iframe, который загружает запутанный JavaScript через своего рода балансировщик нагрузки. Я называю это видом, потому что hxxps://www.hostingcloud.science./bOUb.js случайным образом перенаправляет на URL-адреса для полезной нагрузки: hxxps://www.hostingcloud.science./bOUb.js hxxps: //www.hostingcloud.faith./bOUb.js hxxps://www.hostingcloud.bid./bOUb.js hxxps://www.jshosting.trade./bOUb.js hxxps:// www.freecontent.party./bOUb.js
- Этот запутанный JavaScript является клиентом криптовалюты, который его добывает. Ключ (6a992967a4e9da78e3671393154923f17775bd5e9d86f11bce6d30bc6309244a) хранится на главной странице, которая напрямую обслуживалась.
- Насколько я понимаю, ключи или данные, которыми необходимо обмениваться во время майнинга криптовалюты, будут обслуживаться через HTTP-запросы в сервис-воркере.
Я напрямую связался со своим интернет-провайдером (TKN Deutschland), который стал жертвой такой атаки. Он исправил это напрямую, заменив маршрутизаторы Mikrotik в своей сети.
Для получения дополнительной информации ознакомьтесь со следующими ресурсами:
- https://badpackets.net/200000-mikrotik-routers-worldwide-have-been-compromised-to-inject-cryptojacking-malware/
- https://docs.google.com/spreadsheets/d/1RdT_r4fi4wPx5rY306FftVKaXiAZeQeb5fx78DmbVx0/edit?usp=sharing
- Статья Golem в немецкой прессе об этом конкретном случае с интернет-провайдером: https://www.golem.de/news/mikrotik-proxy-server-fuegen-kryptominer-ein-1810-137071.html
Я уже отправил отчеты о злоупотреблениях для доменов и могу успешно сказать, что они удалили srcip.com, который доставлял на 106 тысяч скомпрометированных маршрутизаторов Mikrotik.
Обновление от 16.10.2018: Некоторые хорошие хакеры удаленно пропатчили большинство уязвимых маршрутов Mikrotik через уязвимость CVE (статья в немецкой прессе).