web-dev-qa-db-ja.com

Netgearルーターはポート32764でリッスンしていますか?

ファームウェアV5.01.01を実行しているNetgearDG834Gがあります。 LAN側からは、ポートスキャンすると、tcpポート32764でリッスンしています。このポートにtelnetで接続しようとすると、応答MMcS\xff\xff\xff\xff\0\0\0\0(16進数で明らかに)が返されます。

UPnPが無効になっていて、リモート管理ポートではなく、WAN側で開いていません。Netgearのドキュメントに何も見つかりません。オンラインで検索しても、何も見つかりません。気付いた人もいますが、実際には誰も答えを持っていません。そのポートへのアウトバウンドアクセスをブロックするファイアウォールルールも作成しましたが、まだ開いているので、実際にそれをリッスンしているのはルーターです。

誰かがこれが何であるか知っていますか?

13
Dentrasi

うーん、変だ。

16進数ff = 10進数255なので、論理的には、受信する応答は次のようになります。

MMcS 255.255.255.255 0.0.0.0(ネットワークをわかりやすくするためにドットを追加)これは、基本的にネットワーク上のブロードキャストアドレスです。ネットワーク上のanyipがMMCSサービス、つまり255.255.255.255ネットマスク0.0.0.0を使用できることを示している可能性があります。

MultiMedia Class Scheduler など、MMCSには、ネットワーク上のマルチメディアトラフィックの優先順位を取得するためにVistaが使用できるものがいくつかあります。ポートがローカルネットワークでも開いている理由を説明します。

このページ の最初の投稿のポイント5に関する情報もあります

それが MIP-MANETセルスイッチング と関係があるのではないかと思います。これは携帯電話ネットワークと関係があるようです。グーグルで MMCS 255.255.255.255 の場合に返される奇妙なものがいくつかあります。のように this

したがって、Windowsマルチメディアクラススケジューラがルーターと通信してトラフィックに優先順位を付けることができるポートである可能性が高いと思いますが、奇妙なファンキーな携帯電話ネットワークのものである可能性があります。

4
Mokubai

実際、これは、説明されているように製造元に含まれているソフトウェアのバックドアのようです ここ そして このスクリプト を使用して悪用できます。

これまでのところ、ベンダーに関係のない人は、Linksys WAG200G、Linksys WAG320N(ファームウェアV1.00.12)、およびNetgearDM111Pのルーターにバックドアがあると報告しています。ただし、Netgear DG834、DG834G WPNT834 DG934、WG602、WGR614ルーター、Linksys WAG160NおよびDGN2000、WAG120Nワイヤレス-WRVS4400Nのデバイス(お客様を含む)も存在する可能性があります。このバックドアは他のデバイスにも存在する可能性があります。

17
NULLZ

