Sisupoika
23-11-2009, 12:29
Fatto vero (come nei film :D), accaduto nella scorsa settimana, si tratta di un bell'esempio di information leakage, che ho menzionato in un vecchio post (http://www.hwupgrade.it/forum/showthread.php?p=27595055#post27595055).
a la twitter :asd:
Mi era stato assegnato il task di effettuare application security auditing per conto di una branch del gruppo che si occupa della Scandinavia, dal momento che loro curano una parte del development per conto loro, e stanno per acquistare licenze di Applicure Dot Defender (per gli interessati: http://www.applicure.com/) che utilizziamo di solito come application firewall per PCI DSS compliance.
Dunque, metto da parte i progetti su cui sto lavorando al momento, e mi metto a giocare un po' con le loro applicazioni - alcune semplicemente localizzate, altre completamente independenti dal development centralizzato in UK.
Spendo i primi due giorni giocando tra XSS, SQL injections, authentication, etc etc etc. Niente. Tutto sembra OK, hanno curato i particolari per bene, come da direttive.
Quando stavo ormai per abbandonare, mi viene in mente di dare una occhiata sui loro servers che usano per le applicazioni indipendenti, fisicamente in un data centre in Danimarca. Trovo diverse applicazioni ad uso interno (amministrazione di diverse cose) che non sono normalmente visibili all'esterno, ma che trovo una volta scovati i range di IPs che usano li'.
Bene, mi metto a giocare con alcune di queste applicazioni e subito mi sembrano meno curate delle applicazioni accessibili a publishers and partners.
Entro una quindicina di minuti, trovo una particolare schermata di amministrazione dove l'authenticazione e' OK, e diversi tentativi di SQL injections falliscono.
Ma fortunatamente, poiche' - contrariamente a quanto il 99% pensano :fagiano: - SQL injection non significa soltanto apice... con una delle combinazioni di codifica degli stessi tentativi ma in unicode, riesco alla fine ad ottenere almeno un errore.
L'applicazione e' .NET, e chi l'ha scritta non si e' preoccupato molto dei particolari o non prevedeva che qualcuno potesse trovare quella specifica applicazione. Il bello e' che l'errore mi mostra qualcosa di abbastanza divertente: si tratta ( di come mi e' poi stato confermato ) di un try....catch che, in caso di eccezioni non gestite, invia una email di notifica.
Fin qui nulla di strano, se non che il loro sys admin locale aveva cambiato - un paio di giorni prima - qualcosa nella configurazione del loro SMTP locale con restrizioni (anti spam) aggiuntive. Come risultato, il codice che si occupa di inviare notifiche email in quel particolare caso (in cui sono riuscito a far generare una eccezione non gestita), fallisce durante l'autenticazione poiche' adesso richiede TLS, e mi mostra mail server, username e password. :D
Il passo successivo e' ovvio: provo ad accedere al mail server con le stesse credenziali, avendo cura -ovviamente- di usare SSL/TLS e di settare il client cosi' che i messaggi scaricati non vengano cancellati dal server.
Di li' al divertimento puro il passo e' stato breve. :D
A parte vedere altre notifiche con altri dati moooolto interessanti, scopro in non molto tempo che la stessa mailbox e' utilizzata come mailbox amministrativa per
- providers di nomi a dominio
- mail servers
- altri servizi gestiti dallo staff del data centre (filtri Symantec e Postini per spam / antivirus, etc)
Senza dilungare troppo ulteriormente, entro qualche ora riesco ad accedere ai control panels per la gestione di diversi domini, e cambio il record SPF del principale dominio usato per la posta per consentirmi di inviare emails, come nulla fosse, con quel dominio da un mio VPS; genero dunque emails - che non verranno filtrate - all'apparenza inviate dal loro sys admin locale, attraverso cui induco alcuni sales account a loggarsi nel loro Outlook Web Access per verificare se la loro posta funzionasse ancora a seguito di aggiornamenti per la sicurezza bla bla bla :asd:
Un banale esempio di stupida ingegneria sociale, fra l'altro.
La pagina di login ovviamente e' un fake messo in piedi in neanche un'ora che si presta bene dopo aver fatto in modo che essa compaia nello stesso solito sito invece dell'originale gestito da exchange per OWA.
Ovviamente quella pagina non fa altro che ritornare un messaggio di errore (dopo avermi inviato i login :fagiano: ), al che 6-7 mi emailano (o meglio, al sys admin :D) facendomi sapere che hanno problemi a loggarsi. Al che rispondo, "OK, ci sto lavorando su bla bla bla". Dopo qualche risata nell'accedere alla posta di diversi membri dello staff, e nel vedere emails che non avrei dovuto vedere, rimetto OWA a posto e, sempre impersonando il loro sys admin (che non e' sempre nello stesso ufficio), invio una nuova richiesta al che loro mi confermano che adesso tutto funziona :asd:
Morale della favola:
- curate applicazioni interne cosi' come quelle che date in pasto al pubblico
- sebbene SQL injections sono sempre piu' difficili oggi giorno grazie a ORM, molti ancora ignorano che proteggersi da SQL injections non significa soltanto filtrare apici in SQL statements..
- se applicazioni interne vengono soltanto utilizzate come talil, mai esporle direttamente o indirettamente (dall'esterno si puo' utilizzare una VPN, no?)
- prestate la massima attenzione nella gestione di eccezioni nelle vostre applicazioni, altrimenti rischiate di esporre informazioni che dovrebbero essere mooolto riservate
- non usate le stesse mailbox per notifiche e per amministrazione di servizi vari
- usate sempre e comunque un application firewall come mod_security, dot defender etc, se possibile, ma cio' non significa non curarsi delle applicazioni...
- etc etc
Ciaps :asd:
a la twitter :asd:
Mi era stato assegnato il task di effettuare application security auditing per conto di una branch del gruppo che si occupa della Scandinavia, dal momento che loro curano una parte del development per conto loro, e stanno per acquistare licenze di Applicure Dot Defender (per gli interessati: http://www.applicure.com/) che utilizziamo di solito come application firewall per PCI DSS compliance.
Dunque, metto da parte i progetti su cui sto lavorando al momento, e mi metto a giocare un po' con le loro applicazioni - alcune semplicemente localizzate, altre completamente independenti dal development centralizzato in UK.
Spendo i primi due giorni giocando tra XSS, SQL injections, authentication, etc etc etc. Niente. Tutto sembra OK, hanno curato i particolari per bene, come da direttive.
Quando stavo ormai per abbandonare, mi viene in mente di dare una occhiata sui loro servers che usano per le applicazioni indipendenti, fisicamente in un data centre in Danimarca. Trovo diverse applicazioni ad uso interno (amministrazione di diverse cose) che non sono normalmente visibili all'esterno, ma che trovo una volta scovati i range di IPs che usano li'.
Bene, mi metto a giocare con alcune di queste applicazioni e subito mi sembrano meno curate delle applicazioni accessibili a publishers and partners.
Entro una quindicina di minuti, trovo una particolare schermata di amministrazione dove l'authenticazione e' OK, e diversi tentativi di SQL injections falliscono.
Ma fortunatamente, poiche' - contrariamente a quanto il 99% pensano :fagiano: - SQL injection non significa soltanto apice... con una delle combinazioni di codifica degli stessi tentativi ma in unicode, riesco alla fine ad ottenere almeno un errore.
L'applicazione e' .NET, e chi l'ha scritta non si e' preoccupato molto dei particolari o non prevedeva che qualcuno potesse trovare quella specifica applicazione. Il bello e' che l'errore mi mostra qualcosa di abbastanza divertente: si tratta ( di come mi e' poi stato confermato ) di un try....catch che, in caso di eccezioni non gestite, invia una email di notifica.
Fin qui nulla di strano, se non che il loro sys admin locale aveva cambiato - un paio di giorni prima - qualcosa nella configurazione del loro SMTP locale con restrizioni (anti spam) aggiuntive. Come risultato, il codice che si occupa di inviare notifiche email in quel particolare caso (in cui sono riuscito a far generare una eccezione non gestita), fallisce durante l'autenticazione poiche' adesso richiede TLS, e mi mostra mail server, username e password. :D
Il passo successivo e' ovvio: provo ad accedere al mail server con le stesse credenziali, avendo cura -ovviamente- di usare SSL/TLS e di settare il client cosi' che i messaggi scaricati non vengano cancellati dal server.
Di li' al divertimento puro il passo e' stato breve. :D
A parte vedere altre notifiche con altri dati moooolto interessanti, scopro in non molto tempo che la stessa mailbox e' utilizzata come mailbox amministrativa per
- providers di nomi a dominio
- mail servers
- altri servizi gestiti dallo staff del data centre (filtri Symantec e Postini per spam / antivirus, etc)
Senza dilungare troppo ulteriormente, entro qualche ora riesco ad accedere ai control panels per la gestione di diversi domini, e cambio il record SPF del principale dominio usato per la posta per consentirmi di inviare emails, come nulla fosse, con quel dominio da un mio VPS; genero dunque emails - che non verranno filtrate - all'apparenza inviate dal loro sys admin locale, attraverso cui induco alcuni sales account a loggarsi nel loro Outlook Web Access per verificare se la loro posta funzionasse ancora a seguito di aggiornamenti per la sicurezza bla bla bla :asd:
Un banale esempio di stupida ingegneria sociale, fra l'altro.
La pagina di login ovviamente e' un fake messo in piedi in neanche un'ora che si presta bene dopo aver fatto in modo che essa compaia nello stesso solito sito invece dell'originale gestito da exchange per OWA.
Ovviamente quella pagina non fa altro che ritornare un messaggio di errore (dopo avermi inviato i login :fagiano: ), al che 6-7 mi emailano (o meglio, al sys admin :D) facendomi sapere che hanno problemi a loggarsi. Al che rispondo, "OK, ci sto lavorando su bla bla bla". Dopo qualche risata nell'accedere alla posta di diversi membri dello staff, e nel vedere emails che non avrei dovuto vedere, rimetto OWA a posto e, sempre impersonando il loro sys admin (che non e' sempre nello stesso ufficio), invio una nuova richiesta al che loro mi confermano che adesso tutto funziona :asd:
Morale della favola:
- curate applicazioni interne cosi' come quelle che date in pasto al pubblico
- sebbene SQL injections sono sempre piu' difficili oggi giorno grazie a ORM, molti ancora ignorano che proteggersi da SQL injections non significa soltanto filtrare apici in SQL statements..
- se applicazioni interne vengono soltanto utilizzate come talil, mai esporle direttamente o indirettamente (dall'esterno si puo' utilizzare una VPN, no?)
- prestate la massima attenzione nella gestione di eccezioni nelle vostre applicazioni, altrimenti rischiate di esporre informazioni che dovrebbero essere mooolto riservate
- non usate le stesse mailbox per notifiche e per amministrazione di servizi vari
- usate sempre e comunque un application firewall come mod_security, dot defender etc, se possibile, ma cio' non significa non curarsi delle applicazioni...
- etc etc
Ciaps :asd: