แฮ็กเกอร์ยึด Tor exit node 333 ตัว (~10% ของเครือข่าย) ดักการเชื่อมต่อ SSH ขโมยรหัสผ่าน แล้วฝังแบ็กดอร์ Ebury บนเซิร์ฟเวอร์ปลายทาง

สรุปสั้น

นักวิจัยรายหนึ่งเผยแพร่บันทึกการสืบสวนเมื่อ 20 ตุลาคม 2569 ว่าผู้โจมตียึด Tor exit node ได้ 333 ตัว คิดเป็นราว 10% ของ exit relay ประมาณ 3,000 ตัวในเครือข่าย Tor โดยเข้าถึงเซิร์ฟเวอร์เบื้องหลังตั้งแต่เดือนสิงหาคม ก่อนเปิดฉากดักทราฟฟิกพร้อมกันเมื่อ 2 ตุลาคม เวลา 9:35 น. ปฏิบัติการนี้เล็งการเชื่อมต่อ SSH และอีเมลที่ไม่เข้ารหัสโดยเฉพาะ ส่วนทราฟฟิกเว็บที่เข้ารหัสยังผ่านไปตามปกติ ทำให้ผู้ใช้สังเกตความผิดปกติได้ยาก ผู้ใช้ที่ไม่สนใจคำเตือนว่า host key เปลี่ยนแล้วล็อกอินต่อจะเสียรหัสผ่านให้ผู้โจมตีทันที

หลังได้รหัสผ่าน ผู้โจมตีเชื่อมต่อไปยังเซิร์ฟเวอร์ปลายทางตัวจริงในฐานะคนกลาง ดูคำสั่งที่ผู้ใช้พิมพ์ และเปิดการเชื่อมต่ออีกช่องเพื่อพยายามติดตั้ง Ebury 1.8.3 แบ็กดอร์ OpenSSH และมัลแวร์ขโมยข้อมูลรับรองบน Linux ทีม network health ของ Tor ได้รับแจ้งในวันเดียวกัน และติดธง BadExit ให้ relay ที่ได้รับผลกระทบภายใน 4 ตุลาคม เซิร์ฟเวอร์ที่ติดเชื้อทั้งหมดที่ระบุได้ถูกปิดในวันที่ 5 ตุลาคม แต่ยังไม่ทราบว่าผู้โจมตีเจาะเซิร์ฟเวอร์ได้อย่างไร และใครอยู่เบื้องหลัง

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

เว็บไซต์ GBHackers รายงานเมื่อวันที่ 21 ตุลาคม 2569 ว่า นักวิจัยพบการโจมตีโดยบังเอิญ เมื่อการเชื่อมต่อ SSH ผ่าน Tor ขึ้นคำเตือน “REMOTE HOST IDENTIFICATION HAS CHANGED” พร้อม fingerprint แบบ ED25519 ที่ไม่ตรงกับเซิร์ฟเวอร์ที่เคยเชื่อถือ แสดงว่าเครื่องที่ตอบกลับไม่ใช่เซิร์ฟเวอร์ตัวจริง เขาจึงสร้างเครื่องสแกนด้วย exitmap แล้วทดสอบ exit node ราว 3,000 ตัวทีละตัว โดยเปิดการเชื่อมต่อ SSH ระหว่างเซิร์ฟเวอร์สองเครื่องที่ตัวเองควบคุมผ่าน exit relay ที่เลือก

ฝั่งต้นทางตรวจ fingerprint ของปลายทาง ส่วนฝั่งปลายทางตรวจว่าทราฟฟิกมาจาก relay ที่เลือกจริง หรือมาจากเซิร์ฟเวอร์ดักกลาง ผลคือมี relay ราว 12 ตัวที่แสดง fingerprint ปลอม แต่มีอีกกว่า 300 ตัวที่ส่งต่อการเชื่อมต่อผ่านโครงสร้างดักกลางชุดเดียวกัน แม้ไม่ได้สลับ fingerprint ระหว่างการทดสอบ เส้นทางการส่งต่อร่วมกันนี้เองที่เปิดโปงเครื่องที่ถูกยึดทั้งหมด 333 ตัว

