เจาะชื่อจริงของผู้ใช้ macOS จากเบราว์เซอร์ด้วยการเดาชื่อผ่าน mDNS

 (fingerprint.com)
3 คะแนน โดย GN⁺ 2023-07-14 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • ชื่อโฮสต์ภายในเครื่องเริ่มต้นของ macOS อาจมีชื่อผู้ใช้อยู่ ทำให้เว็บไซต์สามารถค่อย ๆ แคบวงรายชื่อที่เป็นไปได้ผ่าน ความต่างของเวลาการ resolve ชื่อ mDNS ได้โดยไม่ต้องขอสิทธิ์
  • ผู้โจมตีสามารถนำชื่อยอดนิยม 50 ชื่อตามประเทศและเพศมาผสมกับตัวเลือกชื่ออุปกรณ์ และจากการทดลองพบว่าสามารถเดาชื่อผู้ใช้ macOS ได้ถูกต้องเฉลี่ย 65% ของกรณี
  • JavaScript ในเบราว์เซอร์ไม่สามารถเปิด arbitrary UDP socket ได้ แต่สามารถเปรียบเทียบ ความหน่วงของการตอบสนอง ของที่อยู่ .local ได้ผ่านคำขอ fetch, iframe, Image, WebRTC
  • ข้อมูลอย่างเขตเวลา ภาษา ตำแหน่งจาก IP, navigator.language ของ Safari, ความละเอียดหน้าจอ และ screen.isExtended ถูกใช้เพื่อลดจำนวนตัวเลือกของ locale และรุ่นอุปกรณ์
  • แม้การใช้งานจริงจะต่ำและสังเกตได้ง่ายในแท็บ Network ของเครื่องมือนักพัฒนา แต่เทคนิคการสำรวจ mDNS แบบเดียวกันนี้ยังอาจใช้ตรวจหาเครื่องพิมพ์ สมาร์ตทีวี สมาร์ตสปีกเกอร์ และอุปกรณ์ IoT ได้ด้วย

โครงสร้างที่ทำให้ชื่อรั่วจาก local hostname ของ macOS

  • ชื่อจริงของผู้ใช้ macOS สามารถถูกคาดเดาได้จากในเบราว์เซอร์โดยไม่ต้องขอสิทธิ์ และหัวใจสำคัญคือโปรโตคอล mDNS กับรูปแบบ local hostname เริ่มต้น
  • เพียงใช้รายชื่อชื่อยอดนิยม 50 ชื่อตามเพศของประเทศหนึ่ง ก็สามารถตรวจจับชื่อผู้ใช้ macOS ได้ถูกต้องเฉลี่ย 65% ของกรณี
  • Fingerprint ไม่ได้นำเทคนิคนี้ไปใช้ในผลิตภัณฑ์ และไม่ได้ให้บริการติดตามข้ามเว็บไซต์
  • จุดประสงค์ของการเปิดเผยครั้งนี้คือช่วยให้ผู้พัฒนาเบราว์เซอร์แก้เทคนิคประเภทนี้ได้เร็วขึ้น

วิธีการทำงานของ mDNS และ Apple Bonjour

  • multicast DNS เป็นโปรโตคอลสำหรับลงทะเบียน ค้นหา และกระจายชื่ออุปกรณ์บนเครือข่ายภายใน
  • อุปกรณ์อย่างเครื่องพิมพ์จะส่งแพ็กเก็ตลงทะเบียนแบบ UDP ไปยัง IP ภายในที่สงวนไว้ 224.0.0.251 และอาจมี hostname อย่าง HP_LaserJet_Printer.local
  • โดเมนระดับบนสุด .local บ่งชี้ว่า hostname นั้นต้องถูก resolve ผ่าน mDNS
  • เราเตอร์จะกระจายแพ็กเก็ตเหล่านี้ไปยังอุปกรณ์อื่นบนเครือข่ายภายในโดยอัตโนมัติ เพื่อให้อุปกรณ์เหล่านั้นแคช hostname ได้
  • อุปกรณ์จะส่งแพ็กเก็ต query ไปยัง IP ที่สงวนไว้เดียวกันเพื่อค้นหาอุปกรณ์ชื่อเฉพาะที่อาจมีอยู่บนเครือข่าย
  • ตัวอย่าง hostname มีดังนี้
    • johns-mac-mini.local
    • david-ZenBook-UX431DA-UM431DA.local
    • james-iphone.local
    • canon-mf644c.local
    • bedroom-appletv.local
    • dlinkrouter.local
  • บนอุปกรณ์ Apple มีการใช้ mDNS อย่างแพร่หลายในฐานะส่วนหนึ่งของ Apple Bonjour
  • local hostname เริ่มต้นอาจเผยชื่อผู้ใช้ได้ และบน macOS สามารถดูหรือเปลี่ยน local hostname ได้ที่ System Settings > Sharing

