Live data from Hacker News

How we discovered a database leak in one of the biggest Swiss hosting providers

security.infoteam.ch

61–68 of 68 posts

Re: How we discovered a database leak in one of the biggest Swiss hosting providers

#61

Earlier quoted context omitted.

There is a other email that the regexp lets pass and that’s still not valid: codetrotter@example.com It conforms to the expectated format and could be a valid email, but it’s actually not because no such user exists. An email might also exist, but not accept mail from you. The given email address might exist, by could belong to another user. There’s a million things that can go wrong and you’ll have a very hard time…

Good points. Why do regex tests at all if emails could fail in any number of ways? If you're going to test for at least 3 characters with a @ in the middle, you probably should implement some other simple rules to have a snowball's chance on the internet: only one @ no spaces has TLD (guarantee at least one period after @, and something else after, no consecutive periods) can't begin or end with a period

Your “has TLD” test is already wrong: localpart@tld (example@de) is an odd, but valid address.

Re: How we discovered a database leak in one of the biggest Swiss hosting providers

#62

Earlier quoted context omitted.

I should have been more specific: an email address that is routable over the internet. Where's the TLD on that?

What section of what standard says a TLD can't have an email server on it? Is AAA not allowed to host an email server on `aaa`[1], and have the email `sales@aaa`? [1]: And "aaa" is a valid TLD; see the full list: https://www.iana.org/domains/root/db ; now, perhaps it is required to at least have a second level domain, but that's what I'm asking: is an MX record invalid on a TLD?

It’s actually a valid email and I’ve seen examples of such emails, but can’t remember the exact specifics.

Re: How we discovered a database leak in one of the biggest Swiss hosting providers

#63
post #26
post #8

For whoever was wondering who this provider is: according to whois-nslookup-mxtoolbox_arin_lookup, the server hosting infoteam.ch is provided by metanet (metanet.ch) Not trying to ruin their business, but they should consider handling issues like this one properly.

Sorry, but to avoid problem for now, we prefer to keep the provider anonymous, however we can assure you that it is not metanet.ch.

My mistake, and I am sorry. Feel free to downvote my above post into oblivion.

Re: How we discovered a database leak in one of the biggest Swiss hosting providers

#64
post #7
post #4

They probably use a homebuilt admin panel and sw mgmt, and an update brought back in the old root vuln. They don't use cPanel or Plesk. Or the Chinese hacked it again. Interestingly they - https://security.infoteam.ch/ - offer the very same security service, automatic security audits for their customers. Which explains their angry response the 2nd time.

Maybe I got you wrong, but infoteam.ch are the guys who wrote the blog-post, so your link is to their product they are describing, and not one by the provider? How does that again explain the angry response? AFAIK there is no mention or link to the provider, I guess since they don't want to make enemies just yet (and lose hosting while doing so). But I am willing to speculate that they are looking for another provide…

I got it wrong, not you. Thanks for the heads-up.

They didn't mention who leaked the data. I got confused. The symptom they described looks like an automatically updated system with a leak. One of our swiss customers, a big hosting provider, uses such a system and would fit.

Re: How we discovered a database leak in one of the biggest Swiss hosting providers

#65
post #13

Their vulnerability scanner is basically an on-demand DOS attack. Tried it on my site and almost brought it down

Good. That also tells you that your server probably needs some DOS mitigation. Because if their service almost takes it down, so can a trivial nmap sweep.

Yes, my site does - but that's not the point - it's a text field on a website anyone can use to hit any site without effort.

It's also supposed to be a helpful service, which generally implies it's not gonna behave in a way some would consider to be malicious, but it has no rate limits. If I saw that hit my logs i'd consider it to be an attack, not a friendly vulnerability scan.

Re: How we discovered a database leak in one of the biggest Swiss hosting providers

#66
post #27
post #13

Their vulnerability scanner is basically an on-demand DOS attack. Tried it on my site and almost brought it down

Perhaps your site is just really slow?

It's not super fast, but it's not really slow. A single web server doing 50 req/s, and they pushed that up to 100 req/s. The limit is somewhere around 75.

Re: How we discovered a database leak in one of the biggest Swiss hosting providers

#67
post #26
post #8

For whoever was wondering who this provider is: according to whois-nslookup-mxtoolbox_arin_lookup, the server hosting infoteam.ch is provided by metanet (metanet.ch) Not trying to ruin their business, but they should consider handling issues like this one properly.

Sorry, but to avoid problem for now, we prefer to keep the provider anonymous, however we can assure you that it is not metanet.ch.

You should probably mention that at the top of your blog post. bipson is probably not the only one coming to this (apparently) wrong conclusion based on your current hoster.

Re: How we discovered a database leak in one of the biggest Swiss hosting providers

#68

Earlier quoted context omitted.

> Then, they blocked the IP address of our scanner so we could not scan their server anymore. Long time lurker, made an account just to ask this: What are your comments on this unprofessional reaction from the Swiss?

They should release the name of the hoster. Not so much for internet points but to warn the customers. Who knows what information could have leaked from all those DBs, and I doubt that the hosted sent out a report on that incident.

100% agreed.
Post reply on HN