A Private Bug Bounty Program had a globally readable .htpasswd file. I cracked the DES hash, got access to development and staging environments and was rewarded a shitload of$.
Today I want to share something with you that I recently discovered in a private Bug Bounty Program. Due to private program restrictions, I am not allowed to disclose the identifying details of the bug, so I’m just going to share my techniques and how I discovered it.
So, as a first step, I looked for potential vulnerable subdomains using a Google Dork query: site:*.REDACTED.com -www and then looked for interesting stuff. One particular domain caught my attention and so I had a look at it, admin.REDACTED.com. Upon review, the site looked pretty unspectacular and so I decided to use the tool „dirbuster“ to look for the juicy stuff. I was about to give up when I saw the tool discovered a .htpasswd file with an HTTP status 200. With a bit of excitement, I visited the URL and was pretty surprised to the file rendered.
So what exactly is this? As some of you may know, several webservers offer a mechanism called Basic Authentication. While I now knew the username was us3r, the password was still encrypted… Now, in similar cases, I’ve seen passwords simply being Base64 encoded but here, the encryption didn’t look like anything I was familiar with. After some Googling, I realized it was DES (Data Encryption Standard).. Based on what I read, while DES is now considered insecure and susceptible to theoretical attacks (thanks Wikipedia), there are no trivial methods known for DES cracking. So instead, I used a simple password cracking tool called john with the help of @nijagaw Nico who pointed me to a nice wordlist (Link) to crack it.
Loaded 1 password hash (descrypt, traditional crypt(3) [DES 128/128 SSE2-16])
After some time i finally had the encrypted password.
john --wordlist=/Users/Patrik/Downloads/crackstation.txt pw
Loaded 1 password hash (descrypt, traditional crypt(3) [DES 128/128 SSE2-16])
Press 'q' or Ctrl-C to abort, almost any other key for status
0g 0:00:00:04 5% 0g/s 3316Kp/s 3316Kc/s 3316KC/s 09554858..09554972
0g 0:00:00:27 52% 0g/s 2953Kp/s 2953Kc/s 2953KC/s 42333281..42333395
0g 0:00:00:28 54% 0g/s 2971Kp/s 2971Kc/s 2971KC/s 45154098..45154206
0g 0:00:01:56 35% 0g/s 3055Kp/s 3055Kc/s 3055KC/s CFCbu..CF(CC
Use the "--show" option to display all of the cracked passwords reliably
But what now? The website itself didn’t use any kind of .htaccess and, admittedly, I was a bit lost. However, thanks to the awesome @mongobug, I was able to figure out that each of the following was using Basic Authentication:
Additionally, the fun thing was the Username and Password I discovered worked on each and every one of them. In other words,I had access to the company’s development / beta environments.
The next step? Report it to the program owner who responded quickly, and resolved the issue even quicker. Kudos to them.
End of the story 🙂
Dear Readers, once in a while I enjoy blogging about things unrelated to bug bounties. And so, as it happens, on a quiet Thursday night as I was about to go to bed, I received the following e-mail:
Hmmm unwanted login from a location near Berlin? My younger brother lives in Berlin, I wondered if he logged in to my PayPal Account. I doubted it, so I decided to visit the link in the email. Clicking on it brought me to the following site:
Interesting, http://paypal.de-conflict.ru/ <- as you probably notice, this is definitely not something we should trust, it’s a phishing site. So ,as you may or may not know, I like to use the awesome tool dirbuster. After firing it up and targeting this address, I quickly find some juicy stuff:
- info.php <- PHP Info
- /classes/ <- misconfigured folder
- /backend/ <- Login Form
- /backend/install <- ;-)….
I hope this makes you smile too. First, I looked at the info.php and the system description revealed: Linux fox.hidden-server.ru 2.6.32-673.8.1.lve1.4.3.el6.x86_64 #1 SMP Wed Feb 10 08:57:30 EST 2016 x86_64.
So, based on the .ru, seems it’s a Russian service for criminal activities.
The directory /backend/ was just a simple login form asking for username and password -> I didn’t feel like wasting my time so figured this was a dead end.
Then I found the funniest part, the directory /backend/install:
Okay, good to know, apparently super criminals use the username admin and the password 123456. Think it’ll work on /backend/? Needing to know, I went back to /backend/ and tried the newly discovered credentials 🙂 Sure enough, I was logged in!
Tadaaaa the beautiful back end of a Paypal phishing service. As you can see in the charts on the bottom, there had been three visitors by the time I accessed the dashboard. I browsed through the dashboard and found a link to “data sets”, which included the phished Paypal credentials, Credit Card Numbers etc.
At the time, there were three entries, one from me, one of a victim and the first one ever submitted, which could be a test :-). On that note, if you’re developing a site, what’s the first thing you typically do after installing a new service? You test it out. Turns out, the owner of this was stupid to enter some credentials on the website to test the site, but didn’t realize, or care, that his IP address was saved too. I’ve censored the IP-Address because I can’t be 100% sure it was the one of him though.
After two hours of monitoring the website, there were a couple of real data sets of German phishing victims.
Hmm, it seemed as if more and more people were falling for this scam, so I decided to take some action against it… how you ask?
Well 🙂 I included on every place I could the phrase „Your IP is 85.25.*.*“ and went to bed to see what happens next.
Waking up on Friday, the first thing I did was go online see how many more data sets there were… and it turned out.. the site was gone 🙂
That’s it 🙂 the site is gone and the Russian criminal is now (hopefully) scared that someone recorded his actions and kept evidence of his online identity.
I know several of my e-mail addresses are likely in a database of phishing targets, as I receive similar emails almost daily. Those scam campaigns are mostly based on the same commercial sold phishing CMS system, my plan is to collect as many phishing sites I can find to test if those are similarly designed.
This post is intended for educational purposes and not meant to promote, incentivize or encourage any action which may or may not be considered illegal. None of the described actions are in any relation with my past, current or future employers.
Q = What happened to the harvested credentials?
A = I contacted the victims via mail (4 at that time) and each of them took care and followed the steps I suggested (change Password, contact Paypal, contact Credit Institute, lock the credit cards). Three out of the four contacted persons had a feeling that something strange was going on on that site but decided not to do anything. By the time I contacted them, they knew something strange was going on, and they were glad I took action and contacted them.
Today I want to share a short write-up about a stored cross-site scripting (XSS) issue I found on the Google Cloud Console. I consider it a lucky find. Some of you may remember the tweet I sent to Frans Rosén after he discovered a vulnerability on Google Payments:
As it turned out, among the unsuccessful XSS payloads I saved on my Google account, there was one that actually fired. But unexpectedly. When I was originally testing my payloads, I never managed to trigger the execution until recently and inadvertently. But let’s start from the beginning.
Here’s the video POC I sent in for the Google VRP:
That’s it 🙂
Thanks to Peter @yaworsk for editing :-)! Follow him and support him by buying his book ! For more technical writeups have a look at ERNW’s Insinuator blog, I blog there now and then about Mobile Security and IPv6.
If you have any questions please feel free to contact me at patrik.fehrenbach (at) it-securityguard.com