Un viaggio tecnico nella sicurezza del web server più diffuso nel mondo enterprise
Dopo vent’anni passati a smontare e rimontare infrastrutture, posso dirvi con certezza che Microsoft IIS (Internet Information Services) è come quella vecchia automobile che tutti conoscono ma pochi sanno guidare davvero. È il web server che alimenta milioni di applicazioni enterprise, dagli intranet aziendali ai portali governativi, eppure la sua superficie di attacco rimane sorprendentemente poco compresa anche da molti professionisti del settore.
In questo articolo vi guiderò attraverso un percorso che va dalla ricognizione iniziale fino alle tecniche di fuzzing avanzato, esplorando le vulnerabilità che ho visto compromettere infrastrutture critiche. Non sarà un tutorial per script kiddies, ma un’analisi tecnica approfondita pensata per chi vuole capire davvero cosa succede sotto il cofano.
Il Recon: Dove Tutto Inizia
Fingerprinting: Riconoscere IIS tra la Folla
Prima di poter attaccare, dobbiamo sapere con cosa abbiamo a che fare. IIS ha delle impronte digitali distintive che un occhio esperto riconosce immediatamente. Quando analizzo un target, cerco sempre questi indicatori:
Header HTTP Caratteristici:
Server: Microsoft-IIS/10.0
X-Powered-By: ASP.NET
X-AspNet-Version: 4.0.30319Questi header sono come le targhe di un veicolo: ci dicono non solo che stiamo guardando un IIS, ma anche quale versione e quale stack tecnologico. La versione 4.0.30319, per esempio, ci dice che stiamo guardando un .NET Framework 4.x — informazione cruciale perché determina quali vulnerabilità potrebbero essere presenti.
Cookie di Sessione:
ASP.NET_SessionId— il classico cookie a 24 caratteri esadecimaliASPSESSIONID— la variante legacy per ASP classico
Questi cookie sono come le impronte digitali lasciate da un sospettato: confermano la presenza di tecnologie Microsoft e ci danno indizi sulla configurazione.
Shodan: Il Motore di Ricerca che Spaventa i CISO
Per chi fa ricognizione su larga scala, Shodan è uno strumento irrinunciabile. Le query che utilizzo per identificare infrastrutture IIS includono:
http.title:"IIS"
Ssl:"Azienda Target S.p.A." http.title:"IIS"
Ssl.cert.subject.CN:"target.it" http.title:"IIS"
Immaginate Shodan come un catalogatore universale che fotografa l'intero internet. Ogni dispositivo connesso, ogni server web, ogni webcam mal configurata viene indicizzata. Quando cerco infrastrutture IIS, non sto solo cercando server web: sto mappando la superficie di attacco di intere organizzazioni.La Vulnerabilità del Tilde: Un’Anomalia Storica
Il Concetto di 8.3: Quando il Passato Ritorna
Per capire la vulnerabilità del tilde (~), dobbiamo fare un salto indietro di trent’anni, ai tempi di MS-DOS. In quell’era preistorica dell’informatica, i nomi dei file dovevano rispettare una convenzione rigida: 8 caratteri per il nome, 3 per l’estensione (da qui “8.3”).
Un file chiamato documento-importante-finanziario-2024.txt sarebbe stato automaticamente convertito dal sistema in qualcosa come DOCUME~1.TXT. Windows, per mantenere la compatibilità con software legacy, continua a generare questi “nomi corti” per ogni file creato — a meno che non venga esplicitamente disabilitato.
Il Problema: Information Disclosure Attraverso il Tilde
Ecco dove la storia diventa interessante per noi penetration tester. IIS, in determinate configurazioni, risponde in modo diverso a richieste che utilizzano questi nomi corti. La tecnica, scoperta anni fa ma ancora rilevante, funziona così:
Esempio Pratico: Immaginate un server con un file segreto chiamato password-amministratore.txt che normalmente non è linkato da nessuna parte e non compare nelle directory listing.
Windows avrà creato automaticamente un nome corto: PASSWO~1.TXT
Se inviamo una richiesta come:
GET /PASSWO~1.TXT HTTP/1.1
Host: target.comIl server IIS potrebbe rispondere con un 404 Not Found se il file non esiste, ma con un 400 Bad Request o 403 Forbidden se il file esiste. Questa differenza comportamentale è tutto ciò che serve a un attaccante per enumerare file nascosti.
Enumerazione Carattere per Carattere
La tecnica diventa veramente potente quando la applichiamo in modo sistematico. Possiamo scoprire i nomi dei file lettera per lettera:
- Testiamo
A*~1*→ 404 = esistono file che iniziano con ‘A’ - Testiamo
B*~1*→ 400 = nessun file che inizia con ‘B’ - Testiamo
AD*~1*→ 404 = esistono file che iniziano con ‘AD’ - Testiamo
AE*~1*→ 400 = nessun file che inizia con ‘AE’
Procedendo in questo modo, possiamo ricostruire i primi 6 caratteri di qualsiasi file e i primi 3 dell’estensione. È come giocare a “Impiccato” contro il server web, dove ogni risposta HTTP ci dice se siamo sulla strada giusta.
Strumenti per l’Enumerazione Tilde
Nel corso degli anni ho visto evolversi molti strumenti per automatizzare questo processo:
IIS ShortName Scanner (Java):
bash
java -jar iis_shortname_scanner.jar 0 5 http://target.com/Questo strumento, sviluppato dalla comunità di ricerca sulla sicurezza, automatizza l’intero processo di enumerazione. I parametri 0 5 controllano la velocità e la profondità della scansione.
Burp Suite Extension: L’estensione “IIS Tilde Enumeration Scanner” integra questa capacità direttamente nel flusso di lavoro di Burp, permettendo di identificare la vulnerabilità durante i test manuali.
Nmap NSE Script:
bash
nmap -p80 --script http-iis-short-name-brute target.comPer chi preferisce un approccio più “leggero” e integrato nella suite di ricognizione standard, Nmap offre uno script dedicato.
Shortscan (Tool Moderno):
bash
shortscan https://target.com/Shortscan rappresenta l’evoluzione moderna di questi strumenti, più veloce e con migliori capacità di rilevamento dei falsi positivi.
Dal Nome Corto al Nome Completo: La Fase di Fuzzing
La Logica del Fuzzing Post-Enumerazione
Una volta che abbiamo identificato un nome corto come ADMIN~1.ASP, sappiamo che esiste un file ASP che inizia con “ADMIN” seguito da altri caratteri. Qui entra in gioco il fuzzing mirato.
Il fuzzing, in questo contesto, non è l’attacco cieco che molti immaginano. È un’operazione chirurgica: abbiamo un indizio (i primi 6 caratteri) e dobbiamo completare il puzzle.
Esempio di Wordlist Mirata: Se abbiamo scoperto CONFIG~1, potremmo generare una wordlist con:
configuration.aspxconfigurator.aspxconfigurazione.aspconfig_backup.aspx
FFUF: Il Fuzzing Moderno
FFUF (Fuzz Faster U Fool) è diventato il mio strumento preferito per queste operazioni. La sua velocità e flessibilità lo rendono ideale per completare l’enumerazione IIS:
bash
Copy
# Fuzzing basico con wordlist dedicata
ffuf -w iis-wordlist.txt -u https://target.com/FUZZ
# Fuzzing con estensioni multiple
ffuf -w wordlist.txt -u https://target.com/FUZZ -e .aspx,.asp,.ashx
# Fuzzing basato su short name scoperto
ffuf -w /usr/share/wordlists/dirb/common.txt -u https://target.com/shortnameFUZZ.aspxLa chiave è l’intelligenza delle wordlist. Utilizzare wordlist generiche troppo ampie è inefficiente; utilizzare wordlist specifiche per IIS, come quelle condivise da ricercatori come Orwa Atyat (noto come OrwaGodfather), aumenta esponenzialmente le probabilità di successo.
Estensioni Critiche da Testare
Quando fuzzo un server IIS, do priorità a queste estensioni:
| Estensione | Significato | Pericolo |
|---|---|---|
.aspx | Active Server Pages .NET | Esecuzione codice, RCE |
.asp | Active Server Pages legacy | Esecuzione codice |
.ashx | HTTP Handler | API esposte, data leakage |
.asmx | XML Web Services | SOAP, potenziali XXE |
.config | File di configurazione | Credential exposure |
.zip, .bak | Backup | Source code disclosure |
Vulnerabilità Comuni e Tecniche di Exploitation
Information Disclosure: Quando IIS Parla Troppo
I server mal configurati sono come persone che parlano troppo quando sono nervose: rivelano informazioni che non dovrebbero. IIS ha diversi “tics” di questo tipo:
Trace.axd Abilitato: Il tracing di ASP.NET, quando lasciato abilitato in produzione, espone informazioni sensibili come:
- ID di sessione
- Percorsi fisici dei file
- Valori dei parametri di richiesta
Una richiesta a https://target.com/trace.axd può rivelare l’intero flusso di esecuzione delle ultime richieste.
Errori Dettagliati: Quando customErrors è disabilitato in web.config, IIS mostra stack trace completi agli utenti. Un errore 404 su un file .aspx inesistente potrebbe rivelare:
Versione ASP.NET: 4.0.30319
Percorso fisico: C:\inetpub\wwwroot\app\
Assembly caricati: ...Per un attaccante, queste informazioni sono oro: sanno esattamente cosa stanno attaccando e dove cercare.
ViewState Senza MAC: La Porta per il Deserialization Attack
Il ViewState di ASP.NET è un meccanismo di persistenza dello stato della pagina. Quando la validazione MAC (Message Authentication Code) è disabilitata, diventa possibile manipolare il ViewState per eseguire attacchi di deserializzazione — una delle classi di vulnerabilità più pericolose nel mondo .NET.
Immaginate il ViewState come una scatola che il server invia al client, dicendo “tieni questo per me e rimandamelo alla prossima richiesta”. Se il server non verifica che la scatola non sia stata manomessa (assenza di MAC), un attaccante può inserire oggetti malevoli nella scatola che verranno eseguiti quando il server la riapre.
Web.config Upload: La Chiave del Regno
Uno degli scenari più critici che ho incontrato è la possibilità di caricare o modificare il file web.config. Questo file controlla ogni aspetto dell’applicazione ASP.NET, e la sua modifica permette:
Esecuzione di Codice Arbitrario tramite XAMLX:
<configuration>
<system.webServer>
<handlers>
<add name="xamlx" path="*.xamlx" verb="*"
type="System.Xaml.Hosting.XamlHttpHandlerFactory, System.Xaml.Hosting" />
</handlers>
</system.webServer>
</configuration>Con questa configurazione, un file .xamlx può contenere codice C# che verrà eseguito dal server:
xml
<mca:CSharpValue x:TypeArguments="sd:Process">
System.Diagnostics.Process.Start("cmd.exe", "/c calc.exe");
</mca:CSharpValue>Questa tecnica, purtroppo ancora rilevante su server legacy, trasforma un semplice upload di file in un’execution remota completa.
Tecniche Avanzate: Oltre le Basi
IIS Modules Malevoli: La Persistenza Invisibile
Negli ultimi anni ho osservato un’evoluzione preoccupante nelle tecniche di post-exploitation su IIS. Gli attaccanti non si limitano più a web shell tradizionali (file .aspx modificati), ma installano moduli IIS nativi — DLL che vengono caricate direttamente nel processo w3wp.exe.
Questi moduli sono particolarmente insidiosi perché:
- Sopravvivono ai riavvii del server
- Non compaiono nelle scansioni di file tradizionali
- Operano con i privilegi del worker process IIS
- Possono intercettare e modificare ogni richiesta HTTP
Una web shell tradizionale è come un ladro che entra dalla finestra: se chiudi la finestra, il ladro è fuori. Un modulo IIS malevolo è come un ladro che si costruisce una stanza segreta dentro casa tua: puoi cambiare tutte le serrature che vuoi, lui rimane lì.
HTTPAPI/2.0 e Virtual Hosting
Un comportamento interessante che ho notato su IIS moderni è la gestione degli errori HTTPAPI/2.0. Quando IIS riceve una richiesta con un header Host non riconosciuto o per un dominio non configurato, risponde con un errore generico che può rivelare:
plain
404 Not Found
Microsoft-HTTPAPI/2.0Questo ci dice che il server è in ascolto, ma il virtual host richiesto non esiste. È un indicatore che il server potrebbe ospitare più siti e che vale la pena fare brute forcing dei virtual host.
Mitigazione e Best Practices
Dopo vent’anni a rompere sistemi, posso dirvi che la maggior parte delle vulnerabilità IIS non sono bug del software, ma errori di configurazione. Ecco le contromisure fondamentali:
Disabilitare i Nomi 8.3
powershell
Copy
# Registro di sistema
HKLM\SYSTEM\CurrentControlSet\Control\FileSystem
NtfsDisable8dot3NameCreation = 1Attenzione: Questa modifica non elimina i nomi corti esistenti, ma impedisce la creazione di nuovi. Per rimuovere quelli esistenti, è necessario ricreare le directory interessate.
Configurazioni di Sicurezza Base
- Disabilitare il tracing in produzione:xmlCopy
<configuration> <system.web> <trace enabled="false" /> </system.web> </configuration> - Abilitare custom errors:xmlCopy
<customErrors mode="On" defaultRedirect="~/Error.aspx" /> - Abilitare ViewState MAC:xmlCopy
<pages enableViewStateMac="true" /> - Rimuovere header informativi:xmlCopy
<httpProtocol> <customHeaders> <remove name="X-Powered-By" /> </customHeaders> </httpProtocol>
Principio del Minimo Privilegio
IIS dovrebbe sempre girare con privilegi minimi. L’account del pool di applicazioni non dovrebbe mai avere:
- Accesso in scrittura a directory di sistema
- Permessi su file di configurazione sensibili (
applicationHost.config) - Capacità di eseguire comandi di sistema arbitrari
Conclusione: La Mente dell’Attaccante
Quando analizzo un server IIS, non vedo solo un software: vedo l’intersezione tra decisioni umane (configurazioni, patch, architetture) e vincoli tecnici (compatibilità legacy, performance, funzionalità). La vulnerabilità del tilde è un esempio perfetto: non è un bug nel senso tradizionale, ma una feature (la compatibilità 8.3) che diventa un rischio quando esposta a Internet.
Il vero skill del penetration tester non è nell’esecuzione di tool automatici, ma nella capacità di vedere queste connessioni — di capire che un comportamento apparentemente innocuo (rispondere a richieste con il carattere tilde) può aprire la porta a una compromissione completa.
La sicurezza di IIS, come qualsiasi tecnologia, non è uno stato ma un processo. Richiede comprensione tecnica profonda, attenzione ai dettagli di configurazione, e la consapevolezza che il nemico più pericoloso è spesso la compatibilità con il passato.
