OCR Software Dev Exposes 200k Customer Documents
bleepingcomputer.com
bleepingcomputer.com
The bigger mistake was made before this data breach even happened.
Keeping your data on cloud introduces new attack vendors. It closes others.
If you're going to be an idiot[2][3], and host a production database which doesn't require any authentication on the cloud, I don't have much hope for your non-cloud-deployed security.
[1] For most reasonable definitions of every.
[2] I have had the dubious pleasure of working in a ~15 year-old software company where ~half of the machines were virus-infested (Mostly Conficker, but also some other shit that I forget. This was in 2012. If I recall correctly, we had one part-time IT guy for ~30 engineers. His job was ordering computer parts, and keeping e-mail working. The health of the dev machines was not his problem.) The SOP was to do all your work in a VM running Windows XP, and wipe it every few weeks, or whenever performance would grind to a halt - whichever came first. One of my tasks, a few months in, was to deal with the virus situation on the build server, so that we could 'securely' build the release, and sign it with the encryption key that only the VPs had access to.
[3] I have also had a chance to work in a company obsessed with security (Because of the nature of their products). One of my discoveries, a few months before I left, was that one of their products' updates were pushed via an insecure HTTP downloader. While I was there, nobody budgeted time to get it fixed.
However, the customers that uploaded sensitive documents to this cloud OCR service did not have control of the computers, the code, or the configuration.
Yes, if you don't trust anyone you can't get anything done but this feels like the kind of task where you should be a little bit nervous each time you do it.
Only when losing customer information equals to revenue drops, company will take security more seriously. Enforcing a law to company storing customer to have common security practice is a possible solution, though it hurts low budget startup.
If it's a big megacorp like Google or Microsoft, and I don't consider myself a target for state-level actors, easy.
If I was running a cloud platform of such a massive scale I'd probably scan my own ports to identify glaring problems like this one. Kind of surprising that isn't happening considering how bad it is to have the brand associated with a report like this.
My thought process is deploying this on digital ocean would make it insecure by default.
https://docs.mongodb.com/manual/reference/configuration-opti...
And Mongo isn't even faster for development either while it's far harder to optimize and by default insecure.
Easy mistake to make. I've probably done it at least once on publicly accessible test instances.
It's happening too much.
A somewhat random password would at least provide some protection and minimal inconvenience for devs.
As a developer: really try to minimize data collection at all costs.
I'm waiting for a future where the above is considered common sense.
Thankfully the OCR engine processed documents offline, in a seemingly prescient move, adherence to the rule of processing and storing as little data as needed saved an anxiety inducing set of events from occurring.
Shame that small teams (I think that team is less than 10 devs) are sometimes the only businesses with enough sense to ensure their risk when it comes to things like this is mitigated or reduced.
Dev: I don't gotta worry about setting up Auth on my mongo instance for dev/testing. Deploy/Admins will handle it in production...
Admins: They delivered a container package from CI so we assumed they had set up authentication correctly...
Skiddie: Om nom nom...