💾 Archived View for dioskouroi.xyz › thread › 24996832 captured on 2020-11-07 at 00:52:03. Gemini links have been rewritten to link to archived content
-=-=-=-=-=-=-
________________________________________________________________________________
Worth taking a moment to contemplate for second factors whether the credentials you have could "leak" like this.
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)
Depends what kind of token. Could be a big deal, could be nothing.
Do you feel safe using these pre-loved drives/computers? It seems like a handy way to pick up some kit but I'd wonder about issues with them.
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
I also imagine that being whitehat can fill a lot of the thrill side of things that you might get from blackhatting with significantly less risk.
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.
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.
>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.
From the article.
Evidence of Meow bot attack (a malicious script that deletes data).
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 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".
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?
The author points out that these were monitoring logs (and the screenshot looks very much like an Elastic cluster).
Thus this could be a missing or misconfigured log filter for PII.
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.
Single-used tokens are fine to be passed in the path right? Like email verification /token/{token}
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.
Defense in depth says No, not Ok.
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.
They are a fully managed service for these services, so I'm assuming they store their own set of credentials separately to maintain access.
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.
My hosting provider (to remain nameless) also offers a global login bypass for WP and it gives me the willies.
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.
What would be a proper way to handle it?
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.
> the hosting provider can log in using a password checked
Hmm, but where is this password stored? This sounds like exactly what they were doing!
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
Logging of credentials supplied for 1-Click installs comes to mind.
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.
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!
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.
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.
https://www.youtube.com/watch?v=u_gOnwWEXiA
https://www.youtube.com/watch?v=oDkg1zz6xlw
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?
"We take data security very seriously." Yeah.
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.
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 would guess though, far, far fewer than 60 million customers. I don't see anything that mentions how many "records" per customer were leaked.
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.
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?
Natively, no, but not impossible:
https://www.rayheffer.com/aws-secrets-manager-for-wordpress-...
https://github.com/humanmade/hashicorp-vault
You typically grab those values from environment variables if you deploy wordpress as a container.
Also ECS task definitions natively support Secrets Manager, with no intermediate retrieval necessary
https://docs.aws.amazon.com/AmazonECS/latest/developerguide/...
Nice!
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.
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.
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.
Would that not sadly depend on them having a presence in Europe, with either servers or incorporation?.
They should not be allowed to get away with criminal security.
I'm not sure; I think that if they operate in the EU, they fall under EU law - EU-hosted servers or no. But don't quote me on that.
Pretty sure you're right, but if they have no legal presence in the EU, then it's still hard to enforce.
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.