เพิ่มการทำให้เวลาจังหวะการกดแป้นพิมพ์คลุมเครือใน ssh(1)
(undeadly.org)- Damien Miller คอมมิตฟีเจอร์ทำให้ข้อมูลเวลาระหว่างการกดแป้นพิมพ์ถูกซ่อนในไคลเอนต์ ssh(1)
- เมื่อมีข้อมูลที่ส่งในทราฟฟิกแบบโต้ตอบน้อย ระบบจะใช้การส่งแบบช่วงเวลาคงที่ โดยค่าปริยายคือ 20ms
- หลังการกดแป้นจริงครั้งสุดท้าย จะส่ง การกด chaff ปลอม ต่อไปเป็นเวลาสุ่มเพื่อทำให้รูปแบบด้านเวลาเลือนรางยิ่งขึ้น
- การทำงานถูกควบคุมด้วยคีย์เวิร์ดใหม่ของ
ssh_configคือObscureKeystrokeTiming - การติดตั้งใช้งานนี้ใช้ ส่วนขยาย PING/PONG ใหม่ของชั้นขนส่ง SSH และมีความเป็นไปได้ว่าจะถูกนำไปใช้กับระบบอื่นผ่าน
openssh-portableในภายหลัง
การซ่อนจังหวะเวลาการกดแป้นในไคลเอนต์ ssh(1)
- Damien Miller คอมมิตการรองรับ การทำให้เวลาจังหวะการกดแป้นพิมพ์คลุมเครือ ให้กับ ssh(1)
- ฟีเจอร์นี้พยายามส่งทราฟฟิกแบบโต้ตอบที่มีข้อมูลส่งออกน้อยด้วยช่วงเวลาคงที่ เพื่อซ่อนช่วงเวลาระหว่างการกดแป้น
- ช่วงเวลาการส่งปริยายคือ 20ms
- หลังการกดแป้นจริงครั้งสุดท้าย จะส่งการกด chaff ปลอมต่อไปเป็นเวลาสุ่ม
- ควบคุมการทำงานด้วยคีย์เวิร์ดใหม่ของ
ssh_configคือObscureKeystrokeTiming
ส่วนขยายโปรโตคอล SSH และเส้นทางการเผยแพร่
- การติดตั้งใช้งานนี้ใช้ข้อความชั้นขนส่งใหม่ 2 รายการที่เพิ่มเข้ามาในโปรโตคอล SSH
SSH2_MSG_PINGSSH2_MSG_PONG
- ข้อความเหล่านี้ใช้พื้นที่หมายเลขของ local extensions และมีการประกาศผ่านข้อความ
"ping@openssh.com"ext-infoพร้อมสตริงเวอร์ชัน"0" - การเปลี่ยนแปลงนี้ถูกแนะนำว่าเป็นอีกตัวอย่างหนึ่งของ “security by trickery” และถูกยกให้เป็นเหตุผลที่น่ารอคอย OpenBSD รุ่นถัดไป
- ระบบอื่น ๆ อาจได้เห็นฟีเจอร์นี้ในไม่ช้าผ่าน openssh-portable
1 ความคิดเห็น
ความคิดเห็นจาก Hacker News
จังหวะเวลาการกดแป้นพิมพ์ เป็นปัญหาที่ถูกกังวลกันในงาน I/O ของเทอร์มินัลมาตั้งแต่ทศวรรษ 1980 และแม้ในตอนนั้นก็เป็นสิ่งที่สภาพแวดล้อมเข้ารหัสยุคแรก ๆ อย่าง stelnet หรือ Kerberos ใส่ใจอยู่แล้ว
แอปเทอร์มินัลส่วนใหญ่ใช้ I/O แบบบัฟเฟอร์ สำหรับการป้อนรหัสผ่าน และนี่ก็ยังเป็นฟีเจอร์ด้านความปลอดภัยที่สำคัญอยู่
ในโหมดนี้จะไม่มีสิ่งใดถูกส่งไปยังอีกฝั่งจนกว่าผู้ใช้จะกด Enter ดังนั้นหากมีการแพดดิ้ง ผู้โจมตีแบบคนกลางก็ยากที่จะอนุมานแม้แต่ความยาวของรหัสผ่าน
ช่วงหนึ่ง แอปที่รับรหัสผ่านในโหมดไม่บัฟเฟอร์เพื่อแสดง
*ทุกครั้งที่ผู้ใช้พิมพ์ กลายเป็นเหยื่อชั้นดีมันดูเท่และให้ฟีดแบ็กก็จริง แต่กลับรั่วไหลความเร็วในการกดแป้น ซึ่งเป็นสิ่งที่ควรปกปิดที่สุดในการป้อนรหัสผ่าน
ผมอยากให้การป้อนรหัสผ่านยังคงใช้ I/O แบบบัฟเฟอร์ต่อไป และมองว่าวิธีนี้ดีกว่าจน SSH ทำ obfuscation แล้วยังตามได้ยาก
ถึงอย่างนั้น การที่ SSH เพิ่มฟีเจอร์นี้ก็เป็นเรื่องดี และช่วยปกป้องสิ่งที่บัฟเฟอร์ไม่ได้ เช่น อินพุตของเชลล์หรือเอดิเตอร์
พวกเขาอาจคิดว่า “ความยาวไม่ถูก แสดงว่าน่าจะผิด” แล้วทำให้ข้อดีของรหัสผ่านที่บันทึกไว้หมดไป โดยพยายามพิมพ์รหัสผ่านที่ “ถูกต้อง” เองอีกครั้ง
ในอดีตเหมือนเคยมีวิธีแสดง visual hash เช่น แฮช 2 หลักกับสไมลีย์ แต่สำหรับการโจมตีแบบแอบมองข้ามไหล่ วิธีนี้อาจช่วยผู้โจมตีเสียด้วยซ้ำ
ตอนนี้ก็สามารถนำไปใช้กับการล็อกอินบนหน้าจอสัมผัสได้เช่นกัน โดยเชื่อมโยงแรงกดของนิ้ว พื้นที่สัมผัส และรูปทรงกับผู้ใช้
ถ้ารวมการปัดหน้าจอหรือการเคลื่อนไหวของเมาส์เข้าไปในบริบทของเดสก์ท็อป OS ก็อาจทำแอปความปลอดภัยที่ล็อกระบบได้เมื่อมีผู้ใช้ที่ไม่ใช่เจ้าของเครื่องหรือบัญชีกำลังใช้งานอยู่
อย่างน้อยก็สามารถบันทึกได้ว่าแฟนของผมแอบค้นโทรศัพท์ผมตอนไหน
กล่าวคือ เป็นแบบที่สิ่งที่พิมพ์จะไม่ถูกส่งจนกว่าจะกด Enter หรือปุ่มส่ง
สมัยก่อนที่เล่น MUD อย่างหนัก ผมเคยใช้ไคลเอนต์ Telnet แบบนี้ แต่ในไคลเอนต์ SSH ที่เคยใช้หลังจากนั้นไม่เคยเห็นเลย
ดูเหมือนจะเป็นการป้องกันที่ดีต่อการรั่วไหลของจังหวะเวลาการกดแป้นใน SSH และในบางกรณีการใช้งานอาจดีกว่าวิธีหน่วง 20ms ที่กล่าวในบทความด้วยซ้ำ
แต่พอคิดดูแล้ว ถ้ากด Tab เพื่อใช้ autocomplete ของเชลล์ Linux แล้วส่งไปด้วย ก็น่าจะเหมาะกว่า
นึกถึง Bridge ระดับโปร
แบ่งทีมด้วยผนัง แล้วส่งไพ่ผ่านช่องพร้อมกัน เพื่อป้องกัน การสื่อสารผ่านจังหวะเวลา
https://youtube.com/watch?v=RVZLNRmO3vo
https://en.wikipedia.org/wiki/Blue_Team_(bridge)#Cheating_an...
https://en.wikipedia.org/wiki/Fantoni_and_Nunes_cheating_sca...
https://en.wikipedia.org/wiki/Fisher_and_Schwartz_cheating_s...
และนี่เป็นเพียงกรณีที่เรารู้เท่านั้น
เมื่อก่อนผมเคยเอา Bridge ไปใช้จริงในการสัมภาษณ์งาน
ใน Bridge มีกฎ Active Ethics ที่ว่า หากคู่เล่นให้คำใบ้ด้วยวิธีอื่นนอกเหนือจากการบิด เมื่อเป็นไปได้ตามตรรกะ คุณต้องเลือกทางตรงข้ามเสมอ
ในการสัมภาษณ์ด้านดีบัก ผู้สัมภาษณ์พยายามชี้นำไปสู่คำตอบอย่างโจ่งแจ้งเกินไป ผมจึงหยุดตรวจสอบทุกอย่างที่นึกออกก่อนจะทำตามที่เขาพูด
หลังสัมภาษณ์ผมบอกเหตุผลว่าทำไม และบอกว่าถ้าต้องการคำอธิบายเพิ่มเติมให้ลองค้นหา Active Ethics
แล้วผมก็ผ่าน
นี่คล้ายกับการบอกว่าแคตเชอร์ห้ามส่งสัญญาณให้พิทเชอร์
การส่งข้อมูล เป็นทักษะของมนุษย์ที่เพิ่มมิติให้เกม และควรปล่อยให้ฝ่ายที่ทำได้ดีที่สุดเป็นผู้ชนะ
ดูเหมือนการส่งข้อมูลสัก 1–2 บิตจะไม่ยากนัก
การสื่อสารลับ กับคู่เล่นคือหัวใจสำคัญ แต่การสื่อสารนั้นห้ามเป็นความลับ
มันประหลาดมาก เหมือนบอกว่าสื่อสารได้ แต่ห้ามสื่อสาร
เช่น อาจดันโต๊ะเล็ก ๆ ข้ามแผงกั้นแบบกระแทกหรือค่อย ๆ ดัน เพื่อสื่อความหมายบางอย่าง
คนด้านขวาบนของวิดีโอส่งแบบนั้นในครั้งที่หนึ่งและครั้งที่สอง
มีบทความปี 2008 ที่แนะนำเปเปอร์ปี 2001 เกี่ยวกับ timing attack แบบนี้: https://lwn.net/Articles/298833/
เปเปอร์ที่อ้างถึงคือ “Timing analysis of keystrokes and timing attacks on SSH” และวิเคราะห์ว่าข้อมูลจังหวะเวลาการกดแป้นรั่วไหลข้อมูลเกี่ยวกับลำดับแป้นที่พิมพ์
การวิเคราะห์ที่ละเอียดกว่านั้นบอกว่า สำหรับแต่ละคู่ของการกดแป้น จะรั่วไหลข้อมูลเกี่ยวกับเนื้อหาราว 1 บิต และเนื่องจากเอนโทรปีของรหัสผ่านอยู่ราว 4–8 บิตต่ออักขระ ข้อมูลนี้จึงอาจมีนัยสำคัญมาก
ผมคิดว่าเรื่องนี้ถูกแก้ไปนานแล้ว และเข้าใจว่ามีการแก้ไขราวปี 2012 เลยค่อนข้างแปลกใจที่มันยังไม่ถูกแก้
สักวันหนึ่งเราอาจต้องใช้ แพ็กเก็ตที่เติมข้อมูลสุ่มไว้ล่วงหน้า เพื่อซ่อนการกดแป้นพิมพ์
แม้จะไม่ใช่สเตกาโนกราฟี แต่ก็เป็นวิธีที่ค่อนข้างใกล้เคียง และน่าจะใช้ทำให้การวิเคราะห์ทราฟฟิกยากขึ้นหรือเป็นไปไม่ได้ด้วย
ถ้าเป็นสายสื่อสารเฉพาะ ก็ไม่ยากนักที่จะปล่อยข้อมูลที่เข้ารหัสเต็มรูปแบบให้ไหลผ่านสายอยู่ตลอดที่อัตราการใช้งานสูงสุด แล้วค่อยใส่ข้อมูลจริงลงไปเฉพาะเมื่อจำเป็น
มีงานวิจัยที่ให้โมเดลภาษาเขียน cover text ที่ดูไม่เป็นพิษเป็นภัยขึ้นใหม่ แต่เปลี่ยนการแจกแจงความน่าจะเป็นที่ใช้ในการสุ่มคำให้เป็นการบิดเบือนที่มีเอนโทรปีต่ำสุดซึ่งได้มาจากคีย์
ฝั่งรับสามารถใช้โมเดลและคีย์เดียวกันถอด cover text กลับเป็นข้อความเข้ารหัสได้ และยังใช้กับภาพได้ด้วย
https://openreview.net/forum?id=HQ67mj5rJdR
กระจายเสียงตัวเลขไปทั่วโลกอย่างต่อเนื่อง และตัวเลขเหล่านั้นจะมีความหมายก็ต่อเมื่อมันมีความหมายกับใครบางคนเท่านั้น
พวกเขาทำแบบนั้นทั้งที่รู้กันอยู่แล้วว่าหน่วยข่าวกรองทั่วโลกคอยฟังอยู่
นึกถึงเทอร์มินัลอีมูเลเตอร์รุ่นใหม่ ๆ อย่าง Warp บน macOS
เช่น สงสัยว่ามันรับอินพุตทั้งหมดไว้ในเครื่องก่อน แล้วค่อยส่งไปยังโฮสต์ระยะไกลเป็นก้อนเดียวหรือไม่
ถ้าทำแบบนั้น อินพุตแบบ raw mode บางอย่างที่ทำงานบนโฮสต์ระยะไกลอาจพังได้ แต่ก็น่าจะตรวจจับสถานการณ์แบบนั้นแล้วสลับไปใช้สตรีมการกดแป้นพิมพ์ดิบได้
[1]: https://warp.dev
pty ระยะไกลอาจเป็นโหมดรายบรรทัดหรือ raw mode ก็ได้
เทอร์มินัลที่มีการผสานรวมกับเชลล์แบบพิเศษมักต้องติดตั้งการผสานรวมนั้นบนโฮสต์ระยะไกลด้วย และบางตัวก็จัดการเรื่องนี้ได้ค่อนข้างโปร่งใส
ดังนั้น mosh จึงอาจทำงานได้ดีกว่า SSH ล้วน ๆ บนการเชื่อมต่อที่มี latency สูง
อย่างไรก็ตาม ฟีเจอร์นี้คงไม่ถูกนำไปใช้กับ mosh
ฟีเจอร์ด้านความปลอดภัยบางอย่าง เช่น การป้องกัน timing attack อาจเป็นสิ่งที่เครื่องมือใหม่ป้องกันได้ดีกว่า และเครื่องมือมาตรฐานเก่า ๆ อาจไม่มี
แต่มีโอกาสมากกว่ามากที่เครื่องมือใหม่จะขาดฟีเจอร์ด้านความปลอดภัยอื่น ๆ และการเพิ่ม “AI” ก็ทำให้พื้นผิวโจมตีเพิ่มขึ้นอย่างมาก
พูดตรง ๆ คำกล่าวอ้างด้านความเป็นส่วนตัวของ Warp ก็เชื่อได้ยาก
เครื่องมือประมวลผลภาษาธรรมชาติในปัจจุบันแทบทั้งหมดเอนเอียงไปทางโซลูชันบนคลาวด์ และถ้าเป็นเช่นนั้น ความเป็นไปได้ด้านความเป็นส่วนตัวก็แทบจะเข้าใกล้ศูนย์ทันที
สงสัยว่าภัยคุกคามที่สิ่งนี้ช่วยบรรเทาคืออะไร
ถ้ารู้ รูปแบบการพิมพ์ ของเป้าหมาย ก็สามารถใช้ข้อมูลนั้นกู้คืนเนื้อหาได้
อาจให้เป้าหมายพิมพ์ลงในเว็บไซต์ที่ฉันควบคุมผ่านเบราว์เซอร์ที่เปิด JavaScript ไว้ หรืออัดเสียงการพิมพ์เพื่อเก็บรูปแบบก็ได้
เมื่อเร็ว ๆ นี้ สตรีมเมอร์ออนไลน์บางคนยังถูกโจมตีด้วยโมเดล AI ที่ฝึกจากเสียงพิมพ์คีย์บอร์ดเพื่อขโมยรหัสผ่านด้วย
ฟีเจอร์นี้ดูเหมือนจะเพิ่มสัญญาณรบกวนเพื่อป้องกันเรื่องนั้น
http://www.cs.berkeley.edu/~dawnsong/papers/ssh-timing.pdf [2001]
เมื่อมี machine learning เข้ามาเพิ่ม ความแม่นยำในการถอดรหัสจากเสียงก็ดีขึ้นมาก ดังนั้นในสถานที่ที่ไม่ปลอดภัยทางกายภาพ ควรใช้คีย์บอร์ดที่เงียบ
https://arstechnica.com/gadgets/2023/08/type-softly-research...
ตัวอย่างเช่น ผู้ใช้มักพิมพ์รหัสผ่านเร็วกว่าการพิมพ์อื่น ๆ ดังนั้นในงานอย่าง
sudoจึงอาจเดา ความยาวรหัสผ่าน ได้จากจำนวนการกดแป้นที่ถูกส่งรวมกันในครั้งเดียวกรณีใช้งานของตัวเปเปอร์เองไม่ใช่ภัยคุกคามด้านความปลอดภัย แต่ก็สามารถตีความได้ว่าเป็นการรั่วไหลของข้อมูล
สงสัยว่าจะเพิ่ม latency เท่าไร
โดยเฉพาะ latency ที่คาดเดาไม่ได้เป็นหนึ่งในปัจจัยสร้างความเครียดที่ใหญ่ที่สุดในงานพัฒนาซอฟต์แวร์
เมื่อมีข้อมูลปริมาณน้อย จะส่งทราฟฟิกแบบโต้ตอบเป็น ช่วงเวลาคงที่ โดยค่าเริ่มต้นคือ 20ms
[1]
เครื่องมืออย่าง Mosh ช่วยลด latency ที่รู้สึกได้ค่อนข้างมาก
Mosh จะแสดงการกดแป้นของผู้ใช้ทันทีที่ถูกลงทะเบียนในเครื่อง และแสดงเป็นสีจางเพื่อบอกว่ายังไม่ได้รอรอบไปกลับเสร็จ
ครั้งสุดท้ายที่เห็นเป็นแบบนั้น และบางทีอาจเป็นขีดเส้นใต้ก็ได้
เมื่อรอบไปกลับเสร็จ ตัวอักษรจะแสดงตามปกติ
[1] ถ้าปัจจัยสร้างความเครียดที่ใหญ่ที่สุดในการพัฒนาซอฟต์แวร์คือ latency ของการกดแป้นพิมพ์ ก็ฟังดูถือว่าโชคดีทีเดียว
[2]: https://mosh.org
ลิงก์คอมมิตจริง: https://github.com/openssh/openssh-portable/commit/7603ba712...
ดูเหมือนว่าบางส่วนจะวัด timing ของแพ็กเก็ตเพื่อตรวจจับ เชลล์แบบ hands-on-keyboard บนเครือข่าย เลยสงสัยว่าการเปลี่ยนแปลงนี้จะรบกวนการตรวจจับแบบนั้นได้มากแค่ไหน
ผมมองว่าเป็นวิธีเข้าหาความปลอดภัยที่ผิดจริง ๆ
ถ้ารู้ได้ว่าสคริปต์อัตโนมัติกำลังล็อกอินเข้าอุปกรณ์ก็ดีอยู่หรอก แต่ถ้าออกแบบให้ดีกว่านี้ ข้อมูลนั้นก็ไม่ควรสำคัญอีกต่อไป