2024年7月版 最速!危険度の高い脆弱性をいち早く解説「脆弱性研究所」第24回
7月に公開された重大な脆弱性(CISA KEV参照)
7月に新たに公開された脆弱性は3040となります。この中で特に重大な脆弱性をいくつかピックアップして説明したいと思います。
第三回で説明したCISAによる「実際に悪用されている脆弱性(Known Exploited Vulnerabilities Catalog)」のデータベース情報もあわせて載せています。
7月にCISAのKEVに登録された脆弱性はトータル14件で、内訳は
- Acronis: 1件
- Adobe: 1件
- Cisco: 1件
- Microsoft: 3件
- OSGeo: 1件
- Rejetto: 1件
- ServiceNow: 2件
- SolarWinds: 1件
- Twilio: 1件
- VMWare: 2件
になっています。
参考情報
- CISA「Known Exploited Vulnerabilities Catalog」
1. OpenSSHの脆弱性(regreSSHion: CVE-2024-6387)
2024年7月1日にOpenSSHの脆弱性(regreSSHion: CVE-2024-6387)が公開され、OpenSSH 9.8がリリースされました。非常に危険性の高い脆弱性で影響範囲も広くなっています。今回はこれらの脆弱性の概要と、各ディストリビューションの対応についてまとめます。
一次情報源
CVE情報
公開されたCVEは以下になります。
- CVE-2024-6387
- 影響するバージョン: 8.5p1 <= 9.7p1
- CVSS
- Red Hat: 8.1 Important
- Vector: CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H
- シグナルハンドラの競合によるリモートコード実行の可能性
- クライアントによる認証がLoginGraceTime 秒 (デフォルトでは120秒、古いOpenSSH では600秒) を超えると、sshdのSIGALRMハンドラが非同期的に呼び出されますが、このシグナルハンドラは非同期シグナルセーフではない、さまざまな関数(syslog()など)を呼び出します。この状態は、CVE-2006-5051のレグレッションであり、リモートの攻撃者がサービス拒否 (クラッシュ) を引き起こして任意のコードを実行する可能性があります。
脆弱性詳細
以下、OpenSSH Portableからダウンロードできる方のソースコードを使用しています。
OpenSSHでは、「LoginGraceTime」秒(デフォルトでは120秒、古いOpenSSHでは600秒)以内に認証されない場合、sshdのSIGALRMハンドラが非同期に呼び出されます。
(以下はOpenSSH9.7P1のソース)
2083 */
2084 ssh_signal(SIGALRM, grace_alarm_handler);
2085 if (!debug_flag)
2086 alarm(options.login_grace_time);
2087
ここで、ssh_signal()は非同期安全ではない(スレッドセーフではない)さまざまな関数を呼び出します。たとえば、ssh_signal()から呼び出されるdebug3が呼び出すdo_log()中では
(以下はOpenSSH9.7P1のソース)
336 static void
337 do_log(LogLevel level, int force, const char *suffix, const char *fmt,
338 va_list args)
339 {
–省略--
413 #if defined(HAVE_OPENLOG_R) && defined(SYSLOG_DATA_INIT)
414 openlog_r(progname, LOG_PID, log_facility, &sdata);
415 syslog_r(pri, &sdata, "%.500s", fmtbuf);
416 closelog_r(&sdata);
417 #else
418 openlog(progname, LOG_PID, log_facility);
419 syslog(pri, "%.500s", fmtbuf);
420 closelog();
を呼び出します。
OpenBSD系列であれば、413行の処理に一致してsyslog_r()関数(スレッドセーフなsyslog関数)を呼び出します。しかし、Linux系列であればsyslog()関数(スレッドセーフではない関数)を呼び出してしまいます。syslog() 自体が非同期安全ではない他の関数 (malloc() や free() など) を呼び出すため、これを悪用することができます。
たとえば、クライアントが LoginGraceTime 秒 (デフォルトでは 120 秒、古い OpenSSH バージョンでは 600 秒) 以内に認証しない場合には、スレッドセーフではない関数を利用することになるため、SIGALRMを使用して free() の呼び出しを中断し、ヒープを不整合な状態のままにして、SIGALRM ハンドラ内で free() の別の呼び出し中に、この不整合な状態を悪用することができます。
これは2020年10月 (OpenSSH 8.5p1) でのコミット 752250c (「OpenSSH のログ インフラストラクチャの改訂」) が受け入れられた際に、SIGALRMハンドラで呼び出されるsigdie()で
(以下はOpenSSH8.4P1のソース)
172 void
173 sigdie(const char *fmt,...)
174 {
175 #ifdef DO_LOG_SAFE_IN_SIGHAND
176 va_list args;
177
178 va_start(args, fmt);
179 do_log(SYSLOG_LEVEL_FATAL, fmt, args);
180 va_end(args);
181 #endif
182 _exit(1);
183 }
と元々なっていたものから
(以下はOpenSSH8.5P1のソース)
447 void
448 sshsigdie(const char *file, const char *func, int line, int showfunc,
449 LogLevel level, const char *suffix, const char *fmt, ...)
450 {
451 va_list args;
452
453 va_start(args, fmt);
454 sshlogv(file, func, line, showfunc, SYSLOG_LEVEL_FATAL,
455 suffix, fmt, args);
456 va_end(args);
457 _exit(1);
458 }
と、「 #ifdef DO_LOG_SAFE_IN_SIGHAND」が抜け落ちてしまったことが原因による一種のリグレッションであり、その意味で「regSSHion」と呼ばれる原因になっています。
攻撃
以下、Qualysisのテストにより判明した攻撃にかかる時間です。
- i386 で古い OpenSSH の場合(実験環境ではSSH-2.0-OpenSSH_3.4p1 Debian 1:3.4p1-1.woody.3の場合)、600 秒 (LoginGraceTime) あたり 10 件の接続 (MaxStartups) が受け入れられるとすると、リモートでの特権Shellを取得するのに平均で約1週間かかります。
- SSH-2.0-OpenSSH_4.2p1 Debian-7ubuntu3の場合、120 秒 (LoginGraceTime) ごとに 10の接続 (MaxStartups)が受け入れられる場合には、リモートでの特権Shellを取得するのに平均で約1~2日かかります。
- SSH-2.0-OpenSSH_9.2p1 Debian-2+deb12u2の場合、ASLRとNXがあるため、120 秒 (LoginGraceTime) ごとに 100 の接続 (MaxStartups) が受け入れられる場合には、約3~4時間が攻撃にかかります。しかしglibc のアドレスを正しく推測できるのはASLRのために難しくなり、リモートでの特権Shellを取得するには平均で約6~8時間かかります。
緩和策
そもそも今回の脆弱性はLoginGraceTime(ログインを試みることのできる接続時間)以内に認証されない場合の処理から発生しているため、sshdを更新できない場合には/etc/ssh/sshd_configでLoginGraceTimeを0(無制限)にすることで、今回の脆弱性を迂回することができます。
ただしこれを行った場合には、ログインを試みることのできる接続時間が無制限になるため、今度はDoS攻撃(MaxStartups接続の枯渇)に対して脆弱になるため、可能な限りsshdを更新した方が良いと思います。
影響
こちらの脆弱性ですが、単にRed HatやUbuntuといったLinux系だけではなく、SSHをログインに利用している多くの機種に影響が出ています。
OS:
- Red Hat
- Debian
- Ubuntu
- SuSE
- Rocky Linux
- Alma Linux
- Microsoft
クラウドベンダー
- Amazon
- Microsoft
ネットワーク/HW
- Cisco
- Fortigate
- VMWare(Broadcom)
参考情報
- Qualys Security Advisory: 「regreSSHion: RCE in OpenSSH’s server, on glibc-based Linux systems(CVE-2024-6387)」
- SIOS Securityブログ「OpenSSHの脆弱性(regreSSHion: CVE-2024-6387)と9.8リリース 」
- GitHub:「 Portable OpenSSH(OpenSSHのソースコード)」
- JPCERT CC:「SIG30-C. シグナルハンドラ内では非同期安全な関数のみを呼び出す」
2. “PKFail”セキュアブートバイパスの脆弱性で数百万台のデバイスが対象に
個人ユーザー・企業ユーザー向けのx86/ARMのPCで、セキュアブートをバイパスできる脆弱性”PKFail”が見つかりました。この結果、IntelやAcerなど、さまざまなベンダーが提供する多くの種類のデバイスが影響を受ける模様です。
ここでは、この”PKFail”について見ていきたいと思います。
一次情報源
CVE情報
本記事の執筆時点(07/30/2024)では、本脆弱性にCVEはアサインされていません。CERT/CCではVU#455367として脆弱性の番号が振られている模様です(記事執筆時点では未公開)。
脆弱性情報
2024年初頭、Binarly 研究チームはAmerican Megatrends International (AMI)がテストプラットフォーム用に作成したプラットフォームキー(PK)が漏洩して公開されていることを発見しました。
セキュアブートは、デジタル署名を使用して、ブートローダー、OS、ドライバなどの認証を行い、署名されていない不正なソフトウェアやマルウェアなどが起動時に実行されることを防ぐものです。PKは、このセキュアブートでハードウェアデバイスとファームウェア間の信頼関係を確立するために使われています(セキュアブート、およびPKに関しては、マイクロソフトの「Windows セキュア ブート キーの作成と管理のガイダンス」に詳しく載っています)。
そもそもIntel がサンプルコードとして配布したIntel Boot Guardから漏洩した秘密キーが本番環境で使用され、複数のベンダーに影響を与えているという重大なサプライチェーンセキュリティインシデントを2023年にBinarly研究チームは発見していました。
- 「Leaked MSI source code with Intel OEM keys: How does this affect industry-wide software supply chain?」
- Intel Boot Guardの秘密鍵など1.5TBの機密ファイルがMSIへのハッキングで流出(2023)
このインシデント以降、Binarlyでは漏洩したキーの検出を行うように調査を行っており、その結果、今回のインシデントが発覚した模様です。
影響範囲
GitHub上の「Detected Products vulnerable to PKfail」で影響するベンダーと製品のリストが公開されていますが、あまりにも多いため現時点で判明しているベンダーだけを下記に記します。逐次更新されている模様ですので、詳しくはGitHub上のリンクを確認して下さい。
- Acer
- Dell
- Fujitsu
- Gigabyte
- HP
- Intel
- Lenovo
- Supermicro
検出方法
Binarly研究チームは、今回のインシデントに関係しているかどうかを簡単に調べるために、セキュリティ コミュニティ全体が利用できる無料のスキャン ツール を作成して公開しています。
参考情報
- PKfail: Untrusted Platform Keys Undermine Secure Boot on UEFI Ecosystem
- Windows セキュア ブート キーの作成と管理のガイダンス
- Leaked MSI source code with Intel OEM keys: How does this affect industry-wide software supply chain?
- Intel Boot Guardの秘密鍵など1.5TBの機密ファイルがMSIへのハッキングで流出(2023)
- Detected Products vulnerable to PKfail
3. Cisco Smart Software Manager On-Premの脆弱性(Critical: CVE-2024-20419)
Cisco Smart Software Manager On-Prem(Cisco SSM On-Prem)に、リモート攻撃者が管理ユーザーを含む任意のユーザーのパスワードを変更できる脆弱性が見つかりました。こちら、攻撃する際に認証も必要なく、管理ユーザーのパスワードも変更できるなど、かなり危険性の高い脆弱性です。
一次情報源
CVE情報
公開されたCVEは以下になります。
- CVE-2024-20419
- 影響する製品
- Cisco SSM On-Prem
- Cisco Smart Software Manager Satellite(SSM Satellite)
- CVSS
- Base Score: 10.0 Critical
- Vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H/E:X/RL:X/RC:X
- Cisco Smart Software Manager On-Prem(SSM On-Prem)の認証システムの脆弱性により、認証されていないリモート攻撃者が管理ユーザーを含む任意のユーザーのパスワードを変更できる可能性があります。 この脆弱性は、パスワード変更プロセスの不適切な実装が原因で発生します。 攻撃者は細工した HTTP リクエストを送信することで、任意のユーザーの権限で Web UI または API にアクセスできる可能性があります。
- 影響する製品
参考情報
7月のまとめ
7月ですが、他にもSolarWindsの脆弱性(CVE-2024-23469, CVE-2024-23466, CVE-2024-23467, CVE-2024-28074, CVE-2024-23471, CVE-2024-23470, CVE-2024-23472, CVE-2024-23475)や、NetGearのXSS脆弱性(PSV-2023-0122)、Windowsのゼロデイ脆弱性(CVE-2024-38112)など気になる脆弱性がたくさん出ています。皆様も使用ベンダーからの情報に気をつけて、きちんと更新を行うように気をつけてください。
<著者> 面 和毅
サイオステクノロジー株式会社 上席執行役員
OSS/セキュリティエバンジェリスト
OSSのセキュリティ専門家として20年近くの経験があり、主にOS系のセキュリティに関しての執筆や講演を行う。大手ベンダーや外資系、ユーザー企業などでさまざまな立場を経験。
2015年からサイオステクノロジーのOSS/セキュリティエバンジェリストとして活躍中。また、ヒートウェーブ株式会社でも講師として活動中。
専門分野はSELinuxを含むOSのアクセス制御、AntiVirus、SIEM、脅威インテリジェンス。
「脆弱性研究所」の最新話は、メールマガジンにてもご案内致しています。是非JAPANSecuritySummit Updateのメールマガジンにご登録ください。
メールマガジンの登録はこちらからお願いします
最速! 危険度の高い脆弱性をいち早く解説「脆弱性研究所」の過去の記事はこちらから