Bakers delight

Challenge#

Oops. It seems some of our bakers might have lost their password…

Application: https://pizzamario2025.mendixctf.com

Difficulty: Medium

Solution#

It’s one of my favorite features to explore in CTF challenges. The Forgot Password module is frequently misconfigured, creating opportunities to exploit weaknesses in the authentication flow. In the challenge there are two hints: we need to look for a baker and a password reset flow.

Password reset usually requires an Administration.Account (or any other specialization of System.User). In the PizzaMario app Administration.Account is used. Via the Client API we can retrieve all Accounts visible to us (or ofcourse Ciphix). This already provides us with a piece of the puzzle: a baker account with an email baker5368.B9Kxl@pizzamario.com. We can’t see the username, but we’ll get there.

mx.data.get({xpath:"//Administration.Account", callback: function(obj){console.log(obj)}})

As a next step we will explorer the password reset flow. On the login page a Reset Password button is available. Well that was an easy find, but let’s dig into what it does and doesn’t do. It requests both an email and username. A quick check with Ciphix returned nothing noteworthy. I moved on to ZAP (similar to Burp), my go to tool for further analysis. As a proxy it can track (and intercept) all network requests & responses. Similar to the network tab in the browser’s developer tools it helps understanding the client <> server communications.

Failing the password reset flow gives us an error with another hint. ‘Resetting a password can be hard… If only we knew something about the bakers working at Pizza Mario. Have you tried complaining? Wouter Penris @ Sopra Steria’. Trying the Pizza Complaint challenge is probably required to get a baker associated to your customer which allows us to see the account.

In this particular flow something jumps out, the email and username appear to be validated in separate requests: MFC_StringEmailValidate and MFC_StringUsernameValidate, only after that it will trigger the Step2_SendEmailRecoverPassword flow. Maybe we can enter the email of the baker and our own username as a valid scenario? The request/response section looks interesting, it contains more information than we get on the screen. It gives us away to get the username for the baker. Now we can request a reset with our email and the baker’s username! After completing the password reset flow we get the flag in the email. And a baker account for future use =)

During this write-up I got errors on the recover password flow so I couldn’t verify each step.

Vulnerability#

Password reset functionality is a risky business as it is part of authentication and identity management. It leads to weak or misimplemented authentication mechanisms as the system puts too much trust in user input or fails to enforce identity verification and access controls. In this example users can reset passwords for other accounts, bypassing verification. This maps to TSU-07: Insecure Custom Authentication.

Flag#

One does not simply configure ForgotPassword.