Hidden in Plain Sight



May 2023 – In this edition, we highlight how a decommissioned application was not fully removed as expected, allowing us to abuse legacy functionality to compromise an enormous amount of client and PII data.

Legacy Systems Overview

As security consultants, we see various types of web applications. We have classic web applications that are over 10 years old, held together with PHP and jQuery and brand new applications built with the latest frameworks and design principles. The legacy applications as testers are always the most interesting, as during the long lifespan of these applications, it’s easy to forget about some feature someone implemented a few years ago and has since been re-implemented elsewhere.

Typically legacy systems remain in place whilst there is a strong enough business reason behind this. In this case, the business reason no longer existed, with the client decommissioning (to their best knowledge) the legacy portion of the affected application.

Forgotten Features

Forgotten legacy features are often a goldmine for interesting vulnerabilities as they commonly fall under the radar of pull request reviews, security scanners, and other cyber security processes which only review security of new features. In this particular engagement, we looked at a company’s client portal, where customers could login, access their e-learning resources and certificates, and other various related content. After a small amount of external enumeration, we discovered that we were interacting with a newer version of the site. The older site, “removed” a few years previously, just redirected us to the new site whenever we came across it.

We left testing this part of the site until the later part of the test, once we were happy with the rest of the newer site.

So, we know we are being redirected to the newer site, our first question is how are we being redirected? There’s a couple of ways it could have been done:

  • The older application was completely removed and a simple 301 redirect was handled by the web server.
  • The older application was partially updated and 301 redirects were returned by all endpoints.
  • Some JavaScript was put into the footer of the application’s HTML redirecting to the new page.
  • And so on…

The final one mentioned, JavaScript redirects, are the best ones to come across as a tester. Burp Suite, our tool of choice for web application assessments, has a handy search-and-replace feature for all responses from the server.

Top Tip: A small search-and-replace of “window.location” to “var noRedirectsForMe” will easily disable most JavaScript redirections.

Attack Surface

Once we did this, suddenly we had a huge amount of attack surface to analyse. The entire old version of the application was now accessible to us, including some gems such as SOAP APIs with their WSDL files (essentially, all the documentation we could want), legacy authentication endpoints, and debugging endpoints like those that accepted raw SQL statements.

As a result of the raw SQL statements, it was possible to ultimately achieve remote code execution via the use of xp_cmdshell and the database user being SA…

From this point onwards we had almost unrestricted access to not only a large amount of personal data, but also access to the internal environment through the RCE within the MSSQL server.

In Conclusion…

Migration and deployment is a difficult aspect with legacy applications, especially those that are made by developers who may no longer be easily contactable, no longer develop applications, or just aren’t sure of where the system sits with the rest of the infrastructure. However, the danger of having unmaintained systems still widely accessible cannot be ignored. After all, you wouldn’t have an unpatched Windows XP system publicly accessible, so why have an unmaintained web application publicly accessible?

Our reporting of this issue to our client highlighted the importance of properly decommissioning this older application, making sure they removed the web application code from the production server, and ensuring that the newer application did not rely on any of the APIs offered by the previous application. Our short assessment was the final push to ensure that it was properly decommissioned and not just gently pushing users over to the new site.

If you are concerned about the security posture of your environments, or any of the above sounds similar to your existing environment, please do contact us for more information.


Our client, for allowing us to publish this story.