นักวิจัยแจ้งทีม network health ของ Tor เมื่อ 2 ตุลาคม ภายใน 4 ตุลาคม ทีม Tor แจ้งผู้ดูแล relay และติดธง BadExit ให้ relay เหล่านั้นไม่ถูกเลือกเป็นทางออก ในวันที่ 5 ตุลาคม ผู้โจมตีรีสตาร์ต relay จำนวนมาก แต่ธงที่ติดไว้จำกัดให้ทำงานได้แค่ middle relay และเซิร์ฟเวอร์ที่ติดเชื้อทั้งหมดที่ระบุได้ถูกปิดในวันเดียวกัน ทีม Tor ยังพบว่าผู้โจมตีแก้ไฟล์ torrc เพื่อแปลง relay ที่ไม่ใช่ exit ให้กลายเป็น exit relay ข้อมูลทั้งหมดมาจากบันทึกของนักวิจัยคนเดียว และข้อสันนิษฐานว่าผู้ให้บริการโฮสติ้งถูกเจาะยังไม่ได้รับการยืนยัน

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

relay ที่ถูกยึดเปลี่ยนเส้นทางการเชื่อมต่อ SSH บนพอร์ต TCP 22 ไปยังเซิร์ฟเวอร์ดักกลาง 12 เครื่องที่ผู้โจมตีควบคุม เซิร์ฟเวอร์เหล่านี้ตอบกลับด้วย host key ของตัวเอง หากผู้ใช้ยังไม่เคยเชื่อมต่อเซิร์ฟเวอร์ปลายทางมาก่อน หรือเพิกเฉยต่อคำเตือนแล้วยืนยันตัวตนด้วยรหัสผ่าน รหัสผ่านจะตกอยู่ในมือผู้โจมตีทันที การยืนยันตัวตนด้วยกุญแจ (public key) ไม่เปิดเผยความลับแบบเดียวกัน เพราะผู้โจมตีไม่ได้กุญแจส่วนตัวของผู้ใช้

จากนั้นผู้โจมตีใช้รหัสผ่านที่ได้เชื่อมต่อไปยังเซิร์ฟเวอร์ปลายทางตัวจริง ส่งต่อเซสชันแบบ man-in-the-middle เพื่อให้ผู้ใช้ทำงานได้ปกติขณะถูกดูคำสั่ง และเปิดการเชื่อมต่ออีกช่องเพื่อติดตั้ง Ebury นักวิจัยใช้ honeypot sshesame สังเกตพฤติกรรม พบร่องรอยของ Paramiko ไลบรารี SSH ภาษา Python และความพยายามติดตั้ง Ebury ผ่านสคริปต์ Perl คำสั่งที่เห็นเริ่มจากตรวจ user ID และสิทธิ์ sudo รวมถึงเช็กว่ายกระดับสิทธิ์ได้โดยไม่ต้องใส่รหัสผ่านหรือไม่ แล้วจึงถอดรหัส payload แบบ Base64 และสั่งรัน

Ebury เป็นแบ็กดอร์ที่ฝังใน OpenSSH บนเซิร์ฟเวอร์ Linux ใช้ขโมยข้อมูลรับรองของทุกคนที่ล็อกอินเข้าเครื่อง และเปิดทางให้ผู้โจมตีกลับเข้ามาได้ภายหลัง เซิร์ฟเวอร์ที่ติด Ebury จึงกลายเป็นจุดขโมยรหัสผ่านต่อเนื่อง ไม่ใช่แค่เครื่องที่ถูกเจาะครั้งเดียว อย่างไรก็ดี การพบ Ebury เพียงอย่างเดียวไม่ได้บอกว่ากลุ่มใดอยู่เบื้องหลังปฏิบัติการนี้

อัปเดต 23 ต.ค. 2569: ขอบเขตที่แท้จริง และ post-mortem ของผู้ดูแล relay ที่ถูกเจาะ

