Mistakes were made, and there are definitely lessons to be learned, but if we want to improve the state of security, we really need to change the way we react to these types of bugs.
If a service has an outage and a company posts a postmortem, we all think: "wow! that was an interesting bug, lets learn from this".
We shouldn't be treating security issues differently.
People who make security mistakes aren't idiots. They aren't negligent. They're engineers just like us, who have tight deadlines, blindspots and mistakes.
Shaming people and companies for security bugs will only cause less transparency and less sharing of information - making us all less secure.
This is a really cool bug. Kudos to the researcher for finding it, responsibly reporting it, and to paypal for fixing it in a timely fashion.
Hopefully - this type of bug changes some internal processes and the way the company thinks about 2FA.
As for security questions - these are obviously insecure, and should really never be relied on. If you can opt out of security questions - do so. If you can't - just generate a random password as the answer. "I_ty/:QWuCllV?'6ILs`O12kl;d0-`1" is an excellent name for your first dog / high school. Just don't forget to use a password manager to store these.
I disagree. Your "lets be super nice to everybody" strategy has come to an absurd conclusion. Is there no-one who can be held accountable for competency which they claim, when it comes to computer stuff?
PayPal doesn't write on its websites "We're some enthusiasts with no software or security experience. Let's see how well this works, together!" No, like everyone in this industry, PayPal claims its security experts have your money and financial information super secure. It's one of the first in this space, and has almost two decades of experience.
This wasn't a tricky subtle bug, this was obvious. This should have been caught in code review and tests. PayPal should be afraid of rolling out slick easy-to-use features without code review and tests. It is many years too late for PayPal to be learning the basics.
> If you can't - just generate a random password as the answer. "I_ty/:QWuCllV?'6ILs`O12kl;d0-`1" is an excellent name for your first dog / high school. Just don't forget to use a password manager to store these.
Be wary of social engineering attacks though.
- <support on the phone> I'd also need you to provide me an answer to your security question. What was your first dog's name?
- <me> Oh, you know, it's a long string of random characters I generated, I'd have to give them to you one by one...
- <support> (looks at the answer) uh, right. I see. Let's continue then.
While I strongly agree with the thrust of your comment, I'd like to chime in and say that this is not a cool bug. On the scale of web security bugs, this is the kind of thing you expect an intern to find.
I actually think the post was written in recognition of that fact, and was amused by the thudding, abrupt conclusion it had; it was like the author was sharing a joke. "Yup, it was that easy".
People who do this kind of security work (check out the rest of the author's posts) tend to be running their browsers piped through a local interception proxy. Once you develop the habit of mind to look for stuff like security parameters, it's hard not to notice these kinds of things. I think more developers should tool up the same way and learn the same habits.
All great points and true! The problem is PayPal hasn't been a great company to so many people their practices are abysmal. I've had my company account frozen more then once and it was a terrible experience and it's happened to lots of people. This is a company that makes a lot of mistakes and has bad judgement. They don't deserve my understanding. They haven't earned it. Other companies have.
But otherwise you are right. Less scrutiny more understanding so companies will be open and honest when they screw up.
Indeed - I've long since given up on security answers/questions as being secure. Kind of defeats the purpose of unique passwords if all the answers are common knowledge...
Had to laugh at one instance where I actually had to read out the 30 character secret answer on one support phone call :P
The problem is in PayPal's case, 2FA has been terrible for years. I've even been locked out of the account for a whole week because of their shitty SMS sending service. This prompted me to disable 2FA on Paypal, because weirdly enough that makes me feel "safer" (as in safer from losing my money due to Paypal's stupidity by being locked out of the account).
So in this case I'm certainly not one to say "hey, mistakes were made - let's give them another chance." They've been getting reports about their 2FA system for years. So there's no excuse at this point.
PayPal's 2FA broke on me when it started locking my account every time I attempted to use it, because I'd previously made it send too many SMSes (poor signal).
I was thankful that support let me disable it, but it was worrying they didn't try to verify that I actually controlled my device first.
The simplicity of this exploit demonstrates something profound. The most dangerous things in life are not hidden deep in the weeds. Rather, they stare us in the face in the most obvious spots. It isn't the unknown that presents the biggest threat. It is the known that we never gave a second look.
The cardinal rule of security is: you never, ever, trust anything the client sends.
This bypass is a perfect example. Although author doesn't mention which interception proxy he used, I'm 99% sure it was Burp. Replaying modified content is trivial.
One of my PayPal 2FA phone numbers is listed twice and both cannot be removed (errors when I try). Their support can't help with the situation because their side wasn't able to see the duplicate.
Is 17 days an acceptable TAT here? I know investigation and fixes can be a challenge, but with the severity of this exploit+PayPal being a serious financial service, I kind of would hope for a faster fix. Maybe I'm off base...I really don't know; curious what others think.
How much time would've had to pass (without PayPal doing anything) before the author is ethically obligated to post to HN/media/etc about the hack? I believe publicizing an (unpatched) exploit like this crosses into criminality, but it would be essential to demonstrate some kind of proof, for credence and gravity. I'm guessing the community has some standardized guidelines for this sort of thing, but I'm not aware of them.
Notice that 17 days is basically what is needed to add the issue to the next sprint, complete its development along with everything else for that sprint, and deploy to a live site. To me that sounds fair.
The "standardized guidelines" sometimes vary -- mostly dependent on the nature of the vulnerability -- but 90 days seems to be a pretty common timeframe. That's what Google gives others before they publicize the details, for example.
I've seen equally as ridiculous web bugs, computing prices browser side in javascript, credit card numbers encoded in REST API endpoints, financial websites not supporting 2FA at all or mixing http requests into the sites. We're solidly in the dark ages of web security still.
When I went to setup my online account for my old bank, I entered a randomly generated 16 digit key and got an error; "Maximum password length limited to 6 characters...only alpha-numeric"
I called to inform them that their account creation was broken, because obviously that was a bug. They told me that sometimes people have a hard time remembering their password, so they "need to balance between ease of use and security". My jaw dropped and my head rolled off my shoulders.
It's been a looong time ago but I remember when some instant messenger application was found to be performing authentication client side -- i.e. "Hey server, I'm $user. I promise!" and you were in.
I want to say it was Yahoo Messenger but my memory could very well be lying to me.
What exactly is wrong with offering SMS 2FA? I don't have a smartphone, but I have a great little prepaid phone. Why should I get no features just because they are not necessarily as good as it gets ? Also, as far as I'm aware, all of the major "attacks" on SMS 2FA are just the fact that a smartphone can be compromised in many ways. I have much less attack surface: an attacker would need to reprogram my undocumented exotic architecture phone with a bug in a parser which is probably too small to contain bugs of that nature.
The other way is SMS MITM, which on some networks is demonstrated feasible, but requires basically setting up an SDR near the victim, a lot more complicated.
With my prepaid provider, customer service is shoddy but would need considerably more to do a number port than just the number.
By removing SMS 2FA you gain nothing, and I lose my only viable second factor.
As I just mentioned elsewhere on this thread, SMS isn't the problem here. I use a VeriSign dongle for PayPal 2FA but PayPal still offers the same option of using security questions instead. I was previously under the reasonable assumption that the security questions form was ar least handled correctly, but apparently not.
This seems like a good time to rant about PayPal 2FA and its poor usability.
Every time I open the PayPal app I have to wait for a text message and type a code across. That should not be necessary! PayPal should count the app as the second factor and only ask for the password. I am happy to us 2FA with Google because I only have to use it when on a new device, or once a month or so in the browser.
Second, support 2FA apps like Authy already. SMS based 2FA is both insecure and unreliable.
This is scarily simple. Profit indeed for a black hat. Coupled with a recent post about Gmail on how phone carriers are the weakest link, I just don't feel safe with anything but a dongle based 2fa these days.
Unless the master key is compromised allowing anyone to generate authenticator codes, as I seem to recall happened a few years ago with a major provider.
Am I the only one who found it odd that the author had internet access, but there was no phone signal? Maybe it's because I'm Kenyan, where phone penetration is much higher than internet penetration, and where internet access over GSM has the biggest share of the internet access pie chart.
This often happens when I'm travelling internationally. If I plan on buying a local sim card instead of purchasing a roaming plan - I might not have access to my SMS until I get back home.
Not really. If you're American international roaming fees are usually pretty steep so many times if you want phone service you get a local number. WiFi is ubiquitous, especially hotel wifi.
Just looping trough input arguments from the client, validating them and then acting on them gives the client control of the code execution.
It's not enough to validate each input argument. You musth also verify that all parameters are really there and no extra parameters can slip into the system. The whole combination must make sense. Enumerating all used parameter combinations in a record that can be changed easily is one way to solve this.
I'm assuming that the relevant code, is simply an if statement checking for the existence of the url parameters, not even checking if the security questions are correct.
Or they designed it to show a variable number of security questions (so management could come along and say "we need 4 questions now" without causing havoc). Then they'd iterate through the responses, verifying them against the appropriate question. Simply forgetting to enforce that the number of questions asked has to equal the number of responses sent would cause the described vulnerability.
Nowhere in the article does it say that the POST data was in the URL. As I understood it, he was editing the request body before the request was sent to PayPal's server.
[+] [-] dkopi|9 years ago|reply
If a service has an outage and a company posts a postmortem, we all think: "wow! that was an interesting bug, lets learn from this". We shouldn't be treating security issues differently.
People who make security mistakes aren't idiots. They aren't negligent. They're engineers just like us, who have tight deadlines, blindspots and mistakes. Shaming people and companies for security bugs will only cause less transparency and less sharing of information - making us all less secure.
This is a really cool bug. Kudos to the researcher for finding it, responsibly reporting it, and to paypal for fixing it in a timely fashion. Hopefully - this type of bug changes some internal processes and the way the company thinks about 2FA.
As for security questions - these are obviously insecure, and should really never be relied on. If you can opt out of security questions - do so. If you can't - just generate a random password as the answer. "I_ty/:QWuCllV?'6ILs`O12kl;d0-`1" is an excellent name for your first dog / high school. Just don't forget to use a password manager to store these.
[+] [-] ploxiln|9 years ago|reply
PayPal doesn't write on its websites "We're some enthusiasts with no software or security experience. Let's see how well this works, together!" No, like everyone in this industry, PayPal claims its security experts have your money and financial information super secure. It's one of the first in this space, and has almost two decades of experience.
This wasn't a tricky subtle bug, this was obvious. This should have been caught in code review and tests. PayPal should be afraid of rolling out slick easy-to-use features without code review and tests. It is many years too late for PayPal to be learning the basics.
[+] [-] TeMPOraL|9 years ago|reply
Be wary of social engineering attacks though.
- <support on the phone> I'd also need you to provide me an answer to your security question. What was your first dog's name?
- <me> Oh, you know, it's a long string of random characters I generated, I'd have to give them to you one by one...
- <support> (looks at the answer) uh, right. I see. Let's continue then.
[+] [-] tptacek|9 years ago|reply
I actually think the post was written in recognition of that fact, and was amused by the thudding, abrupt conclusion it had; it was like the author was sharing a joke. "Yup, it was that easy".
People who do this kind of security work (check out the rest of the author's posts) tend to be running their browsers piped through a local interception proxy. Once you develop the habit of mind to look for stuff like security parameters, it's hard not to notice these kinds of things. I think more developers should tool up the same way and learn the same habits.
[+] [-] fritzw|9 years ago|reply
But otherwise you are right. Less scrutiny more understanding so companies will be open and honest when they screw up.
[+] [-] SoreGums|9 years ago|reply
[+] [-] mtgx|9 years ago|reply
So in this case I'm certainly not one to say "hey, mistakes were made - let's give them another chance." They've been getting reports about their 2FA system for years. So there's no excuse at this point.
[+] [-] jamez1|9 years ago|reply
What would actually qualify as negligence in your view of the world!? This is as bad as it gets, this isn't an ordinary mistake.
[+] [-] henrymanager|9 years ago|reply
[deleted]
[+] [-] pkamb|9 years ago|reply
http://imgur.com/a/Tu1AN
https://www.reddit.com/r/SocialEngineering/comments/3kgw3s/p...
[+] [-] TazeTSchnitzel|9 years ago|reply
I was thankful that support let me disable it, but it was worrying they didn't try to verify that I actually controlled my device first.
[+] [-] the7nd|9 years ago|reply
[+] [-] bostik|9 years ago|reply
This bypass is a perfect example. Although author doesn't mention which interception proxy he used, I'm 99% sure it was Burp. Replaying modified content is trivial.
[+] [-] 1812calif|9 years ago|reply
it seems to be an unfortunate emergent behavior of groups of humans.
[+] [-] agildehaus|9 years ago|reply
This is not surprising to me.
[+] [-] ryanfreeborn|9 years ago|reply
How much time would've had to pass (without PayPal doing anything) before the author is ethically obligated to post to HN/media/etc about the hack? I believe publicizing an (unpatched) exploit like this crosses into criminality, but it would be essential to demonstrate some kind of proof, for credence and gravity. I'm guessing the community has some standardized guidelines for this sort of thing, but I'm not aware of them.
[+] [-] blazespin|9 years ago|reply
Security questions are hardly really that great of 2FA protection anyways.
[+] [-] noamyoungerm|9 years ago|reply
[+] [-] jlgaddis|9 years ago|reply
[+] [-] xorgar831|9 years ago|reply
[+] [-] Itsdijital|9 years ago|reply
I called to inform them that their account creation was broken, because obviously that was a bug. They told me that sometimes people have a hard time remembering their password, so they "need to balance between ease of use and security". My jaw dropped and my head rolled off my shoulders.
I didn't setup an online account.
[+] [-] jlgaddis|9 years ago|reply
I want to say it was Yahoo Messenger but my memory could very well be lying to me.
[+] [-] discordance|9 years ago|reply
Also, PayPal really needs to stop using SMS for 2fa.
I expect more from a payment processor that is linked to my bank account.
[+] [-] microcolonel|9 years ago|reply
With my prepaid provider, customer service is shoddy but would need considerably more to do a number port than just the number.
By removing SMS 2FA you gain nothing, and I lose my only viable second factor.
[+] [-] vinay427|9 years ago|reply
[+] [-] aguo|9 years ago|reply
I really wish they had Google authenticator or Yubikey support.
[+] [-] necessity|9 years ago|reply
[+] [-] TorKlingberg|9 years ago|reply
Every time I open the PayPal app I have to wait for a text message and type a code across. That should not be necessary! PayPal should count the app as the second factor and only ask for the password. I am happy to us 2FA with Google because I only have to use it when on a new device, or once a month or so in the browser.
Second, support 2FA apps like Authy already. SMS based 2FA is both insecure and unreliable.
[+] [-] chirau|9 years ago|reply
[+] [-] algesten|9 years ago|reply
Good thing is it works without access to my phone.
Bad thing, the app has a unique ID that PayPal only allows me to use for one of my three accounts.
Wish they implement TOTP.
[+] [-] bad_user|9 years ago|reply
In the security section I don't even have that option.
[+] [-] phreack|9 years ago|reply
[+] [-] vinay427|9 years ago|reply
[+] [-] tmzt|9 years ago|reply
[+] [-] DavidWanjiru|9 years ago|reply
[+] [-] dkopi|9 years ago|reply
[+] [-] nommm-nommm|9 years ago|reply
[+] [-] TazeTSchnitzel|9 years ago|reply
This happens to me at home. Poor cell reception, but WiFi.
[+] [-] gargravarr|9 years ago|reply
[+] [-] unknown|9 years ago|reply
[deleted]
[+] [-] 0xmohit|9 years ago|reply
I've come across a few authentication bypass vulns that seem similar.
[+] [-] nabla9|9 years ago|reply
Just looping trough input arguments from the client, validating them and then acting on them gives the client control of the code execution.
It's not enough to validate each input argument. You musth also verify that all parameters are really there and no extra parameters can slip into the system. The whole combination must make sense. Enumerating all used parameter combinations in a record that can be changed easily is one way to solve this.
[+] [-] ryanlm|9 years ago|reply
[+] [-] kelnage|9 years ago|reply
[+] [-] gengkev|9 years ago|reply
[+] [-] danielsamuels|9 years ago|reply
[+] [-] yashafromrussia|9 years ago|reply
[+] [-] mrcarrot|9 years ago|reply
[+] [-] continuational|9 years ago|reply
[+] [-] andrewvijay|9 years ago|reply