Skip to main content

Don’t forget to track your vendors’ security advisories

Illustration of Don’t forget to track your vendors’ security advisories
Adam Borczyk

Every now and then a new critical vulnerability emerges, that has a worldwide impact and is easy to exploit. We’ve all seen Log4Shell, Spring4Shell… and now React2Shell. Despite media coverage, application teams often miss the importance of security patches.

This particular vulnerability was found during a recent pentest in a production environment of our client, and it does not require any authentication. Global public disclosure of React2Shell happened just 5 weeks before this pentest.

Reconnaissance

At the very beginning of the tests, during the standard web app browsing and looking for an inspiration, a presence of NextJS framework caught our attention. This is indicated by requests for NextJS- generated data to endpoints starting with /_next. Since public disclosure of React2Shell happened just a couple of weeks earlier, why not to give it a try?

The first step is to open browser’s console and type next to get the currently used version of the framework:

According to NextJS’ security advisory, the vulnerability has been fixed in 15.5.7. Therefore, we used a React2Shell scanner published by Assetnote to try to confirm the issue, and proxied it through Burp Suite to see the traffic.

Exploitation

The PoC payload from Assetnote tries to inject a system command echo $((41*271)), which should result in a string 11111 in the HTTP response. The scanner checks whether the response contains a redirection to /login?a=11111, and if so, marks the endpoint as vulnerable. The original payload looks like below:

Response from the tested host was unequivocal:

To prove the vulnerability beyond the mathematical PoC, one can execute id command, or substitute the JavaScript code to any other:

And observe the effect in the response header:

Since the app was running in a production environment, we did not attempt to infiltrate the infrastructure beyond the shown PoC, and the issue was immediately reported to the client and patched.

Takeaways

We have to acknowledge that every publicly available service will be at some point scanned by malicious bots, or otherwise targeted by attackers. A simple, unauthenticated HTTP POST request to an unpatched web app results in a server compromise – this is why it is crucial to track security advisories of our software vendors and patch as soon as possible.

Other Insights

Illustration of Active Directory Killchain: How three misconfigurations led to a Domain Compromise

Active Directory Killchain: How three misconfigurations led to a Domain Compromise

Marek Rzepecki

In the world of Active Directory (AD), an administrator needs to keep an eye on countless factors: keeping servers up to date, disabling redundant services, and managing privilege granulation across user groups. However, sometimes, to take over the whole domain (and log into all machines as any user), an attacker doesn't need to exploit technical vulnerabilities or search for CVE’s. It is often enough if an administrator makes a few small mistakes in configuring the relations between different objects in AD. The killchain presented below is a textbook example of such exploitation, where three separate issues were chained together to achieve a critical impact.

READ article
Illustration of From Username to RCE

From Username to RCE

SZYMON STODTKO

"Never trust data sent by the user." This sentence is repeated like a mantra at every security training. Today, we will look at a case where a general lack of field filtration in an application, particularly the username combined with weak file validation, led to a critical Remote Code Execution (RCE) vulnerability. During web application penetration testing, I came across an interesting chain of vulnerabilities. The application had a function for creating users and assigning them disk space for video files. This mechanism, though seemingly standard, turned out to be the system's Achilles' heel.

READ article
Illustration of Path Normalization allow to access internal outdated software with multiple vulnerabilities, leading to remote code execution

Path Normalization allow to access internal outdated software with multiple vulnerabilities, leading to remote code execution

Jakub Żoczek

During the audit for one of our clients, it was found that some servers allow path normalization which may expose sensitive, internal services. Such behaviour exposed outdated, vulnerable version of WSO2 Api Manager software, containing plenty of publicly known security issues, that might be exploited without authentication. That led to successfully exploitation one of such vulnerabilities achieving Remote Code Execution on api.[REDACTED].com production server.

READ article
A professional cybersecurity consultant ready to assist with your inquiry.

Any questions?

Happy to get a call or email
and help!

Contact Us