วิธีอ้อมเพื่อตรวจสอบ mDNS hostname จากในเบราว์เซอร์

  • mDNS ทำงานบนแพ็กเก็ต UDP จึงไม่สามารถเรียกใช้โดยตรงผ่าน arbitrary UDP socket ในสภาพแวดล้อม JavaScript ของเบราว์เซอร์ได้
  • แต่สามารถทำ timing attack ได้ โดยอาศัยคุณสมบัติที่เบราว์เซอร์พยายาม resolve hostname ใน URL
  • การพิสูจน์แนวคิดใช้วิธีส่งคำขอ fetch แบบ GET ปกติไปยัง device-1.local ที่มีอยู่จริง และ device-2.local ที่ไม่มีอยู่
  • หากที่อยู่ถูก resolve ได้ เบราว์เซอร์จะส่งแพ็กเก็ต TCP ไปยังพอร์ต 80 ซึ่งโดยทั่วไปมีแนวโน้มว่าจะปิดอยู่
  • ในระดับเครือข่ายจะเกิดข้อผิดพลาดต่างกัน
    • device-1.local ที่มีอยู่จริง: ERR_CONNECTION_REFUSED
    • device-2.local ที่ไม่มีอยู่จริง: ERR_NAME_NOT_RESOLVED
  • ใน JavaScript ข้อผิดพลาดทั้งสองแบบจะถูกแมปเป็น Failed to fetch เหมือนกัน จึงไม่สามารถพึ่งชนิดของข้อผิดพลาดเองได้
  • เนื่องจากเครือข่ายภายในทำงานเร็ว hostname mDNS ที่ถูกต้องจึงถูก resolve ได้เร็วกว่าค่า timeout เริ่มต้นของการเชื่อมต่อมาก
  • ในตัวอย่าง ที่อยู่ที่ถูกต้องใช้เวลา 4ms ส่วนที่อยู่ไม่ถูกต้องใช้เวลา 5 วินาที
  • วิธีนี้ให้ผลสม่ำเสมอเพียงพอสำหรับการพิสูจน์แนวคิด และทำงานคล้ายกันในเบราว์เซอร์หลัก
  • ในทางปฏิบัติ นอกจาก fetch แล้ว ยังสามารถทำ timing attack กับการ resolve DNS ผ่าน API เครือข่าย JavaScript เช่น iframe, Image, WebRTC ได้ด้วย

วิธีเดาชื่อผู้ใช้ macOS แบบ brute force

  • local hostname เริ่มต้นของ macOS มีทั้งชื่อผู้ใช้และชื่ออุปกรณ์อยู่ด้วย และรูปแบบจะแตกต่างกันตาม locale ภาษาของระบบ
    • English: <name>s-macbook-pro.local
    • French: macbook-air-de-<name>.local
    • Russian: mac-mini-<name>.local
  • หากใช้วิธีตรงไปตรงมาโดยผสมชื่อยอดนิยม 1,000 ชื่อ, 10 locale ยอดนิยม และชื่ออุปกรณ์ macOS ทั่วไป 5 แบบ จะต้องตรวจสอบ hostname ทั้งหมด 50,000 รายการ
  • ในกรณีนี้ การตรวจสอบทั้งหมดอาจใช้เวลามากกว่า 1 ชั่วโมง
  • กลยุทธ์ที่มีประสิทธิภาพกว่าคือจำกัดขอบเขตการค้นหาให้เหลือ locale เดียว อุปกรณ์เดียว และชื่อที่พบบ่อย 50 ชื่อของ locale นั้น
  • เมื่อจำกัดขอบเขตลง ความแม่นยำจะลดลง แต่เวลาโจมตีจะสั้นลงจนใกล้เคียงสถานการณ์จริงมากขึ้น
  • การเลือก locale อาจอาศัยเขตเวลา ภาษา และตำแหน่งจาก IP ของเบราว์เซอร์
  • Safari เผย locale ของระบบผ่านพร็อพเพอร์ตี navigator.language และค่านี้มักตรงกับ locale ของ hostname เป้าหมาย
  • วิธีอ้อมอีกแบบในการหาประเทศต้นทางของผู้ใช้คือวิธี Apple ID region detection ที่เคยกล่าวถึงก่อนหน้านี้
  • ตัวเลือกอุปกรณ์สามารถคัดให้แคบลงได้จากความละเอียดหน้าจอ
    • ตัวอย่างเช่น ความละเอียด 1728x1117 มีโอกาสสูงว่าเป็น MacBook Pro 16 นิ้ว
    • จอต่อขยายสามารถตรวจจับได้ผ่านพร็อพเพอร์ตี screen.isExtended
    • หากตรวจพบจอต่อขยาย ก็สามารถย้อนกลับไปใช้รายชื่ออุปกรณ์ Apple macOS ที่พบบ่อยที่สุด 3–5 รุ่นเป็นตัวเลือกได้

