Diversão e pena de prisão com reconhecimento de servidores IIS

 (mll.sh)
1 pontos por GN⁺ 3 시간 전 | 1 comentários | Compartilhar no WhatsApp
  • A tela padrão do IIS não é um beco sem saída, e sim o ponto de partida para reconhecimento em bug bounty; é possível reduzir o universo de servidores expostos e vhosts ocultos com Shodan, Google dorks e cabeçalhos de resposta
  • Requisições HTTP/1.0, HTTPAPI 2.0 404, certificados SSL e brute force do cabeçalho Host servem como pistas iniciais para encontrar IPs internos, nomes de host do Exchange e hosts virtuais
  • A enumeração de shortnames com til (~) do IIS, baseada no DOS 8.3, pode revelar nomes curtos de arquivos e diretórios mesmo com listagem de diretório desativada; GitHub Search, BigQuery, LLMs e crunch ajudam a inferir os nomes completos
  • O fuzzing específico para IIS/.NET deve mirar primeiro em caminhos e extensões de alto valor como web.config, trace.axd, elmah.axd, appsettings.*.json e .aspx/.ashx/.asmx/.config
  • Exposição de web.config, normalização de caminho com sessões cookieless, confusão de caminho em reverse proxy, NTFS alternate data stream, bypass de extensão em upload e HPP mostram como erros de configuração e comportamentos legados podem virar superfície de ataque

Métodos de reconhecimento para encontrar servidores IIS

  • Alvos IIS podem ser encontrados primeiro em mecanismos de busca e serviços de busca de ativos na internet
  • Consultas no Shodan permitem filtrar servidores IIS pela combinação do certificado SSL do domínio-alvo, nome da organização e http.title:"IIS"
    • Os exemplos de alvo incluem servidores de staging, painéis administrativos esquecidos e ferramentas internas expostas à internet
    • Além do Shodan, fofa, censys, netlas e odin também fornecem índices diferentes da internet
  • Google dorking é usado para encontrar páginas indexadas com sinais de IIS
    • A pasta aspnet_client e _vti_bin são tratadas como indícios de IIS
    • ext:aspx encontra páginas ASP.NET e sugere que há IIS por trás
    • Buscas com wildcard no formato site:*.target.com e site:*.*.target.com servem para achar subdomínios aninhados que a enumeração básica de subdomínios pode não encontrar
  • Cabeçalhos de resposta são a pista mais fácil para identificar IIS
    • Server: Microsoft-IIS/10.0
    • X-Powered-By: ASP.NET
    • Em verificações em larga escala, httpx ou nuclei podem ser usados para montar uma lista de alvos IIS

Pistas iniciais obtidas após confirmar IIS

  • Algumas configurações de IIS, especialmente front-ends de Exchange ou OWA, podem expor informações internas em requisições HTTP/1.0
  • O cabeçalho Location pode conter um IP interno como https://192.168.5.237/owa/
  • O cabeçalho X-FEServer pode revelar o hostname interno de um servidor Exchange
  • Esse tipo de dado pode levar a exposição de informações útil em etapas posteriores

Automação e busca de hosts virtuais ocultos

  • Depois de obter uma lista de alvos IIS, é possível executar nuclei com tags como microsoft, windows, asp, aspx, iis, azure, config, exposure para reduzir trabalho repetitivo
  • HTTPAPI 2.0 404 nem sempre significa que realmente não há nada ali
    • A instância IIS pode estar vinculada a um host virtual específico, e o 404 aparecer porque o cabeçalho Host da requisição não corresponde
  • Há duas formas de encontrar vhosts ocultos
    • Buscar o hostname necessário no subject ou nos campos SAN do certificado SSL
    • Se o certificado não ajudar, fazer brute force de vhost com ffuf e uma wordlist no cabeçalho Host
  • Ao encontrar o hostname correto, a aplicação real pode responder em vez de um 404 genérico

