back to article Authy 2FA app popped by simple, secret, code

Attackers could bypass the Authy two factor authentication (2FA) system by typing a phrase in a token field. Authy's apps make it possible for punters to log in to services like Gmail, Dropbox and Facebook, or even Amazon Web Services, with a one-time password sourced from an app. But prior to the advent of a patch issued 8 …

  1. Lee D Silver badge

    Sigh. Security 101.

    Sanitise your inputs.

    Do not act upon the data as if it's a filename, program name or anything else.

    Don't pass off unsanitised data to other programs.

    Don't allow directory traversal.

    This isn't just "a slip", this is just atrocious coding. Stop using this program, because god-knows-what other basic security mistakes have been made elsewhere in its coding.

  2. Dan 55 Silver badge
    Thumb Down

    Unit testing, we've heard of it

    Directory paths and slashes in input are probably one of the first things that should have been on the list to be tested, so we can be fairly sure that they haven't done any apart from making sure the log file doesn't fill up with too many errors.

  3. Raumkraut
    FAIL

    User-supplied paths

    Faulty input validation is one thing, and the most obvious that people pick up on, but I can't help feeling that this occurred entirely because of a fundamental wtf in the API design:

    It introduces path traversal making attacker’s job much easier - you only need to type '../sms' to turn /verify API call into /sms (/verify/../sms/authy_id) which will always return 200 status and will bypass 2FA,

    So they appear to be using an HTTP-based API. In the HTTP protocol there are explicit places for communicating user-supplied variables - in the query string or POST body. So why, for the love of Tim, are they putting the (user-supplied) verification code in the request path?

    That's just.... no.

    1. Anonymous Coward
      Anonymous Coward

      Re: User-supplied paths

      Say thanks to all the script-kiddies banging out JS-based apps with Node.js etc and zero concept of good coding practice.

      Ship first, ship fast, ship shit. The holy trinity of the web 2.0 world and their bizarre bazaar.

      Bring back the cathedral!

    2. Anonymous Coward
      Anonymous Coward

      Re: User-supplied paths

      They possibly listened to SEO twats, and made it google friendly!!!

    3. Michael Wojcik Silver badge

      Re: User-supplied paths

      In the HTTP protocol there are explicit places for communicating user-supplied variables - in the query string or POST body. So why, for the love of Tim, are they putting the (user-supplied) verification code in the request path?

      While I agree, generally speaking, with the sentiment, the HTTP specification (RFC 2616 for HTTP/1.1) does not distinguish between the abs_path and query-string portions of Request-URI for this purpose, or between the Request-URI and the message-body. All of that data comes from the client (generally the user agent, though some intermediaries, such as proxies, may alter it), and all of it is untrusted.

      The CGI 1.1 draft specification (never standardized) did explicitly allow program data in the abs_path (what you call "the request path" above). The actual CGI program can appear before the end of the abs_path, and any subsequent path components are passed to it as "PATH_INFO". It's up to the server to decide how the abs_path is partitioned between program-specifier and path-info. Presumably it does so by looking for a translated path component that refers to an executable and not a hierarchical container, though that distinction may be somewhat arbitrary on systems without hierarchical filesystems.

      Of course, CGI is widely deprecated these days, and using this design pattern for anything security-related is almost certainly a terrible idea.

  4. Destroy All Monsters Silver badge
    Windows

    #include <DolanDuck.h>

    Sinatra dependency rack-protection

    I suppose this is not something for women so why the hell is it a dependency on whatever authentication scheme is being implemented? What happened to straightforward simple shit that someone can understand and audit?

    "Modern" programming: "Dependencies, dependencies, dependencies"?

    With no checks.

    1. Michael Wojcik Silver badge

      Re: #include <DolanDuck.h>

      Sinatra is a Ruby gem that provides a DSL for creating simple web apps. It's the new Perl for the new CGI. The fact that we didn't need new versions of either of those things is immaterial; everyone knows DSLs are Good In Themselves.

      Rack::Protection (not "rack-protection"; Darren seems to have copied that from Egor's blog post) is a Ruby gem for Rack, Rails, and other frameworks that's supposed to prevent "common" web vulnerabilities. Sinatra uses it unless told not to. As Egor points out, this is Yet Another case where adding "security software" reduces security. It turns out the Ruby communities bullets are not so silver after all. Shocking!

      I haven't investigated it, but I suspect the problem is that Rack::Protection is removing the URL-encoding of the "." characters and then normalizing the Request-URI, so the "../" part of the token ends up removing the previous element from the abs_path.

  5. Elfo74

    Reminds me of Bobby Tables...

    http://xkcd.com/327/

  6. This post has been deleted by its author

  7. Downside

    confused about Authy

    The article could do with more words for the hard of thinking like me.

    I just don't understand it.

    The screen grab in the article looked like the bit on a web login to gmail or you tube where it asks for the 2FA code.. not the Authy app on the phone.

    So what's broke? The implementation of 2FA used by all of these services, or the Authy app or what?

  8. Pez92

    > This is also a great example how libraries or features that aim to add security actually introduce security vulnerabilities.

    By nature of being 2FA, this is false. You don't use an authy token in place of a password, it's in addition to the password. So no matter how badly authy implements their software, it cannot possibly make your accounts less secure. It just is the equivalent of not having 2FA.

    > So what's broke?

    The phone app is generating a valid token and the snippet on the websites is sending the unsanitized auth token, and then authy's server is reading the unsanitized token and executing commands with it. So the app is fine, ideally the website snippet should be updated to sanitize inputs, but they could actually get by with a hotfix by simply patching their servers to sanitize received auth tokens before reading them. I just tried it out and the exploit no longer works so it appears they've already done so.

  9. mrbbq

    hipster api

    Couldn't have asked for the user-provided input as a POST parameter... nooo, some hipster decided the API needed to look all sexy. Sigh.

POST COMMENT House rules

Not a member of The Register? Create a new account here.

  • Enter your comment

  • Add an icon

Anonymous cowards cannot choose their icon

Other stories you might like