เจาะโมเด็มนับล้านเครื่อง และสืบหาคนที่แฮ็กโมเด็มของฉัน

 (samcurry.net)
2 คะแนน โดย GN⁺ 2024-06-05 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • เมื่อ 2 ปีก่อน ระหว่างทดสอบช่องโหว่ที่บ้าน ผู้เขียนพบเรื่องผิดปกติ
  • ผู้เขียนเปิด HTTP server บนเครื่อง AWS เพื่อให้เซิร์ฟเวอร์ที่มีช่องโหว่ดึงไฟล์ไป
  • ทุกอย่างดูเหมือนตั้งค่าไว้ถูกต้องแล้ว แต่พอจะกลับไปทดสอบช่องโหว่ ก็มี log ที่ไม่คาดคิดปรากฏขึ้น
  • มีใครบางคนดักจับแล้วส่ง HTTP request เดิมซ้ำอีกครั้งหลังจากนั้น 10 วินาที ระหว่างเครือข่ายที่บ้านกับเครื่อง AWS
  • ทราฟฟิกนี้ควรเข้าถึงไม่ได้และไม่ควรมีตัวกลางใด ๆ
  • สิ่งแรกที่นึกถึงคือคอมพิวเตอร์ของตนถูกแฮ็ก และแฮ็กเกอร์กำลังเฝ้าดูทราฟฟิกอย่างใกล้ชิด
  • ผู้เขียนตรวจสอบว่าอาการเดียวกันเกิดบน iPhone ด้วยหรือไม่ และพบว่า IP address ที่ไม่รู้จักดักจับแล้วส่ง HTTP request ของทั้งคอมพิวเตอร์และ iPhone ซ้ำอีกครั้ง
  • มีความเป็นไปได้สูงว่า ISP, โมเด็ม หรือ AWS ถูกเจาะ
  • เพื่อจะตัดความคิดสุดโต่งที่ว่า AWS ถูกแฮ็กทิ้งไป ผู้เขียนจึงเปิดเครื่องบน GCP และพบอาการเดียวกัน
  • ความเป็นไปได้เดียวที่เหลือคือโมเด็มถูกแฮ็ก แต่คนโจมตีเป็นใคร? เมื่อตรวจสอบเจ้าของ IP address ก็พบว่าเป็นของ DigitalOcean
  • IP นี้ถูกใช้เป็นฟิชชิงหลายเว็บไซต์และ mail server ในช่วงไม่กี่ปีที่ผ่านมา
  • เพราะอุปกรณ์ที่ถูกเจาะยังทำงานอยู่ ผู้เขียนจึงถอดปลั๊กและเก็บใส่กล่องไว้
  • จากนั้นไปที่ร้าน Cox เพื่อคืนโมเด็มที่ถูกแฮ็กและรับเครื่องใหม่
  • หลังติดตั้งโมเด็มใหม่ พฤติกรรมแปลก ๆ ก็หยุดลง แต่ก็ยังไม่รู้ว่าโมเด็มถูกเจาะได้อย่างไรแน่
  • 3 ปีต่อมา ระหว่างไปเที่ยวกับเพื่อนผู้เชี่ยวชาญด้านความปลอดภัย ผู้เขียนเล่าเหตุการณ์นี้ให้ฟัง และพวกเขาก็สนใจจนเริ่มสืบสวน
  • เมื่อดูโดเมนที่ IP address นี้จดทะเบียนไว้ ก็พบโดเมนที่สร้างด้วยอัลกอริทึมจำนวนมาก ซึ่งบ่งชี้ว่าเป็น C&C server
  • ผู้โจมตีทำกิจกรรมอันตรายหลายอย่างจาก IP เดียวกัน แต่กลับไม่ถูกระงับตลอด 3 ปี ทำให้เดาเจตนาได้ยาก
  • เนื่องจากโมเด็มใหม่ก็เป็นรุ่นเดียวกัน ผู้เขียนจึงพิจารณาความเป็นไปได้ที่ผู้โจมตีอาจเจาะกลับเข้ามาอีกครั้ง
  • ผู้เขียนจับตาไปที่โปรโตคอล TR-069 ซึ่ง ISP ใช้จัดการอุปกรณ์ และตั้งข้อสันนิษฐานว่าหากโจมตี infrastructure ของเครื่องมือซัพพอร์ตได้ ก็อาจยึดโมเด็มได้
  • จากการวิเคราะห์ JavaScript ของ Cox Business portal พบ API path มากกว่า 700 รายการ โดย API ที่เข้าถึงอุปกรณ์และบัญชีลูกค้าได้มากที่สุดคือ accountequipment, datainternetgateway, account
  • ผู้เขียนพบช่องโหว่ที่ข้ามการยืนยันตัวตนได้ เพียงส่ง HTTP request ซ้ำ ๆ ก็สามารถรันคำสั่งโดยไม่ได้รับอนุญาต
  • ยืนยันได้ว่าสามารถสื่อสารกับอุปกรณ์ของใครก็ได้โดยตรงผ่าน MAC address และ Cox ให้บริการลูกค้านับล้านราย
  • ผู้เขียนพิสูจน์ได้ว่าสามารถเขียนทับการตั้งค่าอุปกรณ์ เข้าถึงเราเตอร์ และรันคำสั่งบนอุปกรณ์ได้ ซึ่งเทียบเท่าสิทธิ์ของทีมซัพพอร์ตเทคนิคของ ISP
  • นี่คือช่องโหว่ที่ทำให้สามารถเปลี่ยนการตั้งค่าโมเด็มนับล้านเครื่อง เข้าถึง PII ของลูกค้า และได้สิทธิ์ระดับทีมซัพพอร์ตของ ISP โดยไม่ต้องมีเงื่อนไขล่วงหน้า
  • สถานการณ์การโจมตีมีดังนี้
    1. ค้นหาลูกค้า Cox Business ผ่าน API
    2. ใช้ UUID เพื่อดึง MAC address ของอุปกรณ์ อีเมล เบอร์โทร ที่อยู่ และ PII อื่น ๆ ของลูกค้า
    3. ใช้ MAC address เพื่อดูรหัสผ่าน WiFi และอุปกรณ์ที่เชื่อมต่ออยู่
    4. รันคำสั่งตามอำเภอใจ เปลี่ยนคุณสมบัติอุปกรณ์ และยึดบัญชี
  • ผู้เขียนรายงานช่องโหว่นี้ให้ Cox ทราบ และภายใน 6 ชั่วโมง บริษัทก็ปิดกั้น API และเริ่มแก้ปัญหาด้านการยืนยันตัวตน
  • ในบรรดา API ที่เปิดเผยมากกว่า 700 รายการนั้น มีจำนวนมากที่ให้ความสามารถระดับผู้ดูแลระบบ และทั้งหมดมีปัญหาเรื่องสิทธิ์แบบเดียวกัน
  • กรณีนี้แสดงให้เห็นถึงช่องโหว่ในชั้นความไว้วางใจระหว่าง ISP กับอุปกรณ์ของลูกค้า
  • ผู้เขียนยังคงสงสัยว่าโมเด็มของตนถูกแฮ็กอย่างไรแน่ และก็ยังไม่เข้าใจว่าทำไมผู้โจมตีจึงส่งทราฟฟิกซ้ำ
  • ยินดีรับทฤษฎีหรือความเห็นที่เกี่ยวข้อง

