9 ms·
I discovered thousands of open databases on AWS
- curiousgal 5y ago> Successful SSH login using the private key I'll be the grumpy uncle and tell people NOT to do this.
- andreareina 5y agoAre you saying not to log ssh logins, or not to allow access via keys? What would you tell people to do instead?
- curiousgal 5y agoI'm telling people not to use a private key they found to log into servers. It's tempting to see how far the rabbit hole goes but it can be very problematic.
- andreareina 5y agoArticle says it's part of "Kubernetes logs for the entire production clusters (gathered through log collectors)", not that the author actually found private keys and used them.
- jeroenhd 5y agoLogging in using someone's password, even if it got leaked like this, is considered a crime where I'm from. I'm sure whatever jurisdiction the author lives in has similar laws. If you know you're not supposed to be inside someone else's computer system, you shouldn't access that system, or shut up about it at least! A crime with good intentions is still a crime according to the law!
- rockwotj 5y agoThis isn't a new thing sadly, numerous reports about stuff like this with both Mongo and Firebase have been reported before
- shaunpersad 5y agoDoubtful on Firebase. It's a managed service so it's not in the same category as these DBs, and is also authenticated by default.
- rockwotj 5y agoI used to work on the Firebase realtime database - many people went to production with public reads/writes. We spent a lot of time trying to educate people not to do that. Examples: https://www.comparitech.com/blog/information-security/firebase-misconfiguration-report/#What_data_is_exposed https://www.comparitech.com/blog/information-security/fireba... and http://ghostlulz.com/google-exposed-firebase-database/ http://ghostlulz.com/google-exposed-firebase-database/
- rockwotj 5y ago> For some companies, the DMARC and SPF records did not allow emails to be received in their mail servers from outside the company. What a mess, they cannot be reached by email at all. Huh? Those protocols are just about sending emails - not receiving mail. Was this supposed to be MX records and firewall rules?
- tmikaeld 5y agoIf spf only include the company ip and the dmarc policy is to drop unknown senders, then it won’t be received by the company’s mail server, it will be dropped.
- technion 5y agoI can't really follow this. If I am trying to email you, there is nothing that could be broken about your DMARC policy which would prevent your mail server receiving my email. What matters would be my own policy, as the sender. Now you might prevent me seeing your replies, but that's another matter.
- kilburn 5y agoDMARC and SPF apply to the domain of the sender, not the recipient. If the SPF records for domain.tld only allow their network's IPs, it means that they won't accept mails FROM domain.tld that come from outside their network. Mails TO domain.tld should be accepted normally, no matter where they come from. It seems to me that the researcher was trying to communicate with those companies by sending them emails using a FROM address of the company. That is, he was sending mails with a forged FROM and SPF/DMARC stopped them as it was designed to do. Alternatively, maybe those companies were using some kind of email filtering service as "front MXes" that then tried to deliver to the company's own servers. In that case it would indeed be a mistake to not include the filtering service's forwarder's IPs in the SPF record, and they would indeed be unreachable from outside the company. In my experience this does happen from time to time, but it is very noticeable (your users will complain) and it gets fixed quickly. It's very stange to me that the researcher met this scenario multiple times...
- tomrod 5y agoTerrible! And terrifying!
- technion 5y agoThere's been a lot of news about Mongo and ES, wait until people start searching for MS SQL servers with blank sa passwords. I've lost count of the amount of conversations I've had trying to shut that down with various organisations.
- hsbauauvhabzb 5y agoI’ve run responder on a digital ocean box (don’t ask) and seen large volumes of attempts to access a fake mssql server, the amount of zombie attacks is pretty eye opening.
- the_arun 5y ago1. Isn't this a gap in the platform? I mean, shouldn't AWS automate this and alert (via AWS Config Rules/AWS Security Hub OR AWS Trusted Advisor) owners of these mis-configured resources? 2. Even better, should aws let customers proceed if they have mis-configurations?
- throwaway984393 5y agoPolicing their customers' configurations would open them up for liability and embarrass them and their customers. But they do provide a ton of tools for customers to investigate their own security. AWS basically rents digital chainsaws. You hope they know how to use it, but you know a fair number probably don't.
- tfigment 5y ago#1 probably. #2 no. AWS is not responsible for how you setup your resources. They are very clear about that unless you use proserve or something. They are not your IT dept even for managed services.
- jamesfinlayson 5y agoAWS very much assumes you know what you're doing. Products like CloudConformity exist to let you know when you're probably misconfiguring something.
- cobookman 5y agoAWS has a product called Security Hub. There's a rule which will alert for any RDS instances open to the internet: https://docs.aws.amazon.com/securityhub/latest/userguide/securityhub-standards-fsbp-controls.html#fsbp-rds-2 https://docs.aws.amazon.com/securityhub/latest/userguide/sec...
- jeroenhd 5y agoThat sounds like an excellent subscription plan, I'm sure they sell those services already. Of course Amazon assumes that you know what you're doing, so it won't include such scans by default. If you set up a container to be world accessible, you're probably intending to do so, otherwise you wouldn't expose it like that. If you're unsure, you can always pay extra to have Amazon verify such things for you, but they're not your IT infra manager and neither should they be.
- itisit 5y agoNot really an issue as far as AWS is concerned, as they view this as on the customer as per the company's Shared Responsibility Model. [0] If you don't know how to manage infrastructure, physical or virtual, perhaps it's time to learn. And if you don't want to, you can string a bunch of SaaS solutions together and hope those companies have their act together internally. [0] https://aws.amazon.com/compliance/shared-responsibility-model/ https://aws.amazon.com/compliance/shared-responsibility-mode...
- pevey 5y agoElasticsearch until recently did not nudge you to set up a username or password by default. I noticed the last time I installed it on a fresh instance that on completion of the install it gives you a warning about this and tells you what to do to set a password. That is a small improvement. Most people would not have the service bound to a public interface, but for those who do for whatever reason have a set up where they are accessing it remotely, at least now there is a tip off that it is completely open to the world by default. This is different from pretty much any other service you might install. MariaDB for instance by default does not allow remote root login even if you change the config to bind it to 0.0.0.0. A lot of people are just totally unaware of this issue. When I read about database leakage, I generally assume 90% probability it was elastic, these days. Defaults are so important.
- jsiaajdsdaa 5y agoYikes lol. I spin up tons of self hosted mysql boxes on public IPs but never would I ever expose 3306 or allow remote root lol. I just have a thin API in Java that feeds queries into it with parameterized statements
- technion 5y agoI think people would be surprised how often it's entirely deliberate. I've had to get told "this is why we used the cloud... so dinosaur sysadmins like you wouldn't slow us down" by many different companies where I've raised this, and I've had this debate in startup communities where "just open everything up" gets defended as "agile" and "modern devops".
- KronisLV 5y ago> I've had to get told "this is why we used the cloud... so dinosaur sysadmins like you wouldn't slow us down" by many different companies where I've raised this, and I've had this debate in startup communities where "just open everything up" gets defended as "agile" and "modern devops". I guess there is some merit to the zero trust security model, since it should urge you to secure every bit of software that you run, without necessarily setting up bastion hosts/DMZs or other types of "server-based ACLs" like that: https://en.wikipedia.org/wiki/Zero_trust_security_model https://en.wikipedia.org/wiki/Zero_trust_security_model (since i've seen the fact that you have a "perimeter" get used as an excuse to get lazy about security aside from it) Yet, i've found that it's just too risky, given how brittle most of our software, including its security functionality, actually is. Just the other day i had even the simple blog software that i use (Grav) fail enforcing its admin login functionality, something that seems incredibly simple on the surface and should be bulletproof, yet somehow wasn't: https://blog.kronis.dev/everything%20is%20broken/grav-security-is-broken https://blog.kronis.dev/everything%20is%20broken/grav-securi... Thus, personally i've found that what's worthy of consideration is taking a bit from both approaches. For example, running everything in containers with overlay networks (not even dedicated service meshes necessarily, even the way how Docker Swarm does it is pretty good: https://docs.docker.com/network/network-tutorial-overlay/ https://docs.docker.com/network/network-tutorial-overlay/) that can expose your apps/web servers on every node where necessary, yet keep your DBs constrained to running inside of the overlay network and thus remain inaccessible from the outside. If and when you need to connect them, maybe run a container with SSH and WireGuard/OpenVPN that let's you forward ports and thus get access to the overlay network, or alternatively just use orchestrator functionality (for example, Kubernetes allows this, albeit i dislike its complexity otherwise) for this.
- captn3m0 5y agoWouldn’t using Shodan have been much easier? Or does Shodan not scan from within AWS?
- TheIronMark 5y agoShodan keeps a running record of what it finds on the Internet, so it's not scanning from within AWS. There are a few other services that do the same thing. I kinda like the idea of using masscan and doing the leg work yourself to get a feel for it, though.
- rbut 5y agoI’d assume a number of these would be due to the good old “docker punching a hole through UFW”, which still hasn’t been fixed.
- charcircuit 5y agoWhy would you bind to a public IP and then use a firewall when you could just not bind to a public IP in the first place?
- rbut 5y agoBecause people use docker-compose.yaml files verbatim, or copy docker run command lines, which more often than not do “-p 8000:8000”, instead of “-p 127.0.0.1:8000:8000”. Therein lies the issue.
- jeroenhd 5y agoThe general expectation when running an application is that when you misconfigure your system, the firewall will at least block incoming traffic. If I run ./program, the system will prevent me from fucking up too badly, like it should if I docker run vendor/program, that extra layer of defence is gone. Most programs still bind to 0.0.0.0 and that's not a problem if your firewall works the way you expect it to. Docker's firewall rules overriding UFW's firewall rules without notice is unexpected for many people. I know I fell for this one years ago when I first messed around with Docker, luckily I wasn't running anything important.
- spiffytech 5y ago
- ec109685 5y agoWhat’s the use case for exposing these services to anything outside a VPC? With a hardened bastion or a vpn endpoint, you can ensure only authorized users can access. A firewall rule of “any AWS IP seems horribly flawed”.
- Hikikomori 5y agoPeople that know things are unlikely to accidentally do this. Unfortunately AWS accounts come with default VPCs that only have a public subnet, so unless you know what you are doing you are likely launching all resources with a public IP and likely allowing too much in your SG.
- raverbashing 5y agoPeople are too worried about using k8s, containers and what not when they don't even know the basics of firewalls, setting basic permissions on their DBs, etc Default secure configs help a lot. But ensuring at least a basic auth system is present should be the duty of every developer/devops, etc.
- jeroenhd 5y agoI think development of easy distribution tools like Docker and K8s (well, easy once it's finally set up right…) make it a bit too easy for some developers to push stuff into production. These tools allow you to avoid the basics and go straight from local dev to production with just a few lines of YAML and a (probably pre-built) pipeline from somewhere. That's great if you're taking into account standard security configuration because you can deploy new tools instantaneously, but it's terrible if you've never thought about firewalls and ACLs before. In a world where the solution to dependency management is "ship an entire Linux install", it's become too easy to mess up. If you don't understand exactly what your magic "just make it work" tools actually do and how they modify your system configuration, you shouldn't use them to run stuff in production.
- erikbye 5y agoRelevant: buckets.grayhatwarfare.com Public, as in unsecured, not with intent.
- z3t4 5y agoSo we finally reached web X.0 where data is shared and open - we only got there accidentally