今週のセキュリティ: Cacti RCE

今週は、システム管理者にとって本当に苦痛になる可能性のあるリモート コード実行 (RCE) の脆弱性から始めます。 システム監視およびグラフ作成ソリューションである Cacti には、HTTP/S ポートへの認証されていないアクセスを持つ攻撃者が簡単に bash コマンドを実行できるように連鎖する一対のバグがあります。 この攻撃の前半は認証バイパスであり、恥ずかしいほど簡単です。 Cacti 認証コードは、 Forwarded-For: リクエストのヘッダー。 それをサーバーの IP に設定すると、認証コードはそれをローカルホスト要求のように扱い、実際の認証プロセスをバイパスします。

後半は remote_agent.php エンドポイント、 poller_id ユーザーによって設定され、文字列として扱われます。 次に、正しい場合 host_idlocal_data_id アイテムがトリガーされると、その文字列は連結されて proc_open() 関数呼び出し。 文字列はサニタイズされていないため、実行する 2 番目のコマンドを含めるだけで十分です。たとえば、webshel​​l をドロップします。

Cacti のバージョン 1.2.23 に修正が含まれ、2 日にリリースされました。 これは悪用される可能性が高く、自動化された悪用がまだ開始されていない場合は、すぐに悪用される可能性があります。 そのため、Cacti をインストールしている場合は、インターフェイスが外部に公開されていないことを再確認してください。

JSON Web トークン

Unit 42 の研究者は、JsonWebToken プロジェクトで RCE を達成するために使用できるエクスプロイトを発見しました。 問題はこのライブラリの verify() この関数は、チェックするトークン、使用するキー、およびオプションの引数を取ります。 options オブジェクトにアルゴリズムが指定されていない場合、キーは PEM 文字列として処理されます。 お茶 toString() そのキーのメソッドは実際のチェック中に呼び出され、文字列またはバッファのいずれかであると想定されています。 しかし、キーが verify() 関数は実際には複雑なオブジェクトであり、独自のものを持ってきました toString() プレイする方法に沿って。 その時点で、任意のコードが実行されます。 そして、このコードがサーバー側で実行されている場合 node.js、それはポップされたサーバーを意味します。

しかし、待ってください、それほど単純ではありませんよね? 有効な JWT に任意のオブジェクトを含めることができるわけではありません。それ自体が問題になります。 したがって、CVE-2022-23529 は踏み台です。 これは安全でないコードですが、この脆弱性に到達するには、アプリケーションの残りの部分に別の脆弱性が必要です。

SCOTUS が NSO を検討

米国の最高裁判所が声明を出すことを拒否することにより、決定的な声明を出したので、私たちはめったに政治的な話に目を向けていません. WhatsAppはNSOグループに対する訴訟を進めており、NSOは、彼らのすべての行動は正当な政府の代理人として取られたものであり、訴訟に対する免除を与えるべきであると主張しています. 第 9 巡回裁判所は、この抗弁はばかげていると判断したため、NSO は当然、最高裁判所に上訴しました。 審理を拒否することで、最高裁判所は、下級裁判所の判決が有効であるべきであるという声明を送信します。これは、訴訟が進行することを意味します。 この訴訟の過程で、いくつかの興味深い詳細が明らかになるはずです.

SBOMとVEX

Software Bill of Materials (SBOM) は最近よく使われるバズワードですが、このコラムではまだその概念について詳しく見ていません。 このアイデアは、ハードウェア ビルドに付属する可能性のある伝統的な部品表に基づいて、しばらく前からありました。 SBOM は、ソフトウェア ソリューションの一部であるライブラリとバイナリの単なるリストです。 理想は、企業がすべてのソフトウェアおよびアプライアンス ソリューションに対して SBOM を持ち、公開された CVE にさらされているかどうかを自動的にチェックできることです。

素晴らしいように聞こえますが、残念ながら、思ったほど単純ではありません。 上記の Chainguard の記事は、主に Vulnerability Exploitability eXchange (VEX) ドキュメントに関するものです。これは、脆弱性の影響を受けない製品を宣言するための標準化された形式です。 それでは、上記の JWT の脆弱性を見てみましょう。 特定のソリューションに脆弱な JWT ライブラリが付属している場合がありますが、ソフトウェア エンジニアは問題とライブラリの使用方法を調べ、ソリューションが実際には脆弱ではないことを証明します。 VEX ドキュメントが作成され、SBOM データベースに追加され、自動化された脆弱性スキャン ソリューションは、そのソリューションの脆弱性を無視することを認識します。

ブラウザ内の TikTok VM

JavaScript はすべてオープン ソースですよね? これは、消費者のブラウザーで実行されるインタープリター言語であるため、定義上、少なくともソースは利用可能です。 ただし、多くのサイトでは、JS コードを難読化して完全に判読できないようにするために、あらゆる手段を講じています。 そして、難読化の現在のチャンピオンは TikTok でなければなりません。 [Ibiyemi Abiodun] による以前の取り組みに基づいて、そのコードのリバース エンジニアリングにしばらく時間を費やしました。 [Veritas].

そしてそれは深い魔法です。 babel を使用していくつかの手順で難読化を解除した後、JS 仮想マシンに供給されているバイトコードであることが明らかになりました。 このブログ エントリは、さらに理解するために専用の逆コンパイラが必要な疑似アセンブリで終了します。 パート 3 を期待していますが、おそらくさらに別の研究者によるものでしょう。

SugarCRM アンダーファイア

SugarCRM のゼロデイが 12 月に seclists.org に投稿され、ホットフィックスがすぐに開発されました。 エクスプロイトは、些細な欠陥のペアです。 1 つ目は認証バイパスです。この場合、ユーザー名とパスワードの両方を 1 に設定してリクエストが送信され、有効な認証 Cookie が生成されます。 2 つ目は、images ディレクトリへの無制限のファイル アップロードです。 PHP スクリプトをアップロードし、URL にアクセスしてすぐに収益を得ることができます。

残念ながら、これは実際に悪用されており、アクセス可能な SugarCRM デプロイメントの約 12% が既にクラックされています。 エクスプロイトは、潜在的に脆弱な展開を返すいくつかの検索文字列で公開されたため、マシンがエクスプロイトされたことは驚くべきことではありません。 インターネット上に SugarCRM ボックスがある場合は、セキュリティ侵害がないか調べてみましょう。

ビットとバイト

VScode は本当に何かです。 すぐにかなりの数のプログラマーのお気に入りになったオープン ソースの Microsoft プロジェクト。 これは優れた IDE であり、拡張機能の幅広いライブラリがあります。 そして、それは問題になる可能性があります。 VSCode 拡張機能はサンドボックスなしで実行され、VSCode を実行しているユーザー アカウントと基本的にすべて同じ権限を持ちます。 タイポスクワッティングや同様のトリックに気をつけなければならないもう 1 つの場所です。

Amazon は、新しい S3 オブジェクトに対してデフォルトでサーバー側の暗号化を展開していると発表しました。 S3 ストレージで見られる最も一般的な問題である認証トークンのリークから保護するために何もしないため、これが実際にどれほど役立つかについて質問があります。 少なくとも、これは物理的な攻撃を防ぐのに役立ちますが、それはまだありそうにありません.

そして鍵といえば、 [Tom Forbes] パッケージやリポジトリで意図せずに公開された AWS キーを見つけるために、すべての正規表現文字列の母を作成しました。 (('|")((?:ASIA|AKIA|AROA|AIDA)([A-Z0-7]{16}))('|").*?(n^.*?){0,4}(('|")[a-zA-Z0-9+/]{40}('|"))+|('|")[a-zA-Z0-9+/]{40}('|").*?(n^.*?){0,3}('|")((?:ASIA|AKIA|AROA|AIDA)([A-Z0-7]{16}))('|"))+ ちょっと大袈裟ですが、彼は PyPi だけで 57 個のライブ AWS キーを見つけました。 印象的。

Leave a Comment

Your email address will not be published. Required fields are marked *