หมายเหตุ: ต่อเนื่องจากข่าวที่แล้ว (ระบบอินเทอร์เน็ตทรูถูกโจมตี ฝังมัลแวร์ดักข้อมูลผู้ใช้งาน) ทางทีมงานทรูได้ประสานงานมาว่าทีมเครือข่ายได้รับทราบปัญหาแล้ว กำลังหาแนวทางในการแก้ไขเป็นการถาวรอยู่ครับ
ระบบอินเทอร์เน็ตมีพื้นฐานอยู่บนบริการหลายๆ อย่างทำงานร่วมกัน ในเงื่อนไขหลักที่ถือว่า "ข้อมูลที่อีกฝ่ายตอบมาเป็นความจริง" เป็นหลัก โดยบริการที่สำคัญมาก (และเป็นช่องโหว่ในการโจมตีมากเป็นอันดับต้นๆ) ในอินเทอร์เน็ตมีอยู่สองอย่างเท่านั้นครับ คือ routing และ DNS คือถ้าสามารถโจมตีสองอย่างในขนาดใหญ่มากๆ ได้ ก็อาจทำให้อินเทอร์เน็ตทั้งโลกหรือส่วนหนึ่งส่วนใดมีปัญหาได้เลยครับ
Routing
Routing นั้นเป็นส่วนของการแลกเปลี่ยนข้อมูลเส้นทาง และใช้หาเส้นทางในการรับ-ส่งข้อมูลกันระหว่างคู่ของหมายเลข IP (ต้นทาง-ปลายทาง) และ DNS เป็นส่วนที่ทำให้หมายเลข IP มี "ชื่อ" ที่สามารถออกเสียง และพูดถึงได้โดยง่าย รวมถึงหน้าที่ในการระบุบริการของโดเมนอย่างอื่นอีก ซึ่งจะขอไม่พูดถึงเพื่อลดความซับซ้อน โดยการใช้งานหลัก (ที่เป็น traffic ส่วนใหญ่ของการใช้งาน DNS) คือการทำหน้าที่แปลงว่า "ชื่อ" ใดๆ มีหมายเลข IP ที่เป็นที่อยู่จริงๆ ที่ไหน
DNS
ในส่วนของ DNS มีการแยกชนิดออกไปอีกเป็น 3 ส่วนคือ
การทำงานคร่าวๆ คือ เครื่องผู้ใช้งานจะถาม resolver ว่า "ชื่อโดเมน" นี้มีหมายเลข IP ใด จากนั้น resolver จะไปหาจากข้อมูลที่เคยถูกถามแล้วตัวเองจำไว้ (cache) ถ้าไม่เจอก็จะถามไปยัง Root/TLD Server เพื่อหา authoritative server ต่อไปเรื่อยๆ (ในรูปเขียน authoritative ผิดนะครับ)
เมื่อ client ได้รับหมายเลข IP จาก resolver แล้ว client ก็จะดำเนินการเชื่อมต่อไปยังเครื่องที่หมายเลข IP ดังกล่าวอีกครั้ง เพื่อที่จะติดต่อรับส่งข้อมูลใดๆ กัน แต่หากการเชื่อมต่อใดๆ ถูกดักไว้ด้วย transparent proxy ตัว client จะมองว่า transparent proxy คือ server ตัวหนึ่ง และในขณะเดียวกัน ตัว transparent proxy นี้ก็จะกลายเป็น client ที่ทำหน้าที่เชื่อมต่อกับ server ตัวจริงอีกครั้งด้วย
นั่นหมายความว่า ในกรณีดังกล่าว transparent proxy จะต้องทำการ "ถาม" resolver เพื่อหาว่าชื่อโดเมนปลายทางที่ต้องการเชื่อมต่อนั้นคือหมายเลข IP อะไรอีกครั้ง
DNS Cache Poisoning
ในระบบของ DNS เนื่องจากตัวมันเองทำงานด้วยโปรโตคอล UDP ซึ่งไม่มีการยืนยันตัวตน และมีการปลอมแปลงข้อมูลต้นทางได้ง่าย ทำให้มีช่องโหว่หนึ่งชื่อ DNS Cache Poisoning คือการปลอมข้อมูลที่ resolver ได้รับจาก authoritative server เพื่อให้ข้อมูลหลังจากนั้นเป็นหมายเลข IP ที่ไม่ถูกต้อง ทำให้เมื่อมี transparent proxy เข้ามาในระบบจึงเกิดเป็นช่องโหว่ที่รุนแรงกว่ากันมาก เมื่อเทียบกับการที่ client ยังสามารถเปลี่ยน resolver ไปใช้ของบริการภายนอกที่น่าเชื่อถือ (เช่น Google DNS หรือ OpenDNS)
จากกระบวนการนี้ ขั้นตอนส่วนที่มีปัญหาคือการที่ resolver ที่ transparent proxy เรียกใช้งานถูกปลอมแปลงข้อมูลได้ และไปรับข้อมูลจากเครื่องเซิร์ฟเวอร์ปลอม (spoof source) แทนที่ authoritative sever ของโดเมนดังกล่าว ขั้นตอนที่ 9 ที่เป็นสีแดงที่ควรจะเป็นจึงถูก resolver มองข้ามไป แล้วนำข้อมูลปลอมตอบกลับให้แก่ transparent proxy ในการนี้ผู้ไม่ประสงค์ดีจำเป็นต้องทราบว่า resolver ตัวดังกล่าวคือหมายเลข IP อะไรเพื่อที่จะโจมตีให้ได้
จากนั้นเมื่อ transparent proxy ทำการดึงข้อมูลจาก server ปลอมดังกล่าวแล้ว ตัว transparent proxy ก็จะทำการ cache ข้อมูลดังกล่าวไว้ด้วย เพื่อที่จะส่งให้แก่ผู้ใช้คนอื่นๆ ที่มีการร้องขอข้อมูลไฟล์เดียวกัน ทำให้ผู้ใช้หลายๆ รายได้รับข้อมูลปลอมไปพร้อมๆ กันโดยไม่เกี่ยวกับการตั้งค่า resolver ที่ client ใดๆ ทั้งสิ้นครับ
ในการนี้ ผู้ไม่ประสงค์ดีสามารถโจมตี resolver ในระยะเวลาสั้นมากๆ เพื่อไม่ให้เป็นที่ผิดสังเกตจนสามารถตามหาเครื่องที่เก็บ malware เจอได้ แล้วให้ transparent proxy ผู้ถูกหลอกนี้เป็นผู้ปล่อย malware แทน ทำให้ตรวจสอบได้ยากขึ้นอีกมากครับ
Comments
authoritive -> authoritative ?
ตรงท้ายๆ มีตกตัว r ไปครับ sever -> server
อคติทำให้คนรับเหตุผลด้านเดียว
ผมสงสัยว่าถ้าใช้ DNSCrypt transparent proxy จะมีผลด้วยรึเปล่า
Opensource - Hackintosh - Graphic Design - Scriptkiddie - Xenlism Project
ตราบใดที่ยัง connect tcp port 80 ก็มีผลทั้งหมดครับ
เดี๋ยวนะครับ
มีปัญหาที่ DNS cache หรือ มีปัญหาที่ http transparent proxy หรือ มีทั้งสองอย่าง
ถ้าตอนนี้ผมเข้าใจไม่ผิด คือมีปัญหาทั้งสองอย่าง
Opensource - Hackintosh - Graphic Design - Scriptkiddie - Xenlism Project
transparent proxy ทำงาน(น่าจะ)ถูกแล้ว(มั้ง)ครับ แต่ได้ข้อมูลป้อนเข้าผิด ผลลัพท์ที่ได้ก็เลยผิด
DNScrypt เข้ารหัสการร้องขอครับ ส่วนใหญ่จะเปน 443 2053 พวกนี้เป็น SSL หมด
ถ้า เฉพาะ DNS เสียใช้ DNSCrypt น่าจะแก้ปัญหาได้ เพราะการร้องขอ DNS น่าจะ connect ไปยัง ip โดยตรง
Opensource - Hackintosh - Graphic Design - Scriptkiddie - Xenlism Project
ถ้าหมายถึงจะใช้ dnscrypt ที่ฝั่งเครื่องเราเอง เพื่อหลบ transpanrent proxy แบบนั้นเป็นไปไม่ได้ครับ เนื่องจาก tproxy มันไม่ได้ใช้วิธีหลอก ip เครื่องเรา แต่มันดักอยู่ใน router เลยครับ (isp router จริงนะ ไม่ใช่ modem ตามบ้าน)
ขอบคุณมากครับ
มึนอยู่กับเจ๊ในพันทิป พยายามเข้าใจเจ๊แกแต่ก็ไม่เข้าใจ
もういい
อันที่จริงไม่ได้ตั้งใจจะเขียนเรื่องนี้เลย :) ต้องขอบคุณเจ๊คนนั้นนะครับ
แหม่.. ก็เจ๋แกทำงานอยู่ CAT นิครับ #ฮา
เจ๊แก World Class น่ะคราบ ทำเป็นเล่นไป ^^
ผมอ่านเห็นเจ๊แกคริฟครั้งแรกก็ตอนที่ กระทู้ปิดตึก cat เนี่ยแหละ
นั้นคงจะเป็นอีกเหตุผลหนึ่งเมื่อใช้ Google Public DNS อินเทอร์เน็ตเลยอึดเป็นเต่าเลย แต่พอใช้ DNS ของทรูเท่านั้น เร็วปึ๊ดขึ้นมาทันใด เพราะ Resolve ช้านี่เอง
ยิ่งอยู่ไกล ยิ่งช้ากระมัง เพราะป่านหลาย hop
ขอบคุณสำหรับบทความดีๆครับ อ่านแล้วเข้าใจง่ายดีครับ
http://www.thairath.co.th/content/tech/396125
ทรูเค้าบอกปลอดภัย ไม่มีการโจมตี ไม่มีการร้องเรียน
iPAtS
ผมเข้าใจว่าคนที่คิดแบบนี้ได้ NSA สูบข้อมูลไปหมดตัวเรียบร้อยแล้วครับ= ="
ถ้ามันดิ้นไม่เลิกก็เอาหลักฐานโชว์หราเลยครับ
555555555555555555555555555555555555555555555555555555
ซือเจ๊ระดับโลก!!
ลงเว็บดราม่าไปแล้ว เตรียมรับทราฟฟิก
กำลังนั่งอ่านเลยครับ
อ่านดราม่าแล้วฮาจริงๆ เจ๊แกเป็น hacker 127.0.0.1 ในตำนานป่าว
ใครใช้ true แล้วยังเจอปัญหาอยู่ช่วยลอง DNSCrypt ให้หน่อยนะครับ
วิธีติดตั้งและใช้งาน DNSCrypt.org
Opensource - Hackintosh - Graphic Design - Scriptkiddie - Xenlism Project
ใช้ทรูอยู่ครับ ที่บ้านสองหลัง มือถือ แล้วก็ Wi-Fi แต่ปัญหาคือยังไม่เคยเจอเลย เลยลองให้ไม่ได้ - -"
จริงๆ ที่อยู่เงียบๆ มาตลอดนี่เกรงว่าโพสต์ไปว่ายังไม่เจอแล้วมันจะเจอเลย :p
Lumia 520ใช้ 3G 850 ไม่ได้ไม่งั้นผมคงลองเองแล้วครับ ^^
อย่างหลังนี่นี่กลัว =,.=
Opensource - Hackintosh - Graphic Design - Scriptkiddie - Xenlism Project
DNSCrypt ไม่มีประโยชน์ครับ ลองดู diagram ในรูปที่ 3 ให้ดีๆ
ตัวที่โดนคือ resolver ที่ transparent proxy ใช้ครับ ถ้าจะติดตั้ง dnscrypt ก็ต้องติดตั้งที่ transparent proxy โน่นแหละ
อีกอย่าง ตอนนี้ true bypass cache ไฟล์ .js ไปแล้วครับ request ผ่าน transparent proxy ไม่มี cache เลย (ส่วนไฟล์ css ยังเจอ)