4 ms·

> you simply change the last part of the URL from “/acr/oow/” to “/acr/report,” and the site would display the consumer’s full credit report. Oh wow, that's on

> you simply change the last part of the URL from “/acr/oow/” to “/acr/report,” and the site would display the consumer’s full credit report. Oh wow, that's one of the dumbest security hole I've seen so far. That means you're either authenticated in the first screen, or the second assumes that you are whom you say you are if you lend on it. There's a clear lack of ethics from whomever built that, whom either didn't care, or didn't know enough know enough to excuse themselves from building it and ask for assistance. I mean, this is not your regular system. Everyone is in there, not that they have much of a choice, and it's their most sensitive data, that you decide you're up to the task to protect. I'm all for learning from your mistakes and I'm the first one to screw up once in a while, and to admit that I am not a security expert. But the size of this combined with how freaking dumb this issue is... This is most likely gross negligence. In most of other industries where people call themselves engineers, you would be putting your own professional reputation on the line when deciding you're up to the task. Then you would get in front of am ethics commission and likely get your license suspended or revoked.

vinceguidry 4y ago
It's nineties-level internet security. Stuff like that was the bread and butter of security researchers of that era.
- contingencies 4y ago
  Closely related period fail: /receipt/<sequential-receipt-number-here>.pdf = all customers full booking history and personal data for all time.
- NovemberWhiskey 4y ago
  I mean, sure, but nothing has changed since: "Broken Access Control" is still #1 on the OWASP Top Ten for 2021.
xnorswap 4y ago
It's just a classic IDOR, it's very easy to fall into with some frameworks. If you look, you see it everywhere. When stack-exchange rolled out their CV feature they had a similar thing which leaked everyone's email address regardless of the public profile visibility or whether they had even used the CV feature.
- bcrosby95 4y ago
  I seem to recall github having this security hole in spades about a decade ago.
suzzer99 4y ago
I'm still struggling to think how this could have happened. I wonder if it has something to do with interaction with annualcreditreport.com? Maybe originally the code had multiple levels of authenticating the user: 1) we know who you are, but you haven't proven it yet, and 2) you've proven it, now you can see everything. But when they integrated with a 3rd party, which could have been a decade or more after the original code was written, some developer who didn't understand the code just lumped everyone who came over from annualcreditreport.com into basket #2, even though that user still had to go through the url flow to prove themselves. Just a guess. I don't think most non-programmers realize how often preventing this kind of thing comes down to one developer making a stink repeatedly to indifferent higher-ups. If that one developer is incompetent or doesn't care, no one else does.
- xnorswap 4y ago
  I don't know about this case, but a lot of the time this class of vulnerability comes down to lack of Authorisation rather than lack of Authentication. So much effort is put into checking that people are who they say they are (is Person X really Person X) , they forget to check that they're authorised (is Person X actually supposed to be accessing resource Y). Given the URLs don't have the actual resource Identifier, it means the resource ID will have been gathered from somewhere else, typically one of three places: 1. Cookies / Localstorage - Easily manipulated and should never be treated as a secure place, it's easy to put simple values here and forget that they still need to be validated / checked server side, and that just because you have access to /foo/Y you might not also have access to /bar/Y. 2. Session - An ASP favourite, sticking something in a key like Session["FolderID"] you might assume you've validated and checked authorisation when you set the key, then later re-use (deliberately or accidentally) the same key elsewhere leaving it open for manipulation. And then you might assume you don't need to re-check authorisation when you read the key.
  - herpderperator 4y ago
    I wouldn't call the "session" concept an ASP favourite - it's the industry standard for any backend web framework to use a user session where the session key is stored as a random cookie value and the actual key-value pairs are stored on the backend somewhere.
8note 4y ago
Credit agencies have no reason to care about their security wrt your data. You aren't their customer, and they don't owe you anything
mancerayder 4y ago
These folks never did a basic penn test ? Unauthenticated access to a different URL seems like a common thing to test for.
- acdha 4y ago
  That's … optimistic in my experience. I've had reports include breathless disclosures that our application was leaking private information because robots.txt could be accessed without authentication, or that we were disclosing source code (front-end JavaScript). Places which treat security as an audit checkbox are going to try to outsource that work to save money and they're going to get people who have enough skill to run a few basic tools but not to reason about the results or do anything creative. Experian seems highly likely to be on that side since they've been able to avoid any significant penalties for past negligence.