ความเห็นของ GN⁺

  • ช่องโหว่ความปลอดภัย: บทความนี้แสดงให้เห็นว่าช่องโหว่ด้านความปลอดภัยของ ISP สามารถสร้างผลกระทบที่ร้ายแรงเพียงใด โดยเฉพาะความสามารถในการเปลี่ยนการตั้งค่าอุปกรณ์จากระยะไกลที่อาจถูกนำไปใช้ในทางที่ผิดได้
  • ความปลอดภัยของ API: เน้นย้ำความสำคัญของ API security ช่องโหว่อย่างการข้ามการยืนยันตัวตนสามารถนำไปสู่ปัญหาความปลอดภัยร้ายแรงได้
  • การปกป้องข้อมูลผู้ใช้: เตือนถึงความเสี่ยงที่ข้อมูลส่วนบุคคลของลูกค้าและการตั้งค่าอุปกรณ์อาจถูกเปิดเผยได้ง่าย ISP ควรใช้มาตรการความปลอดภัยที่เข้มแข็งกว่านี้เพื่อปกป้องข้อมูลดังกล่าว
  • ความเข้าใจเชิงเทคนิค: อธิบายรายละเอียดทางเทคนิคในแบบที่แม้แต่วิศวกรซอฟต์แวร์ระดับเริ่มต้นก็เข้าใจได้ ทำให้เรียนรู้วิธีตรวจจับและแก้ไขช่องโหว่ด้านความปลอดภัยได้
  • การเสนอทางเลือก: เพื่อแก้ปัญหาแบบนี้ การใช้อุปกรณ์เครือข่ายและโปรโตคอลความปลอดภัยที่ปลอดภัยกว่ามีความสำคัญ และอาจพิจารณา ISP หรือโซลูชันด้านความปลอดภัยอื่น ๆ ได้

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 2024-06-05
ความเห็นจาก Hacker News
  • น่าประทับใจที่ Cox รับมืออย่างมีความรับผิดชอบ โดยไม่ปฏิเสธปัญหาหรือโจมตีผู้แจ้งข่าวสาร อยากอ่านบทความติดตามผลว่า bug คืออะไร
  • รู้สึกอึดอัดกับสถานการณ์ที่ ISP บังคับให้ใช้โมเด็มหรือเราเตอร์ของตัวเอง อาจมีโอกาสที่เราเตอร์ของ AT&T จะถูกแฮ็กได้ แต่ยังดีที่มี HTTPS ช่วยไว้
  • เป็นบทความและการสืบสวนที่ยอดเยี่ยม ดูเหมือนว่าอินเทอร์เฟซผู้ดูแลระบบแบบโลคัลของเราเตอร์ Nokia จะยืนยันตัวตนได้ไม่ถูกต้อง แม้จะเปลี่ยนค่าบางอย่างโดยตรงไม่ได้ แต่ก็สามารถแฮ็กหน้าเพจเพื่อเปลี่ยนได้
  • เราเตอร์จำนวนมากต้องอัปเดตเฟิร์มแวร์ด้วยตนเอง เราเตอร์ GL.iNet เพิ่งมีช่องโหว่ RCE เมื่อไม่นานมานี้ จึงแนะนำให้ดำเนินการอย่างการอัปเดตเฟิร์มแวร์และปิดการเข้าถึง SSH
  • ยังสงสัยอยู่ว่าผู้โจมตีดักทราฟฟิก HTTP ได้อย่างไร Cox น่าจะตรวจสอบเวอร์ชันเฟิร์มแวร์และแก้ปัญหาผ่านการอัปเดตอัตโนมัติได้
  • แม้ Cox จะอ้างว่าในอดีตช่องโหว่นี้ไม่เคยถูกนำไปใช้โจมตี แต่ก็เชื่อได้ยาก เครือข่ายดูหละหลวม
  • น่าตกใจที่พบช่องโหว่ใหญ่ในบริษัทเทคโนโลยีขนาดใหญ่ บทความยอดเยี่ยมมาก แต่ช่องโหว่นี้ให้อภัยไม่ได้
  • สงสัยว่าคนที่รายงานช่องโหว่นี้ได้รับรางวัลหรือไม่ เขาสร้างคุณูปการอย่างมาก แต่ดูเหมือนจะไม่ได้รับอะไรเลย ซึ่งเป็นการดูหมิ่นอย่างมาก
  • เหตุผลที่ Cox อ้างว่าในอดีตไม่เคยถูกโจมตีน่าจะเป็นเพราะมี log หรือข้อมูล audit ไม่เพียงพอ
  • เนื้อหาบทความยอดเยี่ยม แต่ผู้โจมตีที่ตั้งใจจริงอาจปลอมตัวเป็นช่างเทคนิคของ Cox เพื่อเข้าถึงได้ ISP ควรใช้การตั้งค่าที่ปิดการเข้าถึงระยะไกลเป็นค่าเริ่มต้น