Over 60 million customer records by a Cloud Application Hosting company Cloud Clusters Inc. leaked including user/password credentials for Magento, WordPress accounts, and MySql.
I've never even heard of Cloud Clusters and I've been working for some of the largest hosts in the US for a decade. I highly doubt they have 60 million customers. GoDaddy doesn't have 60 million customers. RAX doesn't have 60 million customers...
60 million records. They could have reseller hosting where one "customer" has 100's or 1000's of sites on their account. Each of those sites is probably a record.
This is something that GDPR is good for. If this was in the EU, it would've been illegal to hide the incident. Actually, it still might be illegal if they have EU customers.
No, it does not. If they sell to european customers, they fall under GDPR. Enforcement is something else and might require the explicit complain of a customer to their regulator.
How did they manage to store passwords in plain texts. I thought most of the services (wordpress etc) will create passwords for you with a proper encryption?
That's what I'm guessing too. Magento and WordPress both store only the hashed passwords in the database; however, a screenshot from the article shows that the hosting company had stored plain-text passwords for an admin user, which were likely generated automatically, and stored in a separate (and publicly accessible) database.
They have access to the DB users. You can craft a new user & password-hash pair and insert it into the DB to create your own Wordpress user to manage on their behalf, or the lazy way is to just update the user’s password hash with your own. Then when you fix the issue, revert it. Worked for me years ago, not sure if something fundamental changed
Implement a proxy authentication scheme for the hosted services (WP, etc). Now an admin working for the hosting provider can log in using a password checked against a hash stored in their hosting system. No plaintext passwords stored.
There are a few hosting billing system -> account creation products that will generate the login information at purchase time so they can be presented to the user in plain text before being sent over to the provisioned server. It could be being logged accidentally at that point.
Looks like they had tasks to run their services like "wordpress --user alice --password 123 --host alice.cloudclusters.com ..." and they systematically logged all the commands with all arguments/settings/variables.
Way too verbose logging. Should never have logged that.
The logging database (elasticsearch) was exposed to the internet without authentication. Free credentials for all.
> Way too verbose logging. Should never have logged that.
It's interesting to observe the contrast between this and "We're a SaaS startup and we log every.single. RPC request across all services forever including performance data".
You can log all HTTP requests and it is standard practice to do so at the load balancer level (haproxy and co have very configurable logging).
However you MUST NOT logs cookies or headers or content, because these can contain private information.
Last but not least, developers should never pass tokens/passwords in the request path because it will be systematically logged and leaked /api/token/abcdec. That should go into a header or the body.
For example:
Accidentally open to the internet log server(as above).
Attacker sends password reset request.
Attacker checks log to steal token.
Attacker now has stolen account until owner can't log in and does reset, or perhaps semi-permanently if attacker steals all tokens for said account and invalidates them before owner can use them.
For email verification it's less scary if that was really all you wanted.
If you believe you're verifying that the email went to your user, this isn't enough. Lots of systems parse URLs out of emails and follow them, you probably want to look for a a pre-existing session cookie, or insist the user log in from the verification page and confirm this is what they wanted.
Otherwise you've merely got two unrelated facts:
1. Some user of your system (maybe happy_pancake) says bob@example.com is their email address
2. Mail to bob@example.com is received by a machine or person which reads web pages.
It would be foolish to conclude from these facts that happy_pancake is actually bob@example.com or that bob@example.com wants to use your service.
it doesn't say so explicitly in the article, but the screenshots points towards an open elasticsearch instance that seems to be part of k8s logging infrastructure
I blame elasticsearch. I've spun up elasticsearch containers in the past on VPSs to have Meow hit them almost instantly.
It takes longer to read the docs and figure out that if you're not paying, security isn't default. In fact, it's a fair bit of configuration and reading to enable security properly if it's the first time you're using it.
Coupled with Docker popping holes all over your firewall, it's an easy way for a non-security aware operations engineer to leave data all over the internet.
If I'm not mistaken, Meow was created to delete data in instances like this to help protect against misconfigured instances.
I had totally forgotten Meow was even a thing. Talk about a purrfect example of a greyhat attack - pointing out the flaws and removing PII without demanding bitcoins or engaging in ransoms.
Obviously, treat all attacks as if they are serious.. but wow.
Happened to me while doing a Docker tutorial. The practice dockerfile contained an elasticsearch container which I put on that Hetzer instance. Shortly after I received an email from the BSI (German Federal Office for Information Security), warning me about it. Aparently all kinds of entities scan around for vulnerabilities.
I had noticed elasticsearch being the culprit in security advisories and reports of breaches, but it's easy to miss when you're busy with something else. Security has to be the default!
The definition of "malicious" is (acc. to Google): "characterized by malice; intending or intended to do harm."
The Meow bot "intended to do harm", that is, to databases. Of course the creator might have had "lofty" goals and high hopes that this attack will encourage better database managers to harden their security practices in the future. But the Bot itself is definitely "malicious".
Dumb question, but, does WordPress support a dynamic credential manager like Vault or Secrets Manager? Afaik you have to hard code plaintext secrets (such as for the DB) in a .php file?
Funny how leaks nowadays are misconfigured AWS buckets and ElasticSearches. Firewalling my Raspberry pi is probably more secure.
Going cloud is so much more secure, because reasons. Efficiency etc. They can hire experts. Yeah, they do and you can ignore vast swaths of them by checking some box somewhere.
Now you can efficiently fuck everything up and nobody knows how anything works anymore. Good job guys.
OMG, honestly, isnt the severly micro managed interview process supposed to weed out all those developers who are likely to make these kind of mistakes? I always got the impression, that there was a “proper way” to do things, and that was always shouted at me by developers and network engineers who actually have jobs. LOL, you are all good at shouting.
> Secure Thoughts collaborated with Security Expert Jeremiah Fowler to expose a massive leak
Seems to level up in the hacking world, you do whitehat stuff like this, but it could be that 90% of your work is blackhat. Why do 'researchers' risk exposing themselves like this (if the bulk of what you do is blackhat?). I'm not saying Mr Fowler is secretly a blackhat, but many people in the hacking scene are obviously blackhat judging by what they post on social media. You can infer that they like to get up to some sketchy stuff (again - risking exposing themselves to LE).
I think that they think its fun and neat to know how to do it, but most don't actually do it. Kind of like how most people training in martial arts, or tactical shooting aren't actually going around attacking people
No matter the color of your hat, if you're a security researcher, you're likely already on a watch list. Having publicly attributed white hat activity is a good cover.
>As a security researcher, I never circumvent or bypass password protected assets. These records were publically accessible and no hacking necessary to see 63.7 million records.
In Australia, our cyber security laws are very strong. There is no way I'd attempt to access services on random IP's to test if they use no password with common usernames for those services. Any semi compotent prosecutor could argue I accessed a computer without permission and they'd be 100% correct.
The only way I can see myself accessing a computer and not breaking a law is through a genuine mistake i.e. mistyping an IP/url and somehow having the right username + password.
I prefer to stay 100% on the legal side. The only way I'll touch a computer is with a signed document from the owner giving me permission and with clear instruction on what I can and cannot do.
Worth taking a moment to contemplate for second factors whether the credentials you have could "leak" like this.
* For SMS 2FA you might leak the user's phone number which isn't good, but even if you "leak" the 2FA code it's transient and will very quickly be worthless
* For TOTP leaking the current TOTP code (either entered by a user or calculated locally) is transient again, but if you instead leak the seed (which you have) that's fatal.
* For other types of single use codes leaking a code that was successfully presented isn't a problem (it was single use and now won't work) but leaking codes you've generated (e.g. from a "new codes" page) is fatal.
* With WebAuthn you (the relying party) do not have any secret credentials at all, so you can leak everything you have and it makes no difference to the system's security so long as you implemented it correctly.
With WebAuthN you do have secret credentials but if implemented correctly it is almost impossible to leak them, right? Also it might be worth mentioning that WebUSB implementation details have sometimes lead to issues/flaws with WebAuthN/u2f keys: https://www.wired.com/story/chrome-yubikey-phishing-webusb/
Hmmm. You'd think a company with "cluster" in their name would take steps to avoid a cluster-f%%k. Not this one.
It's really quite strange that WordPress passwords are shown in cleartext. WordPress core is diligent about hashing passwords, using nonces, and all that sort of security work. Maybe some workflow uses HTTP GET for logins, in which case passwords land in the weblogs. But a web service company? Using more-or-less standard open source web apps? How hard would they have to try to do that?
google dorking or using shodan can find things like this extremely easily. personally i don't do this sort of crap cause i don't need any legal problems, but it's good to know so you can do it against your own sites to see if you're exposing anything by accident like these dudes did.
There are a lot of terrible hosting companies out there. It's a race to the bottom on pricing.
Speaking as a person in the ISP world who's been doing this stuff since 1996, it's easy to run a terrible and shoddy ISP that works most of the time. It's much harder to do everything right and really care about network architecture, engineering and security.
I just bought 2 computers from a local business that was having a rummage sale.
I mounted the computers with a Linux live disk and it turns out that the computers were used by a professional website development company that created websites for several prominent local businesses around the state.
There was no encryption used on the drives and I found the passwords and authentication tokens for their advertising accounts, LastPass password manager, passwords used by their FileZilla instance, the business American Express card and billing, Office 365, Email accounts etc.
A year ago I purchased a used 500Gb external drive from a local computer recycling center and when I ran an open-source recovery program on the drive I recovered several years of patient medical records.
The lack of security and privacy awareness of the people handling sensitive information is disturbing.
On a similar note, I recently found the Instagram and FB tokens for a prominent media outlet right in their website source code, presumably for auto posting to those sites. Is that a security issue or normal? (Sorry in advance, I'm new to the whole security space)
54 comments
[ 2.9 ms ] story [ 99.2 ms ] threadThey should not be allowed to get away with criminal security.
Hmm, but where is this password stored? This sounds like exactly what they were doing!
Thus this could be a missing or misconfigured log filter for PII.
Way too verbose logging. Should never have logged that.
The logging database (elasticsearch) was exposed to the internet without authentication. Free credentials for all.
It's interesting to observe the contrast between this and "We're a SaaS startup and we log every.single. RPC request across all services forever including performance data".
However you MUST NOT logs cookies or headers or content, because these can contain private information.
Last but not least, developers should never pass tokens/passwords in the request path because it will be systematically logged and leaked /api/token/abcdec. That should go into a header or the body.
For example: Accidentally open to the internet log server(as above). Attacker sends password reset request. Attacker checks log to steal token. Attacker now has stolen account until owner can't log in and does reset, or perhaps semi-permanently if attacker steals all tokens for said account and invalidates them before owner can use them.
If you believe you're verifying that the email went to your user, this isn't enough. Lots of systems parse URLs out of emails and follow them, you probably want to look for a a pre-existing session cookie, or insist the user log in from the verification page and confirm this is what they wanted.
Otherwise you've merely got two unrelated facts:
1. Some user of your system (maybe happy_pancake) says bob@example.com is their email address
2. Mail to bob@example.com is received by a machine or person which reads web pages.
It would be foolish to conclude from these facts that happy_pancake is actually bob@example.com or that bob@example.com wants to use your service.
It takes longer to read the docs and figure out that if you're not paying, security isn't default. In fact, it's a fair bit of configuration and reading to enable security properly if it's the first time you're using it.
Coupled with Docker popping holes all over your firewall, it's an easy way for a non-security aware operations engineer to leave data all over the internet.
If I'm not mistaken, Meow was created to delete data in instances like this to help protect against misconfigured instances.
Obviously, treat all attacks as if they are serious.. but wow.
I had noticed elasticsearch being the culprit in security advisories and reports of breaches, but it's easy to miss when you're busy with something else. Security has to be the default!
Wasn't the whole point of Meow to delete erroneously public-facing data to prevent malicious use?
Calling it a malicious script is ...debatable.
The Meow bot "intended to do harm", that is, to databases. Of course the creator might have had "lofty" goals and high hopes that this attack will encourage better database managers to harden their security practices in the future. But the Bot itself is definitely "malicious".
https://docs.aws.amazon.com/AmazonECS/latest/developerguide/...
https://www.rayheffer.com/aws-secrets-manager-for-wordpress-...
https://github.com/humanmade/hashicorp-vault
Going cloud is so much more secure, because reasons. Efficiency etc. They can hire experts. Yeah, they do and you can ignore vast swaths of them by checking some box somewhere.
Now you can efficiently fuck everything up and nobody knows how anything works anymore. Good job guys.
Seems to level up in the hacking world, you do whitehat stuff like this, but it could be that 90% of your work is blackhat. Why do 'researchers' risk exposing themselves like this (if the bulk of what you do is blackhat?). I'm not saying Mr Fowler is secretly a blackhat, but many people in the hacking scene are obviously blackhat judging by what they post on social media. You can infer that they like to get up to some sketchy stuff (again - risking exposing themselves to LE).
From the article.
The only way I can see myself accessing a computer and not breaking a law is through a genuine mistake i.e. mistyping an IP/url and somehow having the right username + password.
I prefer to stay 100% on the legal side. The only way I'll touch a computer is with a signed document from the owner giving me permission and with clear instruction on what I can and cannot do.
* For SMS 2FA you might leak the user's phone number which isn't good, but even if you "leak" the 2FA code it's transient and will very quickly be worthless
* For TOTP leaking the current TOTP code (either entered by a user or calculated locally) is transient again, but if you instead leak the seed (which you have) that's fatal.
* For other types of single use codes leaking a code that was successfully presented isn't a problem (it was single use and now won't work) but leaking codes you've generated (e.g. from a "new codes" page) is fatal.
* With WebAuthn you (the relying party) do not have any secret credentials at all, so you can leak everything you have and it makes no difference to the system's security so long as you implemented it correctly.
It's really quite strange that WordPress passwords are shown in cleartext. WordPress core is diligent about hashing passwords, using nonces, and all that sort of security work. Maybe some workflow uses HTTP GET for logins, in which case passwords land in the weblogs. But a web service company? Using more-or-less standard open source web apps? How hard would they have to try to do that?
"We take data security very seriously." Yeah.
https://www.youtube.com/watch?v=u_gOnwWEXiA
https://www.youtube.com/watch?v=oDkg1zz6xlw
Speaking as a person in the ISP world who's been doing this stuff since 1996, it's easy to run a terrible and shoddy ISP that works most of the time. It's much harder to do everything right and really care about network architecture, engineering and security.
I mounted the computers with a Linux live disk and it turns out that the computers were used by a professional website development company that created websites for several prominent local businesses around the state.
There was no encryption used on the drives and I found the passwords and authentication tokens for their advertising accounts, LastPass password manager, passwords used by their FileZilla instance, the business American Express card and billing, Office 365, Email accounts etc.
A year ago I purchased a used 500Gb external drive from a local computer recycling center and when I ran an open-source recovery program on the drive I recovered several years of patient medical records.
The lack of security and privacy awareness of the people handling sensitive information is disturbing.