SMS สำหรับการยืนยันตัวตนสองชั้น: วิธีด้านความปลอดภัยที่แย่กว่าที่คิด

 (ccc.de)
2 คะแนน โดย GN⁺ 2024-07-12 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • กรณีที่ CCC พบการเปิดเผยข้อมูลของ IdentifyMobile ทำให้สามารถเห็น รหัสผ่านใช้ครั้งเดียวทาง SMS ได้แบบเรียลไทม์ และมี SMS รั่วไหลมากกว่า 198 ล้านข้อความจากบริษัทกว่า 200 แห่ง
  • 2FA ผ่าน SMS เป็นกลไกเสริมที่ช่วยป้องกันกรณีรหัสผ่านถูกขโมยเพียงอย่างเดียว แต่ความปลอดภัยจริงยังขึ้นอยู่มากกับระดับการจัดการของ ผู้ให้บริการส่ง SMS ภายนอก
  • IdentifyMobile เปิดเผยโค้ดยืนยัน หมายเลขโทรศัพท์ผู้รับ ชื่อผู้ส่ง และข้อมูลบัญชีบางส่วนไว้บนอินเทอร์เน็ต และสามารถเข้าถึงได้เพียงแค่ เดาชื่อซับโดเมน idmdatastore
  • Google, Amazon, Facebook, Microsoft, Telegram, Airbnb, FedEx, DHL ได้รับผลกระทบ และเพียงแค่ฟีดแบบเรียลไทม์ก็อาจถูกใช้ยึดหมายเลข WhatsApp หรือพยายามทำธุรกรรมทางการเงินและเข้าสู่ระบบบริการต่าง ๆ ได้
  • การยืนยันตัวตนชั้นที่สองผ่าน SMS ยังดีกว่าการใช้รหัสผ่านอย่างเดียว แต่แนวทางที่ปลอดภัยกว่าคือรหัสผ่านใช้ครั้งเดียวจากแอปหรือ ฮาร์ดแวร์โทเค็น ซึ่งพึ่งพาเครือข่ายมือถือและผู้ให้บริการ SMS น้อยกว่า

จุดอ่อนของ 2FA-SMS ที่กรณี IdentifyMobile เปิดเผยให้เห็น

  • 2FA ผ่าน SMS กำหนดให้ผู้ใช้ต้องใช้ทั้ง รหัสผ่าน ที่ตนรู้ และ รหัส SMS ที่พิสูจน์การเข้าถึงหมายเลขโทรศัพท์
    • ใช้เป็นชั้นป้องกันเพิ่มเติมเพื่อหยุดการยึดบัญชีเมื่อมีการรั่วไหลของรหัสผ่านเพียงอย่างเดียว
    • ใน SMS อาจมีรหัสที่ใช้ได้เพียงช่วงเวลาสั้น ๆ เช่นรหัสยืนยัน WhatsApp หรือ TAN สำหรับโอนเงินผ่านธนาคาร
  • การยืนยันตัวตนบนพื้นฐาน SMS เปิดรับช่องทางโจมตีหลายแบบอยู่แล้ว
  • ในกรณีนี้ ต่อให้ผู้โจมตีไม่ต้องโจมตีเครือข่ายสื่อสารหรือผู้ใช้โดยตรง ผู้ให้บริการส่ง SMS ภายนอก ก็ยังอาจเป็นจุดอ่อนในห่วงโซ่การยืนยันตัวตนได้
    • IdentifyMobile เป็นผู้ให้บริการส่ง SMS ปริมาณมากให้กับหลายบริษัทและหลายบริการ
    • ผู้ให้บริการรายนี้สามารถเข้าถึงเนื้อหา SMS ได้ และในเนื้อหานั้นมีโค้ดยืนยันอยู่
    • CCC สามารถเข้าถึงข้อมูลแบบเรียลไทม์ได้เพียงแค่เดาชื่อซับโดเมน idmdatastore

