Como encontrei RCE em portugal.gov.pt

tl;dr: Encontrei uma vulnerabilidade simples de upload arbitrário de ficheiros que permite a execução de código (RCE) num sistema de plataformas amplamente usado em portais governamentais portugueses - um dos quais era portugal.gov.pt. O timeline de divulgação longo em entidades governamentais menos críticas levanta uma possível discussão sobre políticas de mitigação de vulnerabilidades em entidades públicas e a necessidade de um CVD nacional.

Introdução

Ao longo dos meus anos a navegar e a executar testes de intrusão a aplicações portuguesas, sempre me vi com o hábito de encontrar comportamentos operacionais estranhos.

Por vezes, levo a cabo esta curiosidade e tento analisar passivamente as aplicações - às vezes apenas ao inspecionar os pedidos HTTP ou as frameworks web que são usadas.

Reportei várias vulnerabilidades ao CERT de Portugal (CERT.PT) ao longo dos anos - seja porque me deparei com um portal governamental que tinha algumas vulnerabilidades ou uma aplicação comercial que permitia a um utilizador fazer compras de graça.

Este processo, geralmente conhecido como “responsible disclosure” ou “divulgação ética”, tem sido recentemente defendido pela “Agência Europeia para a Segurança das Redes e da Informação” ENISA e outras entidades europeias como um fator essencial nas operações passivas de cibersegurança.

A realidade por vezes não falada é que há muitos investigadaores de segurança que percorreram este processo e reportaram este tipo de vulnerabilidades críticas de forma ética - mesmo que NÃO existam diretrizes formais estabelecidas para o fazer de forma segura. No entanto, talvez hajam ainda mais pessoais que descubriram vulnerabilidades críticas em portais governamentais mas têm medo de as reportar devido à falta de diretrizes de divulgação.

Mas parece haver um impulso na direção certa. Desde 2016, vários países criaram um programa de divulgação de vulnerabilidades que ajudaria investigadores neste processo de divulgação ética:

• O Ato de Cibersegurança da UE - promovido pela CEPS taskforce - propõe um padrão para a criação de um programa de Divulgação de Vulnerabilidades Coordenadas (Coordinated Vulnerability Disclosure) para cada Estado-Membro Europeu.
• França, Bélgica, Lituânia e Países Baixos já criaram um programa CVD funcional.
• O CNCS e o CERT.PT comprometeram-se formalmente a desenvolver tal programa, marcando Portugal como ON THE POINT OF IMPLEMENTING pela ENISA.
• O Canadá também produziu recentemente uma proposta de CVD similar “See Something, Say Something”.

Algo parece estranho

Em 2020, após alguns ataques de alto perfil contra entidades portuguesas através de aplicações web vulneráveis, fiquei a perguntar-me - Quão vulneráveis estão os nossos portais governamentais?

Por curiosidade, acedi a <www.portugal.gov.pt> e comecei a ver múltiplos pedidos HTTP com o endpoint /wwwbase.

Dada a “peculiaridade” deste parâmetro - e após alguma pesquisa no Google, imediatamente identifiquei outros portais governamentais que contêm este diretório (torna-se fácil identificar os portais dada a peculiaridade deste caminho).

Um nome continuava a aparecer no código-fonte: Masterlink.

Isto foi descoberto como sendo o principal CMS ( Content Management Suite ) usado por estes websites para o controlo de páginas web e interface de backend.

Este parâmetro wwwbase parecia estranho - e a maioria das pessoas de segurança e até mesmo web developers achariam sua aparência peculiar - já que cria a pressuposto de que alguém seria capaz de acessar ficheiro presentes antes do diretório da aplicação base ao solicitar elementos sem wwwbase.

Isto e os seguintes outros indicadores deixaram-me ainda mais curioso sobre esta aplicação e suas funcionalidades:

