SAPocalypse。 ブラックハット。 J2EEのハッキング。 悪夢悪夢

みなさんこんにちは！ ここで多くの人がもっと書くように頼みました。 実際、フライトの間に少し時間を割って、いくつかの古い脆弱性を思い出しました...しかし、あなたはすでに何を推測しました。



これらのバグに関する情報が最初に公開されてから長い時間が経ちました。 むしろ、丸一年。 ちょうど1年前、私はJ2EE SAPエンジンのセキュリティトピックに関するレポートを持ってBlackHatに行きました。 そのバグについて話してはいかがでしょうか。 特に 、 ZeroNightsの短いビデオを除けば、RuNetのBlackHatで提示されたすべてを詳細に説明する手がまだ届いていないので 、かなり厄介でした。



この研究はSAP NetWeaver J2EE Engineプラットフォームに捧げられたものであり、ABAPエンジンに関する情報は非常に少なく、世界中のセキュリティに関する研究はほとんどありません。 しかし、 Digital Security Research Groupはパンを食べさせず、他の誰もポップしていない場所で何かを壊すようにします。 一般に、最初はSAPが何であるか、ビジネスにとってそれがどのように重要であるかについていくつかの一般的な言葉があり、皮肉屋がスクロールダウンできるようにします。

いくらかの水

SAPのすべてのビジネスアプリケーションは、2つのプラットフォームのいずれかに基づいており、古いソリューションやサポートアプリケーションをカウントしていません。 より正確には、3番目のプラットフォーム-SAP Business Objectsがあります。これは多くのシステムを実行しますが、一般的にはあまり一般的ではなく、NetWeaver J2EE Engineに似ています。



セキュリティの観点から最も古く、最もよく知られ、多かれ少なかれ研究されているプラ​​ットフォーム番号1は、SAP NetWeaver ABAPです。 このアプリケーションサーバーに基づいて、ERP、CRM、SRM、PLM、およびその他の3文字の略語などのシステムが使用されます。これらは通常、スマートな人の目を引くためにリストされています。 これらすべてのアプリケーションは、ビジネスプロセスを自動化するという共通の目標によって結合されています。 これが意味することは、多くはまだ最新ではありませんが、この記事では重要ではありません。



2番目のプラットフォームはSAP NetWeaver J2EE Engine（以下「J2EEエンジン」と呼びます。記事のJ2EEエンジンは、JAVA仮想マシンのコアではなく、すべてのアプリケーションを含むアプリケーションサーバープラットフォーム全体を指します）。 実際、このプラットフォームはビジネスアプリケーションを結合するように設計されています。つまり、それ自体は重要な情報を含まないことが多く、いわゆる仲介者として機能します。 NetWeaver J2EEプラットフォームに基づくこのようなアプリケーションのリストには、SAPポータルが含まれます。SAPポータルは、SSOなどを介してさまざまなリソースへの統合アクセスを提供するユニバーサルエンタープライズポータルの一種です。 ポータルでは、多くの場合、内部SCADAシステムのインターフェースへのリンクを見つけることができます。これは直接利用できませんが、機能の一部はポータルに送信されます。 これが何を脅かすかは理解できると思います。 ポータルに加えて、J2EEエンジンは、たとえばエンタープライズ統合バスであり、さまざまなビジネスアプリケーションと他の多くのアプリケーション間の交換を提供するSAP XI / PIアプリケーションに基づいています。 一般的に、なぜ私はこれすべてですか？



単一の会社でビジネスフローを制御する必要があるとします（なぜこれが必要なのか、この例がどのように思い浮かんだのかは尋ねません）。 これを行うには、データを処理する多数のサーバーよりも、リンクであるサーバーにハッキングする方がはるかに簡単です。 さらに、ABAPエンジンのセキュリティに関する限り、すでに多くの研究が行われており、徐々に安全性が高まっていますが、インド人によって完全に開発されたJAVAエンジンではそうではありません。



そこで、J2EEの部分を分析することにしました。 2009年に開始されたJAVAエンジンのセキュリティ調査により、約200の脆弱性が発見されましたが、そのほとんどは現在製造元によって閉鎖されています。 大量のXSS-ok、情報漏えいの脆弱性、その他の比較的ありふれた問題に加えて、より興味深いバグがありました。実際、これについて詳しく説明します。

ここから読む