Enumeração de shortnames com til no IIS

  • Por causa de um comportamento herdado das antigas regras de nomes de arquivo 8.3 do DOS, o IIS pode permitir enumerar nomes curtos de arquivos e diretórios com requisições especiais
  • Mesmo com listagem de diretório desativada, podem aparecer fragmentos como WEB~1.CON, GLOBAL~1.ASA, SITEBA~1.ZIP, ADMIN~1
  • shortscan é usado como ferramenta para enumeração de shortnames no IIS
  • burp’s IIS Tilde Enumeration Scanner também pode ser usado como alternativa
  • Existem várias formas de expandir um nome curto para o nome completo do arquivo
    • LLM: gera candidatos de nomes de arquivo que contenham o fragmento do shortname
    • GitHub code search: pesquisa nomes reais de arquivos com base nos 6 primeiros caracteres antes de ~1 e na extensão
    • GSNW: recebe fragmentos de shortname e coleta nomes de arquivos correspondentes no GitHub code search
    • GitHub-IIS-Shortname-Generator: gera wordlists de forma semelhante
    • shortnameguesser: consulta várias fontes a partir da saída do scanner para criar uma wordlist direcionada ao alvo
  • A abordagem com BigQuery busca caminhos de arquivos que combinem com o padrão do shortname no dataset público do GitHub no Google BigQuery
  • Se LLM, GitHub e BigQuery falharem, dá para usar crunch para gerar uma wordlist com as combinações restantes e testar com ffuf
    • Também vale verificar variações com hífen, underscore, espaço codificado em URL e ausência de separador
    • O Windows permite espaços em nomes de arquivo, e o IIS também pode servi-los

Fuzzing específico para IIS/.NET

  • Usar apenas wordlists genéricas pode deixar passar arquivos e endpoints próprios do ecossistema IIS/.NET
  • Entre os alvos de alto valor a verificar primeiro estão
    • /web.config, /web.config.bak, /web.config.old, /web.config.txt
    • /global.asax
    • /trace.axd
    • /elmah.axd
    • /connectionstrings.config
    • /appsettings.json, /appsettings.Development.json, /appsettings.Staging.json, /appsettings.Production.json, /appsettings.Local.json
    • /secrets.json
    • /WS_FTP.LOG
    • /_vti_pvt/service.cnf
  • trace.axd é o visualizador de trace do ASP.NET e, se estiver ativo, pode expor logs de requisição/resposta com cabeçalhos, cookies e às vezes credenciais
  • elmah.axd pode permanecer como um endpoint de debug que o desenvolvedor não desativou e exibir logs de erro
  • As extensões a fuzzar em IIS incluem .asp, .aspx, .ashx, .asmx, .wsdl, .wadl, .config, .xml, .zip, .txt, .dll, .json
  • Wordlists úteis incluem
    • secLists IIS.txt: inclui caminhos básicos do IIS, handlers comuns e arquivos legados
    • orwa’s iis.txt: apresentada como uma lista IIS usada em programas reais de bug bounty
    • orwa’s aspx.txt: focada em endpoints .aspx
    • wfuzz iis.txt: lista pequena focada em caminhos IIS conhecidos por serem vulneráveis
    • dirbuster-ng iis.txt: lista compacta voltada a fraquezas específicas de IIS
    • Assetnote wordlists: geradas automaticamente a partir de dados reais de crawling, atualizadas mensalmente, com recomendação de listas ASP e ASPX
    • OneListForAll: onelistforallshort.txt serve para execução direcionada ao alvo; a lista completa, para execuções longas
  • Como o IIS não diferencia maiúsculas de minúsculas, wordlists com mixed-case podem gerar requisições duplicadas
    • É comum usar listas em lower-case ou normalizar com tr '[:upper:]' '[:lower:]' | sort -u

web.config e exposição de código

  • Se web.config puder ser lido via path traversal, arquivo de backup exposto indevidamente ou descoberta por shortname, o impacto em alvos IIS pode ser grande
  • O web.config do IIS pode conter machine keys usadas para assinatura e criptografia de ViewState
  • Com essas machine keys, é possível forjar payloads maliciosos de ViewState serializado e chegar a execução remota de código baseada em desserialização
  • ysoserial.net é uma ferramenta que ajuda a gerar payloads quando a key está disponível
  • Se houver parâmetro de download ou leitura de arquivo, o fluxo natural é testar ../../web.config e variações com URL encoding
  • O recurso legado de cookieless session do ASP.NET pode inserir tokens de sessão no caminho da URL no formato (S(X))
    • O IIS pode remover esse segmento durante a normalização do caminho, permitindo contornar bloqueios de acesso ao diretório /bin
    • Newtonsoft.Json.dll por si só é uma biblioteca padrão e pode não conter segredos da aplicação
    • Se você obtiver DLLs reais da aplicação, poderá descompilá-las com dotPeek ou dnSpy para encontrar credenciais hardcoded, chaves de API, lógica de endpoints internos e implementações de autenticação customizadas

