CVE-2026-76070: Netis NC63 の login.cgi における Base64 デコード後のパスワードを介した未認証・事前認証スタックバッファオーバーフローによる RCE

研究者: Özcan Ersan (@ozcanpng)

開示ステータス

• CVE: CVE-2026-76070
• ベンダー: Netis Systems Co., Ltd.
• 製品: Netis NC63 Wireless AC1200 ルーター
• テスト済みファームウェア: NC63_V3.0.0.3327
• 影響を受けるコンポーネント: /bin/netis.cgi
• エンドポイント: POST /cgi-bin/login.cgi
• パラメータ: Base64 エンコードされた password
• 認証: なし。安全でないデコードは資格情報の比較前に発生します
• アーキテクチャ: MIPS32r2 リトルエンディアン、o32 ABI、uClibc
• 脆弱性クラス: 保存された戻りアドレスを制御可能なスタックベースのバッファオーバーフロー
• 検証: 隔離された QEMU ユーザーモードランタイムにおけるオリジナルハッシュの本番 CGI
• 準備時点の CVE レコード状態: 採番済み。CNA レコード詳細は記入待ち

エグゼクティブサマリー

Netis NC63 ファームウェア V3.0.0.3327 の公開ログインハンドラは、攻撃者が制御する password パラメータを取得し、カスタム Base64 ルーチン FUN_00402bd4 でデコードします。呼び出し元は 64 バイトのローカルスタックバッファを用意しますが、その容量をデコーダに渡しません。デコーダはエンコードされた入力から処理量を導出し、宛先の終端をチェックせずにデコード済みバイトを書き込みます。

保存された MIPS 戻りアドレスは、デコード済みバッファの先頭から 136 バイトの位置にあります。オリジナルハッシュの本番 CGI に対する動的テストでは、以下が確認されました。

1. 140 バイトの B パターンをデコードすると 0x42424242 でフォールトが発生する。
2. 保存された ra を 0x0041a2e0 に置き換えると、ログインハンドラへの 2 回目のエントリが観測され、プログラムカウンタ制御が証明される。
3. 隔離された観測専用テストでは、攻撃者が選択した MIPS a0 値で元のバイナリの直接の system() 呼び出しに到達する。置き換えた /bin/sh は /bin/sh -c NC63_RCE_PROOF を記録したが、コマンドは実行しなかった。

このリポジトリの公開 PoC は、意図的にクラッシュパターンで停止します。リターンチェーン、シェルコード、コマンド、リバースシェル、永続化は一切含まれていません。

影響を受けるアーティファクトの整合性

193f6a5e2ce65972b1805bf076f8d3521379a8441c8aaeb5ad0ba174bbee0792  netis_NC63_V3.0.0.3327.bin
23faa747b7d2f067aa5431bcc227ceca97a7977cf3e7c372f715cbba57f9209b  squashfs-root/bin/boa
eb298774c27070dc595fefcabb4e8c12a46cb5f4fd08f91c3ca92282c3a289a2  squashfs-root/bin/netis.cgi

動的テストに使用した /bin/netis.cgi のコピーは、ベンダー抽出された実行ファイルと同じ SHA-256 です。

攻撃対象領域と認証状態

ベンダーのフロントエンドは、パスワードを Base64 として公開エンドポイントに送信します。

obj.password = base64encode(utf16to8(password));
request({
    url: "/cgi-bin/login.cgi",
    data: obj
});

HTML フィールドは maxlength="63" を使用していますが、これはブラウザ側の制限にすぎません。直接の HTTP クライアントは、より大きなエンコード値を送信できます。

login.cgi は認証前に到達可能である必要があります。安全でないデコードは、デコードされたパスワードが設定済みの管理者パスワードと比較される前に発生します。有効なセッション、Cookie ヘッダー、Authorization ヘッダー、正しいパスワードは一切必要ありません。

ソースからシンクへのトレース

Unauthenticated HTTP client
  |
  | POST /cgi-bin/login.cgi
  | password=<attacker-controlled Base64>
  v
/bin/netis.cgi: FUN_0041a2e0
  |
  | get_request_param("password")
  v
FUN_00402bd4(decoded_stack_buffer, encoded_password)
  |
  | no destination-capacity argument
  | decoded output exceeds 64 bytes
  v
saved s8 at decoded offset 132
saved ra at decoded offset 136
  |
  v
attacker-selected MIPS PC

脆弱なコード

Ghidra から導出した擬似コード（可読性のために名前を正規化済み）:

int login_cgi(void *request)
{
    char decoded[64];
    char stored[68];
    char *password;

    memset(decoded, 0, 64);
    memset(stored, 0, 64);
    password = get_request_param(request, "password");
    if (password != NULL)
        FUN_00402bd4(decoded, password); /* no capacity argument */

    apmib_get(0x15e, stored);
    if (strcmp(decoded, stored) == 0)
        printf("[\"SUCCESS\"]");
    else {
        system("echo 0 >/tmp/boa_auth");
        printf("[\"%d\"]", 0x15);
    }
    return 0;
}

FUN_00402bd4 のデコーダは、宛先ポインタとソースポインタのみを受け取ります。そのループは宛先ポインタを進め、Base64 シンボル 4 つごとに最大 3 バイトのデコード済みバイトを格納します。宛先を decoded + 64 と比較するチェックはありません。

