How to bypass the two factor Authy Authentification with ../sms

With the help of simple input ../sms it was possible to get around the second factor on sites using 2FA via authy.com ( there are quite a lot of them ).

The most interesting thing is that such an annoying vulnerability appeared through no fault of Authy, and I found the whole chain of bugs with great luck.

So, the process of working with authy is simple and consists of two API calls: api.authy.com/protected/json/sms/AUTHY_ID?api_key=KEY for requesting a new token and api.authy.com/protected/json/verify/SUPPLIED_TOKEN/ AUTHY_ID? Api_key = KEY to verify the received token from the user. Both calls must return 200 status, then the request is considered successful.
')
1. It all started with checking their SDK libraries. Everything looked good except for authy-node, which did not encode the token at all before inserting it into the URL - this._request ("get", "/ protected / json / verify /" + token + "/" + id, {}, callback, qs );

You could simply insert VALID_TOKEN_FOR_OTHER_AUTHY_ID / OTHER_AUTH_ID # into the token field and rewrite the API request so that it always returns 200 status, which was considered as confirmation of the second step and allowed the attacker to the account. The fact is that everything after # is considered a fragment and is not sent to the server, and a request of the form / protected / json / verify / VALID_TOKEN_FOR_OTHER_AUTHY_ID / OTHER_AUTH_ID will return 200 and cannot be distinguished from ordinary requests.

2. Then an interesting bug was noticed in authy-python: urllib.quote encoded all the characters except the slash (why I don’t understand). Hmm, what can be done with a slash? Maybe try to insert /../? As you know, /../, /% 2e% 2e / and even /% 252e% 252e / mean “go up one directory” in browsers. But the server is not required to have such a function. However, I decided to send ../sms for the sake of the test and it worked! I still have no idea why, but by inserting ../sms we turned / verify a call into / sms call (/verify/../sms/authy_id) which returned 200 and allowed us to account.

3. And then I remembered that I was reading Daniel's interview on Authy architecture recently. It said that Authy uses Sinatra, which is dragging rack-protection, which I remember had a module called path_traversal.

And the most interesting thing here is that it turned out that path_traversal for some reason decoded the path back and killed the directories before /../. Well, in theory, this was supposed to protect developers from potential path traversal vulnerabilities. In practice, this was the cause of such a serious vulnerability.

So, in order:

1. I enter ../sms in the token field

2. The client encodes this as ..% 2fsms and makes a request to api.authy.com/protected/json/verify/..%2fsms/authy_id

3. path_traversal decodes the received URL at an early stage in api.authy.com/protected/json/verify/../sms/authy_id , divides everything by / and deletes the directory / verify

4. Now the application itself receives a modified path api.authy.com/protected/json/sms/authy_id which sends SMS to the victim and returns 200 status and the answer {"success": true, "message": "SMS token was sent", " cellphone ":" + 1-XXX-XXX-XX85 "}

5. Our client who wanted to check our token sees 200 status and concludes that the token is correct. Even if a custom implementation of the API is used, the client is most likely looking for success = true, which is also present in our answer.

Simply put, typing ../sms in the token field could bypass two factor authentication on all sites using Authy.

There is another wonderful text about a similar vulnerability with the bypass of the first factor through the insertion of the symbol | in another popular 2FA provider Duo Security , but I am too lazy to translate it.

There was a link that we are looking for hackers, but it was deleted. Write in a personal please, if you find this kind of vulnerability during morning exercise.