Discussione Certificati CA - SSL - HTTPS

Stato
Discussione chiusa ad ulteriori risposte.

Err0r404

Utente Bronze
27 Marzo 2017
34
7
6
33
Premesso che è tutto una novità per me e sono solo mosso da curiosità (non cerco di entrare nella NASA, rubare account o carte di credito), proprio non riesco a capire come funzionino questi certificati CA alla base.
Mi è chiaro il concetto superficiale di crittografia asimmetrica e di handshaking.
Mi è chiaro anche il preconcetto che ha determinato il bisogno di una simile tecnologia.
Abbiamo una rete di scambio dati immensa, molti dati sensibili che fanno gola dal ladruncolo alla multinazionale, serve un modo per difendere queste informazioni.
Logico.
Parto dalla mia esperienza personale, quando ho "scoperto" la connessione HTTPS perchè giocavo sulla mia rete domestica con Ettercap e il reindirizzamento.
Avevo letto e cercato molto sullo spoofing, poisoning e quindi di conseguenza sullo sniffing (perchè per la maggiore i tutorial legano questi concetti credo per renderli più appetibili), scopro così che, per esempio, in base sniffing, col cavolo che puoi decriptare informazioni se la vittima scambia dati su siti HTTPS, e a volte, col cavolo che le vedi proprio.
Mi sembra regolare, penso che se questo era il problema da risolvere è stato più che egregiamente risolto, le informazioni non viaggiano in chiaro, se le vedi sono criptate, non hai la chiave, pace.
Poi riesco, sempre giochicchiando a fare dei redirect su index scialbi "You've been Hacked" e trollate simili che piacciono a noi nabbi (almeno impari qualcosina) però ecco che SSL mi fotte il cervello: qualsiasi browser aggiornato (non quelli dei tutorial su macchine virtuali Microsoft "Trapanamipure" XP) si altera non poco se quando scrivi facebook.it si trova nella condizione di venire reindirizzato.
Questa pagina non è sicura, zio (so che vuoi fregarmi).
Da che cosa dipende tutto questo? Perchè un qualsiasi altro sito HTTP non desta tale indignazione?
Qualcosa che dipende dai Certificati CA? E' il browser che morde oppure il modo in cui la pagina index si presenta (hostata cioè su computer locale)?
Vorrei capire di più sulla questione pertanto se avete tempo e modo di aiutarmi con qualche guida, vostra ricerca, lettura o chiacchiera vi ringrazio molto!
Sperando di aver acceso un thread interessante, vi saluto!
 
L'header di un pacchetto HTTPs non sempre e' cryptato, e nell'header sono contenuti gli indirizzi IP del server e del client, per cui probabilmente andavi a modificare l'header del pacchetto cambiando l'IP del server
 
Grazie per le risposte, il video spero di riuscire a vederlo domani per poter meglio capire, ma credo proprio che si tratti di questo mixed-content!
Spero di riuscire a capire tutto, altrimenti sarò di nuovo qui a rompere... sopportatemi :p
 
L'header di un pacchetto HTTPs non sempre e' cryptato, e nell'header sono contenuti gli indirizzi IP del server e del client, per cui probabilmente andavi a modificare l'header del pacchetto cambiando l'IP del server

In realtà in quelle vecchie prove andavo un po' alla cieca con giusto la minima competenza utilizzando per lo più ettercap e beef, quindi non avevo pieno controllo sui pacchetti, lasciavo la maggior parte dei comandi "standard".
Quello del mixed-content è un errore plausibile visto che l'hook di beef per esempio è un http, ma è anche plausibile sia una questione di header, sono ignorante, in quale modo va fatto questo accorgimento durante l'architettura di un redirect?
C'è una sorta di header grabbing che si può fare dal sito che vuoi reindirizzare ed in coda un modo per applicare gli identificativi fakeandoli sul sito di landing?
E si può fare anche se stai semplicemente avvelenando una rete locale reindirizzando tutti su una pagina che hai sul pc attaccante?

Se ti va di aiutarmi o fornirmi documentazione al riguardo ti ringrazio infinitamente!
 
Ultima modifica:
hai abilitato l'https nel config di beef?
stai utilizzando beef su protocollo tls con un certificato privato?

probabilmente con un tcp intercept potresti approfondire lato header, ma io non l'ho mai fatto.
 
Ultima modifica:
https://www.mvmnet.com/it/ssl/help/certificati_ssl.php (non è la migliore risorsa per capire il certificato ma sufficiente ai fini della discussione)

riassumo:
se tu hai la necessità di maneggiare comunicazioni tramite protocollo ssl/tls hai la necessità di fornire un certificato (si paga), chiave pubblica e chiave privata, il browser scarica il certificato dal sito web/ applicazione con la quale vuole instaurare una comunicazione.

