RÉGIMEN DE REGULARIZACIÓN DE OBLIGACIONES

Url: stage.pornhub.com

Report Link:https://hackerone.com/reports/11987113

Date Reported: March 1, 2016 Bounty Paid: $2500

Description:

Prior to their public launch, PornHub ran a private bug bounty program on HackerOne with a broad bounty scope of *.pornhub.com which, to most hackers means all sub domains of PornHub are fair game. The trick is now finding them.

In his blog post, Andy Gill @ZephrFish14 _{explains why this is awesome, by testing the} existing of various sub domain names using a list of over 1 million potential names, he discovered approximately 90 possible hacking targets.

Now, visiting all of these sites to see what’s available would take a lot of time so he automated the process using the tool Eyewitness (included in the Tools chapter) which takes screenshots from the URLs with valid HTTP / HTTPS pages and provides a nice report of the sites listening on ports 80, 443, 8080 and 8443 (common HTTP and HTTPS ports).

According to his write up, Andy slightly switched gears here and used the tool Nmap to dig deeper in to the sub domain stage.pornhub.com. When I asked him why, he explained, in his experience, staging and development servers are more likely to have misconfigured security permissions than production servers. So, to start, he got the IP of the sub domain using the command nslookup:

nslookup stage.pornhub.com Server: 8.8.8.8

13_{https://hackerone.com/reports/119871} 14_{http://www.twitter.com/ZephrFish}

Application Logic Vulnerabilities 52 Address: 8.8.8.8#53

Non-authoritative answer: Name: stage.pornhub.com Address: 31.192.117.70

I’ve also seen this done with the command, ping, but either way, he now had the IP address of the sub domain and using the command sudo namp -sSV -p- 31.192.117.70

-oA stage__ph -T4 & he got:

Starting Nmap 6.47 ( http://nmap.org ) at 2016-06-07 14:09 CEST Nmap scan report for 31.192.117.70

Host is up (0.017s latency). Not shown: 65532 closed ports PORT STATE SERVICE VERSION 80/tcp open http nginx

443/tcp open http nginx 60893/tcp open memcache

Service detection performed. Please report any incorrect results at http://nmap.org/submit/ . Nmap done: 1 IP address (1 host up) scanned in 22.73 seconds

Breaking the command down:

• the flag -sSV defines the type of packet to send to the server and tells Nmap to try and determine any service on open ports

• the -p- tells Nmap to check all 65,535 ports (by default it will only check the most popular 1,000)

• 31.192.117.70 is the IP address to scan

• -oA stage__ph tells Nmap to output the findings in its three major formats at once using the filename stage__ph

• -T4 defines the timing for the task (options are 0-5 and higher is faster)

With regards to the result, the key thing to notice is port 60893 being open and running what Nmap believes to be memcache. For those unfamiliar, memcache is a caching service which uses key-value pairs to store arbitrary data. It’s typically used to help speed up a website by service content faster. A similar service is Redis.

Finding this isn’t a vulnerability in and of itself but it is a definite redflag (though installation guides I’ve read recommend making it inaccessible publicly as one security

Application Logic Vulnerabilities 53 precaution). Testing it out, surprising PornHub didn’t enable any security meaning Andy could connect to the service without a username or password via netcat, a utility program used to read and write via a TCP or UDP network connection. After connecting, he just ran commands to get the version, stats, etc. to confirm the connection and vulnerability. However, a malicious attacker could have used this access to:

• Cause a denial of service (DOS) by constantly writing to and erasing the cache thereby keeping the server busy (this depends on the site setup)

• Cause a DOS by filling the service with junk cached data, again, depending on the service setup

• Execute cross-site scripting by injecting a malicious JS payload as valid cached data to be served to users

• And possibly, execute a SQL injection if the memcache data was being stored in the database

Takeaways

Sub domains and broader network configurations represent great potential for hacking. If you notice that a program is including *.SITE.com in it’s scope, try to find sub domains that may be vulnerable rather than going after the low hanging fruit on the main site which everyone maybe searching for. It’s also worth your time to familiarize yourself with tools like Nmap, eyewitness, knockpy, etc. which will help you follow in Andy’s shoes.

Summary

Application logic based vulnerabilities don’t necessarily always involve code. Instead, exploiting these often requires a keen eye and more thinking outside of the box. Always been on the look out for other tools and services a site may be using as those represent a new attack vector. This can include a Javascript library the site is using to render content. More often than not, finding these will require a proxy interceptor which will allow you to play with values before sending them to the site you are exploring. Try changing any values which appear related to identifying your account. This might include setting up two different accounts so you have two sets of valid credentials that you know will work. Also look for hidden / uncommon endpoints which could expose unintentionally accessible functionality.

You should also be on the lookout for any time some type of transaction occurring, there’s always the chance that developers did not account for race conditions at the database level. That is, their code may stop you but if you can get the code to execute as quickly

Application Logic Vulnerabilities 54 as possible, such that it is almost simultaneously done, you may be able to find a race condition. Make sure you test things multiple times in this area because this may not occur with every attempt as was the case with Starbucks.

Lastly, be on the look out for new functionality - it often represents new areas for testing! And if/when possible, automate your testing to make better use of your time.