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
A user who replied to me also shared some anecdotes that indicate further evidence towards that being the source (a private email address only used for GSuite admin purposes, on her iOS device, upon which she had Covve installed) -- thread here https://twitter.com/angelalgibson/status/1261314415829237761
Looks like it was mined from somewhere and combined with other data...
Unless people are putting their github urls in the contact apps?
Not sure I'd go so far as to accuse a specific company on a public forum. But in this regard, the idea that a contact management app could be behind this DB is plausible.
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 operations regarding customers in Europe, you need to notify your relevant Data Protection Authority
https://edpb.europa.eu/about-edpb/board/members_en
You should also sign your engineers up for this course:
https://www.elastic.co/training/specializations/elastic-stac...
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.
The entire company is in the EU. The need to reach out to their DPA ASAP.
Kudos for reaching out to the greater HN community as a channel for information. A lot of companies are concerned that such a public request gives the impression that they don't have a handle on things. Let's be honest: there isn't a company on a planet that, immediately following a breach, has a handle on things. Honesty is a pre-requisite to re-establishing trust in the (seemingly likely) event that this is a breach if your customers' data.
I don't envy the position you're in. By now, you've hopefully downloaded the link to the data dump[0] and have compared it against your own data to confirm that it is or is not a breach of your own operations. Please put out a communication as soon as possible if you confirm it's their data. Immediately after closing off access to the data (and I'd consider taking the whole thing offline[1]), before you take the additional steps to protect your environment from breach.
The next step is to lock it all down, everywhere. Rank the risks associated with your data; bubble that up to the components that touch it. Encrypt data and protect your private keys (HSM/virtual HSM), to the extent possible, segregate your data by risk, assign separate accounts to different risk categories and ensure lower risk accounts lack permissions to the data and cannot acquire the key to decrypt. Your "Staging", "Development" and "Test" databases ... any chance they have a snapshot of production from some point in the past[2]? Reduce the public exposure of your infrastructure -- create multiple private networks; ensure data can be accessed only by the thing or things that need to access it on the permissions and network layer. Depending on how you're set up, isolate management interfaces to a private network requiring separate authentication in addition to device authentication. Grant permissions to staff on a "minimum required to work" policy. For staff that require day-to-day permissions to high-risk assets, minimally get them a separate (individually assigned) administrative account to avoid accidental changes. But generally stick with "this person, and this alternate (bus factor), only, can alter permissions related to accounts used in production infrastructure"; ideally, requiring both for permissions changes would be awesome, but I'm not aware of broad adoption anywhere.
Audit roles assigned to everything. If this is AWS, you're going to be spending some time in AAM-related tools. Look at every account, every permission and everything it's assigned to and challenge it: does it need this much access? Can I make the access more specific (device narrowed)? Can I assign less access and achieve the same result? Can I separate out these two services with different risk profiles so permissions can be assigned more carefully?
All the best -- not a fun situation to be in.
[0] Someone posted one in the comments; might be gone, dig around the usual places and find a link from a "direct download" site if it's been taken down. (aim for mega.co.nz links; less costly, or google awesome-piracy for workarounds).
[1] I co-authored large parts of the internal security policy at Global Crossing (carried forward to Level 3) about a decade ago - we had a "Critical" category -- when triggered, a situation call started and didn't end until the issue was stable and root causes/solutions were identified. It also meant "if a device was categorized as being able to be infected (we were often dealing with aggressive malware), it was allowed to be taken offline regardless of impacts to the business" - i.e. the cost of failing to contain this is higher than the cost of turning off customers' service. We threw the switch a handful of times. It was hell.
[2] I used to lose it when I saw people doing this with live customer data... except that I've encountered it on 80% of projects I've worked, so I'm numb to it. You can roll fake data pretty easily with various different tools (online and CLI); nobody protects staging/test/dev like they protect prod and since you've determined you must protect this data in production, you don't want to have to protect dev/staging/test that same way.
There's no honour among thieves so there were a bunch of duplicates pretending to be "new" data, but yes there is a cottage industry of stealing smaller quantities of PII, focused particularly on email addresses and passwords (because those get re-used elsewhere) and credit card data (because you may be able to either buy something with it or at least fool your way past an immediate check on the card)
Do not re-use passwords. Like, that's the really easy "Wash your fucking hands" level lesson here. As someone who isn't employed to work with this data any more I'd say that 99% of the value isn't with like stolen passports (though we did see some passport data) or even credit cards, but the passwords.
If you hate that this is even a problem adopt and (if you write code or specify software) implement WebAuthn. Nobody would steal passwords if they didn't work. Not only does stealing WebAuthn credentials from a site's database not work (they're public, the secret that's valuable never leaves the user's FIDO dongle) crooks also wouldn't bother doing it, just like crooks don't steal farm machinery to pull candy vending machines off the wall and steal candy, whereas they do attack ATMs in exactly this way.
If you don’t know the password yourself, then phishing is less effective as it’s quite rare that your password manager forgets that it needs to fill out the form for you.
Don't forget governments. Whatever criminals and corporations have that they shouldn't have, governments probably have an order of magnitude more.
That's cool, thanks!
It must've been vacuumed up from other people's contact or email data.
I know that e.g. GMX has had a leak at some point (or sold data), as an email I created there ages ago was used in phishing. Okay, that's lame, but they've also used the fake name I had given to GMX, spelled perfectly. I've never used that name anywhere when signing up, so it must come from the database.
Edit: three personal domains registered nothing. One corporate domain registered a double digit hit. If I discern any clues I'll get back to the thread.
Maybe Mozilla could partner with HaveIBeenPwned to help dealing with that?
1: https://www.troyhunt.com/ive-just-launched-pwned-passwords-v...
I'd be interested to see the whole dump to see my full record...
To be fair, you’re asking your followers on twitter. That’s as biased as you can have, I would be really surprised if the majority would say no.
Unique passwords per site, with a password manager? Done a long time ago. Should I change some of them? OK, which ones? there are hundreds.
Details of what else about me is in this breech? Not clear where I can find that.
The ones that you know were pwned.
In theory you should change all passwords all the time, but this is a practical middle-ground between that and "never".
Given that, surely Troy can contact those people and ask "who knew this info?". Not many people would know who replaced my bathroom vanity top...
The email contained in this breach is the one I provided to Facebook. It was probably hacked or sold from one of the handful of apps I've connected with FB over the years.
"Pwned on 19 breached sites and found 5 pastes.
If this is public breaches, I would guess in reality I can probably assume it's on double/triple that for sites that have been breached but the data hasn't been posted online.
What am I supposed to do whenever I'm involved in a new breach? Burn all my accounts and start again?
...though in a case like this it wouldn't help since we don't know the site.
Knowing that you have been historically breached is less useful.. Until I need to convince somebody to start taking account security seriously.
Its quite sobering to discover that data breaches are commonplace.
If you reuse passwords, then change your passwords for all the accounts that use the breached password. Hopefully, it'll spur you to start using a password manager so you can easily have strong, unique passwords.
If you don't reuse passwords, then change your password for the breached account. Sometimes services don't tell you about breaches and it is HIBP that first informs you about the breach.
If there is some email address that you really, really don't want bad guys to know about (perhaps a dedicated email address for your important financial accounts), then it helps you know when to switch to another email address.
HIBP helps you know how often a service has been breached in the past, and that might help guide what services you want to use/not-use in the future.
And I think you’re about to describe Sign In with Apple.
Remember that most of us on here have extremely advanced knowledge of the Internet and its workings. This is not the case for the vast majority of Internet users.
I mostly use it through 1Password, because it also notifies you when a service has enabled new security features like 2FA.
https://www.elastic.co/guide/en/elasticsearch/reference/6.3/...
I guess searching on https://www.dehashed.com/ should give you some additional data.
I just got the email notification from HIBP (Have I Been Pwned) a few minutes ago [1], but I am not worried about the compromised data because 1) my personal email address, job title and phone number are all visible in my resume which is publicly available in my website, I actually encourage people —mostly tech recruiters— to download the PDF and contact me via email or phone all the time and 2) my physical address is irrelevant because I have been moving houses every year for the last seven (7) years (even across countries a couple of times. All the social media accounts I have are completely empty, I just keep them around to get a hold on to my nickname.
I recently found, in my website’s HTTP logs, several requests from a web crawler controlled by ZoomInfo [3] an American subscription-based software as a service (SaaS) company that sells access to its database of information about business people and companies to sales, marketing and recruiting professionals. I was going to configure my firewall to block these requests but then I remembered —hey! my website only has information I am comfortable sharing, so it doesn’t matter— but I’ve been thinking it is just a matter of time before someone hacks one of their systems and leaks their database.
In my previous-previous job I found a fairly simple (persistent) XSS vulnerability in BambooHR that allowed non-authorized users to access data from all employees registered in the website including Social Security Numbers (SSN). I told my boss and we immediately edited everything before migrating to a different system. We never knew if BambooHR fixed the vulnerabilities and I wouldn’t be surprised if the data was leaked before or after I found the security hole.
Software security is such a Whac-A-Mole game, even if you get the budget to conduct security audits on your code, there is always going to be a weak link somewhere in the chain and that will be your doom. This is one of the many reasons why I left that job as a Security Engineer, the other reasons were Meltdown [3] and Spectre [4] they both made me realize I was fighting for a lost cause.
[1] https://haveibeenpwned.com/NotifyMe
[2] https://en.wikipedia.org/wiki/ZoomInfo
[3] https://en.wikipedia.org/wiki/Meltdown_%28security_vulnerabi...
[4] https://en.wikipedia.org/wiki/Spectre_%28security_vulnerabil...
Probably these can have a different impact if your threat model is a bit different (money, status, living area, position held, etc).
Reminds me the story about an investigative reporter known in these parts, who was swatted: https://krebsonsecurity.com/2013/03/the-world-has-no-room-fo...
or received a drug package from an investigated person, basically it was a trap: https://krebsonsecurity.com/2015/10/hacker-who-sent-me-heroi...
The journalist knew about this and informed the police beforehand. Happy end.
To add a little more, I have seen people posting on social media answers to posts like "your favorite car, your place of birth, name of mother, name of pet". Guess who uses those words for similar secret questions?
Some personal identifiable information can be used to fabricate fake IDs, for various purposes.
And if we have a linked graph with all the personal, job, address, interacted people, geo-places, etc, it can get creepy (sounds like Facebook, but much more open).
Not saying we all should get paranoid, but leaked data could be used in different ways.
Others are saying they've found data from as recently as mid-2019, so could be possible that the reason it's so hard to find a source is that this is multiple sources. Looking at this as a dump from some sort of contact manager, could see this being a dump from some sales guy's CRM or something where he'd imported multiple datasets as potential leads alongside his personal contacts.
So far so good, if you are a competent PHP programmer (or any other programming language) you make sure these IDs are not consecutive to avoid enumeration attacks, but even if they are part of a guessable sequence you can still secure them by restricting access to all pages except the ones associated to the user ID in the session.
The vulnerabilities I found were a combination of Path Traversal [3], Forced Browsing [4] and Stored Cross Site Scripting [5] that allowed anyone to 1) force a specific PHP file to load arbitrary pages, 2) access data associated to other employee identifiers and 3) send all documents associated to these employee IDs to arbitrary emails by accessing the “Email File” page and crafting a simple HTTP request to bypass a rudimentary form validation.
When I told my boss he continued the investigation and found that we could access certain amount of data associated to employees registered in other subdomains. People who are familiar with BambooHR will understand how stupid this specific problem is considering each subdomain is isolated from the others, so one would expect them to isolate the databases as well.
I don’t know anything about the architecture of their system so I cannot explain why these security holes allowed us to access data from other companies. I was very scared to continue digging into it and my boss was super pissed off. We didn’t know if they used soft deletes so instead of removing the company’s data we decided to edit it with garbage information, then we migrated to another system.
And that was the end of our story with them. We never reported the problems because I started my “research” without previous authorization from BambooHR so if we reported our findings they could sue my employer and we would be in bigger problems. Same thing happened when we found a vulnerability on HipChat [6] in 2014 or so, we reported it and they got super angry at us for conducting that penetration test without permission, the company made an agreement with them and we migrated to Slack.
Good luck to anyone whose employer is still using BambooHR to manage their employee database.
[1] /ajax/employees/files/email_file.php?id=19
[2] /employees/employee.php?id=EMPLOYEE_ID&page=PAGE_ID
[3] https://owasp.org/www-community/attacks/Path_Traversal
[4] https://owasp.org/www-community/attacks/Forced_browsing
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.
https://github.com/acalvoa/SRID_CHANGER/blob/da367e68433b3fd...
Stored secret:
https://github.com/acalvoa/SRID_CHANGER/blob/master/config.p...
Will look more into this later
isNonIndividual, IsNonVisibleToOthers, ShowableNonVisibleToOthers
