regreSSHion：OpenSSHに発見された重大な脆弱性(CVE-2024-6387)

Security Splunk Threat Research Team

ほぼすべてのUnix系およびLinuxシステムにデフォルトでインストールされているOpenSSHアプリケーションに重大な脆弱性があることをQualys社が先日発見し、現在詳しい調査が行われています。

別名「regreSSHion」と名付けられたこの脆弱性CVE-2024-6387により、Linux環境で認証なしでリモートから任意のコードが実行されるリスクがあります。この脆弱性は広範囲に影響を及ぼし、世界中の多数のサーバーやインフラコンポーネントが影響を受ける可能性があります。

このブログ記事では、Splunk脅威調査チームがCVE-2024-6387の複雑な技法について解説し、影響を受けるシステムで想定されるリスクを検証して、その検出戦略と緩和策をご紹介します。

CVE-2024-6387の概要：

技術的な詳細

脆弱性

CVE-2024-6387はシグナルハンドラの競合状態に起因する脆弱性であり、glibcベースのLinuxシステム上のOpenSSHバージョン8.5p1～9.8p1が影響を受けます。この脆弱性は、過去の脆弱性(CVE-2006-5051)への「回帰」に起因しており、攻撃者がリモートからroot権限で任意のコードを実行することで、システムが完全に掌握される危険性があります。

シグナルハンドラの競合状態の詳細：この脆弱性はOpenSSHサーバー(sshd)でのSIGALRMシグナルの処理時に生じます。影響を受けるバージョンでは、SIGALRMハンドラによって、syslog()など、「async-signal-safe (非同期シグナルセーフ)」ではない関数を呼び出すことができます。これにより競合状態が生じ、シグナルハンドラが重要なコードセクションに割り込み可能になって、システムでの処理の整合性が損なわれる可能性があります。攻撃者は、この状態を悪用して、メモリーを操作し、任意のコードを実行します。

過去のCVE-2006-5051との関連：興味深いことに、この脆弱性は、2006年にパッチが公開された脆弱性CVE-2006-5051に回帰したものです。この過去の脆弱性もOpenSSHでのシグナルハンドラの競合状態に起因していました。この脆弱性は修正されましたが、その後、2020年10月にOpenSSH 8.5p1のログ処理基盤に変更があった際に、新たな脆弱性が誤って入り込みました。

この問題は、複雑なソフトウェアシステムのセキュリティを長期にわたって維持することの難しさを浮き彫りにしています。

悪用の具体的な条件：この脆弱性を悪用するにはいくつかの条件を満たす必要があります。

このように悪用の難易度は高いため、脆弱性としては重大レベルであるものの、攻撃を成功させるには高度なスキルと持続性が必要になります。それでも、root権限でのリモートコード実行が可能になるため、影響を受けるシステムでは深刻な問題です。

悪用の仕組み

GitHubで公開された「regreSSHion」のPoC (概念実証)エクスプロイトでは、複雑な競合状態を利用しており、攻撃を成功させるには正確なタイミングが求められ、場合によっては数千回の試行が必要になります。その仕組みを詳しく見ていきます。

タイミングと期間：エクスプロイトを成功させるチャンスがあるのは非常に短時間です。Qualys社の調査では以下のことがわかりました。

システムのメモリーの状態を操作するには、特定の操作の瞬間に正確に割り込む必要があり、タイミングが非常に重要になります。

OSとアーキテクチャ：PoCの対象は主に32bit (x86)システムで、64bit (amd64)版については執筆時点で調査中です。要点は以下のとおりです。

PoCで使われた主な関数：PoCエクスプロイトで使われた重要な2つの関数をご紹介します。

a) prepare_heap()：

この関数の機能は、いわば、ドミノ牌を使って複雑なパターンを作ることです。コンピューターのメモリー(ヒープ)を特定の方法で配置して、エクスプロイトを機能させるために完璧な状態を作ります。具体的な操作は以下のとおりです。

目的は、コンピューターのメモリーを予測可能な配置にして、後でエクスプロイトで利用できるようにすることです。

void prepare_heap(int sock) {
    // Packet a: Allocate and free tcache chunks
    for (int i = 0; i < 10; i++) {
        unsigned char tcache_chunk[64];
        memset(tcache_chunk, 'A', sizeof(tcache_chunk));
        send_packet(sock, 5, tcache_chunk, sizeof(tcache_chunk));
    }
   
    // Packet b: Create 27 pairs of large (~8KB) and small (320B) holes
    for (int i = 0; i < 27; i++) {
        unsigned char large_hole[8192];
        memset(large_hole, 'B', sizeof(large_hole));
        send_packet(sock, 5, large_hole, sizeof(large_hole));
 
        unsigned char small_hole[320];
        memset(small_hole, 'C', sizeof(small_hole));
        send_packet(sock, 5, small_hole, sizeof(small_hole));
    }
    // ... more heap manipulation ...
}

