Caricamento file illimitato - Possibili exploit

I file specifici che vorrei seguire sarebbero:

1. php.ini
2. pagine PHP
   • È molto probabile che queste credenziali siano incorporate per l'accesso al database o ti diano degli indizi su dove cercare dopo.
3. my.cnf
   • File di configurazione MySQL
4. web.config
   • Potrebbero esserci alcune impostazioni utili in IIS che possono essere recuperate esaminando questo file.
5. machine.config
   • Come web.config ma a livello di macchina.
6. File cache
   • Potrebbero esserci alcuni dati interessanti nella cartella temp.

Questi sono quelli a cui riesco a pensare - una volta che inizi a scavare in questi file, probabilmente emergeranno altre idee.

Ending question: do you know other exploitation methods for the unrestricted file upload vulnerability if uploading a shell like above is not permitted?

1. Potresti provare a caricare un file che verrà eseguito al prossimo riavvio o metterlo in una posizione in cui un amministratore potrebbe accidentalmente eseguire il file.
2. È possibile eseguire un attacco DOS esaurendo lo spazio del disco sulla scatola.

Ci sono alcuni possibili scenari di attacco a cui posso pensare ..

Attacco al server:

Come già accennato, puoi usare PHP per aprire / leggere altri file sul sistema che possono dare credenziali o guidarti verso altri vettori di attacco.

Anche se la vulnerabilità di caricamento colloca il file dannoso in una directory specifica che potrebbe contenere determinate funzionalità di sicurezza, ciò non impedisce sempre allo script dannoso di scrivere un nuovo file nella directory superiore.

Puoi usare lo script per vedere chi sta eseguendo, controlla le autorizzazioni di altre cartelle sul sistema per vedere se sono scrivibili da quell'utente.

Un altro attacco evidente sarebbe l'accesso al database tramite il metodo di scansione di script e file di configurazione per le credenziali. Con questo database potresti essere in grado di decifrare la password, o confrontarla con una tabella arcobaleno se non salata.

Se sei in grado di leggere e scrivere su altri script sul server web, puoi backdoor il codice nella speranza di raccogliere la password dell'amministratore in testo normale invece di dover forzare le password con hash nel database.

Attacca l'utente:

Uno dei maggiori problemi con questo tipo di vulnerabilità è che si è in grado di eseguire il codice sul server come server. Questo ti dà accesso ai cookie degli utenti per quel sito, che possono contenere informazioni preziose, che potrebbero portare a una sessione dirottata.

Esiste anche la minaccia di diffusione di malware da parte del sito, attacchi di phishing e qualsiasi altro tipo di attacco che abbia come obiettivo la legittimità degli utenti nel sito.

Ci sono ovviamente più modi in cui è possibile attaccare il sistema con questo tipo di vulnerabilità. Gran parte della prossima fase dell'attacco dipenderà dai risultati della raccolta di informazioni che fai a questo punto.

Anche se non sempre è vero, è generalmente sicuro dire che se uno script può essere caricato da una terza parte non fidata ... il sistema è compromesso. Quello che fai a questo punto è solo una questione di intenti.