Приключения Armada Collective в Украине

В костюм Санта Клауса был переодет один из участников коллектива Armada Collective; в мешке у дедушки был счет-фактура на 10 биткоинов откупных, которые предлагалось внести в течении трех дней. В случае неуплаты protection fee в отведенный срок, команда «Санта Клауса» обещала осуществлять перманентные DDoS-атаки мощностью вплоть до 1 Тбит/сек. и каждодневно удваивать сумму выкупа. Как уже стало понятно, данный вид угрозы – это вымогательство под угрозой нарушения доступности сервисов или DDoS-extortion, а Armada Collective – это коллектив, который специализируется на предоставлении такого рода услуг (за их плечами много «заслуг», но ссылки на них приводить здесь не будем). Мы не знаем, как настоящий Armada Collective защищает свой бренд, поэтому не исключаем возможности использования их «имени» самозванцами. В данной статье упоминания Armada Collective основаны на информации из предновогоднего письма, поэтому просим относиться к материалу с пониманием.

Рис. 1 

По состоянию на день получения письма 10 биткоинов составляли чуть больше 110 000 дол.США или, грубо, 3 000 000 грн. (это как сумма ежемесячной платы за Интернет от 30 000 клиентов). Вместе с тем, по состоянию на предполагаемый день расплаты, 10 биткоинов были эквивалентны 180 000 дол.США или, округленно, 5 000 000 грн. То ли предвестники Нового года не учли стремительности роста курса биткоина, то ли не взяли во внимание «прибыльность» украинского «провайдерского» бизнеса (а может, и то, и другое) – у жертвы присутствовала некая неопределенность: по какому курсу платить? Внесенная сумятица и не рыночная цена откупных сыграла свою роль – заработать Санта Клаусу под этот Новый год не удалось.

В данной статье хотелось немного осветить потенциальную угрозу осуществления распределенной атаки с целью вызова отказа в обслуживании, направленную не на приложения или сервисы, а на инфраструктуру провайдера. Статья основана на реальных событиях. Конечно же, в тот момент, когда происходит DDoS, не всегда успеваешь почитать статьи, но, возможно, кому-то и этот материал будет полезен.

Итак. После получения письма, исходя из изложенных обещаний вымогателей, было понятно, что жертва располагает как минимум тремя днями, чтобы собрать нужную сумму. Тем не менее, в тот же день, но ближе к вечеру, то бишь – в час пик «по-провайдерски», нагрузка на сеть возросла. Скорее всего, это часть маркетинговой стратегии Armada Collective – стимуляция потенциального клиента. Забегая наперед, отметим, что все 4 дня повышение количества трафика до аномальных объемов приходилось на временной отрезок 19:00 – 22:00 (в этот период провайдера мотивировали уже абоненты, вернувшиеся с работы).

Атака на сеть провайдера – это, скорее, штучное мероприятие, требующее предварительного изучения его инфраструктуры и определения её «слабых» мест. Как правило, на уровне абстракции, провайдер, предоставляющий доступ в Интернет абонентам – это несколько пограничных маршрутизаторов, транспортная сеть самого провайдера, объединяющая территориально распределенные площадки (региональные «ядра», узлы агрегации), а также – уровень доступа: активное сетевое оборудование и абонентов. Для создания проблем «на сети» атаку необходимо направить на образующее сеть оборудование, идентифицируемое (доступное) в сети Интернет, например, по IP-адресу. В этой связи отметим, что если «внешние» IP-адреса пограничного оборудования провайдера извне определить еще возможно, то IP-адреса интерфейсов маршрутизаторов, «смотрящих» в сторону абонентов, могут быть идентифицированы только изнутри сети провайдера (например, если с абонентского оборудования осуществить трассировку маршрута). В случаях с описываемыми ситуациями, атаки были направлены как раз на пограничные маршрутизаторы и маршрутизаторы уровня «ядра», а значит – злоумышленник осуществил предварительную разведку (держим это в уме). Забегая наперед, отметим, что использование маршрутизируемых, «честных», IP-адресов на оборудовании, образующем внутреннюю сеть провайдера, не обязательно и только приводит к расширению «диаграммы направленности» атаки (иными словами – чем больше хопов с «честными» IP-адресами между абонентом и пограничным маршрутизатором – тем обширнее может быть поле деятельности для атакующего).