เว็บไซต์ The Hacker News รายงานเพิ่มเติมเมื่อวันที่ 21 ตุลาคม 2569 โดยรวบรวมประกาศของทีม network health ของ Tor บทวิเคราะห์ข้อมูล directory สาธารณะที่โพสต์ใน mailing list tor-relays และ post-mortem ของผู้ดูแล relay รายใหญ่ที่ถูกเจาะ ข้อมูลชุดนี้ปรับภาพของเหตุการณ์หลายจุด ประการแรก ตัวเลข “ราว 10%” หมายถึงจำนวน relay (333 จากราว 3,000 ตัว) แต่เมื่อวัดตามน้ำหนักใน consensus ซึ่งสะท้อนสัดส่วนทราฟฟิกจริง relay ที่ใช้นโยบายของผู้โจมตีคิดเป็น 7.46% ของความจุ exit ทั้งหมด ณ จุดสูงสุดวันที่ 4 ตุลาคม ประการที่สอง บทวิเคราะห์ directory นับได้ 377 relay จากผู้ดูแล 59 ราย ที่เปลี่ยนมาใช้นโยบายของผู้โจมตีระหว่าง 1 ถึง 4 ตุลาคม โดยระบุชัดว่าเป็น “การตรงกันของนโยบาย ไม่ใช่หลักฐานว่าถูกเจาะ” และช่วงที่ผู้ใช้เสี่ยงจริงจึงเริ่มตั้งแต่ 1 ตุลาคม ไม่ใช่ 2 ตุลาคม ไปจนถึงบ่ายวันที่ 5 ตุลาคม

ผู้โจมตีแก้ไฟล์ torrc เปิดพอร์ต 22 ให้ relay 342 ตัวที่เดิมบล็อก SSH และเปลี่ยน relay อีก 24 ตัวที่ไม่ใช่ exit ให้เป็น exit การแก้เดียวกันยังปิดพอร์ตอีเมลแบบเข้ารหัส (IMAPS และ POP3S) และเปิดพอร์ต POP3 และ IMAP แบบที่ส่งข้อความธรรมดาได้บน relay ส่วนใหญ่ เหตุผลที่ปิดพอร์ตอีเมลเข้ารหัสยังไม่ชัด ในวันที่ 4 ตุลาคม ทีม Tor ติดต่อนาย Zimmer ผู้ดูแลกลุ่ม relay ชื่อ Quetzalcoatl ซึ่งเป็นกลุ่มใหญ่ที่สุดที่ได้รับผลกระทบ เขายืนยันว่าไม่ได้เปลี่ยนนโยบายเอง directory authority เริ่มโหวตธง BadExit และ MiddleOnly ตั้งแต่ 18:00 UTC และธงอยู่ใน consensus ภายใน 21:00 UTC เช้าวันที่ 5 ตุลาคม มีสคริปต์รีสตาร์ตโฮสต์ 55 เครื่องของ Quetzalcoatl โดยนโยบายยังคงอยู่ ซึ่งยังไม่รู้ว่าใครเป็นคนรัน และภายใน 17:00 UTC วันเดียวกันไม่มี relay ที่ใช้นโยบายของผู้โจมตีเหลือใน consensus อีก จำนวน relay ที่มีธง Exit ลดลงราว 370 ตัวระหว่าง 3 ถึง 5 ตุลาคม และยังไม่ฟื้นจนถึง 18 ตุลาคม

