Skip to content

Commit 81740fe

Browse files
authored
Merge pull request #183 from rubygems/martinemde/fix-typo
Fix a typo and missing link
2 parents 3e67d5a + 0a39ede commit 81740fe

1 file changed

Lines changed: 2 additions & 2 deletions

File tree

_posts/2024-03-15-password-reset-vulnerability.md

Lines changed: 2 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -19,7 +19,7 @@ On Dec 22nd, 2023, we received the report about multi-factor authentication (MFA
1919

2020
In the screen recording, the reporter showed the following:
2121

22-
1. Use a tool to store the full response from a valid password reset on an attacker controller user without MFA.
22+
1. Use a tool to store the full response from a valid password reset on an attacker-controlled user without MFA.
2323
2. Use the same tool to man-in-the-middle (MITM) the request by the victim (an MFA enabled user).
2424
3. Swap the saved response in place of the MFA challenge response for the victim before it is returned.
2525
4. Change every `user_id` in the page to the victim’s `user_id` (mostly to places that I could tell did not matter, which added skepticism).
@@ -34,7 +34,7 @@ I can come up with a lot of excuses for why I couldn’t possibly have seen this
3434

3535
## Investigation
3636

37-
Luckily the reporter was very responsive to my requests and I was open to being proven wrong. The report was filed at 5:30am Dec 22nd and by 7:30pm the same day we had communicated back and forth for hours. By the 3rd screen recording and after a discussion with Samuel Giddins, our AWS sponsored Software Engineer in Residence, we finally arrived at a proof of the vulnerability. The report had found a real issue.
37+
Luckily the reporter was very responsive to my requests and I was open to being proven wrong. The report was filed at 5:30am Dec 22nd and by 7:30pm the same day we had communicated back and forth for hours. By the 3rd screen recording and after a discussion with [Samuel Giddins](https://github.com/segiddins), our AWS sponsored Software Engineer in Residence, we finally arrived at a proof of the vulnerability. The report had found a real issue.
3838

3939
The vulnerability worked like this: the password reset form (the `edit` action in our rails app) was well protected behind MFA and an email token. You could not render the form without verifying your MFA credentials. However, the submit action on the form (the `update` action in our rails app) only checked the email token and did not care if you had previously submitted a valid MFA. Oops. _All the seemingly pointless changes the hacker was doing were for the purpose of rendering the form so it could be submitted without having passed the MFA check._
4040

0 commit comments

Comments
 (0)