ec109685 4y ago
This is where per-user level encryption of data should be used. If your credit report on that site is encrypted and the keys are only successfully derived by answering your security questions, you've added another layer of security [1]. It also prevents the situation where a hacker gets access to the box doing the security check, and they can read everyone's data versus just those users who are concurrently asking for their reports. Even simpler, this would be prevented if /acr/oow set a decryption key as a cookie after validating the verification data that was then used by /acr/report to decrypt your credit report. [1] Yes, it's possible to enumerate over all user's security answers, so it's not perfect, but it ensures a simple mistake with an if condition, doesn't release everyone's data.
jimhefferon 4y ago
It seems like they owe us all compensatory damages. Big damages. I never really understood how they could take my information, which presumably belongs to me, and then could use it to make millions. How about my cut?
- fsckboy 4y ago
  Your information has never been presumed to belong to you, and you have never presumed that information you had about other people did not belong to you. Have you ever kept track of information about other people and felt compelled to notify them and potentially send them money? Like when you were in first grade and wrote down a list of "people i hate" or "who to invite to my birthday party"? Or when you got older and were getting petitions signed? Or maintaining lists of who do deliver to and collect money from on your paper route? It's actually an important freedom to be allowed to learn things about other people and to write them down, and share your thoughts with other people. I'm not saying that I'm happy about the current state of affairs where we are spied on and sold and resold, but I just wanted to clarify that it's not so simple as you make it out to be that each person owns all information about themselves.
  - A4ET8a8uTh0 4y ago
    << Your information has never been presumed to belong to you, and you have never presumed that information you had about other people did not belong to you. Have you ever kept track of information about other people and felt compelled to notify them and potentially send them money? It is an accurate take. The problem starts when the gathering becomes an industrial level process and start charging money for it. I am almost at a point, where I pray for a Target level breach that somehow involves the 3 bureaus. Maybe then other entities start suing one another over fallout. Until then it is just 'swy'.
bmitc 4y ago
> There's a clear lack of ethics from whomever built that, whom either didn't care, or didn't know enough know enough to excuse themselves from building it and ask for assistance. I highly doubt that Experian attracts the best and brightest. And when you have a company that doesn’t provide any features to the consumers whose data they collect, control, and sell except when sued, you get stuff like this.
scarab92 4y ago
Credit Bureaus exist to share your credit file with any paying credit provider who asks for it. They won't regard accessing credit files in this way as a security / privacy issue, but merely a billing issue.
mrinterweb 4y ago
True. If a structural engineer designed a bridge with supports made out of balsa wood and held together with duct tape, they would get in big trouble when the bridge inevitably collapsed, and the engineering company they worked for would be liable. I don't have high hopes that this level of negligence will have anything firmer than a slap on the wrist for Experian.
- charles_f 4y ago
  They're already not even commenting on the breach, and it's not as visible to the GP as the equifax leak a few years ago by the "state-sponsored chinese hackers". So I agree, very likely to result in nothing.

vinceguidry 4y ago

It's nineties-level internet security. Stuff like that was the bread and butter of security researchers of that era.

contingencies 4y ago
Closely related period fail: /receipt/<sequential-receipt-number-here>.pdf = all customers full booking history and personal data for all time.
NovemberWhiskey 4y ago
I mean, sure, but nothing has changed since: "Broken Access Control" is still #1 on the OWASP Top Ten for 2021.

xnorswap 4y ago

It's just a classic IDOR, it's very easy to fall into with some frameworks. If you look, you see it everywhere. When stack-exchange rolled out their CV feature they had a similar thing which leaked everyone's email address regardless of the public profile visibility or whether they had even used the CV feature.

bcrosby95 4y ago
I seem to recall github having this security hole in spades about a decade ago.

suzzer99 4y ago

I'm still struggling to think how this could have happened. I wonder if it has something to do with interaction with annualcreditreport.com? Maybe originally the code had multiple levels of authenticating the user: 1) we know who you are, but you haven't proven it yet, and 2) you've proven it, now you can see everything. But when they integrated with a 3rd party, which could have been a decade or more after the original code was written, some developer who didn't understand the code just lumped everyone who came over from annualcreditreport.com into basket #2, even though that user still had to go through the url flow to prove themselves. Just a guess. I don't think most non-programmers realize how often preventing this kind of thing comes down to one developer making a stink repeatedly to indifferent higher-ups. If that one developer is incompetent or doesn't care, no one else does.

