นักวิจัยความปลอดภัย Özgün Kültekin เปิดเผยช่องโหว่ OpenSSH ที่ตั้งชื่อเล่นว่า “*sshole” เมื่อต้นเดือนพฤศจิกายน 2569 ช่องโหว่นี้ทำให้ผู้โจมตีล็อกอินผ่าน SSH เข้าบัญชีที่ปิดการใช้รหัสผ่านไว้ได้ เพียงพิมพ์รหัสผ่านยาวเกิน 256 ตัวอักษร กระทบระบบที่ใช้ไลบรารี musl เช่น Alpine Linux, Void Linux และ OpenWrt ที่อยู่ในเราเตอร์บ้าน อุปกรณ์ IoT และคอนเทนเนอร์ Docker จำนวนมาก ทางแก้คืออัปเดตเป็น OpenSSH 10.6p2 แล้วรีสตาร์ต sshd
สารบัญ
⚡ สรุปข่าวใน 30 วินาที
- ช่องโหว่ *sshole กระทบ OpenSSH บนระบบที่ใช้ musl ไม่มี PAM
- ใส่รหัสผ่านยาว 257-1,024 ตัวอักษร แล้วล็อกอินบัญชีที่ปิดรหัสผ่านได้
- เสี่ยง: Alpine, Void Linux, OpenWrt, คอนเทนเนอร์ Docker, เราเตอร์และ IoT
- ไม่กระทบ Debian, Ubuntu, Fedora และระบบที่ใช้ PAM
- แก้: อัปเดต OpenSSH 10.6p2 หรือปิด PasswordAuthentication
ช่องโหว่ทำงานอย่างไร
บน Linux บัญชีที่ไม่มีรหัสผ่าน เช่น root หรือบัญชีที่ล็อกอินด้วยกุญแจ SSH อย่างเดียว จะมีเครื่องหมายดอกจัน (*) อยู่ในช่องรหัสผ่าน ปกติแฮชของรหัสผ่านจริงไม่มีทางตรงกับดอกจัน บัญชีจึงล็อกอินด้วยรหัสผ่านไม่ได้
ปัญหาอยู่ที่ฟังก์ชัน crypt() ของ musl ซึ่งรับข้อมูลได้สูงสุด 256 ไบต์ ถ้ารหัสผ่านยาวกว่านั้น ฟังก์ชันจะคืนค่าดอกจันออกมาเป็นสัญญาณว่าเกิดข้อผิดพลาด ค่านี้บังเอิญตรงกับดอกจันที่เก็บไว้ในบัญชีที่ล็อกไว้ ระบบจึงเข้าใจว่ารหัสผ่านถูกและให้ล็อกอินได้ ผู้โจมตีต้องการแค่เข้าถึงพอร์ต SSH ทางเครือข่ายเท่านั้น
ต้นเหตุมาจากการแก้ CVE-2016-6210 ในปี 2016 ที่ให้ sshd แฮชรหัสผ่านทุกครั้งเพื่อกันการเดาชื่อผู้ใช้ เมื่อทำงานบน musl จึงเผยเครื่องหมายล็อกบัญชีออกมา
ระบบไหนเสี่ยง ระบบไหนปลอดภัย
ระบบที่เสี่ยงต้องเข้าเงื่อนไขพร้อมกัน คือ sshd คอมไพล์กับ musl และไม่ใช้ PAM เปิด PasswordAuthentication มีบัญชีที่ล็อกด้วยดอกจัน และมีบัญชีอย่างน้อยหนึ่งบัญชีที่ตั้งรหัสผ่านแบบ SHA-256 หรือ SHA-512
| ระบบ | ความเสี่ยง |
|---|---|
| Alpine Linux | เสี่ยง (มีอัปเดตแก้แล้ว) |
| Void Linux | เสี่ยง |
| OpenWrt (เราเตอร์บ้าน) | เสี่ยง |
| ระบบที่สร้างด้วย Buildroot, Yocto | เสี่ยง |
| คอนเทนเนอร์ Docker ที่ใช้ Alpine | เสี่ยง |
| Debian, Ubuntu, Fedora (glibc) | ไม่กระทบ |
| ระบบที่ใช้ PAM | ไม่กระทบ |
ค่าเริ่มต้น PermitRootLogin prohibit-password ช่วยกันบัญชี root ไว้ได้ แต่ถ้าบัญชีอื่นที่เข้าถึงได้มีสิทธิ์ sudo หรือ doas ผู้โจมตีก็ยกระดับเป็นผู้ดูแลได้ง่าย นักวิจัยยังอ้างว่าอิมเมจ Alpine บน AWS และ Azure มีบัญชี alpine ที่ใช้ doas ได้โดยไม่ต้องใส่รหัสผ่าน
วิธีแก้และตรวจสอบ
- ขั้นที่ 1 อัปเดตเป็น OpenSSH 10.6p2 หรือสั่ง apk upgrade openssh บน Alpine
- ขั้นที่ 2 รีสตาร์ต sshd เพราะการอัปเดตแพ็กเกจอย่างเดียวไม่ได้เปลี่ยนโปรแกรมที่รันอยู่
- ขั้นที่ 3 ถ้ายังอัปเดตไม่ได้ ตั้ง PasswordAuthentication no แล้วรีสตาร์ต sshd
- ขั้นที่ 4 ตรวจ log SSH หาการล็อกอินด้วยรหัสผ่านสำเร็จในบัญชีที่ไม่ควรรับรหัสผ่าน
- ขั้นที่ 5 ตรวจหาผู้ใช้ใหม่ ไฟล์แปลก กุญแจ SSH ที่ไม่รู้จัก และการใช้ doas ที่ผิดปกติ
ถ้าตรวจแล้วไม่สามารถตัดความเป็นไปได้ว่ามีคนล็อกอินเข้ามา ควรถือว่าเครื่องถูกเจาะแล้ว และติดตั้งระบบใหม่หรือกู้จากข้อมูลสำรองที่สะอาด
ทำไมเราเตอร์และ IoT น่ากังวลที่สุด
เซิร์ฟเวอร์ทั่วไปมักได้อัปเดตเร็ว แต่อุปกรณ์อย่างเราเตอร์บ้าน กล่องรับสัญญาณ และตัวควบคุมในโรงงาน มักใช้ระบบที่สร้างจาก musl และแทบไม่เคยได้รับอัปเดต ถ้าอุปกรณ์เหล่านี้เปิดพอร์ต SSH ออกอินเทอร์เน็ตพร้อมเปิดล็อกอินด้วยรหัสผ่าน ก็อาจถูกเจาะได้ง่าย
ผู้ใช้ทั่วไปที่ใช้เราเตอร์ OpenWrt ควรตรวจว่าเปิด SSH ไว้ทางฝั่งอินเทอร์เน็ตหรือไม่ ถ้าไม่ได้ใช้ให้ปิดไว้ และอัปเดตเฟิร์มแวร์เป็นเวอร์ชันล่าสุด
ฝ่ายไหนรับผิดชอบ
ทีม OpenSSH มองว่าต้นเหตุอยู่นอก sshd แต่ได้เพิ่มการป้องกันเข้าไปแล้ว ส่วนผู้ดูแล musl บอกว่าไลบรารีทำงานตามที่เขียนไว้ในเอกสาร และวางแผนปรับปรุงภายหลัง ผู้ดูแล Alpine เตือนว่าผู้โจมตีที่เข้าถึงพอร์ต SSH ได้ สามารถล็อกอินได้โดยไม่ต้องรู้รหัสผ่านใดเลย
นักวิจัยระบุว่าเขาใช้เอเจนต์ AI ช่วยรันการทดสอบการยืนยันตัวตนราว 17,600 ครั้งจนพบช่องโหว่นี้ เป็นอีกตัวอย่างที่ AI ถูกใช้หาช่องโหว่ได้เร็วขึ้น ทั้งฝั่งผู้ป้องกันและผู้โจมตี
คำถามที่พบบ่อยเกี่ยวกับ ช่องโหว่ OpenSSH *sshole
ช่องโหว่ *sshole คืออะไร
ช่องโหว่ใน OpenSSH บนระบบ musl ที่ใส่รหัสผ่านยาวเกิน 256 ตัวอักษรแล้วล็อกอินบัญชีที่ปิดรหัสผ่านได้
Ubuntu ได้รับผลไหม
ไม่ได้รับผล เพราะใช้ glibc ไม่ใช่ musl
แก้ไขอย่างไร
อัปเดตเป็น OpenSSH 10.6p2 แล้วรีสตาร์ต sshd
ถ้ายังอัปเดตไม่ได้ทำอย่างไร
ตั้ง PasswordAuthentication no ในไฟล์ตั้งค่า SSH แล้วรีสตาร์ต
ใครค้นพบ
นักวิจัย Özgün Kültekin
ความคิดเห็น 0
ยังไม่มีความคิดเห็นเป็นคนแรกที่แสดงความคิดเห็นในบทความนี้