*บทความนี้เป็นการใช้งาน NGINX Plus และ NGINX App Protect บน Proen Cloud มี Add-ons สำเร็จรูปพร้อมใช้แบบ Subscription รายเดือนครับ
ในตอนที่ 1 - 4 เราได้ติดตั้ง NGINX Plus, NGINX App Protect รวมถึงการ Configure transparent mode เพื่อให้พร้อมใช้งานร่วมกับ Backend Applications
ตอนที่ 1 - ติดตั้ง NGINX Plus และ NGINX App Protect
https://bit.ly/napproen
ตอนที่ 2 - ปรับแต่ง NGINX App Protect - transparent mode
https://bit.ly/napproen-ep2
ตอนที่ 3 - ปรับแต่ง NGINX App Protect - Data Guard
https://bit.ly/napproen-ep3
ตอนที่ 4 - ปรับแต่ง NGINX App Protect - HTTP Compliance
https://bit.ly/napproen-ep4
วันนี้จะเป็นตอนพิเศษ เพราะเพื่อนสนิทของ NGINX โดน CVE-2021-41773
ที่เรียกว่าเพื่อนสนิท เพราะตอน NGINX ถูกสร้างขึ้นเมื่อปี 2004 ก็เพื่อแก้ปัญหา C10K ให้เพื่อนสนิทเช่นเดียวกันเลยครับ
ตอนปี 2004 web server ยังมีข้อจำกัดไม่สามารถรองรับ 10000 concurrences ได้, NGINX ถูกสร้างขึ้นมาเพื่อแก้ปัญหานี้ครับ โดยเป็นทั้ง Light weight และ High performance web server
เรามาดู CVE กันก่อนครับ จะเกิดกับ Apache Version 2.4.49
ฉะนั้นการโจมตี ขั้นแรกเราจะเช็ค Apache Version ก่อนครับ โดยพยายามเรียกให้เกิด Error ในตัวอย่างจะเรียกไป path ที่ไม่มีอยู่จริง
จะเห็นว่า Apache จะพ่น Error ออกมาครับ โดยตอนท้ายยังบอกชื่อ และเวอร์ชั่นมาด้วย ซึ่งเป็นเวอร์ชั่นที่โดน CVE-2021-41773 พอดี
ฉะนั้นการปิดบังเลขเวอร์ชั่นก็สามารถช่วยป้องกันเราได้ระดับหนึ่งครับ โดย NGINX สามารถทำได้ดังนี้
จะลองเรียกไปที่ NGINX บ้าง เพื่อตั้งใจให้เกิด Error เช่นกัน
จะเห็นเฉพาะชื่อ NGINX แต่ไม่เห็นชื่อเวอร์ชั่นครับ ที่เป็นเช่นนี้เพราะใน Proen Cloud มีการปรับแต่งไว้แล้วให้ NGINX แสดงเฉพาะชื่อเท่านั้น, เหตุที่แสดงเฉพาะชื่อ เพื่อให้ยังคงง่ายต่อการ troubleshoots ครับ เช่นเมื่อเกิดปัญหาขึ้น แล้วเห็น Error สามารถรู้ได้ว่าเป็น Error จากส่วน NGINX
แต่ถ้าเราต้องการ Security ที่เข้มข้นกว่า ก็จะปิดชื่อด้วยโดยแก้ directive ให้เป็น server_token "";
จะไม่มีชื่อ และ เวอร์ชั่นปรากฎเลยครับ ฉะนั้นการจะโจมตีก็ยากขึ้นมาอีกหน่อย
เรากลับมาที่ตัว CVE ก่อนครับ การโจมตีทำได้โดยเรียกไปยัง path ที่ไม่ควรจะถูกเรียก(เช่น /etc/passwd) และจะต้องมีการ configure Apache ให้ "Require all granted" ด้วย ถึงจะเข้าเงื่อนไขการโจมตี
ตอนนี้องค์ประกอบเราครบแล้ว คือเวอร์ชั่นตรง และ Configure Require all granted ไว้, ทดสอบโจมตีด้วยเทคนิค Directory traversal เรียกไปยัง /etc/passwd ครับ
จบแล้วครับ ทีนี้เราจะป้องกันได้อย่างไร
ในมุม Apache ให้อัพเดทจาก 2.4.49 เป็น 2.4.51 ย้ำว่า .51 นะครับ ถ้า .50 ไม่พอ
ในมุม NGINX ที่จะอยากช่วยเพื่อน ก็เอาตัวเองมาขวาง แล้วจะช่วยได้ไหม ลองท่า NGINX ธรรมดาก่อน(ไม่มี WAF ไม่มี NGINX App Protect) โดยจะเรียกไปยัง NGINX ก่อนเรียกไป Apache อีกที
ผลคือช่วยได้ครับ เพราะการโจมตีที่ Apache ยอมให้ผ่าน, NGINX ไม่ยอมให้ผ่าน เพราะมีการเรียก %2e%2e/ หรือ ../ หลายๆ ครั้งนั่นเอง
ลองปรับเป็นใช้ ../../../../ ตรงๆ บ้าง หรือก็คือการขึ้นไป 4 ชั้น แล้วลงมาที่ /etc/passwd
พบว่ายังผ่านไม่ได้
ท่าต่อมา ถ้าผู้โจมตีรู้ทัน ว่าแบบนี้ผ่าน NGINX ไม่ได้ เลยปรับการโจมตีใหม่ครับ โดยใช้ ../ ครั้งเดียวแบบนี้
Note: ใน NGINX มีการติดตั้ง App Protect ไว้แล้ว แต่ปิดการใช้งานไว้ครับ เท่ากับยังไม่มีการใช้งาน App Protect
พบว่าท่านี้ สามารถผ่าน NGINX ที่ไม่มี App Protect เข้าไปถึงเพื่อนเราหลังบ้านได้
สุดท้าย เป็นท่าเดิมจาก Ep1. ก็คือติดตั้งและใช้งาน NGINX App Protect ในที่นี้เรากด Add-ons ไว้แล้วก็พร้อมใช้งานครับ จากตัวอย่างด้านบนผมทำการ off ไว้ ก็เพียง on กลับมาแบบนี้
'vi /etc/nginx/app-protect.conf'
จากนั้น
'nginx -s reload'
ทดสอบเรียกแบบเดิมอีกครั้ง
จะถูก Rejected และมี Support ID "40481345153723365903"
นำ Support ID มาตรวจสอบสาเหตุการ Rejected
พบว่าเป็นการพยายามหลบเลี่ยง และใช้เทคนิค Directory Traversal ครับ
วันนี้เราทดสอบกับช่องโหว่ที่ประกาศออกมาแล้วครับ สามารถอัพเดท Patch ได้(แม้จะต้องอัพเดทสองครั้ง แต่ก็ยังถือว่ามี Patch)
แต่ถ้าเป็นช่องโหว่ที่ยังไม่ประกาศ หรือเราไม่สามารถติดตามข่าว 365 วัน(คูณด้วยจำนวน App หรือจำนวน Product ที่ใช้ซึ่งแต่ละตัวจะมีช่องโหว่ออกมาต่างกัน) การมี WAF จะช่วยเราได้มากครับ เช่นเคสนี้ WAF ที่เราติดตั้งไว้ตั้งแต่เดือนก่อน สามารถป้องกันช่องโหว่ ที่เพิ่งออกมาได้ เพราะเข้าเงื่อนไขการ Evasion
Series: เสริมความปลอดภัยให้ Backend Applications ด้วย NGINX App Protect
เสริมความปลอดภัยให้ Backend Applications ด้วย NGINX App Protect - ตอนที่ 1 - ติดตั้ง NGINX Plus และ NGINX App Protect
https://bit.ly/napproen
เสริมความปลอดภัยให้ Backend Applications ด้วย NGINX App Protect - ตอนที่ 2 - ปรับแต่ง NGINX App Protect - transparent mode
https://bit.ly/napproen-ep2
เสริมความปลอดภัยให้ Backend Applications ด้วย NGINX App Protect - ตอนที่ 3 - ปรับแต่ง NGINX App Protect - Data Guard
https://bit.ly/napproen-ep3
เสริมความปลอดภัยให้ Backend Applications ด้วย NGINX App Protect - ตอนที่ 4 - ปรับแต่ง NGINX App Protect - HTTP Compliance
https://bit.ly/napproen-ep4
เสริมความปลอดภัยให้ Backend Applications ด้วย NGINX App Protect - ตอนที่ 5 - ปรับแต่ง NGINX App Protect - Rescue Apache HTTP Server from CVE-2021-41773
https://bit.ly/napproen-ep5
สัปดาห์หน้า พบกับ Protection Mechanism ถัดไป ติดตามได้ที่
FB Page: นั่งเล่น NGINX
https://web.facebook.com/NungLenNGINX
FB Group: ร่วมพูดคุยและแลกเปลี่ยนความรู้ไปกับเรา NGINX Super User TH
https://web.facebook.com/groups/394098015436072
เริ่มต้นใช้งานได้ที่ https://app.manage.proen.cloud/
มีทีม Support ให้ครับ
อีกหนึ่งช่องทาง nginx@mfec.co.th
Top comments (0)