Correzione della vulnerabilità della tilde di IIS

9

Uno dei nostri server IIS (IIS 7.5, Server 2008 R2) è apparentemente "vulnerabile" al problema di divulgazione di tilde Short Filename .

Tuttavia, sto facendo fatica a risolvere il problema. Finora l'ho fatto

Disabilitato i nomi di file 8.3, arrestato il server Web, ricreato la directory del sito e riavviato il servizio
Aggiunta una regola di filtro per una tilde nell'URL:

inserisci qui la descrizione dell'immagine

Aggiunta una regola di filtro per una tilde OVUNQUE:

inserisci qui la descrizione dell'immagine

IISRESET un paio di volte
Controllato che web.configha aggiunto le regole di filtro pertinenti

.. ma comunque, non riesco a far passare il test al mio sito :

java -jar ~/temp/IIS-ShortName-Scanner-master/IIS_shortname_scanner.jar http://www.example.com

[...SNIP...]

Testing request method: "TRACE" with magic part: "/webresource.axd" ...
Testing request method: "DEBUG" with magic part: "" ...
Testing request method: "OPTIONS" with magic part: "" ...
Testing request method: "GET" with magic part: "" ...
Reliable request method was found = GET
Reliable magic part was found = 
144 requests have been sent to the server:

<<< The target website is vulnerable! >>>

Cos'altro devo fare per risolvere questo problema?

EDIT: ecco DIR /xche sembra non mostrare nessun nome di file 8.3:

inserisci qui la descrizione dell'immagine

ed ecco il pool di app per il sito (tutti gli altri siti sul server sono uguali):

inserisci qui la descrizione dell'immagine

EDIT2 : Verifica che non siano rimasti 8,3 nomi di file:

inserisci qui la descrizione dell'immagine

security iis

— KEND
fonte

Un modo rapido per ricontrollare se ci sono 8,3 nomi in una directory è dir /x. Il tuo sito potrebbe contenere collegamenti simbolici a directory che contengono ancora nomi 8.3 generati automaticamente.

— Brian,

Nessun segno di nomi di file 8.3 ho paura :(

— KenD

L'installazione di .NET 4.0 (che non è vulnerabile a questo exploit) è l'altra soluzione alternativa per questo problema. Hai già provato questo?

— HopelessN00b,

.Net 4 è installato e tutti i pool di applicazioni sul server sono impostati per l'uso .NET Framework v4.0.30319- vedi screenshot nella modifica sopra.

— KenD,

4

Wow. Probabilmente afferrare le cannucce qui, ma sei sicuro che lo scanner di vulnerabilità che stai utilizzando sia affidabile? Prova uno strumento diverso o prova a eseguire l'attacco manualmente e vedi cosa vedi.

— HopelessN00b,

6

Prova a cercare i nomi di file brevi esistenti con fsutil:

fsutil 8dot3name scan /s /v E:\inetpub\wwwroot

E spogliali se vengono trovati:

fsutil 8dot3name strip /s /v E:\inetpub\wwwroot

Anche guardando il registro con la parte magica vuota ( magic part: ""), mi chiedo che potrebbe essere un bug nel POC. Questa riga in config.xml sembra che abbia una virgola aggiuntiva dopo /webresource.axd:

<entry> key="magicFinalPartList">
 <![CDATA[\a.aspx,\a.asp,/a.aspx,/a.asp,/a.shtml,/a.asmx‌,/a.ashx,/a.config,/a.php,/a.jpg,/webresource.axd,,/a.xxx]]>
</entry>

Ho chiesto a dev. via Twitter e ha risposto:

Per rari casi in cui non sono state richieste estensioni. Ma, recentemente, ciò ha causato solo più problemi! Lo rimuoverò ora.

L'ho rimosso dal file di configurazione. Questa era la seconda lamentela, quindi era il momento giusto per questo cambiamento.

Quindi, sembra che tu sia al sicuro ora :)

— beatcracker
fonte

Temo che non ci siano cambiamenti - vedi "EDIT2" nel mio post originale :(

— KenD

1

Guardando il registro con la parte magica vuota ( magic part: ""), mi chiedo, potrebbe essere un errore nel POC. Questa riga in config.xml sembra avere una virgola extra dopo /webresource.axd:

<entry key="magicFinalPartList"><![CDATA[\a.aspx,\a.asp,/a.aspx,/a.asp,/a.shtml,/a.asmx,/a.ashx,/a.config,/a.php,/a.jpg,/webresource.axd,,/a.xxx]]></entry>

— beatcracker

È molto interessante - anche se, guardando indietro attraverso le revisioni, quella "doppia virgola" è stata nel codice per un po '. Rimuoverlo significa che il test ora viene eseguito senza alcun errore evidente ...

— KenD

Ah, sei al sicuro, vedi aggiornamento!

— Beatcracker

Tutto quel lavoro e siamo sempre stati al sicuro :) Grazie per l'aiuto e per contattare lo sviluppatore!

— KenD,

1

anche "NOTA: la modifica della voce del Registro di sistema NtfsDisable8dot3NameCreation interessa solo i file, le cartelle e i profili creati dopo la modifica. I file già esistenti non sono interessati."

Nota: sebbene la disabilitazione della creazione del nome file 8.3 aumenti le prestazioni dei file in Windows, alcune applicazioni (16 bit, 32 bit o 64 bit) potrebbero non essere in grado di trovare file e directory con nomi di file lunghi.

— albert riojas
fonte

0

Sfortunatamente, l'unico modo per affrontarlo è un fastidioso insieme di giravolte, a seconda della versione di Windows, che disabilita la possibilità di generare nomi 8.3.

Per la tua versione di Windows:

Per disabilitare la creazione del nome 8.3 su tutte le partizioni NTFS, digitare il comportamento fsutil.exe impostare disable8dot3 1 al prompt dei comandi con privilegi elevati, quindi premere Invio.

Fonte: http://support.microsoft.com/kb/121007

— Dave Holland
fonte

L'articolo che hai collegato spiega come disabilitare la creazione del nome file 8.3, non il motivo per cui risolve il problema.

— Michael Hampton,

Ho già disabilitato i nomi dei file 8.3 e dir /xnon mostra nomi brevi nella directory del sito

— KenD,

Ken, era questo il metodo che facevi prima?

— Dave Holland,

Si; Ho anche visto il riferimento a un'impostazione del registro, ma il fsutilcomando sembra impostare semplicemente quella chiave per me.

— KenD,

0

Non sono esattamente sicuro che lo script funzioni e come si configura la tua rete, ma che ne dici di filtrare attraverso qualcosa di fronte al server IIS (anche se è solo un dispositivo virtuale in una macchina virtuale)? Vale a dire, si imposta un IPS con una regola che elimina specificamente il traffico relativo a quel particolare problema?

— dtbnguyen
fonte