LTESniffer: เครื่องดักฟัง LTE ดาวน์ลิงก์/อัปลิงก์แบบโอเพนซอร์ส
(github.com/SysSec-KAIST)- LTESniffer เป็นเครื่องมือโอเพนซอร์สที่จับข้อความไร้สายดาวน์ลิงก์·อัปลิงก์ระหว่างสถานีฐาน LTE กับสมาร์ตโฟน โดยดึง DCI และ RNTI จาก PDCCH ก่อน แล้วจึงถอดรหัส PDSCH·PUSCH เพื่อวิเคราะห์ทราฟฟิกข้อมูล
- ไม่สามารถถอดรหัสข้อความที่เข้ารหัสได้ และวิเคราะห์ได้เฉพาะส่วนที่ไม่ได้เข้ารหัส เช่น header ของ MAC·physical layer, ข้อความ broadcast จากสถานีฐาน หรือข้อความ plaintext ช่วงเริ่มต้นการเชื่อมต่อเท่านั้น
- API สำหรับงานวิจัยด้านความปลอดภัยรองรับ 3 อย่างคือ identity mapping, IMSI collecting และ UE capability profiling เป็นการนำไปใช้เพื่อเติมเต็มความต้องการ passive sniffer ที่งานวิจัยความปลอดภัย LTE เดิมสมมติไว้ ด้วยการถอดรหัสแพ็กเก็ตโปรโตคอล PDSCH·PUSCH
- ขอบเขตฟีเจอร์ครอบคลุม LTE Advanced·LTE Advanced Pro, อัปลิงก์·ดาวน์ลิงก์สูงสุด 256QAM, FDD, สถานีฐานสูงสุด 20MHz, DCI formats 0/1A/1/1B/1C/2/2A/2B และ transmission modes 1~4
- การถอดรหัสแบบเรียลไทม์ต้องใช้ CPU หลาย physical core และชุด SDR ส่วนการเก็บทราฟฟิกอัปลิงก์มีข้อจำกัดเพราะสัญญาณ UE อ่อน จึงต้องให้ sniffer อยู่ใกล้สมาร์ตโฟน หรือเสริมฮาร์ดแวร์ เช่น เสาอากาศทิศทาง, RF front-end, แอมป์ขยายสัญญาณ
LTESniffer ทำอะไร
- LTESniffer เป็นเครื่องดักฟังโอเพนซอร์สที่จับได้ทั้ง LTE ดาวน์ลิงก์และอัปลิงก์
- ลำดับการทำงานคือถอดรหัส PDCCH ก่อนเพื่อดึง DCI และ RNTI ของผู้ใช้ที่ active อยู่ จากนั้นใช้ข้อมูลนี้ถอดรหัส PDSCH และ PUSCH เพิ่มเติมเพื่อดึงทราฟฟิกข้อมูลอัปลิงก์·ดาวน์ลิงก์
- ในมุมผู้ใช้ทั่วไป นี่คือเครื่องมือสำหรับจับข้อความไร้สาย LTE แบบสองทิศทางที่ส่งไปมาระหว่างสถานีฐานกับสมาร์ตโฟนที่เชื่อมต่ออยู่
- ไม่สามารถถอดรหัสข้อความที่เข้ารหัสได้
- ในข้อความที่เข้ารหัส สามารถวิเคราะห์ได้เฉพาะ ส่วนที่ไม่ได้เข้ารหัส เช่น header ของ MAC·physical layer
- ข้อความ broadcast จากสถานีฐานหรือข้อความช่วงเริ่มต้นการเชื่อมต่อที่ส่งเป็น plaintext สามารถวิเคราะห์ได้ครบถ้วน
API สำหรับงานวิจัยความปลอดภัยและวัตถุประสงค์งานวิจัย
- LTESniffer มี ฟังก์ชัน API 3 รายการ สำหรับแอปพลิเคชันและงานวิจัยด้านความปลอดภัย
- identity mapping
- IMSI collecting
- UE capability profiling
- งานวิจัยด้านความปลอดภัย LTE จำนวนมากสมมติว่ามี passive sniffer ที่สามารถจับแพ็กเก็ตเกี่ยวกับ privacy จากอากาศได้ แต่ระบุว่า sniffer โอเพนซอร์สเดิมไม่สามารถถอดรหัสแพ็กเก็ตโปรโตคอลของ PDSCH และ PUSCH ได้ จึงไม่ตรงตามความต้องการ
- รายละเอียดสรุปไว้ใน paper
- วัตถุประสงค์หลักของ LTESniffer คือสนับสนุน งานวิจัยด้านความปลอดภัย·การวิเคราะห์ ของเครือข่ายเซลลูลาร์
- เนื่องจากเป็นการเก็บข้อมูลผู้ใช้ทั้งอัปลิงก์·ดาวน์ลิงก์ จึงต้องปฏิบัติตามกฎระเบียบท้องถิ่นเกี่ยวกับการ sniff ทราฟฟิก LTE
- ผู้พัฒนาไม่รับผิดชอบต่อการใช้งานเพื่อวัตถุประสงค์ผิดกฎหมาย เช่น การตั้งใจเก็บข้อมูลที่เกี่ยวข้องกับ privacy ของผู้ใช้
ฟีเจอร์ที่รองรับและฐานการพัฒนา
- LTESniffer พัฒนาบน FALCON และใช้ไลบรารี srsRAN
- ขอบเขตหลักที่รองรับมีดังนี้
- การถอดรหัสอัปลิงก์·ดาวน์ลิงก์แบบเรียลไทม์ของช่องควบคุม·ข้อมูล PDCCH, PDSCH, PUSCH
- LTE Advanced และ LTE Advanced Pro
- สูงสุด 256QAM ทั้งอัปลิงก์·ดาวน์ลิงก์
- DCI formats 0, 1A, 1, 1B, 1C, 2, 2A, 2B
- transmission modes 1, 2, 3, 4
-
รองรับเฉพาะ FDD
- สถานีฐานสูงสุด 20MHz
- ตรวจจับ modulation สูงสุดของ UL/DL สำหรับสมาร์ตโฟนแต่ละเครื่องโดยอัตโนมัติ
- ตรวจจับการตั้งค่า physical layer ของแต่ละ UE โดยอัตโนมัติ
- RNTI-TMSI mapping, IMSI collecting, UE Capability Profiling
- อัปเดต v2.1.0 เพิ่มการบันทึกไฟล์ IQ raw data ของ subframe, การถอดรหัสแบบออฟไลน์โดยใช้ไฟล์ที่บันทึกไว้ และการเปิดใช้ API ในโหมดดาวน์ลิงก์
- API โหมดดาวน์ลิงก์ใช้ได้เฉพาะ identity collecting และ mapping API
- รายละเอียดที่เกี่ยวข้องอยู่ใน branch
LTESniffer-record-subframeและ README - อัปเดต v2.0.0 รองรับการใช้ USRP B-series สองเครื่อง ในโหมด sniff อัปลิงก์ และแก้บั๊ก
- รายละเอียดที่เกี่ยวข้องอยู่ใน branch
LTESniffer-multi-usrpและ README
ข้อกำหนดฮาร์ดแวร์·ซอฟต์แวร์
- OS ที่ทำงานได้เสถียรคือ Ubuntu 18.04/20.04/22.04
- การถอดรหัสทราฟฟิก LTE แบบเรียลไทม์ต้องใช้ CPU ประสิทธิภาพสูงที่มีหลาย physical core ในช่วงพีคที่สถานีฐานมีผู้ใช้ active จำนวนมาก
- มีตัวอย่างที่ถอดรหัสทราฟฟิกของสถานีฐานที่มีผู้ใช้ active 150 รายแบบเรียลไทม์บนพีซี Intel i7-9700K
- สเปกแนะนำคือ CPU Intel i7 ที่มี physical core 8 คอร์ขึ้นไป, RAM 16GB ขึ้นไป และ SSD 256GB
- เมื่อ sniff เฉพาะดาวน์ลิงก์ สามารถใช้ SDR ส่วนใหญ่ที่ srsRAN รองรับได้
- ตัวอย่างคือ USRP หรือ BladeRF
- SDR ต้องเชื่อมต่อกับพีซีผ่าน USB 3.0
- หากต้องการถอดรหัสข้อความดาวน์ลิงก์ transmission modes 3·4 ต้องใช้เสาอากาศ RX 2 ตัว
- ถ้ามีเสาอากาศ RX เพียง 1 ตัว จะถอดรหัสได้เฉพาะข้อความดาวน์ลิงก์ transmission mode 1
- GPSDO ช่วยปรับปรุงการซิงก์ในการ sniff ดาวน์ลิงก์ แต่ไม่จำเป็น
- การ sniff อัปลิงก์ต้องฟัง สองความถี่ คืออัปลิงก์และดาวน์ลิงก์พร้อมกัน จึงรองรับการตั้งค่า 2 แบบ
- USRP X310 เครื่องเดียว: ช่อง RX 2 ช่องสามารถจูนไปยังความถี่อัปลิงก์·ดาวน์ลิงก์ที่ต่างกันได้ และ GPSDO เป็นตัวเลือกเสริม
- USRP B-Series 2 เครื่อง: ใช้ B210/B200 แยกสำหรับอัปลิงก์·ดาวน์ลิงก์ และใช้ GPSDO เป็น clock source และ time reference เพื่อซิงก์ USRP ทั้งสองเครื่อง
- ในชุด USRP B-Series 2 เครื่อง GPSDO เป็นสิ่งจำเป็น
ขั้นตอนการติดตั้งและรัน
- ก่อน build จาก source ต้องติดตั้ง UHD 4.0 ขึ้นไป และแนะนำให้ build จาก source
- หลังติดตั้ง dependencies ของ srsRAN และ LTESniffer แล้ว ให้ clone repository และ build ด้วย
cmake,make -j 4 - หลัง build แล้ว ไฟล์ executable จะอยู่ที่
<build-dir>/src/LTESniffer - โหมดการรันหลักมี 3 แบบ
- sniff ทราฟฟิก LTE ดาวน์ลิงก์จากสถานีฐาน
- sniff ทราฟฟิก LTE อัปลิงก์จากสมาร์ตโฟนไปยังสถานีฐาน
- security API
- ก่อนใช้งานบนเครือข่ายเชิงพาณิชย์ ต้องตรวจสอบ กฎระเบียบท้องถิ่น เกี่ยวกับการ sniff ทราฟฟิก LTE
- หากต้องการตรวจสอบสถานีฐานที่สมาร์ตโฟนทดสอบเชื่อมต่ออยู่ รวมถึงย่านอัปลิงก์·ดาวน์ลิงก์ สามารถใช้ Cellular-Z สำหรับ Android ได้
- LTESniffer ต้องเชื่อมต่อกับ cell และความถี่เดียวกันด้วย
เอาต์พุตและการวิเคราะห์
- LTESniffer ให้เอาต์พุตเป็น ไฟล์ pcap ซึ่งสามารถนำไปวิเคราะห์เพิ่มเติมและติดตามแพ็กเก็ตใน Wireshark ได้
- ชื่อไฟล์ที่สร้างแตกต่างกันตามโหมด
- ดาวน์ลิงก์:
sniffer_dl_mode.pcap - อัปลิงก์:
sniffer_ul_mode.pcap - API:
api_collector.pcap
- ดาวน์ลิงก์:
- ไฟล์ pcap จะถูกสร้างในไดเรกทอรีเดียวกับที่รัน LTESniffer
- เพื่อให้ Wireshark วิเคราะห์แพ็กเก็ตที่ถอดรหัสแล้วได้ถูกต้อง ต้องดูคู่มือการตั้งค่าใน
pcap_file_example/README.md - ไฟล์ pcap อัปลิงก์มีทั้งข้อความอัปลิงก์และดาวน์ลิงก์
- หากต้องการดูเฉพาะอัปลิงก์ ให้ใช้ filter
mac-lte.direction == 0 - หากต้องการดูเฉพาะดาวน์ลิงก์ ให้ใช้ filter
mac-lte.direction == 1
- หากต้องการดูเฉพาะอัปลิงก์ ให้ใช้ filter
ข้อจำกัดด้านระยะของการ sniff อัปลิงก์
- ระยะใช้งานได้จริงของอัปลิงก์ใน LTESniffer ถูกจำกัดด้วยประสิทธิภาพของ RF front-end เช่น SDR
- UE เป็นอุปกรณ์พกพาที่ปรับการใช้แบตเตอรี่ให้เหมาะสม จึงมีกำลังสัญญาณอัปลิงก์อ่อนกว่าสัญญาณดาวน์ลิงก์จากสถานีฐานมาก
- หากต้องการจับทราฟฟิกอัปลิงก์ให้สำเร็จ สามารถเพิ่มกำลังสัญญาณที่รับได้ด้วยวิธีต่อไปนี้
- อยู่ใกล้ UE ทางกายภาพ
- ใช้ฮาร์ดแวร์พิเศษ เช่น เสาอากาศทิศทาง, RF front-end เฉพาะทาง, แอมป์ขยายสัญญาณ
ข้อจำกัดและทางเลือกที่ระบุใน FAQ
- GPSDO มีประโยชน์สำหรับการซิงก์ที่เสถียรกว่า แต่ในการ sniff ดาวน์ลิงก์สามารถซิงก์กับสัญญาณ LTE และถอดรหัสแพ็กเก็ตได้แม้ไม่มี GPSDO
- ในการ sniff อัปลิงก์ GPSDO จำเป็นเฉพาะเมื่อใช้ USRP B-series 2 เครื่อง
- ชุด USRP X310 เครื่องเดียวไม่จำเป็นต้องใช้ GPSDO
- ทางเทคนิคแล้ว ทราฟฟิกดาวน์ลิงก์สามารถรันด้วย SDR อย่าง BladeRF ที่ไลบรารี srsRAN รองรับได้เช่นกัน
- อย่างไรก็ตาม การทดสอบฟีเจอร์ดาวน์ลิงก์ของ LTESniffer ทำเฉพาะกับ USRP B210 และ X310 เท่านั้น
- ความถูกต้องตามกฎหมายของการใช้ LTESniffer ต้องตรวจสอบ กฎระเบียบท้องถิ่น เกี่ยวกับการ sniff ทราฟฟิก LTE ที่ไม่ได้เข้ารหัส
- วิธีทดสอบอีกแบบที่เสนอคือการตั้งค่าเครือข่าย LTE ส่วนตัวที่ใช้ srsRAN ภายใน Faraday cage
- เนื้อหาข้อความระหว่างผู้ใช้สองรายมองเห็นได้เฉพาะส่วนที่ไม่ได้เข้ารหัส
- ทราฟฟิกไร้สายระหว่างสถานีฐานกับผู้ใช้ส่วนใหญ่ถูกเข้ารหัส
- ในเครือข่าย LTE มีตัวระบุหลายชนิดที่ปรากฏในเอกสารวิชาการว่าเปิดเผยเป็น plaintext เช่น TMSI, GUTI, IMSI, RNTI
- เอกสารตัวอย่างที่ยกมาคือ Watching the Watchers: Practical Video Identification Attack in LTE Networks
1 ความคิดเห็น
ความคิดเห็นจาก Hacker News
ชอบที่มาตรฐานเครือข่ายมือถือเต็มไปด้วยตัวย่อ
เผื่อใครยังไม่รู้ Q ใน PHICH หมายถึง "request"
ส่วน "ARQ" น่าจะขยายได้เป็น https://en.wikipedia.org/wiki/Automatic_repeat_request
บางคนอาจบอกว่า "Q" ใน "ARQ" จริง ๆ คือ "query" และคนที่ขยายเป็น "request" กำลังประเมินระดับคำศัพท์เฉลี่ยต่ำไป
ส่วนตัวคิดว่าถ้าพิจารณาดูแล้ว มีความเป็นไปได้สูงกว่าว่า Q ไม่ได้หมายถึง "request" หรือ "query" แต่เป็นอีกหนึ่งร่องรอยของ Q code แบบคลุมเครือตามธรรมเนียมที่อยู่ใน https://en.wikipedia.org/wiki/Q_code
นี่คือ Q ใน PHICH: https://github.com/srsran/srsRAN_4G/blob/master/lib/src/phy/...
ตามคอมเมนต์ข้างล่าง q คือ Q ของ reQuest
ดูดีทีเดียว
รองรับเฉพาะ FDD ไม่มี TDD และจำกัดที่ 20MHz เลยมีข้อจำกัดอยู่บ้าง
ดูเหมือนว่าจะทำการถอดรหัสแบบเรียลไทม์ได้ระดับหนึ่งด้วย ซึ่งน่าสนใจ ที่สถานีฐาน งานประมวลผลส่วนใหญ่ถูกจัดการโดยโปรเซสเซอร์ค่อนข้างทั่วไปเหมือนกัน แต่ก็ยังผสานกับฮาร์ดแวร์แน่นแฟ้นกว่าซอฟต์แวร์นี้มาก
เสียดายที่ฮาร์ดแวร์แพงเกินไปสำหรับเอามารัน :'(
เพราะงั้นน่าจะรันบน limesdr ได้
ถ้าอยากถูกกว่านี้ก็อาจลอง antsdr หรือ adalm-pluto: https://github.com/srsran/zynq_timestamping
มีโน้ตที่ดีด้วย: https://www.quantulum.co.uk/blog/private-lte-with-analog-ada...
บางฟีเจอร์ใช้กับดองเกิล rtl-sdr ราคาถูกได้ด้วย เป็นฟอร์กของ https://github.com/Evrytania/LTE-Cell-Scanner รุ่นเก่า
อันนี้ออกนอกเรื่องนิดหน่อย แต่สงสัยว่ามีใครเคยลองดักฟัง DSLบ้างไหม
DSL ยุคใหม่ โดยเฉพาะ VDSL2 โดยพื้นฐานคือสัญญาณความถี่สูงที่วิ่งบนคู่สายบิดเกลียวแบบไม่มีชีลด์ ดังนั้นถ้ามีการแตกแขนงของสายก็น่าจะรั่วและแผ่คลื่นออกมาได้ง่าย
ในทางปฏิบัติก็ดูเหมือนจะเป็นแบบนั้น เพราะนักวิทยุสมัครเล่นในสหราชอาณาจักรบ่นเรื่องนี้กันเยอะ[1] สงสัยว่ายังดีมอดูเลตสัญญาณนั้นได้จริงหรือไม่ หรือมันเป็นแค่สัญญาณอ้างอิงรบกวนที่น่ารำคาญในสเปกตรัมเท่านั้น
[1]: https://rsgb.services/public/publications/vdsl/measuring_and...
แล้วก็มีเสียงแฮนด์เชกของ Adsl2 ด้วย: https://www.youtube.com/watch?v=foPGdfsrskA
จำได้ว่าเคยเห็นของที่ใช้โมเด็มเคเบิล DOCSIS เหมือนกัน แต่หาไม่เจอ :(
ข้อเท็จจริงที่น่าสนใจและไม่ค่อยมีคนรู้คือ โทรศัพท์มือถือดิจิทัลยุคแรก ๆ อยู่ในจุดก้ำกึ่งด้านความยากในการถอดรหัส
ไม่ได้ง่ายเลย แต่ก็ง่ายพอที่จะเจาะได้ การเข้ารหัสถูกทำลายได้จริง
rainbow table มีขนาด 2TB และใช้เวลาหลายเดือนในการสร้าง: https://github.com/0xh4di/GSMDecryption?tab=readme-ov-file
เลยทำให้นึกสงสัยว่าระบบรุ่นหลังจากนั้นก็ยังมีช่องโหว่การถอดรหัสอยู่บ้างไหม ไม่ว่าจะด้วยเหตุผลใดก็ตามหรือเพราะผู้กระทำระดับรัฐบางราย
เป็นงานที่สนุก และก็ดีใจที่ยังมีการใช้โอเพนซอร์สแบบนี้อยู่
เมื่อราว 10 ปีก่อนเคยลองดักฟัง downlink ในแล็บวิจัยความปลอดภัยเครือข่ายของมหาวิทยาลัย
หนึ่งในโปรเจ็กต์คือวัดว่าปริมาณการใช้งานของเซลล์ลดลงแค่ไหนในช่วงปิดเทอมฤดูใบไม้ผลิ อีกโปรเจ็กต์หนึ่งคือดูว่าสามารถทำ timing attack กับหมายเลขโทรศัพท์ที่ทราบและตำแหน่งที่ทราบ เพื่อดึง temporary ID ออกมาได้หรือไม่ แล้วโทรซ้ำเพื่อตรวจว่ามันยังอยู่ในบริเวณนั้นหรือเปล่า
สำหรับผม temporary ID นั้นไม่ temporary พอ อยากกลับไปลองเล่นอีกครั้ง
ยังมี 4G dongle บางรุ่นที่รู้กันว่ามีโหมดดีบักที่พัง ซึ่งสามารถใช้ดึงข้อมูลออกมาได้
LTESniffer บอกว่าเป็นโอเพนซอร์ส แต่ดูเหมือนจะไม่มีไฟล์ LICENSE ระดับบนสุด และไม่มีการตั้งค่าไลเซนส์ใน GitHub repository ด้วย
ถ้าจะให้ครอบคลุมถึงไฟล์ build และไฟล์สนับสนุนอื่น ๆ ก็ควรเพิ่มไฟล์ LICENSE ระดับบนสุดเข้าไป