Анализ 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.

Подпишитесь на новости

Главной целью стратегии ИБ стало снижение рисков — 78% против 55% год назад

Компании всё чаще берутся за стратегию ИБ, но писать её мешает нехватка данных и поддержки руководства. Об этом говорят опросы зрителей эфира AM Live «Стратегия информационной безопасности: зачем нужна и как её защитить».

В ходе дискуссии эксперты разбирали, зачем бизнесу стратегия ИБ, как связать её с бизнес-целями, что такое риск-аппетит и недопустимые события, как отличить стратегию от списка закупок и как доказать её ценность руководству.

Ярослав Напалков (МТС Банк) поделился кейсом, как презентация стратегии топ-менеджеру вызвала агрессию, и посоветовал сначала доносить контекст. Николай Казанцев (Securitm) предложил новичкам «три чашки кофе» — пообщаться с CEO, ИТ и стейкхолдерами.

Эксперты также обсудили горизонт планирования (2-3 года с ежегодным пересмотром), роль резервного копирования и киберучений, кейсы с шифровальщиками, BYOD, DLP и построением SOC.

За год доля компаний, у которых стратегия в разработке, выросла с 9% до 28%. А тех, у кого её нет и не предвидится, стало меньше — 21% против 26%. При этом меньше компаний довели документ до рабочего состояния с метриками и кибериспытаниями: 16% против 20%.

Барьеры тоже сместились. Нехватка исходных данных выросла с 46% до 64%, отсутствие buy-in топ-менеджмента — с 25% до 43%. Кадровый дефицит остаётся главным ограничением, хотя и снизился до 59%. Николай Казанцев из Securitm объясняет это зрелостью рынка:

«По нашей статистике, лишь 15-20% служб ИБ имеют хоть как-то формализованный реестр рисков. Я даже не говорю про количественный, хотя бы качественную оценку».

Главной целью на 2027 год снижение рисков и финансового ущерба назвали 78% — рост на 23 п.п. На втором месте устойчивость и сокращение простоев критичных сервисов — 57%. Наталья Глинина из Megafon Pro Business считает это логичным:

«Нормальная цель, потому что она прямо влияет на бизнес. Финансовый ущерб считается недопустимым событием, потому что иначе ваш бизнес может перестать работать».

Соответствие регуляторам держится на уровне 59%, а оптимизация TCO и консолидация стека теряют популярность — 8% против 14%.

Оптимизм по поводу роста интереса к стратегии разделяют не все. Евгений Акимов из «Рубитеха» предположил:

«Просто те, кто были на эфире в 2025 году, разработали стратегию и на наш эфир уже не пришли. Просто новые люди, которые как-то голодны до стратегии».

А ведущий Виктор Бобыльков напомнил, что часть компаний сознательно живёт без документа:

«Одно дело, когда бюджета нет, тогда хотя бы есть исходные данные. Но мы просто не делаем стратегию, потому что смысл её делать, нам денег больше не дадут. Это стратегия стабильной оперейшн».

Участники эфира сошлись на том, что стратегия ИБ — это не список закупок, а инструмент связи с бизнес-целями, который нужно строить на риск-ориентированном подходе. Планировать стоит на 2-3 года с ежегодным пересмотром, фокусироваться на критичных процессах и восстановлении, а ответственность распределять между ИБ, ИТ и бизнесом.

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