post-mortem ของนาย Zimmer ลงวันที่ 7 ตุลาคม ระบุว่าเซิร์ฟเวอร์ 2 เครื่องของเขาติด Ebury เวอร์ชัน 1.8.3 คือเซิร์ฟเวอร์จัดการบน Contabo ที่เป็น VPN gateway และ SSH jump host ของกลุ่ม และ VPS บน FranTech ชื่อ Switzerland2 ที่รัน exit 2 ตัว ผู้โจมตีล็อกอินเซิร์ฟเวอร์จัดการเมื่อ 28 สิงหาคมด้วยรหัสผ่านของบัญชีผู้ดูแลได้ในครั้งแรก ได้สิทธิ์ root ภายใน 5 นาที ติดตั้ง Ebury แล้วกระโดดไป Switzerland2 ในอีกราวหนึ่งชั่วโมงต่อมา เขายอมรับว่า “ต้นเหตุคือฝั่งเรา” เพราะใช้รหัสผ่านเดียวกันทั้ง SSH, sudo และ passphrase ของแบ็กอัป เก็บเป็นข้อความธรรมดาบนเซิร์ฟเวอร์ทั้งสองเครื่อง และเปิด SSH password authentication บนเซิร์ฟเวอร์จัดการที่หันหน้าออกอินเทอร์เน็ต ส่วนแหล่งที่ผู้โจมตีได้รหัสผ่านไปยังไม่รู้ ที่แย่กว่านั้นคือกุญแจหลักแบบ “offline” ของกลุ่ม relay ไม่ได้ offline จริง เพราะมีสำเนาอยู่ในแบ็กอัปบนเซิร์ฟเวอร์จัดการ เข้ารหัสด้วยรหัสผ่านที่ผู้โจมตีมีอยู่แล้ว เขาจึงปลดระวาง relay และ bridge ทั้งหมดในกลุ่มและลบเซิร์ฟเวอร์ทั้งสองเครื่อง

Ebury ที่พบเป็นไลบรารี setuid ไฟล์เดียว คือ /usr/lib/x86_64-linux-gnu/libkeyutils.so.1.10.2 โดยชี้ symlink libkeyutils.so.1 มาที่ไฟล์นี้ ไลบรารีของแพ็กเกจจริงไม่ถูกแตะ ทำให้ dpkg -V และ debsums ตรวจไม่เจอ และ sshd, sudo, PAM ผ่านการตรวจแพ็กเกจหมด การล็อกอินผ่านแบ็กดอร์ของ Ebury ไม่ทิ้งร่องรอย ไฟล์ตั้งค่า exit ถูกเขียนใหม่เมื่อ 2 ตุลาคม โดยไม่มีการล็อกอิน คำสั่ง sudo หรือ cron job ใดในล็อก และการรีบูตตามรอบเมื่อ 4 ตุลาคมฆ่าเครื่องมือที่ซ่อนอยู่ได้ แต่ Ebury กลับมาทันที เวอร์ชัน 1.8.3 ใหม่กว่า IoC สาธารณะของบริษัท ESET ที่หยุดอยู่ที่ 1.8.2 และสคริปต์ตรวจจับที่ ESET เผยแพร่ยังไม่มีชื่อ socket ของเวอร์ชันนี้ นาย Marc-Etienne M. Léveillé ผู้ร่วมเขียนรายงาน Ebury ของ ESET ปี 2557 และเขียนรายงานปี 2567 ซึ่งออกจากบริษัทไปแล้ว ระบุว่าเวอร์ชัน 1.8.3 มีมาตั้งแต่อย่างน้อยเดือนมิถุนายน 2569 และเผยแพร่สคริปต์ฉบับปรับปรุงที่ครอบคลุมเวอร์ชันนี้ พร้อมเตือนว่า “ด้วยจำนวนเซิร์ฟเวอร์ที่เคยติด Ebury ระหว่างปี 2552-2566 (400,000 เครื่อง) น่าจะยังมี Tor relay ที่ถูกเจาะอยู่อีก”

