Protocolli dinamici e randomizzati a Deter attacker

Question

Protocolli dinamici e randomizzati a Deter attacker

#1 da (1 voti)
#2 da (0 voti)

1

Immagina un protocollo che cambia periodicamente.
Cosa succede se l'ordine di questi campi è stato modificato molto?
Un punto nel tempo potrebbe essere il protocollo

{ Payload, Checksum, Length, Flags, ID }

Il prossimo punto nel tempo diventa

{ Flags, Checksum, Payload, ID, Flags }

Dopo un periodo prestabilito, il protocollo cambia di nuovo.

Come attaccante, l'obiettivo è sapere cosa si tratta di un bersaglio per sfruttarlo o trovare buchi. Se dovesse cambiare periodicamente, potrebbe essere più difficile per un attaccante sapere come sfruttare una debolezza. Anche il codice sottostante, i campi, la lunghezza del campo, lo schema di codifica / modulazione e altre cose potrebbero essere modificati.
Ovviamente il client / server dovrebbe essere sincronizzato con queste modifiche. Questo suona come sicurezza attraverso l'oscurità, ma potrebbe ritardare l'aggressore. È già stato fatto prima? In caso contrario, sembra che potrebbe essere utile?

attacks defense protocols

posta dopobop 31.03.2016 - 00:50

fonte

2 risposte

Leggi altre domande sui tag attacks defense protocols

Come evitare l'abuso dell'endpoint del web server da un client canaglia? comprensione del certificato client - pfx sul generale

score 1 · Answer 1

If it were to change periodically it could be harder for an attacker to know how to exploit a weakness. ... the underlying code ... Of course the client/server would need to be in sync with these changes.

Come hai scoperto tu stesso: client e server dovrebbero essere sincronizzati. Ciò significa che ci dovrebbe essere uno stato tenuto da entrambi i lati o che il server deve essere in grado di estrarre lo stato dai messaggi dei client e che il client non dovrebbe essere in grado di inventare il proprio stato. Se guardi più da vicino questi requisiti, hai già le forme tipiche della crittografia simmetrica (vale a dire lo stato si riferisce alla chiave di crittografia) o dell'autenticazione (simile al cookie di sessione). Entrambe sono tecniche consolidate e semplici, quindi perché inventarne una nuova più complessa e in realtà non offre una protezione migliore:

Con lo stato di un cookie di sessione, per prima cosa controlla se il client è autenticato prima di interpretare il resto dei dati. Non c'è bisogno di cambiare il formato per il resto perché viene comunque ignorato se l'autenticazione fallisce.
I dati di crittografia devono essere prima decrittografati. Non è necessario modificare il formato perché il carico utile viene ignorato se la decrittografia fallisce.

Alla fine, la sicurezza dipende solo dall'intensità con cui lo stato comune può essere indovinato dall'attaccante. Non importa se questo stato è una chiave di crittografia, un cookie di sessione o qualche algoritmo che descrive i cambiamenti di formato. Solo che quest'ultimo è più complesso da implementare rispetto alle altre due soluzioni.

score 0 · Answer 2

Sembra che tu stia guardando il TCP stesso, ma il parser dovrebbe determinare il layout in qualche modo in una situazione fuori banda. Potresti costruirlo nello stack di comunicazione e ruotare sulla base di un segreto pre condiviso, ma alla fine verrebbe scoperto. Probabilmente una finestra di 6 mesi?

Inoltre, qualsiasi regolarità dei dati rende più facile capire dove sono i limiti di byte e capire lo schema.