Hole Punching ha aggiunto vulnerabilità sul lato client

4

I siti web e i server spesso vengono violati quando è presente una vulnerabilità nel codice lato server. La perforatura UDP o TCP mette tale rischio sugli utenti dell'applicazione quando le connessioni diventano peer-to-peer?

Prendiamo ad esempio la pratica chiaramente vulnerabile dell'esecuzione di un input non criticato. Ovviamente questa pratica non dovrebbe essere eseguita in base alla progettazione, ma questo genere di cose accade troppo spesso per errore. In una configurazione tradizionale, se user_a interagisce con user_b avremo prima user_a invia input al server, il server elaborerebbe i dati e quindi invierà qualcosa a user_b . Con la perforatura, otteniamo un peer-to-peer tra i due utenti e quindi user_a invia i dati a user_b e user_b lo elabora per se stesso. Se fosse presente una vulnerabilità nel modo in cui l'input è stato elaborato dal server (in questo caso eseguendolo senza disinfettare), la vulnerabilità potrebbe altrettanto facilmente essere presente sul lato client, consentendo a user_a di iniettare e eseguire direttamente il codice su user_b's macchina.

Se dovessi trovare una grave vulnerabilità in un'applicazione di perforazione (Skype e altri servizi VoIP, alcuni giochi in tempo reale multiplayer, ecc.), c'è qualcosa che impedisce a un hacker malintenzionato di avere una backdoor diretta nel sistema di qualsiasi utente loro interagiscono? In caso contrario, i programmi peer to peer sono inutilmente rischiosi? C'è un modo tutto per mitigare questo rischio per le persone che creano queste applicazioni? E le persone che usano queste applicazioni? Programmi come Skype lasciano gli utenti a livelli eccessivi di rischio (più che tipici)?

    
posta rp.beltran 30.03.2016 - 05:03
fonte

2 risposte

3

Considerare la modellizzazione delle minacce dei diversi scenari e il disegno di limiti di affidabilità ragionevoli. Vedo il modello del server client in questo modo:

client-1 | server | client-2

e la visualizzazione dei fori sarebbe simile a questa:

client-1 | server
client-2 | server
client-1 | client-2

In entrambi i casi, né client-1 né client-2 dovrebbero fidarsi implicitamente dei dati provenienti da un'origine esterna, quindi il codice client è responsabile della convalida dell'input.

Un altro modo per vederlo è se un utente malintenzionato è stato in grado di iniettare un MITM nella connessione, indipendentemente dal fatto che provenga da un server o da un client, dovresti fidarti di quei dati?

Peer-to-peer aumenta la facilità di un attacco aumentando il numero di potenziali vettori ostili. Inoltre obbliga il client ad aprire una porta di ascolto per comunicare (anche se è solo temporaneamente aperta), invece del client che origina sempre la connessione al server. Entrambi aumentano la superficie di attacco. A causa di questi aumenti, il cliente ha un rischio elevato di cadere preda di una vulnerabilità di 0 giorni.

Ma il rischio posto da un cliente vulnerabile non cambia: indipendentemente dal metodo di immissione, l'attaccante viola il cliente e causa danni. Il client deve ancora essere protetto allo stesso modo indipendentemente dal metodo di connessione.

    
risposta data 31.03.2016 - 15:12
fonte
2

La questione dipende in gran parte dall'architettura di sicurezza del software utilizzata, ma sì, ci sono stati casi in cui l'implementazione del software peer-to-peer permetteva ai cattivi attori di accedere ai file sui dischi rigidi di altre persone che partecipavano alla rete peer-to-peer. Allo stesso modo, alcuni di questi design consentono anche ai partecipanti, o ISP, di identificare i file che altri utenti condividono in remoto.

Ciò detto non significa che queste applicazioni siano necessariamente pericolose, alcune potrebbero essere molto sicure ma ogni volta che aggiungi un'applicazione che ascolta Internet (o altri sistemi) stai aumentando la superficie di attacco del computer. Questo rischio non è esclusivo del software peer-to-peer, ma è più probabile che il software peer-to-pe abbia porte di ascolto.

Di nuovo dipende molto dai modelli di sicurezza usati più di ogni altra cosa.

In generale, tutti i problemi di sicurezza con la protezione di protocolli non peer-to-peer si applicano anche ai protocolli peer-to-peer. Questo sembra essere un insieme di connessioni molti a molti piuttosto che uno a uno o uno a molti.

Ancora una volta, potrebbero essere davvero sicuri, ma ogni implementazione sarà molto diversa.

    
risposta data 30.03.2016 - 07:30
fonte

Leggi altre domande sui tag