Normalização de caminho, NTFS, upload e bypass de WAF

  • Quando o IIS fica atrás de um reverse proxy ou atua como reverse proxy, diferenças na normalização de caminho podem levar a bypass de controle de acesso
    • O proxy pode encaminhar um caminho codificado achando que é outro recurso, enquanto o IIS decodifica %2f para / e interpreta traversal, entregando um caminho protegido
  • IIS 7.5 e versões semelhantes podem permitir bypass de basic authentication por causa de alternate data streams do NTFS e do comportamento de index allocation
    • O módulo de autenticação pode não reconhecer o caminho como protegido, enquanto o sistema de arquivos o interpreta como o diretório real
  • Em funcionalidades de upload, mesmo que .aspx e .asp sejam bloqueados, o IIS pode permitir stored XSS por meio de extensões que ele serve como HTML por padrão
    • Exemplos de extensões renderizadas como HTML: .cer, .hxt, .htm
    • Exemplos de extensões com vetores XSS baseados em XML: .dtd, .mno, .vml, .xsl, .xht, .svg, .xml, .xsd, .xsf, .svgz, .xslt, .wsdl, .xhtml
  • O IIS remove pontos no fim do nome do arquivo, então filtros de upload podem ser burlados com nomes como shell.aspx., shell.aspx.., shell.aspx...
  • Para server-side includes, são sugeridas extensões como .stm, .shtm, .shtml
  • Quando um WAF bloqueia o payload, é possível dividir o conteúdo com HTTP Parameter Pollution em parâmetros duplicados
    • IIS e ASP.NET, por padrão, concatenam valores de parâmetros duplicados com vírgula, o que pode permitir que o payload seja remontado atrás do WAF

Lições e materiais que ficam de bug bounty em IIS

Leituras relacionadas

