Blocked

Challenge#

It seems like the developers of the patient portal have included a bit of a backdoor in case somebody forgets the admin password: https://patientportal2025.mendixctf.com/ws-doc/

Unfortunately, it seems like access to the backdoor is blocked :(

We did some social engineering and managed to find out that the block is only IP based.

Surely there must be a way to get around something as simple as that :)

Application: https://patientportal2025.mendixctf.com/ws-doc/

Difficulty: Insane

Solution#

The web service path is restricted via an access restriction profile. A first review of the ws-doc documentation, calling the endpoint and looking at the request didn’t provide many starting points. An IP address starting with 10. is part of a private IP address range reserved for local networks. So we decided to see if we could trick the check by deploying an app to the Mendix cloud; in the hope that it would use some sort of network routing that would make the Restriction Profile think it was an internal network request. To no avail, it was still rejecting the request.

Paths Based Access Restrictions and Restriction Profile are both quite flexible in terms of configuration. Both the path and the IP filtering allow free text entry. So there must be a way that Mendix is able to match these configurations so it is able to apply a filtering profile to a path. What would be a probable mechanism approach for path-based configuration resolution would be?….pattern matching, for example with regex (we needed a little hint to get in the right direction). Which brings us to the next step: which URL will the web server accept but that will cause the regex match to fail?

I asked AI to generate a list of “complete fuzzing list” of /ws alternatives that a web server may normalize differently but would all match different regex patterns. Which wasn’t very helpful, it put me on the path of url encoding and other normalization mechanisms. Failing me to provide me with any good examples I was ready to give up on this challenge. The verbose answers of AI did however included examples with query and matrix parameters in urls. With some old-fashioned StackOverflow and Internet searches I found more information on what a regex could parse differently and a nginx server would still accept as a valid url.

It was already getting late, I was back in my hotel room after a few drinks. Tired yet determined, I continued working on the challenge. I decided to first try an alternative approach; see if they forgot to turn on the path access restriction profile on acceptance. The url was easy enough to guess https://patientportalctf2025-accp.apps.eu-1c.mendixcloud.com. Unfortunately they applied the same path restrictions on acceptance. Meanwhile I kept sharing my progress and findings with my team mate Marius, hoping we would see the path.

I returned to the url parsing confident that this was the correct path, and there was no easy way for this insanely difficult challenge. Some more attempts at finding a good ws string that would fool the regex parser and still be a valid url for the nginx server finally paid off. I was in!!!

There it was the response to the POST request on the WS url: <![CDATA[Password reset successful: CTF{SOAP}]]>. But the success was short lived. The flag wasn’t accepted by the CTF scoreboard! This can’t be! It must be correct! Luckily Marius was still more awake than I was… and he noticed I was still on the acceptance environment. So another request to the production url POST https://patientportalctf2025.apps.eu-1c.mendixcloud.com/ws;/WS_ResetAdminPassword provided us with the correct flag! 😅

Vulnerability#

We tend to rely on Mendix for cloud security, but sometimes there is a vulnerability to exploit. I would classify this as TSU-10: Insecure Cloud Deployments — a misconfiguration in a cloud-based web server or API gateway. Although one could argue for TSU-07: Insecure custom authentication or TSU-04: Insecure published integrations as well.

Flag#

Keep calm and carry on.