Apache Struts Statement on Equifax Security Breach
Regarding the assertion that especially CVE-2017-9805 is a nine year old security flaw, one has to understand that there is a huge difference between detecting a flaw after nine years and knowing about a flaw for several years. If the latter was the case, the team would have had a hard time to provide a good answer why they did not fix this earlier. But this was actually not the case here --we were notified just recently on how a certain piece of code can be misused, and we fixed this ASAP. What we saw here is common software engineering business --people write code for achieving a desired function, but may not be aware of undesired side-effects. Once this awareness is reached, we as well as hopefully all other library and framework maintainers put high efforts into removing the side-effects as soon as possible. It's probably fair to say that we met this goal pretty well in case of CVE-2017-9805."
Posted Sep 10, 2017 17:59 UTC (Sun)
by ledow (guest, #11753)
[Link] (26 responses)
It pretty much doesn't matter what it was written in, how it was deployed, whether it was up to date. Obviously there was no separation of services, or controls to monitor unusual activity.
Posted Sep 11, 2017 15:12 UTC (Mon)
by drag (guest, #31333)
[Link] (8 responses)
Modern datacenters are extraordinarily complex systems. They are always going to be vulnerabilities. There are always going to be bad procedures, logs that are missed, applications that are wrong, systems that are in bad health, operators that are asleep or distracted, hard drives failing, etc etc. That's the nature of any complex system.
Once it rises above a certain amount of size and complexity then failures are the norm, not the exception.
In the case of credit cards information... if it's stored and made available to user accounts on the front-end and for billpay or whatever you need that information for.. then it doesn't matter how far and how deep you bury the storage. You could have a hundred networks, a thousand servers, a million firewalls and yet there is going to be a path from external systems to that credit card information. Without such a path it couldn't possibly work.
The only way to come close to 100% secure that sort of information is to never store that information in the first place and even then it's possible to leak numbers out into the wild.
So what happenned here, more then likely (I haven't looked at this particular case closely) is a cascade of failures. If the apache strut problem never existed then maybe the criminals would of just found a different way to exploit all the other failures that existed.
Posted Sep 11, 2017 18:07 UTC (Mon)
by Nelson (subscriber, #21712)
[Link] (6 responses)
A 100% complete and totally catastrophic failure is kind of difficult too though. You have to be pretty bad at things to have a complete failure like this. Being that their core business is selling queries to their databases, you'd think that just to bill correctly they'd have systems in place that would make it obvious when an unusual amount of traffic was being generated or something like that. There are lots of other questions too, they accept credit cards for payment to their various services, they should supposedly be PCI compliant and have undergone some routine audits; those and the exceptions they may have applied for would be very interesting details. I'd expect all these things to be completely separate concerns in a well architected business and this type of failure would require an APT that exploited numerous internal systems over a long period of time, pinning it on struts would be sort of a joke with that kind of situation.
Funny story about equifax. I have paid for their credit monitoring and fraud protection service for about 12 years (just canceled it over the weekend..) FWIW, the family plan pricing was pretty affordable compared to a lot of the alternatives. About 5 years ago it saved my bacon, a car dealership (I'm very certain of it) leaked my information and in a 3 day period 4 new credit accounts were opened in my name and there were 7-10 credit checks run on me. EFX notified me and I was able to shut it down quickly. It's ironic, I was thinking of ending the service but that happened. It cost me nothing but some stress as it was a Sunday and I had to make a dozen or so phone calls; so some stress and 2 hours on the phone. The next month, I got another alert from them, my credit rating dropped, I want to say about 13 points in Equifax' score but it was still in the great category, it was an inconsequential drop but it sounded and felt big and I watch the stuff like a hawk. I remember working very hard to get above 800 and it took a long time for those last few points. I called EFX up to inquire, I hadn't done anything but shut down some frauds that I reported to them, I was worried something else was going on. They told me that there were too many credit checks done on me and that can lower your credit score, I insisted that that didn't happen but they pointed to the 7-10 credit checks that were done fraudulently and I had reported to them. I won't bore you with the details but they wouldn't fix their own score even though I reported the fraud, they told me the score will naturally recover in time, that's the best they could do. That's the kind of business they are. Again, that goes back to my point about them being able to actually audit the queries to their database and bill correctly for them, cause it potentially hurts consumers with their own algorithms; likewise if they give their entire database to partners for some business reasons, then there are potentially queries that aren't factored in and maybe they should be.
Posted Sep 11, 2017 19:50 UTC (Mon)
by drag (guest, #31333)
[Link] (5 responses)
Everybody is this bad at this.
Organizations, unless checked by some external force, will have a tendency to grow continuously in complexity and size up until the point where the bureaucracy is reaches a sort of plateau of critical maximum inefficiency. The critical maximum inefficiency is where people have spent so much time dealing with the bureaucracy that they really don't have any time to do anything else... including making the bureaucracy more complicated. PCI compliance and audits and such things are just a example of bureaucratic road blocks to help manage risk. This is natural, often desirable, and are unavoidable in large organizations. But they are not silver bullets.
Posted Sep 11, 2017 20:10 UTC (Mon)
by jebba (guest, #4439)
[Link] (2 responses)
To find out if you were compromised by Equifax, a PR company set up a Wordpress website with shared SSL certificates, and javascript pulled from multiple outside servers. This is just asking for it.
Posted Sep 11, 2017 20:38 UTC (Mon)
by ssmith32 (subscriber, #72404)
[Link] (1 responses)
Posted Sep 11, 2017 21:05 UTC (Mon)
by jebba (guest, #4439)
[Link]
Posted Sep 11, 2017 21:48 UTC (Mon)
by Nelson (subscriber, #21712)
[Link] (1 responses)
I'm not suggesting that PCI compliance is a silver bullet here, I'm simply asking if they were compliant or what exceptions they had. They would have had to undergo a third party audit, Verizon or somebody gave them a stamp of approval.. I think this sort of event might be the external force that checks these guys. Get those names out there, get the details out there.
Posted Sep 12, 2017 3:06 UTC (Tue)
by drag (guest, #31333)
[Link]
> I'm simply asking if they were compliant or what exceptions they had.
From my experience working in the financial system.. If there is a regulation or industry standard this company would comply with it. That's just par for the course. Not even a question. They are a core part of how the financial industry in the USA functions on a fundamental level.
When you get to this level the difference between who does the regulation and who is the regulated starts to get very blurry. I don't know the details ,but I entirely expect that Equifax is going to have very close relationship with the major banks in the USA, which are the ones that are responsible for defining and enforcing PCI standards since they are the people that own the credit card companies.
Posted Sep 11, 2017 20:43 UTC (Mon)
by ssmith32 (subscriber, #72404)
[Link]
So, yes, it looks like there may have been some really dumb mistakes made.
Posted Sep 11, 2017 16:14 UTC (Mon)
by tialaramex (subscriber, #21167)
[Link] (16 responses)
One reason to think this way is that just because the CRAs have industrialised the collection of this data doesn't mean nobody else can get it with a bit of work. You can be a victim of one particular criminal who has targeted you even if you're not one of millions whose data is lost in bulk. So we should fix the actual problem rather than wring our hands every time there's another breach.
Posted Sep 11, 2017 20:03 UTC (Mon)
by rahvin (guest, #16953)
[Link] (2 responses)
Posted Sep 13, 2017 16:24 UTC (Wed)
by ScottMinster (subscriber, #67541)
[Link] (1 responses)
Posted Sep 17, 2017 12:50 UTC (Sun)
by mathstuf (subscriber, #69389)
[Link]
Posted Sep 11, 2017 20:49 UTC (Mon)
by ssmith32 (subscriber, #72404)
[Link] (12 responses)
Even a government-mandated biometric database is just a collection of plain facts about you. But once someone has those facts they can impersonate you. Game over.
Any other neat ideas for identification that I don't know about? I haven't really kept up like I should...
Posted Sep 11, 2017 22:12 UTC (Mon)
by dskoll (subscriber, #1630)
[Link] (2 responses)
Credit agencies should be required to keep at least one phone number and one email address in your record. If someone wants to do a credit check on you, they should be required to email, text or call you to let you know (1) who is doing the check, (2) what the purpose of the check is and (3) a random PIN that's good for 24 hours.
If you consent to the check, you phone a number or go to a web site, enter the PIN, and the check goes through. If not, you phone the number or go to the web site, indicate that you don't want the check to go through, and it doesn't.
Can that be hacked? Undoubtedly. But it would raise the difficulty substantially. It would also make it much slower for credit agencies to sell credit checks about you, which is why it'll never happen, even though Google, Yahoo, etc. have used similar schemes for much lower stakes for years.
Posted Sep 13, 2017 1:50 UTC (Wed)
by ssmith32 (subscriber, #72404)
[Link]
B) Coz most ppl's email is secure? What?
Posted Sep 13, 2017 1:58 UTC (Wed)
by ssmith32 (subscriber, #72404)
[Link]
Phone + pin = credit freeze, which is already available today.
As for how you deliver a random pin daily, at scale, securely (and that means no UX muck ups) to lower income people most dependent on good credit... I have no idea.
The biggest problem is all these ideas are hardest on people who depend on credit the most. E.g. couldn't make your phone payment? Congrats, your fsck!
Posted Sep 12, 2017 8:07 UTC (Tue)
by tialaramex (subscriber, #21167)
[Link] (8 responses)
Here's how silly this is: If you build a crappy PHP application and "secure" it using a plain password field in your MySQL database with the user's chosen password in it, other PHP developers will know to ridicule you for this design because when inevitably the database gets stolen you lost all the passwords. They all read not to do that and "know better". But if you build a bank, and "secure" it using records of when each customer applied for an account, how much their mortgage payments are each month and what they get paid, industry experts will nod their heads sagely at your brilliant use of data to protect your business.
Bad guys stealing data on this scale don't care about "you". This is a numbers game. Use some stolen records to fill out a thousand loan applications for $5000 each, fifty get approved, ten send the "loan" money abroad to be cashed before the accounts are closed as fraudulent, you now have $50 000 for the trouble of pasting data from one document into another. They're relying on the fact that all the "security" consists of just comparing what was filled in on a form in one place with what's kept in a database in another place. There hasn't been any need to do this for _decades_ but it's what the financial industry is used to, and nobody shows any signs of telling them to knock it off.
Posted Sep 12, 2017 23:45 UTC (Tue)
by ssmith32 (subscriber, #72404)
[Link] (7 responses)
I believe the kernel team does it by having "key parties" where people show up with... wait for it... driver's license and/or passports.
Exactly those things that are the "plain facts" you reject.
Posted Sep 13, 2017 14:26 UTC (Wed)
by nybble41 (subscriber, #55106)
[Link] (6 responses)
In this case you don't need secure key distribution. You aren't actually trying to associate a particular public key with a real-world identity. You just need to show that the person applying for this loan is the same person who has a history of on-time payments on previous loans, utility bills, etc. The key itself is all the identity you need. When you first start out you just generate a fresh key and are treated as someone with no prior credit history; perhaps others with established credit who trust you (or institutions which know your real-life identity and are willing to back you) co-sign your key to give you a head start. Over time you build up a history of payments associated with your key. When you need a loan you sign the application with your private key to prove to the lender that the person submitting the application has an established credit history.
Posted Sep 13, 2017 15:03 UTC (Wed)
by farnz (subscriber, #17727)
[Link] (5 responses)
The problem with the model you outline is that some people have a bad credit history - the "baseline" of no history is higher than the credit record associated with someone who's taken loans and refused to repay. Without this, you have a bootstrapping issue for people who are credit-worthy but who have no history yet (e.g. homosexuals who've run away from a bigoted home situation) - how do I get credit to prove that I'm trustworthy when no-one will vouch for me because the people who could refuse to do so until I acknowledge that I was "wrong" to be gay?
Thus, you also need some mechanism to either prevent people from creating new identities to defraud the banks with, or some mechanism to demonstrate to a high standard that I've never had credit before - otherwise, the baseline inevitably reduces to "not credit worthy".
And, FWIW, the introduction standard is how credit worked in the dim and distant past - one effect was to limit credit to people from "good" families, as you needed an introduction from someone credit-worthy to yourself be eligible to get credit, and you needed to have credit to become credit-worthy.
Posted Sep 13, 2017 18:27 UTC (Wed)
by raven667 (subscriber, #5198)
[Link]
In that time if your reputation was questioned in any way this was death sentence as you cannot operate a business like a farm/plantation without credit, leading to the rise of duels as a way to settle questions of reputation.
Posted Sep 13, 2017 19:08 UTC (Wed)
by nybble41 (subscriber, #55106)
[Link] (3 responses)
This is a flaw in the current system. You can't presume the ability to identify all bad actors; it's too easy to change one's identity and start over. Someone with no known history _could_ have failed to repay prior debts under another name. The only sane default is to trust no one, and extend significant credit only when there is someone with an established credit history at stake.
I addressed your concerns about the "introduction standard" already, in the form of "institutions which know your real-life identity and are willing to back you". To qualify for a significant loan with no prior history you'll need to find someone willing to cosign, or at least stake their own credit score on your good behavior. That may be someone you know personally, but it could also be a business offering "loan insurance" for a minor fee following a more traditional background check. Alternately, you can start with small amounts of credit, such as utility payments. The utility company already knows where you live and takes on little risk by extending a month's worth of services on credit, making this a simple (and already commonplace) way to bootstrap your credit history.
Posted Sep 14, 2017 16:34 UTC (Thu)
by farnz (subscriber, #17727)
[Link] (2 responses)
But the same flaw exists in your system, and is made worse by the requirement to cope with people having lots of legitimate IDs. At least in the current system, it's a criminal offence (not just civil) to create a second ID for the purpose of fraud; in your system, multiple IDs are expected, as I can legally create a new ID at the drop of a hat.
And no, you didn't address my concerns - you completely ignored them. I asked how someone with no prior history (so no institutions that are willing to back you, albeit they know your real-life identity) would get on the credit ladder; your description of "loan insurance" is basically how the current system works. Utilities are no use to someone who's on the bottom of the ladder - they generally don't have utility bills, as those are taken care of as part of their rent on a room in someone else's property; they do pay towards utilities, but they pay a roommate, not a utility firm.
At least in the current system, these people show up as a previously unknown borrower - no added risk from failed credit, but no evidence of good risk either; in your system, such a person ends up in the same pool as people who've refused to pay their debts, making it even harder for someone in a bad situation to get minimal credit to establish their credit-worthiness. Unless, of course, I add in the current system, but described as "loan insurance" and "guarantors" instead...
Ultimately, you're not fixing the issues with the current system, you're just adding a new system on top that adds more issues but doesn't fix the core issues in the current system.
Posted Sep 14, 2017 17:38 UTC (Thu)
by nybble41 (subscriber, #55106)
[Link] (1 responses)
Non sequitur. A lack of history does not imply that no institution would be willing to back you. It implies that you are higher-risk, but that risk is easily manageable.
> Utilities are no use to someone who's on the bottom of the ladder - they generally don't have utility bills, as those are taken care of as part of their rent on a room in someone else's property...
For this purpose rent would count as a utility. Anything you have to make regular payments on would serve to establish history.
> At least in the current system, these people show up as a previously unknown borrower - no added risk from failed credit, but no evidence of good risk either...
Which is an error. An unknown borrower should be considered maximum risk, on par with someone who has refused to pay. You know nothing about them, including whether they care about their credit score. As far as you know they have nothing at stake.
Anyway, there are any number of ways to handle the bootstrapping issue and this is getting quite far off-topic. The original point was simply that public key cryptography can be used to establish identity far more securely than the current system of asking you for slightly obscure—but not truly private—information about yourself, such as previous addresses and your Social Security number. If you want a system linked to real-world identity that's not so difficult to do; just have some authority figure endorse the key after running a thorough background check to verify that you are who you say you are. Doing that in one place, once per person, would certainly be an improvement over every lender verifying your identity separately using their own insecure, ad-hoc procedures based on knowledge just about anyone could collect with a bit of effort.
Posted Sep 14, 2017 18:03 UTC (Thu)
by farnz (subscriber, #17727)
[Link]
Note that a lack of history in your system is not distinguishable from bad history - it could be that I have no history, or it could be that I've run away from debts and created a new key. There's no way to distinguish the two situations.
And if rent counts, then what stops me lying and reporting that my kids pay me $10,000 per month in rent reliably? In general, if arbitrary private actors can report, what stops me falsely claiming "good" behaviour for friends - bearing in mind that I can establish new identities as quickly as you can blacklist them? If you whitelist, how do I as head tenant on a flatshare get on the whitelist?
And no, an unknown borrower is not maximum risk - there are legal penalties for trying to disguise your identity to get money, which mean that unknown is lower risk than known bad, since known bad puts you at risk of having to sue, while unknown but with history of not paying lets you get the police forces involved. This is, however, only possible because you are only permitted to have a single identity - as soon as you're allowed to create multiple identities, the system breaks down.
Posted Sep 10, 2017 21:36 UTC (Sun)
by jebba (guest, #4439)
[Link] (2 responses)
Freeze your credit reports. Here is a great overview:
* https://krebsonsecurity.com/2015/06/how-i-learned-to-stop...
* http://krebsonsecurity.com/2015/11/report-everyone-should...
Direct links to freeze pages:
* Equifax --- https://www.freeze.equifax.com/Freeze/jsp/SFF_PersonalIDI...
* Transunion --- https://freeze.transunion.com/sf/securityFreeze/landingPa...
* Innovis --- https://www.innovis.com/securityFreeze/index
* Experian --- https://www.experian.com/freeze/center.html
These people sell your historical info for other slimy junk:
* Chexsystems --- https://www.chexsystems.com/web/chexsystems/consumerdebit...
You can opt out of yet other junk from Experian, Equifax, Innovis, and Transunion here (this is different from credit freeze):
* https://www.optoutprescreen.com
You can get a free annual credit report from this Congress-mandated site:
Posted Sep 11, 2017 22:05 UTC (Mon)
by pss (subscriber, #39291)
[Link]
Posted Sep 13, 2017 2:02 UTC (Wed)
by ssmith32 (subscriber, #72404)
[Link]
Although I did check the TLS certs on a few links (they looked good - just sayin' best practices for all the other lazy people like me clicking on links on bulletin boards..)
Posted Sep 11, 2017 13:07 UTC (Mon)
by mattdm (subscriber, #18)
[Link] (6 responses)
Posted Sep 11, 2017 13:39 UTC (Mon)
by pboddie (guest, #50784)
[Link]
Given that other technologies stole Java's thunder in many regards, and that things like Maven didn't come along (or not with any force) until later, and that inertia would prevent the introduction of update strategies in environments where things like Struts have been used, I wouldn't want to think about how many applications there are that are vulnerable. It also doesn't help that things like Tomcat and Jetty are regulars on the vulnerability calendar, either.
Posted Sep 11, 2017 13:59 UTC (Mon)
by SEJeff (guest, #51588)
[Link] (3 responses)
Posted Sep 11, 2017 17:11 UTC (Mon)
by ssl (guest, #98177)
[Link] (2 responses)
aren't the current-hip microservices resembling them?
Is that the circle of life?
Posted Sep 14, 2017 5:56 UTC (Thu)
by nhippi (subscriber, #34640)
[Link] (1 responses)
All of this has happened before, and all of this will happen again..
Posted Sep 15, 2017 2:19 UTC (Fri)
by zlynx (guest, #2285)
[Link]
Posted Sep 12, 2017 16:32 UTC (Tue)
by dankohn (guest, #6006)
[Link]
Posted Sep 12, 2017 15:28 UTC (Tue)
by david.a.wheeler (subscriber, #72896)
[Link]
Apache Struts Statement on Equifax Security Breach
Apache Struts Statement on Equifax Security Breach
100% secure is very difficult.
Apache Struts Statement on Equifax Security Breach
Apache Struts Statement on Equifax Security Breach
Apache Struts Statement on Equifax Security Breach
Apache Struts Statement on Equifax Security Breach
Apache Struts Statement on Equifax Security Breach
Not everybody is bad at this stuff, that's just not true. Who else is this bad at it? HBO and Sony are the only examples that come to my mind and they didn't lose my private data. There is another analogue: how many times has Amazon or Walmart shipped something that they sell that wasn't actually bought on their website? Don't forget that they sell access to this data, that's how they make money. There very business model requires auditing access to it, they need to have those kinds of systems in place just to do what they say they do.
Apache Struts Statement on Equifax Security Breach
Apache Struts Statement on Equifax Security Breach
Apache Struts Statement on Equifax Security Breach
1) each service should only manage a slice of the data; ssn, DL, address, etc. All information is merged on the front end, not in a single service.
2) per connection/per user/per session quotas. It should not be possible to request more than X records, even in the slice of the data that the service manages.
Apache Struts Statement on Equifax Security Breach
Apache Struts Statement on Equifax Security Breach
Apache Struts Statement on Equifax Security Breach
Apache Struts Statement on Equifax Security Breach
Apache Struts Statement on Equifax Security Breach
Apache Struts Statement on Equifax Security Breach
Apache Struts Statement on Equifax Security Breach
Apache Struts Statement on Equifax Security Breach
Apache Struts Statement on Equifax Security Breach
Apache Struts Statement on Equifax Security Breach
Apache Struts Statement on Equifax Security Breach
Apache Struts Statement on Equifax Security Breach
Apache Struts Statement on Equifax Security Breach
Apache Struts Statement on Equifax Security Breach
Apache Struts Statement on Equifax Security Breach
Apache Struts Statement on Equifax Security Breach
Apache Struts Statement on Equifax Security Breach
Apache Struts Statement on Equifax Security Breach
Apache Struts Statement on Equifax Security Breach
Apache Struts Statement on Equifax Security Breach
Apache Struts Statement on Equifax Security Breach
Apache Struts Statement on Equifax Security Breach
Apache Struts Statement on Equifax Security Breach
Apache Struts Statement on Equifax Security Breach
Apache Struts Statement on Equifax Security Breach
Apache Struts Statement on Equifax Security Breach
Apache Struts Statement on Equifax Security Breach
This is such a good summary of "good things to do to prepare for unintentional vulnerabilities" that I added it to slide set 8 of my slides on developing secure software.
Apache Struts Statement - good summary about things to do for security