lezione del 3 aprile persa perché stavo facendo l’esame a quelli del primo anno, mentre la prima ora del 5 aprile era dedicata alla commemorazione di Alberto.
Non deve dire niente un programma a meno di specifiche particolari del programma stesso. Code ha una bella funzionalità: creare progetti in modalità debug che emette ulteriori informazioni per dire più roba. In ambito produzione non genera nulla di tutto questo, ma stai attento a non lasciare i log aperti e non fare riflessione dell’input: radice di tutti quanti i mali. Cercate sempre di andare a sanitizzare i parametri, sempre, in maniera paranoica. Dobbiamo dare al programma tutti gli input possibili, per ogni classe di input e vediamo che il programma risponda sempre allo stesso modo, sia funzionalmente che temporalmente, altrimenti l’avversario vi fa un faccia tanto e fa un distinguisher. Rimuovi output rivelatori di alcun genere e sorta. Se sbaglio la password su unix è comodo avere una sleep però per andare a evitare di avere dei casi di brute force pesante. Adesso sta facendo vedere Level02 delle challenge di Nebula, in cui faccio vedere dell’output che sarebbe meglio non andare a fare vedere e sta provando a fare una riparazione rimuovendo semplicemente la printf. Non mettere dei print a caso! Posso migliorare un pochino le applicazioni in questo modo, non le blindo ma sicuramente vado a ridurre la mia superficie di attacco.
Adesso entriamo dentro web for pentester. PHP permette di andare a lavorare in maniera debugger e andare effettivamente in modalità diagnostica andando a carpire informazioni importanti! La soluzione a questo problema consiste nell’adottare la configurazione di debug, ovvero andare in modalità produzione. PHP viene con due file di configurazione e copieremo nella locazione del file php il file php.ini production → questo spegno il display degli errori e vengono solamente loggati su file e non su stdout, lo vedo solamente nel log che sta nel server. L’idea è andare a mettere la configurazione di produzione all’interno del fine del produzione ufficiale. Vediamo l’effetto di questo uso in produzione che cosa posso comportare. Praticamente sto mettendo display error = off, così praticamente dovrei scrivere solamente nel log locale, oppure usare syslog. Si dovrebbe andare ad indagare in tal senso.
[12-04-2023]
Dobbiamo andare ad avere permessi quanto più stringenti possibili. Per esempio la cartella /home/utente sarebbe bene che sia configurata su 700, idem la directory che contiene le chiavi ssh. Cifrare le comunicazioni, non lasciare hash in chiaro di password o altro. Usa https, SEMPRE e COMUNQUE. Blindare i permessi in sostanza. Anche tenere -x- permette di andare a fare qualche lettura dei file, per non parlare di -r- che ci permette di eseguire direttamente un ls nella directories. Testare sempre l’accesso ai file. Dobbiamo fare in modo che gli altri utenti non facciano porcate, devo andare a blindare il tutto. Con questo modo possiamo andare a blindare Nebula 03. Ora stiamo vedendo la challenge Nebula 06. L’idea sarebbe spostare l’hash in /etc/passwd e al secondo campo di ogni riga vogliamo andare ad avere una x. Non possiamo avere tutto quanto l’hash in chiaro e quello che dobbiamo andare a fare è esattamente questo lavoro qua. Non lasciare mai le pw o le chiavi delle API all’interno dei tuoi file.
…
Solito discorso sulle CA per la distribuzione di public key per singole persone o ditte. Una CA da sola non riesce a fare tutto da sola ma abbiamo una root CA e poi abbiamo altre CA sottostanti che funzionano come CA di secondo livello. Andiamo avanti per diversi livelli fino ad arrivare a quelle che firmano effettivamente. Tutta la catena di firme serve per certificare che tutto sia andato a buon fine. Per avere un certificato valido devo pagare essenzialmente o affidarmi ad enti benefici che mi diano una mano senza pagare. Questi passaggi fanno perdere sicuramente del tempo. Possiamo però andarci a generare una chiave privata e chiave pubblica e bollarci da soli il certificato. Praticamente mi faccio da solo il passaporto e me lo firmo da solo. → SELF SIGNED
Sono certificati a tutti gli effetti, ma quando un client https vede questo certificato è un po’ in dubbio. Quando questo accade il browser dice all’utente che questo certificato non è verificabile. Questi hanno poi una durata di tot anni e poi vanno rinnovati. Letsencrypt (https://letsencrypt.org/it/) promuove certificati auto rinnovabili. Si generano i certificati questi vengono rinnovati annualmente. Ottima alternativa low cost per andare a gestire certificati self signed. Il virtual host è già configurato per andare a cerare questo certificato. I moduli sono presenti in /etc/apache2/mods-available. Posso andare ad abilitare il modulo ssl con il comando a2enmod ssl.
Funny fact: in base alla cipher suite che supporta il mio browser posso andare a vedere che tipo di browser sta comunicando con un determinato servizio → https://github.com/LeeBrotherston/tls-fingerprinting
[18-04-2023] recuperare lezione dalle slides, sono rimasto a casa
[19-04-2023]
Ogni input fornito ad un asset deve essere controllato al fine di non renderlo offensivo. Dobbiamo prestare attenzione ad input usati per esecuzione di comandi o valutazione di espressioni. Come mi devo proteggere? Devo andare a limitare l’input sicuramente come prima cosa. Devo essenzialmente andare a fare una santizzazione che posso andare a fare in due fasi:
Cosa intendiamo per filtro?