Hacker News new | past | comments | ask | show | jobs | submit login
DontDuo: Bypass 2FA with DTMF Tones (dontduo.com)
54 points by w8rbt 9 days ago | hide | past | web | favorite | 58 comments





To explain what's going on here for the unaware —

1) Duo is a commercial service that offers multi-factor authentication through a variety of means, one of which is the Phone Call.

2) This site lets you register them as your Duo phone number, when demanded to do so by someone who's trying to protect your high-value access from being hijacked (such as your employer).

3) This site provides you a phone number that auto-accepts all Duo authentication requests, even if you're asleep, offline, or otherwise not authorizing the hacking activity.

4) This site has zero contact information and accountability, and could very well be backed by a black market site that offers hackers lookup access for any Duo phone number for $50/number.

NOTE: I, personally, would absolutely push to fire anyone I found using this, no matter where I worked.


It would help if Duo wasn't a closed off trash fire that no one should be forced to use. I'm not condoning bypassing it if it's something your employer has required, but there's really no excuse for not supporting an open method like TOTP and/or security keys.

If it were free, I'd be pretty tempted to use it, and hope somebody would notice my protest. Duo is thrust upon me by my university. I don't want to install Duo's proprietary app for receiving pushes or generating codes (I effectively can't anyway because my phone is de-Googled), and getting cell reception to receive their call can be difficult in some buildings. The other day it took three calls until the system detected my DTMF press, maybe because I was sitting next to a loud fan.

I dabbled at reversing their Android app, but I saw some references to key rotation and got disheartened -- I don't want to spend man-weeks on this. I was hoping to see some URL I could hit and just get a TOTP secret.

To my uni's credit, they offer support for hardware tokens, and maybe someday I'll get sick enough of the phone calls to start carrying one of those around.

Edit: Thanks to commenters in sibling threads with possible solutions to extracting the secret.


It’s free for upto 10 users I actually use it on some of my machines, with the call back features disabled.

There should be a URL that gives you a QR code for the TOTP/DuoPush enrollment.


Parent means the DontDuo service isn't free, not Duo itself.

Duo supports TOTP and U2F, it also supports now touchID on new Macs which makes it fairly easy to use.

I can get that the phone part is annoying but DuoPosh/TOTP and now the TouchID are probably the smoothest FMA solution for the enterprise I ever used.


