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

Friday, September 6th, 2013 Posted in IP Network | 1 Comment »

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

วันที่ 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: ,

0139 | DDoS : DNS Amplification Attack

Thursday, December 20th, 2012 Posted in IP Network | 2 Comments »

บทความนี้เป็นส่วนหนึ่งของเนื้อหาเกี่ยวกับ DDoS (Distributed Denial of Service) หรือการพยายามโจมตีเพื่อให้เครื่องแม่ข่ายล่มครับ
ซึ่งจะทยอยเขียนตามอารมณ์และโอกาส และถ้าโดนยิงบ่อยๆ ก็จะเขียนบ่อยขึ้น (เอ๊ะยังไง?)

สำหรับ DNS Amplification Attack (หรืออาจเรียกว่า DNS Reflection Attack) นี้เป็นวิธีการโจมตีแบบใช้ตัวตายตัวแทนครับ
จริงๆ แล้วเรื่องนี้ค่อนข้างเก่าพอสมควร เพราะเป็นวิธีการโจมตีเครือข่ายที่ทำง่าย และป้องกันได้ยากมากวิธีนึงครับ โดยมีแผนผังการโจมตีดังนี้


(ภาพประกอบจาก CloudFlare blog)

สาเหตุที่เรียกว่า DNS Amplification หรือ DNS Reflection Attack นั้นก็มาจากลักษณะของการโจมตีครับ ด้วยตัวพื้นฐานของระบบ DNS นั้นจะใช้ protocol UDP ซึ่งเป็นการรับส่งข้อมูลแบบ stateless คือสามารถส่งข้อมูลออกไปได้ตั้งแต่ packet แรกที่ส่ง ดังนั้นจึงเกิดการปลอมแปลงได้ง่ายมากครับ โดยผู้โจมตีจะทำการปลอมแปลงเป็น IP ของเหยื่อ แล้วระดมส่งคำร้องขอทำการ resolve DNS ไปยัง DNS Server ที่ต่างๆ

และเมื่อ DNS Server ได้รับคำร้องแล้ว ก็จะตอบกลับไปหา IP ของเหยื่อ (ตามที่ผู้โจมตีปลอมมา) ทำให้เหยื่อได้รับ packet DNS ปริมาณมหาศาลตามลักษณะของรูปด้านบนครับ และที่บอกว่าเป็น Amplification Attack เพราะรูปแบบของคำร้อง DNS เหล่านี้ส่วนมากจะเป็น packet สั้นๆ แต่ขนาดของ packet ที่ DNS server จะต้องตอบกลับไปมีขนาดใหญ่มาก ทำให้ bandwidth ของเครื่องที่ถูกโจมตีเต็มได้ครับ

สำหรับวิธีป้องกันอาจแบ่งออกเป็นสองส่วนคือ ส่วนของ bandwidth และส่วนของการทำ stateful inspection ครับ คือหาเครื่อง firewall หรือ server ที่รองรับ bandwidth ปริมาณมากกว่าการโจมตีให้ได้ก่อน แล้วจึงทำการ drop ข้อมูลการถาม DNS แบบ stateful ครับ โดยตั้งให้ว่าถ้า firewall ไม่เจอคำร้องสำหรับ DNS request นั้น ให้ทำการ drop reply ที่ได้รับนั้นทิ้งไปประมาณนี้ครับ

iptables -A FORWARD -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT
iptables -A FORWARD -j DROP

และสำหรับเจ้าของ server ถ้าเป็นไปได้ “อย่า” เปิด recursion resolve เพื่อไม่ให้เครื่อง server ของตัวเองกลายเป็นเครื่องที่ไปโจมตีชาวบ้านครับ

Tags: ,