Nel corso della storia si sono verificati innumerevoli fallimenti dovuti all'eccessiva fiducia dei pianificatori nella qualità delle loro soluzioni. Che si tratti dell'inaffondabile Titanic o dell'inespugnabile linea Maginot della Seconda Guerra Mondiale, l'eccessiva fiducia in un'unica soluzione ha causato più volte terribili catastrofi.
Nel mondo della sicurezza informatica non è diverso. Se avete una difesa di cybersecurity con un'unica soluzione, siete in cerca di guai.
I pericoli di una soluzione unica per la sicurezza
In questo articolo analizzeremo un caso particolare in cui ciò si è verificato con un fornitore di e-commerce. Questa azienda ha costruito una nuova API di login per la sua applicazione mobile. Ha rafforzato la sicurezza richiedendo la crittografia RSA a 1024 bit della password nel payload di qualsiasi richiesta di autenticazione.
È una buona idea. Dopotutto, rende quasi inutili gli attacchi man-in-the-middle, poiché le informazioni di autenticazione non sarebbero leggibili dall'uomo. Si presenta come una stringa codificata in base64 e crittografata RSA. Dal momento che le richieste di autenticazione provenivano dalla loro stessa applicazione, si trattava di un approccio piuttosto valido. Pollici in su.
Ma... c'è dell'altro. Non è stata una buona idea pensare che questa misura di sicurezza fosse l 'unica necessaria. Invece di continuare a migliorare la sicurezza con misure come l'imposizione di un massimo di tentativi di password falliti, hanno deciso di spedirlo e di passare ad altre attività di sviluppo.
Sebbene possa sembrare che tutto vada bene, c'era un difetto significativo nella loro soluzione. La chiave pubblica a 1024 bit era facilmente osservabile utilizzando JADX per decompilare la loro applicazione mobile.
Salvando la chiave pubblica in un file locale, un aggressore potrebbe scorrere tutte le password che desidera, criptandole tutte in base alla chiave pubblica dell'obiettivo e annullando completamente il lavoro di protezione dell'endpoint di autenticazione.
Poiché non esisteva un limite massimo di tentativi di password falliti su questo endpoint, ho scritto uno script bash che avrebbe automatizzato il controllo di tutte le password che volevo. Ho dimostrato il problema a questo fornitore di e-commerce con un semplice conto alla rovescia per la mia password che avevo impostato per dimostrare il problema:
#!/bin/bash |
Ecco l'output del mio script:
Welcome 10 |
Vediamo come funziona. In un for Il ciclo inizia con un messaggio di benvenuto per annunciare quale cifra sto inserendo nel tentativo di raggiungere la password che ho impostato per questo proof-of-concept. Poi, vediamo la password e il successivo valore criptato che verrà inviato all'API. (Non pensavate davvero che avrei usato una password così semplice, per non parlare di rivelarla qui, vero?)
Infine, invio la risposta dell'API alla verifica della password. Per i primi sei tentativi, ottengo una risposta non riuscita, ma quando finalmente arrivo alla mia password iper-sicura (😉 ) di faster4wardL'API mi permette di entrare con il mio normale ambito di autorizzazione.
Alla faccia dei payload di autenticazione criptati con RSA...
Come evitare questo stesso tipo di errore
Ora che abbiamo identificato il problema, cosa possiamo fare? Cominciamo con l'errore fondamentale che ci ha portato a questo punto. Ci sono molte cose da fare per proteggere con successo qualsiasi applicazione web, poiché non esiste una pallottola d'argento per proteggere un'applicazione! Nel nostro esempio specifico, oltre alla crittografia RSA, è necessario adottare altre misure.
- Assicuratevi che le vostre chiavi di crittografia siano sicure.
- Imporre un numero massimo di tentativi di verifica della password non riusciti, con conseguente blocco dell'account.
- Implementare la limitazione della velocità di richiesta.
La sicurezza di un sistema esposto a Internet deve abbracciare il principio della difesa in profondità: È necessario distribuire più livelli di difesa sull'intera superficie della vostra presenza sul Web, non solo sui punti che ritenete più interessanti o ovvi da difendere.
Fortunatamente, Linode offre molte ottime funzioni di sicurezza integrate nella nostra piattaforma e ci sono molti standard di settore per affrontare alcuni vettori di attacco comuni. Alcune di queste soluzioni si applicano al vostro account Linode, mentre altre si applicano direttamente ai vostri Linode. Vediamo entrambi i tipi di protezione.
Proteggere l'accesso dell'amministratore al proprio account Linode
Se qualcuno riesce a entrare nel vostro account Linode, il gioco è fatto. Entrare nei vostri Linode diventa banale. Questo è il motivo per cui gli account Linode sono costruiti tenendo conto della sicurezza. Per impostazione predefinita, ogni account Linode deve essere protetto con una verifica telefonica. Linode richiede anche la configurazione di domande e risposte di sicurezza per il recupero dell'account.
Oltre alla verifica telefonica, è possibile configurare l'autenticazione a due fattori utilizzando un codice di autenticazione a tempo con una sola password (TOTP). Sebbene non sia obbligatorio per gli account, si consiglia vivamente di attivare la 2FA, in quanto è molto più sicura di una semplice password e delle domande di sicurezza, e persino più sicura dei codici di verifica telefonica.
È disponibile un altro livello di sicurezza per evitare completamente la password di Linode. È possibile utilizzare una fonte di autenticazione di terze parti (TPA). Utilizzando questo metodo, è possibile configurare metodi sicuri di accesso su una fonte di terze parti di propria scelta (al momento sono supportati Google e GitHub). In questo modo si riducono le possibilità che una password trapelata faccia perdere l'accesso al proprio account Linode.
Un ultimo metodo per proteggere il vostro account è quello di impostare utenti specifici che possano accedere a parti specifiche del vostro account. In questo modo è possibile impostare determinate autorizzazioni su ciò che i sub-utenti possono fare sul vostro account, riducendo ulteriormente la possibilità che un utente malintenzionato possa danneggiare il vostro account.
Introdurre questa separazione delle preoccupazioni tra gli utenti che accedono alle varie parti della vostra infrastruttura è una buona pratica. Naturalmente, se siete un team di una sola persona, questo potrebbe non essere necessario. Tuttavia, se si dispone di una vera e propria separazione delle preoccupazioni, ciò consente di assicurarsi che non vengano apportate modifiche non autorizzate all'account o all'infrastruttura.
Proteggere i Linode
Proteggere il vostro account è sicuramente importante, ma proteggere i vostri server e la vostra infrastruttura potrebbe essere ancora più importante. Dopo tutto, la maggior parte degli aggressori cercherà di entrare nella vostra infrastruttura attraverso l'infrastruttura stessa piuttosto che attraverso il vostro provider di hosting. Linode vi copre anche in questo caso.
Uno dei migliori punti di partenza è l'App Linode Marketplace. Sia che abbiate bisogno di implementare soluzioni di sicurezza come Haltdos WAF per bloccare il traffico dannoso alle porte dei vostri server, sia che vogliate installare con un solo clic uno stack di monitoraggio come una configurazionePrometheus + Grafana , non è molto più facile proteggere e monitorare il vostro stack di Marketplace.
Le applicazioni di terze parti non sono le uniche soluzioni a disposizione. Linode Cloud Firewall è un'ottima soluzione che si configura facilmente direttamente dal Cloud Manager. Anche l'uso di Linode Cloud Firewall e di un firewall sul proprio Linode è un'ottima idea.
Un'altra buona pratica è assicurarsi che i server siano protetti dagli attacchi DDoS. Con Linode, difendete l'intera infrastruttura da questi attacchi per impostazione predefinita, senza alcun costo! Non c'è nemmeno bisogno di fare qualcosa per configurarlo.
Conclusione
Ci sono molte altre cose da dire sulla sicurezza, ma per ora questo è sufficiente. In definitiva, evitate che la soluzione intelligente a un problema vi faccia dimenticare di occuparvi degli altri aspetti che potrebbero mancare nel vostro approccio alla sicurezza.
Commenti