xnorswap 4y ago
I don't know about this case, but a lot of the time this class of vulnerability comes down to lack of Authorisation rather than lack of Authentication. So much effort is put into checking that people are who they say they are (is Person X really Person X) , they forget to check that they're authorised (is Person X actually supposed to be accessing resource Y). Given the URLs don't have the actual resource Identifier, it means the resource ID will have been gathered from somewhere else, typically one of three places: 1. Cookies / Localstorage - Easily manipulated and should never be treated as a secure place, it's easy to put simple values here and forget that they still need to be validated / checked server side, and that just because you have access to /foo/Y you might not also have access to /bar/Y. 2. Session - An ASP favourite, sticking something in a key like Session["FolderID"] you might assume you've validated and checked authorisation when you set the key, then later re-use (deliberately or accidentally) the same key elsewhere leaving it open for manipulation. And then you might assume you don't need to re-check authorisation when you read the key.
- herpderperator 4y ago
  I wouldn't call the "session" concept an ASP favourite - it's the industry standard for any backend web framework to use a user session where the session key is stored as a random cookie value and the actual key-value pairs are stored on the backend somewhere.

8note 4y ago

Credit agencies have no reason to care about their security wrt your data. You aren't their customer, and they don't owe you anything

mancerayder 4y ago

These folks never did a basic penn test ? Unauthenticated access to a different URL seems like a common thing to test for.

acdha 4y ago
That's … optimistic in my experience. I've had reports include breathless disclosures that our application was leaking private information because robots.txt could be accessed without authentication, or that we were disclosing source code (front-end JavaScript). Places which treat security as an audit checkbox are going to try to outsource that work to save money and they're going to get people who have enough skill to run a few basic tools but not to reason about the results or do anything creative. Experian seems highly likely to be on that side since they've been able to avoid any significant penalties for past negligence.

ec109685 4y ago

This is where per-user level encryption of data should be used. If your credit report on that site is encrypted and the keys are only successfully derived by answering your security questions, you've added another layer of security [1]. It also prevents the situation where a hacker gets access to the box doing the security check, and they can read everyone's data versus just those users who are concurrently asking for their reports. Even simpler, this would be prevented if /acr/oow set a decryption key as a cookie after validating the verification data that was then used by /acr/report to decrypt your credit report. [1] Yes, it's possible to enumerate over all user's security answers, so it's not perfect, but it ensures a simple mistake with an if condition, doesn't release everyone's data.

jimhefferon 4y ago

It seems like they owe us all compensatory damages. Big damages. I never really understood how they could take my information, which presumably belongs to me, and then could use it to make millions. How about my cut?

fsckboy 4y ago
Your information has never been presumed to belong to you, and you have never presumed that information you had about other people did not belong to you. Have you ever kept track of information about other people and felt compelled to notify them and potentially send them money? Like when you were in first grade and wrote down a list of "people i hate" or "who to invite to my birthday party"? Or when you got older and were getting petitions signed? Or maintaining lists of who do deliver to and collect money from on your paper route? It's actually an important freedom to be allowed to learn things about other people and to write them down, and share your thoughts with other people. I'm not saying that I'm happy about the current state of affairs where we are spied on and sold and resold, but I just wanted to clarify that it's not so simple as you make it out to be that each person owns all information about themselves.
- A4ET8a8uTh0 4y ago
  << Your information has never been presumed to belong to you, and you have never presumed that information you had about other people did not belong to you. Have you ever kept track of information about other people and felt compelled to notify them and potentially send them money? It is an accurate take. The problem starts when the gathering becomes an industrial level process and start charging money for it. I am almost at a point, where I pray for a Target level breach that somehow involves the 3 bureaus. Maybe then other entities start suing one another over fallout. Until then it is just 'swy'.

bmitc 4y ago

> There's a clear lack of ethics from whomever built that, whom either didn't care, or didn't know enough know enough to excuse themselves from building it and ask for assistance. I highly doubt that Experian attracts the best and brightest. And when you have a company that doesn’t provide any features to the consumers whose data they collect, control, and sell except when sued, you get stuff like this.

scarab92 4y ago

Credit Bureaus exist to share your credit file with any paying credit provider who asks for it. They won't regard accessing credit files in this way as a security / privacy issue, but merely a billing issue.

mrinterweb 4y ago

True. If a structural engineer designed a bridge with supports made out of balsa wood and held together with duct tape, they would get in big trouble when the bridge inevitably collapsed, and the engineering company they worked for would be liable. I don't have high hopes that this level of negligence will have anything firmer than a slap on the wrist for Experian.

charles_f 4y ago
They're already not even commenting on the breach, and it's not as visible to the GP as the equifax leak a few years ago by the "state-sponsored chinese hackers". So I agree, very likely to result in nothing.