This included an internal API with a dependency on a third-party banking API. We'll get to the banking API later in this story.
That's all thanks to developers embracing agile development, microservices, and API gateway redirection that exposed something no one considered.
The whole point of API pentesting is to look at the target objectively with a clear and unbiased view.
The API servers were configured for years to only support a Content-Type of 'application/json'.
This makes sense since it was a RESTful API that relied on data models structured in JSON. In fact, we've had automated tests that verify that using any other Content-Type would return an HTTP status code of 415.
It turned out that the developers were working on an internal API to bridge between the main API and a third party that processes currency conversion and transfers.
As that external API required an XML call-back service, a slight tweak was made to the API framework to allow for a Content-Type of 'application/xml' for the new service endpoint.
They assumed the API gateway would protect them as they had yet to publish the new endpoints through it.
Let me sum it up by saying API gateways aren't always the smartest.
The tests were passing because the API gateway failed the request not the API server.
This one little config change to the API server to allow XML let me get a foothold on the API server thanks to XML Entity Injection.
This let me exfiltrate the API artifacts from the server and ultimately reverse engineer the compiled API into source code allowing me to find out about the external banking API before I should have known.
Some API frameworks will auto-detect the media type based on the payload. This technique has the added benefit that it can sometimes bypass content type filtering in WAF and API gateways.
Whenever I conduct a pentest, one of my personal goals is to get access to API artifacts and ultimately the source code.
Since I knew the API was written in Java using a special framework, I had a good idea of where to look for the files I wanted.
First, I needed to know the full path, including the filenames, of the API artifacts I wanted.
In this case, the API server was built upon a base image that included PHP binaries.
We've tainted a request to send the API server something it wasn't expecting, which returned to us the compiled assets of the API we wanted.
From there, I was able to hone in on the undocumented API endpoints, the expected models and schema, and the corresponding business logic within the API that used the external banking API. I won't bore you with the gory details, but the developers were right they weren't ready to release the code to this new functionality.
The post That time I broke into an API and became a billionaire appeared first on Dana Epp's Blog.
This Cyber News was published on securityboulevard.com. Publication date: Tue, 19 Dec 2023 17:43:05 +0000