สรุปสั้น

ทีมวิจัย Unit 42 ของบริษัท Palo Alto Networks เปิดเผยเทคนิคโจมตี 3 รูปแบบที่พุ่งเป้าไปยัง Google Password Manager ซึ่งทำหน้าที่เป็น cloud authenticator ของ Chrome โดยตั้งชื่อว่า Pass-ta-key, Silver Pass-ta-key และ Golden Pass-ta-key ผลลัพธ์ที่ได้คือมัลแวร์ซึ่งรันด้วยสิทธิ์ผู้ใช้ทั่วไปบนเครื่อง Windows สามารถลงชื่อเข้าใช้บัญชีที่ป้องกันด้วย passkey ของเหยื่อได้ โดยไม่ต้องสแกนลายนิ้วมือ ไม่ต้องใส่ PIN และไม่มีอะไรปรากฏบนหน้าจอของเหยื่อเลย จุดสำคัญที่ต้องเข้าใจให้ตรงกันคือทั้งสามเส้นทางไม่ได้หักการเข้ารหัสของ passkey แต่โจมตีโค้ดที่อยู่รอบ ๆ มัน ได้แก่ วิธีที่ Chrome เก็บกุญแจประจำอุปกรณ์ วิธีที่ Chrome ลงทะเบียนอุปกรณ์ใหม่หลังสถานะเดิมหายไป และคำถามว่าเว็บไซต์ปลายทางตรวจสอบหรือไม่ว่ามีการยืนยันตัวตนของมนุษย์เกิดขึ้นจริง

ผลของการโจมตีมีตั้งแต่การได้ authentication assertion ที่ถูกต้องแบบเงียบ ๆ การติดตั้งกุญแจ user-verification ที่ผู้โจมตีควบคุมเอง ไปจนถึงการดึงค่า Security Domain Secret (SDS) ขนาด 32 ไบต์ที่ใช้ถอดรหัสกุญแจส่วนตัวของ passkey ที่ซิงก์ไว้ นักวิจัยระบุว่าเส้นทางที่สองและสามให้สิทธิ์เข้าถึงซ้ำได้จากสภาพแวดล้อมของผู้โจมตีเอง หลังจากยึดเครื่องปลายทางได้ครั้งแรกแล้ว อย่างไรก็ตามรายงานไม่ได้บอกว่ามีการโจมตีจริงในธรรมชาติ ไม่มีหมายเลข CVE ไม่ระบุเวอร์ชัน Chrome ที่ได้รับผลกระทบ และไม่ได้สรุปสถานะการแก้ไขให้ครบถ้วน การค้นฐานข้อมูล National Vulnerability Database เมื่อวันที่ 3 สิงหาคม 2569 ก็ไม่พบ CVE ที่ตรงกับเทคนิคทั้งสามชื่อนี้

ขอบเขตของงานวิจัยจำกัดอยู่ที่ Google Password Manager บน Chrome ในระบบ Windows ที่มีชิป Trusted Platform Module (TPM) และทุกเส้นทางเริ่มต้นจากเงื่อนไขเดียวกันคือมีมัลแวร์รันอยู่บนเครื่องเหยื่อแล้ว นี่จึงเป็นเทคนิคหลังการยึดเครื่อง (post-compromise) ที่อธิบายว่าผู้โจมตีเอื้อมถึงอะไรได้บ้างบนเครื่องที่เสียไปแล้ว ไม่ใช่คำอธิบายว่าเครื่องนั้นเสียไปได้อย่างไร

รายละเอียดข่าว

เว็บไซต์ The Hacker News รายงานเมื่อวันที่ 3 สิงหาคม 2569 ว่า Unit 42 ได้เผยแพร่รายละเอียดเส้นทางโจมตีทั้งสามต่อ cloud authenticator ของ Google Password Manager โดยเริ่มจากขั้นตอนสำรวจข้อมูลบนเครื่องเหยื่อก่อน

