Rejetto HFS CVE-2026-61500 ถูกใช้โจมตีแล้ว: สุ่มคุกกี้เดาได้จนปลอม admin และรันโค้ด

ผู้ดูแล Rejetto HFS 3.x ต้องอัปเดตเป็น 3.2.1 หรือใหม่กว่าและตรวจย้อนหลังครับ CVE-2026-61500 เป็นช่องโหว่ critical ที่ผู้โจมตีไม่ต้องล็อกอินสามารถเก็บ login responses จำนวนหนึ่ง กู้สถานะตัวสร้างเลขสุ่ม หา session-cookie signing key ปลอม cookie ผู้ดูแล แล้วไปถึง remote code execution ผ่านความสามารถ server_code ได้ VulnCheck ระบุว่าเริ่มเห็น exploitation วันที่ 1 ตุลาคม 2026

ผมเทียบ release 3.2.1 ของ Rejetto, CVE record, telemetry จาก VulnCheck และรายงานของ SecurityWeek เวอร์ชัน 3.0.0 ถึงก่อน 3.2.1 อยู่ในช่วงได้รับผลกระทบตาม record และมีหลักฐานโจมตีจริงแล้ว จึงไม่ควรรอรอบ patch ปกติ

สรุป 30 วินาที

• CVE-2026-61500 มี CVSS 4.0 9.3 และ CVSS 3.1 9.8; network, ไม่ต้องมีสิทธิ์, ไม่ต้องให้ผู้ใช้คลิก และกระทบ confidentiality/integrity/availability สูง
• จุดอ่อนคือใช้ PRNG ที่ไม่เหมาะกับงาน cryptographic ทั้งเผย output บางส่วนใน login response และใช้ state เดียวกันสร้าง signing key ของ session
• ผู้โจมตีเก็บ response เพียงพอเพื่อ reconstruct state แล้ว forge admin session จากนั้นใช้ feature ฝั่งผู้ดูแลไปสู่ code execution
• แก้ใน HFS 3.2.1; การซ่อนพอร์ต, เปลี่ยนรหัสผ่าน หรือ restart อย่างเดียวไม่ซ่อม cryptographic design
• VulnCheck ระบุ exploitation ตั้งแต่ 1 ต.ค. ระบบที่เปิดอินเทอร์เน็ตและเคยรันรุ่นได้รับผลกระทบต้องถือเป็น incident candidate ไม่ใช่เพียงงาน patch
• หลังอัปเดตต้อง revoke sessions/keys, ตรวจ config และ persistence, เก็บหลักฐานก่อน rebuild เมื่อพบสัญญาณผิดปกติ

ทำไมเกี่ยวกับคุณ

HFS มักถูกใช้แชร์ไฟล์แบบง่ายและอาจถูกเปิดจากเครื่องที่ทีมไม่คิดว่าเป็น “server สำคัญ” เช่น workstation, lab หรือเครื่องส่งไฟล์ชั่วคราว จุดนี้ทำให้ inventory พลาดง่าย เปรียบเหมือนประตูหลังโกดังที่ติดกลอนเล็กเพราะคิดว่าเปิดแค่บางวัน แต่ถ้าต่ออินเทอร์เน็ต มันเป็นประตูจริงตลอดเวลา

เมื่อ session admin ถูกปลอม ผู้โจมตีไม่ต้องเดารหัสผ่านและ log อาจดูเหมือนผู้ดูแลปกติ ทีมจึงต้องดู behavior หลัง login เช่น config change, server_code, process ลูก, file write, outbound connection และ account/session ใหม่ ไม่ใช่ค้น failed login อย่างเดียว

ทำงานยังไง: ตรายางที่เผยจังหวะเครื่อง

ลายเซ็น session มีหน้าที่พิสูจน์ว่าคุกกี้ออกโดย server หาก signing key สุ่มแข็งแรงและเก็บลับ ผู้โจมตีแก้ role หรือสร้าง cookie ใหม่ไม่ได้ แต่กรณีนี้ระบบใช้ตัวสร้างเลขสุ่มที่ state เดาได้และยังปล่อย output ให้คนภายนอกเห็น

ลองนึกถึงเครื่องประทับตราที่เลื่อนเฟืองตามจังหวะตายตัว ทุกครั้งที่หน้า login ตอบ มันเหมือนเผยรอยเฟืองอีกหนึ่งจุด เมื่อเก็บตัวอย่างพอ คนโจมตีคำนวณตำแหน่งเฟืองและทำนายตราถัดไปได้ จากนั้นสร้าง signing key ที่ server ยอมรับ จุดสำคัญคือ “สุ่มดูเหมือนสุ่ม” ไม่พอสำหรับ cryptography ต้องใช้ CSPRNG และแยก domain/key material อย่างเหมาะสม

หลัง forge session ผู้โจมตีเข้าฟังก์ชัน admin และ feature ที่อนุญาต code/config expression กลายเป็นสะพานสู่ RCE ช่องโหว่จึงไม่ใช่เพียง account impersonation แต่เปลี่ยนเป็นการควบคุม process ภายใต้สิทธิ์ที่ HFS รันอยู่ ถ้า service ใช้ admin/root ผลกระทบกว้างขึ้นอีก

เงินและผลกระทบ

การหยุด file server อาจกระทบงานส่งไฟล์ แต่การปล่อยระบบที่ถูก exploit ทำให้ข้อมูลทุกไฟล์, credential ใน process, network share และเครื่องข้างเคียงเสี่ยง ตัดสินใจตาม exposure: instance อินเทอร์เน็ตควร isolate ทันทีแล้วเปิดช่องทางสำรองที่ตรวจสิทธิ์ได้ ไม่ควรรอ maintenance window ปกติ

ต้นทุน incident อยู่ที่ forensic, credential rotation, partner notification และความน่าเชื่อถือ ไม่ใช่ค่าอัปเดต package เก็บ timeline ว่าเริ่มใช้รุ่นใด เปิดอินเทอร์เน็ตเมื่อไร และ patch เมื่อไร เพื่อกำหนดช่วง log review อย่างมีหลักฐาน

สิ่งที่ยังไม่ชัดและแหล่งข่าวพูดไม่ตรงกัน

CVE record ระบุช่วง affected และกลไก ส่วน VulnCheck ระบุ exploitation observed แต่ข้อมูลสาธารณะยังไม่บอกจำนวนเหยื่อ, actor หรือ campaign scope ทั้งหมด SecurityWeek สรุป score 9.3 ตาม CVSS v4 ขณะที่บางฐานแสดง 9.8 ตาม CVSS v3.1 ตัวเลขต่างเพราะระบบคะแนนคนละรุ่น ไม่ใช่ข้อขัดแย้งว่า severity ต่ำลง

ยังไม่ควรสรุปว่าไม่พบ IOC เท่ากับไม่ถูกโจมตี เพราะ session forgery อาจใช้ request ที่หน้าตาเหมือน admin และ retention log ของเครื่องชั่วคราวมักสั้น หากหลักฐานไม่พอแต่ exposure สูง ให้ตัดสินจาก risk และ rebuild จาก known-good มากกว่าประกาศว่าปลอดภัย

ควรทำอะไร

1. ทำ inventory HFS ทุก instance จาก package/process/listening port และ asset discovery ไม่พึ่ง CMDB อย่างเดียว
2. ถ้าเป็น 3.0.0–3.2.0 ให้ isolate จากอินเทอร์เน็ต เก็บ memory/disk/log ตาม incident plan แล้วอัปเดต 3.2.1 หรือใหม่กว่าจาก release ทางการ
3. ยืนยัน hash/provenance ของ artifact และรัน service ด้วย account สิทธิ์ต่ำ ไม่ให้เข้าถึง secret/network share เกินงาน
4. revoke active sessions, rotate credential/token ที่ process เข้าถึงได้ และอย่าใช้การเปลี่ยนรหัสผ่านแทน patch
5. ตรวจ config diff โดยเฉพาะ code hooks, startup/persistence, scheduled task, child process, file write และ outbound connection ในช่วง exposure
6. ทำ external validation ว่า endpoint เก่าไม่เปิด และ negative test ว่า cookie ปลอมไม่ได้สิทธิ์ admin โดยไม่ใช้ PoC กับ production
7. หากพบ compromise ให้ rebuild known-good และขยาย hunt ไป credential/host ที่เชื่อมโยง

