How I got RCE in portugal.gov.pt

tl;dr: Found a very simple arbitrary file upload vulnerability that lead to RCE in a CMS widely used in Portuguese government portals - one of which was portugal.gov.pt. Long disclosure timeline in less critical governmental entities raises a possible discussion about vulnerability mitigation policies in portuguese public entities and the need for a national 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.

I’ve reported several vulnerabilities to Portugal’s CERT (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 by ENISA and other 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 - proposes a standard for the creation of a Coordinated Vulnerability Disclosure program for each European Member State;
• France, Belgium, Lithuania, and Netherlands have already created a functional CVD program;
• CNCS and CERT.PT have been formally committed 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”.

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 <www.portugal.gov.pt> and started seeing multiple requests containing the endpoint /wwwbase.

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?).

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.

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.

One of these Masterlink websites happened to be registo.natural.pt - which allows public registration:

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.

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:

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:

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

The response returned:

/upload/imagens/i12320.png

And the file had been uploaded successfully:

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.

An RCE proof-of-concept was made that executes the whoami command and prints out its result. A report was then immediately sent to [email protected].

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

I also noticed that portugal.gov.pt is behind the Imperva Incapsula 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

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” 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.

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)

• 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