脆弱性テクニカルサポート：CMS。 パート1

1C-Bitrixは最も人気のあるCMSシステムの1つです。 これには、名刺Webサイトから高負荷システムまで、多くの興味深いソリューションが含まれています。 ペンテスト中にこの製品に頻繁に遭遇し、検出されたセキュリティ問題のほとんどは、Bitrixコア自体ではなく、自己記述モジュールで見られることに注意してください。 一度、ボックス化されたソリューションに基づいて単一システムのセキュリティを分析すると、多くの興味深い脆弱性が検出されました。 残念ですが、すべてについて話すことはできませんが、サーバーでのリモートコードの実行と権限の昇格については既に話すことができます。



ところで、RCE開発者は修正を拒否しました。

悪意のある猫

Bitrixと1Cアカウンティングの統合に精通しているなら、おそらく「1c_bx_import.php」というスクリプトに出くわしたでしょう。 要するに、これは診断用のデバッグスクリプトです。その機能の詳細については、開発者からのリンクを参照してください 。 いくつかの特定のアクションに加えて、サーバーへのファイルのダウンロードとアップロード、アーカイブの解凍、任意のファイルの削除の機能を実装しています。



このスクリプトの状況はあいまいです。開発者によると、CMSの公式な部分ではありませんが、会社のリソースにあり、顧客の問題を解決するためにテクニカルサポートによって使用されることがあります。 最終的に、これはさまざまなリソースで、時にはサイトのルートで見つけることができることを意味します。 開発者は、この製品は自分の危険とリスクでのみ使用する必要があると正直に指摘しましたが、スクリプトには認証と承認があるため、ユーザーはおそらくすべてが安全で良いと信じています。 残念ながら、これは完全に真実ではありません。



スクリプトで認証がどのように実装されるかを見てみましょう。

if ((@$_REQUEST['mode']!='query' && @$_REQUEST['mode']!='exchange')) define('NEED_AUTH',true); require($_SERVER["DOCUMENT_ROOT"]."/bitrix/modules/main/include/prolog_before.php");
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

最も可能性が高いのは、URIの「mode」パラメーターが「query」または「exchange」の場合、ユーザーにログインフォームが与えられ、スクリプトが終了すると考えられていたためです。 ただし、よく見ると、エラーが論理演算子に忍び込んでいることがわかります。 それはまったく逆でした。「モード」が「クエリ」または「交換」と等しくない場合にのみ認証が要求されます 。



スクリプトで許可を確認します。 開発者は、スクリプトは管理者のみが実行することを提案しました。

 if ((!$USER->IsAdmin())&&(@($_GET['mode']!='query'))) { echo ' .    .  .'; localredirect("/404.php"); }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

両方の条件が満たされない場合、スクリプトは終了します。 もう一度注意深く見てみましょう。



ユーザーが管理者ではなく、モードがクエリと等しくない場合は、「アクセスが拒否されました」と表示されます。



管理者である必要はなく、最初の条件は当てはまらず、「アクセスが拒否されました」セクションに入ることはなく、スクリプトは引き続き正常に動作します。 匿名ユーザーがパラメーター「モード」として「クエリ」を指定すると、スクリプト内のすべてのアクションが利用可能になります（「アクション」パラメーターは関数のタイプを選択する役割を果たします）。 ファイルの機能により、サーバーからファイルをダウンロードして任意のディレクトリにアップロードできることを考えると、このスクリプトへのパブリックアクセスは非常に大きなセキュリティリスクです。



実行可能なコマンドの完全なリスト：

• createfile-指定されたパスにテキスト「success」を持つファイルを作成します
• setsession-ランダムCookieを現在のユーザーセッションに追加します
• createiblocktypeform-インフォブロックタイプの作成
• ダウンロード-サーバーから任意のファイルをダウンロードします
• xmlgetinfo-サーバーから任意のファイルをダウンロードする
• deletefile-サーバーから任意のファイルを削除します
• getfile-サーバー上のファイルのリストを取得します
• unzip-アーカイブを解凍します
• アップロード-ファイルを任意のディレクトリにアップロードします
• 検索-サーバー上のファイルを検索します
• show_bxmltree-ディレクトリ構造をxmlファイルとして出力します

たとえば、次のリクエストは、データベースにアクセスするためのアカウントを含む構成ファイルをダウンロードできるようにするリクエストです。







そして、このようなリクエストにより、攻撃者はサーバー上のファイルのリストを取得できます。







最後に、任意のコードをダウンロードできます：







クライアントとCMS開発者の両方に脆弱性を報告しました。 残念ながら、Bitrix開発者はエラーの修正を拒否しました。これは、上記のように、このスクリプトがCMSの公式コンポーネントではないためです。

ローカル権限昇格

1C-Bitrix Webクラスターの開発者は、クラスターサーバーのいずれかのbitrixシステムユーザーにアクセスできる、クラスター内のすべてのサーバーでスーパーユーザー特権（ルート）を取得できるようにするミスを犯しました。



1C-Bitrix WebクラスターはAnsibleサーバー管理システムを使用し、サーバー間の認証はSSHキーを使用して実行されます。 キーファイルにアクセスできるのはスーパーユーザーのみです。 Ansibleがリモートサーバーでキーを読み取り、コマンドを実行するために、sudoユーティリティが使用されます。これにより、rootユーザーに特権が与えられます。



クラスターシステムインストーラーは、sudo / etc / sudoersコマンド構成ファイルに次の行を追加します。

 bitrix ALL=NOPASSWD: /usr/bin/ansible * -m setup
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

システムスクリプトは、アスタリスクの代わりに、クラスター内のサーバー名を置き換えます。



sudoユーティリティは、文字列内の部分文字列の出現を検索し、execvクラスのシステムコマンドの場合のように引数を分離しません。 上記の行のアスタリスク文字を使用すると、任意の数の文字を挿入できます。これらの文字は個別の引数に分割されます。 したがって、1つのコマンドで簡単に特権を増やすことができます。

 $ sudo /usr/bin/ansible 127.0.0.1 -m shell -a 'whoami; echo -m setup' 127.0.0.1 | success | rc=0 » root -m setup bitrix@test: ~
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

sudo自体の引数は次のとおりです。

 ["sudo", "/usr/bin/ansible", "127.0.0.1", "-m", "shell", "-a", "whoami; echo -m setup"]
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

そして、これは開発者によって書かれたsudoersルールに対応しています。 開発者はこの脆弱性に同意し、現時点ではすでに修正されています。

おわりに

結果として何が得られますか？ 脆弱性は非常に単純であり、悪用の特定の条件を必要としません。



テストされたサイトを制御する機会を探すときのアクションをリストします。

1. ホストを決定し、ファイルとディレクトリを選択する手順を開始します（dirbuster）。
2. 「bx_1c_import.php」に一致しました。 分析のために開発者のサイトからソースをダウンロードします。
3. サーバーから任意のファイルをダウンロードする機能が見つかりました。
4. まず、データベースにアクセスするための構成ファイルdbcon.phpをダウンロードします。 残念ながら、MySQLは「localhost」との接続のみを想定しています。 ソースコードをさらに分析します。
5. カスタムコードをアップロードする機能が見つかりました。 サーバーに再び接続しますが、現在のユーザーは、Webサーバーが実行されており、私たちに代わって、限られた権限しかありません。
6. テストされたホストの分析の結果、明らかになりました-これはクラスタ全体です。 そして、彼らは名刺サイトで1Cとの統合を行いませんでした。
7. 「Ansible」と対話する可能性を模索しています。
8. クラスター全体で既にルートへの特権を増やします。
9. ...
10. 新しい脆弱性を探しています。