How I found an exploit in a Paypal vendor ticket server(blog.pentestbegins.com)
blog.pentestbegins.com
How I found an exploit in a Paypal vendor ticket server
http://blog.pentestbegins.com/2017/07/21/hacking-into-paypal-server-remote-code-execution-2017/
29 comments
The incompetence of those responsible at PayPal is startling. This is such a basic exploit, my goodness. At least they acknowledged and fixed it in a timely manner.
I wouldn't be too hasty to blame the employees. A lot of times, bugs are a result of organizational structure. As they say, you ship your org chart. It can happen very easily that a feature relies on collaboration between many teams and more often than not there isn't a single person who has a good understanding of the whole pipeline. Bugs sneak in easily.
Someone, or a group of people, is responsible for deploying this server in its configuration. These people are incompetent. I don't care if it's an engineer or leadership or corporate structure problem - it is a problem caused by incompetence. If you have a potentially lethal car accident because the car was faulty, nobody's gonna say "Oh well, it's just the corporate structure, nobody is responsible."
I'm not crazy about the form of the blog post but it does have some content so I posted it.
Right. It's hard to see the text between all the gifs.
$('img').hide() worked nicely
Still images I can handle; it's the animation which really distracts from being able to read the text.
This smells strongly like farmed out to 3rd party creative agency work. Different domain, basic off the shelf PHP help desk software etc.
A lot of time organizations don't have developers, and rather than work with the product organization within their company to get an idea pitched and approved and implemented, they just contract it out to an agency. The end result is some server running AWS, not connected to the real companies network, but with your brand on it, and no real support from a security and administration perspective.
A lot of time organizations don't have developers, and rather than work with the product organization within their company to get an idea pitched and approved and implemented, they just contract it out to an agency. The end result is some server running AWS, not connected to the real companies network, but with your brand on it, and no real support from a security and administration perspective.
Better title: "How I found an exploit in a Paypal vendor ticket server."
Clearly the title is meant to bait an interest in financial vulnerabilities. A "Paypal server" is as meaningful a name as a "Google webpage".
Clearly the title is meant to bait an interest in financial vulnerabilities. A "Paypal server" is as meaningful a name as a "Google webpage".
OK let's use that above.
Is it though?
Who knows what kind of "soft center" is around the "hard shells" of these organisations?
For starters, the "uname -a" he ran shows the server's kernel to be from Jan 2016. Right from the top of my head, this is probably vulnerable to "dirtycow" (for which there are weaponized exploits on github).
Who knows where root on this server can get you? You're not allowed to check. Legally that's black. No bug-bounty program allows you to go beyond the "/etc/passwd" print.
Who knows what kind of "soft center" is around the "hard shells" of these organisations?
For starters, the "uname -a" he ran shows the server's kernel to be from Jan 2016. Right from the top of my head, this is probably vulnerable to "dirtycow" (for which there are weaponized exploits on github).
Who knows where root on this server can get you? You're not allowed to check. Legally that's black. No bug-bounty program allows you to go beyond the "/etc/passwd" print.
> For starters, the "uname -a" he ran shows the server's kernel to be from Jan 2016.
Who lets an Internet-facing production server run for a year without updates?
(So, okay, it is possible that whoever is responsible for that machine did install updates but did not reboot the server. But that still leaves that server running with a known vulnerability.)
Who lets an Internet-facing production server run for a year without updates?
(So, okay, it is possible that whoever is responsible for that machine did install updates but did not reboot the server. But that still leaves that server running with a known vulnerability.)
> A "Paypal server" is as meaningful a name as a "Google webpage".
If you can execute on a server that serves a "Google webpage" then I'll be impressed. No, it doesn't have to be google.com.
If you can execute on a server that serves a "Google webpage" then I'll be impressed. No, it doesn't have to be google.com.
A ticket vendor server that was explicitly allowed in the CSP in PayPal.com sites. Not as benign as it seems.
True, and that might be worth mentioning in the title as well - but my post was not about how benign the contents of the article are. The point is whether "hacking a Paypal server" makes people expect what the post is actually about. This Paypal-administrated server might give you access to the nuclear launch codes, but the title is still misleading.
[deleted]
down vote cause of click bait title
I love reading write-ups like this, it gives me so many ideas about how to attack my own applications. Distracting gifs aside, it's well presented and easy to follow and reproduce on similarly vulnerable platforms.
Really he got access to a sever running php help desk software. Nothing really important or crazy. The exploit was as simple as uploading a command executor script.
My wife's credit card used to be tied to her PayPal account. It was stolen 4 times in 2 years and we had no idea why until our bank asked if she's been using it with PayPal and so she removed it and we haven't had a card theft event for about a year now...
Not to say that Paypal's security is flawless, but it also depends on your wife's behaviors as well.
Not having it attached to her PayPal reduces the attack surface a bit which isn't a bad thing.
It's also completely possible that it either wasn't stolen from PayPal or that an unrelated breach (reused passwords on a compromised site etc) allowed someone to access the PayPal account.
Not having it attached to her PayPal reduces the attack surface a bit which isn't a bad thing.
It's also completely possible that it either wasn't stolen from PayPal or that an unrelated breach (reused passwords on a compromised site etc) allowed someone to access the PayPal account.
I have maxed out the number of cards PayPal allows you to link to your account for years (8 or 9 cards I think) plus two bank accounts. Yet I haven't had any issues with unauthorized charges.
Awesome find and excellent writeup.
But I have to say that I find those flashy gifs and memes a little bit distracting.
But I have to say that I find those flashy gifs and memes a little bit distracting.
he hacked into https://www.paypal-brandcentral.com/
\
not paypal.com
not paypal.com
Would love to see more of these articles on Hacker News; very educational, almost adventurous, Kevin Mitnick style (obviously not quite).
I know that Paul Graham had a different definition of "hacking" in mind when he started HN, but still. I love these hacking write-ups.
I know that Paul Graham had a different definition of "hacking" in mind when he started HN, but still. I love these hacking write-ups.