Bypass Sistema de doble factor de Authy.com

Se ha encontrado una vulnerabilidad en el sistema de autenticacion de doble factor de Authy.com con tan solo digitar "../SMS"

Segun cuenta Egor Homakov, un investigador de seguridad independiente de Sakurity, quien reveló la vulnerabilidad de "inyección" que afectó el servicio Authy a través de una biblioteca de código abierto de uso común.

Con tan solo digitar ../sms pueden pasar por alto el segundo factor es utilizado por 2FA authy.com.

el proceso de trabajar con authy es simple y consta de dos llamadas a la API:

1. El cliente solicita un nuevo Token http://api.authy.com/protected/json/sms/AUTHY_ID?api_key=KEY  donde AUTHY_ID es el identificador públicamente disponible asociado con la cuenta de usuario corriente. Respuesta esperada : {"success":true,"message":"SMS token was sent","cellphone":"+1-XXX-XXX-XX85"} con estado 200
2. El usuario envía la señal de vuelta y el cliente comprueba si el elemento es válido con http://api.authy.com/protected/json/verify/SUPPLIED_TOKEN/AUTHY_ID?api_key=KEY y autentica con el segundo factor si la API responde con el estado 200.

Todo comenzó con la comprobación de las bibliotecas SDK. Todo parecía bien, excepto por authy-nodo, que no codificaba una señal antes de colocarlos en la URL - — this._request(«get», "/protected/json/verify/" + token + "/" + id, {}, callback, qs);

Sólo se puede insertar VALID_TOKEN_FOR_OTHER_AUTHY_ID/OTHER_AUTH_ID#  se tendria que sobrescribir la ruta y hacer el envío del cliente de modo que esto siempre devuelva el estado 200.cualquier cosa despues del Hash # es ignorado.
/protected/json/verify/VALID_TOKEN_FOR_OTHER_AUTHY_ID/OTHER_AUTH_ID  Es imposible distinguir petición forjada a partir de una válida en el servidor porque #/AUTHY_ID no se envía.

Despues descubrio un Bug interesante en authy-python: urllib.quote el cual codifica todos los caracteres excepto una barra y qué se puede hacer con una barra? Puede tratar de insertar  /../? como ya deben saber,  /../, /%2e%2e/  significa "subir un directorio" en los navegadores. Sin embargo, el servidor no tiene que tener esta característica.
ver tabla URLencode

FUNCIONAMIENTO:

1. El atacante digita "../SMS" en el campo del token de verificacion
2. La aplicación cliente lo codifica como "..%2fsms" y hace una llamada a la API para Authy - https://api.authy.com/protected/json/verify/..%2fsms/authy_id.
3. Path_traversal middleware decodifica la ruta a: https://api.authy.com/protected/json/verify/../sms/authy_id divide por barras y elimina el directorio frente a /...
4. actualmente Authy API ve la ruta modificada https://api.authy.com/protected/json/sms/authy_id  simplemente envía otro SMS al authy_id  y responde con el estado 200. {"success":true,"message":"SMS token was sent","cellphone":"+1-XXX-XXX-XX85"}.
5. Toda la biblioteca SDK de Authy consideran el estado 200 como respuesta exitosa.

Fuente:
http://sakurity.com/blog/2015/03/15/authy_bypass.html