これは [〜#〜] mips [〜#〜] ファームウェアのアップグレードに使用されるSerComm製造のルーターおよびホームゲートウェイデバイス(Linksys、Netgear、Cisco)に存在するポートです。

これは、ポート32764でリッスンしているscfgmgrプロセスによって管理されます。

Telnet経由でアクセスすると、プレフィックスがScMMまたはMMcS(システムのエンディアンに応じて)のデータが返されるようです。

これは、ヘッダー(0xCバイト)の後にペイロードが続く非常に単純なバイナリプロトコルです。

ヘッダー構造:

typedef struct scfgmgr_header_s {
    unsigned long   magic;
    int             cmd;
    unsigned long   len;
} scfgmgr_header;

これは、Cisco GPLソースに基づいています(例:廃止されたftp-eng.Cisco.comのwap4410n_v2.0.1.0_gpl.tgz)。

実際の情報については、 elvanderbの説明とサンプルPython code を参照してください。


現在、デバイスへのフルアクセスを提供できるヒープベースのバッファオーバーフローで有名です( バックドア )。これは2013年のクリスマスに Eloi Vanderbeken によって発見されましたが、おそらく2008年に中国のハッカーに知られていました( cgi file )。

作業方法は次のとおりです。

ヒープベースのバッファオーバーフロー:

Heap based buffer overflow

メッセージ:

Messages

したがって、単純なオーバーフローメッセージを使用すると、多くの興味深い詳細が得られます。

screenshot - WiFi username and password

ただし、これにより構成がリセットされる可能性があるため、自宅で行わないでください。

このポートを介して実行されるルーターによって実行されるいくつかの逆コマンドを次に示します。

  1. nvram-ダンプ構成。

  2. get var-構成変数を取得します

    スタックベースのバッファオーバーフローの可能性(変数がユーザーによって制御されている場合)

  3. set var-構成変数を設定します

    スタックベースのバッファオーバーフロー、出力バッファ(サイズ≈0x10000)がスタック上にあります。

  4. commit nvram-/tmp/nvramからnvram/dev/mtdblock/3を読み取り、CRCを確認します

    / tmp/nvramからnvram(/ dev/mtdblock/3)を設定します; CRCを確認してください

  5. ブリッジモードをオンに設定します(わからない、テストする時間がありませんでした)

    nvram_set(“wan_mode”, bridgedonly)
    nvram_set(“wan_encap”, 0)
    nvram_set(“wan_vpi”, 8)
    nvram_set(“wan_vci”, 81)
    system(“/usr/bin/killall br2684ctl”)
    system(“/usr/bin/killall udhcpd”)
    system(“/usr/bin/killall -9 atm_monitor”)
    system(“/usr/sbin/rc wan stop >/dev/null 2>&1”)
    system(“/usr/sbin/atm_monitor&”)
    
  6. 測定されたインターネット速度を表示する(ダウンロード/アップロード)

  7. cmd(うん、それはシェルだ…)

    • 特別なコマンド:

      • 終了、さようなら、終了->終了...(生きている= 0)
      • cd:ディレクトリの変更(少しWTF)
    • その他のコマンド:

      • stdout処理での整数オーバーフロー(?)は悪用できませんが、それでも.。
      • cmd出力でのバッファオーバーフロー(同じバッファを再度)…
  8. ファイルの書き込み

    • ペイロード内のファイル名
    • ルートディレクトリ=/tmp
    • ディレクトリトラバーサルが可能かもしれません(テストされていませんが、open(sprintf(“/tmp /%s”、payload))…)
  9. 返品バージョン

  10. モデムルーターのIPを返す

    • nvram_get(“ lan_ipaddr”)
  11. デフォルト設定に戻す

    • nvram_set(“ restore_default”、1)
    • nvram_commit
  12. / dev/mtdblock/0を読む[-4:-2]

    • それが何であるかわからない、私はそれをテストする時間がなかった
  13. nvramをディスク(/ tmp/nvram)にダンプし、コミットします

出典: (スライドショー)Linksysが私のクリスマスをどのように救ったか!


通常、この種のポートは、公式には [〜#〜] iana [〜#〜] である必要があります。

これは nSpawn このポートに関連して2007年にLinuxQuestionsで返信したものです:

正式にIANAによって割り当てられたポート(0から約30000までの番号)の場合、その番号は/ etc/services内のサービス( 'getent services portnumber')、NmapまたはSansのISCのようなオンラインデータベース。

エフェメラルポートの使用は、/proc/sys/net/ipv4/ip_local_port_rangesysctlを使用してローカルで構成できることに注意してください。以前のデフォルトは1024-5000でした。サーバーの場合、32768-61000の値が使用され、一部のアプリケーションでは1025-65535のようなものが必要です。

また、これらは静的な番号からサービスへのマッピングであり、たとえば/ etc/servicesはTCP/22がSSHに一致すると表示しますが、特定の状況ではそうである必要はありませんが、

それ以外の場合、どのプロセスがそれにバインドしたかわからないポートの場合は、ホストにアクセスできる場合は、netstat -anplsof -w -n -i protocol:portnumber、またはfuser -n protocol portnumberを使用して問い合わせることができます。これが最も正確な方法です。

それ以外の場合は、ホストにアクセスできない場合は、たとえばtelnetでホストに問い合わせることができます。これは正確な方法ではありません。侵害されたホストの場合は、侵入者に警告することができます。

参照:

1
kenorb