-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 - --- title: "Como encontrei RCE em portugal.gov.pt" description: "Encontrei uma vulnerabilidade de segurança critica num CMS amplamente usado em portais governamentais portugueses - um dos quais era portugal.gov.pt" publishDate: "12 Março 2024" langs: [] tags: [research, responsible, disclosure, rce, portugal, vulnerability] - --- **tl;dr**: Encontrei uma [vulnerabilidade](#a-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](#Esta-é-uma-timeline-de-divulgação-saudável) sobre políticas de mitigação de vulnerabilidades em entidades públicas e a necessidade de um [CVD](https://vuls.cert.org/confluence/display/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. ![Yes this cover image was made with GPT-4.0 - the prompt I used is on my Github](./img/logo.png) Reportei várias vulnerabilidades ao [CERT](https://www.cncs.gov.pt/pt/certpt/) 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](https://www.enisa.europa.eu/publications/developing-national-vulnerabilities-programmes/@@download/fullReport) pela "Agência Europeia para a Segurança das Redes e da Informação" [ENISA](https://www.enisa.europa.eu/) e [outras](https://www.ceps.eu/ceps-publications/software-vulnerability-disclosure-europe-technology-policies-and-legal-challenges/) 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](https://www.ceps.eu/ceps-publications/developing-national-vulnerability-programmes/) - propõe um padrão para a criação de um programa de Divulgação de Vulnerabilidades Coordenadas ([Coordinated Vulnerability Disclosure](https://vuls.cert.org/confluence/display/CVD)) para cada Estado-Membro Europeu. - - França, Bélgica, Lituânia e Países Baixos já [criaram](https://www.enisa.europa.eu/publications/coordinated-vulnerability-disclosure-policies-in-the-eu/@@download/fullReport) um programa CVD funcional. - - O CNCS e o CERT.PT [comprometeram-se formalmente](https://www.cncs.gov.pt/docs/qnrcs-web-eng.pdf) 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"](https://www.cybersecurepolicy.ca/vulnerability-disclosure). ## 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 e comecei a ver múltiplos pedidos HTTP com o _endpoint_ `/wwwbase`. ![wwwbase1](./img/wwwbase1.png) 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). ![wwwbase2](./img/wwwbase2.png) 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. ![masterlink](./img/masterlink.png) 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`.
CMS / PaaS
CMS / PaaS
Find bug
Find bug
Registration feature 
Registration featur...
Site A
Site A
Site B
Site B
Explore app
Explore app
Explore bug
Explore bug
Authenticated features
Authenticated features
enabled
enabled
Registration feature 
Registration featur...
disabled
disabled Um destes websites Masterlink era `registo.natural.pt` - que permite o registo público: ![registo1](./img/registo1.png) 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. ![registo2](./img/registo2.png) 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: ![registo3](./img/registo3.png) 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: ```bash curl -s -i -A "" -X POST -F "image[]=@portugal.png" "https://registo.natural.pt/processos/include/FileUpload.ashx" ``` A resposta retornou: ```html /upload/imagens/i12320.png ``` E o ficheiro foi transferido com sucesso: ![upload](./img/upload.png) 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. ![upload2](./img/upload2.png) 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 `cert@cert.pt` com os detalhes da vulnerabilidade. ![email4](./img/email4.png) ```sh cat report | gpg -o - -a -e -r cert@cert.pt - | vim - ``` ![certemail](./img/certemail.png) 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
| | Data da Metrica |--| |-------|-----------|--| | **17 de Agosto 2020** | Desenvolvida prova de conceito de execução de código em `portugal.gov.pt` | | **17 de Agosto 2020** | Reportada vulnerabilidade ao CERT.PT usando PGP assinado | | **17 de Agosto 2020** | Recebido reconhecimento do CERT.PT enquanto coordenam o _report_ para as entidades afetadas ([CEGER](https://www.ceger.gov.pt/) para portugal.gov.pt) e o fornecedor de CMS Masterlink | | **19 de Agosto 2020** | Verifico que a vulnerabilidade foi **corrigida** e PoC removido de `portugal.gov.pt` | | **19 de Agosto 2020** | CERT.PT pede uma lista de outras entidades afetadas | | **19 de Agosto 2020** | Forneço ao CERT.PT uma lista de domínios afetados identificados dado o _google dork_ | | **20 de Agosto 2020** | Reconhecimento do CERT.PT enquanto coordenam relatórios para as entidades afetadas | | **3 de Maio 2021** | Reporto ao CERT.PT que ainda existem 2 domínios governamentais (GOV.PT) e 1 entidade governamental vulneráveis a RCE | | **14 de Mar. 2023** | Reporto ao CERT.PT que agora existem 2 endpoints vulneráveis e que uma divulgação pública desta descoberta será lançada no final de Abril de 2023 | | **21 de Nov. 2023** | Conecto-me com o DPO (Data Protection Officer) da SEG-SOCIAL.PT no Linkedin para coordenar a correção da vulnerabilidade do último domínio GOV.PT | | **21 de Nov. 2023** | Reporto ao SOC da SEG-SOCIAL a natureza da vulnerabilidade e os endpoints vulneráveis associados | | **16 de Dez. 2023** | Verifico que a vulnerabilidade foi **corrigida** no último domínio GOV.PT. Ainda resta 1 domínio governamental vulnerável ([ICNF](https://www.icnf.pt/) - `registo.natural.pt`) | | **2 de Jan. 2024** | Envio outro e-mail ao CERT.PT a explicar que `registo.natural.pt` ainda está vulnerável e que planeio lançar este post de blog no dia 10 de Janeiro | | **28 de Jan. 2024** | Encontro 2 pessoas da equipa de IT de `ICNF` e contacto-os no LinkedIn a explicar a situação | | **30 de Jan. 2024** | Uma das pessoas de IT do ICNF responde no LinkedIn com um endereço de e-mail de um sysadmin do `ICNF` | | **30 de Jan. 2024** | Envio um e-mail a um sysadmin do ICNF com os detalhes da vulnerabilidade e como alcançar uma possível correção | | **5 de Fev. 2024** | Ainda sem resposta - Encaminho o mesmo e-mail para `dgaf@icnf.pt` | | **13 de Fev. 2024** | Verifico já nao ser possível efetuar upload de ficheiros ASHX em `registo.natural.pt` | | **12 de Março 2024** | Publico este blog-post |
## 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](https://vuls.cert.org/confluence/display/CVD/3.5.+Coordinator)" 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](https://pt.wikipedia.org/wiki/Teste_de_intrus%C3%A3o), 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. ![enisa_on_national_cvd](./img/enisa_on_national_cvd.png) 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)](https://www.cncs.gov.pt/docs/qnrcs-web-eng.pdf) - - [Coordinated Vulnerability Disclosure Policies in the EU](https://www.ceps.eu/ceps-publications/coordinated-vulnerability-disclosure-policies-in-the-eu/) - - [Good Practice Guide on Vulnerability Disclosure. From challenges to recommendations](https://www.enisa.europa.eu/publications/vulnerability-disclosure) - - [Coders’ Rights Project Vulnerability Reporting FAQ](https://www.eff.org/issues/coders/vulnerability-reporting-faq) - - [Hackerone: Summary of The CERT Guide to Coordinated Vulnerability Disclosure](https://www.hackerone.com/vulnerability-management/your-tldr-summary-cert-guide-coordinated-vulnerability-disclosure) - - [Hackerone: Software Vulnerability Disclosure in Europe: Summary and Key Highlights of the European Parliament CEPS Task Force Report](https://www.hackerone.com/vulnerability-management/software-vulnerability-disclosure-europe-summary-and-key-highlights) - - [EU needs one set of vulnerability disclosure rules, says expert task force](https://cyberscoop.com/eu-vulnerability-disclosure-rules-says-expert-task-force/) -----BEGIN PGP SIGNATURE----- iQHDBAEBCAAtFiEEUR60IXM9NmJXDRuqysNf5Hr0Z4cFAmXx4VQPHHY5QG91dGxv b2suY29tAAoJEMrDX+R69GeH4VYL/3tMfP3ABrBmn/YSGbBqMcM6ol/OURBCHDkj 03pti56NyXJEkhHGRkeYPmZCa/FCjkod45FVgHYPV2Ku5oQZfjO9DtcNoFBIcksf gG90xWar5YkNP4J+2PmShFVd0jmu0tnv84tyFtIjFk7iG/3pE5fnknM9sluHo8pb JDYqeo/GEEfQVkCIZ8tKbAUFTXOILtN8sOFrPH3TO3FiMeNC/AFo8YVoflBpC4st TM0woiKtAmU2hrKbmuUt+2LHh/Z7532mDiF70rWDJCwQtBD0kGbxh3W0135z9Y6h XvcbM4u582LdtAvWdPfZWjOk091EZxN3A2HVq25vPV95eLD1OfzJRMkHVwdF9fPf wM4W2M0GyK5vuGbjHapMCHqL5Add0nvqVCnTYUYUjIVmuLrwHIyjYKFrLRGVL5oS 1Pfe+RU/qqFw90183nJYRqdPdXhBPbmsKIskddl3cL7p0uL9fAPBNXUttzhUa+Ur UzeNlhGFU7V6gmjvpRoxL8BKw9Zf2Q== =CHYK -----END PGP SIGNATURE-----