ขอบเขตการเปิดเผยและความเสี่ยงที่เกิดขึ้นจริง

  • ข้อมูลที่ถูกเปิดเผยไม่ได้มีแค่เนื้อหา SMS แต่ยังรวมถึง หมายเลขโทรศัพท์ผู้รับ ชื่อผู้ส่ง และในบางกรณียังมีข้อมูลบัญชีอื่น ๆ ด้วย
  • บริษัทที่ได้รับผลกระทบมีมากกว่า 200 แห่ง รวมถึงกรณีที่มอบหมายความปลอดภัยของการยืนยันตัวตนให้ IdentifyMobile โดยตรงหรือผ่านผู้ให้บริการรายอื่น
    • Google, Amazon, Facebook, Microsoft
    • Telegram, Airbnb, FedEx, DHL
    • มี SMS รั่วไหลรวมมากกว่า 198 ล้านข้อความ
  • เพียงฟีดแบบเรียลไทม์ก็เพียงพอสำหรับสถานการณ์การนำไปใช้ในทางที่ผิดได้หลายแบบ
    • ยึดหมายเลข WhatsApp
    • หากรู้รหัสผ่านอยู่แล้ว ก็สามารถทำธุรกรรมทางการเงินได้โดยไม่ต้องเข้าถึงโทรศัพท์
    • หากรู้รหัสผ่านอยู่แล้ว ก็สามารถเข้าสู่ระบบบริการต่าง ๆ ได้หลายแห่ง
  • โดยทั่วไปการนำไปใช้จริงยังคงต้องมีรหัสผ่าน แต่ในข้อมูลที่รั่วไหลยังมีลิงก์ 1-click login รวมอยู่ด้วย
    • ในบางบริษัทขนาดใหญ่ที่ได้รับผลกระทบ ขอบเขตที่ IdentifyMobile ดูแลถูกจำกัดอยู่แค่บางบริการเท่านั้น
    • ความประมาทของ IdentifyMobile ทำให้ทั้งบริษัทและลูกค้าตกอยู่ในความเสี่ยงอย่างมีนัยสำคัญ
    • CCC ไม่ได้เก็บข้อมูลไว้ แต่ก็ไม่อาจตัดความเป็นไปได้ได้ว่าคนอื่นอาจเข้าถึงข้อมูลดังกล่าว

