Why this one?
Total incomprehension of the driving force behind society for decades is not an indicator of intelligence.
- 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.
Btw, schedule is spelt with a c after the s.
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.
Hopefully they at least took the Base64 password out of the error log. I'm sure they did. Right? !?
One nit: I'd rather see people redact sensitive data with solid blocks instead of blurs in screenshots. Can't be too careful!
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.
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”
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
- 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.
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.
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.
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"
There is a second IT silliness here, a minor one compared to the password gaffe. "noreply" addresses should not be real mail accounts or working aliases!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!
This is not generally possible, browsers cannot make arbitrary socket connections in the way that would be required to reliably communicate with an SMTP server. The article makes clear that the frontend is calling a poorly-coded email-sending API implemented as an HTTP endpoint.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.”
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!
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.
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.
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.
>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...
This isn’t a marketing push so much as an observation. Some company will fill this niche at some point. There is no reason to disclose your SSN to a car dealership if you can share a shielded, verifiable record of your credit history to them.
You can look through my comment history — I am not here to sell a product.
Isn't it accepted security knowledge, that about 99% of everybody is at a "should not be doing it myself" level of security/crypto incompetence? I'm not saying that the example isn't particularly bad. It is.
Requiring competence would appear to be the wrong way to do it, here.
I'm aware of employment contracts that require you to pay back the cost of training if you leave the job before some specified time period (maybe 1 or 2 years).
And where did that 5% chance come from? Any kind of data to back it up or is it just a number you pulled out from nowhere?
If your businesses don't know how to employ external contractors blame it on your managers. India is a massive country. Not every Indian developer is an incompetent buffoon, just like not every European/American is the next Fabric Bellard.
It is not racism. Since we stopped working with them, we haven't had a single issue with our software development services. They simply do not understand business basics. They write code as if we ask ChatGPT. No second thought, no bug hunt. Just linear coding with no security in mind. They do not ask themselves "If I remove this code from here, would this other part break?". We worked more on fixing the issues they caused than we worked with them.
We won't make this mistake again. I am also very sure this is not only us. I heard it from many American developers. If you have some time, just read some horror stories on tech blogs and other forums. I understand things might be difficult in India that force people to lie about their skills to make money but now we rather pay double than deal with issues the cheap labor causes.
Here's a long list of them
If you search for "technical" you get "organisational and technical measures", and most are organisational rather than technical.
If you search by the word "hack" which seems to be the seems to be the usual terminology used there for vulnerabilities being exploited. There are 18 of these of 2182 entries. Not even one per EU country since 2018. Given how common data breaches are it is a tiny number.
Most of them do not give details, but those that do suggest the fines are levied only in extreme cases (for example allowing unauthenticated internet access to medical data: https://www.enforcementtracker.com/ETid-1015 ) or for certain types of failure (e.g. not having MFA). Most do not give details.
its better than I thought, but still far too little, and all the cases where any details are given it is for only a very narrow range of failures.
Here's a few famous ones, most of which are of course a few years old since government agencies tend to move slow but more recent ones will get what's coming for them.
https://www.theguardian.com/technology/2022/nov/28/meta-fine...
https://ico.org.uk/media/action-weve-taken/mpns/2618524/marr...
https://en.wikipedia.org/wiki/British_Airways_data_breach#Co...
A GDPR related 400 000€ fine because a company was storing confidential data without authentication using sequential IDs, _and_ they didn’t care when they were warned about the issue.
He's doing the job we put him there to do.
I see your point, did you know it’s a book?
Dang
Harvard Business Review: https://hbr.org/2014/12/overcoming-the-peter-principle
[1] https://www.ribbonfarm.com/2009/10/07/the-gervais-principle-...
The news stores are more encouraging. Thanks.