Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fix a typo and missing link #183

Merged
merged 1 commit into from
Mar 18, 2024
Merged

Fix a typo and missing link #183

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
4 changes: 2 additions & 2 deletions _posts/2024-03-15-password-reset-vulnerability.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -19,7 +19,7 @@ On Dec 22nd, 2023, we received the report about multi-factor authentication (MFA

In the screen recording, the reporter showed the following:

1. Use a tool to store the full response from a valid password reset on an attacker controller user without MFA.
1. Use a tool to store the full response from a valid password reset on an attacker-controlled user without MFA.
2. Use the same tool to man-in-the-middle (MITM) the request by the victim (an MFA enabled user).
3. Swap the saved response in place of the MFA challenge response for the victim before it is returned.
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).
Expand All @@ -34,7 +34,7 @@ I can come up with a lot of excuses for why I couldn’t possibly have seen this

## Investigation

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.
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.

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._

Expand Down
Loading