Domanda Aiuto per possibile vulnerabilità

[NSteel]

Buonasera a tutti,
grazie in anticipo a chiunque di voi mi dedicherà anche un solo minuto del suo tempo per farmi più chiarezza sulla seguente problematica: è possibile vedere le richieste HTTPs (usando come protocollo TLS 1.2/1.3, no protocollo SSL) se faccio l'ipotesi di essere un MITM?
Ho visto dei video che apparentemente fanno finta di essere un "server" che prende la richiesta e la inoltrano al server destinatario della richiesta legittima. Facendo così è come se creassero due distinti canali a cui il MITM ha accesso e riesce a vedere le richieste passare. Dato che non vi hanno mostrato come fare, volevo chiedervi: è una cosa fattibile o meno? Perché ho riscontrato un applicativo che utilizzo quotidianamente che tramite un parametro che viene passato tramite GET ed una parte del campo cookie posso praticamente loggarmi come admin in tale applicativo.
Essendo però un applicativo che viaggia tramite HTTPs (TLS 1.2/1.3), se non si riesce a cifrare le richieste TLS che girano nella rete (assumendo che io sia un MITM) mi sentirei di dire che il prodotto è sicuro.

Grazie a chiunque risponda!

 

[JunkCoder]

I parametri in query string della GET fanno comunque parte dell'header ed è cifrato con TLS. Se sei un MitM non puoi decifrare il traffico passivamente, però se il tuo applicativo non controlla a dovere il certificato o la chain of trust puoi crearne uno self-signed e stabilire una connessione con quello (creando a tua volta una connessione con la vera chiave al vero applicativo), se però parliamo di un normale browser vedresti un avviso di sicurezza che ti avvisa dei problemi di certificato e ti chiede se vuoi proseguire, se non lo fai il segreto nell'url non verrà inviato (stessa cosa se è una richiesta in background da javascript).

 

[NSteel]

Grazie mille per la risposta.
Ragionando per assurdo che schiaccio avanti ed utilizzo il mio browser anche se vedo il problema di certificato (spoiler: accedendo all'applicativo mi da un problema di certificato perchè non l'ho importato per "pigrizia" pertanto è molto verosimile questo scenario) quanto è facile/difficile mettere in piedi questo meccanismo di MitM?
Inoltre, secondo la tua esperienza, potrebbe essere considerato un bug questo scenario (tipo "replay attack")? Perchè ogni azione che viene eseguita su questo applicativo viene passato tramite get un codice ed il cookie. Quindi una volta ottenuti posso praticamente effettuare qualsiasi chiamata e fare tutto perchè sono riutilizzabili tranquillamente (ovviamente se becco un admin che sta lavorando).

 

[JunkCoder]

Se anche il tuo certificato è self-signed e non ti accorgeresti della differenza può essere tanto facile che basta impostare ngnix come reverse proxy e loggare o usare burp suite, a quel punto non sai con chi stai scambiando i dati, non importa se sono cifrati o no se hai scambiato la chiave con l'attaccante.

 

[NSteel]

Grazie mille per la risposta.
Questo prodotto, ngnix é facilmente installabile per il test che devo fare? Potrebbe avvicinarsi in un caso real? E soprattutto.. potrebbe essere considerato un bug o meno questo comportamento dell’applicativo?

Grazie

 

[JunkCoder]

Grazie mille per la risposta.
Questo prodotto, ngnix é facilmente installabile per il test che devo fare? Potrebbe avvicinarsi in un caso real? E soprattutto.. potrebbe essere considerato un bug o meno questo comportamento dell’applicativo?

Grazie

Non credo si possa definire bug in senso stretto, è una misconfiguration che può compromettere la sicurezza in determinate situazioni in questo caso. Il fatto di usare un certificato self-signed non sarebbe un problema se fosse pinned nella client application (o se lo importi manualmente nel browser), il problema è che ogni volta il browser ti chiede se ti fidi del certificato e tu sei portato a cliccare avanti senza controllare, tutto qui.

