I despise the existence of the credit reporting bureaus and would love to see one of them caught with their pants down for a breach that was entirely preventable (well, at least through the vector that was used). If they failed to patch a known vulnerability, and that caused the breach, likely they'll be on the hook for a larger payout once settlement time comes.
This is exactly what I meant. These companies compile large amounts of personal financial data without peoples consent. They use SSNs for non-tac purposes, which I think is/was illegal. This ultimate cause of the breach has nothing to do with the exploit used, but rather the fact that this company and its practices exist at all. They put peoples info on a computer connected to the internet for no reason other than efficiency - profit.
If it was not a zero-day, it means the attack was preventable, which points away from a world where a hundred million people's private information is unavoidably vulnerable.
In either case, it's a very small amount of evidence anyway, but in that respect at least, hoping it wasn't a zero-day makes sense.
If it was not a zero-day, it means the attack was preventable, which points away from a world where a hundred million people's private information is unavoidably vulnerable.
Working in the security industry quickly cures you of this illusion. It is unavoidably vulnerable in most cases. If someone wants to pop your network, they can usually find a way. The most clever code won't prevent someone from strolling in and plugging a raspi onto your network. Nobody notices an inconspicuous black box amid a pile of cables.
Let's not confuse physical access to getting it over the internet.
If they stayed old-school and had their computers inaccessible except to their own people, you'd have to make phone calls, fax, and mail to do anything with them. That would be less efficient - more costly - but it would prevent the possibility of a remote attack compromising huge amounts of data.
If we move up in abstraction, if these companies didn't exist and collect all the data the danger would be completely eliminated. OTOH the banks and lenders who use their services would have to find other ways to estimate credit-worthiness and that would again... cost more.
The network isn't necessarily the target. Developer machines are prime candidates for pivots. Most devs don't bother installing security updates, and many laptops are badly configured or running tools like Jenkins which in certain cases gets you remote code access. Equally promising is to set up a honeypot wifi AP and then wait for someone to accidentally connect to it.
Most devs have creds littered throughout their system. Some subset of the creds will get me access to your network. If you let me rifle through your box for a few hours I'd likely find a way to pivot somewhere else.
Yeah, I know and I agree. That's where the "very small amount of evidence" comes into play. A slightly better point is how this acts as evidence for how unavoidably vulnerable we are.
Unfortunately ~nobody does. The effectiveness of red teams was one of the most surprising aspects of working in security. The most common way to break into someplace was to pose as a construction worker: http://i.imgur.com/ZjnGmZ5.png
If you're dressed as one of them, you can go wherever you want and people rarely ask questions. Another approach is to pose as an interviewee. That's how you get into the building, but beyond that you never actually talk to anyone so nobody is suspicious. People generally don't care when someone is walking around the halls dressed up in a suit.
One of my coworkers was involved in dozens of red teams and he got caught a grand total of one time. Every other time he was able to acquire an IP address, take a picture of himself sitting in the exec's chair, swipe a file out of the server room, or whatever the customer wanted.
>If you meet a member of that select club, "The Twelve True Fishermen," entering the Vernon Hotel for the annual club dinner, you will observe, as he takes off his overcoat, that his evening coat is green and not black. If (supposing that you have the star-defying audacity to address such a being) you ask him why, he will probably answer that he does it to avoid being mistaken for a waiter. You will then retire crushed. But you will leave behind you a mystery as yet unsolved and a tale worth telling. ...
So, every time, he took a pic in the exec's chair, stole a file from the server room, and also did whatever he wanted? What is the 'N' factor here, because it sounds like your friend is a bold high schooler who achieved N=1,2,3(tops). Pretty boring security stuff.
To clarify, the companies he penetrated were the ones that hired him in the first place. Red teaming is when a company hires you to perform physical pentesting. You're legally allowed to break into their company within a set of defined rules. Usually the rules are straightforward: no breaking stuff (though sometimes there are exceptions), achieve the objective, carry a "get out of jail" envelope with two emergency contacts from inside the target company who will verify they paid you to break in if anything goes wrong. Other than that, you're free to be as creative as you want in achieving whatever the customer asked for. Think Ocean's Eleven.
These gigs are highly paid and secretive. The coworker I mentioned went on dozens of assignments like this. Admittedly he was legendary, but only because he was so experienced. If you were motivated and malicious, you could do many of the same things to attack a target network. People rarely do that, but it's the ultimate proof that none of us are secure against motivated adversaries.
I mean GP that you're replying to literally said N~=dozens, meaning probably 25+
Side note, that sounds like something one of my old bosses would do on his red team excursions (he also told me to get my teeth pulled without anesthetics at all, so... yea).
The fact that the pii existed is more systemic. We use social security numbers to verify identity and have a unique way of identify people across systems. If our current system of doing this (i.e. SSNs) are no longer reliable we will have to come up with something to replace it. If what we use to replace it is as brittle of a solution we will run into a similar problem down the road.
well ya thats the point, credit card breaches may still happen but those are easy to cancel, but all the PII would be permanently in the public domain.
No, they'll still be at fault because if you have a massive pile of highly sensitive data online, and all it takes is one vulnerability to get at it all, then your security model was awful.
Was this database typically accessed with broad-sweeping queries that could snarf large amounts of it at once, or was it the sort of thing where a few specific keys were used to identify a single client record? My thinking is that it was probably the latter, and if that's the case then another layer of security should have been in place there. Stored procedures can be used to require very specific queries to access very specific records--this falls under the "prevention" category. Next, monitors should be deployed so that someone gets notified right away if some session makes a large number of successive queries to get around the restriction--this goes under the heading of "detection". These two things would have been able to prevent attackers getting the goods with just one exploit.
...yet companies regularly fail to take these kinds of simple and rational steps seriously, and then act like it was all just too hard for anyone to possibly defend against.
They should be liable for poor storage practices around sensitive PII. Take for example SSN. With SHA2, there is no good reason for them to be stored in plaintext.
If you don't need it, don't store it. For SSN, you just need a function (SHA256+Salt) that would give you a one way mechanism of Creating an identifier that masks the original in an irreversible way.
The prevalence and misuse of SSN as an identifier for people is so out of date at this point and weak. We need something different.
There's no evidence so far (that I've seen) that points to Equifax storing SSNs in plaintext. The initial reports so far indicate that the exploit scraped the SSNs while it was in use by other systems, and not at rest in a database. Encryption (whether they do it or not) wouldn't have saved the day here.
> The prevalence and misuse of SSN as an identifier for people is so out of date at this point and weak. We need something different.
If you're just hashing with SHA2 and a salt, an attacker with a run-of-the-mill GPU could crack any given hashing quite quickly. It might still take quite a bit of time to get all 143 million, but that's fine. Sell off the score in blocks of 10,000 and let the customer know they have to reverse the hashes themselves.
I find their behaviour overall rather abhorrent and against people in general. Justice should be served, but I hope it goes very poorly for them. Sorta like one might hope something bad happens to Oracle.