คำถามหลักที่ยังเปิดอยู่คือผู้ดูแลอีก 58 รายถูกเจาะอย่างไร จาก relay ที่อยู่บนเครือข่าย FranTech Solutions (เจ้าของแบรนด์ BuyVM) 101 ตัว มีถึง 71 ตัวที่เปลี่ยนมาใช้นโยบายของผู้โจมตี เทียบกับเพียง 13 จาก 9,054 ตัวบนผู้ให้บริการอื่น และนักวิจัย kaba นับได้ว่าเซิร์ฟเวอร์ที่ถูกเจาะนอกกลุ่ม Quetzalcoatl 26 จาก 27 เครื่องอยู่บน FranTech/BuyVM จึงตั้งคำถามว่าผู้โจมตีอาจเจาะในระดับผู้ให้บริการโฮสติ้งหรือไม่ นอกจากนี้ relay 40 ตัวของผู้ดูแล 21 รายเปลี่ยนนโยบายภายใน 5 นาทีครึ่งเมื่อ 1 ตุลาคม ซึ่งบทวิเคราะห์ตีความว่าผู้โจมตีรายเดียวถือสิทธิ์เข้าถึงทั้ง 40 ตัวอยู่แล้ว นาย Léveillé เดาว่ารหัสผ่านน่าจะถูกขโมยจากการล็อกอินผ่านโฮสต์ที่ติด Ebury อยู่ก่อน โดยผู้ให้บริการโฮสติ้งที่ถูกเจาะเป็นอีกความเป็นไปได้ ESET เคยพบผู้ให้บริการที่เซิร์ฟเวอร์จัดการติด Ebury แล้วลามไปถึง VPS ของลูกค้า ผู้อยู่เบื้องหลังยังไม่ถูกระบุ และยังไม่รู้ว่าโฮสต์ที่ได้รับผลกระทบติด Ebury กี่เครื่อง ผู้ดูแลรายอื่นรายงานสัญญาณที่ต่างออกไป เช่น daemon CRON ปลอมที่ตั้งชื่อเป็นตัวพิมพ์ใหญ่ และกฎ NAT ที่เปลี่ยนเส้นทางพอร์ต 22 ซึ่งเซิร์ฟเวอร์ของนาย Zimmer ไม่มี จึงยังไม่ชัดว่าทุกกรณีเป็นผู้โจมตีรายเดียวกัน

ผลกระทบ

ผู้ที่เสี่ยงคือผู้ดูแลระบบหรือนักพัฒนาที่ใช้ SSH ผ่าน Tor (เช่น ผ่าน torsocks หรือ ProxyCommand) ไปยังเซิร์ฟเวอร์บนอินเทอร์เน็ตทั่วไป และยืนยันตัวตนด้วยรหัสผ่านในช่วงตั้งแต่ 2 ถึง 5 ตุลาคม 2569 หากเพิกเฉยต่อคำเตือน host key รหัสผ่านอาจถูกขโมย และเซิร์ฟเวอร์ปลายทางอาจถูกฝัง Ebury ไปแล้ว ผู้ที่ส่งอีเมลแบบไม่เข้ารหัสผ่าน Tor ในช่วงเดียวกันก็อาจถูกดักอ่านเนื้อหาเช่นกัน ส่วนการเชื่อมต่อไปยัง onion service ไม่ผ่าน exit node จึงไม่ได้รับผลกระทบจากการโจมตีนี้

ในภาพใหญ่ เหตุนี้ตอกย้ำว่า exit node คือจุดที่เห็นทราฟฟิกแบบไม่เข้ารหัสระหว่าง Tor กับปลายทาง การยึดได้ถึง 10% ของ exit relay ทำให้ผู้ใช้จำนวนมากมีโอกาสผ่านเครื่องของผู้โจมตีโดยไม่รู้ตัว และการที่ผู้โจมตีแปลง relay ธรรมดาเป็น exit เองยังแสดงว่าการคัดกรอง relay ต้องดูการเปลี่ยนบทบาทด้วย

คำแนะนำ

• ปิดการยืนยันตัวตน SSH ด้วยรหัสผ่าน (PasswordAuthentication no) และใช้กุญแจหรือใบรับรอง SSH แทน
• ห้ามเพิกเฉยต่อคำเตือน “REMOTE HOST IDENTIFICATION HAS CHANGED” ตรวจ fingerprint ผ่านช่องทางอื่นก่อนเชื่อมต่อทุกครั้ง และใช้ StrictHostKeyChecking yes หรือกระจาย known_hosts ล่วงหน้า
• ผู้ที่ล็อกอิน SSH ผ่าน Tor ด้วยรหัสผ่านช่วง 2–5 ตุลาคม 2569 ให้เปลี่ยนรหัสผ่าน และตรวจเซิร์ฟเวอร์ปลายทางหา Ebury เช่น ตรวจความสมบูรณ์ของไบนารี OpenSSH และไลบรารีที่เกี่ยวข้องกับแพ็กเกจของระบบ
• ตรวจล็อก SSH หาการล็อกอินซ้อนจากที่อยู่ IP ของ Tor exit node และคำสั่งตรวจ sudo ตามด้วยการถอดรหัส Base64
• หากจำเป็นต้องเข้าถึงเซิร์ฟเวอร์ผ่าน Tor ให้ใช้ onion service ซึ่งไม่ผ่าน exit node
• ผู้ดูแล Tor relay ควรดูแลเหมือนระบบ production ที่ถูกเล็งสูง แพตช์สม่ำเสมอ ตรวจความเปลี่ยนแปลงของ torrc และแยกการเข้าถึงสำหรับผู้ดูแล
• อัปเดต 23 ต.ค. 2569: ช่วงเวลาเสี่ยงขยายเป็น 1 ถึงบ่ายวันที่ 5 ตุลาคม 2569 ผู้ที่ยอมรับ host key ที่ไม่คุ้นหรือเปลี่ยนไประหว่างใช้ SSH ผ่าน Tor ให้ถือว่ารหัสผ่านถูกขโมย และตรวจ known_hosts หา key ของเซิร์ฟเวอร์ดักกลางตามตาราง IoCs ด้านล่าง
• ผู้ดูแล relay บน Linux ตรวจ Relay Search ว่ามีธง Exit หรือ exit policy ที่ไม่ได้ตั้งเองหรือไม่ และตรวจ torrc รวมไฟล์ที่ include ทั้งหมด หาบรรทัด ExitRelay, ExitPolicy, ContactInfo, MyFamily หรือ Nickname ที่ถูกแก้ พร้อมตรวจกฎ NAT บนพอร์ต 22, process หรือการเชื่อมต่อขาออกที่ไม่รู้จัก, ผู้ใช้ใหม่, authorized_keys, cron job, systemd unit และไบนารี tor ที่ไม่ผ่านการตรวจแพ็กเกจ แต่ระวังว่าโฮสต์ที่ตรวจแล้วสะอาดก็ยังติด Ebury เวอร์ชันนี้ได้
• ตรวจ Ebury จากระบบ rescue หรือดิสก์อิมเมจแบบ offline หากทำได้ ถ้าต้องตรวจบนเครื่องที่รันอยู่ให้ล็อกอินด้วยกุญแจเท่านั้น ห้ามพิมพ์รหัสผ่านลงเซิร์ฟเวอร์ที่สงสัย เพราะ Ebury จะดักไปทันที และเริ่ม shell ด้วย H=1 I=1 LD_PRELOAD=":" LD_DEBUG=":" bash เพื่อเลี่ยง userland rootkit ก่อนรันสคริปต์ตรวจฉบับปรับปรุงของนาย Léveillé
• ถ้าพบ ให้ปิด relay เก็บดิสก์และล็อกไว้ก่อนล้าง ติดตั้งระบบใหม่แทนการทำความสะอาด (เพราะ Ebury รอดการรีบูต) สร้าง relay identity ใหม่และถือว่ากุญแจเดิมถูกขโมย หมุนเวียนข้อมูลรับรองทุกตัวบนโฮสต์ แล้วแจ้ง bad-relays@lists.torproject.org
• ไม่ใช้รหัสผ่านเดียวกันซ้ำระหว่าง SSH, sudo และ passphrase ของแบ็กอัป และเก็บกุญแจหลักแบบ offline ไว้นอกเซิร์ฟเวอร์ที่ออนไลน์จริง ๆ

Indicators of Compromise (IoCs)

ข้อมูลจาก post-mortem ของนาย Zimmer และการสังเกตของนักวิจัย kaba · IP ถูก defang แล้ว ([.]) ต้องแปลงกลับก่อนใช้งาน · hash ของไฟล์ Ebury ต่างกันในทุกเซิร์ฟเวอร์ จึงไม่มี hash ให้ใช้ตรวจ

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

• Tor Exit Nodes Compromised to Intercept SSH — kaba.cx
• Hackers Compromise 333 Tor Exit Nodes to Steal SSH Credentials and Deploy Ebury Malware — GBHackers
• tor-relays mailing list — Tor Project
• Updated Ebury detection script (covers 1.8.3) — GitHub
• Attackers Hijacked Over 300 Tor Exit Relays to Intercept SSH Connections — The Hacker News