วิธีการยืนยันตัวตนที่เลือกใช้แทน SMS ได้

  • หากเป็นไปได้ การใช้รหัสผ่านใช้ครั้งเดียวที่สร้างจากแอปหรือ ฮาร์ดแวร์โทเค็น แทน SMS จะปลอดภัยกว่า
    • วิธีเหล่านี้ไม่พึ่งพาเครือข่ายมือถือ
    • และไม่พึ่งพาผู้ให้บริการส่ง SMS อย่าง IdentifyMobile
    • ถึงอย่างนั้น การยืนยันตัวตนสองชั้นก็ยังดีกว่าการใช้เพียงรหัสผ่านอย่างเดียว

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

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

 
GN⁺ 2024-07-12
ความเห็นจาก Hacker News

  • เมื่อไม่นานมานี้คนรู้จักโดน Google Ads phishing โดยผู้โจมตีซื้อโฆษณากับคีย์เวิร์ดอย่าง “BANKNAME login” แล้วทำหน้าเข้าสู่ระบบของธนาคารปลอมได้แนบเนียนมาก ขณะที่เบื้องหลังก็กำลังทำการโจมตีแบบ relay อยู่
    พอเหยื่อกรอกรหัสยืนยันตัวตนแบบ 2 ขั้นตอนจากแอปมือถือ หน้าจอกลับปฏิเสธและขอรหัสใหม่ แต่จริง ๆ แล้วรหัสครั้งที่สองเป็นรหัสอนุมัติสำหรับเพิ่มผู้รับเงินใหม่แบบ “pay anyone” และเงินก็ถูกโอนไปด้วยวิธีนั้น
    เดิมทีคิดว่า SMS 2FA อ่อนแอในระดับโปรโตคอลอยู่แล้ว แต่ในกรณีนี้ วิธีของธนาคารที่ส่งข้อความ SMS คนละแบบระหว่างตอนล็อกอินกับตอนเพิ่มผู้รับเงินใหม่อาจจะดีกว่าก็ได้
    ในอุดมคติ ระบบไม่ควรเป็นแค่แอปสร้างโทเค็นธรรมดา แต่ควรสร้าง โทเค็นแยกตามประเภทธุรกรรม เช่น โทเค็นสำหรับล็อกอินกับโทเค็นสำหรับเพิ่มผู้รับเงิน และต้องใช้แทนกันไม่ได้ อยากรู้ว่าเคยมีใครเห็นธนาคารที่ให้ 2FA ระดับนี้บ้างไหม
    เป็นไปได้ว่า passkey อาจทำให้ปัญหาแบบนี้หมดความหมายไปเลย เพราะมันสร้างการเชื่อมต่อทางกายภาพกับฮาร์ดแวร์ในเครื่อง โดยสรุปแล้วเหยื่อได้เงินคืนในที่สุด

    • โฆษณาไม่ได้เป็นแค่การก่อกวนทางจิตวิทยาที่น่ารำคาญซึ่งกินแบนด์วิดท์และทรัพยากรประมวลผลเท่านั้น แต่ยังเป็นช่องทางอันดับหนึ่งในการแพร่ การหลอกลวงและมัลแวร์ บนเว็บอีกด้วย
      ถ้าอยากปรับปรุงท่าทีด้านความปลอดภัย การติดตั้งตัวบล็อกโฆษณาเป็นหนึ่งในวิธีที่ดีที่สุด ขอย้ำว่าแนะนำอย่างมากให้ช่วยตั้งค่า uBlock Origin ให้เพื่อนหรือคนในครอบครัวที่ไม่ค่อยถนัดเทคโนโลยี
    • HSBC มีฟีเจอร์แบบนี้จริง ๆ ในแอปของแต่ละประเทศสามารถสร้าง security code คนละแบบสำหรับการล็อกอินเว็บไซต์, การยืนยันธุรกรรม (เช่น โอนเงินให้ผู้รับ), และการยืนยันตัวตนซ้ำ (เช่น เปลี่ยนข้อมูลส่วนตัวอย่างหมายเลขโทรศัพท์)
      หน้าจอของแอปออสเตรเลียดูได้ที่นี่ และแอปของสหรัฐฯ กับสหราชอาณาจักรก็คล้ายกัน: https://www.hsbc.com.au/content/dam/hsbc/au/images/ways-to-b...
      HSBC ให้บริการแบบนี้มาหลายปีแล้ว แต่ก็ยังไม่เข้าใจว่าทำไมมันถึงยังไม่กลายเป็นมาตรฐาน หรือทำไมธนาคารสหรัฐฯ อื่น ๆ ยังไม่เอาไปใช้
    • ด้วยความอยากรู้อยากเห็นเลยเคยลองซื้อโฆษณา Google ดูครั้งหนึ่ง ได้เครดิตฟรีมาเลยลอง แต่แค่จะให้โฆษณาผ่านอนุมัติก็ต้องฝ่าข้อกำหนดและแนวทางไร้สาระจำนวนมาก
      แต่กลับไม่เข้าใจว่าทำไมกับโฆษณาทั่วไปถึงเข้มงวดขนาดนั้น ในขณะที่กลับขายโฆษณาให้ หน้า phishing ที่ปลอมเป็นธนาคารและดักคนที่ค้นหาธนาคารนั้นได้
    • ควรบอกคนในครอบครัวและคนรู้จักไว้ด้วยว่าแม้แต่ FBI ก็ยังแนะนำให้ใช้ ส่วนขยายบล็อกโฆษณา บนเสิร์ชเอนจินเพื่อหลีกเลี่ยงการหลอกลวงแบบนี้โดยตรง [0]
      “เมื่อค้นหาข้อมูลบนอินเทอร์เน็ต ให้ใช้ส่วนขยายบล็อกโฆษณา เบราว์เซอร์อินเทอร์เน็ตส่วนใหญ่รองรับการติดตั้งส่วนขยาย รวมถึงส่วนขยายบล็อกโฆษณา ตัวบล็อกเหล่านี้สามารถเปิดหรือปิดได้ภายในเบราว์เซอร์ ทำให้คุณอนุญาตโฆษณาในบางเว็บไซต์ได้ ขณะที่บล็อกโฆษณาในเว็บไซต์อื่น”
      [0] https://www.ic3.gov/Media/Y2022/PSA221221
    • บทเรียนอีกอย่างจากเรื่องนี้คือควร บุ๊กมาร์กหรือจำ URL ของธนาคารไว้ และอย่าไว้ใจว่าเสิร์ชเอนจินจะพาเราไปยังธนาคารที่ถูกต้อง

  • ผมสงสัยมานานแล้วว่าบริษัทที่บังคับใช้ SMS 2FA ไม่ได้จริงจังกับความปลอดภัย แต่แค่อยากได้เบอร์โทร และใช้ 2FA เป็น security theater เพื่อให้คนยอมให้เบอร์

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

  • NIST ระบุไว้นานมากแล้วอย่างชัดเจนว่าไม่ควรใช้ SMS 2FA
    NIST SP 800-63B §5.1.3.3
    https://pages.nist.gov/800-63-3/sp800-63b.html#pstnOOB

    • มุมมองและผลประโยชน์ของ NIST ไม่จำเป็นต้องสอดคล้องกับสิ่งที่ผู้ให้บริการต้องใส่ใจในด้านประสบการณ์ลูกค้าหรือผู้ใช้เสมอไป
      ลูกค้า: “แอป 2FA คืออะไรคะ/ครับ? ปกติรหัสมันก็ส่งมาที่มือถือไม่ใช่เหรอ?”
      ฝ่ายซัพพอร์ต: “ใช่ครับ/ค่ะ แต่ตอนนี้เราไม่รองรับ SMS 2FA แล้ว”
      ลูกค้า: “แต่ตอนที่รหัสส่งมาที่มือถือก็ไม่เคยมีปัญหานี่คะ/ครับ”
      ฝ่ายซัพพอร์ต: “ครับ/ค่ะ แต่ NIST แนะนำว่าไม่ควรใช้ SMS 2FA”
      ลูกค้า: “NIST คืออะไร? น่าหงุดหงิดจริง ๆ ฉันต้องเข้าใช้บัญชีของฉันนะ”

  • น่าเสียดายที่แทบทุกธนาคารบังคับให้ใช้ SMS เพราะแอปธนาคาร ปฏิเสธไม่ทำงานบนมือถือที่รูทแล้ว ช่างเป็นความสำเร็จด้านความปลอดภัยที่ยอดเยี่ยมจริง ๆ

    • อย่างน้อยก็ยังถือว่ามีทางเลือกอยู่
      ในประเทศของผม แทบทุกธนาคารบังคับใช้ 2FA ผ่านแอปโดยไม่มีทางเลือกเป็น SMS
      ถ้าไม่อยากซื้อและพกมือถืออีกเครื่อง ก็เหลือใช้ได้แค่ธนาคารเดียวที่ไม่บังคับแบบนั้น
    • นั่นถือเป็นข้อได้เปรียบด้านความปลอดภัยจริง
      บนมือถือที่รูทแล้ว เท่ากับเปิดช่องให้แอปอื่นสอดแนมหรือขโมยข้อมูลธนาคารได้
      ที่แอปธนาคารไม่ยอมทำงานบนมือถือที่ความปลอดภัยถูกทำลายแล้ว ก็ดูสมเหตุสมผลดี
    • ประเด็นนี้อาจถกเถียงกันได้ แต่มือถือที่รูทแล้วมีความปลอดภัยต่ำกว่าโดยเนื้อแท้
      อย่างไรก็ตาม GrapheneOS ไม่ควรถูกรวมอยู่ในนั้น เพราะ build อย่างเป็นทางการของ GrapheneOS ไม่มีสิทธิ์ root

  • บทความนี้กำลังปะปนปัญหาสองอย่างที่มีนัยด้านความปลอดภัยต่างกัน
    ลิงก์ 1-click login น่ากังวลจริง และเพียงแค่เข้าถึง SMS ได้ก็อาจยึดบริการอย่าง WhatsApp ได้
    แต่โค้ด 2FA น่ากังวลน้อยกว่าในเชิงเปรียบเทียบ เพราะเป็นปัจจัยที่สอง ดังนั้นผู้โจมตียังต้องมีรหัสผ่านด้วย
    ในกรณีแบบนี้ ผมจึงกังวลเรื่องการใช้ SMS และความเสี่ยงจากการดักจับน้อยกว่ามาก

    • ทุกครั้งที่ฐานข้อมูลข้อความ SMS รั่ว จะมีฐานข้อมูล ข้อมูลรับรองบัญชี รั่วประมาณ 1000 ฐาน

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

    • อยากรู้ว่าเป็นธนาคารไหน ผมใช้ Lloyds และธุรกรรมได้รับการยืนยันผ่านแอป ไม่ใช่ SMS
    • ประโยคแรกไม่จริงเลย SMS เป็นเพียงหนึ่งในตัวเลือก แต่หลายธนาคารรองรับ 2FA แบบใช้แอป
      เห็นด้วยว่าเครื่องอ่านบัตรมีประโยชน์ในกรณีออฟไลน์ แต่ผมแทบไม่เคยจำพกมันไว้เลย เลยติดปัญหาระหว่างเดินทางบ่อย

  • สวีเดนแก้ปัญหานี้ด้วย BankID มานานแล้ว
    https://en.wikipedia.org/wiki/BankID
    น่าทึ่งมากว่าหน่วยงานรัฐและเอกชนจะทำอะไรได้บ้างถ้าร่วมมือกันสักเล็กน้อย มันเป็นวิธีเดียวในการล็อกอินและทำ 2FA สำหรับบริการภาครัฐและธนาคารส่วนใหญ่ และใช้งานได้ดี
    น่าเหลือเชื่อที่ไม่ใช่ทุกประเทศจะมีระบบแบบนี้ และยิ่งน่าเหลือเชื่อกว่านั้นคือทั้ง EU ก็ยังไม่มีระบบแบบนี้

    • EU กำลังนำ Digital Wallet มาใช้เพื่อการนี้ หวังว่าจะใช้งานดีกว่า BankID เวอร์ชันฟินแลนด์ และคงจะดียิ่งกว่าถ้าพึ่งพาธนาคารหรือองค์กรเอกชนที่แสวงหาค่าเช่าน้อยลง
      ถึงอย่างนั้นก็ไม่ได้ตั้งความหวังสูงนัก
      https://ec.europa.eu/digital-building-blocks/sites/display/E...
    • ถ้าตามที่วิกิอธิบายไว้ ก็สงสัยจริง ๆ ว่ามันไม่รองรับ Linux เลยหรือเปล่า แบบการ์ดก็น่าจะใช้แทนได้อยู่

  • ข้อความใน S3 bucket ดูเหมือนจะอัปเดตทุก 5 นาที: https://www.zeit.de/digital/datenschutz/2024-07/it-sicherhei...
    แต่ CCC นิยามว่านี่เป็นปัญหาเฉพาะของ 2FA-SMS นั้นไม่ถูกต้อง สิ่งที่ได้รับผลกระทบไม่ใช่แค่ Twilio Verify (API สำหรับ 2FA) แต่เป็น SMS ทั้งหมด ที่ส่งผ่านผู้ให้บริการรายนี้

    • อยากรู้ว่าข้ออ้างอิงเรื่อง Twilio Verify มาจากไหน เพราะไม่มีที่ไหนพูดถึงเลย

  • นี่ไม่ใช่ปัญหาของตัว SMS เองเท่าไรนัก แต่ใกล้เคียงกับปัญหา ความปลอดภัยของผู้ให้บริการ ที่ปกป้องคลังข้อมูลอ่อนไหวได้ไม่ดีมากกว่า

    • OTP และ hardware token ไม่จำเป็นต้องเขียนค่าลับแบบหมุนเวียนลงในคลังข้อมูลที่อาจถูกอ่านได้โดยไม่ได้รับอนุญาต ซึ่งในแง่นี้มันก็เป็นปัญหาของ SMS ด้วย
      ช่องทางโจมตีแบบเฉพาะเจาะจงนี้ไม่มีอยู่เลยในเทคโนโลยีเหล่านั้น

  • สถาบันการเงินหลายแห่งที่ผมทำงานด้วยบังคับใช้ SMS 2FA และไม่ให้ตัวเลือก HOTP/TOTP เลย บ้าชัด ๆ