Если, с позиции злоумышленника, перечень целей для атаки понятен, то, с точки зрения жертвы, при солидном размере сети и значительном объеме аномального трафика, процедура определения атакуемого IP-адреса/интерфейса превращается в настоящий challenge. В данном случае на помощь могут прийти:

• функционал самого оборудования (например, debug-режим, позволяющий видеть заголовки пакетов (а значит – IP-адреса), поступающих на процессорную обработку;
• возможности sflow/netflow, которые, однако (что следует учитывать), во время атаки могут просто не работать;
• статистика загруженности интерфейсов и определение IP-адресов последних (при должном учете устройств сети).

По отзывам провайдеров, исходя из журналов оборудования, были использованы такие техники осуществления DDoS’а:

1. Атака фрагментированными пакетами
2. BGP-flood
3. UDP-flood
4. DNS-flood
5. ICMP-flood

В общей сложности, в периоды атак объем аномального трафика составлял примерно 1,5 млн. пакетов в секунду (pps), что на три четверти соответствует заявленной мощности атаки – 1.9 млн. pps, при пересчете 1Тбит в pps (при минимальном размере пакета в 64 байта; понятно, что это зависит от протокола). Естественно, увеличение количества «прилетающих» пакетов, в некоторых случаях, приводило к нарушению доступности, так как оборудование было не в состоянии их обработать и выходило из строя.

В сети Интернет есть информация, касающаяся рекомендаций, направленных на противодействие DDoS-атакам. В то же время, практическая реализация этих рекомендаций не так очевидна и требует отдельного изучения возможностей оборудования и специфики функционирования сети. К примеру, достаточно непросто, не говоря про остроту необходимости, задокументировать атаку, записав, например, PCAP, в тот момент, когда вычислительная мощность оборудования почти исчерпана.

Исходя из профиля угрозы, построенного на основании имевших место атак на сети украинских провайдеров, можно рассмотреть возможность внедрения таких рекомендаций.

1. Ограничить количество «маршрутизируемых» IP-адресов, используемых на интерфейсах оборудования, реализующего «внутреннюю» сеть провайдера. Таким образом количество целей для атаки будет сокращено к IP-адресам интерфейсов пограничного оборудования.
2. Четко представлять устройство своей сети и знать IP-адреса инфраструктуро-образующего сетевого оборудования (зачастую, учитывая информацию в биллинге, предпочтение отдается «инвентаризации» сетевых адресов оборудования абонентов, в то время как адреса собственного оборудования, в виду их нерегулярной востребованности, упускаются из вида).
3. С помощью штатного (встроенного, в том числе, для защиты от DDoS) функционала пограничного оборудования, обеспечить перенастройку пороговых default-значений для разного типа протоколов и атак. Например, в случае с фрагментированными пакетами значение bandwidth установить в 20 (по умолчанию – 20 000). Это позволит ограничить количество фрагментов, помещаемых в буфер, прежде чем будет собран IP-пакет. В противном случае память, отведенная под буфер, может быть переполнена неполными фрагментированными дейтаграммами. Для разных устройств настраиваемые параметры могут иметь другие имена; цель – описать принцип.
4. С помощью штатного функционала межсетевых экранов и/или списков контроля доступа оборудования, ограничить перечень IP-адресов, с которых могут устанавливаться соединения на сетевой порт 179/tcp оборудования (как мера против BGP-flood’а).
5. Отработать и быть готовым применить механизм блокировки UDP-/DNS-/NTP-/SSDP-flood’а, и другого аномального трафика на IP-адреса оборудования провайдера, с помощью вышестоящего провайдера, для которого этот трафик будет являться транзитным, и, по сему, блокировка которого не повлияет на работу абонентов. Как вариант – подготовить и, в случае необходимости, применить механизм RTBH (Remotely-Triggered Black Hole), позволяющий в автоматическом режиме отсечь паразитный трафик на границе сети путем его перенаправления на псевдо-интерфейс, который не передает и не получает трафик (например, null0). В данном случае останется только оперативно определить IP-адрес, на который направлена атака (грубо говоря, придется "блек-холить" IP-адреса своего же оборудования).
6. Обеспечить доступность управляющего сегмента, разрешить доступ к интерфейсам управления только с доверенных IP-адресов.

Теперь касательно одного из членов команды Санта Клауса. Мысль о том, что атакующий проник в «тыл» и изучил сеть провайдера изнутри не давала покоя. Более детальное изучение журналов оборудования позволило определить некую коррелирующую аномалию – в преддверии атаки с одного из IP-адресов абонента в отношении внутреннего интерфейса как раз абонентского маршрутизатора были осуществлены попытки подключения как к SSH, что могло сойти за обыкновенный брутфорс, так и к BGP, что немного специфичнее. В случае с BGP, если быть точнее, то кто-то с IP-адреса абонента пытался представиться neighbor’ом (установить BGP-соединение) – с чего бы это?

При исследовании оборудования абонента оказалось, что IP-адрес назначен маршрутизатору ASUS, выступающему пограничным оборудованием и транслирующим сетевые порты определенных, использующихся абонентом, сервисов (1C, сервер баз данных и др.). Помимо всех прочих проблем, доступ к панели управления маршрутизатором извне ограничен не был. В то же время, при попытке зайти в панель управления ASUS’а, маршрутизатор сообщил, что «у него занято» – кто-то другой (при чем не абонент, как мы выяснили), из российского сегмента сети Интернет (г. Ростов-на-Дону), находился в «админке» устройства (рис. 2).

Рис. 2 

С IP-адреса 176.59.77.57, который находится в зоне ответственности провайдера TELE2, 11.12.2017 в 15:56:43 GMT+2 (в период +/- 10 минут) был получен несанкционированный доступ к оборудованию абонента (трафик шел на сетевой порт 8090/tcp). Исходя из нашего опыта исследований (по части перенастройки маршрутизаторов: от iptables до pptp вследствие их компрометации злоумышленниками), можем с достаточным уровнем уверенности предположить, что маршрутизатор абонента сыграл не последнюю роль в изучении инфраструктуры атакованного провайдера, так как злоумышленник мог использовать его в своих целях, в том числе, чтобы временно выдавать себя за абонента и «видеть» сеть провайдера изнутри.

Так как описанное касается сферы «кибер», мы не можем гарантировать, что существует связь между Armada Collective - 176.59.77.57 - Россия (Ростов-на-Дону), поэтому просим не манипулировать общественным мнением, ссылаясь на приведенную в статье информацию, потому как IP-адрес мог быть любым, в том числе, мог принадлежать скомпрометированному оборудованию абонента.

Если, вопреки конкурентности среды провайдеров, кто-то пожелает поделиться и своим опытом противодействия данным угрозам, мы с радостью добавим материал в статью.

На этом всё. Итог: Armada Collective, атака на инфраструктуру украинских провайдеров, выкуп в 10BTC, длительность - 4 дня (19:00 – 22:00), мощность - 1.5 Mpps.

P.S. Хотелось бы добавить, что провайдер это сродни "священной корове" - от его безопасности и благосостояния зависит безопасность потребителя. Никто не отменял такую урозу, например, как MiTM, посредством разных техник, в т.ч. BGP-hijacking. Провайдерам однозначно надо быть на чеку, так как, только из нашего опыта, в марте и июне этого года, наряду с десятками тысяч пострадавших организаций, особенно точечно злоумышленниками прорабатывались как раз некоторые провайдеры и операторы Украины, ставшие отдельным объектом заинтересованности атакующих.

Отдел реагирования на инциденты CyS Centrum (CyS-CERT)