31c3 CTF – Rick write-up


This is my write-up for the Rick-challenge in the 31c3 CTF. A little warning for those playing along: visiting the starting URL http://188.40.18.67/ with JavaScript enabled will get you Rick-rolled ;-)

The information to get started the challenge with the challenge was:

[code]Seems like somebody got pwned http://188.40.18.67[/code]

313c_roll

In the HTML-source of that URL we see an interesting comment:

[html highlight=”8″]
<!DOCTYPE html>
<html>
<head>
<title>You got PWNED!</title>
</head>
<body>

<!– ERROR: Could not write logfile – attacking 83.163.xx.xx:22 –>
<center>
[/html]

The IP-address shown is my own, so I started checking my sshd-logs, and indeed, they show a few login attempts coming in from the CTF-server:

[code highlight=”2,5,8″]Dec 28 21:15:23 mgmt sshd[51082]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=67.31c3ctf.aachen.ccc.de
Dec 28 21:15:25 mgmt sshd[51082]: Failed password for invalid user admin from 188.40.18.67 port 37865 ssh2
..
Dec 28 21:15:26 mgmt sshd[51084]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=67.31c3ctf.aachen.ccc.de
Dec 28 21:15:28 mgmt sshd[51084]: Failed password for invalid user oracle from 188.40.18.67 port 37866 ssh2
..
Dec 28 21:15:29 mgmt sshd[51086]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=67.31c3ctf.aachen.ccc.de
Dec 28 21:15:30 mgmt sshd[51086]: Failed password for invalid user hans from 188.40.18.67 port 37867 ssh2[/code]

So, it looks like the CTF-server is trying to attack me. Let’s get Kippo answer these SSH-requests and harvest some credentials of the users trying to login:

[code]2014-12-28 21:58:03+0100 [SSHService ssh-userauth on HoneyPotTransport,5,188.40.18.67] login attempt [admin/admin] failed
2014-12-28 21:58:05+0100 [SSHService ssh-userauth on HoneyPotTransport,6,188.40.18.67] login attempt [oracle/oracle123] failed
2014-12-28 21:58:06+0100 [SSHService ssh-userauth on HoneyPotTransport,7,188.40.18.67] login attempt [hans/=l@Zy+&’}M_.]<zEcDN9] failed[/code]

Ok, some ‘default’ attempts from users admin and oracle, but hans most definitely looks very promising. I added the user/password to Kippo’s userdb and tried again…

[code] 2014-12-28 22:03:55+0100 [SSHService ssh-userauth on HoneyPotTransport,101,188.40.18.67] hans trying auth password
2014-12-28 22:03:55+0100 [SSHService ssh-userauth on HoneyPotTransport,101,188.40.18.67] login attempt [hans/=l@Zy+&’}M_.]<zEcDN9] succeeded
2014-12-28 22:03:55+0100 [SSHService ssh-userauth on HoneyPotTransport,101,188.40.18.67] hans authenticated with password
2014-12-28 22:03:55+0100 [SSHService ssh-userauth on HoneyPotTransport,101,188.40.18.67] starting service ssh-connection
2014-12-28 22:03:55+0100 [HoneyPotTransport,101,188.40.18.67] connection lost[/code]

This time, we see that the account logs in just fine, but drops the connection even before the welcome-banner is sent.

Let’s try the harvested credentials on the attacking machine:

[shell highlight=”10″]$ ssh hans@188.40.18.67
RSA key fingerprint is 67:93:80:c8:13:ea:04:de:95:79:2f:d3:1b:fc:88:73.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added ‘188.40.18.67’ (RSA) to the list of known hosts.
hans@188.40.18.67’s password: =l@Zy+&’}M_.]<zEcDN9
Last login: Sun Dec 28 21:45:22 2014 from xx.xx.xx.xx
hans@31c3ctf-rick:~$ ls
flag.txt
hans@31c3ctf-rick:~$ cat flag.txt
31c3_a5bb3ead8fbc6617374ea3f57f0563d2[/shell]

And, there it is… another fine flag…

Also, we find here the starting point needed for the roll-challenge:

[shell]hans@31c3ctf-rick:/tmp/.xxx/usr/share/binfmts/. $ ls -fl
total 3176
-rwxr-xr-x 1 hans hans 813773 Dec 29 16:30 malware.old
drwxr-xr-x 3 hans hans 4096 Dec 29 19:01 ..
drwxr-xr-x 2 hans hans 4096 Dec 29 19:01 .
-rw-r–r– 1 hans hans 144 Dec 29 16:34 note.txt
-rwxr-xr-x 1 hans hans 2423671 Dec 29 16:19 malware
hans@31c3ctf-rick:/tmp/.xxx/usr/share/binfmts/. $ cat note.txt
malware.old is the original binary, malware is the debug build with some debugging output to troubleshoot problems, exploit works against both.
[/shell]