b) attempt_race_condition()：

この関数では、エクスプロイトを実際に再現します。絶好のタイミングでドミノ牌を倒して特殊な効果を生じさせるようなものです。その仕組みは以下のとおりです。

サーバーの正常な処理を絶好のタイミングで中断できるかどうかがこのエクスプロイトの鍵です。タイミングが合えば、攻撃者はサーバーのメモリーを操作して、高いレベル(root)の権限で任意のコードを実行できます。

int attempt_race_condition(int sock, double parsing_time, uint64_t glibc_base) {
    unsigned char final_packet[MAX_PACKET_SIZE];
    create_public_key_packet(final_packet, sizeof(final_packet), glibc_base);
 
    // Send all but the last byte
    if (send(sock, final_packet, sizeof(final_packet) - 1, 0) < 0) {
        perror("send final packet");
        return 0;
    }
 
    // Precise timing for last byte
    struct timespec start, current;
    clock_gettime(CLOCK_MONOTONIC, &start);
 
    while (1) {
        clock_gettime(CLOCK_MONOTONIC, &current);
        double elapsed = (current.tv_sec - start.tv_sec)
                         + (current.tv_nsec - start.tv_nsec) / 1e9;
        if (elapsed >= (LOGIN_GRACE_TIME - parsing_time - 0.001)) { // 1ms before SIGALRM
            if (send(sock, &final_packet[sizeof(final_packet) - 1], 1, 0) < 0) {
                perror("send last byte");
                return 0;
            }
            break;
        }
    }
    // ... check for successful exploitation ...
}

このプロセスは非常に高い精度が求められ、成功までに何度も試行が必要になります。ジェットコースターに乗りながら針に糸を通そうとするようなもので、場合によっては攻撃を数千回試みることになるでしょう。しかし、成功すれば、攻撃者はサーバーを完全に掌握できます。

難易度が高いため現実の環境でこのエクスプロイトを成功させるのは困難です。それでも、成功した場合、攻撃者がログイン認証をせずにシステムを自由に制御できるようになるため、影響は甚大です。システム管理者は、OpenSSHを更新するとともに、このような攻撃からシステムを守るためのセキュリティ対策を講じることが重要です。

エクスプロイト対策

Splunk脅威調査チームは、侵害後の挙動に関連するアクティビティに沿った一連のLinux分析ストーリーを開発しました。これらのストーリーは、Linux環境での強力な検出機能を提供します。特に重要なストーリーが以下の4つです。

これらのストーリーには、アノマリ検出や、MITRE ATT&CKフレームワークのTTP (戦術、技法、手順)など、幅広い検出手法が取り入れられています。この分析ストーリーを導入すれば、Linuxインフラを標的とする高度な脅威について、侵害後の各段階での検出、調査、対応能力を大幅に強化できます。

OpenSSHインベントリ

UbuntuホストにインストールされているOpenSSHのバージョンが特定のエクスプロイトや攻撃に対して脆弱であるかどうかを確認するために、インベントリをサーチするSplunkクエリーを作成できます。このクエリーでは、パッケージの監査ログを分析して、本番環境のネットワーク内で見つかったすべてのOpenSSHのバージョンを特定します。

パッケージの監査ログを利用することで、OpenSSHのすべてのインスタンスを体系的に追跡および監査できます。このアプローチにより、使用しているソフトウェアバージョンを確実かつ包括的に把握できます。そこから、既知の脆弱性の影響を受けやすいバージョンをすばやく洗い出すことができます。

このインベントリ用のシンプルなサーチを次に示します。

index=unix source=package NAME= "*openssh*"
|  rex field=VERSION "^1:(?<ssh_version>\d+\.\d+)"
|  eval ssh_version_number = tonumber(ssh_version)
| eval vulnerable_ssh_version = if(ssh_version_number >= 8.5 AND ssh_version_number < 9.8, "Vulnerable SSH Version", "SSH Version not Vulnerable")
|  stats count by NAME VENDOR ssh_version ssh_version_number VERSION vulnerable_ssh_version
OpenSSHパッケージを特定するためのSplunkクエリー
(OpenSSHパッケージを特定するためのSplunkクエリー、Splunk 2024)

