セキュリティ

Danfoss SM-800Aにおける複数のリモートコード実行脆弱性

Multiple remote code execution vulnerabilities in danfoss sm-800A (midnightblue.nl)

8 pointsby rros2026年11月12日1 コメント

要約

Danfoss SM-800Aコントローラーの最新ファームウェアバージョン（5.3.2まで）において、6件の認証前リモートコード実行（RCE）ゼロデイ脆弱性が発見されました。これらの脆弱性は、スタックベースのバッファオーバーフローに起因し、デバイスの乗っ取り、永続的なアクセス、またはサービス不能状態を引き起こす可能性があります。対策として、ネットワークからの直接アクセスを制限することが推奨されています。

全文翻訳

Danfoss SM-800Aにおける複数のリモートコード実行脆弱性

背景

10月11日にフランスで始まった攻撃波に先立ち、複数のDanfoss製品ライン（AK SM-800、AK SM-800A、AK-EM100）におけるいくつかの脆弱性が、SynAcktiv（2023年
[1,2））、Claroty（2025年
[3））、およびDIVD/HackDefense（2023年
[4）によって既に文書化されていました。

これらの脆弱性には、広く議論されたcode-of-the-day認証バイパス（CVE-2025-41450）、AK-SM800AにおけるOSコマンドインジェクション（CVE-2023-25915、CVE-2025-41451）、およびパス・トラバーサル（CVE-2023-25914）の脆弱性、さらにEOLのAK-EM100におけるSQLインジェクション（CVE-2023-22583）およびOSコマンドインジェクション（CVE-2023-25911）の脆弱性が含まれていました。

これらの脆弱性のすべては、驚くほど発見・悪用が容易であり、最初の公開Proof-of-Concept（PoC）エクスプロイトは、フランスの攻撃から48時間以内にドロップされました
[5、6） - 11月2日の第2波攻撃に先行して。

Censysによると、依然として数百のDanfossシステムがオンラインで公開されています（ただし、かなりの部分がすでにハニーポットになっていることは間違いありません）。また、1000を超えるCopelandおよびDixell製冷蔵コントローラーも存在します。さらに、ターゲットにされなかった類似ベンダー（Eliwellなど）のコントローラーも数百台公開されたままです。

［画像］

2026年10月11日時点のDanfoss、Copeland/Dixell、およびEliwellシステムのCensys検索

‍

これらすべてから言えることは、これらのコントローラーの証明可能な劣等なセキュリティ体制と、深刻な影響を及ぼすいくつかの攻撃波にもかかわらず、コントローラーは依然としてパブリックインターネットに公開されているということです。これは理解できる理由（スーパーマーケットチェーンは、リモートメンテナンスを停止したり、VPN経由でアクセスを制限したりすると、SLAや保険条件の違反リスクを負うことがあるため、簡単なシステム変更ではありません）によるものですが、防御側が、パッチを適用するだけでリスクが十分に軽減されたと考える罠に陥らないことが極めて重要であると考えています。これはDanfossのガイダンスでも示唆されています。

これを実証するために、最新のDanfoss AK-SM800Aファームウェアバージョン（執筆時点では5.3.2）を調査し、1時間のマニュアル調査（AIは不要…）で、6件の認証前リモートコード実行0デイ脆弱性を発見しました。

［画像］

Danfoss AK-SM800A

‍

現在、Danfossと協調脆弱性開示プロセスを進めており、開示が整理されるまで技術的な詳細は控えますが、これらのコントローラーに対する継続的な標的化のため、資産所有者がこれらのデバイスの全体的なセキュリティ体制について現実的な見解を持ち、断片的なパッチ適用に依存するのではなく、適切な対策を講じることが重要であると考えています。

‍

概要

CVE: 未定
‍ベンダー: Danfoss
影響を受ける製品: AK-SM800A
影響を受けるバージョン: 5.3.2まで全て
脆弱性の種類: 複数（6件）のスタックベースバッファオーバーフロー
‍潜在的な影響: デバイス全体の乗っ取り、永続的なアクセス（リセット後も可能）、永続的なサービス不能（デバイスを動作不能にする）
緩和策: VPN、プライベートAPN、または非常に制限的なIPホワイトリストACLによるネットワーク公開の制限

‍

60分とファームウェアイメージ

初期調査とセットアップ

Danfoss AK-SM800Aのファームウェアイメージは、ウェブサイトからダウンロードでき、アプリケーションロジックを処理する7-zip圧縮されたARMバイナリが含まれています。Danfoss AK-SM800Aコントローラーは、i.MX6プロセッサ上でDanuxというカスタムYoctoベースのLinuxディストリビューションを実行しています。

まず、ファームウェアの仮想環境をセットアップしましょう。ここでは、カーネルを含むシステム全体をエミュレートするのではなく、バイナリをユーザランドでエミュレートするのが最も簡単な方法です。ファイルシステムをマウントした後、qemu-armel-static をそこにコピーして、次のコマンドを実行するとシェルが表示されます。

$ sudo chroot . /qemu-armel-static /bin/sh
sh-4.4#

‍

Clarotyが指摘したように、SM800AプラットフォームはNGINXリバースプロキシ、多数のCGIハンドラー、およびアプリケーションロジックを処理する独立したプロセスで構成されています。.cgi サフィックスで終わるURLへのリクエストは、sm_app 実行可能ファイルによって作成されたタスクに転送されます。

sm_app は、デバイス上で発生するほぼすべてのことを担当する巨大なモノリシックアプリケーションであることが判明しました。これは、ユーザーランドプロセスで実行されるミニリアルタイムオペレーティングシステム（RTOS）に似ています（リフト＆シフトプラットフォーム移行の結果として一般的な組み込みアーキテクチャの選択）。52個のエントリからなるタスク（スレッド）リストがあり、その中には Task_Modbus_drv_task、Task_Ethernet、Task_IOHandler、Task_Web などがあります。この環境でsm_appを実行すると、デバイスやドライバーの大部分が欠落しているため、ほぼ確実にクラッシュします。バイナリに一時的なパッチを適用してクラッシュを回避することは可能かもしれませんが、おそらく苦痛を伴うでしょう。

幸いなことに、私たちはTask_Webにのみ関心があるので、すべてを修正する代わりに、LD_PRELOADを使用してバイナリに侵入し、メイン（main()）に到達するまで初期化コードをすべて実行させ、そこでコードフローを乗っ取り、ここでは詳しく説明しないフックを適用して、Webサーバーを開始できます。Danuxには便利にもgccが搭載されていることが判明しました。

$ gcc -shared -g -fPIC -o libpreload.so preload.c
$ sudo chroot . /qemu-armel-static -E LD_PRELOAD=/libpreload3.so /danfoss/sm_app
hi from hijacked code

‍

いくつかの追加のマイナーな修正により、エミュレートされたWebサーバーと通信できるようになりました。

$ curl -v -d '' http://127.0.0.1:8080/xml.cgi
*   Trying 127.0.0.1:8080...
* Connected to 127.0.0.1 (127.0.0.1) port 8080
> POST /xml.cgi HTTP/1.1
> Host: 127.0.0.1:8080
> User-Agent: curl/8.5.0
> Accept: */*
> Content-Length: 0
> Content-Type: application/x-www-form-urlencoded
> 
< HTTP/1.1 200
< Date: Sat, 07 Nov 2026 21:44:33 GMT
< Content-Type: text/xml
< Content-Length: 75
< Connection: keep-alive
< Server: Danfoss SM800A
< Access-Control-Allow-Private-Network: true
< Access-Control-Allow-Origin: *
< Access-Control-Allow-Methods: GET, POST, OPTIONS
< Access-Control-Allow-Headers: aksm-auth,Keep-Alive,User-Agent,X-Requested-With,If-Modified-Since,Cache-Control,Content-Type
< Cache-Control: no-store, no-cache
< 
* Connection #0 to host 127.0.0.1 left intact
<?xml version="1.0" encoding="utf-8"?><resp error="4">DEFAULT_STRING</resp>

‍

心配なコードの臭い

最初に行うべきことは、いわゆるコードの臭いとアンチパターンを通じて、コードベースのセキュリティ品質を把握することです。

最初のそのような悪いコードの臭いは、strcpy の極めて寛容な使用です。strcpy() 関数の使用は、サイズパラメータがないため推奨されません。代わりに、関数はヌルバイトに遭遇するまでソースバッファから宛先バッファにバイトをコピーし続けます。これは、ソースバッファがユーザーによって提供された場合にメモリ破損の脆弱性の一般的な原因となります。コードベースには数百のstrcpy呼び出しが存在し、それらは外部から到達可能で認証されていないハンドラ関数の一部です。実際、以前のファームウェアリリースでは、各コマンドハンドラが中央で認証を行うのではなく、それ自体で認証を強制する責任がありました。これにより、認証前の攻撃対象領域が不必要に拡大しました。

［画像］

外部から到達可能な関数におけるstrcpyの広範な使用

‍

次に、バイナリセキュリティメカニズムとエクスプロイト緩和策を確認します。

$ checksec sm_app
[*] '/mnt/SM800A-4.2.4/sm_app'
    Arch:     arm-32-little
    RELRO:    Partial RELRO
    Stack:    No canary found
    NX:       NX enabled
    PIE:      No PIE (0x10000)
    RPATH:    b'$ORIGIN:$ORIGIN/../../sm_gp_lib/Debug/:$ORIGIN/../../sm_fu_lib/Debug/:$ORIGIN/../../sm_df_lib/Debug/:$ORIGIN/../../sm_msgqueue_lib/Debug/:$ORIGIN/../../sm_lz_lib/Debug/:$ORIGIN/../../sm_tm_lib/Debug/:$ORIGIN/../../sm_up_lib/Debug/:$ORIGIN/../../sm_history_lib/Debug/:$ORIGIN/../../sm_thread_lib/Debug/:$ORIGIN/../../sm_fs_lib/Debug/:$ORIGIN/../../sm_at_lib/Debug/:$ORIGIN/../../sm_mutex_lib/Debug/:$ORIGIN/../../sm_lg_lib/Debug/:$ORIGIN/../../sm_system_lib/Debug/:$ORIGIN/../../sm_os_lib/Debug/:$ORIGIN/../../sm_ip_lib/Debug/:$ORIGIN/../../sm_dl_lib/Debug/:$ORIGIN/../../sm_db_lib/Debug/:$ORIGIN/../../sm_tk_lib/Debug/:$ORIGIN/../../sm_session_lib/Debug/'

‍

スタックカナリアと位置独立実行可能ファイル（PIE）が有効になっていないことが判明しました。これらのメカニズムは、何十年もの間メモリ破損防御の定番となっており、最新のARMアプリケーションプロセッサで実行される最新のLinuxディストリビューションでこれらの機能を有効にするには、エンジニアリング作業は一切必要ありません。単に適切なコンパイラフラグを設定するだけです。これらの機能の有効化はUbuntu 17.10でデフォルトになり、数ヶ月前に最後に更新されたネットワーク接続アプリケーションにそれらが有効になっていないという言い訳は全くありません。

さらに懸念されるのは、Danfossの複数の事業部門（Climate Solutions & Electronic Controllersを含む）がセキュア製品開発ライフサイクルのIEC 62443-4-1認証を取得しており、これが目立つように宣伝されていることです。さらに、DanfossはIEC 62443-4-2をサイバーセキュリティ要件の設計と改善の実装の指針となるフレームワークとして明示的に言及しています。資産所有者、システムインテグレーター、および調達担当者は、そのような認証が製品の実際のセキュリティ体制についてどれだけ少ないことを言えるのかを正確に認識すべきです。

‍

［画像］

IEC 62443-4-1証明書（Danfoss Climate Solutions & Electronic Controllersを対象）

‍

脆弱性の発見とPoC開発

Danfossのセキュリティ体制の最初の印象は、過去の脆弱性の性質と相まって、懸念すべきものです。しかし、これがどれほど悪い結果になるかを見るために、最新バージョンのファームウェアを1時間だけ手動で掘り下げるだけで何が見つかるか見てみましょう。

ハーネスを開発し、バイナリをカバレッジ誘導型ファジングにかけることもできます。しかし、それは真剣な努力を要し、コード品質の印象からすると、strcpy() が呼び出されているランダムな場所を調べることにします。最初に検査した関数の1つは、認証されていないエンドポイントで、多数の解析ロジックとstrcpy呼び出しを持つCGIハンドラーであることが判明しました。

影響を受ける正確なエンドポイントは開示しませんが、ワンライナーで簡単に悪用できることを示します。

$ curl -v -d <redacted>"$(echo 'print("A"*768)'|python)"<redacted> http://127.0.0.1:8080/<redacted>.cgi
*   Trying 127.0.0.1:8080...
* Connected to 127.0.0.1 (127.0.0.1) port 8080
> POST /<redacted>.cgi HTTP/1.1
> Host: 127.0.0.1:8080
> User-Agent: curl/8.5.0
> Accept: */*
> Content-Length: 888
> Content-Type: application/x-www-form-urlencoded
>

‍

これにより、プログラム制御フローを乗っ取れる可能性を示す、 nice な SEGFAULT が得られます。

［画像］

‍

検査したコードのわずかな部分だけでも、このような脆弱性が少なくとも5つ存在します。

もちろん、リモートでクラッシュを引き起こすこと自体は悪いことですが、バッファオーバーフローを利用してリモートコード実行を獲得できることは、はるかに悪いことです。経験豊富なエクスプロイト開発者なら誰でも、エクスプロイト緩和策のないARM Linuxで単純なスタックベースのバッファオーバーフローを悪用するのは非常に簡単であることに同意するでしょう。もし同意しないなら、おそらくフロンティアまたはオープンウェイトモデルが彼らに同意させるのを助けてくれるでしょう。

残る唯一の課題（もしそう呼べるなら）は、strcpy() がヌルバイトに遭遇するとコピーを停止するという事実です。リモートコード実行を獲得したい場合、ヌルバイトを含む複数のアドレスを書き込む必要があります。したがって、strcpy() のこの固有の制限を何らかの方法で克服する必要があります。現時点ではアプローチを共有しませんが、それはロケット科学ではありません。また、悪用されるアプリケーションはroot権限で実行されます（当然です）。

協調開示のため曖昧にせざるを得ないため、少なくともPoCとして、私たちの100%職人技、手作り、AIおよびグルテンフリーのエクスプロイトの実行結果を示しましょう。

［画像］

Danfoss SM-800Aでroot権限での完全なRCEを達成
(デモは古いファームウェアバージョンを示していますが、新しいバージョンにも適用されます)

‍

Danfossセキュリティレベルと厳格モード

上記で実証されたエクスプロイトはバージョン3.3.0を対象としていましたが、バグは最新バージョンのファームウェア（執筆時点では5.3.2）にも存在します。

しかし、後のファームウェアバージョンでは、Danfossによってセッション制御とセキュリティレベルの概念が導入されました
[1,2）。Danfossによると、セッション制御は、さまざまなリモートインターフェイス（StoreView Browser、StoreView Web、Alsense、およびサードパーティXML）の認証ルールエンジンです。このセッション制御メカニズムは、前述の個々のハンドラレベルの認証強制に取って代わります。

セッション制御には3つのセキュリティレベルがあります：後方互換、許可、および厳格。4.0から、セキュリティレベル厳格がデフォルトとして設定されました。これは以下を意味します。

HTTPSを強制する
サードパーティXMLリクエストにはユーザー名とパスワードを含めることはできず、セッショントークンはAKSM-authヘッダーで提供する必要があります。

このAKSM-authヘッダーメカニズムは、歴史的にはBase64エンコードされたユーザー名とパスワードを認証キーとして含んでいましたが、現在は初期認証から派生したセッショントークンを含める必要があります
[3）。厳格セキュリティレベルでは、ウェブからアクセス可能な攻撃対象領域のほぼすべてが認証されていないユーザーから隔離されます（上記のエクスプロイトで使用されたバグを含む）。これが、このセキュリティ制御の有効化がCERT-FRの公式緩和策に含まれている理由です。

残念ながら、セッション制御メカニズムにも、少なくとも1件の単純な認証前メモリ破損脆弱性が存在することが判明しました。

実装方法は、別のバイナリsm_fcgi_appを介しています。これは、ユーザーが認証されていると判断した場合にのみすべてのコマンドをNGINXに通過させるWeb Application Firewall（WAF）として機能します。そうでない場合、通過が許可される唯一のコマンドは認証に使用されるgetauthコマンドです。

一見すると、sm_fcgi_appにおけるパーサー差分攻撃の可能性に気づきましたが、より迅速な成功ルートを調査することにしました。別の単純なstrcpyベースの認証前メモリ破損が存在することが判明しました。

‍

$ curl -k -v -d <redacted> -A "$(echo 'print("A"*1536)'|python)" https://127.0.0.1:3443/<redacted>.cgi
... 
> POST /<redacted>.cgi HTTP/1.1
> Host: 127.0.0.1:3443
> User-Agent: AAAAAAAAAAAAAAAA...AAAAAAAAAAAAAAAA
> Accept: */*
> Content-Length: 41
> Content-Type: application/x-www-form-urlencoded
>

‍

執筆時点での最新AK-SM800Aファームウェアで、厳格セッション制御を有効にしてこれを実行すると、SEGFAULTが発生します。これは、さらに努力すれば、別の認証前RCEに変換できます。言うまでもなく、sm_fcgi_appもスタックカナリアとPIEを有効にしていません。これで十分でしょう。もう十分です。

［画像］

‍

永続性とブリッキングのリスク

最後に、これがどれほど悪い結果になるかを正確に把握したいと思います。

一度だけ長時間の解凍サイクルを開始して数千万ドル相当の食品をダメにするのは一つのことですが、防御側の典型的な対応は、影響を受けたコントローラーを工場出荷時リセットし、認証情報をローテーションし、パッチを適用し、厳格セッション制御モードを設定し、おそらくコントローラーをインターネットから隔離することです。しかし、ヒットしたコントローラーは生産でその仕事を続けます。

ここで、攻撃者がこれらのコントローラーに永続化できたと想像してください。彼らは最初のペイロードをトリガーするだけでなく、工場出荷時リセットやファームウェアアップデートを生き残る小さなインプラントを残します。OSレベルのアクセスがあれば、SALTWATER / SEASPYマルウェア（Barracudaデバイス向け）、FIRESTARTERマルウェア（Ciscoデバイス向け）、およびSonicwallマルウェア（すべてファームウェアアップデートを生き残る）で示されているように、典型的なUnixライクデバイスではこれはそれほど難しくありません。

このようなシナリオでは、攻撃者はリモートアクセスを維持するか、または2番目（または3番目…）の攻撃のために時間トリガーペイロードを残すことができます。これにより、食品の新しいバッチをダメにすることでダメージが増加します。あるいは、攻撃者は単にフラッシュメモリを消去し、/または悪意のあるファームウェアアップデートをプッシュしてコントローラーをブリックし、2025年12月のポーランド電力網への攻撃中に展開されたTTPと同様に、高価で時間のかかる交換を必要とするように、それらを永久に動作不能にする可能性があります。

どちらのアプローチもAK-SM800Aコントローラーに対して実行可能であるように思われます。なぜなら、責任のあるワンタイムプログラマブル（OTP）ヒューズレジスタの一部をチェックしたことからわかるように、i.MX6のセキュアブート機能を利用していないからです。

‍

潜在的な影響

デバイス全体の乗っ取り: リモートコード実行により、認証されていない攻撃者はAK-SM800Aコントローラーのオペレーティングシステムレベルで任意のコードをリモートで実行できます。これにより、攻撃者はパラメータを変更したり、不要なアクション（解凍操作など）を開始したりしながら、システムログからアクティビティを隠蔽できます。さらに、セキュアブート機能の欠如は、RCEを持つ攻撃者がアクセスを維持するためにコントローラーに永続的にインプラントを埋め込むか、または後でセカンダリペイロードをトリガーすることを可能にします。深いイントロスペクションとフォレンジック機能なしでは、デバイスがファームウェアレベルでインプラントされているかどうかを判断することは（工場出荷時リセット後でも）不可能です。

‍

機器の損傷（ブリッキング）: セキュアブートの欠如により、RCEを持つ攻撃者は、デバイスを動作不能にし、特別なハードウェア介入（例：フラッシュメモリの消去や無限ブートループの発生）なしでは回復不能にする悪意のあるファームウェアをプッシュできます。このような'ブリッキング'またはワイパーアプローチは、完全なデバイス交換を必要とします。このようなシナリオの危険性は、特にOT機器に対して、および攻撃者によるそのようなTTPの展開は、Midnight Blueの以前のブログ投稿
[1,2）で強調されてきました。これにより、コントローラーの交換に時間がかかるため、フリーザーが数日間またはそれ以上利用できなくなる可能性があります。

‍

緩和策

上記のすべてを考慮すると、断片的なパッチ適用や厳格セッション制御の有効化は、基本的なエクスプロイト緩和策を欠き、1時間のカジュアルな調査で複数の認証前RCEをもたらす根本的に欠陥のあるコードベースに対して、セキュリティと人員リソースの最小限のROIしか得られないため、リソースの誤配分であると考えています。

代わりに、資産所有者およびシステムインテグレーターが、すべてのDanfoss、Copeland、およびDixellコントローラーに対して、そしてできれば他のベンダーの類似コントローラーに対しても、以下の行動を取ることを強く推奨します。

インターネットに公開されているコントローラーを棚卸しする。これは、資産所有者のパブリックIP範囲だけでなく、システムインテグレーターの4Gモデム経由のものも含む。
‍
コントローラー管理インターフェイスが、VPN、プライベートAPN、または非常に制限的なファイアウォール強制IPホワイトリスト（広範なIPジオフェンシングまたはブラックリストは十分ではありません）のいずれかを通じてのみアクセス可能であることを確認する。
CERT-FRの推奨事項に従い、IPホワイトリストは中間的な緩和策であり、設定ドリフトと変更管理の課題のリスクにより、長期的に持続可能ではありません。

‍