แฮกเกอร์โจมตีเซิร์ฟเวอร์ NGINX เพื่อเปลี่ยนเส้นทางการจราจรของผู้ใช้

ผู้ไม่หวังดีกำลังโจมตีเซิร์ฟเวอร์ NGINX ในแคมเปญที่มุ่งเป้าไปที่การยึดการจราจรของผู้ใช้และเปลี่ยนเส้นทางผ่านโครงสร้างพื้นฐานแบ็คเอนด์ของผู้โจมตี NGINX เป็นซอฟต์แวร์โอเพนซอร์สสำหรับการจัดการการจราจรบนเว็บที่ใช้ในการให้บริการเว็บ การปรับสมดุลโหลด การแคช และ Reverse Proxy การโจมตีนี้เกิดขึ้นโดยการแก้ไขไฟล์คอนฟิกูเรชันของ NGINX และ Baota hosting management panels ซึ่งส่งผลกระทบต่อเว็บไซต์ที่มีโดเมนระดับบนสุดของเอเชีย (.in, .id, .pe, .bd, .th) รวมถึงเว็บไซต์ของรัฐบาล (.gov) และสถาบันการศึกษา (.edu) การโจมตีนี้ตรวจจับได้ยากเนื่องจากไม่ได้ใช้ช่องโหว่ของ NGINX แต่เป็นการซ่อนคำสั่งที่เป็นอันตรายในไฟล์คอนฟิกูเรชันที่มักไม่ได้รับการตรวจสอบอย่างละเอียด

Severity: สูง

System Impact:

• เซิร์ฟเวอร์ NGINX
• แผงควบคุม Baota hosting management panels
• เว็บไซต์ที่มีโดเมนระดับบนสุดของเอเชีย (.in, .id, .pe, .bd, .th)
• เว็บไซต์ของรัฐบาล (.gov)
• เว็บไซต์ของสถาบันการศึกษา (.edu)

Technical Attack Steps:

1. ผู้โจมตีแก้ไขไฟล์คอนฟิกูเรชัน NGINX ที่มีอยู่เดิม
2. แทรกบล็อก ‘location’ ที่เป็นอันตรายเพื่อดักจับคำขอที่เข้ามาบนเส้นทาง URL ที่ผู้โจมตีเลือก
3. เขียนคำขอใหม่เพื่อให้มี URL ต้นฉบับทั้งหมด
4. ส่งต่อการจราจรผ่านคำสั่ง ‘proxy_pass’ ไปยังโดเมนที่ผู้โจมตีควบคุม
5. เก็บรักษาเฮดเดอร์คำขอ เช่น ‘Host’, ‘X-Real-IP’, ‘User-Agent’ และ ‘Referer’ เพื่อให้การจราจรดูเหมือนถูกต้องตามกฎหมาย
6. ใช้ชุดเครื่องมือแบบหลายขั้นตอนที่เป็นสคริปต์ 5 ขั้นตอน:
7. Stage 1 – zx.sh: เป็นสคริปต์ควบคุมเริ่มต้น ทำหน้าที่ดาวน์โหลดและรันขั้นตอนที่เหลือ มีกลไกสำรองสำหรับการส่งคำขอ HTTP ดิบผ่าน TCP หากไม่สามารถใช้ curl หรือ wget ได้
8. Stage 2 – bt.sh: กำหนดเป้าหมายไฟล์คอนฟิกูเรชัน NGINX ที่จัดการโดยแผงควบคุม Baota เลือกเทมเพลตการแทรกโดยอิงตามค่า server_name เขียนทับคอนฟิกูเรชันอย่างปลอดภัย และโหลด NGINX ซ้ำเพื่อหลีกเลี่ยงการหยุดทำงานของบริการ
9. Stage 3 – 4zdh.sh: แจกแจงตำแหน่งคอนฟิกูเรชัน NGINX ทั่วไป เช่น sites-enabled, conf.d และ sites-available ใช้เครื่องมือวิเคราะห์ เช่น csplit และ awk เพื่อป้องกันคอนฟิกูเรชันเสียหาย ตรวจจับการแทรกก่อนหน้าผ่าน hashing และไฟล์ mapping ทั่วโลก และตรวจสอบการเปลี่ยนแปลงโดยใช้ nginx -t ก่อนโหลดซ้ำ
10. Stage 4 – zdh.sh: ใช้แนวทางการกำหนดเป้าหมายที่แคบลง โดยมุ่งเน้นไปที่ /etc/nginx/sites-enabled และโดเมน .in และ .id เป็นหลัก ทำตามกระบวนการทดสอบและโหลดซ้ำคอนฟิกูเรชันเดียวกัน โดยใช้ pkill เป็นกลไกสำรอง
11. Stage 5 – ok.sh: สแกนคอนฟิกูเรชัน NGINX ที่ถูกบุกรุกเพื่อสร้างแผนที่ของโดเมนที่ถูกยึด เทมเพลตการแทรก และเป้าหมาย proxy จากนั้นส่งข้อมูลที่รวบรวมได้ไปยังเซิร์ฟเวอร์ C2 ที่ 158.94.210[.]227

