Archive for January, 2014

0176 | Proof: ‘True Internet’ transparent proxy exists

Tuesday, January 21st, 2014 Posted in Misc | No Comments »

  • จำลอง client ขึ้นมาก่อน จากรูปนี้จะเห็นว่า client ทำการเชื่อมต่อไปที่ “หมายเลข IP” ตรงๆ ไม่มีการ lookup dns ออกมาแน่นอน
    upic.me

  • log บน DNS server ของโดเมนที่ระบุใน Host header ของ TCP มีการ resolve มาจาก resolver ที่เป็น IP ของทรู

    21-Jan-2014 06:32:35.340 client 119.46.241.2#10021: query: izspoofdetector.thredir.upic.me IN A -ED (122.155.3.119)

  • ลำดับของ header ของ request ครั้งต่อๆ มา (เข้าใจว่า cache hit) ถูกแก้ไขโดย transparent proxy
    upic.me

ครั้งแรก
> HTTP/1.1 200 OK\r\n
> Server: nginx/1.4.1\r\n
> Date: Mon, 20 Jan 2014 23:32:36 GMT\r\n
> Content-Type: text/css\r\n
> Content-Length: 16313\r\n
> Last-Modified: Mon, 01 Oct 2012 17:01:27 GMT\r\n
> ETag: “5069cc67-3fb9″\r\n
> Expires: Mon, 27 Jan 2014 23:32:36 GMT\r\n
> Cache-Control: max-age=604800\r\n
> Accept-Ranges: bytes\r\n
> Connection: keep-alive\r\n

ครั้งที่ 2
> HTTP/1.1 200 OK\r\n
> Cache-Control: max-age=604800\r\n
> Content-Length: 16313\r\n
> Content-Type: text/css\r\n
> ETag: “5069cc67-3fb9″\r\n
> Server: nginx/1.4.1\r\n
> Expires: Mon, 27 Jan 2014 23:32:37 GMT\r\n
> Last-Modified: Mon, 01 Oct 2012 17:01:27 GMT\r\n
> Connection: keep-alive\r\n
> Date: Mon, 20 Jan 2014 23:44:20 GMT\r\n

  • เทียบกับการ request จาก server ที่อยู่ต่างประเทศ จะเห็นว่า header ไม่มีการเปลี่ยนแปลงลำดับใดๆ ทั้งสิ้นไม่ว่าจะ request กี่ครั้ง
    upic.me

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

Wednesday, January 15th, 2014 Posted in IP Network | No Comments »

อันนี้เขียนลง 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 ต่อไปเรื่อยๆ

upic.me

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

upic.me

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

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

upic.me

จากกระบวนการนี้ ขั้นตอนส่วนที่มีปัญหาคือการที่ 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: , ,