Chrome เก็บระเบียนข้อมูลรับรองที่ซิงก์ไว้ภายใต้พาธ %LocalAppData%\Google\Chrome\User Data\<Profile>\Sync Data\LevelDB นักวิจัยระบุว่ากระบวนการที่ไม่มีสิทธิ์พิเศษสามารถอ่านข้อมูลกำกับได้มากพอที่จะระบุว่าเหยื่อผูก passkey ไว้กับเว็บไซต์ใดและใช้ชื่อผู้ใช้อะไร รวมถึงตัวระบุข้อมูลรับรองและชิ้นส่วนกุญแจส่วนตัวที่ถูกเข้ารหัสไว้

เส้นทางแรกชื่อ Pass-ta-key ทำงานด้วยการดึงกุญแจแสดงตัวตนของอุปกรณ์ที่ Chrome ห่อไว้ออกมา แล้วสั่งให้ TPM ตัวเดิมลงลายมือชื่อคำขอที่ผู้โจมตีกำหนดเองผ่านการเรียกใช้ Windows Cryptography API: Next Generation (CNG) ซอร์สโค้ดของ Chromium ในปัจจุบันอธิบายว่าทำไมก้อนข้อมูลนั้นถึงนำกลับมาใช้ซ้ำได้ กล่าวคือ Chrome สร้างกุญแจ TPM โดยไม่ตั้งชื่อกุญแจ ซึ่งคอมเมนต์ในโค้ดระบุว่าเป็นการป้องกันไม่ให้กุญแจถูกเขียนลงดิสก์ จากนั้น Chrome ส่งออกกุญแจเป็นก้อนข้อมูลทึบและโหลดกลับมาภายหลังภายใต้แฟล็กที่ระงับการแจ้งเตือนใด ๆ ในไฟล์เดียวกันยังมีคอมเมนต์ TODO ชี้ไปยัง Chromium issue 398125799 ที่เสนอให้ตั้งชื่อกำกับกุญแจเหล่านั้นแทน

ผลคือ Google Cloud Authenticator คืนค่า assertion ที่ถูกต้องกลับมา และสิ่งเดียวที่แยกมันออกจาก assertion ที่เกิดหลังการยืนยันตัวตนของผู้ใช้จริงคือบิตเดียว นั่นคือแฟล็ก User Verified (UV) ที่ถูกปล่อยว่างไว้ ข้อกำหนด Web Authentication ฉบับปัจจุบันระบุว่าเว็บไซต์ปลายทางที่ตั้งค่า userVerification เป็น required ต้องปฏิเสธพิธีการยืนยันตัวตนเมื่อบิตนั้นหายไป นักวิจัยระบุว่า GitHub บังคับใช้การตรวจสอบนี้ ขณะที่ eBay ยอมรับ assertion ที่ใช้ทดสอบจนกระทั่งบริษัทแก้ช่องว่างของการตรวจสอบหลังได้รับแจ้ง

เส้นทางที่สองชื่อ Silver Pass-ta-key เล่นงานชั้นถัดไป โดยมัลแวร์บังคับให้ Chrome ลงทะเบียนอุปกรณ์ใหม่ เนื่องจาก Chrome ไม่ได้สร้างกุญแจ user-verification ทันที ช่วงเวลาว่างตรงนั้นเปิดโอกาสให้ผู้โจมตีลงทะเบียนกุญแจของตัวเองแทน Unit 42 ระบุว่าบริการปลายทางไม่ได้ตรวจสอบว่ากุญแจที่เพิ่งลงทะเบียนมาจากฮาร์ดแวร์ที่ปลอดภัยหรือไม่ และ assertion ที่ลงลายมือชื่อด้วยกุญแจนั้นจะมีแฟล็ก UV ติดมาด้วย ซึ่งนักวิจัยระบุว่าเปิดทางให้ล็อกอินในภายหลังได้โดยไม่ต้องใช้อุปกรณ์ของเหยื่อ

