If a "leading Insurance Broker across India" can't afford to hire competent developers the least they can do is throw a couple bucks at someone who took the time to identify the multiple severe problems that jeopardized their customers and who notified them responsibly.
The fact that they didn't and still haven't reset the password of the compromised email account blows my mind. Why would I ever trust a company that acts like this to do anything right? It seems like Toyota Tsusho Insurance Broker India should be avoided like the plague.
"Please stop sending me these confusing emails. I have important work to do."
The only way to fix this is a "changing of the guard" at the organizational level. The IT boss, and everything he has ever touched, has to go.
Sounds like exactly the kind of someone you wouldn't want to have to trust with your personal information let alone trust to manage your life/property/business/liability insurance.
which likely led to this issue in the first place
Great post!
To be fair, this usually doesn't start as a boggling level of disdain. It usually starts out as 100% ignorance. It's how the people and the group respond to the negative feedback from experts and from reality, which brings in the disdain, even spiraling to boggling levels.
There are two deep lessons herein, rooted in game theory.
EDIT: In this case, op did everything right!
However, there's a problem when the severe danger is disguised by layers of abstraction and complexity and obscured by time. Even emotionally neutral warnings will trigger our psychological attack defenses in these cases.
Note, I'm not saying op did anything wrong. What I am saying, is that delivering negative feedback about anything complex is itself a complex operation!
A security membrane which needs this kind of feedback to work correctly should be viewed as having a serious design flaw.
“There is no key.”
Bug bounties (and proper education + screening processes for developers) are the most effective way for businesses to prevent security breaches - relying on legal recourse is more of a “shutting the stable door after the horse has bolted” sort of approach.
Not debatable at all - if you get mugged, it’s the criminals fault.
But if you trust your money to a bank, they leave the safe unlocked, and your money is gone, it’s their fault. That literally the whole point of a bank.
Same with your data - when it stolen, it usually the company’s fault - after all if there is no security, sooner or later it will happen.
A "site" that's a static webpage? Sure.
A full application that just happens to use HTTP as one of its interfaces? More difficult than you'd think.
- Most management has a non-tech background. So they get what they want to hear and don’t want to hear what’s wrong.
- Thinking this coming from the same team or from the same company is wrong. They silo developers like crazy. There likely was an API developer, an Office 365 developer, frontend developer (so specific it is down to the framework or stack!) and the developers themselves will not touch anything they aren’t “certified “ in.
- I have been in meetings on $100 million projects where they will seriously argue over the cost of sendgrid. Eventually this will come down to no one having “sendgrid experience” And some developer saying they can do it in Office365.
- Security team will get the first cut in budget since it should “already be secure.”
- You are likely talking over the head of the nephew hired to do security for this. Will the government or anyone sue them? No, so why is this guy bugging us.
Developers aren’t encouraged to develop but get tickets out and not question them. The manga is “It wasn’t in the requirements” all the way down the chain.
I work with smart developers out of India but it is not a culture of innovation. This kind of work is treated like a call center. Don’t go off script, stick your little problem domain, if we aren’t failing we are winning.
Reading this in your comment was physically painful.
This is what you get, ladies and gentlemen, without unions and labour right.
Coming soon, to us too.
Are you speaking of the EU? The US has at-will employment and most software developers are not unionized.
To a T.
I managed to get my application removed, but the vulnerability existed for several years until they updated to a new system. The new system also appeared to have some vulnerabilities, but I never invested time to figure it out. I just did not do business with that dealer ever again, and I'm super wary about car dealerships and finance applications these days...I usually get my financing from elsewhere even if it means a bit higher of a payment...thankfully my vehicle is paid off.
But how on earth did anyone approve storing confidential customer documents in an email account? This seems to indicate there's nobody in charge that understands anything about how to run this business. And if it's a subsidiary or outsourcing partner, it also shows that nobody has ever audited this business.
This is criminally negligent behavior from the company owners, and whoever is contracting them to do this work.
Given the competence shown here, I doubt anyone approved anything. Most likely saving sent mail was a feature of whatever mail server they're using and it was a byproduct of the dumb decision to use an actual account for a "noreply" address.
They changed when they realised employees were taking all their customers’ details to new jobs.
A friend who's taken Visa's data confidentiality training several times notes that customer data is secondary to Visa's own marketing campaign details.
One nit: I'd rather see people redact sensitive data with solid blocks instead of blurs in screenshots. Can't be too careful!
However, I've also had to deal with the reverse. Folks from India and elsewhere that just blindly churn out code according to literal instructions and don't give any thought as to how that code might not be safe/efficient/whatever.
That being said, I blame the company, not the people. You could easily end up in a similar mess here in the states if you don't take some time to vet.
(note: watching someone code on an interview aka pair coding isn't vetting, even take home assignments don't. If you do either of these, you aren't vetting, you are subconsciously looking at speed/accuracy/ability to think quickly, which may also mean you are discriminating based on age/disability -- i.e. people that code slower or think slower tend to be older or have a disability -- which is a violation of federal law here in the states.)
I even had a conversation with one telling me "Americans can afford it, we don't feel bad hacking them". This came from a developer who worked with us for over 2 years.
This is not a subject like genders and pronouns or whatever makes sensitive people feel angry. I advise anyone I meet the same thing. Avoid at all costs. Maybe 1 in 20 are okay but I don't recommend rolling the dice for that single gem.
Why this one?
There should be a legal framework that holds companies liable for certain level of security mishandling when it comes to private customer data.
AFAIK it does not do much, if anything to punish breaches caused by incompetence. I have not heard of of any cases where companies were fined for breaches.
Not the whole of Europe. The EEA and the UK has legislation based on it what has not yet diverged significantly.
Edit: Yup! Instead of just doing calculations, it involved some e-mail workflow.
> The password could be used to log into the “noreplyeicher@ttibi.co.in” Microsoft email account.
I'm surprised this is literally true as described.
The actual browser itself makes the actual SMTP connection to the Microsoft e-mail host! The authentication name used is the above e-mail address. I typed out the Base64 to check:
1> (base64-decode "bm9yZXBseWVpY2hlckB0dGliaS5jby5pbg")
"noreplyeicher@ttibi.co.in"
The noreply address is just a fake you put into the SMTP envelope and From: which will bounce due to not resolving if someone replies to it.
> The actual browser itself makes the actual SMTP connection to the Microsoft e-mail host!
In this case, it's not that they were sending the password directly for any reason, but instead returning the raw SMTP log from sending the email; which as a byproduct had the password in it due to needing to authenticate with the SMTP server.
Total incomprehension of the driving force behind society for decades is not an indicator of intelligence.
Hopefully they at least took the Base64 password out of the error log. I'm sure they did. Right? !?
- store all sent emails
- create an interface for business/non-devs to view and search past messages
If they were using all the functionality of this "free" SMTP approach, that's quite a bit of development + maintenance cost.
I really can't believe they haven't changed the password. I wonder what part of their workflow that breaks?
Probably their single sign-on. They probably only have the one company password, shared. That's the single sign-on!
Persistent power being one of these.
Can't wait til there's enough electricity in India to where hacks become a primary concern.
They're laying down 100k kilometesr of fiber optic per a month and 350 5g cell sites per day.
“The noreply account could be the most important account in an organization because it could potentially have a record of everything they have ever sent to customers”
This shouldn't have been possible in the first place for a few months now as Microsoft did a massive push to disable anything but OAuth logins for O365.
This takes "don't call us, we'll call you" to the next level: running a vast chunk of your business from the noreply@ account!
Maybe applications that take personal and sensitive data should require a clearance. Companies that perform pen tests should also require clearances.
>TTIBI never responded to the question, so I decided to close the case on December 22 and CERT-In sent me a nice appreciation letter.
The letter:
"Dear Eaton Zveare,
This email is written in appreciation and recognition of your efforts for bringing our attention to the "Cryptographic Failures" in one of the Indian websites on 08.08.2023. The role of responsible security researchers is pivotal for creating a secure cyber ecosystem and CERT-In strongly believes in working actively with a researcher like you for the discovery of cyber security vulnerabilities and their subsequent remediation in a responsible manner.
We look forward to your valuable contribution in future as well.
Thanks & Regards"
https://eaton-works.com/cdn-cgi/imagedelivery/VwwCqBIYNXeyNQ...