Seppur non strettamente collegati all'attività di attacco, i messaggi di errore o gli alert generati dal server e presentati al client contengono (di solito) informazioni interessanti da utilizzare eventualmente per aumentare le possibilità di successo di altri attacchi.
Informazioni da uno script
Chi ha utilizzato asp si ricorderà di come fosse frequente (se non si prendevano le necessarie contromisure) ottenere una reazione come l'errore riportato qui sotto, se per esempio una funzione che aspettava dei parametri numerici in ingresso riceveva una stringa.
Microsoft VBScript runtime error '800a000d' Type mismatch: '[string: "'"]' /script/anagrafica.asp, line 190
Apparentemente, questo errore non rivela niente di eclatante. Ci sta però dicendo che il tipo di dato atteso per la query non è quello effettivamente ricevuto. Altri messaggi tipici ( che a tutt'oggi spesso ritroviamo) interessano l'area db e altro non sono che segnalazioni di imprecisioni o errori nella query o nella connessione al db stesso (errori odbc)
Microsoft OLE DB Provider for ODBC Drivers error '80040e14' [Microsoft][ODBC SQL Server Driver][SQL Server]Incorrect syntax near the keyword 'or'. /login.asp, line 11
Qui abbiamo scoperto che stiamo utilizzando un Odbc per SqlServer.
Dalla traccia dello stack
Per quanto riguarda le applicazione in .net o java, capita sovente di avere come risultato di un errore, la descrizione dello stack dell'errore. Questa descrizione proveniente dal server contiene diverse informazioni riguardo l'applicazione. Elenchiamone alcune:
- La descrizione dell'errore che si è verificato che può tornare utile ad esempio per focalizzarci su un attacco DoS (Denial of Service).
- I nomi delle classi (e spesso anche dettagli su package ecc) che in un qualche modo hanno avuto a che fare con l'errore.
- Spesso viene riportato anche il numero di riga che corrisponde all'errore (attenzione che potrebbe non corrispondere alla riga del codice sorgente!)
- Spesso vengono riportati dettagli riguardo alla versione del framework in uso.
Dai messaggi di debug
Il massimo per un pentester è accorgersi che l'applicazione in caso di errore visualizza i messaggi "standard" di debug.
Questo può accadere, per esempio, agli sviluppatori .Net che si dimenticano, in ambiente di produzione, di impostare a false il valore della proprietà debug. Il dettaglio della descrizione dell'errore a volte è sorprendente.
Da Internet
Un altra grande fonte di informazioni, sopratutto quando si lavora su un'applicazione sviluppata da terzi, è quello di ricercare i messaggi di errore (o i codici di errore) su internet. L'utilizzo di framework o snippet di codice "preconfezionato" ci permette di accelerare il lavoro di sviluppo di un'applicazione web; per contro tutti possono utilizzare lo snippet o il framework.
Questo è un bene se sappiamo quello che facciamo. Se non siamo sicuri, un'implementazione errata si trasformerà probabilmente in un errore seguito da un messaggio di errore. Se questo messaggio di errore è visualizzato durante un vulnerability assesment o un penetration test, il primo passo che deve compiere il tester sarà quello di cercare su internet qualche traccia dell'errore ricevuto da altri utenti/sviluppatori.
Trovato lo stesso errore in un forum, chi aveva postato l'errore descrive la struttura della applicazione che guarda caso ha generato il medesimo messaggio. Il tester può ora pensare che l'applicazione sotto esame abbia la stessa struttura applicativa dell'utente del forum..quindi può procedere all'analisi con una conoscenza in più!