เส้นทางที่สามชื่อ Golden Pass-ta-key มุ่งไปที่ตัว SDS โดยตรง Unit 42 ระบุว่ามัลแวร์สามารถกระตุ้นให้เกิดการลงทะเบียนใหม่ อ่านค่าความลับออกจากหน่วยความจำของโปรเซส Chrome ในจังหวะสั้น ๆ ที่มันอยู่ในรูปข้อความธรรมดา แล้วนำไปกู้คืนกุญแจส่วนตัวของ passkey ที่ซิงก์ไว้ ทีมวิจัยระบุว่า Google ได้นำการเปิดเผย SDS ที่เคยหลุดอยู่ในล็อก FIDO ของ Chrome ออกไปแล้ว และ eBay ได้ตรวจสอบแฟล็ก UV แล้ว แต่ย้ำว่าความลับดังกล่าวยังคงเดินทางมาถึงฝั่งไคลเอนต์และคงอยู่ในหน่วยความจำของ Chrome การแก้เรื่องล็อกจึงไม่ได้ปิดเส้นทางที่รายงานอธิบายไว้

The Hacker News ระบุว่าได้ติดต่อ Google เพื่อสอบถามว่าความลับที่ถูกขโมยไปจะยังใช้ได้อยู่หรือไม่หลังผู้ใช้เปลี่ยน PIN ของ Password Manager และติดต่อ Palo Alto Networks เพื่อขอรายละเอียดเพิ่มเติม แต่ยังไม่ได้รับคำตอบ

วิธีการโจมตี

จุดร่วมของทั้งสามเส้นทางคือไม่มีอันไหนแตะการเข้ารหัสของ WebAuthn เลย แต่โจมตีสมมติฐานของระบบรอบข้างแทน

Pass-ta-key อาศัยการที่กุญแจ TPM ของ Chrome ถูกสร้างแบบไม่มีชื่อกำกับ แล้วส่งออกเป็นก้อนข้อมูลที่โหลดกลับมาใช้ใหม่ได้โดยไม่มีป๊อปอัปถามผู้ใช้ มัลแวร์จึงยืมความสามารถในการลงลายมือชื่อของ TPM มาใช้ได้ทั้งดุ้น ผลลัพธ์ที่ได้เป็น assertion ที่ถูกต้องทุกประการยกเว้นบิต UV ซึ่งแปลว่าเว็บไซต์ที่ตรวจบิตนี้จริงจะรอด ส่วนเว็บไซต์ที่ตั้งค่า userVerification: required แต่ไม่ได้ตรวจค่าที่คืนกลับมาจะถูกหลอกได้ ในบรรดาสามเส้นทาง อันนี้เป็นอันเดียวที่ขึ้นอยู่กับการตรวจสอบซึ่งเว็บไซต์ปลายทางควบคุมได้เอง

Silver Pass-ta-key อาศัยสถานะ deferred_uv_key_creation ที่อุปกรณ์ซึ่งเพิ่งลงทะเบียนใหม่สามารถค้างอยู่ได้ ซอร์สโค้ด Chromium ที่เปิดเผยยืนยันว่าสถานะนี้มีอยู่จริง แต่โค้ดสาธารณะเพียงอย่างเดียวไม่พอจะยืนยันว่าการสลับกุญแจฝั่งเซิร์ฟเวอร์ตามที่รายงานอธิบายยังทำได้กับ Chrome รุ่น stable ล่าสุดหรือไม่ และรายงานก็ไม่ได้บอกว่าปัจจุบันบริการฝั่งโปรดักชันตรวจ hardware attestation ก่อนรับกุญแจทดแทนแล้วหรือยัง ซึ่งเป็นมาตรการที่ Unit 42 แนะนำเองเพื่อปิดเส้นทางนี้

Golden Pass-ta-key อาศัยข้อเท็จจริงที่ว่า SDS ต้องเดินทางมาถึงเครื่องไคลเอนต์เพื่อใช้ถอดรหัส ซอร์สโค้ด Chromium ยืนยันเฉพาะส่วนที่ว่า Chrome สร้างหรือรับความลับขนาด 32 ไบต์เข้ามาไว้ในโครงสร้างข้อมูลของโปรเซสไคลเอนต์ ส่วนความน่าเชื่อถือของการดึงค่าออกมาได้จริง การยึดบัญชี และการคงอยู่ข้าม epoch ของความลับในอนาคต ยังอ้างอิงจาก Unit 42 ฝ่ายเดียวหรือยังไม่มีข้อสรุป

