What’s going on ladies & gents? As you can probably already tell by the title of this post, we’ll be going over a security issue that allowed anyone to access and read 2 million pay monthly Verizon Wireless contracts that contained full names, addresses, phone numbers, device models and serial numbers, and signatures.
After some standard recon, I came across the following subdomain that was rather interesting:
telestore.verizonwireless.com. With some basic research, I came to learn that this was a subdomain used for employees to access internal Point of Sales tools and view customer information. With Google dorks, I found some valid paths of Verizon Employee tools and began to dirsearch them for more directories and files. From the Google Dorking, I also learnt the path used to view Verizon Wireless Pay Monthly customers contracts in PDF format - although we had to be authenticated for this - that always leading to a 404. I bruteforced GET parameters to find the
a parameter and the
With some results coming back from our dirsearch I learnt about a path that weirdly enough, set us a valid session.
Now that we’re authenticated…
Now that we were being treated as an authenticated user, we could go ahead and browse to the original paths located via Google Dorking. For some reason, from the authentication bypass we managed to find prior, it had linked us up to a specific phone number and contract number (??? nice). I checked whether this was determined in a cookie or something else and could be modified, but found nothing. Below is a screenshot showing the main page of the tool that we could access due to the authentication bypass (albeit linked to a specific agreement/phone number):
Even though we couldn’t modify the contract or phone number our session was linked to, it didn’t matter. We could simply click the agreement number and it would open the page we mentioned before to view the contracts in PDF format – with the
m parameters that we previously bruteforced. This time, it loaded. The first thing I decided to mess with was the
a parameter (meaning agreement), and see if there was an IDOR there. I figured there wouldn’t be because at first glance, it seems the agreement number and phone number has to match up – why else would there be two parameters matching up? I was wrong. As usual, it’s the small & stupid things that are overlooked that lead to the biggest issue. Simply modifying the value of the
a parameter changed the contract that we would be shown. The contract contained the following information on customers:
- Full name
- Mobile Number
- Model and serial number of device being bought
Below are pictures of what the contracts looked like:
After a quick check, I learnt that
1310000000 was the lowest contract number that could be viewed and
1311999999 was the highest. That means that there was information of around 2 million Verizon Pay Monthly customers exposed.
That’s all! Thanks for reading :)
(As usual, sorry for the boring post. I suck at writing.)
- Reported to VECIRT on 16/06/2019
- Patched on 15/07/2019
- Blogged on 09/09/2019
Daley Bee - https://twitter.com/daley