Анализ TTL помог выявить источник DDoS-атаки на GitHub

Анализ TTL помог выявить источник DDoS-атаки на GitHub

Роберт Грэм (Robert Graham) из команды Errata Security, получивший известность как разработчик сверхпроизводительного DNS-сервера robdns и системы masscan, способной за пять минут просканировать порты всех хостов в Сети, опубликовал результаты исследования источника подстановки вредоносных JavaScript-блоков, применяемых для DDoS-атаки на GitHub.

Исследование подтвердило, что модификация трафика производится на оборудовании "Великого китайского файрвола" или в непосредственной близости от него, в частности в инфраструктуре магистральной опорной сети крупнейшего китайского провайдера China Unicom. Пока непонятно санкционирована ли атака китайскими властями или она стала возможной в результате взлома инфраструктуры сети China Unicom третьими лицами.

Для определения точки подстановки трафика был использован довольно интересный метод, основанный на анализе изменения TTL (поле в заголовке IP-пакета, уменьшаемое на единицу на каждом транзитном маршрутизаторе). Ранее, изучая атаку на GitHub, исследователи из компании Netresec обнаружили важные особенности работы с TTL на перехватывающем трафик MITM-узле. Подстановка используемых в атаке JavaScript-блоков осуществлялась только для пакетов с низким TTL ("пришедших издалека"), а подменённые в результате MITM-атаки пакеты снабжались с аномальном большим TTL, т.е. значение данного поля искусственно заменялось на большое значение, что явно выделяло прошедшие через MITM-прокси пакеты в общем потоке ответов от сервера, сообщает opennet.ru.

Например, проверочные пакеты к серверу Baidu, отправленные с TTL 64, достигают целевого хоста при TTL 46, т.е. по пути наблюдается 18 транзитных шлюзов. Но после отправки web-запроса, ответ приходит с TTL 98 или 99, что можно использовать как сигнал получения ответа от подставного сервера. Роберт Грэм решил воспользоваться данной аномалией и проследить на каком узле в цепочке передачи пакета происходит изменение TTL. Для этого им был подготовлен модифицированный вариант утилиты traceroute, отправляющий HTTP-запросы с изменённым TTL и отслеживающий пакеты об исчерпании времени жизни от маршрутизаторов.

Большинство систем выставляет по умолчанию для пакетов значение TTL 64, по мере прохождения маршрутизаторов значение TTL уменьшается и в момент достижения целевого хоста содержит своё минимальное значение, позволяющее оценить число транзитных маршрутизаторов по пути следования пакетов. Принцип действия утилиты traceroute сводится к том, что она вначале отправляет пакет с TTL=1 и, так как время жизни пакета истекает на первом шлюзе, получает от него ICMP ответ с отражением данного факта. Таким образом определяется первый узел по пути следования пакета. Затем проверки повторяются с TTL=2,3... до тех пор пока не будет получен положительный ответ, что будет сигнализировать достижение целевого хоста.

Особенностью созданного Робертом Грэммом мдифицированного варианта traceroute является то, что для анализа узлов за китайским межсетевым экраном вначале осуществляется установка HTTP-соединения с нормальным TTL, после чего начинается цикличная проверка с минимальными значениями TTL (1,2,3... и до достижения хоста). В один прекрасный момент при определённом TTL будет пройден весь путь следования пакета и получен положительный ответ. При этом полученное пошаговой проверкой число хопов будет отличаться от числа хопов, полученных в результате первого запроса (при пошаговой проверке 12, при прямом запросе 94).

 

 

Появление ответа при запросе с TTL значительно ниже возвращённого при первой проверке эталонного TTL будет свидетельствовать о достижении MITM-прокси. IP-адрес с которого был получен последний ответ об истечении времени жизни пакета можно считать адресом MITM-прокси. В данном случае MITM-прокси находится в сети оператора China Unicom. Примечательно, что обратная проверка через запуск traceroute из Китая к запрещённому в Китае внешнему ресурсу, показывает, что пакеты блокируются в инфраструктуре China Unicom.

