Sei sulla pagina 1di 2

Componenti gruppo:

Emanuele De Carolis 1741935 decarolis.1741935@studenti.uniroma1.it


Eugenio Gadaleta 1914773 gadaleta.1914773@studenti.uniroma1.it
Marco Macrini 1921383 macrini.1921383@studenti.uniroma1.it

Nome Macchina Virtuale: VM_100298


Username: lelinho

Password (lelinho): z-P/r7#xf=LcWaf-


Password (ema): Qwertyui!0

Creazione nuovo utente ‘ema’ e settaggio passwd(weak credential).

Installazione openssh (concessa prima vulnerabilità per local access).

Hacking: ora è permesso una connessione remota verso la VM usando prima nmap
per scansionare i servizi attivi della macchina virtuale (es. SSH) e poi utilizzando il
tool Hydra, grazie ai dizionari ,possiamo forzare la password dell’account ema
(essendo debole) per ottenere un local access.

In un real-life system è possibile che un utente scelga una password non robusta.

Abbiamo concesso 2 vulnerabilità per privilege escalation:

1) Concessa per l’utente ema la funzione nano (all’interno del file /etc/sudoers)
per la directory /var/opt/* [lo si vede con sudo –l].

Hacking: l’hacker all’interno del profilo ‘ema’ ora puo arrivare a modificare il file
/etc/sudoers/ attraverso la funzione nano disponibile per la directory
/var/opt/../../etc/sudoers. In particolare può riconfigurare i privilegi per l’utente ‘ema’ e
farlo diventare root.

2) Concessa la root per l’utente ‘ema’ (all’interno del file etc/sudoers)per la


gestione del file /home/ema/test.sh

Hacking: l’hacker vedendo questo privilegio può creare un file “test.sh” all’interno
della propria directory e renderlo eseguibile (chmod 764). Dopo di che lo modifica
usando il comando ‘echo’ aggiungendo ‘/bin/bash –i’. Così si può ottenere la root
eseguendo il comando ‘sudo ./test.sh’ .

Entrambe le vulnerabilità possono essere ritrovate in un real-life system a causa di


una scorretta configurazione per l’assegnazione di permessi all’utente (poor system
configuration).

Creazione Web site con apache2 e mysql.


Creazione di un website (login form) collegato al database personale rinominato
Ethical_Hacking.
2 tipi di vulnerabilità:

1)SQLI

Hacking: analizzando le pagine di cui è composto il sito si può vedere la query


utilizzata per accedere al db ed effettuare il login. In particolare in questa query, non
statica, viene richiesta il matching tra username e password immessi nel login form
con quelli contenuti nel database Ethical_Hacking.
Per questo, eseguendo un Sql Injection di basso livello, si può accedere al sistema
(es: admin’or’1’=’1) sia per username che per password.

E’ possibile che in un real-life system l’input non venga correttamente filtrato (oppure
mancanza di statement), rendendo l’applicazione vulnerabile a una SQL Injection.

2)XSS

Una volta effettuato il login correttamente è possibile inserire un nome all’interno del
banner di ricerca. Per poter passare alla pagina successiva è obbligatorio compilare
il banner.

Hacking: l’hacker, analizzando il codice della pagina “home.php”, può notare che la
form invoca la pagina “search.php” con un metodo GET. In questo modo i dati inviati,
successivamente con la query, sono sensibili ad un Injection. Nello specifico,
eseguendo lo script “<script>alert(“xss”)</script>” è possibile passare alla pagina
successiva senza immettere il campo obbligatoriamente richiesto.

Il codice PHP non è sicuro e si espone a questo tipo di vulnerabilità.