การหา instance ต้องมองกว้างกว่าชื่อ service ครับ ตรวจ process tree, listening socket, package inventory, startup folder, scheduled task, container image และ reverse-proxy route เพราะ HFS อาจถูกรันจากโฟลเดอร์ดาวน์โหลดหรือเปลี่ยนชื่อ executable เครื่องที่ “ปิดจากอินเทอร์เน็ตแล้ว” ยังต้องตรวจว่ามี port-forward, tunnel, VPN หรือ load balancer เก่าชี้อยู่หรือไม่ เก็บผลสำรวจพร้อมเวลาและแหล่งข้อมูลเพื่อรู้ว่าช่องว่างของ inventory อยู่ตรงไหน

ด้าน detection ให้สร้าง timeline จาก web access log, application log, process creation, file modification และ egress แล้วผูกด้วย host clock ที่ตรวจ drift แล้ว มองหา session ที่ได้สิทธิ์ admin โดยไม่มี login flow ปกติ การแก้ configuration/code hook, process ลูกจาก HFS, ไฟล์ executable/script ใหม่ และการเชื่อมต่อออกที่ไม่ตรง baseline แต่อย่าฟันธงจาก IOC เดียว เพราะ attacker เปลี่ยน infrastructure ได้และ request ที่ forge สำเร็จอาจไม่สร้าง failed login

การเก็บหลักฐานควรมาก่อน uninstall หรือ reboot เมื่อ incident policy อนุญาต จด version, command line, working directory, hash ของ binary/config, active connections และ memory capture ตามความเหมาะสม จากนั้น clone หลักฐานไปวิเคราะห์ในสภาพแวดล้อมแยก ห้ามนำ exploit สาธารณะไปยิง production เพื่อ “เช็กว่ารอดไหม” เพราะการทดสอบอาจเปลี่ยน state และทำลายหลักฐาน ใช้ version/provenance และ negative test หลัง patch เป็นเกณฑ์ยืนยันแทน

สำหรับองค์กรที่อัปเดตทันแต่เคยเปิดรุ่นเสี่ยง ให้ถือช่วง exposure เป็นคำถามแยกจากสถานะวันนี้: patched ไม่ได้แปลว่าอดีตสะอาด กำหนด lookback ตั้งแต่เริ่มใช้ 3.x หรืออย่างน้อยตั้งแต่ exposure ล่าสุดตาม log retention หากหลักฐานขาดและ asset เข้าถึงข้อมูลสำคัญ ให้เลือก rebuild/rotate มากกว่าพึ่งความเงียบของ log แล้วเพิ่ม control ระยะยาว เช่น allowlist ผู้ใช้, reverse proxy authentication, network segmentation และ service account ที่อ่านได้เฉพาะโฟลเดอร์จำเป็น

Recap

• patch เป็น HFS 3.2.1+ จากต้นทางที่ตรวจได้
• isolate ระบบ exposed และเก็บหลักฐานก่อนล้าง
• revoke session/rotate secret หลัง patch
• ตรวจ config, process, persistence, file และ egress ย้อนหลัง
• ลด service account privilege และ segment network
• อย่าตีความ CVSS ต่างเวอร์ชันว่าแหล่งข่าวขัดกัน

เรื่องนี้เตือนชัดว่า PRNG สำหรับงานทั่วไปห้ามถูกยืมมาเป็นกุญแจครับ เมื่อรอยสุ่มถูกเปิดให้เก็บและ state เดาได้ กลอน session ทั้งบานก็กลายเป็นตรายางที่ทำซ้ำได้