0175 | โจมตี transparent proxy ด้วย dns cache poisoning

อันนี้เขียนลง blognone ครับ ก๊อปกลับมาลง blog ตัวเองอีกที

ระบบอินเทอร์เน็ตมีพื้นฐานอยู่บนบริการหลายๆ อย่างทำงานร่วมกัน ในเงื่อนไขหลักที่ถือว่า “ข้อมูลที่อีกฝ่ายตอบมาเป็นความจริง” เป็นหลัก โดยบริการที่สำคัญมาก (และเป็นช่องโหว่ในการโจมตีมากเป็นอันดับต้นๆ) ในอินเทอร์เน็ตมีอยู่สองอย่างเท่านั้นครับ คือ routing และ DNS คือถ้าสามารถโจมตีสองอย่างในขนาดใหญ่มากๆ ได้ ก็อาจทำให้อินเทอร์เน็ตทั้งโลก หรือส่วนหนึ่งส่วนใดมีปัญหาได้เลยครับ

Routing นั้นเป็นส่วนของการแลกเปลี่ยนข้อมูลเส้นทาง และใช้หาเส้นทางในการรับ-ส่งข้อมูลกันระหว่างคู่ของหมายเลข IP (ต้นทาง – ปลายทาง) และ DNS เป็นส่วนที่ทำให้หมายเลข IP มี “ชื่อ” ที่สามารถออกเสียง และพูดถึงได้โดยง่าย รวมถึงหน้าที่ในการระบุบริการของโดเมนอย่างอื่นอีก ซึ่งจะขอไม่พูดถึงเพื่อลดความซับซ้อน โดยการใช้งานหลัก (ที่เป็น traffic ส่วนใหญ่ของการใช้งาน DNS) คือการทำหน้าที่แปลงว่า “ชื่อ” ใดๆ มีหมายเลข IP ที่เป็นที่อยู่จริงๆ ที่ไหน

ในส่วนของ DNS ก็ยังมีการแยกชนิดออกไปอีกเป็น 3 ส่วนคือ Root/TLD server, authoritive server และ resolver โดยการทำงานคร่าวๆ คือ เครื่องผู้ใช้งานจะถาม resolver ว่า “ชื่อโดเมน” นี้มีหมายเลข IP ใด จากนั้น resolver จะไปหาจากข้อมูลที่เคยถูกถามแล้วตัวเองจำไว้ (cache) ถ้าไม่เจอก็จะถามไปยัง Root/TLD Server เพื่อหา authoritive server ต่อไปเรื่อยๆ

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

นั่นหมายความว่า ในกรณีดังกล่าว transparent proxy จะต้องทำการ “ถาม” resolver เพื่อหาว่าชื่อโดเมนปลายทางที่ต้องการเชื่อมต่อนั้นคือหมายเลข IP อะไรอีกครั้ง

ในระบบของ DNS เนื่องจากตัวมันเองทำงานด้วยโปรโตคอล UDP ซึ่งไม่มีการยืนยันตัวตน และมีการปลอมแปลงข้อมูลต้นทางได้ง่าย ทำให้มีช่องโหว่หนึ่งชื่อ DNS Cache Poisoning คือการปลอมข้อมูลที่ resolver ได้รับจาก authoritive server เพื่อให้ข้อมูลหลังจากนั้นเป็นหมายเลข IP ที่ไม่ถูกต้อง ทำให้เมื่อมี transparent proxy เข้ามาในระบบจึงเกิดเป็นช่องโหว่ที่รุนแรงกว่ากันมาก เมื่อเทียบกับการที่ client ยังสามารถเปลี่ยน resolver ไปใช้ของบริการภายนอกที่น่าเชื่อถือ (เช่น Google DNS หรือ OpenDNS)

จากกระบวนการนี้ ขั้นตอนส่วนที่มีปัญหาคือการที่ resolver ที่ transparent proxy เรียกใช้งานถูกปลอมแปลงข้อมูลได้ และไปรับข้อมูลจากเครื่องเซิร์ฟเวอร์ปลอม (spoof source) แทนที่ authoritive sever ของโดเมนดังกล่าว ขั้นตอนที่ 9 ที่เป็นสีแดงที่ควรจะเป็นจึงถูก resolver มองข้ามไป แล้วนำข้อมูลปลอมตอบกลับให้แก่ transparent proxy ในการนี้ผู้ไม่ประสงค์ดีจำเป็นต้องทราบว่า resolver ตัวดังกล่าวคือหมายเลข IP อะไรเพื่อที่จะโจมตีให้ได้

จากนั้นเมื่อ transparent proxy ทำการดึงข้อมูลจาก server ปลอมดังกล่าวแล้ว ตัว transparent proxy ก็จะทำการ cache ข้อมูลดังกล่าวไว้ด้วย เพื่อที่จะส่งให้แก่ผู้ใช้คนอื่นๆ ที่มีการร้องขอข้อมูลไฟล์เดียวกัน ทำให้ผู้ใช้หลายๆ รายได้รับข้อมูลปลอมไปพร้อมๆ กันโดยไม่เกี่ยวกับการตั้งค่า resolver ที่ client ใดๆ ทั้งสิ้นครับ

