Skip to content
KitploitKITPLOIT
StrumentiBlog
Invia
StrumentiBlog
Invia

Strumenti di Hacking, PenTest e Cybersecurity per il tuo Arsenale di Sicurezza!

Kitploit è una directory di strumenti di hacking, cybersecurity e pentesting. Scopri gli ultimi aggiornamenti dei progetti per trovare vulnerabilità, analizzare sistemi, automatizzare i test e rafforzare la tua sicurezza.

··Feed·Contatto·Privacy·© 2026 Kitploit

Directory degli strumenti

Categorie

Vedi tutte le categorie
Loading categories
mellon — Strumento di attacco OSDP (e la parola elfica per amico) | Kitploit
Strumenti/GitHubGitHub/bishopfox/mellon
Analisi delle VulnerabilitàExploitCrittografiaPenetration TestingSicurezza Hardware
GitHubbishopfox/mellon

mellon

Strumento di attacco OSDP (e la parola elfica per amico)

Vedi Repository
114943 anni faRevisionato da Kitploit

Più Popolari

Vedi tutti →

Scopri gli strumenti più utilizzati dalla nostra community.

Esplora tutti gli strumenti

Sfoglia la nostra collezione di strumenti

Vedi tutti gli strumenti →
Condividi

Vulnerabilità OSDP sfruttate da questo strumento

Strumento di attacco OSDP (e la parola elfica per amico)

Attacco #1: La crittografia è opzionale

OSDP supporta, ma non richiede strettamente, la crittografia. Quindi la tua connessione potrebbe non essere nemmeno crittografata. L'attacco #1 consiste semplicemente nell'ascoltare passivamente e vedere se riesci a leggere i numeri delle carte sul cavo.

Attacco #2: Attacco di downgrade

Solo perché il controller e il lettore supportano la crittografia non significa che siano configurati per richiederne l'uso. Un attaccante può modificare il messaggio di risposta delle capacità del lettore (osdp_PDCAP) per pubblicizzare che non supporta la crittografia. Quando ciò accade, alcuni controller proseguono senza crittografia.

Attacco #3: Attacco in modalità installazione

OSDP ha una modalità di "installazione" quasi ufficiale che si applica sia ai lettori che ai controller. Come suggerisce il nome, dovrebbe essere utilizzata durante la configurazione iniziale di un lettore. In pratica, consente ai lettori di chiedere al controller qual è la chiave di crittografia di base (SCBK). Se il controller è configurato per rimanere permanentemente in modalità installazione, un attaccante può presentarsi sul cavo e richiedere la SCBK.

Attacco #4: Chiavi deboli

Il codice di esempio di OSDP spesso include chiavi di crittografia hardcoded. Chiaramente sono intese come esempi, dove l'utente dovrebbe generare le chiavi in modo sicuro da solo. Ma questo non viene spiegato né reso semplice per l'utente. E chiunque sia stato nel campo della sicurezza abbastanza a lungo sa che ciò che è predefinito probabilmente sarà presente in produzione.

Scarica lo strumento

Quindi, come vettore d'attacco, quando il collegamento tra lettore e controller è crittografato, vale la pena provare a enumerare alcune chiavi deboli comuni. Si tratta di chiavi AES a 128 bit, quindi non saremo in grado di enumerarle tutte. Né una parte significativa di esse. Ma possiamo colpire alcuni schemi comuni che si vedono quando qualcuno hardcoda una chiave:

  • Tutti valori a singolo byte. [0x04, 0x04, 0x04, 0x04 …]
  • Tutti valori di byte monotonamente crescenti. [0x01, 0x02, 0x03, 0x04, …]
  • Tutti valori di byte monotonamente decrescenti. [0x0A, 0x09, 0x08, 0x07, …]

Attacco #5: Cattura del set di chiavi

OSDP non ha un meccanismo in-band per lo scambio di chiavi. Ciò significa che un attaccante può:

  • Inserire un dispositivo di ascolto nascosto sul cavo.
  • Rompere / resettare di fabbrica / disabilitare il lettore.
  • Attendere che qualcuno dell'IT arrivi a sostituire il lettore.
  • Catturare il messaggio del set di chiavi (osdp_KEYSET) quando il lettore viene configurato per la prima volta.
  • Decrittografare tutti i messaggi futuri.

Configurazione di un banco di prova (Linux/MacOS)

Troverai il codice proof-of-concept per ciascuno di questi attacchi in attack_osdp.py. Dai un'occhiata al comando --help per maggiori dettagli sull'utilizzo. Questo è uno script Python, pensato per essere eseguito da un laptop con adattatori USB<-->RS485 come questi. Quindi probabilmente vorrai procurartene alcuni. Non deve essere per forza quel modello, comunque.

Se hai un controller che vuoi testare, allora bene. Usalo. Se non ce l'hai, abbiamo un controller OSDP volutamente vulnerabile che puoi usare qui: vulnserver.py.

Alcuni degli attacchi in attack_osdp.py si aspetteranno di essere un MitM completo tra un lettore e un controller funzionanti. Per testarli, potresti aver bisogno di tre adattatori USB<-->RS485, collegati insieme con una breadboard.

Problemi aggiuntivi a medio/basso rischio

Questi problemi non sono, singolarmente, sfruttabili ma rappresentano comunque un indebolimento del protocollo, dell'implementazione o del sistema complessivo.

  • I MAC sono troncati a 32 bit "per ridurre l'overhead". Questo è molto vicino (ma non del tutto, nei nostri calcoli) a un intervallo sfruttabile nella pratica.
  • Gli IV (che derivano dai MAC) sono ridotti similmente a 32 bit di entropia. Ciò causerà il riutilizzo degli IV, che è una grande bandiera rossa per un protocollo.
  • Le chiavi di sessione sono generate utilizzando solo 48 bit di entropia dal nonce RNG del controller. Questo sembra non essere possibile da enumerare offline per un attaccante che osserva, tuttavia. (A meno che non ci sfugga qualcosa, nel qual caso diventerebbe un problema critico.)
  • I numeri di sequenza sono composti da soli 2 bit, non fornendo sufficiente freschezza.
  • Viene utilizzata la crittografia in modalità CBC. GCM sarebbe una modalità di cifratura a blocchi più moderna e adatta ai protocolli di rete.
  • Le modalità SCS 15 e 16 sono essenzialmente "cifrari nulli" e non dovrebbero esistere. Non crittografano i dati.
  • Il byte di comando OSDP è sempre non crittografato, anche nel bel mezzo di una sessione Secure Channel. Questo è un enorme vantaggio per gli attaccanti, rendendo molto più semplice scrivere strumenti di attacco. Significa che un attaccante può sempre vedere quale "tipo" di pacchetto viene inviato, anche se altrimenti crittografato. Gli attaccanti possono capire quando le persone entrano con il badge, quando il LED si accende, ecc... Queste non sono informazioni che dovrebbero essere in chiaro.
  • SCBK-D (una chiave di crittografia predefinita hardcoded) non fornisce alcuna sicurezza e dovrebbe essere rimossa. Serve solo a offuscare e a dare un falso senso di sicurezza.