It doesn't support these at my institution. Maybe they haven't rolled out this version? (Technically you can get U2F to work, but they have a bright red warning that says it's unsupported when you do that.)

IT admins at your org can enable or disable 2FA methods allowed via the Duo administration console. Many US edus disable TOTP.

I think because they don’t want to deal with supporting the app and (almost) everyone has a phone that can receive calls.

How does this problem relate to the post topic at hand? I can’t find the connection between “Duo doesn’t support TOTP and security keys” and “Duo phone method bypass for $4/mo”.

(Incidentally, Duo does support OATH-TOTP and Yubikeys in native mode.)


It's related because it's very easy to empathize with people wanting to bypass Duo, when Duo is a crappy proprietary app built on top of an open standard that people are forced to use.

Your "incidentally" comment is actually important: organizations have to enable these additional auth methods; mine does not support TOTP. If it was the case that people weren't forced to either answer the phone or use a crappy app to log in (and own a smartphone), there would be much less impetus to bypass it. The point is not bypassing 2FA. The point is bypassing Duo.


Who on earth thought this was a good idea, at any level?

You have an entire industry-ideology that says, "build things that people want and turn those wants into needs full stop". No mention of ethics at all [1]. Is it really surprising to see startups with blatant disregard for security and ethics?

[1] http://paulgraham.com/start.html


I, personally, would absolutely push to fire anyone who thinks that phone calls (or SMS) are reasonable second factors.

Or instead of handing over your second factor authentication to a startup web service, you could buy a Yubikey, leave it on your keyring or plugged into your laptop and just touch it.

Some Yubikey models also store the secrets that generate the frustrating 6 character TOTP codes. A pairing a Yubikey with a desktop app, you can copy/paste the codes instead of the error-prone process of manually re-typing them.


>Or instead of handing over your second factor authentication to a startup web service, you could buy a Yubikey

...assuming the service in question accepts yubikeys, or even TOTPs. I've seen plenty of services (mostly financial) that only allow sms or voice calls.


Duo implements a proprietary setup layer over HOTP (counter based instead of time based, useful for hardware key generators that don't have a clock). I needed it for my University and internship, and was able to set it up on an Android emulator (or rooted device), copy the secret key and counter off of the app's config file, and then use it on my laptop.

On the computer I have ~/.totp/ which contains files like `github` with the secret key as the file content. In my bashrc I made a function which runs oathtool on the contents of the given filename to generate the 6 digit code and then copies it to the clipboard with xclip (run it like `$ totp github`).

For the duo thing, I had to make the same `name` file with the secret key as the content, and a `name-counter` file with an integer. I put a hotp function in bashrc, so running `hotp name` generates the 6 digit code, copies it to the clipboard, and increments the counter.

I had to tell Duo I was adding a tablet (since the emulator had no phone number), it gives a QR code with a URL as a backup; I opened the URL in the emulator which opened the Duo app in the emulator and finished the setup. Then on the host computer run adb shell and cat out /data/data/com.duosecurity.duomobile/files/duokit/accounts.json from the emulator shell (or the shell on your rooted Android)

Get the 'otpSecret' and counter, at the end of otpSecret replace the \u003d with its actual character: '=', then put the secret into the file ~/.otp/name and the counter into ~/.otp/name-counter

Turns out I actually put a tiny script in my PATH instead of adding a function to bashrc:

    #!/bin/sh
    typeset -i counter=$(<~/.otp/name-counter)
    oathtool --hotp -b $(<~/.otp/name) -c $counter | xclip -selection clipboard
    echo $((counter + 1)) >~/.otp/name-counter
On macOS there's a `clip` command which you will have to use instead of xclip to copy to clipboard.

I have saved a very old (2 years?) version of the Duo APK which works great for this (or at least was working great the last time I tried, 2 months ago). The newer app versions refuse to run without Google Play Services, but you can still make a throwaway andorid emulator with GPS. I'd like to share the APK I have, but no way to do so without linking this pseudonym to my real identity...

The most idiotic thing is that basically the entire 2FA ecosystem fucked up into turning 2FA into phoneFA. Your password is a secret, it can be guessed by some hacker on the other side of the world, so let's have two secrets, with the second one being unguessably long and only known to your hardware, so that it can make a human-sized login code. There are standards for this like TOTP and HOTP, but instead of having basically password managers for these secret keys, we get SMS auth and Duo and Authy, with no way for a normal person to generate otp codes on their actual computer. Google Authenticator and even the Duo app actually allow you to scan QR codes with TOTP secret keys and get the 6 digit OTPs from their app, but Duo itself won't let you use the standards to login, or to do it on your computer.

For completeness, here's the TOTP function in my bashrc:

    function totp() {
     oathtool --totp -b $(<~/".totp/${1}") | xclip -selection clipboard;
    }
So if you have a file ~/.totp/github with the secret key as the content, you would open a terminal (or something like Guake/Yakuake) and run the command `totp github` and the 6-digit OTP would be in your clipboard.

I have been doing the same on AOSP with the andOTP app. Can't get why large companies/universities have boners for proprietary crap like duo. A company comes along and says, "Here's some textbook standard stuff, and here we add our lock-in on top of it. Would you like the lock-in ?" And everyone says, "Yes please."

For those suffering, this helps: https://github.com/puddly/android-otp-extractor

Edit: Responding to your edit

>with the second one being very long and only known to your hardware. There are standards for this like totp and HOTP,

TOTP/HOTP don't provide phishing protection. Neither does Duo (which is largely HOTP), but that's a different issue.

>but instead of having basically password managers for these secret keys, we get SMS auth and duo and authy, with no way for a normal person to generate otp codes on their actual computer

SMS auth is terrible, but TOTP/HOTP are also hard to secure. There isn't a meaningful way of securing the secret, and computers are far more insecure than phones. You don't want your 2nd factor on the computer if that's your first factor too. So the right way forward is hardware based keys. However, it should all still be open standards based. Not some hacked up garbage that needs google play services.


> Can't get why large companies/universities have boners for proprietary crap like duo.

It's like the classic HN argument of "Why don't you just use rsync/sftp vs dropbox" - because it's easier. For users, for admins, for the business.

The biggest problem with rolling out 2FA is onboarding and adoption.

Onboarding people is a massive pain in the arse. Issuing hardware tokens to people is even more of a giant pain in the arse, particularly if you have more than a handful of people in more than one city or country.

We deployed Duo because it allowed us to add 2FA reasonably easy to a wide range of services. It allowed us to require our contractors in countries like India and the Philippines to use it. They all have phones, even basic android devices can run it.

Rolling out physical tokens requires us to mail them out to people. Everything we sent to our offices in Spain larger than a letter got caught in customs for three months and/or "lost". Even USB thumb drives.

I've worked with people who are continually losing or destroying phones, keys, wallets, etc. Making them carry a hardware token, which will also get lost/destroyed means you're now constantly issuing them a new one.

On the systems side of things - it allowed us to add 2FA to devices that don't support it, or don't support the same 2FA you've chosen for everything else.

On the support side of things, it was dead easy to have automatic enrolment/signup based on existing processes (eg read LDAP/AD group membership), and it has a UI that actually allows us to properly delegate access to support staff.

Could we have rolled our own? Absolutely. But we'd have had to spend a lot more time, and a lot more money setting it up and maintaining it, and it gives good enough security.

Our biggest threat isn't a nation state or directed attack where someone can steal your phone and pull the token secrets.

Our biggest threat is Jim from Marketing who used the same damn password for his corporate email as he used when signing up for MarketingCon, and then having that registrant database leak.


I don't even have a strong objection to Duo or their offerings. If they can make a buck by automating stuff or reducing friction, that's fine. The only part I hate is the artificial end-user lock in. If they just called it HOTP and let the users use whatever client they want, that would be ok. Instead, they have this artificial wrapper around HOTP and make people use their app.

The universities often receive "grants" from the vendors to foster initial development along with incentives provided based on adoption and usage.. https://www.azcentral.com/story/news/local/arizona-education...

It's not just universities, it's basically any Windows centric place that seems to gravitate towards packaged solutions rather than understanding or implementing the tech piecemeal.

I feel that at least public universities have some responsibility to not peddle garbage like this. I don't know if there are laws about this, but requiring students/staff to use play services and blobs to access university infrastructure (all paid for by taxes and fees) shouldn't be a thing.


> A company comes along and says, "Here's some textbook standard stuff, and here we add our lock-in on top of it. Would you like the lock-in ?" And everyone says, "Yes please."

That's not the sales pitch, _at all_, and you belie your inexperience in this understanding. Perhaps if you tried working for a big company or a university and began to understand the scale of the things they deal with in regards to identity and access management, you'd understand better. Let me expand on this.

What a company like Duo, OneLogin, Okta, IDaptive, etc. offers is not "textbook standard stuff". Sure, under the hood their system no doubt uses a ton of open source components, like anyone's does, glued together with their own secret sauce. That's the product. It's part of what they're selling you, but it's not all. You need to consider:

* Service operations and maintenance

* Security, scaling and capacity issues, upgrades, etc

* Ongoing development to keep the product current with the market (not much use to offer an authentication solution if it doesn't have the protocols and capabilities the other apps in the market that it is going to be interfacing with will require)

* Support and documentation

* Privacy and compliance

* Implementation and onboarding services, integration consultation and other professional services

The product itself is a turnkey solution, virtually guaranteed by the terms of service to be be fit for purpose, which means your overworked team has some hope of actually implementing it to the point of onboarding users within a quarter / semester or two rather than waiting for a slow project to even set up and get a proof of concept working with a home-built solution.

I'm not saying there isn't a place for home built solutions - I myself have authored extensive home-brewed configuration management software and workflow automation code in an academic environment. Still, there are certain critical pieces of infrastructure that are absolutely best left to purchasing solutions from teams of professionals that have invested their life's work into one particular concern or other.

That said:

> TOTP/HOTP don't provide phishing protection

This is not quite true. You can get a user's password, but the whole point of 2FA is that the password on its own should be useless. Of course, if you're re-using that password somewhere else where there is no 2FA, there is a vulnerability; however, almost all external services run by a competent IT org should be fronted by the same IDP at this point, and if you're not there yet you have to spend the cash to do it if you want meaningful security. Stealing the password should be pretty close to a non-impactful event at this point.

It is true that it is far better to have push-based authentication set up - something Duo pioneered, and most vendors have also implemented. For my current set of users, I've made it a mandatory policy; we don't allow SMS or DTMF auth at all. However, one could still be fooled by a phishing page that mimicks our login screen; it would be the absence of a working push that would have to tip the user off that something has happened. Some say "user education" is the key here, and I have had some mixed luck with that.

> However, it should all still be open standards based. Not some hacked up garbage that needs google play services.

If we want the convenience of push auth (which is actually better thought of as fingerprint auth, if you have MDM on your end-user's phones and push a policy that incentivizes the use of Touch ID by virtue of making the password too long for thenm to want to type it), then we need to deal with app stores. It's not like any IT-supported end user is going to have a phone that isn't either a well-supported Android or iPhone model; getting push services working basically requires going with what the Big Two want on that front. What choice do we really have?

> So the right way forward is hardware based keys.

I've maintained an RSA infrastructure, and have dabbled in Yubikeys, but the fact is: these things are expensive, they need to be replaced more often than we'd like, there are license costs for many of them, users lose them or leave them at home, you might un out of stock of them and have difficulties onboarding people, auditing their rollout and usage is more difficult, support for using them with a mobile phone is shit, etc. so many of the advantages over a phone app are moot.

They also aren't as physically secure as a phone, obviously. One can imagine a situation where a high value target is spearphished for their password and mugged for their RSA key in the building's parking lot one day. I'd far rather a physically secure, GPS-trackable, remote-wipeable iPhone get lost with their software token on it than a push-button RSA token.

Cryptocards that require a password are a solution some government agencies use, in my understanding; this is also obviously going to be a turnkey proprietary solution that costs even more than anything discussed above.


Your response is too long, so I'll address only a few points:

>Perhaps if you tried working for a big company or a university and began to understand the scale of the things they deal with in regards to identity and access management

I manage my lab's freeipa setup. It lets you manage TOTP tokens. I think it also allows yubikeys, but I haven't checked. It may not be as full-fledged as other offerings, but you can manage. The university pays several vendors for different sets of services (MS for AD, RedHat for servers, Duo for 2FA etc.) Right now, Duo may be preferred, but there is nothing stopping you from paying RH for a freeipa+totp solution. Vote with your wallet and all that.

>This is not quite true.

It is. The threat model is different. It's about replaying the 2FA token. That's the whole argument against TOTP/HOTP.

> it would be the absence of a working push

The phishing site can generate a working push. It just logs in to the real site at the same time with your first factor, which generates the push.


> Your response is too long

Rude. Go ahead and run your small computer lab and pretend you're dealing with issues on the scale that companies with thousands or tens of thousands of employees do. They're absolutely choosing the cheaper option when going with a managed provider vs. your hacked-together TOTP solution.


There is nothing hacked together in this. If you are not aware, freeipa (called idm downstream by RedHat) is a pretty full featured solution with is more or less a replacement for AD if your clients are unix based. And RedHat will absolutely support your scale requirements. It is mostly that AD is a lock-in in itself due to windows, and duo will work better with AD, whereas idm/freeipa does not have a standalone 2fa product that would work with AD.

> more or less a replacement for AD if your clients are unix based

Few people are lucky (?) enough to support a purely unix environment. AD is not expensive when it comes to enterprise-scale projects and plenty of things simply require it for proper support, so I've never seen an enterprise that doesn't have it. I have seen enterprises with classic non-AD pre-Windows-2000 LDAP integrated alongside AD, but usually just as a legacy thing that's too hard to remove.

Considering the amount of resources available to help with AD vs. the amount you'd need to be able to support a 3rd party solution, it should be no surprise MS still has a stranglehold on this. What's more surprising is how badly they've fumbled the use of Azure AD, SSO, ADFS, etc. as real solutions compared to the cloud-first vendors like OneLogin, Duo, Centrify, etc.


Thanks, this is really cool.

> The newer app versions refuse to run without Google Play Services, but you can still make a throwaway andorid emulator with GPS.

Can't you run GPS on a rooted phone, or am I mistaken? (If not, what about with magisk?) I suppose if it will run on a phone with an unlocked bootloader, you could always keep it unrooted until you need to copy the hotp, then root it.

Amazing that they've managed to rent-seek on top of a freely available open standard.


You can run GPS on a rooted phone.

Duo does provide a very valuable service to organizations that pay for it - it's just frustrating for a user to be stuck with them.


I found a better method, actually. Someone reverse engineered the app. Actually very simple. https://github.com/simonseo/nyuad-spammer/tree/master/spamme...

OK that's clever but you are still bypassing 2FA and I am baffled why would you want to do that -- just switch off 2FA if it's annoying? If your employer doesn't let you and you bypass like this (I presume you are entering your password on the laptop too) then you are begging to be fired.

Your phone has an app with your work email on it, and probably ones with internal chat and other things too. Your phone has no 2fa - anyone who knows your passcode/pattern (and you need one even if you use a fingerprint) has access to all your work stuff.

Clearly, being able to access company resources without having two devices isn't the problem that 2FA is being used to solve. I just want to have the same ease of access on my computer that I have on my phone.


This is a horrible idea. I just can't. Why does this service even exist. I seriously hope duo figures out the numbers this site is using and blacklists them.

I think the point is that relying on phone calls and DTMF tones for two factor authentication is trivial to bypass. Anyone can record DTMF tones in a voicemail message and forward calls to that number.

"Anyone can record DTMF tones in a voicemail message and forward calls to that number."

I have never used "duo" and it has taken me a few reads of this to understand exactly what this is, but I think it's worth pointing out that your own personal 'dontduo' service would be trivially simple to set up in a simple twiml bin, at twilio.

I think it would look something like this:

  <?xml version="1.0" encoding="UTF-8"?>
  <Response>
  <play digits="1w2w3w4"></play>
  <Hangup />
  </Response>
"Include w to introduce a 0.5s pause between DTMF tones. For example, 1w2 will tell Twilio to pause 0.5s before playing DTMF tone 2. To include 1s of pause, simply add ww."

https://www.twilio.com/docs/voice/twiml/play#attributes-digi...


What do you mean trivial to bypass? If I have an account secured with a password and with Duo, then I give you my password, can you get into my account? How?

A "sim hijacking" attack is where an attacker calls your phone company and pretends to be you. They claim to have lost their phone, and get a new sim card issued to them with your phone number. when they put the sim in their phone, the duo authentication message goes to their phone instead of yours.

any 2-factor system based on the phone system is no more secure than your phone company's willingness to give away your phone number, and they're usually pretty willing. I actually had this happen to me, in a benign way: my employer started paying my phone bill, they transfered my phone number from my personal plan on one carrier to the company plan with a different carrier. Somebody at the office just handed me a new sim card and told me my old SIM didn't work anymore - it required no interaction on my part to transfer my number to a new plan with a new company. that's apparently just normal procedure.


This is brilliant! BRB gonna set that up right now.

2FA is one of those things that is nice when you want it but a huge PITA when it’s forced on you.


To prove to you that PSTN based 2FA is never a reasonable idea.

What is a reasonable idea when your adversary is the user?

How do you give a person secret knowledge that they need to provide you to authenticate but can’t provide to something else?


TPMs built into managed devices; USB hardware tokens for others.

I agree, this is a site that shouldn't exist, it's security disaster. Duo should blacklist all their numbers. One easy way would be to detect which accounts consistently confirm instantly; since humans can't do that, those accounts almost certainly must be connected to a subverting bot like this.

I mean it’s really no different than a password manager that stores both your password and your OTP key.

Those are strong words for a service that claims to save 3 frustrating hours a month. Let it be, it's how capitalism works — solving needs, no matter how tiny.

Pretty sure a dev made this for themself and decided to share


Having lived under a terrible bureaucracy that rolled out Duo to everything but make sure to set it up so that every. single. auth. required entering credentials and 2FA and expired all sessions every 12 hours I would have paid anything to get around it.

Services like Duo and Okta are enabling your least favorite IT admin to put users in ‘S’SO hell.


Remove your account defenses while simultaneously giving authentication information to a third party? What could go wrong‽

If you fill this out with the same email as the protected account, you're basically inviting an untrusted third party to launch a brute-force attack on your now-defenseless account.

Using this sounds like a good way to take liability when your account gets hacked. It will not look good to be fired for intentionally defeating corporate security systems.


Duo was one of the last things keeping me from switching to Google-free AOSP, and I toyed with a similar idea while trying to reverse-engineer a free software replacement. Instead, I ended up writing a small tool that allows you to use any old HOTP authenticator with Duo. I use FreeOTP+ on my phone, but you could just as easily stick that HOTP secret in a script or onto a Yubikey. You might find it useful if you're working your way up to 100% Stallman status: https://github.com/evan-goode/duolibre.

By the way, I gotta say this project is pretty hilarious, and you're a true baller for trying to sell this to people.


The website is strangely sparse. Just trust us. We're a website, we have https. All I could work out is that they're apparently from Georgia according to their generated T&C.

I got the trial. Gave me a 201 area code number. Called it and it waited some seconds after answering, played a DTMF tone and hung up. No, I didn't test it with Duo (lol). Every time this number receives a phone call it increments a login counter on the dashboard.

You may want to contact Twilio abuse and ask them if they operate that number, and if so, point them to the terms of service that issued it and note that they appear to be a flight-by-night credential harvester.

I'm very confused about what this is.

Duo as in Google's Duo video calling? There's 2FA on that? I've never seen any.

Or is there some other Duo it's referring to?


I assume this is referring to Duo Security, owned by Cisco: https://duo.com/

I was just as lost as OP. Can someone also explain how it uses DTMF tones? Is it using tones to deliver or receive 2FA codes? Scanned the above url but didn't see the info.

You register with this service, get a new phone number from them that they auto-answer, then provide this number to the security service. When the security service calls this number, it will play back DTMF codes to simulate whatever buttons you need to press to enter your code key.

It calls you, and then you need to pick up and press the one key to authenticate yourself.



Applications are open for YC Winter 2020

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: