Richieste HTTP e moduli Apache: Vettori di attacco creativi

Question

Domanda leggermente non ortodossa qui:

Attualmente sto cercando di rompere un Apache con una manciata di moduli personalizzati.

Ciò che ha generato il test è che Apache internamente inoltra richieste che considera troppo grandi (ad esempio 1 MB cestino) ai moduli collegati in modo appropriato, costringendoli a gestire i dati inutili e la mancanza di gestione nei moduli personalizzati ha causato Apache nella sua interezza per andare in fiamme. Ahi, ahi, ahi.

Questo particolare problema è stato risolto per fortuna, ma è sorta la questione se ci possano essere altre vulnerabilità simili.

In questo momento ho uno strumento a mia disposizione che mi consente di inviare una richiesta HTTP non elaborata al server (o meglio, dati grezzi attraverso una connessione TCP stabilita che potrebbe essere interpretata come una richiesta HTTP se seguisse la forma di uno , ad esempio "OTTIENI ...") e sto cercando di trovare altre idee. (Attacchi a livello di TCP come Slowloris e Nkiller2 sono non la mia attenzione in questo momento.)

Qualcuno ha un paio di buone idee come per confondere moduli personalizzati del server fino al punto di server auto-immolazione?

• Broken UTF-8? (Anche se dubito che Apache si preoccupi della codifica - immagino che si limiti a manipolare i byte non elaborati.)
• Roba che è a malapena troppo lunga, seguita da un byte 0, seguita da una cianfrusaglia?
• eccetera

Io non mi considero un ottimo tester (sto facendo questo per necessità e mancanza di manodopera, io, purtroppo, non hanno nemmeno una comprensione più di base dei meccanismi interni di Apache che mi avrebbe aiutato lungo), motivo per cui spero in una risposta perspicace o due o tre. Forse alcuni di voi hanno fatto test simili per i propri progetti?

(Se StackOverflow non è il posto giusto per questa domanda, mi scuso. Non so dove altro metterlo.)

Answer 1

A seconda di quali altri moduli che sono stati agganciati in, e che altro li attiva (o è solo troppo-grandi richieste?), Si potrebbe desiderare di provare alcuni dei seguenti:

• Bad codifiche - per esempio overfong utf-8 come hai detto, ci sono scenari in cui i moduli dipendono da questo, per esempio alcuni parametri.
• manipolazione dei parametri - di nuovo, a seconda di cosa fanno i moduli, alcuni parametri potrebbero interferire con essi, modificando i valori, rimuovendo i parametri previsti o aggiungendo quelli inattesi.
• in contrasto con l'altro suggerimento, vorrei guardare i dati che sono appena abbastanza breve, vale a dire uno o due byte inferiore al limite massimo, ma in diverse combinazioni - diversi parametri, intestazioni, richiedere il corpo, ecc
• Cerca su HTTP Request Smuggling (anche here e here) - intestazioni di richieste errate o combinazioni non valide, come più terminazioni di contenuto o terminatori non validi, potrebbe causare l'interpretazione errata del comando da parte di Apache.
• Considerare anche gzip, codifica chunked, ecc. È probabile che il modulo personalizzato implementa il controllo della lunghezza e la decodifica, fuori uso.
• E la richiesta parziale? Ad esempio, le richieste che causano una risposta 100-Continua o intervallo?
• Lo strumento fuzzing, Peach, consigliato da @TheRook, è anche una buona direzione, ma non aspettatevi un grande ROI per la prima volta.
• Se si ha accesso al codice sorgente, una revisione del codice di sicurezza focalizzata è una grande idea. Oppure, anche una scansione automatica del codice, con uno strumento come Coverity (come @TheRook menzionato), o uno migliore ...
• Anche se non si dispone dell'accesso al codice sorgente, si consideri un test di penetrazione della sicurezza, sia da parte di esperti consulente/pentito, o almeno con uno strumento automatico (ce ne sono molti là fuori) - es appscan, webinspect, netsparker, acunetix, ecc.

Answer 2

Apache è uno dei progetti software più incalliti sulla faccia del pianeta. Trovare una vulnerabilità nel HTTPD di Apache non sarebbe un'impresa da poco e consiglio di tagliare i denti su una preda più facile. Per confronto è più comune vedere vulnerabilità in altri HTTPD come questo in Nginx che ho visto oggi (nessuna battuta). Ci sono state altre vulnerablite di divulgazione del codice sorgente che sono molto simili, vorrei guardare a this e qui è another. lhttpd è stato abbandonato su sf.net per quasi un decennio e sono noti buffer overflow che lo influenzano, il che lo rende una divertente applicazione da testare.

Quando si attacca un progetto, è necessario verificare quale tipo di vulnerabilità è stata rilevata in passato. È probabile che i programmatori commettano ripetutamente gli stessi errori e che spesso emergano degli schemi. Seguendo questi schemi puoi trovare più difetti. Dovresti provare a cercare database vulnerabili come Nist's search for CVEs. Una cosa che vedrete è che i moduli Apache sono più comunemente compromessi.

Un progetto come Apache è stato pesantemente confuso. Esistono framework di fuzzing come Peach. Peach ti aiuta a fare i fuzzing in molti modi, in un modo che ti può aiutare fornendoti alcuni dati di test non corretti con cui lavorare.Lo sfarfallio non è un ottimo approccio per i progetti maturi, se segui questa strada indirizzerei lo apache modules con il minor numero di download possibile. (Attenzione progetti con davvero bassi download potrebbe essere rotta o difficili da installare.)

Quando una società è preoccupato per secuirty spesso pagare un sacco di soldi per un'analisi strumento fonte automatizzata, come Coverity. Il Department Of Homeland Security ha dato alla Coverity un sacco di soldi per testare progetti open source e Apache is one of them. Posso dirti in prima persona che ho trovato a buffer overflow con lo sfarfallio che Coverity non ha rilevato. Coverity e altri strumenti di analisi del codice sorgente come open source Rats generano molti falsi positivi e falsi negativi, ma aiutano a restringere i problemi che riguardano un codice di base.

(Quando ho eseguito RATS per la prima volta sul kernel Linux sono quasi caduto dalla sedia perché il mio schermo elencava migliaia di chiamate a strcpy() e strcat(), ma quando ho scavato nel codice tutte le chiamate in cui si lavora con testo statico, che è sicuro.)

Rischio di vulnerabilità uno sviluppo di exploit è a lot of fun. Raccomando di sfruttare le applicazioni PHP/MySQL ed esplorare The Whitebox. Questo progetto è importante perché mostra che ci sono alcune vulnerabilità del mondo reale che non possono essere trovate a meno che non si legge il codice riga per riga manualmente. Ha anche applicazioni del mondo reale (un blog e un negozio) che sono molto vulnerabili agli attacchi. Di fatto entrambe queste applicazioni sono state abbandonate a causa di problemi di sicurezza. Un web fuzzer dell'applicazione come Wapiti o acuentix violenterà queste applicazioni e quelle simili. C'è un trucco con il blog. Una nuova installazione non è vulnerabile a molto. Devi usare l'applicazione un po ', provare ad accedere come amministratore, creare un post di blog e poi scansionarlo. Quando si esegue il test di un'applicazione Web per SQL injection, assicurarsi che la segnalazione degli errori sia attivata. In php puoi impostare display_errors=On nel tuo php.ini.

Buona fortuna!