新しいクラスを発見した場合、多くの例を見つけることができるので、脆弱性のクラス全体（または少なくともサブクラス）を個別の問題よりも検出する方がはるかにクールであることは誰もが知っています。 J2EEエンジンの例では、SAP NetWeaver J2EE EngineプラットフォームはJavaで記述されたアプリケーションをホストできるJ2EE標準アプリケーションサーバーであるため、まったく問題はありません。 これは、Apache Tomcatのようなもので、わずか100倍の大きさで、より複雑で理解しにくいものです。複雑な部分では、確実に脆弱性が現れます。 実際、このサーバーには、SAP Portal、SAP XI、SAP PIなどのビジネスシステム自体が、個別のアプリケーションまたは一連のアプリケーション、および独自の開発アプリケーションとして配置されています。 このような大規模システムは、より小さなアプリケーション（アプリケーション）で構成されており、各アプリケーションは、複雑さやコードのサイズの点で、小さなWebプロジェクトに匹敵することがよくあります。 このようなアプリケーションはデフォルトで多数インストールされています。 したがって、NetWeaverバージョン6.40には約500があり、バージョン7.2にはすでに1200があります。当然、各アプリケーションには独自のバグが含まれていますが、それらを検索する必要はなく、すべて特定です。 より一般的なもの、ある種の大規模な脆弱性、つまりすべてのアプリケーションに潜在的に存在するものを見つけたいと考えました。

ここから良い

J2EEアプリケーションに精通している人なら、おそらくすべてが少なくとも1つのファイルweb.xmlによって結合されていることを知っているでしょう。 このファイルとSAPにさらに精通している人々は、ほとんどの場合、すでにそれが何であるかを推測しています。 ただし、最初に、典型的なWEB.XMLファイルの構造を見てください。

