-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 - --- title: "How I got RCE in portugal.gov.pt" description: "Found an RCE vulnerability in a CMS widely used in Portuguese government portals - one of which was portugal.gov.pt" publishDate: "12 Mar 2024" langs: [en, pt] tags: [research, responsible, disclosure, rce, portugal, vulnerability] - --- **tl;dr**: Found a very simple arbitrary file upload [vulnerability](#the-bug) that lead to RCE in a CMS widely used in Portuguese government portals - one of which was **portugal.gov.pt**. Long [disclosure timeline](#disclosure-timeline) in less critical governmental entities raises a possible [discussion](#is-this-a-healthy-disclosure-timeline) about vulnerability mitigation policies in portuguese public entities and the need for a national [CVD](https://vuls.cert.org/confluence/display/CVD). ## Introduction Throughout my years of browsing and pentesting Portuguese applications I always found myself having the habit of finding weird operational behavior. This often drives me into curiosity rabbit holes. I sometimes indulge this curiosity and try to passively analyze these applications - sometimes by merely inspecting the web requests or the web frameworks that are used. ![Yes this cover image was made with GPT-4.0 - the prompt I used is on my Github](./img/logo.png) I've reported several vulnerabilities to Portugal's [CERT](https://www.cncs.gov.pt/pt/certpt/) (CERT.PT) over the years - whether because I stumbled upon a government portal that had some vulnerabilities or a commercial application that would allow a user to make purchases for free. This process commonly known as "responsible" or "ethical" disclosure has been recently [argued](https://www.enisa.europa.eu/publications/developing-national-vulnerabilities-programmes/@@download/fullReport) by [ENISA](https://www.enisa.europa.eu/) and [other](https://www.ceps.eu/ceps-publications/software-vulnerability-disclosure-europe-technology-policies-and-legal-challenges/) european entities as an essential factor in passive cyber security operations. The sometimes unspoken reality is that there are a lot of security researchers who have done this process and reported these types of critical vulnerabilities in an ethical manner - even though there WERE no formal guidelines in place for us to do so in a secure manner. There are, however, perhaps even more individuals who have identified critical vulnerabilities on governmental portals but are too afraid to report them due to the lack of disclosure guidelines. But there appears to be some push in the right direction. Since 2016, several countries have created a vulnerability disclosure program that would aid researchers in the process of ethical disclosure: - - [EU Cybersecurity Act]() - promoted by [CEPS taskforce](https://www.ceps.eu/ceps-publications/developing-national-vulnerability-programmes/) - proposes a standard for the creation of a [Coordinated Vulnerability Disclosure](https://vuls.cert.org/confluence/display/CVD) program for each European Member State; - - France, Belgium, Lithuania, and Netherlands have already [created](https://www.enisa.europa.eu/publications/coordinated-vulnerability-disclosure-policies-in-the-eu/@@download/fullReport) a functional CVD program; - - `CNCS` and `CERT.PT` have been formally [committed](https://www.cncs.gov.pt/docs/qnrcs-web-eng.pdf) into developing such program. Marking Portugal as `ON THE POINT OF IMPLEMENTING` by ENISA; - - Canada also recently developed a similar CVD proposal ["See Something, Say Something"](https://www.cybersecurepolicy.ca/vulnerability-disclosure). ## Something smells odd In 2020, after some high profile hacks against Portuguese entities via vulnerable web applications, I kept asking myself - How vulnerable are our government websites? I curiously browsed and started seeing multiple requests containing the endpoint `/wwwbase`. ![wwwbase1](./img/wwwbase1.png) Given this parameter's "uniqueness" - and after some basic google fu, I immediately identified other governmental portals containing this directory (makes it incredibly easy to fingerprint too right?). ![wwwbase2](./img/wwwbase2.png) One name kept popping up in the source code: "Masterlink". This was found to be the major CMS (Content Management Suite) used by these websites for web page control and backend interface. ![masterlink](./img/masterlink.png) This parameter `wwwbase` seemed strange - and most security people and even web developers would find its appearance odd - since it creates the assumption that one would be able to access files present _before_ the base application directory by requesting elements without `wwwbase`. This and the following other indicators made me more curious about this application and its security features: - - Seemingly complex and functionality-rich CMS; - - Usage of ASP and ASP.NET (old programming language with sometimes unmaintained code); - - Primarily used in public governmental entities. (Unfortunately) Public entities are less likely to do internal penetration tests that identify possible issues in these applications, since this is the case - it leaves itself untested against an outsider. Given the variety of websites that I found using this CMS platform, I decided to explore them and their features. Given the existence of a login backend - the following flow is often used when researching vulnerabilities in CMS or Platform-as-a-Service providers.
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 One of these Masterlink websites happened to be `registo.natural.pt` - which allows public registration: ![registo1](./img/registo1.png) I curiously started going through the HTML source code of this page. ## Why looking at Javascript matters Within the registration page, I once again started merely inspecting all the new Javascript files that were now being used. ![registo2](./img/registo2.png) One of these files was `/processos/include/campoHTML/editorHTML.js` which caught my attention given its name. HTML editing is usually a backend functionality and its endpoints are not ideally presented in the frontend. Within this Javacript file, the following portion of its contents was found: ![registo3](./img/registo3.png) A file upload handler - most likely used by the backoffice dashboard to upload images and static files - was found along with its `ASHX` upload endpoint. ## The bug As you can imagine by now, the bug was pretty straightforward. I curiously tried to upload a .PNG file toward this endpoint using the following command: ```bash curl -s -i -A "" -X POST -F "image[]=@portugal.png" "https://registo.natural.pt/processos/include/FileUpload.ashx" ``` The response returned: ```html /upload/imagens/i12320.png ``` And the file had been uploaded successfully: ![upload](./img/upload.png) I was slightly baffled so I replicated the same request towards `https://portugal.gov.pt/processos/include/FileUpload.ashx` and the behaviour was the same. (!) Ok sure I can upload arbitrary images towards portugal.gov.pt but can you do the same with ASP files? The answer was yes. ## Proof of concept and WAF issue So as it turns out, you could interact with this endpoint and upload arbitrary ASHX files without any restriction or authentication. ![rce1](./img/rce1.png) An RCE proof-of-concept was made that executes the `whoami` command and prints out its result. A report was then immediately sent to `cert@cert.pt`. ![email4](./img/email4.png) ```sh cat report | gpg -o - -a -e -r cert@cert.pt - | vim - ``` ![certemail](./img/certemail.png) I also noticed that `portugal.gov.pt` is behind the [Imperva Incapsula](https://www.imperva.com/products/web-application-firewall-waf/) WAF, so another question was raised: Why didn't the WAF block the uploaded file? As I later found out, Incapsula WAF blocks ASP code within any of its multipart uploaded files - however - for whatever reason the WAF does not inspect ASHX files. (!) ## Disclosure timeline
| | Date of Metric |--| |-------|-----------|--| | **August 17th, 2020** | Developed RCE Proof-of-Concept to `portugal.gov.pt`; | | **August 17th, 2020** | Received ack from CERT.PT as they coordinate report to affected entities ([CEGER](https://www.ceger.gov.pt/) for portugal.gov.pt) and CMS provider Masterlink; | | **August 19th, 2020** | I verify that the vulnerability has been **fixed** and PoC removed from `portugal.gov.pt`; | | **August 19th, 2020** | CERT.PT asks for a list of other affected entities; | | **August 19th, 2020** | I provide CERT.PT with a list of affected domains identified given the google dork; | | **August 20th, 2020** | Acknowledgement from CERT.PT as they coordinate reports to affected entities; | | **May 3rd, 2021** | I report to CERT.PT that there are still 2 governmental (GOV.PT) domains and 1 governmental entity vulnerable to RCE; | | **March 14th, 2023** | Report to CERT.PT that there are now 2 vulnerable endpoints and that a public disclosure of this finding will be released at the end of April 2023; | | **Nov 21st, 2023** | I connect with the DPO (Data Protection Officer) of `SEG-SOCIAL.PT` on Linkedin in order to coordinate the vulnerability fix of the last GOV.PT domain; | | **Nov 21st, 2023** | I report to `SEG-SOCIAL`'s SOC the nature of the vulnerability and the associated vulnerable endpoints; | | **Dec 16th, 2023** | I verify that the vulnerability has been **fixed** in the last GOV.PT domain. Still 1 governmental domain left vulnerable ([ICNF](https://www.icnf.pt/) - `registo.natural.pt`); | | **Jan 2nd, 2024** | I send another email to CERT.PT explaining that `registo.natural.pt` is still vulnerable and that I plan on releasing this blog post on 10th of January; | | **Jan 28th, 2024** | I track down 2 people from `ICNF`'s IT team and contact them on LinkedIn explaining the situation; | | **Jan 30th, 2024** | One of the IT people from `ICNF` responds on LinkedIn with an email address of a ICNF sysadmin; | | **Jan 30th, 2024** | I email an `ICNF` sysadmin with the vulnerability details and how to achieve a possible fix; | | **Feb 5th, 2024** | Still no response - I forward the same email to `dgaf@icnf.pt`; | | **Feb 13th, 2024** | The website `registo.natural.pt` was found to be no longer vulnerable since it returns an error when uploading ASP and ASHX files; | | **March 12th, 2024** | I release this blog post. |
## Is this a healthy disclosure timeline? When it comes to a disclosure timeline the main success factor is how fast and efficiently the critical vulnerability gets fixed across the affected systems. In this case, Portugal's `CERT` was exceptionally proactive at coordinating a fix for its most critical vulnerable portal `portugal.gov.pt` taking less than 1 day between the vulnerability report and the mitigation. `Masterlink` also quickly released a new CMS version where this vulnerability was fixed. Most portals were found to no longer be vulnerable in the span of a few months. Certain governmental websites - however - did not follow this quick mitigation process. Having three years passed since the initial report, there were still one `gov.pt` domain and one governmental associated websites vulnerable. I thought about the possibility that these entities no longer have valid licensing to the CMS making software updates no longer a viable option since its a general occurrence when it comes to vulnerability patching. After this process, I found that there seemed to exist some resistance between `CERT.PT` and the last affected entities on their ability to properly fix the vulnerability in a promptly manner. Even though the people behind `CERT.PT` are extremely professional and competent - I found that they perhaps lack in funding and resources when battling these tricky vulnerability disclosures towards public entities. There is also the factor of enforcement policy, where perhaps `CERT.PT` does not have proper guidelines to enforce vulnerability fixes across governmental entities, and is constricted by merely reporting them toward the affected IT team. ## What we're doing right Portugal's CERT, `Masterlink` and the top governmental entities like `CEGER`, `DGS` and `SGE` moved fast in fixing critical security vulnerabilities in its affected entities. CERT is also in the process of getting approval for their proposal of a CVD (Coordinated Vulnerability Disclosure) that would aid this process of vulnerability disclosure. > 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 anticipates the need to amend the criminal law. The task force presented a proposal with a comprehensive CVD policy and legislative amendments. The proposal is now being examined by decisionmakers. Even though we don't have a formal CVD, CERT.PT still manages to successfully play the role of a "[vulnerability coordinator](https://vuls.cert.org/confluence/display/CVD/3.5.+Coordinator)" when it comes to quickly reporting tricky vulnerabilities to critical governmental entities while managing to safeguard the integrity of an ethical disclosure. ## What we're still lacking Unfortunately, most public entities in Portugal do not perform regular offensive security audits, so security disclosures are an essential factor when it comes to protecting governmental assets. Portugal still does not have a national CVD (Coordinated Vulnerability Disclosure) that legally protects researchers and facilitates coordination with affected entities. ENISA still recommends the following standards when it comes to implementing a CVD. ![enisa_on_national_cvd](./img/enisa_on_national_cvd.png) In this program, the national CERT.PT team would play the part of "coordinator" where vulnerability disclosure would be triaged very much like a Vulnerability Disclosure Program - throughout multiple phases until it gets mitigated by the vendor. According to ENISA's standard, this "coordinator" would validate the vulnerability, triage, and report it to the affected entities. The "coordinator" would also manage a multiparty response with the affected entity and develop workarounds for when vulnerabilities are not as simple to fix (i.e., software out of licensing). > "Protection of security researchers. Researchers involved in vulnerability discovery are often exposed to criminal or civil liability. The legal liability and responsibilities of security researchers should be fully clarified to enable them to continue their work without fear of prosecution." - EFF Coders’ Rights Project Vulnerability Reporting Overall, I still think CERT and CNCS should have more funding and human resources attributed to tackle and facilitate this process. ## Sources - - [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----- iQHDBAEBCAAtFiEEUR60IXM9NmJXDRuqysNf5Hr0Z4cFAmXx4VIPHHY5QG91dGxv b2suY29tAAoJEMrDX+R69GeHsy4L/0J/ZrvP1zXgAgt2NfqdOFVsh93r2XIycol/ 7NvHqqCKHWV4su6DA1fhjIR02xyAACt7FsAo5iI0+00UogSasFKhYULHa2KYzVsV YKvgsODUupvOr/sV/aaP6s7rIPNGqRyIxfOFtRkwxbMYOv1T1D0c8GjZmTohnsoO x2LvA+DmZwPr9gsOaZ3Nhl04JNi90efVy9M9Yk5oWjPs37HkGN6O0zUWpf0uk8QG IegEJqzNsJT+JhUlv82fFplxY35Fj2seE9UYjHXyjZ/sR+kiWflsuvEklXwIDRv5 rOes7olpd8eWxFKjLHfS8LNS0uag35umLr2VHNp+3N5Ufq7xw7hAim69hWx5+8sB RsV7X0bKxr1qxFR+D9snkw+ZW22RLCyi7MsKgShz6NNGBzic54+7I7XdWTZsuyXE RchM4omO3Et+C+cB9MBl8IRblV48vw5qvuDg2JOdKsRqoRLn8LqAZEy0J1vzclua lNXPmvdBRUR3NqBTKbDf+D9sMbKLUQ== =PhwZ -----END PGP SIGNATURE-----