The unattributable “db8151dd” data breach • Hacker News Board

Re: The unattributable “db8151dd” data breach

#121

Post by lawnchair_larry » Fri, May 15, 2020, 7:53 PM UTC

throwaway834792 wrote: post #71

Based on a large (over 50 results) domain search for a company I work for, the data I found was very old, circa 2014. I know this because almost everyone in the domain search stopped working for the company on or after 2014. Everyone else has worked at the company since 2013 or earlier.

That doesn’t set an upper bound on when the breach happened, it sets a lower bound. Old email addresses aren’t deleted by whoever had them. It just means it contains data from at least 2014, up to and including 2019.

Re: The unattributable “db8151dd” data breach

#122

Post by VectorLock » Fri, May 15, 2020, 8:56 PM UTC

Nextgrid wrote: post #2

For the people that use unique per-merchant e-mail addresses (like someone+amazon@...), could you try some of those aliases on HaveIBeenPwned and see which ones come up in this breach? That might shed some light onto its origin.

So many things disallow + in email addresses I don't even bother any more.

Re: The unattributable “db8151dd” data breach

#123

Post by UI_at_80x24 » Fri, May 15, 2020, 8:56 PM UTC

noxford1 wrote: post #48

smichel17 wrote: post #41

Earlier quoted context omitted.

Thanks for saving me a click. No desire to play "guess how many minutes I'll have to spend clicking sidewalks" today.

If it takes you minutes to solve a recaptcha your problem might not be the recaptcha...

It must be his fault, things like being visually impaired cannot ever be accounted for or considered.

Recaptcha is hostile to end users and makes my like a fucking hell. But your right, it's my fault.

Re: The unattributable “db8151dd” data breach

#124

Post by Scoundreller » Fri, May 15, 2020, 9:00 PM UTC

alexpotato wrote: post #119

tialaramex wrote: post #116

Earlier quoted context omitted.

No, more likely it's like street corner drug dealing, or say, the industrial area near me that has street walkers (well I presume it doesn't now because neither street walkers nor their johns want to die of COVID-19) This stuff happens, at a low level, and prosecuting it is expensive and makes little real difference so why bother? It's not even like busting shop lifters and petty burglars where at least you make the…

I remember one of the online British banks writing up a whole detailed post on how they knew exactly who has been stealing money from them. They wrote up all of their information and sent it to the police who came back with: "Yeah, thanks. Here's the thing: this is non-violent crime and the total amount stolen is less than GBP 100,000" (don't remember the exact number but something thereabouts). People like to think…

Usually in that situation you could sue the person in court.

Easier to prove too.

Re: The unattributable “db8151dd” data breach

#125

Post by Scoundreller » Fri, May 15, 2020, 9:02 PM UTC

VectorLock wrote: post #122

Nextgrid wrote: post #2

For the people that use unique per-merchant e-mail addresses (like someone+amazon@...), could you try some of those aliases on HaveIBeenPwned and see which ones come up in this breach? That might shed some light onto its origin.

So many things disallow + in email addresses I don't even bother any more.

Or accepts it at account creation, but not at login!

Re: The unattributable “db8151dd” data breach

#126

Post by Scoundreller » Fri, May 15, 2020, 9:02 PM UTC

jerome-jh wrote: post #16

Nextgrid wrote: post #9

Earlier quoted context omitted.

Could it be from whois data? Seems like a reasonable place for which to submit such a generic address.

Or could be the spammers sanitized them.

How would they know which to sanitize???

Re: The unattributable “db8151dd” data breach

#127

Post by akersten » Fri, May 15, 2020, 9:04 PM UTC

wnevets wrote: post #108

Am I the only one who dislikes some of those column names? isNonIndividual, IsNonVisibleToOthers, ShowableNonVisibleToOthers

I can smell the enterprise ball-of-mud spaghetti code from here :)

Re: The unattributable “db8151dd” data breach

#128

Post by viro » Fri, May 15, 2020, 9:05 PM UTC

throwaway9993 wrote: post #50

Dataset for sale: [redacted] Similar data structure: https://stackblitz.com/edit/angular-soswe4?file=src%2Fapp%2F... Owner works for: https://covve.com Covve: This simple yet state-of-the-art app will revolutionise your business relations like you've never seen. Edit: Response: https://twitter.com/covve/status/1261287954967941120

thank you

Re: The unattributable “db8151dd” data breach

#129

Post by smichel17 » Fri, May 15, 2020, 9:30 PM UTC

NSAID wrote: post #117

eitland wrote: post #84

Earlier quoted context omitted.

It might just be that you use Firefox. Seems anybody who doesn't use Chrome is automatically flagged even if you are logged in with a >12 years old gmail account that is linked to paid storage.

I use Firefox with numerous tracker blockers and only had to hit the checkbox.

Turning on privacy.resistFingerprinting in about:config is the big one. The temporary containers addon also makes a difference.

Re: The unattributable “db8151dd” data breach

#130

Post by outworlder » Fri, May 15, 2020, 9:40 PM UTC

service_bus wrote: post #89

alexproto wrote: post #68

Hi all, Alex here, CTO at Covve. Just got alerted of incident db8151dd in . We’re investigating as top priority with our security experts what relation this may have with Covve. We are monitoring the feedback in this blog and would really appreciate any additional information you may have on this as we investigate (alex@covve.com).

It appears your organization left an elasticsearch database exposed to the internet. This happens frequently due to poor configuration. You're either going to have logs pointing to an IP that the individual used to siphon your data, or nothing. With an exposed elasticsearch database, you possibly had the data being siphoned by many parties, and are only aware now because of this particular incident. If you have any o…

> It appears your organization left an elasticsearch database exposed to the internet. This happens frequently due to poor configuration.

sigh

Why is everything being deployed publicly accessible? If one is relying on their database configuration as their only protection, they are one fuckup away from disaster.

Layers, people, layers. If this is on a cloud provider, put it on a private VPC/subnet. Add a load balancer or similar serving traffic only to the instances you need traffic routed to(which are unlikely to be databases themselves, more likely web servers). Configure firewalls accordingly. And of course, configure the servers properly.