-> Faccio HPKP header removal per non far fare il pinning! <- E' mandatorio -> Seccare le richieste OCSP <- Opzionale... Testare con tutti i browser per certificato client verso IP non locale ----------------------- - Se il server chiede un certificato client e' un problema? SI - Se il client non supporta SNI (e ce ne sono: Win XP, BB9, etc.) la modalita' SSL proxy e' complessa -> l'ip destinazione va letto dal kernel ----> Il metodo coi certificati client ha il problema che questi si possono zappare tutti in un colpo (es: domain issuer) -> il server dovrebbe testare vari certificati client finche uno non viene accettato per un dato IP. Poi continua a proporre quello -> Lo shellcode testa se c'e' gia' il suo issuer - Il rischio del client cert e' se c'e' ma manca la policy (esce pop up) -> es Group policy non hanno effetto se non e' un windows professional - Il client cert se vedo che non me lo manda, su quell'ip comincio a non chiederlo piu' - a meno che non mi venga refreshato da "jpg"? - non mandare ttl exceeded per evitare traceroute (ma forwarda il pacchetto) - i pacchetti con TTL basso li forwarda (senza abbassarlo) - tenere conto dello SNI per le richieste (e forse per la cache dei certificati) - Posso disabilitare PFS per fare tutte in passivo senza dover creare due socket distinte (client-proxy e proxy-server)? -> Forse posso anche ricreare l'hash di tutto l'handshake che viene mandato alla fine con il tls -> Se riesco a tenere i pacchetti di dimensioni uguali per TCP seq/ack sarebbe fantastico! -> Anche la connessione con il client cert request vediamo se riusciamo a farla cosi'! - Vogliamo estendere a BlackBerry? Forse per i vecchi ci sono exploit, ma per il 10? - Le connessioni ai vari server le dovremmo fare con vari ip di decoy - Tutti gli stage dell'exploit dovranno essere serviti in TLS con PFS -> Alla fine cancella codice dalla memoria - Fare un test con piu' certificati client installati - Provare a fare un donwnload di un exe via https (es: tor) con IE mentre si intercetta https -> il problema era che mitm proxy faceva store and forward... - Quando si cambiano le variabili d'ambiente, forzare Il browser a rileggerle, altrimenti se si scarica e si lancia TOR nella medesima sessione, questo non si legge le nuove variabili inserite dallo shellcode ---> Non si puo' fare! - Verificare che windows update continui ad andare (non deve fare mitm sulle connessioni a winupdate) ---> E NON FACCIA BLOCCARE L'EXPLOIT!!! --------------------------------------------------------------------------------------------------------------- - Su utente ADSL si puo' identificare target usando parametri RADIUS (debole se ad es. router wifi) --------------------------------------------------------------------------------------------------------------- !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! - Se utilizziamo cypher suite per fare il marking, c'e' bisogno di condividere i certificati generati fra tutti gli appliance, altrimenti un client che cambia ADSL potrebbe ricevere un certificato diverso per lo stesso marker. - Proviamo ad usare soluzioni diverse dall'iframe (per inoculare l'exploit) per ottimizzare il caricamento del resto della pagina mentre si scaricano i vari stage. - Non inviare exploit alla prima connessione da un ip, ma mandarlo random (solo se su quell'ip identifico nuovi device). Cosi' evito che analista si becchi facilmente lo shellcode ----- Come ultima alternativa per l'identificazione (anche se complessa) - Fingerprint passivo da SYN/SYNACK - Se due o piu' macchine hanno lo stesso profilo, le discrimino dal traffico in chiaro. - Se ne trovo una che in chiaro non e' stata marchiata, fermo mitm su tutte le macchine con quel profilo finche' non injecto anche quella -------------- VERSIONE BRIDGE - La versione trasparente potrebbe prendere il certificato, crearne uno di uguale lunghezza che viene storato, eliminare tutti gli algoritmi che permettono PFS, e, dopo aver letto la chiave di sessione far fluire la connessione limitandosi a decifrare il traffico in passivo -> Da vedere cosa succede in caso di rinegoziazione della chiave (si puo' togliere dal server e dal client hello?) ----> TLS_RSA_WITH_AES_128_CBC_SHA e' quello mandatorio (P_SHA256 e' la PRF di default) - Droppare Hello_request ed evitare rinegoziazioni? -> Basta vedere i pacchetti di handshake (anche cifrati) e manglare solo quelli per ottenere la nuova chiave di sessione dopo rinegoziazione - Permettere il resume di una sessione? - Se ho l'id in cache ho anche gia' la chiave - Altrimenti lo azzero - Bisogna tenere comunque traccia delle sessioni TCP -> Fare attenzione alle ritrasmissioni quando si modifica il pacchetto di handshake certificato - Siccome dovrei forzare RSA non posso toglierlo dai cypher supportati per il marking (di fatto riduco i bit a disposizione) - Supporto solo TLS1.1 e 1.2 - Attenzione se viene usata Compression - Devo supportare qualche forma di reassembly IP e/o TCP per avere tutti i record SSL integri - Il ClientHello do' per scontato che sia in un solo pacchetto: solo se lo riconosco intero e "marcato" continuo il mangling di quella sessione