La chiave pubblica del server web viene scaricata, è all'interno del certificato. Dopo averla scaricata controlla che sia stato firmato da una fonte che può essere considerata attendibile, l'attendibilità della fonte è definita dal controllo dell'ente di emissione del certificato.

Il certificato ha al suo interno anche il dominio o l'ip del webserver, e conferma insieme all'autorità di certificazione che la risposta proviene effettivamente dalla fonte certificata.
Sucessivamente verrà generata una chiave simmetrica condivisa tramite la quale sarà possibile gestire il traffico protetto.
Questa chiave simmetrica utilizzerà la chiave pubblica rilasciata dal web server per criptare il traffico, assicurando così la sicurezza della comunicazione. (fintanto che la chiave privata rimane tale)

Per tornare al punto.

Il problema che hai avuto tu si presenta nel momento in cui la comunicazione viaggia http-https, beef come ho anticipato ha l'opzione di utilizzare il protocollo tls. e nel caso necessario deve essere abilitato nel file di configurazione del tool.

Se viene generato un certificato privato, il browser potrebbe non ritenere questo certificato valido se non emesso da un ente valido. può essere generato un certificato privato(intendo privato come auto-generato e non generato da enti accreditati) ma in questo caso il problema si ripresenterebbe.

Beef una volta impostato nel config l'uso del protocollo ssl/tls ha a disposizione un certificato di default che non dà questi problemi (alla maggior parte degli utenti)

Come beef maneggi questo certificato per evitare il problema a cui, penso, faceva riferimento unixLike_, cioè al contrasto delle informazioni nella comunicazione (CONVALIDATI dai dati nel certificato), presuppongo che sia un MITM, quindi te sei nel mezzo e gestisci le due comunicazioni, non ne ho idea.
 
https://www.mvmnet.com/it/ssl/help/certificati_ssl.php (non è la migliore risorsa per capire il certificato ma sufficiente ai fini della discussione)

riassumo:
se tu hai la necessità di maneggiare comunicazioni tramite protocollo ssl/tls hai la necessità di fornire un certificato (si paga), chiave pubblica e chiave privata, il browser scarica il certificato dal sito web/ applicazione con la quale vuole instaurare una comunicazione.

La chiave pubblica del server web viene scaricata, è all'interno del certificato. Dopo averla scaricata controlla che sia stato firmato da una fonte che può essere considerata attendibile, l'attendibilità della fonte è definita dal controllo dell'ente di emissione del certificato.

Il certificato ha al suo interno anche il dominio o l'ip del webserver, e conferma insieme all'autorità di certificazione che la risposta proviene effettivamente dalla fonte certificata.
Sucessivamente verrà generata una chiave simmetrica condivisa tramite la quale sarà possibile gestire il traffico protetto.
Questa chiave simmetrica utilizzerà la chiave pubblica rilasciata dal web server per criptare il traffico, assicurando così la sicurezza della comunicazione. (fintanto che la chiave privata rimane tale)

Per tornare al punto.

Il problema che hai avuto tu si presenta nel momento in cui la comunicazione viaggia http-https, beef come ho anticipato ha l'opzione di utilizzare il protocollo tls. e nel caso necessario deve essere abilitato nel file di configurazione del tool.

Se viene generato un certificato privato, il browser potrebbe non ritenere questo certificato valido se non emesso da un ente valido. può essere generato un certificato privato(intendo privato come auto-generato e non generato da enti accreditati) ma in questo caso il problema si ripresenterebbe.

Beef una volta impostato nel config l'uso del protocollo ssl/tls ha a disposizione un certificato di default che non dà questi problemi (alla maggior parte degli utenti)

Come beef maneggi questo certificato per evitare il problema a cui, penso, faceva riferimento unixLike_, cioè al contrasto delle informazioni nella comunicazione (CONVALIDATI dai dati nel certificato), presuppongo che sia un MITM, quindi te sei nel mezzo e gestisci le due comunicazioni, non ne ho idea.

Ti ringrazio per l'interessamento e l'aiuto BaBajaga, ho fatto tesoro delle tue informazioni e sono andato a cercare risposte e approfondimenti in giro.
Ne risulta che ad oggi ci sono tanti motivi per cui un attacco del genere non può avere assolutamente esito positivo, almeno con le attuali contromisure alla portata di tutti.

In primo luogo TLS per quanto riguarda lo sniffing che, se non ho capito tutto davvero male, è il protocollo che include HTTP "incapsulandolo" in HTTPS con cifratura asimettrica, doppia chiave client server e relativi certificati di sicurezza ed è invalicabile nel senso che non permette di manipolare le informazioni nè in testa, nè in coda (in assenza di certificato originale), nè tantomeno in mezzo (poichè la cifratura è roba tosta).

