INTRODUCTION
NAT Slipstreaming เป็นเทคนิคการโจมตีช่องโหว่ซึ่งทำให้ผู้โจมตีสามารถเชื่อมต่อเข้าเครือข่ายภายในที่มี Firewall หรือ NAT ขวางอยู่ได้โดยตรง เพียงแค่ผู้ใช้งานเปิดเว็บไซต์ซึ่งถูกสร้างโดยผู้โจมตีที่ออกแบบมาโจมตีช่องโหว่นี้เป็นพิเศษ ลักษณะของช่องโหว่ขึ้นอยู่กับการอิมพลีเมนต์ฟังก์ชันของ NAT ซึ่งส่วนใหญ่แล้วเหมือนกัน ทำให้อุปกรณ์ที่อาจได้รับผลกระทบนั้นสามารถมีได้หลากหลาย
ในบทความนี้ ทีมตอบสนองการโจมตีและภัยคุกคาม (Intelligent Response) จาก บริษัทไอ-ซีเคียว จำกัด จะมาวิเคราะห์ที่มาของช่องโหว่ แนวคิดซึ่งอยู่เบื้องหลังการโจมตีช่องโหว่ ข้อจำกัดรวมไปถึงแนวทางในการลดผลกระทบจากช่องโหว่ครับ
แม้ว่าต้นตอของช่องโหว่นั้นจะสามารถทำความเข้าใจได้ง่าย แต่ด้วยเงื่อนไขของการโจมตีช่องโหว่ทำให้เนื้อหาอาจมีรายละเอียดเยอะขึ้นและอาจทำให้ผู้อ่านสับสนได้ เราขอแนะนำให้ผู้อ่านทำความเข้าใจจากหัวข้อ Vulnerability Overview ก่อน จากนั้นลองลงรายละเอียดที่สำคัญในหัวข้อย่อยอื่นๆ ที่เกี่ยวข้องต่อไป
ATTACK TECHNIQUE OVERVIEW
เทคนิค NAT Slipstreaming เป็นเทคนิคการโจมตีที่อาจเรียกได้ว่าได้รับอิทธิพลมาจากเทคนิค NAT pinning ซึ่งถูกประกาศในปี 2010 ทั้ง 2 เทคนิคมีผู้ค้นพบและทำวิจัยคนเดียวกันคือ Samy Kamkar และมีเป้าหมายเดียวกันคือการโจมตีการทำงานของ NAT ในลักษณะที่ผู้เริ่มต้นการโจมตีมาจากฝั่งผู้ใช้งาน หรือจากภายในสู่ภายนอก และมีผลลัพธ์ที่เหมือนกันคือหากการโจมตีสำหรับนั้น กระบวนการทำงานของ NAT จะถูกข้ามผ่านและทำให้ผู้โจมตีซึ่งอยู่เครือข่ายภายนอกสามารถทะลุกระบวนการทำงานของ NAT เพื่อเข้าถึงเครือข่ายภายในได้โดยตรง
อย่างไรก็ตาม เทคนิคการโจมตี NAT Slipstreaming เจาะจงการโจมตีไปในส่วน Application Level Gateway (ALG) ซึ่งอาศัยการตรวจสอบข้อมูลที่ส่งมาใน application layer เพื่อสนับสนุนการทำงานของ NAT ให้สามารถทำงานได้อย่างถูกต้อง ผู้โจมตีใช้วิธีการสอดแทรกข้อมูลในแพ็คเกต (packet injection) ด้วยโปรโตคอล SIP ไว้ในการส่งข้อมูลจากฟอร์มของเว็บไซต์ผ่านโปรโตคอล HTTP เพื่อหลอกการทำงานของ ALG และส่งที่จุดระเบิดไปให้ฝั่งผู้ใช้ในลักษณะของเว็บเพจ เมื่อผู้ใช้งานเปิดเว็บเพจที่มีโค้ดฝังอยู่ โค้ดดังกล่าวจะส่งผลให้เกิดการเปิดช่องทางการเชื่อมต่อที่ข้ามผ่านการทำงานของ Firewall และ NAT ได้
เทคนิคการโจมตีหลักอยู่ที่การทำให้ผู้ใช้งานซึ่งอยู่ในเครือข่ายภายในสร้างการเชื่อมต่อในโปรโตคอล SIP ออกมาโดยไม่รู้ตัว ทั้งนี้ด้วยเงื่อนไขและความไม่ง่ายที่จะแทรกแพ็คเกตของโปรโตคอล SIP ไว้ในโปรโตคอล HTTP อย่างสมบูรณ์แบบ การที่จะใช้เทคนิคให้สำเร็จจึงต้องมีการอาศัยแนวทางของการทำความเข้าใจกระบวนการทำงานของฟีเจอร์ Connection tracking ใน ALG, การควบคุมของแพ็คเกตด้วยวิธีการอย่าง TCP segmentation หรือ IP fragmentation เมื่อใช้ SIP UDP รวมไปถึงการใช้ WebRTC และ TCP timing attack เพื่อให้องค์ประกอบการโจมตีสมบูรณ์
หากสิ่งที่ผู้อ่านคาดหวังคือการเข้าใจเทคนิค NAT Slipstreaming อย่างเพียงพอ นี่คือจุดสิ้นสุดของเนื้อหาที่เราแนะนำให้ได้อ่าน อย่างไรก็ตามหากผู้อ่านสนใจอย่างแท้จริงถึงที่มาของเทคนิค แนวคิดและความสร้างสรรค์ของนักวิจัยเพื่อแก้ปัญหาในส่วนต่าง ๆ ให้การโจมตีเกิดขึ้นได้จริง เราขอแนะนำให้อ่านรายละเอียดของช่องโหว่ต่อในส่วน Attack Technique Insights ด้านล่างครับ
ATTACK TECHNIQUE INSIGHTS
เนื้อหาในส่วนต่อไปนี้คือส่วนที่จะอธิบายเทคนิคการโจมตี NAT Slipstreaming ในทุกมุมที่ผู้เขียนมีความเข้าใจ เพื่อให้เกิดความเข้าใจในลำดับของเทคนิคอย่างถูกต้อง เราขอเพิ่มคำอธิบายสั้น ๆ ในแต่ละขั้นตอนย่อยดังนี้ครับ
- หัวข้อ Understanding NAT Pinning Technique อธิบายแนวคิดของเทคนิคการโจมตี NAT Pinning ที่ส่งผลเป็นอย่างมากต่อการมอง Attack surface และแนวทางในการ Exploit ของ NAT Slipstreaming
- หัวข้อ Fundamental of ALG Attack อธิบายใจความสำคัญของเทคนิค NAT Slipstreaming ว่ามีไอเดียการโจมตีหลักเป็นอย่างไร
- หัวข้อ The "Slipping" Part อธิบายการนำแนวคิดของการโจมตีมาทำให้เกิดการโจมตีจริง
- หัวข้อ Write-What-Where in Network Packets อธิบายการแก้ปัญหาอุปสรรคแรกเพื่อให้การโจมตีสมบูรณ์ โดยการใช้ TCP segmentation และ IP fragmentation
- หัวข้อ The Need for Leaking Internal Address อธิบายการแก้ปัญหาในอุปสรรคที่สองเพื่อให้แพ็คเกต SIP ที่จะส่งนั้นถูกต้อง โดยการใช้เทคนิคต่าง ๆ เพื่อให้ได้มาซึ่งหมายเลขไอพีแอดเดรสภายในของเป้าหมาย
- หัวข้อ Crafting the Exploit อธิบายการนำองค์ประกอบทั้งหมดมารวมกันเพื่อสร้างเป็นชุดของ Exploit สำหรับเทคนิคนี้
Understanding NAT Pinning Technique
ในปี 2010 ผู้ค้นพบและวิจัยช่องโหว่ NAT Slipstreaming ได้มีการเปิดเผยงานวิจัยชิ้นแรกออกมาในชื่อ NAT Pinning พร้อมกับหน้าตัวอย่างของระบบเพื่อทดสอบเทคนิคการโจมตี การโจมตีโดยใช้เทคนิค NAT Pinning ที่สำเร็จนั้นจะทำให้อุปกรณ์เราท์เตอร์ทำการฟอร์เวิร์ดพอร์ตที่ผู้โจมตีกำหนดออกมา และเป็นช่องทางให้ผู้โจมตีที่อยู่เครือข่ายภายนอกสามารถเข้าถึงผู้ใช้งานที่อยู่ในเครือข่ายภายในได้
NAT Pinning อาศัยการใช้ฟีเจอร์ DCC (Direct Client-to-Client) ในโปรโตคอล IRC ที่ทำให้ผู้ติดต่อสื่อสารระหว่างกันสามารถติดต่อสื่อสารกันได้โดยตรงมาเปิดการใช้งานของ NAT โดยการหลอกล่อให้ผู้ใช้งานภายในร้องขอการเชื่อมไปยังเราท์เตอร์ และให้เราท์เตอร์เปิดและฟอร์เวิร์ดพอร์ตที่ต้องการจากภายนอกเข้ามา ขั้นตอนในเทคนิคการโจมตีสามารถอธิบายอย่างละเอียดได้ดังนี้
- ผู้โจมตีหลอกให้ผู้ใช้งานซึ่งเป็นเหยื่อนั้นเข้าถึงเว็บไซต์ที่มีการฝังโค้ดที่เป็นอันตรายเอาไว้
- เมื่อผู้ใช้งานเข้าเว็บไซต์ดังกล่าว ฟอร์มที่ถูกฝังไว้ในหน้าเว็บไซต์จะสร้างการเชื่อมต่อไปยังเซิร์ฟเวอร์ IRC ผ่านโปรโตคอล IRC ที่พอร์ต 6667 (http://attacker.com:6667)
- เมื่อเข้าถึงเซิร์ฟเวอร์ IRC แล้ว ฟอร์มอีกส่วนหนึ่งที่ถูกฝังไว้จะทำงาน ฟอร์มส่วนที่สองนี้จะทำการส่งข้อมูล PRIVMSG samy :\1DCC CHAT samy [ip in decimal] [port]\1\n ไปยังเซิร์ฟเวอร์ ข้อมูลซึ่งปรากฎในด้านบนเป็นการส่งข้อความในโปรโตคอล IRC ไปให้บัญชีผู้ใช้งาน samy ในเซิร์ฟเวอร์ IRC และร้องขอให้มีการเปิดใช้งานฟีเจอร์ DCC ขึ้นมาโดยระบุหมายเลขไอพีแอดเดรสเป็นค่าใดก็ได้ และพอร์ตเป็นหมายเลขพอร์ตที่ผู้โจมตีต้องการจะเชื่อมต่อเข้าไป
- เมื่อข้อความในขั้นตอนที่ 3 ถูกส่งผ่านเราท์เตอร์ซึ่งมีการใช้งาน NAT คั่นระหว่างเครือข่ายภายในและภายนอก เราท์เตอร์จะตีความว่าผู้ใช้งานกำลังจะมีการใช้ฟีเจอร์ DCC ของ IRC ซึ่งมีความจำเป็นจะต้องมีการเปิดพอร์ตในฝั่งของผู้ใช้งานเอาไว้เพื่อให้ผู้ที่จะพูดคุยด้วยอีกฝั่งหนึ่งเชื่อมต่อเข้ามาหา ด้วยเหตุนี้เราท์เตอร์จะทำการเปิดและฟอร์เวิร์ดพอร์ตขาเข้าจากภายนอกเข้ามาภายในจากหมายเลขพอร์ตที่ระบุไว้ในข้อความ
- เมื่อขั้นตอนที่ 4 เสร็จสิ้น ผู้โจมตีจากเครือข่ายภายนอกสามารถเชื่อมต่อเข้ามายังพอร์ตที่เราท์เตอร์เปิดรอเอาไว้ และเข้าถึงเครือข่ายข้างในได้ หากข้อความในขั้นตอนที่ 3 ระบุว่าเป็นพอร์ต 21 เมื่อถึงขั้นตอนที่ 5 ผู้โจมตีก็สามารถเชื่อมต่อเข้ามาโดยระบุหมายเลขพอร์ตเป็นหมายเลข 21 ได้ทันที
สิ่งที่ NAT Slipstreaming และ NAT pinning มีเหมือนกันคือลักษณะในการสร้างการโจมตีจากฝั่งผู้ใช้งานที่อยู่ภายในเครือข่ายจากการเปิดเว็บไซต์ และมีเป้าหมายในการโจมตีส่วน NAT เหมือนกันด้วย
Fundamental of ALG Attack
NAT (Network Address Translation) เป็นแนวคิดซึ่งถูกใช้เพื่อให้ระบบภายในเครือข่ายสามารถติดต่อไปยังเครือข่ายภายนอกได้ด้วยการมีหมายเลขไอพีแอดเดรสขาออกจาก NAT เป็นหมายเลขไอพีแอดเดรสเดียว โดยมี NAT เป็นตัวกลางในการจัดการแก้ไขข้อมูลเกี่ยวกับหมายเลขไอพีแอดเดรสที่ถูกส่งผ่านตัวมันให้มีค่าที่เหมาะสม ในขณะเดียวกัน NAT ก็มีหน้าที่ในการแยกการเชื่อมต่อจากระบบภายในต่างระบบไปยังระบบภายนอกระบบเดียวกันด้วย เมื่อระบบภายในทำการสร้างการเชื่อมต่อผ่าน NAT ไปยังระบบปลายทางภายนอก การติดตามการส่งข้อมูลจากปลายทางเข้ามาคือหน้าที่ของกลไกที่เรียกว่า Connection tracking ด้วยในแนวทางของการตรวจสอบและแก้ไขข้อมูลในแพ็คเกตที่ไม่ต่างกัน
อย่างไรก็ตามการใช้ NAT และโซลูชันอย่าง Firewall มีปัญหากับโปรโตคอลของแอปพลิเคชันกลุ่มหนึ่งที่มีการใช้พอร์ตที่หลากหลายตามฟีเจอร์ของโปรโตคอล ไม่สามารถระบุก่อนจนนำมาสู่การแก้ไขการตั้งค่าที่เหมาะสมได้ ตัวอย่างที่เห็นได้ชัดเจนคือโปรโตคอลอย่าง FTP ที่มีการแยกช่องทางในการส่งคำสั่งควบคุมของโปรโตคอล และช่องทางในการรับส่งข้อมูลจริงๆ ที่ต่างกัน รวมไปถึงโปรโตคอลอื่น ๆ ที่มีการกำหนดพอร์ตแบบ dynamic เมื่อจะมีการใช้งานซึ่งทำให้ไม่สามารถระบุพอร์ตได้
เพื่อแก้ไขปัญหานี้ องค์ประกอบที่ชื่อ Application Layer Gateway (ALG) จึงถูกใช้งานเพื่อช่วยให้ Firewall หรือ NAT สามารถจัดการและควบคุมการทำงานได้อย่างเหมาะสม ALG ทำงานเป็นส่วนหนึ่งของ Firewall หรือ NAT โดยจะทำการตรวจสอบข้อมูลในแพ็คเกตในระดับ application layer ด้วยการหาคีย์เวิร์ดหรือองค์ประกอบภายในแพ็คเกตที่ช่วยให้ระบุได้ว่าจะมีการใช้งานอย่างไรก็เกิดขึ้น จากนั้นทำการแก้ไขการตั้งค่าเพื่อให้รองรับการใช้งานดังกล่าวนั้น
ด้วยการตรวจสอบโปรโตคอลและข้อมูลในแพ็คเกตเพื่อระบุหาการตั้งค่าที่เหมาะสม ความเสี่ยงด้านความปลอดภัยจึงเกิดขึ้นมาจากการทำงานของ ALG ในมุมของการหลอกการทำงานของ ALG ให้หลงเชื่อว่าการเชื่อมต่อแบบผิดปกตินั้นปกติผ่านการแทรกคีย์เวิร์ดหรือข้อมูลในแพ็คเกตของโปรโตคอลให้เหมาะสม ประเด็นการแทรกคีย์เวิร์ดหรือข้อมูลในแพ็คเกตของโปรโตคอลให้เหมาะสมและหลอกการทำงานของ ALG จนเกิดช่องทางเพื่อข้ามผ่านมาตรการความปลอดภัยได้คือใจความหลักของการโจมตี NAT Slipstreaming
The "Slipping" Part
จากไอเดียในส่วนที่แล้วของการโจมตีการทำงานของ ALG ด้วยการแทรกคีย์เวิร์ดและข้อมูลในแพ็คเกตของโปรโตคอลและหลอกให้ ALG เปิดช่องทางการเชื่อมต่อโดยที่ผู้ใช้งานไม่รู้ตัว นักวิจัยหลักของเทคนิคการโจมตีนี้ได้มีการนำแนวทางการโจมตีเดิมที่ใช้ในเทคนิค NAT Pinning ขึ้นมาใช้ใหม่ โดยอาศัยการหลอกให้ผู้ใช้งานเข้าถึงหน้าเว็บไซต์ปลอมที่มีสคริปต์อันตรายและเป็นผู้เริ่มต้นการสร้างการเชื่อมต่อออกมาจากข้างใน
ในงานวิจัย NAT Slipstreaming นั้น นักวิจัยมีการอ้างอิงการทำงานของ ALG มาจากเฟรมเวิร์ค netfilter ซึ่งอิมพลีเมนต์ฟีเจอร์อย่าง NAT ใน Linux kernel ดังนั้นอาจมีความเป็นไปได้ในเรื่องของความผิดพลาดในการโจมตีซึ่งเกิดจากการที่อุปกรณ์ที่อิมพลีเมนต์ ALG นั้นมีเงื่อนไขที่ไม่เหมือนกับเงื่อนไขของที่ปรากฎใน netfilter
ประเด็นสำคัญต่อมานั้นคือการเลือกโปรโตคอลที่ ALG รองรับเพื่อใช้เป็นส่วนของการหลอก การเลือกโปรโตคอลยังมีเงื่อนไขเพิ่มขึ้นมาจากเดิมเนื่องจากการโจมตี NAT Pinning ในปี 2010 ซึ่งอาศัยโปรโตคอล IRC นั้นส่งผลให้เว็บเบราว์เซอร์เริ่มทำการจำกัดการเชื่อมต่อโดยระบุเอาไว้ในโค้ดของโปรแกรมเว็บเบราว์เซอร์ (ดูเพิ่มเติม ซอร์สโค้ดของ Google Chrome ในส่วนที่มีการจำกัดการใช้งานพอร์ต) ดังนั้นโปรโตคอลที่จะใช้ในการโจมตีกับ ALG จะต้องถูกรองรับโดย ALG และสามารถถูกส่งผ่านเว็บเบราว์เซอร์ได้ด้วย
ทั้งนี้หากแนวทางในการโจมตีของผู้อ่านไม่ใช่การใช้งานเบราว์เซอร์แต่เป็นช่องทางอื่น ตัวเลือกของโปรโตคอลที่สามารถใช้งานเพื่อโจมตีได้อาจมีมากกว่าที่ระบุและปรากฎในงานวิจัย NAT Slipstreaming
จากการตรวจสอบซอร์สโค้ดของ netfilter และการทดสอบกับเว็บเบราว์เซอร์ Google Chrome นักวิจัยได้สรุปโปรโตคอลที่น่าสนใจและเป็นไปตามเงื่อนไขซึ่งนำมาใช้โจมตีได้ตามรูปภาพด้านล่าง
ด้วยเงื่อนไขของการโจมตีที่นักวิจัยกำหนดไว้คือการเรียกผ่านเว็บเบราว์เซอร์ Google Chrome เพื่อสร้างการเชื่อมต่อจากภายในเครือข่ายสู่ภายนอก โปรโตคอลที่ยังไม่ถูกบล็อคโดย Google Chrome ในตาราง ได้แก่โปรโตคอล sane, โปรโตคอล sip, โปรโตคอล pptp และโปรแกตคอล h323 q931 จึงเป็นโปรโตคอลที่อาจนำมาใช้ในการโจมตี ALG ได้
นักวิจัยหลักของการโจมตี NAT Slipstreaming ระบุว่า เขาได้เลือกทดสอบทฤษฎีการโจมตีโดยการเลือกใช้โปรโตคอล SIP ด้วยเหตุผลในเรื่องของความแพร่หลายในการใช้งาน และมีโอกาสที่สูงที่อุปกรณ์เครือข่ายอื่น ๆ จะรองรับการทำงาน
เมื่อถึงจุดนี้ เรามีแคนดิเดตหรือตัวเลือกของโปรโตคอลซึ่งเมื่อถูก ALG ตรวจสอบแล้วอาจมีการเปิดช่องทางการเชื่อมต่อขึ้นมาโดยที่ผู้ใช้งานไม่รู้ตัวซึ่งก็คือโปรโตคอล SIP อย่างไรก็ตามการสื่อสารในโปรโตคอล SIP จะต้องมีลักษณะเป็นอย่างไรล่ะถึงจะทำให้ ALG เชื่อและเปิดการเชื่อมต่อได้โดยที่ผู้ใช้ไม่รู้ตัว หรือในอีกความหมายหนึ่ง หากผู้ใช้งานถูกหลอกให้ส่งข้อมูลโดยใช้โปรโตคอล SIP แล้ว อะไรล่ะคือสิ่งที่ผู้ใช้งานควรส่งออกไป?
คำตอบสำหรับคำถามด้านบนสามารถค้นหาได้จากการทำความเข้าใจการทำงานของ NAT, ฟีเจอร์ Connection tracking และการทำงานของ ALG ซึ่งก็คือฝั่งของอุปกรณ์ที่จะรับ (และถูกหลอก) จากการส่งข้อมูลมาโดยเหยื่อของเรา เนื่องจากนักวิจัยมีการอ้างอิงการทำงานของ ALG มาจากเฟรมเวิร์ค netfilter ซึ่งอิมพลีเมนต์ฟีเจอร์อย่าง NAT ใน Linux kernel การทำงานของ ALG จึงสามารถทำความเข้าใจได้จากการอ่านและทำความเข้าใจโค้ดของเฟรมเวิร์ค netfilter โดยเฉพาะอย่างยิ่งในส่วนโมดูล SIP connection tracking ซึ่งเฟรมเวิร์ค netfilter ใช้ในการติดตามการรับส่งข้อมูล
สำหรับผู้ที่สนใจการไล่การทำงานของ SIP connection tracking ตามซอร์สโค้ด เราขอแนะนำให้อ่านงานวิจัยต้นฉบับในส่วน Connection Tracking / Application Level Gateway Investigation ซึ่งลงรายละเอียดในส่วนนี้เอาไว้ ทั้งนี้เราได้สรุปผลลัพธ์จากการทำความเข้าใจซอร์สโค้ดของ SIP connection tracking ซึ่งทำให้ทราบว่าเราควรเตรียมแพ็คเกต SIP อย่างไรให้เหยื่อส่งออกไปรวมไปถึงเงื่อนไขต่าง ๆ ตามประเด็นด้านล่าง
- โมดูลจะรอรับแพ็คเกต SIP ที่ส่งมาอยู่ 4 ลักษณะคือผ่าน IPv4 หรือผ่าน IPv6 ในเลเยอร์ Network และผ่าน TCP หรือ UDP ในเลเยอร์ Transport โดยจะต้องถูกส่งมาที่พอร์ต 5060 เท่านั้น
- ในโมดูล SIP connection tracking จะมีการตรวจสอบว่าแพ็คเกตที่เข้ามานั้นเป็นแพ็คเกตของโปรโตคอล SIP หรือไม่โดยการตรวจหาการมีอยู่ของเมธอดในโปรโตคอล SIP ว่ามีการปรากฎในส่วนแรกของแพ็คเกตหรือไม่ หากไม่มีการปรากฎของเมธอดอย่างถูกต้อง แพ็คเกตดังกล่าวจะไม่ถูกประมวลผลต่อ โดยเมธอดทั่วไปเมื่อเริ่มการเชื่อมต่อของโปรโตคอล SIP คือค่า INVITE หรือ REGISTER
- เมื่อการตรวจสอบลักษณะแพ็คเกต SIP เสร็จสิ้น เฟรมเวิร์ค netfilter จะทำการเตรียมพอร์ตเพื่อให้ผู้ใช้งานจากเครือข่ายข้างนอกเชื่อมต่อเข้ามา (เรียกว่า firewall pinhole เนื่องจากเปิดช่องขนาดเล็กเท่ารูเข็มไว้ช่องเดียว) หลังจากฟังก์ชันภายใน SIP connection tracking จะทำการแก้ไขข้อมูลหมายเลขไอพีแอดเดรสของผู้ส่งจากหมายเลขไอพีแอดเดรสภายในเป็นหมายเลขไอพีแอดเดรสขาออกของ NAT เพื่อให้สามารถปลายทางซึ่งอยู่เครือข่ายด้านนอกสามารถเชื่อมต่อได้
- เฟรมเวิร์ค netfilter จะรอจนกระทั่งมีการตอบกลับจากเซิร์ฟเวอร์ที่อยู่เครือข่ายภายนอก กระบวนการตรวจสอบแพ็คเกต SIP ที่ตอบกลับมาจะเกิดขึ้นและหากลักษณะของแพ็คเกต SIP ที่ตอบกลับมานั้นถูกต้องตามเงื่อนไข พอร์ตที่ถูกเตรียมไว้ในขั้นตอนก่อนหน้าจะถูกฟอร์เวิร์ดมาภายใน สร้างเป็นการเชื่อมต่อขึ้น
ดูเหมือนว่าการทำความเข้าใจการทำงานของ SIP connection tracking ในเฟรมเวิร์ค netfilter จะทำให้เราทราบว่าเราจะต้องเตรียมแพ็คเกตเพื่อให้ (หรือหลอก) ผู้ใช้เป็นผู้ส่งอย่างถูกต้องในข้อ 1 และ 2 จากนั้นมีการเตรียมเซิร์ฟเวอร์ SIP เพื่อตอบกลับการร้องขอจึงจะทำให้เงื่อนไขในข้อ 4 เกิดขึ้นจริง
เงื่อนไขในข้อที่ 1 นั้นไม่ได้เป็นปัญหาเท่าใดนักเนื่องจาก Google Chrome สามารถถูกใช้เพื่อระบุลักษณะการเชื่อมต่อตามเงื่อนไขได้ ปัญหาที่แท้จริงกลับมาอยู่ที่ข้อที่ 2 ที่เราจะต้องทำให้เบราว์เซอร์ส่งแพ็คเกต TCP (หรือ UDP) ที่มีเมธอดของโปรโตคอล SIP อยู่ในตำแหน่งที่เหมาะสม ไม่เช่นนั้นโมดูล SIP connectiong tracking จะเตะแพ็คเกตของเราออกไปอย่างไม่ไยดี ภายใต้เงื่อนไขของการใช้เบราว์เซอร์ในการโจมตี เบราว์เซอร์กลับกลายเป็นตัวเลือกที่ทำให้สถานการณ์และเงื่อนไขการโจมตีนั้นยุ่งยากขึ้นไปอีก ด้วยเหตุผลดังนี้
- เบราว์เซอร์โดยทั่วไปจะไม่ส่งแพ็คเกตเป็นโปรโตคอล TCP เปล่า มันมีเลเยอร์ของแอปพลิเคชันซ้อนทับอยู่ด้านบนซึ่งทำให้แพ็คเกตที่ถูกสร้างออกไปนั้นไม่ตรงตามเงื่อนไข
- หากเราดึงดันที่จะส่งออกไป เราอาจทำได้มากที่สุดโดยการทำให้ผู้ใช้งานส่งข้อมูลโดยใช้โปรโตคอล HTTP หรือ HTTPS ออกไปโดยไม่รู้ตัว แต่โปรโตคอล HTTP ก็จำเป็นต้องมีเมธอดของมันเองขึ้นต้น เช่นเดียวกับ HTTPS ที่มีการเข้ารหัสเอาไว้อยู่
- ทางเลือกของโปรโตคอลอื่นที่เบราว์เซอร์สามารถส่งออกไปในเลเยอร์ Application ล้วนแล้วแต่ไม่สอดคล้องกับเงื่อนไขการโจมตี อาทิ Flash มีการส่งข้อมูลในรูปแบบที่ไม่สามารถควบคุมได้, Java จำเป็นต้องขอสิทธิ์ในการส่งข้อมูล, WebSockets ส่งเป็น HTTP, WebRTC (RFC 7742) มีการเข้ารหัส, โปรโตคอล STUN (RFC 3489) และ TURN (RFC 5766) ก็มีรูปแบบที่ตายตัว ส่วนโปรโตคอล TURNS (RFC 7065) ก็มีรูปแบบที่ตายตัวและถูกเข้ารหัสด้วย
เมื่อการเลือกใช้โปรโตคอล SIP ในการโจมตี ALG มีเงื่อนไขอีกมากมายตามมา ความสามารถและความสร้างสรรค์ในแก้ไขปัญหาเพื่อข้ามผ่านเงื่อนไขในการโจมตีไปจนได้คือศิลปะและ mindset ที่แฮกเกอร์ควรต้องมี เราจะมาติดตามกันส่วนถัดไปเพื่อทำความเข้าใจความสร้างสรรค์ในการแก้ไขปัญหานี้กันต่อครับ สำหรับใครที่และกลัวว่าจะลืมความเข้าใจในส่วนนี้ ด้านล่างคือสรุปเนื้อหาในส่วนของ The "Slipping" Part ครับ
- ภายใต้เงื่อนไขและสถานการณ์แบบการโจมตี NAT Pinning ผู้วิจัยเลือกสถานการณ์สำหรับ NAT Slipstreaming ด้วยการหลอกให้ผู้ใช้สร้างการเชื่อมต่อจากภายในผ่านเว็บเบราว์เซอร์เพื่อหลอก ALG โดยผู้ใช้งานไม่รู้ตัว
- นักวิจัยเลือกใช้โปรโตคอล SIP ในการโจมตี ALG เนื่องจากเป็นโปรโตคอลที่ ALG จะมีการประมวลผล และสามารถส่งจากเว็บเบราว์เซอร์ Google Chrome ได้ ณ ตอนนี้ (ยังไม่มีการบล็อคการส่งออก)
- ทั้งนี้ด้วยเงื่อนไขที่จะทำให้แพ็คเกต SIP นั้นเป็นแพ็คเกต SIP จริง ๆ นักวิจัยพบว่าโปรแกรมเว็บเบราว์เซอร์ไม่สามารถส่งข้อมูลได้ตามเงื่อนไขที่เหมาะสม และอาจทำให้ข้อมูลที่ส่งออกไปนั้นไม่ถูกมองเป็นแพ็คเกต SIP จนถูกดรอปในที่สุด
Write-What-Where in Network Packets
ความเดิมจากตอนที่แล้ว นักวิจัยพบว่าการที่จะสร้างการโจมตีในลักษณะเดียวกับ NAT Pinning หรือการให้ผู้ใช้งานซึ่งอยู่ในเครือข่ายภายในเป็นผู้สร้างการเชื่อมต่อออกมาสู่เครือข่ายภายนอกและเปิดช่องทางให้ผู้ไม่ประสงค์ดีนั้น โปรโตคอลที่น่าสนใจในสถานการณ์ดังกล่าวคือโปรโตคอล SIP ที่สามารถูกส่งผ่านเว็บเบราว์เซอร์อย่าง Google Chrome อย่างไรก็ตามโปรโตคอล SIP กลับมีเงื่อนไขอยู่ซึ่งหากไม่สามารถทำได้ตามเงื่อนไขดังกล่าว ผู้รับแพ็คเกตอาจปฏิเสธดังกล่าวเนื่องจากคุณลักษณะที่ไม่ถูกต้อง
เงื่อนไขสำคัญเพื่อให้แพ็คเกตในโปรโตคอล SIP ของเรานั้นเป็นแพ็คเกตที่ถูกต้องคือการระบุเมธอดของแพ็คเกต SIP อาทิ INVITE หรือ REGISTER ไว้ในส่วนแรกสุดของแพ็คเกต ดังนั้นเนื้อหาในส่วนนี้จึงว่าด้วยเรื่องของเงื่อนไขที่เรียกว่า Write-what-where (CEW-123) ซึ่งมักปรากฎในการช่องโหว่ประเภท Memory corruption โดยเป็นเงื่อนไขที่ทำให้ผู้โจมตีสามารถเขียนค่าใด ๆ ก็ได้ไปยังตำแหน่งที่ต้องการในหน่วยความจำ อย่างไรก็ตามในเนื้อหาส่วนนี้เราจะมาพูดถึงเงื่อนไข Write-what-where ในเน็ตเวิร์กแพ็คเกตเพื่อเป้าหมายของการทำสิ่งที่เป็นไปไม่ได้อย่างการเริ่มต้นการส่งข้อมูลในโปรโตคอล HTTP ด้วยเมธอดของโปรโตคอล SIP ให้เป็นจริงขึ้นมาได้ครับ
เราส่งท้ายในบท The "Slipping" Part ด้วยการสำรวจความเป็นไปได้ของโปรโตคอลในเลเยอร์ที่ 7 ว่ามีโอกาสมากน้อยแค่ไหนที่จะใช้ในการโจมตี อย่างไรก็ตามผลสำรวจไม่ได้ให้ข้อมูลใด ๆ ที่มีประโยชน์ต่อเรามากเท่าไหร่นัก ถ้าในเลเยอร์ 7 ไม่มีความเป็นไปได้ ทางเลือกของเราก็อาจจะอยู่ในเลเยอร์อื่น 😉
Samy ซึ่งเป็นนักวิจัยของเทคนิค NAT Slipstreaming เสนอแนวทางที่น่าสนใจแนวทางหนึ่งขึ้นมาคือการลงไปเล่นกับฟังก์ชันของโปรโตคอล TCP ข้อเสนอตั้งอยู่บนสมมติฐานที่ว่าหากเราส่งแพ็คเกตในโปรโตคอล TCP ที่มีขนาดใหญ่มาก ๆ ฟีเจอร์หนึ่งของโปรโตคอล TCP ชื่อ TCP segmentation จะทำงานขึ้น โดยมันจะแยกแพ็คเกตขนาดใหญ่ให้เป็นแพ็คเกตขนาดเล็กหลายอัน ถ้าเราออกแบบแพ็คเกตอย่างรอบคอบมากพอเพื่อตอบรับเงื่อนไขนี้ หนึ่งในแพ็คเกตเล็ก ๆ ของเรานั้นก็อาจมีแพ็คเกตที่ขึ้นต้นด้วยเมธอดในโปรโตคอล SIP ที่ถูกต้องได้ตามเงื่อนไขการโจมตี
เพื่อให้เราสามารถออกแบบแพ็คเกตอย่างถูกต้องเพื่อให้เมื่อถูกแบ่งนั้นจะมีแพ็คเกตที่ตรงกับเงื่อนไขของการโจมตี เราจำเป็นต้องทราบข้อมูลอีกจำนวนหนึ่งก่อน ได้แก่ ค่า Max Transmission Unit หรือ MTU ซึ่งระบุขนาดสูงสุดที่สามารถถูกส่งได้ในหนึ่งการเชื่อมต่อในเลเยอร์เน็ตเวิร์ก, ขนาดของเฮดเดอร์ของโปรโตคอล IP, ลักษณะการตั้งค่าที่อยู่ในเฮดเดอร์ของโปรโตคอล IP, ขนาดของเฮดเดอร์ของโปรโตคอล TCP, ลักษณะการตั้งค่าที่อยู่ในเฮดเดอร์ของโปรโตคอล TCP, ขนาดของส่วนข้อมูลและตำแหน่งในแพ็คเกตที่ผู้โจมตีสามารถควบคุมได้ โดยคุณสมบัติทั้งหมดจะต้องทราบก่อนการโจมตี เพื่อให้สามารถปรับแต่งลักษณะของแพ็คเกตได้อย่างเหมาะสม
ในการเก็บข้อมูลดังกล่าว Samy มีการพัฒนาสคริปต์ซึ่งทำหน้าที่เป็น packet sniffer ชื่อ max_pkt_size.pl สำหรับการระบุหาข้อมูลดังกล่าวโดยรับข้อมูลจากผู้ใช้งานซึ่งถูกลักลอบส่งมาด้วย HTTP POST นอกเหนือจากนั้น Samy ยังมีการพัฒนาเว็บเซิร์ฟเวอร์เฉพาะสำหรับรอรับการส่งข้อมูลจากโปรโตคอล SIP ที่พอร์ต TCP/5600 เอาไว้ด้วยเพื่อตอบการส่งข้อมูลใด ๆ กลับไป ป้องกันไม่ให้เกิดข้อผิดพลาดและทำให้เกิดความผิดสังเกต
นอกเหนือจากการประเมินและคำนวณเพื่อหาตำแหน่งที่ถูกต้องสำหรับเมธอดของโปรโตคอล SIP แล้ว Samy ยังได้มีการควบคุมขนาดของแพ็คเกตที่จะใช้ในการติดต่อระหว่างผู้ใช้งานและเซิร์ฟเวอร์ของผู้โจมตีในระดับของโปรโตคอล TCP โดยการกำหนดค่า Maximum Segment Size (MSS) ซึ่งเป็นฟีเจอร์ที่อยู่ในโปรโตคอล TCP การกำหนดค่า MSS จะเกิดขึ้นในขั้นตอนที่เซิร์ฟเวอร์มีการตอบ SYN-ACK ตั้งแต่การทำ 3-way handshake การกำหนดค่าในส่วนนี้สามารถตั้งค่าได้ในที่ระบบที่รันเว็บเซิร์ฟเวอร์
โดยในกรณีของ Samy คำสั่งที่ใช้ในการกำหนดค่า MSS มีตามตัวอย่างด้านล่าง
ip route replace default via [gateway] dev eth0 advmss 1500
เมื่อผู้ใช้งานเปิดหน้าเว็บเพจที่ฝังสคริปต์ที่เป็นอันตรายเอาไว้ ข้อมูลขนาดใหญ่พร้อมกับเลขสุ่มชุดหนึ่งจะถูกส่งมาผ่าน HTTP POST มายังเว็บเซิร์ฟเวอร์ของผู้โจมตี ผู้โจมตีจะทำการประมวลผลขนาดของแพ็คเกตที่เหมาะสมและส่งข้อมูลดังกล่าวกลับไปยังผู้ใช้งานผ่าน HTTP POST อีกส่วนหนึ่ง สคริปต์ในเว็บไซต์ของฝั่งผู้ใช้งานจะรับข้อมูลและประมวลผลขนาดเพื่อให้ทราบว่าในสภาพแวดล้อมของผู้ใช้งานนั้น สคริปต์จำเป็นจะต้องเติมข้อมูลขยะลงไปในแพ็คเกตมากน้อยเพียงใดเพื่อให้เกิดการทำ TCP segmentation และทำให้แพ็คเกตที่มีเมธอดของโปรโตคอล SIP เป็นแพ็คเกตใหม่พอดี
ในบางกรณีที่การเชื่อมต่อในโปรโตคอล SIP เกิดขึ้นบนโปรโตคอล UDP และทำให้ NAT จะอนุญาตให้มีการส่งแพ็คเกตเฉพาะในโปรโตคอล UDP ผ่านตัวมัน ทางเลือกในการทำ Fragmentation ยังคงเป็นไปได้ภายใต้การใช้โปรโตคอล TURN ซึ่งเป็นโปรโตคอลติดต่อสื่อสารแบบ peer-to-peer เช่นเดียวกับ SIP และ WebRTC โปรโตคอล TURN ทำงานบนโปรโตคอล UDP และถูกรองรับในหลายเว็บเบราว์เซอร์สำหรับการใช้งาน WebRTC
ในการทำงานของโปรโตคอล TURN นั้น ผู้ใช้งานจำเป็นต้องมีการพิสูจน์ตัวตนด้วยชื่อผู้ใช้งานและรหัสก่อนโดยจะมีการส่งค่าของชื่อผู้ใช้งานแบบไม่มีการเข้ารหัส อ้างอิงจากรายละเอียดของโปรโตคอลในเอกสาร RFC โปรโตคอล TURN ไม่ได้มีการกำหนดขนาดหรือจำนวนตัวอักษรเอาไว้ในส่วนของชื่อผู้ใช้งาน ซึ่งส่งผลให้ผู้โจมตีสามารถใช้การส่งชื่อผู้ใช้งานเพื่อพิสูจน์ตัวตนในโปรโตคอล TURN เพื่อทำ packet overflow ซึ่งในไปสู่เงื่อนไข Write-what-where ได้
เนื่องจากโปรโตคอล TURN ทำงานอยู่บนโปรโตคอล UDP ที่ไม่มีการทำ Segmentation ในตัวโปรโตคอลเอง กระบวนการ Segmentation จึงจะเกิดขึ้นในระดับ TCP หากขนาดของแพ็คเกตนั้นเกินค่า MTU เมื่อเกิดการกระบวนการ Segmentation แพ็คเกตซึ่งถูกแบ่งและอยู่ในระดับต่อๆ ไปจะไม่ได้มีเพียงค่าของข้อมูลที่เรากำหนดแต่จะมีส่วนที่เป็นเฮดเดอร์ของโปรโตคอล UDP อยู่ด้วย ดังนั้นการคำนวณเพื่อจัดการการเรียงแพ็คเกตในกรณีของ UDP นั้นจะต้องทำการคำนวณจากค่า MTU แทนค่า MSS เพื่อให้ส่วนตัวของแพ็คเกตที่มีเมธอดในโปรโตคอล SIP นั้นอยู่ที่แพ็คเกตที่ถูกแบ่งแล้วพอดี เงื่อนไข Write-what-where ในกรณีของโปรโตคอล UDP ก็จะสมบูรณ์
สำหรับเนื้อหาในส่วน Write-What-Where in Network Packets เราสามารถสรุปใจความสำคัญได้ดังนี้ครับ
- เนื่องจากแพ็คเกตในโปรโตคอล SIP ที่ถูกต้องนั้นจะต้องเริ่มต้นด้วยเมธอดในโปรโตคอล SIP และเนื่องจากข้อจำกัดของเว็บเบราว์เซอร์ การปรับแต่งเพื่อให้เงื่อนไขการโจมตีถูกต้องจึงเกิดขึ้นในเลเยอร์ที่ต่ำลงมา โดยการเล่นกับกระบวนการ Segmentation ในโปรโตคอล TCP และกระบวนการ Segmentation ในโปรโตคอล IP หากมีการรับและส่งข้อมูลในโปรโตคอล UDP
- กระบวนการ Segmentation คือการตัดแบ่งแพ็คเกตที่มีขนาดใหญ่เกินกำหนดของโปรโตคอลออกเป็นแพ็คเกตขนาดเล็ก
- การจะทำให้กระบวนการ Segmentation เกิดและเป็นประโยชน์ต่อการโจมตีได้ ผู้โจมตีจะต้องทราบข้อมูลสภาพแวดล้อมจากฝั่งผู้ใช้งาน เพื่อให้ทราบจำนวนของข้อมูลขยะที่ต้องเพิ่มเข้าไปเพื่อให้แพ็คเกตมีขนาดใหญ่และถูกตัดแบ่งได้อย่างพอดี
- ในกรณีของ TCP segmentation การระบุหาขนาดที่เหมาะสมเกิดขึ้นผ่านการส่งข้อมูลจาก HTTP POST จากผู้ใช้งานมายังผู้โจมตีเพื่อให้ฝั่งผู้โจมตีประมวลหาขนาดที่เหมาะสม และส่งกลับไปยังสคริปต์ซึ่งทำงานอยู่ในเว็บไซต์ในฝั่งของผู้ใช้งาน
- ในกรณีของโปรโตคอล UDP ซึ่งกระบวนการ Segmentation เกิดที่โปรโตคอล IP การระบุหาขนาดที่เหมาะสมเกิดขึ้นผ่านการส่งข้อมูลชื่อผู้ใช้งานในโปรโตคอล TURN ไปให้กับผู้โจมตีเพื่อให้ฝั่งผู้โจมตีประมวลผลหาขนาดที่เหมาะสม และส่งกลับไปยังสคริปต์ซึ่งทำงานอยู่ในเว็บไซต์ในฝั่งของผู้ใช้งาน
The Need for Leaking Internal Address
แม้เราจะสามารถทำให้ผู้ใช้งานส่งแพ็คเกตออกมาจากเบราว์เซอร์ที่มีลักษณะตรงกับเงื่อนไขที่ ALG จะทำการประมวลผลและตีความว่าแพ็คเกตจากโปรโตคอล SIP อีกหนึ่งเงื่อนไขที่เราจะต้องทำให้ได้คือการใส่หมายเลขไอพีแอดเดรสภายในของเป้าหมายลงไปในแพ็คเกตที่จะส่งออกมา ก่อนจะทำการส่งออกมาจริง ๆ
สาเหตุที่แพ็คเกต SIP ที่ผู้ใช้งานจะส่งออกมา (โดยไม่รู้ตัว) อยู่ในโค้ดการทำงานของ ALG และในส่วนของ RFC ของโปรโตคอล SIP โดยหากอ้างอิงจากโค้ดการทำงานของ ALG นั้น ฟังก์ชัน process_sip_request() ซึ่งอยู่ในไฟล์ nf_conntrack_sip.c จะมีการระบุเงื่อนไขอยู่ชัดเจนว่า ALG จะระบุหาและรับแพ็คเกตที่มีค่าหมายเลขไอพีแอดเดรสที่ถูกต้องเท่านั้น
เนื่องจากในมุมของผู้โจมตีที่อยู่ภายนอก ทราฟิกใด ๆ จากผู้ใช้งานซึ่งเดินทางมาถึงผู้โจมตีนั้นล้วนแล้วแต่ผ่าน NAT ซึ่งทำให้การรับรู้หมายเลขไอพีแอดเดรสภายในนั้นไม่สามารถทำได้โดยตนง ด้วยเงื่อนไขนี้ สิ่งที่ผู้โจมตีต้องจัดเตรียมเพื่อให้ผู้ใช้งานเป็นสั่งการ (โดยไม่รู้ตัว) และส่งผลให้เกิดการเติมหมายเลขไอพีแอดเดรสภายในของผู้ใช้งานลงไปคือลักษณะของเทคนิคการโจมตีประเภทต่าง ๆ ซึ่งส่งผลให้เกิดการรับทราบข้อมูลหมายเลขไอพีแอดเดรสภายในได้ เทคนิคการโจมตีเหล่านี้มีหลากหลาย ตามรายการดังนี้
- ใช้โปรโตคอล WebRTC ซึ่งในปัจจุบันจำเป็นต้องใช้ผ่านโปรโตคอล HTTPS ในกรณีที่เราเลือกใช้โปรโตคอล WebRTC ในการหาหมายเลขไอพีแอดเดรสภายในนั้น เราจะต้องทำการตรวจสอบว่าการเชื่อมต่อเกิดขึ้นในโปรโตคอล HTTP และทำการรีไดเร็คการเชื่อมต่อไปยัง HTTPS หลังจากใช้โปรโตคอล WebRTC ในการหาหมายเลขไอพีแอดเดรสภายในเสร็จแล้ว ฝั่งผู้โจมตีจะบังคับให้ผู้ใช้งานรีไดเร็คกลับมาที่ HTTP เพื่อทำการโจมตีต่อ โดยอาจสามารถทำได้ผ่านการเติมหมายเลขไอพีแอดเดรสของเซิร์ฟเวอร์ไว้ที่ URL เพื่อข้ามผ่านฟีเจอร์ cross-origin
- ใช้การโจมตี TCP Timing Attack ในกรณีที่เบราว์เซอร์เป้าหมายไม่รองรับการใช้งาน WebRTC ซึ่งสามารถอ่านเพิ่มเติมถึงรายละเอียดการโจมตีในส่วนนี้ได้จาก Timing Attack
เมื่อได้หมายเลขไอพีแอดเดรสภายในของผู้ใช้งานมาแล้ว สิ่งที่เราต้องทำเป็นอันดับสุดท้ายคือประกอบร่างแพ็คเกตที่จะถูกส่งมาจากผู้ใช้งานออกมา ซึ่งเราจะพูดถึงประเด็นในส่วนสุดท้าย "Crafting the Exploit" ครับ
Crafting the Exploit
เมื่อผู้ใช้งานเปิดหน้าเว็บเพจของผู้โจมตีซึ่งฝังสคริปต์สำหรับการคำนวณหาขนาดของแพ็คเกตที่จะทำให้เกิดการ Segmentation อย่างเหมาะสมเอาไว้ และส่วนของสคริปต์ที่จะทำการโจมตีเพื่อรู้หมายเลขไอพีแอดเดรสภายใน ผลลัพธ์สุดท้ายที่นำผลลัพธ์ของสคริปต์ต่าง ๆ มาประกอบจะอยู่ในลักษณะของการส่งข้อมูลแบบ HTTP POST ออกมาตามรูปภาพด้านล่าง (แนะนำให้ดูรูปภาพขนาดเต็ม)
ลักษณะของข้อมูลส่วนสุดท้ายที่ผู้ใช้งานจะส่งออกมาและให้ ALG ประมวลผลตามรูปภาพด้านบนสามารถอธิบายได้ดังนี้
- ส่วนตัวหนังสือสีน้ำเงิน/ฟ้าซึ่งเป็นการส่ง HTTP POST ออกมา ข้อมูลส่วนใหญ่ในส่วนนี้จะถูกกำหนดโดยเว็บเบราว์เซอร์ยกเว้นในส่วนที่เป็นตัวหนา ข้อมูลในส่วนนี้เป็นคือส่วนที่สคริปต์สำหรับการคำนวณขนาดจะรับค่ามาและนำมาคำนวณเพื่อให้ขนาดที่เหมาะสมและทำให้เกิดการทำ Segmentation โดยหากเกิดการแบ่งขึ้นมาแล้ว แพ็คเกตในส่วนนี้จะถือว่าเป็นแพ็คเกตย่อยส่วนแรก
- ส่วนตัวหนังสือสีขาวเป็นส่วนที่ถูกเติม (pad) จากการคำนวณขนาดเพื่อให้ขนาดของแพ็คเกตใหญ่มากพอที่จะทำให้เกิดการทำ Segmentation เราจะเห็นลักษณะของตัวอักษร ^_ จำนวนหลายตัวซึ่งทำหน้าที่ขยายขนาดของแพ็คเกตให้ใหญ่ขึ้นจนเต็ม MTU หากเกิดการแบ่งแพ็คเกตขึ้นมาแล้ว แพ็คเกตในส่วนนี้จะถือว่าเป็นแพ็คเกตย่อยส่วนที่สองที่จะส่งมายังเซิร์ฟเวอร์ของผู้โจมตี และผู้โจมตีจะต้องตอบกลับไปเพื่อไม่ให้เกิดข้อผิดพลาดจนผิดสังเกต
- ส่วนตัวหนังสือสีเขียวเป็นส่วนของแพ็คเกต SIP ที่ถูกจัดวางอย่างเหมาะสมให้เมื่อการทำ Segmentation แล้ว แพ็คเกตย่อยในส่วนนี้ซึ่งถือว่าเป็นส่วนที่สามจะถูกมองโดย ALG ว่าเป็นแพ็คเกตในโปรโตคอล SIP ด้วยการขึ้นต้นของเมธอด REGISTER ตามโปรโตคอลของ SIP พร้อมกับการระบุหมายเลขไอพีแอดเดรสภายในอย่างถูกต้อง ส่วนสำคัญที่สุดของแพ็คเกตอยู่ในส่วนของ CONTACT ซึ่งผู้โจมตีจะระบุพอร์ตที่ต้องการให้เกิดการฟอร์เวิร์ดโดย ALG และสามารถเข้าถึงได้จากผู้โจมตี ในรูปภาพนี้ส่วนดังกล่าวถูกชี้ด้วยตัวอักษรสีน้ำเงินเข้ม
เมื่อแพ็คเกตดังกล่าวถูกส่งมายังเซิร์ฟเวอร์ของผู้โจมตี เซิร์ฟเวอร์ผู้โจมตีจะทำการตรวจสอบแพ็คเกตที่เข้ามาและดูว่าแพ็คเกตในส่วน SIP นั้นมีการแก้ไขหมายเลขไอพีภายในเป็นหมายเลขไอพีภายนอกจากการผ่าน NAT แล้วหรือไม่ ความหมายของการที่หมายเลขไอพีแอดเดรสภายในในแพ็คเกต SIP ที่ไม่ถูกแก้ไขอาจบ่งบอกได้ว่ากระบวนการ Segmentation ยังไม่สมบูรณ์ซึ่งส่งผลให้ NAT ยังมองไม่ออกว่าแพ็คเกตในส่วนนี้เป็นแพ็คเกต SIP อย่างถูกต้อง หากการตรวจสอบแพ็คเกตที่ออกมาพบว่าหมายเลขไอพีแอดเดรสในส่วนแพ็คเกต SIP ยังไม่ถูกแก้ไข เซิร์ฟเวอร์ของผู้โจมตีจะมีการส่งสัญญาณกลับไปยังสคริปต์เพื่อให้ทำการปรับปรุงขอบเขตของแพ็คเกตใหม่ให้เกิดการทำ Segmentation อย่างถูกต้อง
จากการทดสอบโดย Samy เบราว์เซอร์โดยส่วนใหญ่จะสามารถแก้ไขขนาดของแพ็คเกตโดนอัตโนมัติได้หลังจากล้มเหลวสองครั้ง ยกเว้นในกรณีของเบราว์เซอร์อย่าง Firefox ที่มีการใช้ multipart-boundary ซึ่งส่งผลกระทบต่อขนาดของแพ็คเกตที่ออกมา Samy ยืนยันว่าการโจมตีสามารถทำสำเร็จได้ภายใต้การลองปรับขนาดแพ็คเกตไม่ประมาณ 10 ครั้ง
เมื่อการปรับขนาดของแพ็คเกตสมบูรณ์และถูกส่งมาผ่าน NAT โมดูล ALG ใน NAT จะถูกหลอกให้เชื่อว่าผู้ใช้งานกำลังจะพยายามติดต่อไปยังผู้ใช้งานอื่นภายนอกด้วยโปรโตคอล SIP และยินยอมให้แพ็คเกตนั้นผ่านไปยังเซิร์ฟเวอร์ผู้โจมตี ฝั่งเซิร์ฟเวอร์ของผู้โจมตีจะตอบกลับด้วย SIP response ที่ซ่อนอยู่ภายใต้ HTTP response เพื่อให้เบราว์เซอร์ของผู้ใช้งานปลายทางที่รับนั้นไม่ผิดสังเกต หลังจากขั้นตอนนี้แล้ว NAT ซึ่งทำงานอยู่ระหว่างกลางจะทำการเปิดพอร์ตที่ระบุอยู่ในส่วน CONTACT ของแพ็คเกต SIP แรกที่ผู้ใช้งานเป็นผู้ส่งออกมา ส่งผลให้เกิดการฟอร์เวิร์ดพอร์ตที่ผู้โจมตีเลือกไปยังระบบของเหยื่อในเครือข่ายภายในได้ในที่สุด
MITIGATIONS
- หลายเบราว์เซอร์ซึ่งสามารถถูกบังคับให้มีการส่งข้อมูลออกไปยังพอร์ตที่เกี่ยวข้องกับการโจมตีอย่างพอร์ตของโปรโตคอล SIP เริ่มถูกแพตช์เพื่อป้องกันไม่ให้มีการส่งข้อมูลในพอร์ตดังกล่าวแล้ว เช่น ใน Google Chrome รุ่นที่ 87 (อ้างอิง) เช่นเดียวกับ Mozilla Firefox (อ้างอิง) เราขอแนะนำให้ติดตามและอัปเดตแพตช์ทันทีเพื่อลดความเสี่ยงที่จะถูกโจมตีโดยเทคนิค NAT Slipstreaming
- อุปกรณ์เน็ตเวิร์กที่มีความสามารถในการตรวจจับการโจมตีช่องโหว่เริ่มมีการปล่อย signature สำหรับตรวจจับและหยุดการโจมตีแล้ว ขอให้ติดตามการอัปเดต signature และพิจารณาปรับใช้งานตามความเหมาะสม
You must be logged in to post a comment.