Microsoft Edge เก็บรหัสผ่านทั้งหมดไว้ในหน่วยความจำแบบข้อความล้วน แม้ตอนที่ไม่ได้ใช้งาน
(twitter.com/L1v1ng0ffTh3L4N)- Microsoft Edge จะ ถอดรหัสรหัสผ่านที่บันทึกไว้ทั้งหมดตั้งแต่ตอนเริ่มทำงาน และคงข้อมูลรับรองเหล่านั้นไว้ในหน่วยความจำของโปรเซสในรูปแบบ ข้อความล้วน
- พฤติกรรมนี้เกิดขึ้นแม้ผู้ใช้จะยังไม่ได้เข้าเว็บไซต์ที่ใช้ข้อมูลรับรองนั้นก็ตาม
- UI ของ Password Manager ใน Edge จะ ขอให้ยืนยันตัวตนอีกครั้ง ก่อนแสดงรหัสผ่านเดียวกัน แต่ตัวโปรเซสของเบราว์เซอร์มีรหัสผ่านทั้งหมดในรูปแบบข้อความล้วนอยู่แล้ว
- ในบรรดาเบราว์เซอร์ที่ทดสอบซึ่งใช้ Chromium เป็นฐาน มีเพียง Edge เท่านั้นที่ทำงานในลักษณะนี้ ขณะที่ Chrome ถูก ออกแบบให้ดึงและแยกรหัสผ่านที่บันทึกไว้จากหน่วยความจำของโปรเซสได้ยากกว่าอย่างมาก
- Chrome จะถอดรหัสเฉพาะเมื่อจำเป็นต้องใช้ข้อมูลรับรองเท่านั้น และใช้ App-Bound Encryption (ABE) เพื่อผูกการถอดรหัสไว้กับโปรเซส Chrome ที่ได้รับการยืนยันตัวตน ทำให้ โปรเซสอื่นไม่สามารถนำคีย์เข้ารหัสของ Chrome ไปใช้ซ้ำได้
- ด้วยการควบคุมนี้ รหัสผ่านแบบข้อความล้วนจะปรากฏเพียงช่วงสั้น ๆ ตอนกรอกอัตโนมัติหรือเมื่อผู้ใช้เปิดดูเอง จึงลดประสิทธิภาพของการสแกนหน่วยความจำในวงกว้างลง
สถานการณ์ความเสี่ยงและสถานะการเปิดเผย
- ในสภาพแวดล้อมที่มีการใช้งานร่วมกัน ความเสี่ยงจากการคงรหัสผ่านแบบข้อความล้วนไว้ในหน่วยความจำจะยิ่งสูงขึ้น
- หากผู้โจมตีได้ สิทธิ์ผู้ดูแลระบบ บนเทอร์มินัลเซิร์ฟเวอร์ ก็จะเข้าถึงหน่วยความจำของโปรเซสของผู้ใช้ทุกคนที่ล็อกอินอยู่ได้
- ในการสาธิต ผู้โจมตีที่ยึดบัญชีผู้ใช้ซึ่งมีสิทธิ์ผู้ดูแลระบบ สามารถดูข้อมูลรับรองที่บันทึกไว้ของผู้ใช้ที่ล็อกอินอยู่คนอื่นอีกสองราย หรือผู้ใช้ที่ตัดการเชื่อมต่อไปแล้ว ขณะที่ Edge ยังทำงานอยู่ได้
- ได้รายงานพฤติกรรมนี้ให้ Microsoft ทราบแล้ว และคำตอบอย่างเป็นทางการคือพฤติกรรมนี้เป็น “by design”
- ได้แจ้ง Microsoft ว่าจะเปิดเผยข้อมูลนี้อย่างรับผิดชอบ เพื่อให้ผู้ใช้และองค์กรสามารถประเมินแนวทางการจัดการข้อมูลรับรองของตนได้
- เมื่อวันพุธที่ 29 เมษายน ได้เผยแพร่รายละเอียดนี้ที่ BigBiteOfTech ของ Palo Alto Networks Norway พร้อมสาธิตเครื่องมือง่าย ๆ ที่ใช้ตรวจสอบได้ว่ารหัสผ่านถูกเก็บเป็นข้อความล้วนในหน่วยความจำหรือไม่
- เครื่องมือพิสูจน์แนวคิดถูกเผยแพร่บน GitHub แล้ว และกำลังเปิดรับข้อเสนอแนะเนื่องจากยังมีประสบการณ์กับ C# และการเผยแพร่บน GitHub ไม่มากนัก: EdgeSavedPasswordsDumper
1 ความคิดเห็น
ความคิดเห็นบน Hacker News
ถ้าผู้โจมตีได้สิทธิ์ผู้ดูแลระบบเทอร์มินัลเซิร์ฟเวอร์ ก็จะเข้าถึงหน่วยความจำของโปรเซสของผู้ใช้ที่ล็อกอินอยู่ทั้งหมดได้ และถ้าเป็นสิทธิ์แอดมิน ก็สามารถแนบดีบักเกอร์เข้ากับทุกโปรเซสของ Chrome เพื่อบังคับถอดรหัสรหัสผ่านได้ด้วย
ความต่างที่แท้จริงอาจมีแค่ระดับ cold boot attack แต่ถึงอย่างนั้นก็ยังไม่ชัดว่ามันแค่ทำให้การโจมตีง่ายขึ้นเล็กน้อย หรือทำให้การโจมตีที่เดิมทำไม่ได้กลายเป็นทำได้
[1] https://devblogs.microsoft.com/oldnewthing/20060508-22/?p=31...
ดูแล้วไม่น่าจะเป็นปัญหาเฉพาะของ Edge และ Microsoft ก็ไม่มีเหตุผลที่จะทำให้เบราว์เซอร์ปลอดภัยน้อยกว่าโปรเจกต์ต้นน้ำ
Chrome มองผู้โจมตีที่อยู่ในเครื่องจริง ๆ ว่าอยู่นอก threat model และถือว่าถ้าผู้ใช้ล็อกอินเป็นฉันบนอุปกรณ์ของฉัน หรือรันซอฟต์แวร์ด้วยสิทธิ์ผู้ใช้ของระบบปฏิบัติการของฉันได้ ก็ไม่มีทางที่ Chrome หรือแอปไหน ๆ จะป้องกันได้
ผู้โจมตีแบบนั้นสามารถแก้ไฟล์ executable และ DLL, เปลี่ยนตัวแปรสภาพแวดล้อมอย่าง PATH, แก้ไฟล์คอนฟิก, อ่านข้อมูลบัญชีผู้ใช้แล้วส่งออกไปภายนอกได้อยู่แล้ว ดังนั้นจุดยืนคือ Chrome ไม่อาจรับประกันการป้องกันที่มีความหมายจริงได้
https://chromium.googlesource.com/chromium/src/+/148.0.7778....
ไม่แน่ใจว่าฉันพลาดอะไรไป
[0] https://en.wikipedia.org/wiki/Cloudbleed
ผมคิดว่านี่เป็นสิ่งที่ควรนำมาพิจารณา ตัวจัดการรหัสผ่านมีเหตุผลที่หลังผ่านไป 10 นาทีจะขอ master password หรือ passkey ใหม่
ผมเคยคิดว่า Chrome พึ่งพาพื้นที่ความปลอดภัยแบบเข้ารหัส ดังนั้นแม้มีสิทธิ์ root การดึงรหัสผ่านออกมาแบบง่าย ๆ ก็น่าจะทำได้ยากพอสมควร
แน่นอนว่าไม่ควรปล่อยคอมพิวเตอร์ทิ้งไว้ แต่ก็ไม่ได้หมายความว่าควรออกแบบผลิตภัณฑ์ให้ความผิดพลาดที่หลีกเลี่ยงไม่ได้ถูกนำไปใช้โจมตีอย่างร้ายแรงได้ง่าย
https://support.microsoft.com/en-us/topic/export-passwords-i...
ตัวอย่างเช่นเครื่องมืออย่าง KeePass ให้ความสำคัญพอสมควรกับการลงทะเบียนปลั๊กอินเบราว์เซอร์ แต่ถ้ามีแค่สิทธิ์ผู้ใช้ทั่วไป ก็ยังดึงคีย์นั้นออกจากเบราว์เซอร์แล้วทำอะไรก็ได้อยู่ดี
วิธีแบบ “เชื่อถือเบราว์เซอร์นี้” ของเว็บแอปก็ดูแปลกเหมือนกัน ถ้าที่เก็บคุกกี้ถูกอ่านได้ง่าย