by Severin Wischmann & Markus Schalch

Penetration testing projects are all about the defined scope and objective, i.e. which systems, entry points, personal or company sites may be attacked, and what specific scenarios should be tested for. These two properties are usually defined at the beginning of the project with the client, which requires a trade-off to be made between completeness and feasibility from a temporal point of view. If, on the one hand, the scope is large and the goal is to find all security related issues, it will take a lot of time to eventually achieve that goal. If, on the other hand, the scope is very small and the goal is to obtain access to a single file on a network share then there might be no tangible outcome for the customer in case no path to that file exists within the scope of the project – other than the fact that there does or does not exist such a path, of course. For example, finding all security-related issues in the internal 10.0.0.0/8 network is arguably too large a scope in general. With potential legacy systems, test systems, and that one server that cannot be patched, there will be too many issues to handle in a reasonable time frame. In contrast, testing a single external-facing web application with the goal of accessing a file on the main drive of the domain controller would usually not lead to meaningful results, either. Well, usually…

During a recent project Oneconsult was included in the whole development cycle of a data collection service. From the initial architecture drafts and the first specifications to a web application penetration test of the finished product, security was always an important part of each project stage. Within the final stage, the customer decided to open up the web application firewall (WAF) for part of the tests to allow access to the administrative interface of the web application. Since these pages are accessible to internal staff, who could either be malicious or have compromised computers, including this part of the application in the penetration test made sense in an environment where sensitive data is gathered and processed.

Part of the application was built with Orbeon Forms [1]. One of the framework’s selling points is that forms can be designed directly in the web browser. Orbeon understands itself as a component of a web application rather than a whole web application on its own. Therefore, it does not implement authentication or session management, but leaves this to the embedding application [2]. In the presented case, access to the Orbeon Form Builder was only checked with the WAF and no other authentication or authorisation check was implemented to this functionality. With the WAF disabled for the tests, Oneconsult also had access to this functionality.

One interesting feature of Orbeon is that a form can include external services. These are meant to be HTTP-based services to be referenced by their URL. For example, this would allow the creation of a form that gathers user preferences of the company’s products, without that product list being entered into the form but fetched directly from their online shop. However, http:// is not the only scheme that can be used in URLs. Another one is file://, which is used to reference files that are accessible from the local system. Such a file can be on either the local hard drives or on any network share accessible to the system. During testing, Oneconsult found that the Orbeon Form Builder does not sanitise URLs with regard to unsupported schemes, which made it possible to read the content of local files and directories on the system. Our customer’s engineering partner immediately reported this vulnerability to Orbeon and they fixed it swiftly. During their investigation into the issue, Orbeon discovered that there were multiple instances where sanitisation was missing, as can be seen in the corresponding ticket on GitHub [3].

Usually, a local file read on an application server does not compromise more systems in the environment as the application is executed with the least amount of privileges necessary to run the application. An Apache webserver, for example, is executed as a user that, by default, only has the rights to read the necessary configuration files and to access the web application’s root directory. In this case, though, the application was executed as a local administrator. Even worse for our customer, the Platform as a Service (PaaS) provider had configured the same password for the local administrators on all reachable systems. Therefore, it was possible to access the local main storage of all systems that have been set up by the provider. With these access rights it was possible to exfiltrate a lot of sensitive data: From configuration files with passwords for connected services to administrative passwords for the environment to the file with all the password hashes for all domain users (i.e. C:\Windows\NTDS\ntds.dit). From this last file, further passwords could have been recovered by using a password cracking tool, but this was out of scope. However, the fact remains that, in this instance, a small vulnerability in a third-party software of a web application lead to the complete compromise of the internal domain.

This is an illustrative example of why thorough system hardening and application testing is an important part of every project release. Additionally, it shows that limiting access to the sensitive parts of an application is just good practice.

The following two blog posts discuss two specific aspects of system hardening, namely managing passwords for local administrators and managing user privileges (in German):

Conclusion

By outsourcing the noncore parts of an IT infrastructure, like the infrastructure of noncore web applications, direct control over that infrastructure decreases, which means that the implicit trust in the competence of the provider’s personnel has to be very high. This trust should always be accompanied and made explicit by a well-reviewed service contract, which allows testing of the purchased services and enables internal monitoring personnel to access data required to perform their task. Yet, there are more and more third-party libraries and applications included in software projects nowadays. For example, a WordPress plugin, which provides some style elements, is added to an internal website that provides access to a core service on the internal domain. Again, this code comes from mostly unknown sources, which is (implicitly or explicitly) trusted. From time to time, these libraries are found to be vulnerable by themselves and thus should be managed like any other application in terms of proper patch management.

If our customer had not had the far-sightedness to include the administrative parts of the application and set the scope accordingly, they would not have identified that critical vulnerability in a key third-party application and the misconfiguration of the underlying servers would not have been revealed either.

Therefore, when you plan your next penetration test, be sure to define your scope so that it enables you to achieve the goal you have set.

About the author

Severin Wischmann has studied computer science at the Swiss Federal Institute of Technology (ETH) in Zurich, one semester of which he spent in Sweden at Lund University. During his master studies he specialized in IT security and wrote his master thesis in the field of hardware security. Severin has worked as a teaching assistant at the ETH focusing on programming and as a software engineer for an e-commerce company doing web application development. He joined Oneconsult in October 2014 as a penetration tester and IT forensics specialist and became a senior penetration tester in April 2017. Severin is an Offensive Security Certified Professional (OSCP), a GIAC Exploit Researcher and Advanced Penetration Tester (GXPN), holds the GIAC Reverse Engineering Malware (GREM) certificate, is an OSSTMM Professional Security Tester (OPST) and an OSSTMM Professional Security Analyst (OPSA).

Markus Schalch has studied at the Swiss Federal Institute of Technology (ETH) in Zurich where he gained his degree in computer science (MSc ETH CS). During his studies he worked as a system administrator for a Swiss engineering company. For his master studies Markus specialized in information security and wrote his master thesis on jamming resistance in wireless communication. As an assistant in the lecture network security, he discovered his passion for penetration testing and gained first-hand insight into this field. Since September 2015 Markus has been working as a penetration tester and security researcher at Oneconsult and became a senior penetration tester and security researcher in April 2018. He is an Offensive Security Certified Professional (OSCP) and a certified OSSTMM Professional Security Tester (OPST).

About Oneconsult

Oneconsult group is your renowned Swiss cyber security services partner since 2003 with offices in Switzerland and Germany and 1600+ completed security projects worldwide.

Get expert advice from an owner-managed and vendor-independent consultancy with 40+ highly qualified cyber security experts, including certified ethical hackers / penetration testers (OPST, OPSA, OSCP, OSCE, GXPN), digital forensics specialists (GCFA, GCFE, GREM), ISO security auditors (ISO 27001 Lead Auditor, ISO 27005 Risk Manager, ISO 27035 Incident Manager) and dedicated IT security researchers to solve even your most demanding information security challenges. Together we address your external and internal threats such as malware infections, hacker attacks and APT as well as digital fraud and data leakage with core services like penetration tests / ethical hacking, real-life APT tests and ISO 27001 security audits. In case of emergency, Oneconsult’s incident response & IT forensics team supports you with around-the-clock expert assistance (24 h x 365 days).

www.oneconsult.com