Распространяется схема скрытого захвата аккаунтов WhatsApp — GhostPairing

В мессенджере WhatsApp (принадлежит признанной в России экстремистской организации и запрещённой корпорации Meta) набирает обороты схема мошенничества, которая выглядит совсем не как взлом. Никаких краж паролей, подмены сим-карт или тревожных уведомлений. Напротив — всё происходит тихо и почти незаметно. Пользователь сам даёт злоумышленнику доступ к своему аккаунту, считая, что просто проходит безобидную проверку.

Исследователи из Avast называют эту атаку GhostPairing — и она начинается с максимально простого сообщения. Обычно жертве пишет кто-то из знакомых в WhatsApp:

«Привет, я тут нашёл твоё фото».

 

Ничего подозрительного — обычный контакт, короткая фраза и ссылка. Многие нажимают, не задумываясь.

По ссылке открывается страница, визуально очень похожая на Facebook (принадлежит признанной в России экстремистской организации и запрещённой корпорации Meta): знакомые цвета, логотип, привычная структура. Сайт сообщает, что для просмотра фото нужно пройти «верификацию». И вот здесь пользователь попадает в ловушку.

 

На самом деле страница не имеет никакого отношения к Facebook. Её задача — аккуратно провести человека через официальный процесс привязки нового устройства к WhatsApp. Тот самый, который используется для WhatsApp Web или десктопной версии.

Схема чаще всего задействует вариант с числовым кодом, потому что он выглядит как стандартная мера безопасности и не требует второго устройства. Механика простая: сайт просит ввести номер телефона, WhatsApp присылает настоящий код привязки, а фейковая страница предлагает ввести его «для продолжения». Пользователь вводит код — и устройство злоумышленника тихо добавляется в список связанных.

Пароль никто не крадёт. Защита не взламывается. С точки зрения WhatsApp всё выглядит корректно — доступ был одобрен владельцем аккаунта.

После этого атакующий получает почти тот же уровень доступа, что и при использовании WhatsApp Web. Он видит синхронизированные чаты, получает новые сообщения в реальном времени, может читать фото, видео и голосовые сообщения, а также писать от имени жертвы. При этом сам смартфон продолжает работать как обычно, без ошибок и предупреждений.

Самое неприятное — пользователь может неделями не подозревать, что к его аккаунту подключено «призрачное» устройство. Злоумышленник просто наблюдает: читает переписки, изучает стиль общения, смотрит, кто с кем и о чём говорит.

Дальше схема масштабируется сама собой. Захваченный аккаунт начинает рассылать то же самое сообщение контактам жертвы — в семейные чаты, рабочие группы, друзьям. Так как сообщение приходит от знакомого человека, доверие срабатывает автоматически. Кто-то игнорирует, но кто-то обязательно нажимает. Этого достаточно, чтобы атака распространялась дальше без массового спама и случайных рассылок.

Опасность GhostPairing в том, что она использует возможности WhatsApp именно так, как они задуманы. Атака не блокирует аккаунт, не привлекает внимание и не требует сложных технических приёмов. Связанные устройства остаются активными, пока их не удалят вручную.

Защититься от этого, к счастью, несложно. Стоит регулярно проверять список связанных устройств в настройках WhatsApp. Если там есть что-то незнакомое — немедленно отключить. Любые просьбы ввести код или отсканировать QR-код «для просмотра контента» должны настораживать: привязка устройств в WhatsApp должна происходить только по инициативе самого пользователя. Также полезно включить двухэтапную проверку и, по возможности, предупредить близких — такие схемы отлично работают именно на незнании.

История с GhostPairing — это не только про WhatsApp. Всё больше сервисов используют быстрые сценарии привязки устройств через коды и подтверждения. Когда такие действия выглядят слишком привычно и просто, ими начинают злоупотреблять.

Напомним на днях в Сеть попал инструмент, который позволяет отслеживать активность пользователей WhatsApp.

RSS: Новости на портале Anti-Malware.ru