Clear
Lead Graphic Papers

Web Application Security รายสะดวก #1

ผู้เขียน: ไพชยนต์ วิมุกตะนันทน์
วันที่เผยแพร่: 4 พ.ค. 2555
ปรับปรุงล่าสุดวันที่: 4 พ.ค. 2555

Share on Facebook Share on Twitter Share on Google+

ขอออกตัวก่อนว่าบทความนี้อาจจะมีหลายๆ ส่วนที่อ้างอิงมาจากบทความเดิม ( http://www.thaicert.or.th/papers/technical/2012/pa2012te001.html ) ซึ่งไม่ได้มีรายละเอียดในเชิงลึกมากนัก ส่วนมากจะเป็นการแนะนำให้ทำอะไรบางอย่าง แต่ไม่ได้อธิบายว่าทำอย่างไรหรือทำไปเพื่ออะไร ดังนั้นบทความนี้จะนำข้อแนะนำเหล่านั้นมาขยายความให้ชัดเจนขึ้น เพื่อให้ผู้ที่อาจไม่มีประสบการณ์มากนักสามารถนำไปประยุกต์ใช้ หรือแม้แต่ทำตามตัวอย่างไปเลยได้อย่างง่ายดาย

ถ้าพูดถึง Web application ท่านผู้อ่านก็คงทราบดีอยู่แล้วว่าประกอบด้วยของ 2 อย่าง นั่นคือ Web server และ Application อย่างแรกก็ได้แก่ Apache และ IIS ที่เรารู้จักกันดี เดี๋ยวนี้อาจจะมีตัวอื่นเข้ามาปนบ้าง เช่น lighttpd หรือ nginx หรือพวกที่กลายพันธุ์ไปอย่าง Apache Tomcat แต่ก็อยู่ในพื้นฐานเดียวกันทั้งสิ้น ส่วนอย่างหลังก็ได้แก่ PHP, JSP และ ASP เป็นหลัก และก็มีตัวอื่นๆ เช่น Ruby, C#, python รวมถึงของเก่าที่ยังเชื่อถือได้เสมออย่าง perl ก็ยังมีการใช้งานอยู่ไม่น้อย

แต่ไม่ว่าส่วน Application นี้จะเป็นอะไรก็ตาม ส่วนแรกคือ Web server ก็ยังทำงานเหมือนเดิมเสมอไม่มีการเปลี่ยนแปลง นั่นคือทำหน้าที่เป็นสื่อกลางระหว่างผู้ใช้งานกับ Application เบื้องหลัง และในกรณีที่มีการโจมตี Web application เกิดขึ้น Web server นี้เอง ก็จะเป็นพยานปากสำคัญ ที่มองเห็นเหตุการณ์การโจมตีโดยตลอด และเก็บบันทึกรายละเอียดเอาไว้ใน Log file ดังที่หลายๆ ท่านอาจจะได้เรียนรู้ความสำคัญของ Log file จากประสบการณ์จริงกันมาแล้ว เมื่อ Web application ของท่าน ตกเป็นเป้าหมายของเหล่าผู้ไม่ประสงค์ดี

แต่การที่รู้ว่าถูกโจมตีหลังจากถูกโจมตีสำเร็จแล้วก็ไม่น่าจะดีเท่าไหร่ ถึงแม้การที่ได้ทราบรายละเอียดการโจมตีอย่างละเอียดจาก Log จะช่วยให้ท่านสามารถแก้ไขช่องโหว่ได้อย่างถูกต้องครบถ้วนมากขึ้น สิ่งที่ดีกว่านั้นก็คือ ท่านสามารถรู้ได้ก่อนที่การโจมตีจริงๆ จะเกิดขึ้น หรือแม้แต่ก่อนที่การโจมตีจะสำเร็จ ซึ่งทั้งหมดนี้ อาจจะทำได้โดยการพิจารณาจาก Log ของ Web server นั่นเอง

ถ้า Web application ของท่านไม่ได้มีช่องโหว่ (Vulnerability) ชนิดที่รู้กันอยู่แล้วจนมีผู้สร้างเครื่องมือโจมตี (Exploit) แจกจ่ายกันอย่างแพร่หลาย คือท่านเป็นผู้ดูแลระบบที่มีความระมัดระวังตามสมควรอยู่แล้วนั่นเอง สิ่งแรกที่ผู้ไม่ประสงค์ดีมักจะทำ ก่อนที่จะโจมตีท่านก็คือ การตรวจสอบระบบของท่านเพื่อรวบรวมข้อมูล (Information gathering) การกระทำนี้บางครั้งอาจเรียกว่าการ Probe หรือ Scan หรือบางครั้งอาจเรียกว่า Footprinting สำหรับวิธีการก็มีได้หลากหลาย ส่วนมากมักจะใช้เครื่องมืออัตโนมัติเช่น Nikto, W3af หรือ Skipfish ซึ่งเป็นเครื่องมือที่มีการแจกจ่ายอย่างไม่คิดมูลค่าบน Internet

Pp2012te0008-1.png

ภาพที่ 1 แสดง Log ของ Apache ที่ถูก Scan ด้วยโปรแกรม Skipfish

ตัวอย่างที่แสดงให้เห็นจากโปรแกรม Skipfish ข้างต้นนั้น อาจจะเห็นได้ค่อนข้างชัดเจนเนื่องจากเป็นการ Scan โดยไม่ได้มีการปรับแต่งค่าการทำงานใดๆ ของโปรแกรม Skipfish เลย และทำการทดลองในเครื่องแม่ข่ายที่ไม่มีการใช้งานจริง แต่ในกรณีที่เป็นเครื่องแม่ข่ายหลักที่มีผู้เข้ามาใช้บริการเป็นจำนวนมาก และผู้ไม่ประสงค์ดี ที่ต้องการหาช่องโหว่ใน Web application ของท่าน มีการปรับแต่งค่าให้โปรแกรมทำงานในลักษณะที่ทำให้สังเกตเห็นได้ยากขึ้น เช่น เปลี่ยนค่า User Agent ให้เป็นของ Web browser จริง (ในตัวอย่างเป็น Mozilla/5.0 SF/2.05b ซึ่งเป็นของ Skipfish โดยเฉพาะ) และปรับการทำงานให้ช้าลง แทนที่จะ Scan ด้วยความอัตราความเร็วหลายสิบครั้งใน 1 วินาทีตามตัวอย่าง เพื่อให้ผลของการ Scan ดูกลมกลืนไปกับการใช้งานจริงบนเครื่องแม่ข่าย ดังนั้นหากท่านกลับไปดู Log ของ Web server ของท่านในวันนี้ ท่านอาจไม่สามารถสังเกตเห็นความผิดปกติอะไรเลย ทั้งๆ ที่อาจจะมีผู้ไม่ประสงค์ดี ทำการ Scan ไปแล้วหลายต่อหลายครั้งก็ตาม

แต่การตรวจสอบในรูปแบบนี้ ไม่ว่าจะตั้งค่าโปรแกรมอย่างไรก็ตาม สิ่งที่ต้องเกิดขึ้นอย่างแน่นอนก็คือ 404 error ซึ่งจะเกิดขึ้นเมื่อโปรแกรมที่ตรวจหาช่องโหว่เหล่านี้ พยายามเดาชื่อไฟล์ที่อาจมีอยู่ในระบบ โดยไฟล์เหล่านี้อาจเป็นช่องโหว่ ที่สามารถนำมาใช้เป็นประโยชน์ในการเจาะเข้าสู่ระบบจริงๆ ได้ ชื่อไฟล์ที่โปรแกรมเหล่านี้นำมาลองเดา อาจจะมาจากฐานข้อมูลที่มีการรวบรวมเอาไว้ล่วงหน้า ว่าเป็นไฟล์ที่มักจะเป็นช่องโหว่ หรือมีข้อมูลที่น่าสนใจ หรืออาจเป็นการเดาในลักษณะ Brute-force ก็ได้ ผลลัพธ์ของการเดาชื่อไฟล์ มักจะผิดมากกว่าถูก และทุกครั้งที่ผิด Web server ก็จะบันทึกเอาไว้ใน Log ว่าเป็น 404 error ซึ่งแปลว่า file not found นั่นเอง

Log ของการ Scan ของโปรแกรมเหล่านี้อาจจะดูว่ามีปริมาณมาก (ในตัวอย่างมีประมาณ 10000 บรรทัด เป็น 404 ประมาณ 1200 บรรทัด) แต่เมื่อเทียบกับ Log ของ Web server ที่มีจำนวนผู้เข้าชมจำนวนมากๆ แล้ว ก็อาจเรียกได้ว่าเป็นแค่ส่วนเล็กๆ ในจำนวน Log มหาศาล ดังนั้นจะตรวจหาความผิดปกตินี้ได้อย่างไร ท่านผู้อ่านที่คุ้นเคยกับเครื่องมือใน Unix อาจจะนึกถึงเครื่องมือ grep และ wc ซึ่งต้องอาศัยความรู้ในการเขียน grep pattern ที่เหมาะสมและต้อง login เข้าไปใน Web server หรืออุปกรณ์ที่เก็บ Log ทุกครั้งที่ต้องการตรวจสอบ นอกจากไม่สะดวกแล้ว หากพบว่ามีสิ่งผิดปกติอยู่ใน Log ท่านก็ยังต้องดำเนินการเองอีกด้วย เช่น Block IP address ต้องสงสัยที่ Firewall หรือเขียน ACL บน Apache เอง ซึ่งอาจจะล่าช้าไม่ทันการ หรือเกิดความผิดพลาดได้โดยง่าย

เพื่อช่วยให้การตรวจสอบความผิดปกติใน Log เป็นไปโดยอัตโนมัติ และสามารถทำการรับมือ (Mitigate) กับการโจมตีได้โดยอัตโนมัติด้วย สิ่งที่จำเป็นต้องมีก็คือโปรแกรมประเภท Log monitoring หรือบางท่านอาจจะจัดว่าเป็น Host-based IPS ประเภทหนึ่ง ซึ่งโปรแกรมเหล่านี้จะทำการตรวจสอบ Log ที่กำหนดเป็นระยะๆ เมื่อพบว่ามีรายการ Log ที่ผิดปกติตามเงื่อนไขที่เรากำหนด มันก็จะดำเนินการตามคำสั่งที่เรากำหนดไว้ล่วงหน้า เช่นท่านอาจกำหนดให้โปรแกรมดังกล่าว คอยตรวจสอบสถานะ 404 บน Log ของ Apache โดยระบุเงื่อนไขว่า หากมีรายการ 404 จาก IP เดียวกันตั้งแต่ 20 ครั้งใน 1 วินาที ให้สั่ง Block IP address นั้นด้วย iptables ทันที

ตัวอย่างของโปรแกรมประเภทนี้ตัวหนึ่ง ได้แก่ Fail2Ban ( http://www.fail2ban.org ) ซึ่งถูกออกแบบมาให้ป้องกันการโจมตีประเภท Brute-force โดยอาศัย iptables เป็นตัว block การโจมตี ซึ่งในกรณีนี้ เราจะกำหนดเงื่อนไขให้ Fail2ban ตรวจสอบ Apache log ที่มีผลลัพธ์เป็น 404 error (file not found) ที่มีความถี่มากกว่า 20 ครั้งต่อ 1 วินาที โดยใช้รูปแบบของ configuration ดังต่อไปนี้

# Fail2Ban configuration file
# Modified from https://rem.co/en/article/fail2ban-phpmyadmin-script/ - PHPMyAdmin protection rules

[Definition]

failregex = <HOST> -.*"(GET|POST) .*" 404 .*

ignoreregex =

สำหรับผู้ใช้งาน Debian GNU/Linux และ Ubuntu ให้บันทึกไฟล์นี้เป็นชื่อ /etc/fail2ban/filter.d/apache-404.conf ส่วนผู้ใช้งาน Distribution อื่นให้ตรวจสอบตำแหน่งที่เก็บไฟล์ filter ของ Fail2ban จากคู่มือของ Distribution นั้นๆ

ขั้นต่อไป ให้ตรวจสอบว่า Apache ที่ท่านใช้งานอยู่ เก็บ Log (access log) ไว้ที่ใด ( ในที่นี้ สมมุติให้เป็น /etc/apache2/access.log ) เมื่อทราบแล้ว ให้เพิ่มรายการนี้ในไฟล์ /etc/fail2ban/jail.conf และเช่นเดียวกับ สำหรับผู้ใช้งาน Linux Distribution อื่นที่ไม่ใช่ Debian หรือ Ubuntu ให้ตรวจสอบตำแหน่งที่เก็บไฟล์ jail.conf ของ Fail2ban จากคู่มือของ Distribution นั้นๆ

[apache-404]

enabled = true
port = http,https
filter = apache-404
logpath = /var/log/apache2/access.log
maxretry = 20
findtime = 1
bantime = 300


bantime คือช่วงเวลาที่จะให้ Fail2ban block การเข้าถึงจาก IP ที่ถูกตรวจพบว่าพยายามโจมตีระบบตามเงื่อนไขที่กำหนด โดยมีหน่วยเป็นวินาที หากกำหนดเป็นค่าติดลบ จะหมายถึงให้ Fail2ban ทำการ block IP นั้นๆ ตลอดไป และอย่าลืมว่า ตัวเลข 20 ครั้งต่อ 1 วินาทีเป็นการสมมุติขึ้น เพื่อให้เห็นได้ชัดเจนในการทดลอง ในชีวิตจริงอาจมีค่าที่ต่ำกว่านี้มาก เนื่องจากผู้ไม่ประสงค์ดีต้องการหลบหลีกการตรวจจับดังที่กล่าวไว้ข้างต้น

เมื่อกำหนดค่าให้ Fail2ban ตามตัวอย่างแล้ว ผู้เขียนก็จะมาลอง Scan ระบบด้วย Skipfish ดูอีกครั้ง ก็พบว่า Fail2ban สามารถตรวจพบการโจมตีตามเงื่อนไข คือมี 404 error จาก IP เดียวกัน 20 ครั้งต่อวินาที และทำการ block ได้สำเร็จ

Pp2012te0008-2.png

ภาพที่ 2 แสดงการทำงานของ Fail2ban จาก Log ของโปรแกรม



และเมื่อมาดูในฝั่ง Skipfish ก็จะพบว่า การ Scan ถูก block ภายในเวลาประมาณ 3.5 วินาทีเท่านั้น

Pp2012te0008-3.png

ภาพที่ 3 แสดงการทำงานของ Skipfish เมื่อทำการ Scan เครื่องแม่ข่ายที่ป้องกันไว้แล้ว

จากการทดลอง จะเห็นได้ว่า Fail2ban สามารถป้องกันการทำ Information gathering ด้วยวิธี URL scanning หรือ URL bruteforcing ได้ผลในระดับหนึ่ง แต่อย่างไรก็ตาม หากผู้ไม่ประสงค์ดีใช้รูปแบบการ Scan หรือ Probe วิธีอื่นๆ หรือในกรณีที่ของระบบที่มีช่องโหว่ที่รู้จักกันดีอยู่แล้ว ผู้ไม่ประสงค์ดีก็อาจจะทำการโจมตีได้โดย Fail2ban ไม่สามารถตรวจจับและป้องกันได้ นอกจากนี้ ระบบตรวจจับการโจมตีทุกชนิด ย่อมมีโอกาสที่จะเกิดความผิดพลาดในลักษณะที่เรียกว่า False positive ได้ นั่นคือเป็นการใช้งานปกติที่ถูกเข้าใจผิดว่าเป็นการโจมตี และถูก block อย่างไม่ควรจะเป็น สำหรับตัวอย่างที่แสดงนี้อาจเกิดได้จากผู้พัฒนาเว็บไซต์ของท่านเอง ที่อาจสร้าง html page ที่มี dead link จำนวนมากโดยไม่รู้ตัว ทำให้ผู้ที่เข้ามาชมเว็บไซต์นั้นตามปกติถูก block เนื่องจากเกิด 404 error ขึ้นมากเกินค่าที่กำหนดโดยไม่ได้ตั้งใจ

และถึงแม้เมื่อท่านติดตั้ง Fail2ban ไปแล้วและได้ผลเป็นที่น่าพอใจ ท่านก็ควรที่จะพิจารณาการป้องกัน Web application ของท่านด้วยมาตรการอื่นๆ ด้วย ทั้งนี้อาศัยแนวคิดเรื่อง Defense-in-depth หรือ Layered defense ซึ่งผู้เขียนจะนำวิธีการป้องกันแบบอื่นๆ มาเสนอให้ท่านได้ทราบในโอกาสต่อไป

Clear