ข้อจำกัดสำคัญที่ต้องระบุให้ชัดคือรายงานไม่ได้ยืนยันว่าเส้นทางทั้งสามถูกปิดหมดแล้ว การค้นเอกสารสาธารณะของ Chrome และหน้าสนับสนุนกับหน้าข่าวของ eBay เมื่อวันที่ 3 สิงหาคม 2569 ไม่พบประกาศที่บันทึกการเปลี่ยนแปลงทั้งสองรายการที่รายงานกล่าวถึง และไม่มีแหล่งใดอธิบายวิธีที่ผู้ใช้จะตรวจสอบได้ว่า SDS ของตัวเองรั่วไปแล้วหรือไม่

ผลกระทบ

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

ฝั่งเว็บไซต์ปลายทางก็ได้บทเรียนตรง ๆ ว่าการตั้งค่า userVerification เป็น required ในคำขอไม่มีความหมายอะไรเลยหากไม่ตรวจบิต UV ที่คืนกลับมา กรณี eBay ที่ยอมรับ assertion ทดสอบจนกระทั่งได้รับแจ้งแสดงว่าช่องว่างแบบนี้เกิดขึ้นได้แม้ในบริการขนาดใหญ่ และผู้ให้บริการรายอื่นที่ใช้ไลบรารีหรือโค้ดตรวจสอบชุดเดียวกันก็ควรตรวจสอบตัวเองด้วย

สำหรับผู้ใช้ทั่วไป ปัญหาที่ยังไม่มีคำตอบคือไม่มีวิธีตรวจว่า SDS ของตัวเองถูกดึงไปหรือไม่ และเอกสารสาธารณะของ Google เปิดให้ผู้ใช้เปลี่ยน PIN ของ Password Manager หรือลบข้อมูล Password Manager ทั้งหมดได้ แต่ไม่ได้อธิบายกลไกหมุนหรือเพิกถอน SDS โดยเฉพาะ แหล่งข้อมูลที่ตรวจสอบทั้งหมดก็ไม่ได้บอกว่าการเปลี่ยน PIN หรือลบข้อมูลจะทำให้ความลับที่ผู้โจมตีถือไว้แล้วใช้ไม่ได้ ซึ่งเป็นข้อมูลที่คนสงสัยว่าตัวเองโดนแล้วจำเป็นต้องรู้เพื่อลงมือทำอะไรสักอย่าง

คำแนะนำ

  • เว็บไซต์และแอปพลิเคชันที่รองรับ passkey ควรตั้ง userVerification เป็น required และตรวจบิต UV ที่ได้รับกลับมาจริง ไม่ใช่เชื่อว่าค่าที่ส่งไปในคำขอเพียงพอ
  • ผู้ให้บริการจัดการข้อมูลรับรองควรตรวจ attestation ของกุญแจที่เพิ่งลงทะเบียน เพื่อไม่ให้กุญแจซอฟต์แวร์ของผู้โจมตีถูกรับเข้าระบบแทนกุญแจในฮาร์ดแวร์
  • เพิ่มความเข้มของขั้นตอนลงทะเบียนซ้ำและการกู้คืนบัญชี เพราะทั้งเส้นทางที่สองและสามเริ่มจากการบังคับให้อุปกรณ์เข้าสู่กระบวนการ re-enroll
  • จำกัดการเข้าถึงสถานะ passkey ที่เก็บอยู่บนเครื่อง และหลีกเลี่ยงการปล่อยให้กุญแจหลักปรากฏในล็อกหรือค้างอยู่ในหน่วยความจำของไคลเอนต์นานเกินจำเป็น
  • ในเชิงปฏิบัติการ ให้ถือว่าเครื่องที่ติดมัลแวร์แล้วเท่ากับบัญชีทั้งหมดบนโปรไฟล์เบราว์เซอร์นั้นถูกยึดไปด้วย การล้างเครื่องอย่างเดียวไม่พอ ต้องพิจารณาลงทะเบียน passkey ใหม่และตัดอุปกรณ์เดิมออกจากบัญชี
  • ทีมเฝ้าระวังควรจับตากระบวนการที่ไม่ได้รับอนุญาตซึ่งเข้าอ่านโฟลเดอร์ Sync Data\LevelDB ของ Chrome และการเรียกใช้ CNG ที่มาจากไบนารีนอกเหนือจากตัวเบราว์เซอร์เอง

แหล่งอ้างอิง