Recommendations:

Short Term:

• ตรวจสอบไฟล์คอนฟิกูเรชัน NGINX และ Baota panel เพื่อหารายการ ‘location’ หรือ ‘proxy_pass’ ที่น่าสงสัย
• ตรวจสอบบันทึกการเข้าถึง (access logs) และบันทึกข้อผิดพลาด (error logs) ของ NGINX อย่างละเอียด เพื่อหารูปแบบการเชื่อมต่อที่ผิดปกติหรือการเปลี่ยนแปลงที่ไม่ได้รับอนุญาต
• ใช้เครื่องมือ File Integrity Monitoring (FIM) เพื่อตรวจจับการเปลี่ยนแปลงใดๆ ในไฟล์คอนฟิกูเรชันของ NGINX ทันที

Long Term:

• ใช้หลักการสิทธิ์ขั้นต่ำ (Least Privilege) สำหรับบัญชีผู้ดูแลระบบที่จัดการ NGINX และ Baota panel
• นำระบบควบคุมเวอร์ชัน (version control system) มาใช้สำหรับไฟล์คอนฟิกูเรชัน NGINX เพื่อติดตามและย้อนกลับการเปลี่ยนแปลงที่ไม่ต้องการ
• ติดตั้ง Multi-Factor Authentication (MFA) สำหรับการเข้าถึงระบบการจัดการเซิร์ฟเวอร์และบัญชีที่เกี่ยวข้อง
• จัดให้มีการฝึกอบรมด้านความปลอดภัยสำหรับบุคลากร เพื่อให้เข้าใจถึงวิธีการโจมตีที่ซ่อนเร้นและการตรวจจับการแก้ไขไฟล์คอนฟิกูเรชัน
• ติดตั้งและกำหนดค่าระบบตรวจจับการบุกรุก (Intrusion Detection System – IDS) หรือระบบป้องกันการบุกรุก (Intrusion Prevention System – IPS) เพื่อตรวจจับกิจกรรมที่น่าสงสัยบนเครือข่ายและเซิร์ฟเวอร์
• ดำเนินการตรวจสอบความปลอดภัยและทดสอบการเจาะระบบ (penetration testing) อย่างสม่ำเสมอ เพื่อระบุช่องโหว่และจุดอ่อนที่อาจถูกโจมตี
• อัปเดตซอฟต์แวร์ NGINX และ Baota panel รวมถึงระบบปฏิบัติการที่เกี่ยวข้องให้เป็นเวอร์ชันล่าสุดเสมอ เพื่อปิดช่องโหว่ที่ทราบ

Source: https://www.bleepingcomputer.com/news/security/hackers-compromise-nginx-servers-to-redirect-user-traffic/