Every Louisiana driver's license holder exposed in cyberattack
theguardian.com
theguardian.com
As it is, states and corporations externalize the costs of hacks to the victims of their incompetence. They have no reason to take opsec seriously because they aren't held liable in even the most egrigious cases. Data should be a liability.
This is the crux of it, methinks. "Data is the new oil" has been a common refrain and as long as the externalities of poor security posture hygiene can be completely outsourced while these companies make mountains of cash by monetizing your every scrap of behavior, attention and information, this will only get worse as every entity seeks to hoard more information on you.
Keeping more data than absolutely necessary for critical business operations should be an existential threat for any entity. Those businesses built on this data ought to take Fort Knox level pains to secure it. Anything short of that and we will continue to exist in a society of deteriorating trust and social contract.
The common usage of this phrase isn't too inaccurate. Keep in mind what oil does to the environment, not just during spills but even in normal refining!
When oil spills, it causes toxic damage to the environment. When data spills, it causes damage to society's individuals and the firms that should have kept the data secure.
It's not a perfect analogy, but there are some similarities.
Stripe is a good mental model here, I don't want a person's credit card data, I want to charge them for my product. I love storing a Stripe customer ID, if a hacker were to grab that table, I wouldn't lose (a lot) of sleep, they couldn't do much with it. If that table held credit card data...I would.
That farms out a lot of responsibility to Stripe, but for a side project, I don't have the time necessary to do as good of a job at it relative to Stripe.
I'm really curious how effective these are in practice if someone got logs or backups, but it at least gives people a path to know what data is there remove the active copies
Your bank can give you a bank card with cryptographic keys in it and then you need the card to make a transaction. But then if you lose the card...
At which point we fall back to birth certificates and things because there's nothing else available. The alternative would be that if you lose your bank card, you lose your money. Which could be mitigated by e.g. having backup cards that you keep at home in a safe, but some people would lose those too, and what then?
By analogy, the cryptographic key on the bank card is a cross between a session token and a private key. Like a private key, it is never directly exposed for verification. Like a session token, it can be replaced.
You need to bootstrap it all somehow. All you've done is move the authentication problem to how you get a government id.
Suppose your house burns down and you're standing on your lawn in your pajamas with no identity documents of any kind. What now?
- something you know, like a password - something you have, like an RFID card - something you "are", like a fingerprint
You can add multiple of these and choose from different categories to add security, but each time you do it also gets less convenient. You could require a birth certificate, DNA test, and social security number for any access to a bank account, but then it wouldn't really work as a checking or savings account, and if you lose your birth certificate you're locked out of your account.
Definitely worth considering the other side - when you need to access the account how much inconvenience and delay are you willing to put up with before you can? For a checking account it seems like people usually just want a single one of them - the debit card, account login, or face/fingerprint to authenticate
Especially since the cost of actual security is very high. You have to build it into every aspect of the system. It makes development cost an order of magnitude more and constrains usability... and you'll still never really be certain
When you take employees into account the cost becomes almost insurmountable. Keeping bank style security means tightly limiting access, making even simple operations more work.
That's not an excuse. That's a warning. We are at grave risk, and we need to completely reconsider how almost every piece of software is written. Competence is hard and expensive.
The part of the DMV that performs driver testing isn't the part that loses all your data. It wouldn't be impossible to disband their IT department and give the role to some other government agency.
They could also just, you know, stop collecting it. Print your height and hair color etc. on your driver's license and don't store it anywhere else. Instead store a hash of it at the DMV with the salt stored on the license itself, so you can revalidate the license without being able to reconstitute it.
Disbanding the DMV doesn’t make the cost to any actor infinite (“DMV” is an abstraction, and state agencies are routinely created amd destroyed, sometimes as political damage control due to IT scandals [0], but that’s not an infinite cost on anyone.)
[0] e.g., the California Department of Information Technology in 2002: https://www.google.com/amp/s/www.computerworld.com/article/2...
Mostly, its not; a lot is not outsourced, and a lot that is is outsourced on personal services contracts at rates that even if there was no vendor overhead wouldn’t pay for a top-flight pay and benefits package.
I’d estimate that if this happened, the cost to secure data would grow by about a factor of 3.
Exactly. Mandate financial compensation for any and all value derived from data that an individual creates, whether they opted in or not.
If YC ran banner ads and my comment is viewed on the same page as an ad, then I should receive some significant percentage of that ad revenue. If an ad is targeted to a customer on IG through an ad campaign, based on the user's data, then the user should get a significant percentage of that ad.
That should clear everything up.
I can confidently tell you that your understanding of security mitigations is flawed. And I say that based on experience not just a baseless opinion. Silver bullets in security don't exist.
Let's every moveit instance was run in a container in a vm and in a dmz (actually moveit transfer is usually deployed in a dmz, isolated from everything else). But the entire purpose of the software is to contain all these important files and expose them to authorized parties, basically a file server (even has sftp!). The threat actors in this case didn't even bother compromising the OS, they just got a session id as a result of abusing sqli and .net deserialization flaw and logged into the webui and downloaded the files. At no point could a vm have stopped any of this.
I said your undersranding is flawed because you mindset is solution centric not data centric. If all an attacker cares about is access to your gmail, a qubes VM with strict selinux rules is useless if they get you to click on a link that exploits firefox to steal your gmail cookies, defeating any yubikey 2fa you may have.
Also, Qubes does not trust the hardware emulation [2]. It keeps the trusted computing base as small as possible. Of course, the covert-channel attacks are still possible [3], but they are much weaker and can be mitigated through isolation. Qubes does not implement an ordinary copy-paste functionality; it's implementation is much more secure, see [4,5].
Hardware-virtualized VMs without any devices attached are extremely hard to escape from or access for other VMs. I am not aware of any successful attempts in the last >10 years.
> qubes VM with strict selinux rules is useless if they get you to click on a link that exploits firefox to steal your gmail cookies
This is wrong, because clicking on a link in my email would open a broswer in a dedicated, disposable VM. Also any attachment would also open in a disposable VM.
Having said that, you are probably right that in this case Qubes itself would not help as the whole database had to be available online.
[0] https://www.qubes-os.org/security/xsa/
[1] https://www.qubes-os.org/news/2021/06/08/qsb-069/
[2] https://www.qubes-os.org/faq/#is-the-io-emulation-component-...
[3] https://www.qubes-os.org/doc/data-leaks/
[4] https://www.qubes-os.org/doc/how-to-copy-and-move-files/#sec...
[5] https://www.qubes-os.org/doc/how-to-copy-and-paste-text/#sec...
And again, you miss the whole point of zero-day, it is an unknown. You can create an attacker-hostile environment but you cannot make guarantees or claim a solution is best practice against an unknown/undefined.
As far as I am aware for example, spectre/meltdown or *-hammer attacks could have been used against your disposable vm to read your email vm's memory. There are also hardware attacks against radio controllers/chips that could be used to wirelessly dump memory without your interaction.
You know, I was just telling someone how I thought those scenes in movies where the hacker guy types really fast and hacks everything were silly when I started working in security. Now, I know that if he is just the guy buying/trading exploits and spent a lot of time automating stuff and setting up infra,it is indeed possible to make it all look so easy (but still, some movies/shows take it too far). Especiallu in government work, the guys using the tools are rarely the guys that develop them or maintain their infra. The guys who develop access might also be different from the guys who action objectives or work on exfil or shell management.
Did you ever think that such a good performance that Xen and Qubes have is not a mere coincidence? What if I tell you that it is not just a pure luck? It just can't be luck statistically: in the Linux kernel, serious vulnerabilities are found all the time, whereas here they're extremely rare.
Let me tell you that it is actually a result of a good architecture. You know, in Xen, the trusted computing base, i.e., the code responsible for isolation and security is really small: it's of the order of 100k lines of code. In Linux it's millions of lines. Every code has bugs, it's unavoidable, but you simply can't have a similar number of bugs in 100k lines as in millions of lines. There are no "guarantees" here, just pure statistics.
In addition, Xen is very popular among big companies, so its code is constantly checked for bugs by the best people in the field. And zero-days in it are so expensive that you would not waste one on leaking personal data of people for no reason. Security is not about guarantees, it's about probabilities. And they are very small in Qubes, if you are not a big target. Even if you are, they are smaller than for any other system, thanks to the security-oriented design and reliance on compartmentalization.
Yes, Qubes is vulnerable to Spectre, Meltdown, *-hammer attacks. But it never attempted to protect the user against the hardware it runs on. It is physically impossible. Also, hardware attacks like these are exception, not the rule. And even they usually don't lead to VM escapes.
[1] https://www.alea.gov/dps/driver-license/driver-records-crash...
[2] https://www.caranddriver.com/features/a32035408/dmv-selling-...
Just trying to get context, I also lived in place where SSN are not a big deal because they are not used to prouve anything
And besides, why wouldn’t an unencrypted backup of the entire DMV database for the State or Louisiana be getting tossed around using such a program?
Good grief.
So this hit a wide spectrum of services both public and private.
[1] https://techcrunch.com/2023/06/15/moveit-clop-mass-hacks-ban...
> Progress Software, which develops the MOVEit software, patched the vulnerability — but not before hackers compromised a number of its customers.
And they got promoted and now my private info is public and theyll never see an ounce of accountability.
Good old corporate and governmental America.
They are all peculiar system with weird UX.
To freeze your credit, you first have to produce your ID to companies such as Equifax which have been responsible for many data leaks. So you’re putting yourself at additional risk.
Secondly, anyone with a copy of your ID can just unfreeze your credit. So it’s basically useless.
As far as giving my ID to Equifax; they already have my details whether I give it to them or not.
Also I think freezing also prevents soft credit pulls so automatic credit limit increases won’t be given or add an extra hassle of “unfreezing” to get the increase.
What I do is use those “free” credit monitoring services (ie, credit karma, credit sesame) and monitoring provided by some of my credit cards to get full coverage across all credit bureaus.
If any unrecognized application for credit comes through using my information, then I will immediately get notifications.
Otherwise, I just continue as normal. Request CLIs for my current cards and grow my available credit.
However, in the past month, despite having frozen credit, someone managed to get a BofA checking account opened enough that I got emails about it, and had to spend a ton of time trying to get to the fraud department (I do have BofA credit cards, which I guess I should have gone through to get to fraud). They had already denied it, but sent me emails, I guess because of the existing accounts with that social.
Additionally, my spouse recently got a Square debit card mailed to her, in the (inaccurate) name of a local business. Again, very difficult to get ahold of the fraud department. Of course, someone rented a luxury apartment in her name in Oakland a couple years ago, and Oakland PD still hasn't called back, and literally nobody else cares; the management was responsive, but said they weren't even sure that they could evict, given COVID; I just hope the rooftop espresso bar is nice for the fraudster.
I protect myself per what's legally obligated. For established accounts, that means checking transactions within the regulation E timeframes. For companies that I have no relationship with, that means responding to any notices I actually receive that falsely claim I'm doing business with them or the like. Beyond that, it is not my responsibility to help this terrible financial surveillance industry, which wouldn't even exist if it were up to me.
My understanding of this attack is that the company
1) didn’t have IP access controls to limit machines that can talk to the moveit manager
2) didn’t have SSL client certificates to prevent a machine from connecting without a valid certificate
Now a sql injection really isn’t good, it’s not hard to protect against, both by sanitising inputs and using prepared statements, but that’s why we have defence in depth
Which is what makes it even more annoying when someone decides “oh I can save a few bob by giving our employees private information to the lowest bidder as the cost won’t fall on my departments budget”
* If you are in the US, go to one of the credit bureau sites (Transunion/Experian/Equifax) and sign up for a fraud alert. You'll need to provide your current phone number and what this does is this: no fintech/bank is supposed to create an account or issue credit in your name unless they have verified the activity with this phone number.
* If you have previously been a victim of fraud, sign up on one of the aforementioned bureaus for an Extended Fraud Alert.
* Isolate your email tied to your finance accounts from regular email that you give out on website signups, doctors' offices, etc. Only your bank/brokerage needs to know that this email exists
* If you can afford to, pay to track leakage of this information on the dark web or password sharing forums
* Use a password manager
* Use 2FA on all your accounts and use an authenticator app if possible. It's not ideal but it's better than the SMS/email 2FA
* If your telecom provider supports it, ask them about how you can protect yourself from sim-swapping and porting. Add a PIN to your phone provider account if you can.
I am not the victim, nor a participant in fraud in that situation, the bank is. Maybe they should follow some steps and not give out money to randos that walk in and ask for it?
Going to a branch physically is impractical these days - how many of us have even been to a branch that houses our brokerage or 401k accounts for instance? And so many mainstream Fintech apps like Stripe and Robinhood don't even have branches.
2. If they are stupid enough to lend/send money to random people over the phone, that's their problem.
3. If they don't have enough branches open to support in-person services, which forces them to turn to over-the-phone work, that's their problem.
There's many other things they could do. Snail-mail identity confirmation, partnering with FedEx or another bank whomever to attest identity, etc, etc. It's not my problem if they are too cheap to operate branches, and too lazy to do any of those things, just like it's not my problem if you keep a chest of gold coins in your unlocked shed, and then go on to tell everyone about it!
And yet, it's totally your problem.
All of our opinions on whose problem it should be, are worth nothing.
But you already knew the answer.
https://www.vice.com/en/article/43kxzq/dmvs-selling-data-pri...
Should we just default freeze our credit? Is it time to finally get some ID monitoring service w/ insurance?
You'll have to get involved in policy, period.
My company just cries “it’s not our fault” when it clearly is. The larger problem here is that this bit of unchangale data can be used not just to open lines of credit but do things like take student loans out.
Those loans are then automatically deducted from your salary and they won’t stop doing that even after you flag it. a private company can steal money from you after they cock up.
Monitoring + insurance? We did the freeze, but is that sufficient enough?
Seems like I'm gonna have to get some kind of insurance + monitoring in case something goes really south, no?
I guess I can try to avoid doing business with companies who insist on using these "secrets". Sometimes I don't have a choice, though.
It would be wonderful to have ubiquitous PKI for every citizen in the United States. I don't trust private companies to do it. A large segment of the electorate would never trust the government to do it. (I like the idea of the USPS leveraging their tremendous physical presence and delivery infrastructure to do it, personally, but I think that would meet about the same level of opposition as the government doing it.)
I guess we'll just continue with this ridiculous charade of "secret" numbers, the silly idea of "identity theft", and most of the consequences applying to the individual.
That'll fix it real fast.
The entire premise of "identity theft" is backwards. No one stole my identity, no they committed fraud against the bank.
In any other context fraud costs are born by the victim of the fraud, i.e it should be the bank. Only in "identity theft" do we allow a 3rd party of the fraud to be liable for the damages.
I am not sure how that even happened
But the bank, the fraudster, and/or the credit burro should be liable, not the unsuspecting innocent.
MoveIT Automation / Transfer are used throughout many sensitive industries, such as banking.
I believe the "identification by digital photograph" that is being rolled out at US airports (no longer need to show ID at some security checkpoints) is based on photographs shared by state-level driver's license/id card.
Increased roll-out of facial recognition technology probably increases the value of stealing headshots associated with other identity information.
I believe federal "RealID" requires states to maintain a database of digital photographs from identification documents. I think almost all states do that now.
After that it’s a combination of your phone/watch plus your photo.
It’s not perfect, but it’s more than just comparing your photo to your drivers license photo.
Edit: looks like there may be a second program that does just what you say: https://www.tsa.gov/biometrics-technology/evaluating-facial-...
This is the program that I am aware of: https://support.apple.com/en-us/HT213329
Probably that second link you found.
Edit: no really, enjoy it. Apologies for the AMP link but you know, gotta find something quick for those conservatives here unable to accept the reality they've welcomed. https://www.google.com/amp/s/arstechnica.com/tech-policy/202...
It's already in effect for multiple states. Downvotes alleviate the cognitive dissonance. Go go go !!
Edit - I was wrong and that happened in 2021 by the same group.
There was not date and given it was the same group, I made a bad assumption.
Showing ID for TSA is voluntary, like their full body scans. I can file court cases without ID. I can quit claim (transfer) land without ID.
My State use to use your SSN for its License ID, but they changed moved away from that over 20 years ago. Glad they did. BTW, as noted Oregon too, I am sure there are others.
Glad we are all on Real ID, that sure helped out the Russians a lot. But Real ID did nothing useful for me.
edit: spelling