AI製のRevshell PoC
AI製Redishell PoCの未検証の完成版。
オリジナルPoC:
https://github.com/raminfp/redis_exploit/blob/main/exploit_poc.py
韓国のピース:
https://github.com/dwisiswant0/CVE-2025-49844/blob/master/CVE-2025-49844.lua
その後、GDBを接続して調査を進め、ベースアドレスを取得し、さらにいくつかのことを突き止めました。しかし、結局のところ、これは単純なヒープ脆弱性ではないようです。何を試してもコード実行は不可能でした。クラッシュするか？はい。コマンド実行？いいえ。
私たちはリバースエンジニアリングにそれほど精通しているわけではないので確信は持てませんが、数時間かけて最強クラスのAIモデルの助けを借りて見つけたすべての情報から判断すると、この脆弱性を介してコード実行を達成することは不可能です（あるいは、1000回に1回の偶然が起こるかもしれませんが、それは完全な推測にすぎません）。
数多くの試行を通じて、私たちが到達できたのはせいぜい次のような状況です:
Script attempted to access nonexistent global variable 'print' script: 67dfac1cecac4f99df897c7a0713f1d6fcef69a4, on @user_script:21.
コード実行が可能な本物のPoCを見てみたいものです。
よく読んでください。私たちが言ったのは「今のところ知っている/見てきた限りでは」ということです。これは絶対的な主張ではなく、考慮していなかったトリックやタネがあるかもしれません。世の中にはもっと優れたBinExersがいます。
なお、Redisサーバーは安定したままでした。テストのためにDockerから取り出しました。エクスプロイトを数千回発射することでクラッシュを誘発できます。このブルートフォース方式とコード実行の試みを組み合わせるのはまだ試していませんが、それが解決策かもしれません。
ご覧のとおり、オリジナルのPoCも同じ問題を抱えているようです。「簡略化」されたと主張していますが、結果が何を意図しているのかは完全には明らかではありません。
まだ何も...
$ while redis-cli -h localhost -p 6380 --eval korean.lua; do printf '.'; done
不思議なことに、Redisのパッチノートにはまったく別のCVEが記載されています。これもバイナリエクスプロイトの一種とされていますが、はるかに単純で、スタックベースのバッファオーバーフローであり、RCEが可能とされています：
XACKDEL のバグがスタックオーバーフローと潜在的なRCEを引き起こす可能性これに関する情報はさらに少ないことがわかりました。自己コンパイルなしにバックポートされていないバージョンを見つけるのはすでに困難ですが、おそらくそれが私たちが取らなければならない道なのでしょう。
これらすべての POTENTIALS - 私には可能性がある。今や可能性が2つになった。
62507 が有力だ...まだRCEはないが、簡単で有望に見える...
では、CVE-2025-49844は単なる策略だったのでしょうか？韓国のパズルはまだクラッシュを生み出していません。しかし、自己コンパイルした8.2.2に対してはまったく異なる出力を生成します。認めざるを得ませんが、私自身も「そうだ、クラッシュする、十分あり得る、おそらく簡単だ...」と考え、CVE-2025-49844のクラッシュ部分は機能するだろうと決めつけていました。しかし、それは決して起こりませんでした。以前、間違ったことを言ってすみません。しかし、これで明確になったはずです。CVE-2025-49844はクラッシュせず、CVE-2025-62507はクラッシュします。
.(error) ERR user_script:16: Script attempted to access nonexistent global variable 'newproxy' script: 859491190bfb66357ec83aee16eb0554967c9c38, on @user_script:16.
見覚えがあるだろうか？ 彼らがそこで何をしたのかはわからない... それとも私以外に誰も確認していないのだろうか？ 最近の世界はかなり奇妙な場所になった。