• CMS aparentemente complexo e rico em funcionalidades
• Uso de ASP e ASP.NET (linguagem de programação antiga e por vezes sem manutenção)
• Usado principalmente em entidades governamentais públicas. (Infelizmente) Entidades públicas são menos propensas a realizar testes de intrusão internos que identifiquem possíveis problemas nestas aplicações, já que este é o caso - deixam-se expostos contra um possível atacante externo

Dada a variedade de websites que encontrei a usar esta plataforma CMS, decidi explorá-los e as suas funcionalidades. Dada a existência de um backend de login - o seguinte fluxo é frequentemente usado ao pesquisar vulnerabilidades em CMSs ou serviços de Plataform-as-a-Service.

Um destes websites Masterlink era registo.natural.pt - que permite o registo público:

Comecei depois a analisar o código-fonte HTML desta página.

Olhar para Javascript é importante

Na página de registo, mais uma vez comecei a olhar simplesmente para os novos ficheiros Javascript que agora estavam a ser usados.

Um desses ficheiros foi /processos/include/campoHTML/editorHTML.js, que me chamou à atenção devido ao nome. A edição de HTML é geralmente uma funcionalidade de backend e os endpoints não se encontram idealmente apresentados no frontend.

Dentro deste ficheiro Javacript, a seguinte parte do seu conteúdo foi encontrada:

Um handler de upload de ficheiros - provavelmente usado pelo painel de backoffice para carregar imagens e ficheiro estáticos - foi encontrado junto a este endpoint de upload ASHX.

A vulnerabilidade

Como podem imaginar até agora, a vulnerabilidade é bastante simples e direta. Curiosamente, tentei fazer o upload de um ficheiro .PNG para este endpoint através do seguinte comando:

curl -s -i -A "" -X POST -F "image[][email protected]" "https://registo.natural.pt/processos/include/FileUpload.ashx"

A resposta retornou:

/upload/imagens/i12320.png

E o ficheiro foi transferido com sucesso:

Fiquei um bocado perplexo, então repliquei o mesmo pedido HTTP para https://portugal.gov.pt/processos/include/FileUpload.ashx e o comportamento foi o mesmo. (!)

Ok, posso fazer upload de imagens arbitrárias para portugal.gov.pt, mas será que é possível fazer o mesmo com arquivos ASP? A resposta foi sim.

Prova de conceito e problema com WAF

Verificou-se assim que é possível interagir com o endpoint e fazer upload de ficheiros ASHX arbitrários sem qualquer restrição ou autenticação.

Uma prova de conceito de execução de código foi realizada, onde o comando whoami é executado e o seu output devolvido. Um report foi imediatamente enviado para o [email protected] com os detalhes da vulnerabilidade.

cat report | gpg -o - -a -e -r [email protected] - | vim -

Também verifiquei que portugal.gov.pt está protegido por uma Web Application Firwall (WAF) Incapsula, e uma outra questão foi levantada: Por que é que a WAF não bloqueou o ficheiro transferido?

Como descobri mais tarde, a WAF Incapsula bloqueia código ASP dentro de qualquer um dos seus ficheiros transferido como Multipart - no entanto - por alguma razão, a WAF não efetua inspeção a ficheiros ASHX.

Timeline de divulgação

Será esta uma timeline de divulgação saudável?

Quando se trata de uma timeline de divulgação, o principal fator de sucesso é quão rápido e eficientemente a vulnerabilidade crítica é corrigida nos sistemas afetados. Neste caso, o CERT de Portugal foi excepcionalmente proativo na coordenação de uma correção para o portal vulnerável mais critico portugal.gov.pt, tendo levado menos de 1 dia entre o relatório da vulnerabilidade e a sua mitigação.

Masterlink também agiu rapidamente ao lançar uma nova versão do CMS onde esta vulnerabilidade foi corrigida. A maioria dos portais foram encontrados com a vulnerabiliadde mitigadada no espaço de alguns meses.

Certos websites governamentais - no entanto - não seguiram este processo de mitigação rápida. Tendo passado três anos desde o relatório inicial, ainda havia um domínio gov.pt e um website governamental vulneráveis.