Nginx è un webserver, puoi configurarlo in pochi minuti per fare da reverse proxy con un altro server e certificato ma non è facilmente configurabile per chi non lo ha mai usato, forse burp suite ti risulterà piú intuitivo visto che ha estensioni per mitm e il modulo interceptor fatto a posta.

 

[NSteel]

Non credo si possa definire bug in senso stretto, è una misconfiguration che può compromettere la sicurezza in determinate situazioni in questo caso. Il fatto di usare un certificato self-signed non sarebbe un problema se fosse pinned nella client application (o se lo importi manualmente nel browser), il problema è che ogni volta il browser ti chiede se ti fidi del certificato e tu sei portato a cliccare avanti senza controllare, tutto qui.

Nginx è un webserver, puoi configurarlo in pochi minuti per fare da reverse proxy con un altro server e certificato ma non è facilmente configurabile per chi non lo ha mai usato, forse burp suite ti risulterà piú intuitivo visto che ha estensioni per mitm e il modulo interceptor fatto a posta.

Grazie mille quindi ipotizzando questo scenario
Client A: client legittimo che sta facendo operazioni sull'applicativo (In LAN)
Server A: server che espone l'applicativo su porta 443 (Quindi HTTPs con TLS 1.3)
Io posso utilizzare un Client B che vede il traffico passare dal client A verso il server A e attraverso BurpSuite, modulo Interceptor riesco ad intercettare le chiamate HTTPs per prendere ottenere Cookie e Richieste GET/POST?

Grazie per la delucidazione, molto chiaro

 

[JunkCoder]

Grazie mille quindi ipotizzando questo scenario
Client A: client legittimo che sta facendo operazioni sull'applicativo (In LAN)
Server A: server che espone l'applicativo su porta 443 (Quindi HTTPs con TLS 1.3)
Io posso utilizzare un Client B che vede il traffico passare dal client A verso il server A e attraverso BurpSuite, modulo Interceptor riesco ad intercettare le chiamate HTTPs per prendere ottenere Cookie e Richieste GET/POST?

Grazie per la delucidazione, molto chiaro

Ricordavo male, in Burp Suite Proxy l'intercept funziona solo per il pc in locale. Per fare un MitM di questo tipo B fa da server per Client A e da client per il Server A. Il client A crede di parlare con il server A, invece il server B gli presenta il suo certificato, se viene accettato la connessione viene stabilita, a quel punto il Server B gira tutte le richieste tramite il Client B che impersona il Client A e contatta il vero Server A, per loggare tutto e far tornare indietro le risposte fino al Client A.

Con nginx potresti configurare una cosa simile:

server {
   listen 443 ssl;
   server_name example.yourdomain.com;
   ssl_certificate  /path/to/your/certificate;
   ssl_certificate_key  /path/to/your/certificate/key;
   ssl_prefer_server_ciphers on;

   location / {
        proxy_pass https://serverA:443;
   }
}

Il certificato puoi generarlo self-signed tramite openssl.
Usando log_format puoi specificare cosa far salvare a ngnix nei file di log (ad esempio i parametri delle GET)

 

[NSteel]

Ricordavo male, in Burp Suite Proxy l'intercept funziona solo per il pc in locale. Per fare un MitM di questo tipo B fa da server per Client A e da client per il Server A. Il client A crede di parlare con il server A, invece il server B gli presenta il suo certificato, se viene accettato la connessione viene stabilita, a quel punto il Server B gira tutte le richieste tramite il Client B che impersona il Client A e contatta il vero Server A, per loggare tutto e far tornare indietro le risposte fino al Client A.

Con nginx potresti configurare una cosa simile:

server {
   listen 443 ssl;
   server_name example.yourdomain.com;
   ssl_certificate  /path/to/your/certificate;
   ssl_certificate_key  /path/to/your/certificate/key;
   ssl_prefer_server_ciphers on;

   location / {
        proxy_pass https://serverA:443;
   }
}

Il certificato puoi generarlo self-signed tramite openssl.
Usando log_format puoi specificare cosa far salvare a ngnix nei file di log (ad esempio i parametri delle GET)

Molto gentile!
Settimana prossima che sono in ufficio proverò e ti faccio sapere. Come teoria ho capito, vediamo se riesco a farlo anche in pratica. Grazie mille.