samyk/slipstreamNAT स्लिपस्ट्रीमिंग एक हमलावर को पीड़ित मशीन से बंधी किसी भी TCP/UDP सेवाओं तक दूरस्थ रूप से पहुंचने की अनुमति देता है, पीड़ित के NAT/फायरवॉल को बायपास करते हुए, केवल पीड़ित के नेटवर्क पर कोई व्यक्ति किसी वेबसाइट पर जाकर।
NAT Slipstreaming एक हमलावर को पीड़ित के NAT/फ़ायरवॉल को बायपास करते हुए, पीड़ित के NAT के पीछे किसी भी सिस्टम पर बाउंड किसी भी TCP/UDP सेवा तक दूरस्थ रूप से पहुँचने की अनुमति देता है (रिमोट आर्बिट्ररी फ़ायरवॉल पिनहोल कंट्रोल), बस पीड़ित द्वारा किसी वेबसाइट पर विज़िट करने मात्र से।
v1 विकसित किया: @SamyKamkar // https://samy.pl
v2 विकसित किया: Samy Kamkar && (Ben Seri && Gregory Vishnipolsky of Armis)।
यहाँ पढ़ें Ben और Gregory का v2 पर उत्कृष्ट तकनीकी लेख जो v2 के उनके अपडेट में गहराई से जाता है और इसमें बहुत सारे अतिरिक्त विवरण हैं।
v1 रिलीज़ हुआ: 31 अक्टूबर, 2020
v2 रिलीज़ हुआ: 26 जनवरी, 2021
स्रोत कोड: https://github.com/samyk/slipstream
एनिमेटेड संस्करण यहाँ draw.io के मेरे फोर्क से जनरेट किया गया, जो एनिमेशन में एक्सपोर्टेबल एज कॉन्टेक्स्ट फ्लो और कंट्रोल की अनुमति देता है
NAT Slipstreaming उपयोगकर्ता के ब्राउज़र का शोषण करता है, साथ ही NATs, राउटर और फ़ायरवॉल में निर्मित एप्लीकेशन लेवल गेटवे (ALG) कनेक्शन ट्रैकिंग मैकेनिज़्म का उपयोग करता है, जो टाइमिंग अटैक या WebRTC के माध्यम से आंतरिक IP निष्कर्षण, स्वचालित रिमोट MTU और IP फ़्रैग्मेंटेशन डिस्कवरी, TCP पैकेट साइज़ मसाजिंग, TURN प्रमाणीकरण दुरुपयोग, सटीक पैकेट बाउंड्री नियंत्रण, और ब्राउज़र दुरुपयोग के माध्यम से प्रोटोकॉल कन्फ्यूज़न को श्रृंखलाबद्ध करता है। चूँकि NAT या फ़ायरवॉल ही गंतव्य पोर्ट को खोलता है, यह ब्राउज़र-आधारित किसी भी पोर्ट प्रतिबंध को बायपास करता है।
यह हमला कुछ TCP और UDP पैकेटों के डेटा भाग पर बिना HTTP या अन्य हेडर शामिल किए मनमाना नियंत्रण का लाभ उठाता है; हमला सभी प्रमुख आधुनिक (और पुराने) ब्राउज़रों में इस नई पैकेट इंजेक्शन तकनीक को करता है, और यह मेरी मूल 2010 की NAT Pinning तकनीक (DEFCON 18 + Black Hat 2010 में प्रस्तुत) का एक आधुनिक संस्करण है। इसके अतिरिक्त, स्थानीय IP पता डिस्कवरी के लिए नई तकनीकें शामिल हैं।
इस हमले के लिए आवश्यक है कि NAT/फ़ायरवॉल ALG (एप्लीकेशन लेवल गेटवे) का समर्थन करे, जो उन प्रोटोकॉल के लिए अनिवार्य हैं जो कई पोर्ट का उपयोग कर सकते हैं (कंट्रोल चैनल + डेटा चैनल) जैसे SIP और H323 (VoIP प्रोटोकॉल), FTP, IRC DCC, आदि।
उच्च स्तर पर, NAT Slipstreaming इस प्रकार काम करता है:
.local mDNS/Bonjour पता हमले के लिए उपयोगी नहीं होगा)192.168.0.1) के लिए छिपे img टैग पृष्ठभूमि में लोड किए जाते हैंimg टैग से onerror/onsuccess इवेंट जोड़े जाते हैंusername फ़ील्ड से भरे IP फ़्रैग्मेंटेशन को मजबूर किया जा सके
username फ़ील्ड के अंदर भेजा जाता है, जो IP फ़्रैग्मेंटेशन और सटीक बाउंड्री नियंत्रण को मजबूर करता हैusername फ़ील्ड को सटीक TCP सेग्मेंट आकार / पैकेट बाउंड्री में "स्टफ" किया जाता है, फिर “H.323 पैकेट” जोड़ा जाता है और वेब फॉर्म के माध्यम से पोस्ट किया जाता है
हम NAT (नेटवर्क एड्रेस ट्रांसलेशन) का उपयोग कई कारणों से करते हैं। NAT की सबसे उपयोगी विशेषता यह है कि यह एकल सार्वजनिक IP पते को कई सिस्टमों के बीच साझा करने की अनुमति देता है। यह एक स्थानीय नेटवर्क बनाकर, कनेक्ट होने वाली सभी मशीनों को स्थानीय IP पते प्रदान करके ऐसा करता है, और जब उनमें से कोई सिस्टम इंटरनेट तक पहुँचता है, तो यह बाहर जाने वाले पैकेटों को फिर से लिखता है ताकि सार्वजनिक IP का उपयोग किया जा सके, ताकि प्रतिक्रियाएँ NAT पर वापस आएँ, और इसके विपरीत, गंतव्य IP को विशिष्ट क्लाइंट के IP में फिर से लिखना।
यह NAT की ज़िम्मेदारी है कि वह एक ही पते/पोर्ट (google.com:443) पर कनेक्शन को आंतरिक होस्ट से अलग करे, क्योंकि अंततः उनका आउटबाउंड पोर्ट, गंतव्य IP और स्रोत IP सभी समान होंगे। यदि दो अलग-अलग आंतरिक पीयर एक ही स्रोत पोर्ट से कनेक्ट करने का प्रयास करते हैं, तो आधुनिक NAT उनमें से एक स्रोत पोर्ट को बदल देंगे (कुछ नेटवर्क सभी TCP/UDP स्रोत पोर्ट के साथ ऐसा करते हैं)।
Wikipedia ala Wikiwand से:``` One of the important features built on top of the Netfilter framework is connection tracking. Connection tracking allows the kernel to keep track of all logical network connections or sessions, and thereby relate all of the packets which may make up that connection. NAT relies on this information to translate all related packets in the same way, and iptables can use this information to act as a stateful firewall.
यदि आपके NAT के पीछे कोई मशीन एक पैकेट भेजती है और आपका राउटर उम्मीद करता है कि रिमोट होस्ट प्रतिक्रिया दे सकता है, तो वह जानकारी का ट्रैक रखता है, विशेष रूप से स्रोत और गंतव्य पोर्ट, स्रोत और गंतव्य IP पते, और आपका आंतरिक IP, फिर उससे मेल खाने वाले किसी भी पैकेट को आपके आंतरिक IP पर वापस भेजता है।
यदि आपके LAN पर कोई अन्य होस्ट समान स्रोत और गंतव्य पोर्ट + IP के साथ समान कनेक्शन बनाने का प्रयास करता है, तो आपका NAT इसे अलग नहीं कर पाएगा (स्रोत IP आपके LAN पर अलग हैं लेकिन WAN पर एक ही सार्वजनिक IP में बदल दिए जाते हैं), इसलिए यह स्रोत पोर्ट को बदल देता है, लेकिन आपको वापस भेजते समय इसे फिर से लिखता है।
### एप्लीकेशन लेवल गेटवे
ALGs NAT को एक मल्टी-पोर्ट प्रोटोकॉल जैसे FTP को आपके सिस्टम से FTP सर्वर तक जाने के लिए ट्रैक करने की अनुमति देते हैं, फिर जब आप किसी विशिष्ट पोर्ट पर अपने आंतरिक IP पर एक फ़ाइल भेजने का अनुरोध करते हैं, तो ALG पैकेट को आपके सार्वजनिक IP को शामिल करने के लिए पुनः लिख सकता है, फिर FTP सर्वर कनेक्शन को आपके पास वापस भेज सकता है। यदि यह आपके IP को पुनः नहीं लिखता, तो FTP सर्वर आपके आंतरिक IP पर आपसे वापस जुड़ने का प्रयास करेगा (या बिल्कुल प्रयास नहीं करेगा यदि यह अपेक्षा करता है कि स्रोत IP सिग्नलिंग कनेक्शन के समान हो)।
से [विकिपीडिया](https://www.wikiwand.com/en/Application-level_gateway):```
In the context of computer networking, an application-level
gateway consists of a security component that augments a
firewall or NAT employed in a computer network. It allows
customized NAT traversal filters to be plugged into the
gateway to support address and port translation for certain
application layer "control/data" protocols such as FTP,
BitTorrent, SIP, RTSP, file transfer in IM applications, etc.
In order for these protocols to work through NAT or a
firewall, either the application has to know about an address/
port number combination that allows incoming packets, or the
NAT has to monitor the control traffic and open up port
mappings (firewall pinhole) dynamically as required.
Legitimate application data can thus be passed through the
security checks of the firewall or NAT that would have
otherwise restricted the traffic for not meeting its limited
filter criteria.
मैं पहले देखना चाहूँगा कि सामान्य गेटवे वास्तव में पैकेट और FTP, SIP जैसे मल्टी-पोर्ट प्रोटोकॉल को कैसे संभालते हैं। ऐसा करने के लिए, हम सामान्य राउटर के फर्मवेयर को रिवर्स इंजीनियर करना चाहेंगे। हम भौतिक राउटर से फ्लैश डंप कर सकते हैं, हालांकि अगर हम निर्माताओं से अनएन्क्रिप्टेड फर्मवेयर प्राप्त कर सकते हैं, तो हम अधिक राउटर मॉडलों की और बहुत तेज़ी से जांच कर पाएंगे।
हम एक सामान्य राउटर, Netgear Nighthawk R7000 से शुरुआत करेंगे। एक त्वरित खोज हमें हालिया फर्मवेयर वाला Netgear लेख ढूंढने में मदद करती है। एक बार जब हम फर्मवेयर डाउनलोड करके अनज़िप करते हैं, तो हमें R7000-V1.0.9.64_10.2.64.chk नामक 30MB की फ़ाइल मिलती है।```sh tigerblood:~c/ng$ wget http://www.downloads.netgear.com/files/GDC/R7000/R7000-V1.0.9.64_10.2.64.zip --2019-05-19 19:21:13-- http://www.downloads.netgear.com/files/GDC/R7000/R7000-V1.0.9.64_10.2.64.zip Resolving www.downloads.netgear.com (www.downloads.netgear.com)... 104.69.65.243 Connecting to www.downloads.netgear.com (www.downloads.netgear.com)|104.69.65.243|:80... connected. HTTP request sent, awaiting response... 200 OK Length: 31705064 (30M) [application/zip] Saving to: ‘R7000-V1.0.9.64_10.2.64.zip’
R7000-V1.0.9.64_10.2.64.zip 100%[=============================================>] 30.24M 6.25MB/s in 11s
2019-05-19 19:21:24 (2.83 MB/s) - ‘R7000-V1.0.9.64_10.2.64.zip’ saved [31705064/31705064]
tigerblood:~c/ng$ unzip R7000-V1.0.9.64_10.2.64.zip Archive: R7000-V1.0.9.64_10.2.64.zip extracting: R7000-V1.0.9.64_10.2.64.chk inflating: R7000-V1.0.9.64_10.2.64_Release_Notes.html tigerblood:~c/ng$ file R7000-V1.0.9.64_10.2.64.chk R7000-V1.0.9.64_10.2.64.chk: data tigerblood:~c/ng$ ls -lh R7000-V1.0.9.64_10.2.64.chk -rw-r--r-- 1 samy staff 30M Mar 26 11:46 R7000-V1.0.9.64_10.2.64.chk
`file` कमांड किसी भी [magic info](https://www.wikiwand.com/en/Magic_number_(programming)) का पता नहीं लगाता, इसलिए हम फ़ाइल में नेस्टेड डेटा को स्कैन करने के लिए [`binwalk`](https://github.com/ReFirmLabs/binwalk) का उपयोग कर सकते हैं।```sh
tigerblood:~c/ng$ binwalk R7000-V1.0.9.64_10.2.64.chk
DECIMAL HEXADECIMAL DESCRIPTION
--------------------------------------------------------------------------------
58 0x3A TRX firmware header, little endian, image size: 31703040 bytes, CRC32: 0xBEF1BB2F, flags: 0x0, version: 1, header size: 28 bytes, loader offset: 0x1C, linux kernel offset: 0x21E3F0, rootfs offset: 0x0
86 0x56 LZMA compressed data, properties: 0x5D, dictionary size: 65536 bytes, uncompressed size: 5436416 bytes
2221098 0x21E42A Squashfs filesystem, little endian, version 4.0, compression:xz, size: 29475437 bytes, 1988 inodes, blocksize: 131072 bytes, created: 2018-12-26 04:15:38
मैं macOS का उपयोग करता हूँ और binwalk बॉक्स से बाहर कुछ Linux ऐप्स पर निर्भर करता है जिसके कारण binwalk -e (जो फ़ाइलें निकालता है) विफल हो जाता है, इसलिए मैं मैन्युअल रूप से निकालता हूँ (और मुझे perl गोल्फ पसंद है)।```sh
tigerblood:~c/ng$ perl -ne'$@.=$_}{print+substr$@,2221098' R7000-V1.0.9.64_10.2.64.chk > squash.fs
या [`inout`](https://github.com/samyk/samytools/blob/master/inout) का उपयोग करें, उदा. `inout R7000-V1.0.9.64_10.2.64.chk 2221098`।
आप `dd` का उपयोग कर सकते हैं, हालांकि आप एक बड़ा `bs` (ब्लॉक आकार) चाहेंगे ताकि यह तेजी से आउटपुट दे, उदा. 1024, हालांकि `skip` विशेषता (जो इसे squashfs ब्लॉब के स्थान से शुरू करने का निर्देश देती है) ब्लॉक आकार का सम्मान करेगी और 2221098 स्पष्ट रूप से 2 के अलावा किसी और चीज़ से विभाज्य नहीं है जो मेरे दिमाग में जल्दी आता है...अब मैं उत्सुक हूं।```sh
tigerblood:~c/ng$ time dd if=R7000-V1.0.9.64_10.2.64.chk skip=$((2221098/2)) bs=2 of=squash.fs2
14741000+0 records in
14741000+0 records out
29482000 bytes transferred in 78.363403 secs (376222 bytes/sec)
real 1m18.385s
user 0m12.553s
sys 1m4.451s
अब स्क्वैश फाइलसिस्टम को अनपैक करते हैं। मैंने squashfs-tools का एक फोर्क का फोर्क बनाया है जो macOS पर चलता है और lzo सपोर्ट रखता है। आपको xz और lzo भी इंस्टॉल करने की आवश्यकता हो सकती है। वैकल्पिक रूप से, आप Linux पर sasquatch का उपयोग कर सकते हैं।```sh
tigerblood:~c/ng$ sudo port install xz lzo
...
tigerblood:~c/ng$ git clone https://github.com/samyk/squashfs-tools && cd squashfs-tools/squashfs-tools && make && sudo make install && cd ../..
और अंत में हम squash fs को अनपैक कर सकते हैं।```sh
tigerblood:~c/ng$ unsquashfs -l -no squash.fs
Parallel unsquashfs: Using 8 processors
1881 inodes (2535 blocks) to write
squashfs-root
squashfs-root/bin
squashfs-root/bin/addgroup
... (many more files) ...
tigerblood:~c/ng$ cd squashfs-root && ls
bin data dev etc lib media mnt opt proc sbin share sys tmp usr var www
अब हमारे पास अन्वेषण करने के लिए कच्चा OS है!
अब देखते हैं कि क्या हम FTP से संबंधित कोई फ़ाइलें ढूँढ सकते हैं, क्योंकि यह एक भारी उपयोग किया जाने वाला प्रोटोकॉल था, इसलिए ALG समर्थन राउटर्स में व्यापक होगा। मैं अपने g tool का उपयोग करता हूँ जो egrep के चारों ओर एक सुविधाजनक रैपर है।```sh
tigerblood:~c/ng/squashfs-root$ find . | g ftp
./usr/bin/tftp
./usr/sbin/bftpd
./usr/sbin/ftp
./usr/sbin/ftpc
./usr/etc/sftp-ssh.service
कुछ भी दिलचस्प नहीं है, तो चलिए उन बाइनरी फ़ाइलों के लिए `g` करते हैं जिनकी सामग्री /ftp/ से मेल खाती है, कुछ ऐसी फ़ाइलों को अनदेखा करते हुए जिनकी हमें परवाह नहीं है।```sh
tigerblood:~c/ng/squashfs-root$ g -la ftp -v '\.(html?|js|gif)$|www/|bin/'
lib/libsmbd-base-samba4.so
lib/libavformat.so.55
lib/libavutil.so.52
lib/libavcodec.so.55
lib/modules/tdts.ko
lib/modules/2.6.36.4brcmarm+/kernel/lib/br_dns_hijack.ko
lib/libcrypto.so.1.0.0
opt/xagent/certs/ca-bundle-mega.crt
usr/etc/sftp-ssh.service
usr/lib/libnvram.so
usr/lib/libcurl.a
usr/lib/libcurl.so.4.3.0
usr/lib/libcurl.so
usr/share/avahi/service-types
usr/share/libcrypto.so.1.0.0
g डिफ़ॉल्ट रूप से वर्तमान कार्यशील निर्देशिका को पुनरावर्ती रूप से स्कैन करता है। -l केवल फ़ाइल नाम प्रिंट करने के लिए है (क्योंकि ये अधिकतर बाइनरी होंगी), -a बाइनरी फ़ाइलों को स्कैन करने के लिए, ftp मिलान करने के लिए टेक्स्ट, और -v '\.(html?|js|gif)$|www/|bin/' वेब फ़ाइलों और निष्पादन योग्य फ़ाइलों (जो (s)bin/ में हैं) को अनदेखा करने के लिए।
कोई भी lib/lib*.{a,so}{.*,} (bash format) फ़ाइलें रुचिकर नहीं हैं, तो चलिए कम के साथ फिर से स्कैन करें:```sh
tigerblood:~c/ng/squashfs-root$ g -la ftp -v '.(html?|js|gif)$|www/|bin/|lib.*.(so|a)(.|$)'
lib/modules/tdts.ko
lib/modules/2.6.36.4brcmarm+/kernel/lib/br_dns_hijack.ko
opt/xagent/certs/ca-bundle-mega.crt
usr/etc/sftp-ssh.service
usr/share/avahi/service-types
### संभावित उपयोगी फ़ंक्शनों की खोज
ठीक है, दो रुचिकर फ़ाइलें -- `lib/modules/tdts.ko` संबंधित हो सकती है, और `lib/modules/2.6.36.4brcmarm+/kernel/lib/br_dns_hijack.ko` शायद संबंधित नहीं है लेकिन दिलचस्प लगती है! बाद में इसकी जांच कर सकता हूँ।```sh
tigerblood:~c/ng/squashfs-root$ file lib/modules/tdts.ko
lib/modules/tdts.ko: ELF 32-bit LSB relocatable, ARM, EABI5 version 1 (SYSV), BuildID[sha1]=0aa35748e245e60273ceb5a48641e424d069235b, not stripped
tigerblood:~c/ng/squashfs-root$ strings lib/modules/tdts.ko | g ftp
ftp_decoder_open
ftp_decoder_close
ftp_decode_epsv_resp
ftp_decode_eprt_cmd
ftp_decode_pasv_resp
ftp_decode
ftp_decode_port_cmd
ftp_decoder
check_ftp_ft_rule
बढ़िया! एक कर्नेल ऑब्जेक्ट (.ko) जिसमें ftp फ़ंक्शन हैं, और "port" जैसे शब्दों के साथ, यह संभवतः एक FTP ALG से संबंधित है। FTP RFC 959 PORT कमांड के अर्थ की व्याख्या करता है:```
DATA PORT (PORT)
The argument is a HOST-PORT specification for the data port to be used in data connection. There are defaults for both the user and server data ports, and under normal circumstances this command and its reply are not needed. If this command is used, the argument is the concatenation of a 32-bit internet host address and a 16-bit TCP port address. This address information is broken into 8-bit fields and the value of each field is transmitted as a decimal number (in character string representation). The fields are separated by commas. A port command would be: PORT h1,h2,h3,h4,p1,p2 where h1 is the high order 8 bits of the internet host address.
### जाँच करने योग्य पोर्ट / सेवाएँ
हालाँकि हमें कुछ FTP फ़ंक्शन मिले हैं, हम उन पोर्ट्स में अधिक रुचि रखते हैं जिनका हम उपयोग कर सकते हैं। आधुनिक ब्राउज़र कई [प्रतिबंधित पोर्ट्स](https://github.com/samyk/chromium/blob/2d57e5b8afc6d01b344a8d95d3470d46b35845c5/net/base/port_util.cc#L20-L90) पर आउटबाउंड HTTP(S) कनेक्शन को रोकते हैं, जिनमें FTP भी शामिल है, इसलिए FTP ALG का दुरुपयोग संभवतः संभव नहीं है।
2010 में, जब मैंने पहली बार [NAT Pinning का प्रदर्शन किया](https://samy.pl/natpin/), तब मैंने DCC CHAT/FILE संदेशों के माध्यम से पोर्ट 6667 (IRC) का उपयोग किया। जल्द ही, ब्राउज़र विक्रेताओं ने पोर्ट 6667 को ब्लॉक कर दिया...हालाँकि कुछ ने पोर्ट को संग्रहीत करने के लिए uint32 (32 बिट अहस्ताक्षरित पूर्णांक) का उपयोग किया, जाँच की कि क्या पोर्ट ब्लॉक था, और यदि नहीं, तो कनेक्ट किया।
इससे बचने के लिए, यह ध्यान रखना महत्वपूर्ण है कि TCP पोर्ट 16 बिट लंबे होते हैं, इसलिए यदि आप चुने हुए 'प्रतिबंधित' पोर्ट में 2**16 (65536) जोड़ते हैं, इस मामले में 65536+6667=72203, ब्राउज़र 72203 संग्रहीत करेगा, यह पोर्ट प्रतिबंध पास करेगा (72203 != 6667), फिर TCP स्टैक पर भेज दिया जाएगा जहाँ इसे 16 बिट पर छोटा किया जाएगा, जो कि वह प्रतिबंधित पोर्ट है जो हम चाहते थे!
मेरा सरल [`base calculator, 3`](https://github.com/samyk/samytools/blob/master/3) यह दिखाता है (db = dec -> bin):```sh
tigerblood:/Users/samy/d$ 3 db 65536 6667 65536+6667
000000010000000000000000
000000000001101000001011
000000010001101000001011
我们使用我的diffbits工具可以更好地看到它，这是一个简单的工具，用于查看位字符串之间的相似性和差异，以及多个位字符串组之间的相似性和差异，对逆向专有二进制协议很有用。
आगे बढ़ें और अपनी पसंद का डिसअसेंबलर खोलें। मैंने NSA के हमारे दोस्तों से Ghidra का उपयोग किया है क्योंकि यह मुफ्त और ओपन सोर्स है।
हमने tdts.ko में strings के माध्यम से जो फंक्शन देखे, वे ftp_decode और ftp_decoder थे, इसलिए संभव है कि अन्य ALG में _decode फंक्शन हो। चलो देखते हैं...
ठीक है, बहुत सारे _decode फंक्शन हैं... नीचे स्क्रॉल करने पर, एक दिलचस्प sip_decode है।
हमारे प्रतिबंधित ब्राउज़र पोर्ट्स की जांच करने पर, हम देखते हैं कि 5060, डिफ़ॉल्ट SIP पोर्ट, Chrome में प्रतिबंधित नहीं है :)
SIP TCP/UDP 5060 पर रहता है, लेकिन RTP (ऑडियो) जैसे मीडिया को फ्लाई पर उत्पन्न वैकल्पिक पोर्ट पर भेजा जाता है। SIP कॉल के लिए अनुरोध भेजते समय, आपका SIP क्लाइंट एक यादृच्छिक पोर्ट चुनता है, उसे खोलता है, और SIP हेडर में शामिल करता है। आपके NAT को भी इसे देखना चाहिए और इसे खोलना चाहिए, यह मानते हुए कि SIP ALG सक्षम है (और अधिकांश राउटर्स पर डिफ़ॉल्ट रूप से चालू रहता है)।
यह मानते हुए कि NATs SIP पैकेट्स को लाइन दर लाइन पढ़ते हैं (SIP HTTP की तरह न्यूलाइन-आधारित है और बाइनरी प्रोटोकॉल नहीं है), शायद यह HTTP हेडर को अनदेखा करेगा और एक बार POST डेटा पर पहुंचने पर, REGISTER को पढ़कर मान लेगा कि यह SIP पैकेट है। यह IRC DCC के लिए हमारे 2010 संस्करण में काम कर गया था। NAT ने HTTP हेडर को अनदेखा किया और सिर्फ IRC DCC कमांड को पार्स किया।
मजेदार बात यह है कि इसने हमें वास्तव में हमारी साइट पर आने वाले उपयोगकर्ताओं को एक वैध IRC सर्वर से कनेक्ट करने, एक चैनल में शामिल होने, और उनके आईपी से उनकी जानकारी के बिना एक संदेश भेजने की अनुमति दी! :P मैंने इस तकनीक को ब्राउज़रों द्वारा पोर्ट 25 को ब्लॉक करने से पहले और SPF रिकॉर्ड के सामान्य होने से पहले क्लाइंट आईपी पतों के साथ मेल सर्वर को ईमेल भेजने के लिए डेमो किया था... पागलपन।
अब, एक त्वरित परीक्षण में, HTTP POST के माध्यम से पोर्ट 5060 पर SIP REGISTER पैकेट भेजना काम नहीं करता है... शायद हम पैकेट से कुछ गायब कर रहे हैं।```javascript // our sip message var sipmsg = 'REGISTER sip:samy.pl;transport=TCP SIP/2.0\r\n' + 'Contact: sip:[email protected]:1234;transport=TCP\r\n\r\n'
// load form in an iframe so user doesn't see it var iframe = document.createElement('iframe') iframe.name = 'iframe' iframe.style.display = 'none' // hide the iframe
// create form var form = document.createElement('form') form.setAttribute('target', 'iframe') // load into iframe form.setAttribute('method', 'POST') // need the POST area where we can add CRLFs form.setAttribute('action', 'http://samy.pl:5060') // "http" server on SIP port 5060 form.setAttribute('enctype', 'multipart/form-data') // ensure our data doesn't get encoded
var textarea = document.createElement('textarea') textarea.setAttribute('name', 'textname') // required textarea.innerHTML = sipmsg form.appendChild(textarea) document.body.appendChild(iframe) document.body.appendChild(form) form.submit()
यदि हम स्निफ करते हैं, तो हम देखते हैं ([`h2b`](https://github.com/samyk/samytools/blob/master/h2b) द्वारा पार्स किया गया):```sh
$ unbuffer tcpdump -X port 5060 | h2b
POST / HTTP/1.1
Host: samy.pl:5060
Connection: keep-alive
Content-Length: 191
Cache-Control: max-age=0
Origin: http://samy.pl
Upgrade-Insecure-Requests: 1
Content-Type: multipart/form-data; boundary=----WebKitFormBoundaryhcoAd2iSAx3TJA7A
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_14_4) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/75.0.3770.66 Safari/537.36
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3
Referer: http://samy.pl/o/sp.html
Accept-Encoding: gzip, deflate
Accept-Language: en-US,en;q=0.9
------WebKitFormBoundaryhcoAd2iSAx3TJA7A
Content-Disposition: form-data; name="textname"
REGISTER sip:samy.pl;transport=TCP SIP/2.0
Contact: <sip:[email protected]:1234;transport=TCP>
------WebKitFormBoundaryhcoAd2iSAx3TJA7A--
हालांकि, इससे पोर्ट नहीं खुलता, और न ही IP को पुनः लिखा जाता है जैसा कि हम उम्मीद करते हैं (इस पर बाद में और अधिक), इसलिए हम कुछ याद कर रहे होंगे।
आइए कर्नेल ऑब्जेक्ट में खोदाई जारी रखें। डिसअसेंबली में, हम एक SIP पैकेट से "SIP/2.0" टैग देखते हैं, इसलिए संभवतः यह यहाँ पार्स हो रहा है (जो "decode" की तरह लगता है)।
आह, यही कारण है कि हम असफल होते हैं। ऐसा लगता है कि यह INVITE पर strncasecmp चला रहा है (REGISTER पर समान पार्सिंग) -- पैकेट की शुरुआत में 'INVITE' शब्द का मिलान (केस-असंवेदनशील, जो दिलचस्प है क्योंकि SIP INVITEs अपर केस होते हैं) करता है और यदि शब्द मेल नहीं खाते तो branches if not equal (ARM असेंबली bne) 0 पर जाता है, इसलिए यदि शब्द मेल खाते हैं, तो शब्दकोश क्रम 0 होगा और हम ct_sip_get_header पर जारी रखेंगे जो मजेदार लगता है, और अन्यथा बाहर निकलता प्रतीत होता है।
यही समस्या है... जबकि हम आउटबाउंड सॉकेट उत्पन्न करने के लिए वेब ब्राउज़र का उपयोग कर सकते हैं (TCP via HTTP(S), UDP via TURN w/WebRTC), हमारे पास ब्राउज़र पर पर्याप्त नियंत्रण नहीं है कि TCP डेटा भाग की शुरुआत 'INVITE' शब्द से कर सकें, जैसा कि यह मॉड्यूल अपेक्षा करता है। 2010 IRC संस्करण में, IRC ALG केवल पंक्ति दर पंक्ति देखता था, सभी HTTP हेडर डेटा को अनदेखा करता था, फिर POST डेटा में न्यूलाइन का उपयोग करके एक मान्य 'IRC DCC' भेजता था। हालाँकि, यह SIP ALG बहुत अधिक सख्त है और अनुरोध की शुरुआत को नियंत्रित करना संभव नहीं है। यदि TLS का उपयोग कर रहे हैं, तो एन्क्रिप्टेड हेडर पैकेट की शुरुआत करेगा। यदि HTTP का उपयोग कर रहे हैं, तो HTTP विधि पैकेट की शुरुआत करेगी (GET, POST, आदि)। क्या हम किसी अन्य तरीके से इसका शोषण कर सकते हैं?
कनेक्शन ट्रैकिंग और एप्लिकेशन स्तर गेटवे को बेहतर ढंग से समझने के लिए, हम देख सकते हैं कि वे netfilter, Linux's network stack में कैसे व्यवहार करते हैं। मैंने Linux स्रोत को पार्स करने के आधार पर सबसे सामान्य ALGs और वे कैसे व्यवहार करते हैं, इसका एक चार्ट बनाया है।
इस चार्ट से, सबसे दिलचस्प (जिन्हें Chrome ब्लॉक नहीं करता) हैं sane (backup), sip (voip), pptp (vpn), और h323 (voip)। हम SIP चुनेंगे क्योंकि यह इन प्रोटोकॉल में से अधिक सर्वव्यापी है, और हम इसे पहले से ही कुछ राउटर के फर्मवेयर में देखते हैं।
Linux विशेष रूप से प्रति प्रोटोकॉल आधार पर कनेक्शन ट्रैकिंग को संभालने के लिए nf_conntrack_*.c फ़ाइलें रखता है, और पैकेट मैंगलिंग (संशोधन) के लिए nf_nat_*.c फ़ाइलें रखता है।
हम SIP कनेक्शन ट्रैकिंग मॉड्यूल पर एक त्वरित नज़र डालेंगे
module_init(nf_conntrack_sip_init) इस कनेक्शन ट्रैकर को आरंभ करता है, nf_conntrack_sip_init को कॉल करता हैnf_ct_helper_init(...AF_INET, IPPROTO_TCP, "sip", SIP_PORT...) हम उम्मीद करते हैं कि सिग्नलिंग IPv4 AF_INET TCP IPPROTO_TCP पोर्ट 5060 SIP_PORT से आए...यह UDP, TCP, IPv4 और IPv6 के लिए होता हैsip_help_tcp(...) जब मेल खाने वाला TCP SIP पैकेट आता है तो कॉल किया जाता है
process_sip_msg(...) यदि यह एक संभावित SIP पैकेट जैसा दिखता है
process_sip_request(...) यदि यह एक अनुरोध हैstrncasecmp(*dptr, handler->method, ...) हैंडलर तब तक बाहर निकलेगा जब तक विधि (जैसे, REGISTER) पैकेट के डेटा भाग की शुरुआत में न हो (TCP या UDP) जैसा कि हमने ऊपर INVITE के साथ देखा...REGISTER बस एक और SIP कमांड हैprocess_register_request(...)nf_ct_expect_init(...) sip_handlers के माध्यम से हम फ़ायरवॉल पिनहोल (दूरस्थ व्यक्ति को वापस कनेक्ट करने की अनुमति देने के लिए पोर्ट) आरंभ करते हैं, लेकिन हम इसे अभी तक नहीं खोलतेnf_nat_sip_hooks -> nf_nat_sip(...) NAT क्लाइंट के आंतरिक IP पते को NAT के सार्वजनिक IP में बदलता (पुनः लिखता) है ताकि गंतव्य ठीक से उस तक पहुँच सकेsip_help_tcp(...) -> process_sip_msg(...) ->
process_sip_response(...) अब हम SIP सर्वर से SIP प्रतिक्रिया देख रहे हैं
process_register_response(...) -> refresh_signalling_expectation(...) NAT द्वारा पोर्ट तभी फॉरवर्ड किया जाता है जब SIP सर्वर द्वारा एक मान्य SIP प्रतिक्रिया भेजी जाती हैजहाँ तक हम जानते हैं, हम ब्राउज़र को अपनी इच्छानुसार ट्रैफ़िक के साथ आउटबाउंड TCP कनेक्शन बनाने के लिए बाध्य नहीं कर सकते, और हमारे लिए REGISTER या INVITE जैसी SIP विधि से शुरू होने वाला TCP/UDP पैकेट बनाना आवश्यक है।
Flash पहले आउटबाउंड सॉकेट की अनुमति देता था, लेकिन एक प्रारूप में था जिस पर हमारा पूर्ण नियंत्रण नहीं था। Java को अनुमति की आवश्यकता होती है। WebSockets अभी भी HTTP हैं। TLS एन्क्रिप्टेड है। WebRTC (RFC 7742) एन्क्रिप्टेड है। STUN (RFC 3489) और TURN (RFC 5766) निश्चित प्रारूपों में हैं, और TURNS (RFC 7065) एन्क्रिप्टेड है।
उच्च स्तर पर, हम TCP पैकेट की शुरुआत को नियंत्रित नहीं कर सकते, लेकिन क्या होगा यदि हम बहुत बड़ा पैकेट भेजें? एक अधिकतम पैकेट आकार होना चाहिए...जिस बिंदु पर, एक पैकेट को कई पैकेटों में विखंडित किया जाना चाहिए। यदि हम TCP पैकेट के आकार को ओवरफ्लो कर सकते हैं और डेटा के एक हिस्से को सटीक रूप से नियंत्रित कर सकते हैं, तो क्या हम पैकेट विभाजन का कारण बन सकते हैं और हमारा डेटा हमारे अगले, ओवरफ्लो किए गए पैकेट की शुरुआत में हो सकता है?
ठीक है, हमें यह जानना होगा कि ब्राउज़र कितना डेटा भेजेगा, जो प्रति ब्राउज़र भिन्न होगा, और यहां तक कि उपयोगकर्ता के अनुसार भी क्योंकि वे अलग-अलग HTTP हेडर भेज सकते हैं। HTTPS काम नहीं करेगा क्योंकि अधिकांश सामग्री एन्क्रिप्टेड है, जबकि एक HTTP POST हमें हेडर के एक बड़े हिस्से को नियंत्रित करने की अनुमति देता है।
पैकेट का सामान्य आकार प्राप्त करने के लिए, हम एक बड़ा (6000 बाइट) HTTP POST एक आईडी और पैडिंग डेटा के साथ एक छिपे हुए वेब फॉर्म के माध्यम से http://our.attack.server:5060/pktsize पर भेजते हैं। हमले के सर्वर पर, हम एक पैकेट स्निफ़र चलाते हैं जो हमारे पैकेट की सीमाओं की तलाश करता है ताकि MTU (अधिकतम संचरण इकाई) आकार, IP हेडर आकार, संभावित IP विकल्प, TCP हेडर आकार, संभावित TCP विकल्प, डेटा पैकेट आकार, और पैकेट का कौन सा भाग हम नियंत्रित करते हैं, निर्धारित किया जा सके।
हम एक कस्टम सर्वर भी चलाते हैं जो TCP पोर्ट 5060 पर सुनता है, और ब्राउज़र को संतुष्ट करने के लिए HTTP ट्रैफ़िक के साथ प्रतिक्रिया करता है ताकि क्लाइंट पक्ष पर कुछ भी संदिग्ध न दिखे (एक गलत प्रतिक्रिया वाला सर्वर कंसोल में त्रुटियाँ उत्पन्न करेगा, या गलत प्रतिक्रिया देने वाला सर्वर स्थिति स्पिनर को चालू रखेगा)।
हम आगे प्रारंभिक SYN प्रतिक्रिया के दौरान एक अधिकतम खंड आकार (mss) TCP विकल्प भेजकर पीड़ित के आउटबाउंड पैकेट आकारों में हेरफेर करने का प्रयास करते हैं (RFC 793 x3.1)। यह पीड़ित मशीन को TCP पैकेट को एक निश्चित आकार में रखने का निर्देश देता है।
आप Linux पर ip route में advmss <size> जोड़कर ऐसा कर सकते हैं। हम 1500 का उपयोग करेंगे।```sh
ip route replace default via [gateway] dev eth0 advmss 1500
एक बार जब हमें पैकेट मिल जाते हैं, तो हम आकार डेटा को एक अलग POST के माध्यम से पीड़ित क्लाइंट को वापस भेजते हैं, जिसने पीड़ित की ID भेजी थी ताकि हम इसे पीड़ित से मूल अनुरोध के साथ सहसंबंधित कर सकें। इस बिंदु पर, क्लाइंट को अच्छा अंदाजा हो जाता है कि कैसे पैकेट को पैड करना है ताकि मनमाना डेटा TCP पैकेट में किसी विशिष्ट स्थान पर पहुंचे।
### UDP और TURN के साथ IP फ्रैग्मेंटेशन
कुछ NAT केवल UDP पोर्ट्स को एक्सेस करने की अनुमति देते हैं यदि SIP कनेक्शन मूल रूप से UDP था, इसलिए हम इस मामले में TURN का उपयोग करते हैं। TURN एक प्रोटोकॉल है जो SIP और WebRTC जैसे पीयर-टू-पीयर संचार के लिए रिलेइंग का समर्थन करता है। TURN UDP है जबकि TURNS (TURN+TLS) TCP है। आधुनिक ब्राउज़र WebRTC के लिए TURN का समर्थन करते हैं यदि वे मीडिया साझाकरण के लिए एक-दूसरे के साथ सीधा पीयर-टू-पीयर कनेक्शन नहीं बना सकते।
TURN उपयोगकर्ता नाम और पासवर्ड के माध्यम से प्रमाणीकरण की अनुमति देता है, उपयोगकर्ता नाम क्लियरटेक्स्ट में भेजा जाता है। दिलचस्प बात यह है कि उपयोगकर्ता नाम किसी भी आकार या वर्णों द्वारा सीमित नहीं है, इसलिए हम इसका उपयोग उसी प्रकार के पैकेट ओवरफ्लो को करने के लिए कर सकते हैं।
चूंकि TURN UDP पर है, IP पैकेट स्वयं MTU आकार से अधिक होने पर विखंडित हो जाएगा (UDP सेगमेंटेशन का समर्थन नहीं करता)। दूसरे पैकेट में न केवल डेटा भाग हमारे नियंत्रण में होगा, बल्कि UDP हेडर भी! यह हमारे हमले के लिए महत्वपूर्ण नहीं है, लेकिन दिलचस्प है और निश्चित रूप से वैकल्पिक हमले उत्पन्न कर सकता है। अंततः हम MSS आकार के बजाय गणना किए गए MTU आकार के आधार पर अपने पैकेट सीमा को संरेखित करके UDP के माध्यम से वही हमला कर सकते हैं, जिससे हमारा SIP UDP पैकेट दूसरे पैकेट सीमा पर रहता है (एक नकली UDP हेडर के साथ) जो हमें UDP पोर्ट्स को वापस अपने पीड़ित को अग्रेषित करने की अनुमति देता है।
## TCP टाइमिंग अटैक / आंतरिक सबनेट और IP डिस्कवरी
ओह, यह अभी भी काम नहीं करेगा! ALG के लिए इसे एक वैध SIP पैकेट के रूप में व्यवहार करने के लिए, जिस IP पते पर आप डेटा वापस आने का अनुरोध कर रहे हैं ([`Contact`](https://tools.ietf.org/html/rfc2543#section-6.13) SIP लाइन में) वह आंतरिक IP (पीड़ित) होना चाहिए जहां से SIP पैकेट आया था, जो हम नहीं जानते। केवल राउटर का सार्वजनिक IP पता ही हमारे सर्वर तक प्रेषित होता है (क्योंकि NAT स्रोत IP को फिर से लिखता है जब वह सार्वजनिक पक्ष से बाहर निकलता है)।
हम यह जांच Linux के `nf_conntrack_sip.c` के [process\_sip\_request](https://github.com/samyk/linux/blob/ea2cec24c8d429ee6f99040e4eb6c7ad627fe777/net/netfilter/nf_conntrack_sip.c#L1260) में देखते हैं:
[2010](https://samy.pl/natpin/) में, हमने [LiveConnect](https://developer.mozilla.org/en-US/docs/Archive/Web/LiveConnect) का उपयोग किया जो कुछ शर्तों के तहत Javascript से Java कोड निष्पादित करने की अनुमति देता था, उपयोगकर्ता का स्थानीय IP निकालता था। वह काफी जल्दी अप्रचलित हो गया।
कुछ ब्राउज़रों (Chrome, Firefox) पर, हम [WebRTC](https://www.w3.org/TR/webrtc/) का उपयोग करके [ICE](https://tools.ietf.org/html/rfc5245) के माध्यम से पीड़ित का आंतरिक IP पता प्राप्त कर सकते हैं (जो केवल STUN/TURN/TURNS का उपयोग करता है)। ये प्रोटोकॉल NAT के पीछे पीयर्स को अपने बारे में जानकारी निर्धारित करने में मदद करने के लिए हैं। विडंबना यह है कि ICE "अनुरोध" में किसी सर्वर का उपयोग करने की आवश्यकता नहीं है क्योंकि ब्राउज़र पहले से ही अपने आंतरिक IP को जानता है, और एक दूरस्थ STUN/TURN सर्वर इसे वैसे भी नहीं जान सकता जब तक कि क्लाइंट पहले स्थान पर इसे न भेजे। समस्या यह है कि सभी ब्राउज़र यह तंत्र प्रदान नहीं करते हैं।
आज के अनुसार, Chrome पर `.local` mDNS/Bonjour पते के बजाय स्थानीय IP पता प्राप्त करने के लिए WebRTC का उपयोग करने के लिए HTTPS की आवश्यकता होती है, लेकिन शेष हमलों के लिए HTTP आवश्यक है, इसलिए हम पहले पता लगाते हैं कि हम HTTP पर हैं या नहीं, और यदि नहीं, तो HTTPS पर रीडायरेक्ट करते हैं। फिर हम स्थानीय IP पता निकालने के लिए WebRTC का उपयोग करने का प्रयास करते हैं। किसी भी स्थिति में, हम फिर HTTP पर वापस रीडायरेक्ट करते हैं जिसमें IP(s) URL में जोड़ा जाता है ताकि अन्य संचार विधियों के माध्यम से क्रॉस-ओरिजिन प्रतिबंधों को बायपास किया जा सके।
### टाइमिंग अटैक
यदि Safari, IE <= 11, या अन्य का उपयोग कर रहे हैं जो WebRTC का समर्थन नहीं करते हैं या जानबूझकर आंतरिक IP प्रकट नहीं करते (Safari), तो हम पीड़ित के आंतरिक IP पते को प्रकट करने के लिए वेब टाइमिंग अटैक का उपयोग कर सकते हैं।
हम इसे पहले पृष्ठ पर छिपे हुए HTML `` टैग उत्पन्न करके प्रबंधित करते हैं, सभी सामान्य गेटवे (192.168.*.1, 10.0.0.1, और [अन्य](https://github.com/samyk/slipstream/blob/main/server#L159)) पर, Javascript `onsuccess` और `onerror` ईवेंट के साथ। हर बार जब कोई img पृष्ठ पर लिखा जाता है, एक टाइमर शुरू होता है और यदि `onsuccess` लोड होता है, तो इसका मतलब है कि IP ने वेब सर्वर के साथ प्रतिक्रिया दी, और यदि कोई वेब सर्वर नहीं चल रहा है लेकिन IP नेटवर्क पर है, तो यह TCP RST (रीसेट, मतलब पोर्ट खुला नहीं) वापस भेजेगा, जिससे `onerror` ट्रिगर होगा। यदि कोई IP मौजूद नहीं है, तो कोई RST नहीं भेजा जाता है और प्रतिक्रिया > 1 सेकंड लेगी, जिस बिंदु पर हम जानते हैं कि IP हमारे नेटवर्क पर मौजूद नहीं है।
एक बार जब हम इनमें से किसी एक ईवेंट को ट्रिगर होते देखते हैं, तो हम एक संभावित आंतरिक सबनेट को जान जाते हैं जिस पर हम हैं, फिर हम सबनेट पर प्रत्येक IP के लिए वही हमला करते हैं (उदाहरण, 192.168.0.[2-255]), और इस बार अधिक सटीक टाइमिंग करते हैं ताकि यह निर्धारित किया जा सके कि कौन सा IP **सबसे तेज़** प्रतिक्रिया देता है। यह संभवतः हमारा अपना (पीड़ित) आंतरिक IP है, क्योंकि हमें नेटवर्क इंटरफ़ेस छोड़ने की भी आवश्यकता नहीं है। भले ही हम किसी कारण से पहले न हों, फिर भी हम नेटवर्क पर प्रतिक्रिया देने वाले सभी IPs पर अपना हमला आज़माते हैं।
## ब्राउज़र प्रोटोकॉल कन्फ्यूज़न
एक बार जब क्लाइंट को पैकेट आकार और आंतरिक IP पता मिल जाता है, तो यह एक विशेष रूप से तैयार किया गया वेब फॉर्म बनाता है जो POST डेटा को तब तक पैड करता है जब तक हमें विश्वास नहीं हो जाता कि पैकेट विखंडित हो जाएगा, उस बिंदु पर हमारा SIP REGISTER जिसमें आंतरिक IP पता होता है, जोड़ दिया जाता है। फॉर्म पीड़ित की सहमति के बिना Javascript के माध्यम से सबमिट किया जाता है। :)
[](img/pinpkt.png)
### लाइव ब्राउज़र पैकेट परिवर्तन
हमारे अटैक सर्वर पर, क्योंकि हम पैकेट्स को आते हुए देख सकते हैं, हम देखते हैं कि क्या SIP पैकेट को सार्वजनिक IP पते के साथ फिर से लिखा गया था। यदि नहीं, तो हम क्लाइंट को (स्वचालित रूप से) बताते हैं कि SIP पैकेट अपेक्षित पैकेट सीमा पर नहीं था और इसे फिर से नहीं लिखा गया, और हम अपने स्निफर से नई सीमा स्थिति प्रदान करते हैं।
क्लाइंट कोड स्वचालित रूप से अपने पैकेट आकार को नए आकार में केवल लगातार दो विफलताओं के बाद समायोजित करता है। कुछ ब्राउज़र (Firefox) कभी-कभी फॉर्म के लिए उत्पन्न मल्टीपार्ट-बाउंड्री के कारण थोड़े अलग पैकेट आकार हो सकते हैं, जो अधिकांश अन्य ब्राउज़रों के विपरीत, एक निश्चित लंबाई नहीं है। मुझे लगता है कि लगभग 10 प्रयासों के बाद, वही आकार उपयोग किया जाएगा और हमला सफल होगा।
एक बार जब SIP पैकेट पैकेट सीमा पर आ जाता है, तो NAT धोखा खा जाएगा, यह विश्वास करते हुए कि यह एक वैध SIP पंजीकरण है और पीड़ित की मशीन पर एक SIP क्लाइंट से है। एक बार जब हमारा सर्वर उचित SIP प्रतिक्रिया के साथ जवाब देता है (ब्राउज़र को कुछ भी संदिग्ध न पहचानने देने के लिए एक उचित HTTP प्रतिक्रिया के अंदर नेस्टेड), NAT मूल पैकेट में पोर्ट खोल देगा जिसे हमने पीड़ित को भेजने के लिए कहा था और राउटर अब **हमलावर द्वारा चुने गए किसी भी पोर्ट को आंतरिक पीड़ित को वापस अग्रेषित करेगा, यह सब सिर्फ एक वेबसाइट पर ब्राउज़ करने से**।
हमला पूरा हुआ। हमलावर अब पीड़ित पर चल रही मनमानी TCP/UDP सेवाओं से कनेक्ट कर सकता है।
# अन्य निष्कर्ष
ये इस हमले में उपयोग नहीं किए गए हैं, लेकिन फिर भी दिलचस्प हैं और संभावित रूप से अन्य हमलों के लिए उपयोग किए जा सकते हैं।
- IP विखंडन IP डेटा अनुभाग में सभी डेटा का पूर्ण नियंत्रण देता है, जिसका अर्थ है ओवरफ्लो हुए पैकेट में स्रोत/गंतव्य पोर्ट सहित UDP हेडर का पूर्ण नियंत्रण
- पीड़ित IP स्टैक पुन: संयोजित करता है और डेटा को पार्स नहीं करेगा, हालांकि जिस NAT से पैकेट गुज़रता है वह संवेदनशील होगा
- ब्राउज़र या सिस्टम फ़ायरवॉल को बायपास करने की अनुमति देता है क्योंकि केवल UDP पोर्ट जो निरीक्षण किया जाता है वह मूल पैकेट है, ओवरफ्लो हुआ विखंडित पैकेट नहीं
- `Expires: 0` भेजकर और किसी और के लिए conntrack हटाकर SIP क्लाइंट पर DoS हमला करना
- यदि कोई पोर्ट पहले से लिया गया है, तो सुने जाने वाले पोर्ट को तब तक बढ़ाया जाता है जब तक कि पोर्ट 0 पर ओवरफ्लो न हो जाए
- STUN में किसी भी आधुनिक ब्राउज़र में प्रमाणीकरण लागू नहीं है
# डाउनलोड
पढ़ने के लिए धन्यवाद! आप मेरे [NAT Slipstream github](https://github.com/samyk/slipstream) से प्रूफ ऑफ कॉन्सेप्ट कोड डाउनलोड कर सकते हैं।
# संपर्क
**संपर्क बिंदु:** [@SamyKamkar](https://twitter.com/samykamkar)
मेरे और प्रोजेक्ट्स <https://samy.pl> पर खोजें या संभावित रूप से <[email protected]> पर मुझसे संपर्क करें।