ในการนี้ ผู้ไม่ประสงค์ดีสามารถโจมตี resolver ในระยะเวลาสั้นมากๆ เพื่อไม่ให้เป็นที่ผิดสังเกตจนสามารถตามหาเครื่องที่เก็บ malware เจอได้ แล้วให้ transparent proxy ผู้ถูกหลอกนี้เป็นผู้ปล่อย malware แทน ทำให้ตรวจสอบได้ยากขึ้นอีกมากครับ

Tags: dns, proxy, security

0166 | DNS Resolver ของทรูถูกวางยา

ความจริงเคยเกิดเหตุการณ์อย่างนี้หลายครั้งแล้ว แต่เหมือนว่าไม่มีการปรับปรุงระบบอะไรที่สามารถป้องกันปัญหานี้ได้เลย

วันที่ 5 กันยายนที่ผ่านมา มีรายงานจากผู้ใช้อินเทอร์เน็ตทรูจำนวนมาก ว่าเข้าเว็บไซต์ปกติอยู่ดีๆ ถูกเด้งไปเว็บไซต์ “parking.ps”

ซึ่งส่วนตัวก็เจอบ้างเหมือนกัน อ่านเว็บโน่นนี่นั่นอยู่ดีๆ เด้งไปเว็บนี้หน้าตาเฉย พยายาม view source เว็บที่ดูแล้วก็ไม่มีอะไรผิดปกติ จนปะเข้ากับความเห็นนี้ใน pantip ครับ

ก็เลยนึกขึ้นได้ว่าก่อนหน้านี้ก็เคยมีเหตุการณ์ประมาณนี้บ้างแล้วเหมือนกันคือ (ถ้าจำไม่ผิด) google.co.th โดน poison ไปเว็บโฆษณาอะไรซักอย่าง ที่มีปัญหาเฉพาะคนที่ใช้ DNS resolver ของทรู…

การโจมตีรูปแบบนี้เรียกว่า DNS Cache Poisoning ครับ หลักการคือการอาศัยช่องโหว่ของการทำงานของระบบ DNS ปกติ ที่จะมี DNS resolver เป็นคนที่ “ช่วย” client ในการหาว่า domain ที่ client ต้องการทราบข้อมูล IP (หรือ dns record อื่นๆ) ซึ่งมีขั้นตอนการทำงานประมาณนี้ (ตัวอย่างนะครับ)

• client ถาม resolver ว่า xxx.com มี IP อะไร
• resolver ตรวจสอบใน cache ว่ามีข้อมูลอยู่แล้วรึเปล่า ถ้ามีก็ตอบไปเลย
• ถ้าไม่มี resolver ก็จะไล่ถามมาตั้งแต่ root server (ด้วย root hint record ภายใน resolver เอง) > gtld server (ที่ได้รับจาก root server) > auth server ของโดเมน

ไล่เป็น Hierachy ได้ประมาณนี้

ซึ่งการทำงานนี้ เมื่อ resolver ได้ผลลัพท์จาก authoritive server (สีฟ้าๆ) มาแล้ว มันก็จะ cache ผลลัพท์นั้นๆ ไว้ที่ตัวเองจนกว่าจะหมดอายุตามที่ auth server ตอบมา เพื่อความเร็วในการตอบ client ครั้งต่อๆ ไปจะได้ไม่ต้องไปถามซ้ำ

ด้วยการที่ DNS ทำงานบน protocol UDP ทำให้เราสามารถปลอมแปลง packet ได้ง่าย ผู้ไม่ประสงค์ดีก็จะสามารถส่งข้อมูลปลอมๆ ตอบไปหา resolver แทนได้ถ้าสามารถคาดเดาข้อมูลการ request DNS ของ resolver ได้ (ซึ่งไม่ยากเลย…) และเมื่อปลอมได้แล้ว resolver ก็จะเก็บข้อมูลปลอมๆ นั้นไว้กับตัวเอง จนกว่าจะหมดอายุที่ระบุไว้ตามข้อมูลปลอมๆ นั้น

พอ client ได้ ip ผิด มันก็เลยติดต่อไปหา server ผิดตัว ทำให้ได้รับข้อมูลผิดกลับไป เป็นเหตุให้เกิดเหตุการณ์ประมาณนี้ขึ้นมานั่นเองครับ

วิธีป้องกัน… จริงๆ มันมีมาตรฐาน DNSSEC ที่ช่วยป้องกันการปลอมแปลงข้อมูลพวกนี้อยู่น่ะนะครับ แต่… แทบจะไม่ค่อยมีใครใช้กันซักเท่าไหร่ เพราะตั้งค่ายาก+ซับซ้อนพอควร
บวกกับจริงๆ แล้ว resolver ที่ใช้ software ใหม่ๆ จะมีระบบป้องกัน DNS poisoning ด้วยหลายๆ เทคนิคประกอบกันทำให้การโจมตีแบบนี้ยากขึ้นมาก (แต่ก็ยังเป็นไปได้) ล่ะนะ

ปล. เขียนตอนง่วงๆ อาจอ่านไม่รู้เรื่องนะครับ (ฮา)

Tags: dns, security