INTRODUCTION 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. TECHNICAL DETAILS (PROOF OF CONCEPT) First, it’s necessary to understand what path normalization vulnerabilities are. In modern web application environments, usually more than one server is being used for different purposes still being available from one host. To achieve this, front-end servers like load balancers and reverse proxies are being used, to then, based on specific routes, send those requests to internal, back-end servers.

The problem is that different servers’ implementations might possibly interpreted requests in a different way. One of area of such interpretation is how to normalize requested routes. For example, requesting /static/../robots.txt should get path normalized and /robots.txt should be requested. However, because of all sort of different ways URLs could be interpreted in web applications environments - sometimes attacker might trick front-end server not to normalize the path and at the same time – back-end server will do a normalization and access internal services. Some of those paths might be inaccessible from front-end server on purpose, for security reasons. This is the case of the issue identified on api.[REDACTED].com.

Below there is an example of tricky URL normalization request:
The server’s response: It can be noticed that WSO2 admin panel has been accessed. However, requesting directly the /carbon/admin/login.jsp doesn’t provide such response. That’s the basic proof for accessing the internal service.

The copyright footer line states “2018”, suggesting it’s not a recent version of WSO2. Quick search revealed plenty of vulnerabilities found over last years - some of them allowing unauthenticated remote code execution. One of techniques used by the auditor use Siddhi Streaming testing module, that allow to perform code execution thanks to authentication bypass. To better understand how WSO2 works, as presented on the screenshot below, auditor first created local instance with similar version used on production application. Then, it was possible to proof that such Siddhi module allows to achieve remote code execution: After testing it locally, auditor created payload code that provides reverse shell from [REDACTED] API server to self-controlled machine: The URL-encoded payload above, has been sent as the following HTTP request: Then, a reverse shell popped instantly: Auditor was able to get access to WSO configuration files, database plaintext passwords, list of hostnames for the API, access to the Internal Network etc. It was also possible to interact with AWS metadata endpoint, that possibly would give more reliable access to the server through SSH: Reviewing configuration files on the server, revealed plenty of plaintext passwords for other internal services, databases access and as being used on production could lead to massive data breach of customer’s data. SUMMARY It has been recommended to client to properly normalize paths on WSO2 front-end server, so it won’t be possible to access internal services. Additionally, it was strongly recommended to update WSO2 to the latest available, stable version of WSO2 software.