kaleth4/cve-2021-4045TP-Link Tapo C200 कैमरे (CVE-2021-4045) के लिए कमांड इंजेक्शन एक्सप्लॉइट, जो UART के माध्यम से रूट शेल एक्सेस और रिवर्स-इंजीनियर्ड uhttpd बाइनरी विश्लेषण प्रदान करता है।
CVE-2021-4045
CVE-2021-4045 TP-Link Tapo C200 कैमरे में पाई गई एक कमांड इंजेक्शन भेद्यता है, जो हमलावर को root विशेषाधिकारों के साथ डिवाइस का पूर्ण नियंत्रण लेने की अनुमति देती है। यह भेद्यता फर्मवेयर संस्करण 1.1.16 Build 211209 Rel. 37726N से पहले के सभी संस्करणों को प्रभावित करती है।
🔗 INCIBE की आधिकारिक सूचना: https://www.incibe.es/incibe-cert/alerta-temprana/vulnerabilidades/cve-2021-4045 (वास्तविक लिंक से बदलें)
🔧 अनुशंसित समाधान: फर्मवेयर को 1.1.16 या उससे ऊपर के संस्करण में अपडेट करें।
$ nmap -sV -p- 192.168.1.81
**परिणाम**:```
PORT STATE SERVICE
443/tcp open https
554/tcp open rtsp
2020/tcp open xinupageserver
8800/tcp open sunwebadmin
जैसा कि आप देख सकते हैं, डिवाइस में कुछ दिलचस्प खुले पोर्ट हैं। सबसे पहले मैंने पोर्ट 443 को आज़माया। हालाँकि nmap स्पष्ट रूप से बताता है कि यह https का उपयोग करता है, जब मैंने प्रारंभिक स्कैन किया, तो मैंने इसे अनदेखा कर दिया और काफी समय यह सोचकर बिताया कि पोर्ट 443 http का उपयोग कर रहा है। इस वजह से, मैंने https://192.168.1.81:443 के बजाय केवल http://192.168.1.81:443 को आज़माया, जिससे मुझे केवल 400 प्रतिक्रियाएँ मिलीं। जैसा कि मैंने परिचय में कहा था, यह प्रक्रिया असफलताओं से भरी थी। अन्य पोर्ट्स के बारे में, उन पर चलने वाली सेवाएँ मेरे लिए पूरी तरह से अज्ञात थीं और मुझे उनके बारे में कोई स्पष्ट जानकारी नहीं मिली। उस समय, मेरे पास कोई ज्ञात विकल्प नहीं बचा था, इसलिए गहराई से जाँच करने का समय था।
----[ शेल प्राप्त करना ]-------------------------------
कैमरा खरीदने से पहले, मैंने इंटरनेट पर डिवाइस के बारे में पिछले शोध खोजे और, सौभाग्य से, मुझे यह GitHub रिपॉजिटरी मिली जहाँ लोग रिवर्स इंजीनियरिंग करने के लिए सहयोग कर रहे थे। एक समस्या में बताया गया था कि UART पोर्ट के माध्यम से कंसोल तक पहुँच कैसे प्राप्त करें, जो उस समय मेरे लिए पूरी तरह से अज्ञात था। इसलिए मैंने मूल बातें सीखीं और कनेक्ट करने के लिए एक USB से TTL कनवर्टर खरीदा।
उल्लिखित समस्या की मदद से, मैं एक चाकू और एक पेचकस के साथ डिवाइस खोलने और जल्दी से UART का पता लगाने में सक्षम था। कुछ प्रयासों और बहुत धैर्य के बाद, अंततः मैंने पैड पर कुछ तारों को सोल्डर करने में सफलता प्राप्त की।
फिर, यह जाँचने का समय आया कि क्या सोल्डरिंग डेटा ट्रांसमिशन के लिए पर्याप्त अच्छी थी। मैंने तारों को USB एडाप्टर से जोड़ा, यह ध्यान में रखते हुए कि UART का Rx एडाप्टर के Tx से जाता है और इसके विपरीत, और एडाप्टर को अपने कंप्यूटर से जोड़ा। फिर से, उल्लिखित समस्या के लिए धन्यवाद, मुझे पता था कि सीरियल कनेक्शन के लिए बॉड दर 57600 थी, इसलिए मैंने निष्पादित किया:
$ sudo screen /dev/tty.usbserial-0001 57600
जहाँ '/dev/tty.usbserial-0001' वह USB पोर्ट है जिससे एडाप्टर जुड़ा है और जो डिवाइस को बिजली प्रदान करता है। मुझे तुरंत डेटा प्राप्त होने लगा, बढ़िया।
हालाँकि, मुझे अभी भी कंसोल तक पहुँच नहीं मिली थी। मैं जो प्राप्त कर रहा था वह केवल डिवाइस का बूट अनुक्रम था, जो वास्तव में U-Boot बूटलोडर था। यह कुछ इस तरह दिखता था:
U-Boot 2014.01-v1.2 (Jul 16 2021 - 18:41:10)
Board: IPCAM RTS3903 CPU: 500M :rx5281 prid=0xdc02 force spi nor mode DRAM: 64 MiB @ 1066 MHz Skipping flash_init Flash: 0 Bytes flash status is 0, 0, 0 SF: Detected XM25QH64A with page size 256 Bytes, erase size 64 KiB, total 8 MiB Using default environment
Autobooting in 1 seconds copying flash to 0x81500000 flash status is 0, 0, 0 SF: Detected XM25QH64A with page size 256 Bytes, erase size 64 KiB, total 8 MiB SF: 8388608 bytes @ 0x0 Read: OK
[...]
एंटर दबाने पर, हमें एक उपयोगकर्ता नाम और पासवर्ड दर्ज करने के लिए कहा जाता है। उस GitHub समस्या के लिए धन्यवाद, हम क्रेडेंशियल्स जानते हैं, इसलिए हम उपयोगकर्ता 'root' और पासवर्ड 'slprealtek' के साथ सफलतापूर्वक लॉग इन कर सकते हैं और अंततः कंसोल तक पहुँच प्राप्त कर सकते हैं।
एक बार जब मैंने जाँच लिया कि कनेक्शन काम कर रहा है, तो मुझे सोल्डरिंग को मजबूत करने की आवश्यकता थी, क्योंकि आवरण को जोड़ने की प्रक्रिया के दौरान यह दो बार टूट चुका था। मैंने सभी तारों को सुरक्षित करने के लिए हॉट ग्लू लगाया और डिवाइस को बंद कर दिया, सभी मोटरों को डिस्कनेक्ट कर दिया। अब, मेरी परीक्षण इकाई तैयार थी।
----[ डिवाइस की खोज ]--------------------------
अब जब हमारे पास एक आवरण है, तो आइए डिवाइस का अन्वेषण करें:
root@SLP:~# uname -a Linux SLP 3.10.27 #1 PREEMPT Wed Nov 11 20:42:05 CST 2020 rlx GNU/Linux
root@SLP:~# cat /etc/openwrt_version 12.09-rc1
जैसा कि हम देख सकते हैं, यह एक OpenWRT मशीन है जो Linux 3.10.27 चला रही है। अब हम सक्रिय प्रक्रियाओं और खुले पोर्ट्स की जाँच करेंगे:
root@SLP:~# ps PID USER VSZ STAT COMMAND 1 root 2328 S init 2 root 0 SW [kthreadd] 3 root 0 SW [ksoftirqd/0] 4 root 0 SW [kworker/0:0] 5 root 0 SW< [kworker/0:0H] 6 root 0 SW [kworker/u2:0] 7 root 0 SW [rcu_preempt] 8 root 0 SW [rcu_bh] 9 root 0 SW [rcu_sched] 10 root 0 SW< [khelper] 11 root 0 SW< [writeback] 12 root 0 SW< [bioset] 13 root 0 SW< [kblockd] 14 root 0 SW [khubd] 15 root 0 SW [kworker/0:1] 16 root 0 SW [kswapd0] 17 root 0 SW [fsnotify_mark] 18 root 0 SW< [crypto] 27 root 0 SW [kworker/u2:1] 46 root 0 SW< [deferwq] 47 root 0 SW< [kworker/0:1H] 247 root 2328 S -ash 262 root 0 SW [irq/27-gpio res] 273 root 0 SW< [cryptodev_queue] 282 root 860 S /sbin/hotplug2 --override --persistent --set-rules-f 304 root 888 S /sbin/ubusd 325 root 8152 S tp_manage 357 root 3416 S /usr/bin/ledd 361 root 3408 S /sbin/msglogd 367 root 3220 S /usr/sbin/netlinkd 370 root 5468 S < /usr/bin/system_state_audio 379 root 10180 S /usr/sbin/wlan-manager 491 root 1636 S /sbin/netifd 492 root 1520 S /usr/sbin/connModed 494 root 11488 S /usr/bin/dsd 496 root 1532 S /usr/sbin/connModed 502 root 7640 S /bin/cloud-service 520 root 4360 S /bin/cloud-brd -c /var/etc/cloud_brd_conf 653 root 15020 S /bin/cloud-client 830 root 2320 S /usr/sbin/telnetd -b 127.0.0.1 861 root 3852 S /usr/sbin/uhttpd -f -h /www -T 180 -A 0 -n 8 -R -r C 870 root 6048 S /usr/bin/relayd 872 root 5948 S /usr/bin/rtspd 879 root 4612 S /usr/bin/p2pd 884 root 11152 S /bin/dn_switch 889 root 4180 S /bin/storage_manager 920 root 40940 S /bin/cet 956 root 32336 S /bin/vda 960 root 3808 S /bin/wtd 970 root 11288 S /bin/nvid 1019 root 2332 S udhcpc -p /var/run/static-dhcpc.pid -s /lib/netifd/s 1037 root 0 SW [RTW_CMD_THREAD] 1059 root 1212 S wpa_supplicant -B -Dwext -iwlan0 -P/tmp/supplicant_p 1089 root 2332 S /usr/sbin/ntpd -n -p time.nist.gov -p 133.100.9.2 -p 1103 root 3840 S /usr/bin/motord 1447 root 2324 R ps
root@SLP:~# netstat -natpu Active Internet connections (servers and established) Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name tcp 0 0 0.0.0.0:8800 0.0.0.0:* LISTEN 920/cet tcp 0 0 127.0.0.1:929 0.0.0.0:* LISTEN 875/p2pd tcp 0 0 0.0.0.0:20002 0.0.0.0:* LISTEN 325/tp_manage tcp 0 0 0.0.0.0:2020 0.0.0.0:* LISTEN 969/nvid tcp 0 0 0.0.0.0:554 0.0.0.0:* LISTEN 920/cet tcp 0 0 127.0.0.1:23 0.0.0.0:* LISTEN 832/telnetd tcp 0 0 127.0.0.1:921 0.0.0.0:* LISTEN 878/relayd tcp 0 0 127.0.0.1:922 0.0.0.0:* LISTEN 877/rtspd tcp 0 0 0.0.0.0:443 0.0.0.0:* LISTEN 863/uhttpd tcp 0 0 192.168.1.80:37380 52.19.66.90:443 ESTABLISHED 507/cloud-brd udp 0 0 0.0.0.0:20002 0.0.0.0:* 325/tp_manage udp 0 0 0.0.0.0:38000 0.0.0.0:* 1087/ntpd udp 0 0 0.0.0.0:3702 0.0.0.0:* 969/nvid
हम उन खुले पोर्ट्स के पीछे की प्रक्रियाओं को देख सकते हैं जो nmap स्कैन में दिखती हैं, जैसे uhttpd या cet। मैंने विशेष रूप से uhttpd प्रक्रिया पर ध्यान केंद्रित किया, क्योंकि यह https सर्वर के पीछे है (जो उस समय मुझे अभी भी लगता था कि http है) और मैं पहले से ही http प्रोटोकॉल से बहुत परिचित था।
uhttpd OpenWRT द्वारा इस वितरण को चलाने वाले एम्बेडेड उपकरणों में उपयोग के लिए बनाया गया एक वेब सर्वर है। इस बिंदु पर, मैं जानना चाहता था कि क्या मैं इसके बारे में अधिक जानकारी प्राप्त कर सकता हूँ, जैसे स्रोत कोड या कम से कम पथ। मैंने OpenWRT विकी पर गया और uhttpd और सामान्य रूप से OpenWRT के बारे में सीखा। OpenWRT मशीनों में, एक प्रणाली होती है जिसे Unified Configuration Interface (UCI) कहा जाता है, जिसका उपयोग मूल रूप से सिस्टम सेवाओं को आसानी से कॉन्फ़िगर करने के लिए किया जाता है। इसका उपयोग करके, हम uhttpd का कॉन्फ़िगरेशन प्राप्त कर सकते हैं:
root@SLP:~# uci show | grep uhttpd ucitrack.@uhttpd[0]=uhttpd ucitrack.@uhttpd[0].init=uhttpd uhttpd.main=uhttpd uhttpd.main.listen_https=443 uhttpd.main.home=/ww uhttpd.main.rfc1918_filter=1 uhttpd.main.max_requests=8 uhttpd.main.cert=/tmp/uhttpd.crt uhttpd.main.key=/tmp/uhttpd.key uhttpd.main.cgi_prefix=/cgi-bin uhttpd.main.lua_prefix=/luci uhttpd.main.lua_handler=/usr/lib/lua/luci/sgi/uhttpd.lua uhttpd.main.script_timeout=180 uhttpd.main.network_timeout=180 uhttpd.main.tcp_keepalive=0 uhttpd.px5g=cert uhttpd.px5g.days=3600 uhttpd.px5g.bits=1024 uhttpd.px5g.country=CN uhttpd.px5g.state=China uhttpd.px5g.location=China uhttpd.px5g.commonname=TP-Link upnpc.uhttpd=entry upnpc.uhttpd.proto=TCP upnpc.uhttpd.ext_port=80 upnpc.uhttpd.desc=uhttpd
यहाँ कुछ दिलचस्प पैरामीटर हैं। पहला, 'uhttpd.main.home' सर्वर की रूट डायरेक्टरी की ओर इशारा करता है, इसलिए हम वेब सर्वर की कुछ फ़ाइलें पा सकते हैं। फिर, 'uhttpd.main.lua_handler' Lua हैंडलर स्क्रिप्ट की ओर इशारा करता है जो सर्वर शुरू करते समय Lua रनटाइम एनवायरनमेंट को प्रारंभ करने के लिए उपयोग की जाती है, क्योंकि uhttpd Lua स्क्रिप्ट का समर्थन करता है, इसलिए वहाँ और दिलचस्प फ़ाइलें हो सकती हैं। हालाँकि, निर्देशिका '/www' खाली है और न तो कोई 'sgi' निर्देशिका '/usr/lib/lua/luci' में है और न ही सिस्टम में 'uhttpd.lua' फ़ाइल है। मैंने इस uhttpd इंस्टेंस के काम करने के तरीके के बारे में जानकारी खोजने की कोशिश की, लेकिन कुछ नहीं मिला, केवल कॉन्फ़िगरेशन पैरामीटर जो कहीं नहीं जाते।
इस बिंदु पर, मुझे पता था कि समाधान सीधे 'uhttpd' बाइनरी का विश्लेषण करना और रिवर्स इंजीनियरिंग लागू करना था, लेकिन उससे पहले मैं एक परीक्षण वातावरण बनाना चाहता था ताकि अनुरोध करने पर वेब सर्वर के अंदर क्या होता है, यह पता चल सके, क्योंकि जिस तरह से प्रक्रिया बनाई गई थी, वहाँ कहीं भी कोई आउटपुट नहीं था।
मैंने ps कमांड के आउटपुट में प्रक्रिया 861 के लिए पाया गया कमांड चलाने की कोशिश की:
$ /usr/sbin/uhttpd -f -h /www -T 180 -A 0 -n 8 -R -r C
हालाँकि, मुझे बहुत सारी त्रुटियाँ मिलीं और मैं इसे काम करने में असमर्थ रहा। चूँकि मैं एक अलग पोर्ट पर समान uhttpd प्रक्रिया नहीं बना सका, मैंने प्रक्रिया की '/proc' प्रविष्टि की जाँच करके गुम आउटपुट को खोजने की कोशिश की, यदि वे मौजूद हों तो उन्हें पढ़ने का प्रयास किया (जैसा कि PwnFunction के इस वीडियो में समझाया गया है)। लेकिन एक बड़ी समस्या थी:
root@SLP:~# sudo ls -l /proc/864/fd/ lrwx------ 1 root root 64 Nov 10 22:44 0 -> /dev/null lrwx------ 1 root root 64 Nov 10 22:44 1 -> /dev/null lrwx------ 1 root root 64 Nov 10 22:44 2 -> /dev/null lrwx------ 1 root root 64 Nov 10 22:44 3 -> anon_inode:[eventpoll] lrwx------ 1 root root 64 Nov 10 22:44 4 -> socket:[1830]
'stdin', 'stdout' और 'stderr' के लिए सभी फ़ाइल डिस्क्रिप्टर '/dev/null' पर रीडायरेक्ट किए गए थे, जो मूल रूप से उन्हें एक ब्लैक होल में रीडायरेक्ट करता है जहाँ उन्हें नहीं पाया जा सकता। मैं अटक गया था और मुझे नहीं पता था कि क्या करना है। चूँकि मैं पहले से ही '/proc' प्रविष्टि में था, मैंने जाँच शुरू कर दी, क्योंकि मुझे याद नहीं था कि '/proc' प्रविष्टियों में किसी प्रक्रिया के बारे में इतनी जानकारी होती है और मैं उत्सुक था। इस आकस्मिक जिज्ञासा के लिए धन्यवाद, मेरी नजर 'environ' प्रविष्टि पर पड़ी, जिसमें उस प्रक्रिया के लिए सभी पर्यावरण चर होते हैं। इन पर्यावरण चरों में से एक था:
UHTTPD_ARGS=-h /www -T 180 -A 0 -n 8 -R -r C200 -C /tmp/uhttpd.crt -K /tmp/uhttpd.key -s 443
मुझे तुरंत एहसास हुआ कि ps द्वारा दिखाया गया कमांड गलत था और बाद में मुझे पता चला कि यह इसलिए था क्योंकि UART इंटरफ़ेस में सभी वर्णों को प्रदर्शित करने के लिए पर्याप्त चौड़ाई नहीं थी। एक और असफलता जिसने मुझे महत्वपूर्ण सबक सिखाए: कभी भी UART पोर्ट के आउटपुट पर भरोसा न करें।
अब आखिरकार मैं समान मापदंडों के साथ uhttpd का एक और इंस्टेंस बना सकता हूँ और बिना '/dev/null' पर पाइप के, बाइनरी का परीक्षण कर सकता हूँ, जबकि मैं उस पर रिवर्स इंजीनियरिंग कर रहा हूँ।
----[ Ghidra के साथ uhttpd की रिवर्स इंजीनियरिंग ]--------
यह पहली बार था जब मैंने Ghidra का उपयोग किया। मैंने कुछ वीडियो देखे थे और कुछ लेख पढ़े थे (stacksmashing और liveoverflow को अद्भुत और आसानी से समझने वाली सामग्री के लिए धन्यवाद), लेकिन मैंने वास्तव में इसका उपयोग कभी नहीं किया था, इसलिए यह सीखने का एक बहुत अच्छा अवसर था।
मैंने uhttpd बाइनरी खोली और कई प्रयासों के बाद पाया कि भाषा MIPS32, लिटिल एंडियन, mips16e के साथ थी। कुछ फ़ंक्शन नाम बाइनरी के साथ डिफ़ॉल्ट रूप से आए, लेकिन अन्य नहीं। मैंने फ़ंक्शन का नाम बदलने में भी कुछ समय बिताया, क्योंकि ऐसा लगता है कि Ghidra अक्सर बाहरी फ़ंक्शन के साथ भ्रमित हो जाता है और उनके लिए अजीब रैपर मिलते हैं, जैसे:
मैंने बाइनरी के तर्क और संरचना को समझने के लिए `main()` फ़ंक्शन और अन्य महत्वपूर्ण फ़ंक्शन का विश्लेषण किया। मुझे कुछ दिलचस्प, पहले से पहचाने गए फ़ंक्शन मिले, जिनमें `do_login()` और `uh_slp_proto_request()` शामिल थे। मैं बाद में इस बारे में और बात करूँगा।
इस पहले संपर्क के बाद, मैंने बग की खोज शुरू की। चूँकि मैं ओवरफ्लो कमजोरियों में पूरी तरह से नौसिखिया हूँ, सबसे पहले मैंने system(), exec() और popen() के कॉल खोजे ताकि यह जाँच सकूँ कि कोई कमांड इंजेक्शन कमजोरी है जिसका मैं आसानी से शोषण कर सकता हूँ। और मेरी कितनी किस्मत थी।
फ़ंक्शन 'exec_and_read_json()', कमांड को निष्पादित करने के लिए 'popen()' का उपयोग करता है:
ejecutar_y_leer_json
फ़ंक्शन 'exec_and_read_json()' का उपयोग दो बिना नाम वाले फ़ंक्शन द्वारा किया जाता है, जिन्हें मैंने 'set_language()' और 'wifi_connect()' नाम दिया है। ये फ़ंक्शन क्रमशः भाषा सेटिंग और वाई-फ़ाई कनेक्शन (स्पष्ट रूप से) के लिए जिम्मेदार हैं। 'wifi_connect()' एकल उद्धरण (') को पार्स करता प्रतीत होता है, जबकि 'set_language()' नहीं करता। इसका मतलब है कि यदि हम 'set_language()' फ़ंक्शन के इनपुट को नियंत्रित कर सकते हैं, तो हम सफलतापूर्वक अपने स्वयं के कमांड इंजेक्ट कर सकते हैं:
conexión wifi establecer_idioma
फ़ंक्शन 'set_language()' का उपयोग 'uh_slp_proto_request()' द्वारा किया जाता है, वह फ़ंक्शन जिसका मैंने पहले उल्लेख किया था, जो इनपुट के रूप में उपयोगकर्ता से प्राप्त कुछ पार्स किए गए डेटा को पास करता है।
función_principal_1 función_principal_2
उपयोगकर्ता डेटा को पार्स करने के लिए, uh_slp_proto_request() जाँचता है कि क्या यह एक मान्य JSON ऑब्जेक्ट है। फिर, यह कुंजी method द्वारा पहचाने गए एक स्ट्रिंग मान और params द्वारा पहचाने गए एक डिक्शनरी मान प्राप्त करता है (कम से कम मुझे ऐसा लगता है, क्योंकि Ghidra फ़ंक्शन कॉल को हल नहीं कर सका, लेकिन ऐसा लगता था कि यह इस तरह काम करता है)। चुने गए विधि के आधार पर, uh_slp_proto_request() निष्पादित होने वाले फ़ंक्शन का चयन करता है।
तो, निम्नलिखित पेलोड भेजने पर:{"method": "setLanguage", "params":{}}
हम सही ढंग से 'set_language()' फ़ंक्शन को कॉल करते हैं और '{}' को 'language_json' पैरामीटर के रूप में पास करते हैं। फिर, 'set_language()' के अंदर, 'language_json' ऑब्जेक्ट को एक स्ट्रिंग में बदल दिया जाता है और इसे सीधे "ubus call system_state_audio set_language '%s'" में निष्पादन के लिए डाला जाता है।
इस पेलोड को भेजते समय:{"method": "setLanguage", "params": {"payload": "'; touch poc;'"}}
निम्नलिखित निष्पादित किया जाएगा।
ubus call system_state_audio set_language '{"payload": "'; touch poc;'"}'
जिसमें वास्तव में 3 कमांड हैं:
ubus call system_state_audio set_language '{"payload": "'
touch poc
'"}'
दूसरा हमें कोड का पूर्ण निष्पादन करने की अनुमति देता है।
अब, फ़ंक्शन 'uh_slp_proto_request()' का उपयोग एक अन्य अनाम फ़ंक्शन द्वारा किया जाता है जो सभी अनुरोधों को संभालता है, जिसे मैंने 'main_server_function()' नाम दिया है। यदि कोई अनुरोध मान्य है (अधिकतम लंबाई से अधिक नहीं है, सर्वर कॉन्फ़िगरेशन के अनुसार 'http' या 'https' का उपयोग करता है, आदि), तो 'main_server_function()' जाँचता है कि URL में '/cgi-bin/luci' या '/web-static' है या नहीं। यदि ऐसा नहीं है, तो 'uh_slp_proto_request()' को कॉल किया जाता है।
uh_slp_proto_request_entrypoint
एक परीक्षण करके और कैमरे को कुछ अनुरोध भेजकर, हम जाँच सकते हैं कि 'uh_slp_proto_request()' द्वारा उपयोग किए गए डेटा मानक POST डेटा हैं। इसलिए, यदि हम उपरोक्त पेलोड के साथ '/' पर एक POST अनुरोध भेजते हैं, तो 'uh_slp_proto_request()' इस डेटा को संसाधित करेगा, 'set_language()' को कॉल करेगा, और हमारा पेलोड 'exec_and_get_result()' द्वारा निष्पादित कमांड में इंजेक्ट हो जाएगा।
जैसा कि आप देख सकते हैं, मैंने प्रमाणीकरण के बारे में कुछ नहीं बताया, क्योंकि फ़ंक्शन 'setLanguage()' को बिना लॉग इन किए कॉल किया जा सकता है। यह किसी भी उपयोगकर्ता को बिना प्रमाणीकरण के एक ही अनुरोध से कैमरे का पूर्ण नियंत्रण लेने की अनुमति देता है।
----[ शोषण ]----------------------------------
अब, एक्सप्लॉइट लिखने का समय है। मैंने netcat के साथ रिवर्स शेल प्राप्त करने का तरीका जानने में कुछ समय बिताया। यह सरल लग रहा था, लेकिन मैं इसे काम करवा नहीं पा रहा था। मैंने पाया कि BusyBox में स्थापित netcat का संस्करण कार्यक्षमता में काफी सीमित है, इसलिए पारंपरिक रिवर्स शेल मान्य नहीं थे। हालांकि, मुझे PayloadsAllTheThings रिपॉजिटरी (हमेशा की तरह) में वह मिल गया जिसकी मुझे तलाश थी और मुझे सही रिवर्स शेल मिल गया। चूंकि uhttpd रूट के रूप में चलता है (TP-Link की बदौलत), हमें केवल एक दुर्भावनापूर्ण POST अनुरोध भेजकर उच्चतम विशेषाधिकारों वाला शेल मिलता है। एक्सप्लॉइट GitHub पेज पर उपलब्ध है: https://github.com/hacefresko/CVE-2021-4045/blob/master/pwntapo.py
<img width="1168" height="737" alt="image" src="https://assets.kitploit.com/production/public/readmes/27855/3db3624bf0623cca2dcb69e0d3a9c9401d40d44462d94e4f4b3d4eb4f62c8c23.png" />
🚨 **सीखा गया सबक**:
- मैंने पोर्ट **443** पर `https` को `http` समझ लिया, जिससे गलती का पता चलने तक समय बर्बाद हुआ।
- पोर्ट **2020**, **554** और **8800** पर सेवाएँ अज्ञात थीं, जिसके लिए अतिरिक्त शोध की आवश्यकता थी।
---
## 🔓 **शेल प्राप्त करना**
### UART के माध्यम से कंसोल तक पहुँच
1. **Investigación previa**:
- मुझे डिवाइस के रिवर्स इंजीनियरिंग के बारे में जानकारी वाला एक GitHub रिपॉजिटरी मिला।
- मैंने **UART** पोर्ट तक पहुँचने के लिए **USB से TTL कनवर्टर** का उपयोग करना सीखा।