パッチ未適用のバージョンを実行しているホストでsshdの「timeout before authentication」(認証前にタイムアウト)ログの記録が増えていないかどうかを確認します。この攻撃では新たなログインが何度も試行されるため、ネットワーク監視を行っている場合は、代わりに新規接続の件数が増えていないかどうかを確認することもできます。

sourcetype=journald OR sourcetype=linux:auth OR TERM(sshd) OR TERM(ssh)
TERM(Timeout) TERM(authentication) "Timeout before authentication"
| timechart count by host
認証前のタイムアウトの件数をグラフにするためのSplunkクエリー
(認証前のタイムアウトの件数をグラフにするためのSplunkクエリー、Splunk 2024)

緩和策

最も効果的な解決策はパッチを適用することですが、それが難しい場合は、CVE-2024-6387の脆弱性に対するリスクを軽減するための緩和策がいくつかあります。

パッチ管理

アクセス制御

ホストベースの侵入防止

SSH設定の強化

sshd_configの以下の設定を調整して、攻撃を緩和します。

ネットワークのセグメント化

多要素認証(MFA)：SSHアクセスにMFAを導入して、セキュリティの層を厚くします。初期のエクスプロイトを防ぐことはできませんが、攻撃者が盗んだ認証情報を悪用するのを制限できます。

監視とアラート

代替アクセス手段：重要なシステムでは、VPNソリューションなど、SSHを使用せず強力な認証を備えたセキュリティの高いリモートアクセス手段を代わりに使用することを検討します。

Snort：シグネチャベースの検出を導入します。CVE-2024-6387のエクスプロイト試行を検出するためのSnortシグネチャ(SID：63659)がCisco Talosから公開されています。セキュリティインフラにSnortを追加することで、組織の防御層を厚くできます。

これらの緩和策はいずれも、多層防御戦略の一部にすぎないことに注意してください。1つの対策を取り入れれば安心というわけではなく、複数のセキュリティ層を組み合わせることで最良の効果を発揮します。また、新しい脅威や脆弱性に対応するために、セキュリティ対策を定期的に見直して更新することも重要です。

詳しい情報

セキュリティ分析ストーリーの最新コンテンツは、GitHubからダウンロードするか、Splunk ES Content Update Appで利用できます。また、Splunk Security Essentialsでは、プッシュアップデートによってこれらの検出方法をすべて利用できます。すべてのセキュリティコンテンツの一覧は、Splunkマニュアルのリリースノートに掲載されています。

フィードバック

ご意見やご要望がございましたら、GitHubから遠慮なくお寄せください。Slackチャネル「#security-research」にご参加いただくこともできます。SlackのSplunkユーザーグループへの招待が必要な場合は、こちらの手順に従ってください。

寄稿者

この記事の執筆にあたってご協力いただいた以下の方々に感謝を申し上げます。Michael HaagとTeoderick Contreras、Splunk脅威調査チームのLou Stella、Bhavin Patel、Rod Soto、Eric McGinnis、Jose Hernandez、Patrick Bareiss、そしてSURGeのJames Hodgkinson、Jonathan Heckinger、Cisco TalosのMichael GentileとKeith Lehrschall(敬称略)

このブログはこちらの英語ブログの翻訳、山村 悟史によるレビューです。
/ja_jp/blog/fragments/sidebar/top-50-cybersecurity-threats-promo-primary-asset
Style
two-column

関連記事

Open Cybersecurity Schema Framework (OCSF)がついにv1.0スキーマをリリース
セキュリティ
4 分程度

Open Cybersecurity Schema Framework (OCSF)がついにv1.0スキーマをリリース

1周年を迎えたOpen Cybersecurity Schema Framework (OCSF)が新しいオープンデータスキーマをリリースしました。
DECEIVEのご紹介：AIを活用した概念実証ハニーポット
セキュリティ
6 分程度

DECEIVEのご紹介：AIを活用した概念実証ハニーポット

Splunk SURGeは、AIを活用した概念実証段階のハニーポット「DECEIVE」を公開しました。AIを活用した動的なシミュレーションとセッションサマリーにより、サイバーセキュリティ業務を効率化して、革新的なセキュリティソリューションを構築する方法をご紹介します。
Splunkのセキュリティユースケース
セキュリティ
3 分程度

Splunkのセキュリティユースケース

セキュリティ担当者にとって最大の課題は、業務の両立です。既存の脅威の調査と修復を実施しながら、新たに猛威を振るうサイバー攻撃に後れをとらずに対応しなければなりません。Splunkでは、Splunkのセキュリティソリューションの活用方法についてより良く理解するための主要なセキュリティユースケースをご紹介しています。
/ja_jp/blog/fragments/about-splunk
/ja_jp/blog/fragments/subscribe-footer