Se non bastasse abbiamo HSTS la procedura di impedimento di downgrade del protocollo HTTPS che forza la comunicazione protetta e molto probabilmente è proprio questa che mi ha impedito di fare il redirect. Liste HSTS preimpostate sono addirittura implementate nel database dei browser che anche in assenza di prima comunicazione con il server vanno subito a richiedere forzatamente il campo protetto e si allertano immediatamente se qualcosa dovesse andare storto finanche nel primo tragitto, questo e il secondo database imostato tramite learn che definisce a priori la risoluzione dei domini DNS fanno si che non si possano compromettere i dati apparentemente da nessuna parte a meno di creare una terza via con Social Engineering.

Ma è mai possibile mi chiedo io? Va a finire che l'unico modo di eseguire una penetrazione sarà trikkare il browser con Reversing? :p

Oh, correggetemi se ho sbagliato qualcosa eh! :D
 
Tutto giusto, solo aggiungo solo una cosa:

Dai perscontato che nel panorama internazionale vengano rispettate e aggiornate le linee guida relative all'aggiornamento del protocollo tls per quanto riguarda la sicurezza.

Per quanto mi riguarda ho riscontrato spesso che gli amministratori in realtà non prestano particolare attenzione all'aggiornamento dei protocolli, Insecure Transportation Security Protocol Supported (TLS 1.0) ad esempio è una vulnerabilità riscontrata spesso.
Può portare a un attacco Browser Exploit Against SSL/TLS comunemente chiamato BEAST.


Inoltre per quanto riguarda l'HSTS già è stato "sorpassato" dallo sviluppo del tool sslstrip2 nel 2014 se non propriamente configurato.

un pò di link:

http://www.slideshare.net/Fatuo__/offensive-exploiting-dns-servers-changes-blackhat-asia-2014
https://github.com/byt3bl33d3r/sslstrip2


In linea di massima non vengono prese in considerazione per quanto riguarda le applicazioni web tutte quelle vulnerabilità che hanno un incidenza privata (lato utenza ad esmepio xss-reflected & mitm) anzi le responsabilità vengono spesso scaricate appunto sull'utente che non si mantiene aggiornato in termini di sicurezza teorica e applicativa.

Naturalmente ritengo questa pratica un fallimento sociale ed educativo, ma comunque restano vulnerabilità potenzialmente a basso impatto.

(non prendere come oro colato quel che dico che in questo campo c'è solo da imparare, anche io faccio fatica a coprire il tutto, cerca di approfondire, se sei interessato all'argomento, ancora di più :) )

p.s Che le contromisure siano alla portata di tutti è una fortuna in mano ai pochi che della tutela fanno professione.
 
Dai perscontato che nel panorama internazionale vengano rispettate e aggiornate le linee guida relative all'aggiornamento del protocollo tls per quanto riguarda la sicurezza.

No, no, lungi da me!
Solo che credo che il bello del Penetration Testing o dell'Ethical Hacking in generale sia sempre figurarsi il copione peggiore e spremere le meningi (con una sana dose di culo) per avere risultati soddisfacenti. Credo che la cosa che genera maggior fomento sia sempre mettere insieme il sapere e dare vita a nuove opere, possibilmente in linea con la legalità. Per il resto ci sono siti che l'HTTPS nemmeno sanno dove sta di casa e possono essere utilizzati come cavie per imparare qualcosa alla base. E da lì al superarmato Facebook ci sono un miliardo di sottocategorie.

Basti pensare al caso che hai citato tu o all'exploit che uccide HSTS manipolando l'orologio della vittima e portando a scadenza il ttl del certificato, che sta scritto su Wikipedia tra l'altro, non occorre andare assai lontano.
Mi sono addirittura imbattuto in tutorial per clonare alcuni certificati e/o decriptare gli HTTPS con wireshark (da verificare, eh), quindi volendo è ovvio che la falla può sempre starci.

In linea di massima non vengono prese in considerazione per quanto riguarda le applicazioni web tutte quelle vulnerabilità che hanno un incidenza privata (lato utenza ad esmepio xss-reflected & mitm) anzi le responsabilità vengono spesso scaricate appunto sull'utente che non si mantiene aggiornato in termini di sicurezza teorica e applicativa.

Su questo punto non ho proprio idea di cosa stai parlando, se ti va di spiegarmi meglio ho le orecchie aperte!

p.s Che le contromisure siano alla portata di tutti è una fortuna in mano ai pochi che della tutela fanno professione.

Non c'era alcuna remora velata, spero tu non abbia frainteso, ho profondo rispetto per le competenze professionali.

Ti ringrazio infinitamente per questo share di documentazione da cui sono pronto ad attingere per saziare la curiosità.
Poi non sono a conoscenza, per esempio, di tool di Informaion Gathering che diano un valido apporto in termini di verifica degli exploit per questi protocolli, sono ignorante, esistono per caso? Magari potrei aggiungerli alla mia "armeria" :D
 
Stato
Discussione chiusa ad ulteriori risposte.