How we discovered a database leak in one of the biggest Swiss hosting providers(security.infoteam.ch) |
How we discovered a database leak in one of the biggest Swiss hosting providers(security.infoteam.ch) |
Thanks to Hacker News and its incredible community, there have been a massive number of new users. We are working on adding more resources to the infrastructure to make the scans quicker. For now, it is possible that some of you have to wait some hours before receiving the first results.
Thanks for trying our new product, we hope to improve it with your feedbacks.
Long time lurker, made an account just to ask this: What are your comments on this unprofessional reaction from the Swiss?
Not trying to ruin their business, but they should consider handling issues like this one properly.
https://apility.io/search?q=infoteam.ch
https://apility.io/search?q=80.74.143.113
https://apility.io/search?q=dynco.ch
This thing happens sometimes, specially if you use a shared hosting. Recently using a well known cloud provider the Public IP address assigned was in a spam blacklist! It’s a good idea to have a look at your IP and domains frequently.
(Disclaimer: I’m the founder of the tool used for the lookup in the blacklists)
The conclusion for what happened is obvious: the host "patched" what the attacker had done, but not the vulnerability that gave them access. Thus, the attackers re-used the same attack later to re-gain access.
However how do you go about picking a new provider? How do you know that anyone else is any better?
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.
(Also overriding scrolling is not cool)
"That's expensive, and complicated! We'll just do regular audits and be fine."
[some time later]
"Someone exfiltrated all our data using mysqldump!"
= /
source: nslookup infoteam.ch; whois 80.74.143.113
(I do think, however, that it would be important to know.)
Sounds a lot like feigned ignorance about the nature of the root user. Not entirely sure if it would help them in a court of law. They should probably anonymized the whole thing better to be completely on the safe side (not a lawyer though).
Given a few other hints at English not being the first tongue (or possibly even the fourth, CH having four official co-equal languages) of the writer(s) in question, that could just be awkwardness from a non-native speaker. Their English is vastly superior to my German, French, Italian, or Romanche.
Check the access logs.
Regularly.
that besides pitching their own product for an issue any similar natured scan would pick up i'd say it smells like marketing department at work more than chinese hackers or shitty service provider.... >.>
i doubt they would have left a passwordless root on their mysql, or didnt they check the initial setup they were given by the provider before taking it in use?
Once that account is deleted, a new passwordless root account is created by the attacker in order to continue access.
And the problem returned a week after the 'fixed' it.
I know nothing about the particular hosting provider in question.
I've also seen, in general, far more false alerts than real ones. (Yes, Nagios, I am in fact looking at you.)
The gender-casing is a quirk of the article, and would reflect at least three of the languages official within Switzerland (German, French, and Italian are all gendered languages, I'm fairly certain Romanche is as well). It's fair to note that, though perhaps not quite to the extent you did.
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.
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 provider just now :)
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.
Beyond that just queue and try to deliver the email. Tell the user than an email should arrive shortly and that if it doesn’t they should check their spam folder and that they should check that they gave the correct email address. When you say this you repeat the email address that the user gave you (escaped for XSS of course).
I think some people “validate” against a strict pattern to keep their users from mistyping, but really there are so many ways to make a typo and still match those regexes that IMO it’s pointless to use a complicated regex and 80% of the times those regexes end up rejecting actually valid (though unusual) email addresses.
I think for a lot of developers the reason they do this is that they’ve learned that they should validate data and so they decide to validate email and to do so they either copy-paste some random-ass regex off the internet or they write their own broken regexes.
All your regex should do is to ensure that there is an @ in the address and that there is something before and something after. This keeps people from mistakenly entering say for example their phone number because they didn’t read what the field was for.
To prevent people from making your machine send your emails where it should not, such as to root@localhost of your server or elsewhere on your local network (don’t know why anyone would and also it wouldn’t be a big issue, just a tiny bit annoying), is a server configuration concern. Specifically, a concern of configuration of the email server software and of your firewalls.
User presses sign up -> Send then to registration form, they fill in their details which you validate lightly client side, they submit -> You validate lightly server-side and either send them back to the form or on to the next step -> You tell them “Thank you, your registration is now complete. An email should arrive in your inbox shortly. If it does not, please check your spam folder and also control that you entered your email address correctly. The email address you gave us was somebody@example.com.”
codetrotter@example
code@trotter@example.com
code trotter@example.com
codetrotter@example..com
codetrotter@example.com.
.codetrotter@example.com
My company runs a website that has elderly people signing up for newsletters. The client is paranoid about not getting every last drop of possible data, and raises hell for every email address that isn't deliverable. There are LOTS of ways to easily ruin a simple email address.
Wrong: https://en.wikipedia.org/wiki/Email_address#Syntax
(I know this is of little help if your email app doesn't allow them. I just want to point out that the standard does allow them.)
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 catching them.
The only way to identify if an email is valid and accepts mail is to actually send an email there.
You can, as a help for the user identify odd looking email addresses and flag them in the UI (“this looks unusual, are you sure”), but generally speaking, chances are high that any strict validation will reject real world addresses while not catching all errors.
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
You cannot validate an email address.
You can make a basic excruciatingly simple test for proper form. And should probably limit your checks to that.
For all else, attempt to use the email address provided for validation within your onboarding loop with a sufficiently unique verification URL or code. If that succeeds, the address is ... still not absolutely certainly valid, as it may have gone to a third party who proceeded to verify it. But at least it delivered to somebody.
See: https://hackernoon.com/the-100-correct-way-to-validate-email...
[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?