1 comentários

 
GN⁺ 3 시간 전
Comentários no Hacker News

  • O motivo de colocarem uma página de aterrissagem do IIS na frente de todo honeypot é justamente atrair os black hats
    Só de pensar que eles perderam horas correndo atrás do próprio rabo já dá uma alegria enorme

    • Não deveria parar por aí; seria divertido colocar um servidor IIS real na frente e empilhar honeypots como uma matrioska para ver até onde eles conseguem entrar
    • A menos que você esteja rodando o honeypot dentro da faixa de IP de uma organização real, no fim das contas o que vai receber é só tráfego de bots
      Os black hats de ponta miram alvos grandes, e os de baixo escalão se concentram em presas fáceis encontradas no Shodan ou em zero-days de aplicações que eles mesmos descobriram
    • Ruído é uma camada de segurança muito subestimada
    • Abri as portas do Plex e do Nintendo Switch e os scans vieram como loucos
      Se houver mais formas de sacanear scanners de porta, quero saber
    • Criar URLs como aspnet_client/admin.php e fazer retornar cabeçalhos do WebObjects também parece um bom passatempo

  • Quando dizem que “o IIS tem um comportamento legado herdado das antigas regras de nomes de arquivo DOS 8.3”, fico me perguntando se isso quer dizer que o comportamento do sistema operacional subjacente fica exposto, combinado com o fato de que o document root padrão do IIS é C:\Inetpub
    No Windows 10/11, nomes 8.3 vêm ativados por padrão na unidade C, mas desativados por padrão nas outras unidades
    PS> (Get-ItemProperty -Path 'HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion').DisplayVersion → 24H2
    fsutil 8dot3name query C: retorna 8dot3 name creation is ENABLED, enquanto fsutil 8dot3name query U: retorna DISABLED

  • O estilo de escrita do texto é bem peculiar

    • Em vários momentos achei que tinha sido escrito pelo Claude

  • Uau, isso trouxe uma nostalgia forte
    Houve uma época em que existiam tantos scanners de IIS que os logs do servidor ficavam praticamente inutilizáveis
    Havia uma vulnerabilidade de directory traversal em que bastava codificar ../ na URL, e isso incendiou a internet inteira por meses

    • Essas tentativas de traversal ainda aparecem com muita frequência, junto com ataques de script kiddie contra PHP/WordPress

  • Ainda existe lugar usando IIS?

    • Existe. Se você usa Windows Server e IIS, a máquina entra no domínio e normalmente tem um SPN no formato HOST/MACHINE.DOMAIN
      Serviços do Windows e identidades de App Pool do IIS fazem login com (g)MSA ou contas virtuais (NT Service*), então um ambiente de Kerberos gerenciado funciona direito sem você precisar lidar manualmente com troca de senha a cada 30/60/90 dias
      Dá para autenticar no MS SQL Server com Kerberos e também entrar com Kerberos no fluxo OAuth2 de outros aplicativos web, e tudo simplesmente se encaixa
      WinRM também funciona a partir do shell padrão do Windows sem configuração extra, e tecnicamente até dá para contornar 2FA, porque na prática é assim que funciona
      No Linux também dá, mas a chance de ficar bem configurado depende muito do ambiente de trabalho e, pela minha experiência até agora, não é alta
    • Departamentos de TI corporativos ainda usam demais
    • Converso com frequência com gente que ainda roda IIS no Windows Server
      Existem muitos aplicativos antigos, e entre eles há vários bastante importantes
    • Alguns bancos ainda usam IIS
      Se for uma empresa grande o bastante para manter uma intranet, em algum lugar — talvez em toda parte — vai ter IIS rodando
      Ele se integra muito bem ao AD, o que torna tarefas bastante complexas ridiculamente simples
      O mundo está migrando para a AWS e o uso está caindo, mas isso também é só se amarrar de novo ao produto proprietário de um fornecedor só (Amazon), então é uma burrice parecida. A diferença é que dessa vez você nem possui o hardware
      A TI do setor público gosta de IIS. Se você olhar sites de impostos municipais ou de imóveis, há uma boa chance de encontrar um monte de scripts .aspx
      Também vi isso em aplicativos web do setor público europeu, onde aplicações .NET customizadas com backend em SQL Server frequentemente tocam administrações locais inteiras
      Na Ásia, especialmente China e Taiwan, parecia que gostavam de IIS e o usavam para hospedar todo tipo de coisa
      O mundo em geral realmente seguiu em frente, mas há uma quantidade enorme de código legado sobre IIS operando cidades e organizações importantes, e isso não vai mudar
      Se você acha isso ruim, ainda existem lugares rodando AS/400, Lotus Notes e Novell GroupWise na web
    • Sim. E, falando como alguém que não entende muito, o que se deveria usar hoje em dia?
      Pense numa empresa pequena que produz código corporativo em .NET Framework, onde tudo é Windows, os clientes não aceitam nuvem, SOAP ainda domina, e o único responsável por TI não teve tempo de ligar para o que aconteceu depois de 2010
      Uma reescrita completa é irrealista, eles querem algum ganho de segurança, mas não têm fôlego para mexer a fundo nas configurações nem podem apostar em algo complexo como Kubernetes

  • Queria ver uma análise dessas sobre nginx também

  • Considerando navegadores desktop em geral, o design está muito bem feito, e o conteúdo também é excelente

    • Não sei se isso foi ironia, mas no meu navegador desktop a barra lateral fica sobreposta ao painel principal, com texto em cima de texto
      Ainda assim, gosto do resto da apresentação
    • Chamar de “excelente” é ser bem generoso com um conteúdo em nível de script kiddie do começo dos anos 2000
      O autor ainda parece precisar aprender o quanto a civilização depende de pessoas que, sem grande motivo, não escolhem ser cruéis umas com as outras

  • Não entendi o que está acontecendo com a barra lateral à esquerda sobrepondo o texto principal