ข้อจำกัดและความเป็นไปได้ในการประยุกต์ใช้อื่น

  • การโจมตีนี้ ไม่ค่อยใช้งานได้จริง เนื่องจากมีทั้งจุดอ่อนโดยธรรมชาติและข้อจำกัดหลายอย่าง
  • เว้นแต่ว่าเจ้าของเว็บไซต์ตั้งใจจะเปิดเผยตัวตนของผู้เยี่ยมชมโดยเจตนา วิธีนี้มักถูกตรวจพบได้ง่ายในแท็บ Network ของเครื่องมือนักพัฒนาเบราว์เซอร์
  • หากนำวิธีนี้ไปรวมกับ installed applications detection ก็อาจสร้างเว็บไซต์ที่เป็นอันตรายซึ่งแสดงทั้งชื่อจริงของผู้ใช้และตำแหน่งงานโดยอาศัยรายชื่อแอปเฉพาะทางที่ติดตั้งอยู่ได้โดยไม่ต้องขอสิทธิ์
  • แม้อุปกรณ์ Apple ที่รัน macOS จะเป็นตัวอย่างหลัก แต่เทคนิคการสำรวจ mDNS สามารถขยายไปใช้ได้อีกหลายแบบ
  • ยังสามารถใช้ตรวจหาเครื่องพิมพ์ สมาร์ตทีวี สมาร์ตสปีกเกอร์ และอุปกรณ์ IoT ภายในบ้านอื่น ๆ ผ่านการสแกนเครือข่ายภายในได้ด้วย
  • ใช้กับ iPhone และ iPad ได้เช่นกัน โดยมีเงื่อนไขว่าต้องเปิด Wi-Fi syncing หรือฟีเจอร์ Safari remote debug อยู่

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

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

 
GN⁺ 2023-07-14
ความคิดเห็นจาก Hacker News

  • บน macOS ฉันใช้ Little Snitch อยู่ ซึ่งมี UI ที่ดีพอสมควรและสามารถตั้งให้ถามผู้ใช้ในเครื่องอย่างชัดเจนก่อนอนุญาตคำขอเครือข่ายได้
    https://www.obdev.at/products/littlesnitch/index.html
    บางครั้งมันจะติดขัดตอนล็อกอินจากระยะไกล โดยปกติคือเวลาเซสชัน SSH พยายามดาวน์โหลดอะไรใหม่ๆ เช่น NPM ไปดึงองค์ประกอบของ NodeJS มาใช้ ดาวน์โหลดผ่าน SSH ในเทอร์มินัลแบบข้อความก็จะค้าง แล้วพอรู้ว่าต้นเหตุคือ Little Snitch ก็ต้องเดินลงไปที่โต๊ะข้างล่าง ขยับเมาส์ปลุกจอ ปลด screensaver แล้วกด “Allow” ในกล่องโต้ตอบของ Little Snitch
    ก็ถือว่ามันทำงานตามที่ตั้งใจไว้ เพียงแต่เครื่องมือแบบนี้มักตั้งค่าให้อนุญาตคำขอในเครือข่ายภายในแบบเงียบๆ เป็นค่าเริ่มต้น เลยไม่แน่ใจว่ากลเม็ดในโพสต์ต้นฉบับจะใช้ได้กับสภาพแวดล้อมของฉันไหม

    • สำหรับฉัน การตั้ง LittleSnitch ให้อนุญาตเฉพาะชื่อโฮสต์บางตัวจากเบราว์เซอร์เป็นเรื่องที่นึกภาพไม่ออก ฉันมีกฎแบบ “อนุญาตทราฟฟิกทั้งหมดที่ไปยัง 53/80/443” ไม่อย่างนั้นเว็บไซต์ส่วนใหญ่คงทำให้ LittleSnitch เด้งป๊อปอัปเป็นร้อยๆ อัน
    • ฉันใช้ NetFence บน iPhone ที่ jailbreak แล้ว
      พอเห็นว่าแอปต่างๆ แอบเปิดการเชื่อมต่อ socket อะไรบ้างก็น่าตกใจ รวมถึงแอปธนาคารด้วย
      https://havoc.app/package/netfence
    • แต่ Little Snitch ก็ยัง มี IP หลุดออกไป แม้ตอนบล็อก :(
      https://news.ycombinator.com/item?id=35363343
    • ฉันเคยใช้ OpenSnitch ซึ่งเป็นซอฟต์แวร์คล้ายกันบน Linux มันไม่ได้จับอะไรแปลกๆ ได้ แต่ทำให้การใช้งานทั่วไปน่ารำคาญมากพอสมควร
    • ข้อมูลประกอบคือ การ resolve DNS เกิดขึ้นก่อนป๊อปอัปอนุญาต/ปฏิเสธการเชื่อมต่อ ตัวอย่างเช่น www.example.com จะถูก resolve เป็น 1.1.1.1 แต่จะยังไม่เกิดการเชื่อมต่อจริงไปยัง 1.1.1.1 จนกว่าจะกด Confirm
      ถ้าเพิ่ม Pi-hole เข้าไปในเครือข่าย คุณจะไม่เสียใจทั้งเวลา เงิน หรือการลงทุนที่ลงไป

  • มีวิธีป้องกันไม่ให้เว็บไซต์บนอินเทอร์เน็ตวงกว้างส่งคำขอเครือข่ายเข้ามายังเครือข่ายภายในของฉันไหม? นึกไม่ออกเลยว่าทำไมสิ่งนี้ถึงควรถูกอนุญาตโดยปริยาย
    ไม่ได้หมายความว่าอยากชุบชีวิตสิทธิ์แบบ Local Intranet Zone ของ IE กลับมานะ

    • โดยทั่วไปแล้วทำไม่ได้เพราะ CORS เหตุผลเดียวที่ “แฮ็ก” นี้ใช้ได้ก็เพราะจังหวะเวลาของการถูกปฏิเสธต่างกันระหว่างคำขอโดเมนที่ resolve ไม่ได้ กับคำขอที่ resolve ได้แล้วแต่ถูกปฏิเสธ
      แต่ถึงคุณจะรันอะไรบางอย่างอยู่ที่ https://192.168.2.1 เว็บแอปที่รันจาก https://my-own-domain.com ก็จะเข้าถึงไม่ได้ เว้นแต่บริการบน 192.168.2.1 จะอนุญาต my-own-domain.com เป็น Origin
    • Brave เพิ่งเพิ่มฟีเจอร์ที่ ต้องขอสิทธิ์เพื่อเข้าถึงเครือข่ายภายใน
      https://brave.com/privacy-updates/27-localhost-permission/
      โพสต์ HN: https://news.ycombinator.com/item?id=36574775
    • แอปที่มักใช้วิธีนี้ในทางที่ผิดคือ Discord เดสก์ท็อปแอป ซึ่งจะเปิด local port ทิ้งไว้และรอฟังอยู่
      เมื่อเบราว์เซอร์ไปยังหน้าคำเชิญเข้าร่วมช่องของ Discord มันจะส่งคำขอผ่านพอร์ตนี้ไปยัง localhost และส่งต่อ channel ID ให้ไคลเอนต์ จากนั้นแอปก็จะแสดงประสบการณ์แบบเนทีฟ “Join Channel” ได้
      ฉันรู้เรื่องนี้เพราะเห็นว่ามันยังทำงานต่อแม้อยู่ในโหมดไม่ระบุตัวตน และเบราว์เซอร์ก็ล็อกเอาต์จาก Discord ไปแล้วด้วย ไม่ดีเลย โลกเดสก์ท็อปจำเป็นต้องยกระดับ sandboxing ของทุกแอปพลิเคชันอย่างมาก
    • บล็อกได้ด้วย static filter ของ uBlock Origin:
      ||local^$all
      แบบนี้จะบล็อกทุกคำขอที่ไปยัง .local รวมถึงคำขอที่มาจาก .local เองด้วย ถ้าคุณต้องการให้ foo.local คุยกับตัวเองได้ เช่น เพื่อรันเว็บเซิร์ฟเวอร์ ก็ต้องเพิ่มข้อยกเว้นแยกตามโดเมน:
      @@||foo.local^$domain=foo.local,all
      หรือถ้าคุณเชื่อถือ .local ทั้งหมดและอยากอนุญาตให้ foo.local ใดๆ คุยกับ bar.local ใดๆ ได้ ก็เพิ่มข้อยกเว้นครอบทั้ง .local ได้หนึ่งรายการ:
      @@||local^$domain=local,all
    • เพื่อไม่ให้สับสน ประเด็นนี้ไม่ใช่เรื่องที่เซิร์ฟเวอร์บนอินเทอร์เน็ตส่งคำขอเข้ามายังเครือข่ายภายใน แต่เป็นเรื่องที่ เว็บเบราว์เซอร์ในเครื่องส่งคำขอนั้นออกไป แน่นอนว่า JavaScript ที่รันในเบราว์เซอร์อาจถูกโหลดมาจากเซิร์ฟเวอร์บนอินเทอร์เน็ตได้

  • ยิ่งเวลาผ่านไป ฉันยิ่งรู้สึกสบายใจกว่าถ้าใช้อินเทอร์เน็ตผ่าน Qubes box เป็นหลัก โดยใช้ Whonix/Tor VM แบบใช้แล้วทิ้ง และปิด JavaScript ไว้
    นี่มันน่าขยะแขยงจริงๆ ไม่ได้แปลกใจ แต่แค่ความจริงที่ว่ามันเป็นไปได้ก็น่ากลัวในหลายแง่มุมแล้ว
    ถ้าไม่รู้จัก fingerprint.com บริษัทนี้ทำ “การทำโปรไฟล์ผู้ใช้เชิงลึก” ประมาณว่ารักษา user ID เดิมไว้ได้ต่อเนื่องแม้จะเปลี่ยนคอมพิวเตอร์ เบราว์เซอร์ หรือระบบปฏิบัติการก็ตาม มีเดโมอยู่บนหน้าแรก แล้วมันเดาได้แม่นขนาดไหนก็ค่อนข้างชวนขนลุก

    • มันยังระบุได้ว่าเป็นอุปกรณ์เดิมแบบเป๊ะๆ แม้อยู่คนละ VPN IP ก็ตาม ขนลุกจริง
    • นี่มันน่าขยะแขยง เดโมของมันทำได้แม้ในโหมดไม่ระบุตัวตนบน iPhone ปกติและเปลี่ยน IP ไปสองตัวแล้ว ซึ่งน่าประทับใจในทางแย่ เพราะดูยังไงก็น่าจะเหมือน iPhone เครื่องอื่นๆ
      ฟิลเตอร์ uBlock Origin ที่ทำให้เดโมพัง:
      ||fpjscdn.net

  • ด้วยการโจมตีแบบอาศัยจังหวะเวลาลักษณะคล้ายกัน ก็สามารถสแกนพอร์ตของเครื่อง local และอุปกรณ์อื่นในเครือข่าย local จากในเบราว์เซอร์ได้
    https://github.com/Flu1dTeam/PortScanner
    เมื่อก่อน eBay ก็เคยทำแบบนี้แล้วโดนจับได้
    https://blog.nem.ec/2020/05/24/ebay-port-scanning/

    • อะไรเนี่ย หลอนมาก ทำไมฉันไม่เคยได้ยินเรื่องนี้มาก่อนเลย?

  • โชคดีที่ฉันเปลี่ยนชื่ออุปกรณ์ไว้ตลอด
    การตั้งชื่อเริ่มต้นของ Apple ถือเป็นความพลาดด้านความเป็นส่วนตัว. ครั้งหนึ่งฉันเคยไปเดตครั้งแรกกับคนที่ทำงานในหน่วยงานบังคับใช้กฎหมาย เธอมาคนเดียว และเป็นผู้หญิงที่ชัดเจนว่าใส่ใจการปกป้องตัวเองมาก เธอบอกว่าตรวจสอบประวัติฉันแล้ว และบอกตำแหน่งของพวกเราให้คนในชุมชนรอบตัวเธอสองสามคนรู้ไว้ด้วย
    แต่ฝั่งฉันกลับไม่รู้แม้แต่นามสกุลของเธอ และยังเอาเรื่องนั้นมาล้อเล่นอีก หลังมื้อเย็นพอเราขึ้นรถ หน้าจอบนแดชบอร์ดก็ขึ้นว่า iPhone ถูกจับคู่อัตโนมัติแล้ว และชื่อ iPhone เครื่องนั้นตั้งเป็นชื่อกับนามสกุลของเธอ ฉันเลยรู้สึกสนใจขึ้นมา ฉันไม่ได้ชี้เรื่องนั้นตรง ๆ แต่ปล่อยให้เธอลองเดาว่าฉันรู้ชื่อเธอได้ยังไงจนกระทั่งจบการขับรถ

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

  • ในตัวอย่างข้างบน ที่อยู่ที่ใช้ได้ใช้เวลา4 มิลลิวินาที ส่วนที่อยู่ที่ใช้ไม่ได้ใช้เวลา 5 วินาที
    อันนี้น่าแปลกใจ ฉันคาดว่าการค้นหา DNS ที่ล้มเหลวน่าจะเร็วกว่า timeout การเชื่อมต่อปกติที่เกิดหลังการค้นหา DNS สำเร็จเสียอีก
    ถึงอย่างนั้น ฉันก็ยังคิดว่า s-mac-xxxx เป็นตัวเลือกที่แปลกอยู่เสมอ โดยเฉพาะเมื่อคิดว่านี่คือบริษัทที่ขายจุดเด่นเรื่องความเป็นส่วนตัวอย่างหนัก น่าจะคาดหวังได้ว่าจะไม่ใช้ชื่อจริง หรือไม่ก็กรณีนี้ให้ “ความเป็นมิตรต่อผู้ใช้” มาก่อน ในมุมความเป็นส่วนตัว ชื่อโฮสต์แบบสุ่มที่ Windows สร้างให้นั้นดีกว่า

    • DNS ปกติถามเซิร์ฟเวอร์เดียวที่ IP เดียวเพื่อขอคำตอบแบบใช่/ไม่ใช่ แต่mDNS เป็น multicast จึงไม่มีเซิร์ฟเวอร์ตัวใดตัวหนึ่งที่มีอำนาจตอบได้อย่างชัดเจนว่า “ไม่ใช่”†. จะรู้ว่าไม่มีเรคคอร์ดก็ต่อเมื่อเซิร์ฟเวอร์ไม่ตอบและการค้นหาหมดเวลาเท่านั้น
      † ถ้าจะพูดให้เป๊ะก็ไม่ถูกทั้งหมด ถ้ามีอุปกรณ์ที่รู้ว่าชื่อนั้นเป็นของตัวเอง มันก็สามารถตอบว่าไม่ใช่ได้
    • เหตุผลที่ชื่อจริงของผู้ใช้ไปอยู่ในชื่อโฮสต์ อาจเป็นเพราะAirDrop. ดูเหมือนระบบจะใช้ชื่อโฮสต์กับฟีเจอร์อย่าง Personal Hotspot หรือ AirDrop และถ้าใช้ชื่ออีกแบบหนึ่งก็น่าจะสร้างความสับสนในวงกว้างเวลาแชร์ไฟล์
    • นอกจากประเด็นเรื่อง timeout การเชื่อมต่อปกติแล้ว ตรงนี้ยังเป็นกรณีของconnection refused คือได้รับ RST ไม่ใช่ timeout ของการเชื่อมต่อด้วย

  • บทความเขียนดีและน่าสนใจ โดยเฉพาะน้ำเสียงที่ไม่โอ้อวดเกินจริงอย่างประโยคว่า “เมื่อพิจารณาจากจุดอ่อนโดยเนื้อแท้และข้อจำกัดมากมาย การโจมตีนี้จึงไม่ใช่สิ่งที่ใช้งานได้จริง” ซึ่งฉันชอบมาก

    • ถ้าอยู่ในอีกจักรวาลหนึ่ง เรื่องนี้คงถูกตั้งชื่อว่า “FINGERBleed” และมีทั้งเว็บไซต์เท่ ๆ กับโลโก้เรียบร้อย
    • ยังไม่แน่ใจนัก
      วิธีนี้ทำให้เราทดสอบได้ว่ามีชื่อโฮสต์บางชื่ออยู่ในเครือข่ายหรือไม่
      ถ้าเป็นชื่อโฮสต์ที่ไม่ซ้ำเพียงชื่อเดียวอาจไม่ใช่ปัญหาใหญ่ แต่ถ้าเป็นชื่อคงที่หรือชื่อเริ่มต้นที่พบได้บ่อยในโลก IoT ล่ะ
      เว็บไซต์จะสามารถเดาแบบลับ ๆ ได้ว่าผู้ใช้เป็นเจ้าของอุปกรณ์บางชนิดหรือไม่ ถ้านำไปใช้กับการโจมตีแบบเจาะจงเป้าหมายก็ยิ่งแย่กว่าเดิม ถ้ารู้อุปกรณ์บางส่วนในเครือข่ายอยู่แล้ว ก็อาจเดาได้ว่าผู้ใช้ที่เชื่อมต่ออยู่ในเครือข่ายเป้าหมายนั้นหรือไม่

  • ถ้าการปิด JavaScript ไม่ได้ปิดประสบการณ์ของผู้ใช้ปลายทางไปด้วยก็คงดี

    • นี่เป็นเหตุผลเดียวที่ทำให้ฉันยังปิด JavaScript ทั้งระบบไม่ได้
      แต่ดูเหมือนจากนี้ไปฉันคงต้องปิดไว้เป็นค่าเริ่มต้นเพราะกังวลเรื่องความเป็นส่วนตัว
    • ไม่มีวิธีจำกัดอย่างหนักว่าจาวาสคริปต์เอนจินจะทำอะไรได้บ้างหรือ?

  • โชคดีที่ชื่ออุปกรณ์ของฉันมักจะเป็นประมาณ “xxxs's MacBook Pro (34)” อยู่แล้ว. ไม่ใช่บั๊ก แต่เป็นฟีเจอร์

    • ตั้งชื่อผู้ใช้ของโน้ตบุ๊กเป็น user และตั้งชื่อโฮสต์เป็น hostname กันเถอะ ยิ่งมีคนทำแบบนี้มากเท่าไรก็ยิ่งดี

  • น่าสนใจ เขียนก็ดี และยังมีproof of conceptที่ใช้ได้ด้วย ทำออกมาได้ดี
    มาตรการตอบโต้ที่น่าสนุกอย่างหนึ่งคือเปลี่ยนชื่อโฮสต์ของอุปกรณ์เป็นอะไรแบบ atemptingurl.local เพื่อหลอกให้ผู้โจมตีอยากเข้าไปดูเว็บไซต์นั้น แล้วทำหน้าเว็บนั้นให้ประณีตพอที่จะใช้เทคนิคเดียวกันเล่นงานผู้โจมตีคืน พร้อมแสดงข้อความประมาณนี้:
    “สวัสดี [ชื่ออุปกรณ์ของแฮ็กเกอร์]! ข้อมูลเครื่องของคุณ, IP address, ตำแหน่งทางภูมิศาสตร์ และข้อมูล fingerprint อื่น ๆ ได้ถูกรวบรวมและรายงานไปยัง [ใส่ชื่อหน่วยงานไซเบอร์สุดน่ากลัว] แล้ว” อย่างน้อยต่อให้เป็นตัวเก๋าที่ชำนาญไม่ใช่ script kiddie ก็น่าจะเรียกเสียงหัวเราะได้บ้าง
    ผู้คนควรมีเหตุผลให้หัวเราะมากกว่านี้ :-)

    • ถ้าจะทำแบบนั้นต้องรัน HTTP server ที่เปิดอนุญาต CORS ทั้งหมดไว้ ซึ่งก็เท่ากับเปิดตัวเองให้เจอบั๊กทั้งหมดของ HTTP server ที่เลือกใช้ และทำให้ความปลอดภัยของตัวเองลดลงด้วย