Back in March the well-publicised repeal of Obama’s broadband privacy regulations made headlines everywhere. Published under H.Res.230 it allowed for ISP’s in the United States to no longer seek consent for collecting and marketing user information.
Interestingly, there was little focus on the middleman in all of this: the data broker. Data brokers can come in all shapes and sizes but generally buy and sell user data of all types, ranging from specific marketing opt-in data on a website to more mundane data that is already public (such as births, deaths, divorces, etc.).
I embarked on an analysis of data broker sites to examine what kind of security was in place for data brokers with a web presence. After all, if these data brokers were going to amass ever-greater collections of user data, it would make sense that this user data is protected adequately to avoid the ever-depressing regularity of breaches we have become accustomed to.
For this research, I focused on US-based data brokers because the regulation impacts them directly and the United States historically has less stringent rules on data protection than we are used to in Europe. I based myself on the list of data brokers collated by www.privacyrights.org – a non-profit based in the US that campaigns for increased user privacy.
As the research is in progress, I’ve anonymized all screen captures and will omit website names as discovered vulnerabilities are currently going through responsible disclosure with the various companies involved.
First of all, encryption, or rather, the lack of it. Of the top 100 data brokers, only 25% utilize some kind of encryption on the landing page. It improves when we get to a login page and gets bumped up to 50% but this is still poor.
The encryption scores are mixed with only 50% of those using encryption actually getting an ‘A’ score on SSL Labs. To make things worse, several data broker sites are vulnerable to ‘session fixation’. This means that the session cookie you are dealt with on the landing page is identical to the one you’re issued after successfully logging in.
Combine this with no encryption on the landing page and an attacker in a man-in-the-middle position has effectively nullified the encryption since he can sniff the cookie in clear and ride your encrypted session all the way (it’s the same cookie).
Onto other vulnerabilities. Although I’ve only covered 20 data-brokers so far, two SQL injections (SQLi) were discovered on two separate sites (see images below).
Ignoring that it might be possible to escalate these to remote code execution, they give access to a substantial number of records. Combined, these two data brokers cover in excess of 20 billion separate records.
Client-side vulnerabilities are even more prevalent. Out of the first 20 sites, we have cross-site scripting (stored, reflected and DOM-based) in 10 out of 20 data brokers. One notable stored cross-site scripting is exposed on a site that has over 10,000 daily visitors on the landing page. Worse still is the presence of some of these on the actual payment pages themselves (see below).
What is interesting is most of these pages are stuffed with ‘secures seals’ which obviously don’t work - the XSS above matches the footer below:
It doesn’t stop there, although I do have to stop for brevity: there are cross-site request forgeries, open redirect and indirect object references abound on many of these pages. There are also fewer configuration issues that plague them – the most common being admin interfaces exposed to the entire internet.
As for defense mechanisms, these generally boil down to ‘security-as-a-service’ offerings. Aside from the redundant ‘secure seals’ that appear on payment pages, subscriptions to CloudFlare and Incapsula bot protection services could be detected on a few broker sites. These were insufficient to prevent exploitation of common vulnerabilities, since the enforcement actions were configured to ban sessions or IP addresses for a few minutes.
Leveraging access to Tor nodes made these restrictions trivial to bypass. One site had the Cloudflare web application firewall offering that protected it against payloads sent in the URL’s correctly, but anything sent in the body of a HTTP Post request was ignored, so I could still exploit stored XSS vulnerabilities this way.
Before I reach any conclusions, lets start with a few caveats:
- This is preliminary research, which although indicative of a larger trend, doesn’t cover all the data brokers, and focuses exclusively on US-based data brokers
- Some data brokers exclusively collect and distribute data that is already public, such as marriages, divorces, births and deaths so the impact of this data being leaked is less severe than data intended to remain private. It can however ‘enrich’ other leaked data to build complete profiles of individuals over time.
So what does this all mean? Firstly, data broker protective measures are woeful, mainly consisting of security-as a-service offerings and security seals, which are not effective countermeasures on their own but best placed in a defense-in-depth stack. The fact that most sites don’t even implement transport layer security as standard shows the lag they have with the security of mainstream sites today.
Secondly, it means we are now entering the age of the mega breach. In the way that breaches in the hundreds of millions of records are becoming the norm today, we will soon become accustomed to breaches containing billions of records a few years from now.
Lastly, this is an area crying out for regulation. Opening up access to larger and larger pools of consumer data should bring with it corresponding shifts in security obligations, which are sadly lacking today - at least in the United States. Until then, it’s watch and wait.