Base64 は入力変換であり、根本的な欠陥ではありません。根本原因は、攻撃者が制御するデコード済み長さと、容量が一切強制されない固定サイズの宛先との不一致です。通常のパディング付き入力では、エンコードされた 4 文字が最大 3 バイトのデコード済みデータを表すため、サーバー側のチェックでは書き込み前にデコード済みサイズを計算して検証する必要があります。

スタック破壊の分析

FUN_0041a2e0 は 0x0041a2e0 で始まり、0xa8 バイトのフレームを作成します。

0041a2e0  addiu sp,sp,-168
0041a2e4  sw    ra,164(sp)
0041a2e8  sw    s8,160(sp)
0041a2ec  move  s8,sp

デコード済みデータの宛先は s8+0x1c から始まります。保存された s8 と ra はそれぞれ s8+0xa0 と s8+0xa4 にあります。

decoded[64]  s8+0x1c   decoded offset 0
saved s8     s8+0xa0   decoded offset 132
saved ra     s8+0xa4   decoded offset 136

正確な戻りアドレスまでの距離は 0xa4 - 0x1c = 0x88、すなわち 136 バイトです。

動的検証

保存された戻りアドレスの上書き

140 バイトのデコード済み B パターンが、4 バイトの保存された戻りアドレスを置き換えました。

--- SIGSEGV {si_signo=SIGSEGV, si_code=1, si_addr=0x42424242} ---
qemu: uncaught target signal 11 (Segmentation fault)

プログラムカウンタ制御

別の 140 バイト入力は、保存された ra を 0x0041a2e0 に設定しました。QEMU CPU トレースは、通常の最初のハンドラエントリに続き、s8=0x41414141 および ra=0x0041a2e0 を持つ 2 回目のエントリを記録しました。

観測専用のコマンド境界

元のバイナリには、0x0041a3cc に直接の jal system があります。非公開の隔離検証では、既存の固定ベース命令が a0 にマーカーをロードし、その呼び出しに到達しました。静的観測プログラムが /bin/sh の上にマウントされ、コマンドインタープリタの引数を記録し、何も実行しませんでした。

argv[0]=</bin/sh>
argv[1]=<-c>
argv[2]=<NC63_RCE_PROOF>
CONTROLLED_MARKER_REACHED
PASS: attacker-controlled a0 reached system() and /bin/sh argv.
PASS: the guard logged the request and executed no command.

これは、隔離された本番コードパスにおける RCE プリミティブを実証するものです。展開されたカーネルとスタックランダム化構成の下での物理ルーター上で、同一のエクスプロイト信頼性を確立するものではありません。

権限とバイナリハードニングの状況

元の Boa 設定は、User root、Group root、および /bin と /web/cgi-bin を含む CGI パスを指定しています。本番実行ファイルは固定ベース (0x00400000) であり、スタックカナリアや RELRO はなく、RWX セグメントを持つ実行可能な GNU スタックを宣言しています。

安全な公開 PoC

同梱のスクリプトはデフォルトでドライラン モードであり、デコード後に 140 バイトの B を含む Base64 フォームボディを生成するだけです。

python3 poc/poc.py

送信には、明示的な許可済みターゲットと --send が必要です。

python3 poc/poc.py --target http://192.168.1.1 --send

パターンを送信すると CGI プロセスがクラッシュする可能性があります。許可された使い捨て環境でのみ使用してください。この PoC は、非公開の RCE 検証チェーンを実装していません。

影響

悪用に成功すると、ルーター管理コンテキストで攻撃者が選択したコードやコマンドを実行できます。元の Boa 設定では、このコンテキストは root として実行されます。潜在的な影響には、設定情報や秘密情報の漏えい、DNS/ファイアウォール/ルーティングの操作、トラフィックのリダイレクト、サービスの中断、デバイスの完全な乗っ取りが含まれます。

対策

1. カスタムデコーダを、宛先容量を受け取る API に置き換える。
2. 計算されたデコード済み長さが 63 バイトを超える入力を拒否し、終端文字用の領域を確保する。
3. デコード前に、サーバー側で長さと Base64 構文を検証する。
4. FUN_00402bd4 のすべての呼び出し元を監査する。
5. スタックカナリア、PIE、NX、RELRO を有効にして再ビルドする。
6. CGI プロセスを最小権限で実行する。

証拠の索引

スクリーンショットとトレースの対応については evidence/README.md を参照してください。正規化された Ghidra 抜粋は attachments/decompiled-functions/ にあります。

開示のタイムライン

• 2026-08-16: 発見と隔離された本番バイナリでの検証が完了。
• 2026 年 8 月: VulnCheck に報告。
• 2026-08-20: VulnCheck が CVE-2026-76070 を採番し、公開開示を許可。
• 2026-08-20: 公開開示パッケージが公開。

参照

• CVE-2026-76070
• VulnCheck
• Netis NC63 サポートページ
• CVE-2026-73673

物理ルーターへのフラッシュは行われていません。実際のシェルコマンド、リバースシェル、永続化、外部接続、認証情報の窃取、破壊的なファームウェア操作は一切使用されていません。