Pensei na possibilidade de que estas entidades não tenham mais licenciamento válido para o CMS, tornando as atualizações de software não viáveis - o que complicaria substanticalmente a sua mitigação.

Após este processo, descobri que parecia existir alguma resistência entre o CERT.PT e as últimas entidades publicas afetadas, na sua habilidade de corrigir a vulnerabilidade de maneira proativa.

Embora as pessoas por trás do CERT.PT sejam extremamente profissionais e competentes - descobri que talvez lhes falte financiamento e recursos ao enfrentar estas divulgações de vulnerabilidade mais complexas para entidades públicas.

Há também o fator de política de mitigação - onde possívelmente o CERT.PT não tenha diretrizes adequadas para impor correções de vulnerabilidades nas entidades governamentais - e está restrito apenas a reportá-las para a equipa de IT afetada.

O que estamos a fazer certo

O CERT de Portugal, Masterlink e as principais entidades governamentais como CEGER, DGS e SGE agiram rapidamente na correção da vulnerabilidade e as suas entidades afetadas.

O CERT também está no processo de desenvolver uma proposta para um CVD (Coordinated Vulnerability Disclosure) que auxiliaria esse processo de divulgação de vulnerabilidades.

Portugal does not have a CVD policy in place. However, a task force including the Portuguese National Cybersecurity Centre (CNCS), public authorities and stakeholders from the cybersecurity community was convened to work on a proposal for establishing a policy at the national level which anticiptes the need to amend the criminal law. The task force presented aproposal with a comprehensive CVD policy and legislative amendments. The proposal is now being examined by decisionmakers.

Embora não tenhamos um CVD formal, o CERT.PT ainda consegue desempenhar com sucesso o papel de um ”coordenador de vulnerabilidades” quando se trata de reportar rapidamente vulnerabilidades criticas a entidades do setor publico e governamental.

O que ainda nos falta

Infelizmente, a maioria das entidades do setor público em Portugal não realizam auditorias regulares de segurança ofensiva, o que torna estas divulgações de segurança um fator essencial na proteção de ativos governamentais.

Portugal ainda não possui um CVD nacional (Divulgação de Vulnerabilidade Coordenada) que protege legalmente os investigadores e facilita a coordenação com as entidades afetadas. A ENISA ainda recomenda os seguintes padrões quando se trata de implementar um CVD.

Neste programa, a equipa nacional do CERT.PT desempenharia o papel de “coordenador”, onde a divulgação de vulnerabilidade seria triada muito como um programa de divulgação de vulnerabilidades - ao longo de várias fases até ser mitigada pelo fornecedor ou entidade afetada.

De acordo com o padrão da ENISA, este “coordenador” validaria a vulnerabilidade, faria a triagem e a reportaria às entidades afetadas.

O “coordenador” também gerenciaria uma resposta multiparte com a entidade afetada e desenvolveria soluções alternativas para quando as vulnerabilidades não são tão simples de corrigir (por ex. software fora de licenciamento).

“Proteção dos investigadores de segurança. Os investigadores envolvidos na descoberta de vulnerabilidades muitas vezes estão expostos à responsabilidade criminal ou civil. A responsabilidade legal e as responsabilidades dos investigadores de segurança devem ser totalmente esclarecidas para permitir que continuem seu trabalho sem medo de perseguição.” - Coders’ Rights Project Vulnerability Reporting FAQ

No geral, ainda acho que o CERT e o CNCS deveriam ter mais financiamento e recursos humanos atribuídos para enfrentar e facilitar esse processo.

Links

• CNCS: National Cybersecurity Framework (2020)

• Coordinated Vulnerability Disclosure Policies in the EU

• Good Practice Guide on Vulnerability Disclosure. From challenges to recommendations

• Coders’ Rights Project Vulnerability Reporting FAQ

• Hackerone: Summary of The CERT Guide to Coordinated Vulnerability Disclosure

• Hackerone: Software Vulnerability Disclosure in Europe: Summary and Key Highlights of the European Parliament CEPS Task Force Report

• EU needs one set of vulnerability disclosure rules, says expert task force