<servlet> <servlet-name>CriticalAction</servlet-name> <servlet-class>com.sap.admin.Critical.Action</servlet-class> </servlet> <servlet-mapping> <servlet-name>Critical</</servlet-name> <url-pattern>/admin/criticalfunc</url-pattern> </servlet-mapping> <security-constraint> <web-resource-collection> <web-resource-name>Restrictedaccess</web-resource-name> <url-pattern>/admin/*</url-pattern> <http-method>GET</http-method> </web-resource-collection> <auth-constraint> <role-name>admin</role-name> </auth-constraint> </security-constraint>
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

エラーがどこにあるのかを誰かが既に理解しているだろう...いや、閉じられていないタグに指を突くように急いではいけません。私は単なるタイプミスではなく、悲しい結果につながる脆弱性を意味します。 見つかりませんでしたか？ 次に、読むことをお勧めします。 J2EEエンジンには、Invoker Servletのようなメカニズムがあります。 これにより、開発者がデバッグモードで直接クラスにアクセスするのに便利なように、クラスの名前で直接行で任意のサーブレット（サーバー上で機能を実行するアプリケーションの一部）を呼び出すことができます。 いずれにせよ、これはそのように説明されているので、私は議論しないでしょう、多分それは本当に便利です。 しかし、このサーブレットのクラス名を/ servlet / <servlet-name-or-class>のようにURLバーに入力することにより、セキュリティ設定をバイパスすることが特に便利です。

そしてここで一般的に最も美味しい

問題は、危険なアクションを実行するサーブレットを作成し、/ adminなどのディレクトリに配置し、adminロールを持つユーザーを除くすべてのユーザーに対して<auth-constraint>を使用してアクセスを閉じるときに始まります。 ファイルは、/サーブレットディレクトリへの直接アクセスが何らかの方法でブロックされていないため、リンク/サーブレット/ <servlet-name-or-class>のInvokerメカニズムを通じて直接サーブレットにアクセスし、認証なしで必要なデータを取得できることです防御が/ *に立っていた場合、すべてが問題ありません）。 これは非常に単純で簡潔であり、J2EEアプリケーションでバッファオーバーフローが発生せず、そのようなアーキテクチャ上のバグが発生した場合、JAVAタイプがCより安全であることは重要ではありません。



私たちにとっての主な問題は、 初めて 、500のすべてのアプリケーションの中で、Invokerサーブレットへのアクセスをフィルタリングせず、このサーブレットを介して危険なアクションを実行したアプリケーションです。結局、実際のリスクを示す必要があります「これは理論的には、特別な状況では、a + bc * dがあまり良くないものにつながる可能性があるということです。」



たとえば、ある楽しいWebサービスでは、OSから任意のファイルを読み取ることができますが、このバグに対して脆弱です。つまり、サーバーに保存されているファイルを読み取ることができます。 必要に応じて、DBMSから直接データをダウンロードし、金融取引を掘り下げることもできます。主なことは、ブラウザーが数ギガバイトのファイルを開いてダウンロードすることに依存していないことですが、これはまったく別の話です。

私はごまかしました

この脆弱性については、私たちにとって何か不十分なものでした。BlackHatに移動するために砲撃しなければ、なんらかの形で失敗しました。 そして、私はさらに検索を始めました：WEB.XMLで他に何ができるでしょうか？ そして、動詞改ざんのような脆弱性に関する古い記事を思い出しました。 理論上は非常に有効なバグですが、実際のシステムには実用的な例はありませんでした。 当然のことながら、試してみることにしました。うまくいったら、幸運を期待していないのに、朝のドーナツをむさぼり食いそうになりました...本当に効きます-できません。 いいね！

情熱が落ち着いた後、私は本当に何をしなければならないかを理解しました。それは、アーキテクチャの問題を検出することと、そのような脆弱性が存在する実際の例を見つけることだからです。 ただし、問題は何かを説明します。 したがって、ここでも、アクセス制御を担当する最愛のWEB.XMLまたはその一部の例を示します。

 <url-pattern>/admin/*</url-pattern> <http-method>GET</http-method> </web-resource-collection> <auth-constraint> <role-name>admin</role-name> </auth-constraint>
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

この例では、adminロールを持つユーザーのみが/ adminディレクトリにあるアプリケーションにアクセスし、GETメソッドのみを実行できることが示されています。 それなしで？ どんな場合でも、明示的に禁止されていないものはすべて許可されていることがわかりました。たとえば、GETとまったく同じですが、ユーザーに結果を表示しないHEADメソッドを使用すると、匿名で実装できます。 、ユーザーもロールもまったくありません。 なんで？ はい、ファイルでそう言っているため：管理者のみがGETメソッドを使用して/ adminディレクトリにアクセスできます。 そして他の方法で-誰にでも！ つまり、メソッドの名前が明示的に示されていない場合、これは管理者のみがすべてのメソッドを使用でき、すべてが問題ないことを意味します。 そして、1つの方法が示されたので、他のすべてをリストしてください。



幸せになりたいですか？ はい、ありませんでした。今、干し草の山、または少なくとも、J2EEエンジンにインストールされている少なくともいくつかのアプリケーションで針を探す必要があります。



•動詞の改ざんに対する脆弱性

•HEADリクエストをサポートし、GETと同じ方法で処理します

•重要なアクションを実行します。応答本文は、HEADであるため重要ではありません。

•単なるデモとしてではなく、すべてのインストールに存在することが望ましい



はい、疲れました。 はい、しました。



一般的に、このアプリケーションは...と呼ばれますが、ちなみに、この投稿を注意深く読むとわかります。 そして、それはWebインターフェースを備えたJ2EEエンジンのコントロールに他なりません。 つまり、システムにユーザーを作成できますが、ユーザーはそこにいます！ 彼に任意のロールを割り当てることができ、OSコマンドを実行でき、サーバーをリモートで停止できます。これらすべてを1つの単純なHEADリクエストで実行できます。



同時に、J2EEエンジンを使用するSAP Portalは、簡単にオンラインでグーグル検索できます。 たとえば、次のようになります。inurl：/ irj / portal



ストーリーの最もクールな部分は、SecurityByteカンファレンス（いわゆる「インドシリコンバレー」）でバンガロールに行って、このトピックに関するプレゼンテーションを行っているときに、誰も私に近づかなかったことです。その非常に脆弱なインターフェイスの開発者、それによって私の疑いは正当化されました。 ちなみに、開発者はクールな男であることが判明しました。もちろん、私は彼がBla c kHa tに参加するのを手伝ってくれたことに感謝しました。 冗談です。



今日は以上です。kHat2012でBlaのラスベガスに飛ぶ飛行機にこれらの行を追加します。ここで、非常にエレガントなバグを1つ紹介します-ちなみに、SAPでもJavaでも、レポートをお待ちください...