Case Study : Exploiting a Business Logic Flaw with GitHub’s Forgot Password workflow (discovered by John Gracey)
John Gracey of Wisdom published a very interesting business logic flaw in GitHub’s reset password workflow on November 28th, 2019. It was acknowledged and fixed by GitHub’s security team. If not mitigated, this flaw can lead to account takeover vulnerability (specifically for accounts with 2FA not enabled).
From ASCII to Unicode
ASCII (American Standard Code for Information Interchange) had became the first widespread encoding scheme. However, it was limited to only 128 character definitions. This was fine for the most common English characters, numbers, and punctuation, but slowly became limiting for the rest of the world.
Naturally, the rest of the world wanted the same encoding scheme for their characters too, which was why the Unicode standard was created. The objective of Unicode was to unify all the different encoding schemes so that the confusion between computers can be limited as much as possible.
As John Gracey points out, developer understanding of unicode is often limited to internationalization and hence fail to grok details associated with unicode points and units. This lack of understanding could lead to an inherent vulnerability called Unicode Case Mapping Collision.
Loosely speaking, a collision occurs when two different characters are uppercased or lowercased into the same character. This effect is found commonly at the boundary between two different protocols, like email and domain names.
~ John Gracey
On November 24th 2019, GetWisdom had published an exhaustive list of case mapping collisions with english alphabets here . Following this article, John published a detailed case study of the logic flaw here. I’d recommend for you all to read John’s post in detail before you proceed further.
Hacking Unicode Case Mapping Collision
Let us attempt to emulate this business logic workflow associated with resetPassword functionality
- Attacker enumerates with a unicode character embedded in local part of email address (not domain part). For example: `jıll@service.com`
- Attacker clicks forgot-password and types the email (for example: `jıll@service.com` where `ı` is the unicode character)
- The business logic supporting forgot-password function receives the attacker controlled email address and case-folds (toLowerCase) as a part of sanitization practice. This case folding transformation leads to a Unicode Case Mapping Collision which fundamentally transforms the identity to another user’s email address — `jıll@service.com` with a unicode `ı` is transformed into `firstname.lastname@example.org` due to case mapping collision.
- Of course, the validation passes leading to next step of creating a reset link and dispatching an email to address specified via request (which is attacker controlled) and NOT to email-address associated with registered account (retrieved after validating identity).
Let us use this sample spring-boot based application (forked and revised) with forgot password functionality that emulates both a best and worse scenario associated with this logic flaw.
If you're already a student of Learn Spring Security, you can get started diving deeper into registration with Module 2…
Refer to controller logic supporting password reset here (with all symptoms that can lead to an exploit)
- Attacker enumerates Forgot Password function in SaaS service with an embedded unicode character.
- Attacker controlled userEmail parameter is injected into the resetPasswordBad controller routine.
- Validation function findUserByEmail accepts attacker controlled email address that is transformed (via caseFolding) and passes validation condition (if registered user exists).
- Email with reset password link is now sent to to address specified via request (which is attacker controlled) and NOT to email-address associated with registered account (retrieved after validating identity).
Automated verification of Business Logic flaws in source code
Let’s fire up ShiftLeft’s Ocular query engine and trace through information flows in order identify all of these missteps leading to this Business Logic Flaw.
At this stage we have extracted the attack surface and identified all controller functions mapped to exposed routes. Let us proceed to next step.
This route particularly is of interest to us is
RouteMapping( “[\”/user/resetPasswordBad\”]”, “org.baeldung.web.controller.RegistrationController.resetPasswordBad:org.baeldung.web.util.GenericResponse(javax.servlet.http.HttpServletRequest,java.lang.String)” )
CONDITION #1 : Attacker controlled vector (email) with unicode in local part is case folded and then passed to database validation routine
CONDITION #2 : If condition #1 passes, a reset token of a registered user is sent to attacker controlled email (with embedded unicode character)
Safe Coding to prevent this business logic flaw
- Observe for anomalous volume of password resets (forgot password requests) initiated upon your application. An attacker is most likely enumerating your end point.
- Use two factor authentication (2FA) as a part of validation and reset functions.
- As John Gracey suggests, use punycode conversion as a part of your registration, validation and reset functions. Validate for both, local and domain part of email addresses.
- Continuously verify your entire fleet of applications in a CI/CD pipeline to ensure that none of the conditions above are violating baseline checks in any current and future releases.
- Send out password reset email ONLY to the original email address that was used to create the account and NOT to email address controlled by attacker.
ShiftLeft is an application security platform built over the foundational Code Property Graph that is uniquely positioned to deliver a specification model to query for vulnerable conditions, business logic flaws and insider attacks that might exist in your application’s codebase.
If you’d like to learn more about ShiftLeft, please request a demo.