Downclimb

2017.01.15

RSS feed

Weekly infosec news summary for 2017.01.08 – 2017.01.15

Quotes

“Remember: no matter what happens today, you’ll look back at it as a time when finding and exploiting bugs was way easier” Natalie Silvanovich

 

“I just wish we had more infosec firefighters, rather than so many standing around with lighters, helpfully pointing out flammables.” Wendy Nather

 

Top stories

MongoDB ransomware and the deficiencies of IaaS

News this week came out that there is MongoDB ransomware going after all the exposed MongoDB instances that don’t have any authentication in front of them (link). This “ransomware” is just deleting the data so even if the victims pay the “ransom”, they can’t recover their data. So far 29K databases are believed to have been attacked of a possible 52K exposed instances. This same story played out in August for exposed Redis instances as covered by Duo (link), and a similar situation is now occurring for ElasticSearch instances (link).

Attacks on Redis, MongoDB, ElasticSearch, and other services that install without default authentication have been happening for years. By and large many blame either the users (they need to “RTFM”) or the application creators (MongoDB needs to ensure authentication is always used). I believe however that the IaaS providers (ex. Amazon Web Services) are most to blame by making it much more complicated than it should be to setup a secure network architecture. Many project put in the cloud involves a front-end service that is exposed to the Internet and one or more back-end services such as MongoDB that should not be. Developing this locally on a laptop is likely to not expose that MongoDB instance, but in order to move this setup to AWS in a secure manner, you need to understand and setup a VPN, proxy, VPCs, and Security Groups. AWS offers dozens of cloud services, none of which is a VPN or proxy, but everyone using AWS in a secure manner has to set these up.

We can see in Shodan where the IP space is that the exposed MongoDB instances are (report link):

Exposed MongoDB instances

Exposed MongoDB instances

This graph shows that AWS hosts many of the exposed MongoDB instances, which is really just representative of how many people use AWS over other services. For everyone that uses any IaaS provider, some percentage will expose their backend services to the Internet. Similar graphs can be obtained for ElasticSearch, Redis, or any other database such as MySQL, PostgreSQL, SQL server, etc. Even if your database uses authentication, it should not be exposed to the Internet.

Infosec rule: No service that has the potential to use less than 128-bits of entropy for its authentication should be exposed to the Internet without rate-limiting or 2FA.

You can make the ballpark assumption that most logins can handle about 100 attempts per second which is 3B attempts per year. This is on the order of magnitude of every 7 character lowercase password combination, or about 32-bits of entropy. There are two additional important rules of infosec:

  • For any service that allows users to create their own password without complexity rules, some (very large) percentage of them will choose weak passwords, and even if there are complexity rules, some percentage will choose a common password that manages to bypass the rules (ex. P@assw0rd).
  • Shared passwords will always be managed poorly (ie. it will not be rolled when it should be).

The means that either one of your coworkers will choose a bad password for their account, or if you have a single account that you share and you generate a secure password for it, it will be exposed somehow and not rolled. Some might assume that they would detect if 100 login attempts per second were being tried against their server for a full year, but the people that expose databases to the Internet are not the people who would detect this.

So the results of all this is you should never expose a database or any other backend service, even if it uses authentication, to the Internet. Some of you may find this obvious, but clearly there are a vast number who do not or do not know how to avoid this. Some have said these aren’t “real” businesses exposing MongoDB, and are likely just people experimenting with the cloud, but I’ve never heard of anyone using IBM SoftLayer to experiment, and there are a thousand exposed instances there.

You may think they should better understand what they are doing before they host services in the cloud, but again, I assure you that even those that know what they are doing make mistakes. We can look back at the story of Instagram’s Million Dollar Bug Bounty where they exposed their Sensu instance to the Internet. They should know better and they likely do, but it happened, and here’s a dirty secret: Every company that uses cloud hosting has exposed a server to the Internet that they shouldn’t have at some point. Further, in this case, the attacker (the bug bounty researcher) used an RCE vuln to bypass the authentication, but once in, he discovered that 6 of the passwords were “changeme”, 3 were the same as the user’s name, 2 were “password”, and 1 was “instagram”. These could have been quickly brute-forced to gain access without the RCE vuln, so again, never expose a back-end service to the Internet because even if they have authentication, they aren’t made to handle the persistent attempts of attackers. Within your network, this authentication buys you time if an adversary gets inside. Do not expect it to do more.

My ask to IaaS providers is they look at the current percentage of the market share they have (X), and the current percentage of exposed back-end services they host (Y). I suspect X and Y are the same for every IaaS provider. They should look for ways to reduce the number of exposed back-end services they host, such that their success criteria is a reduction of Y/X, enabling them to advertise the claim that they are the safest IaaS provider because the number of customers that get hacked while using their services is going to be greatly reduced.

Business

Tools

Other reads

  • The EyePyramid attacks: Two Italians were arrested for hacking high-profile politicians, bankers, lawyers and more. The attacks have been going on since 2010. The attacks involved spear-phishing, were relatively unsophisticated, and the attackers used poor opsec, using IP addresses associated with their company in the attacks. However, it is interesting because it had success, and the attackers were going after people in their own country who likely have security teams to protect them and investigate attacks. This gives evidence of the unfortunate asymmetry facing many defenders today, where attackers have it easier than the defenders do.
  • Command execution on Ansible controller from host: Ansible had a series of vulns allowing you to take over the Ansible controller. This means that for networks that use Ansible for IT automation, if you take over one host, you can take over the Ansible controller which would then allow you to take over all hosts. From the researchers, “The handling of Facts in Ansible suffers from too many special cases that allow for the bypassing of filtering. We found these issues in just hours of code review, which can be interpreted as a sign of very poor security.”
  • Hacker Steals 900 GB of Cellebrite Data: The company Cellebrite provides forensics services for mobile phones, and gained fame for being suspected as the company that enabled the FBI to get access to the San Bernardino shooter’s encrypted iPhone. Cellebrite’s backups were compromised by a hacker. You have to protect your backups at the same level of protection as the original data. To properly encrypt your backups, see my post Creating Disaster Recovery backups.
  • Second Wave of Shamoon 2 Attacks Identified: Palo Alto networks describes the most recent Shamoon attacks which wipe all the data on computers. It’s interesting because it contains 16 account credentials that are specific to the organization that was attacked to enable the malware to spread before the date it was set to perform its destructive actions. This means that the attackers had done recon work prior to sending in this malware.
  • Iran Leaks Censorship via BGP Hijacks: This article describes how nations use BGP hijacks to block sites.
  • Summary of the latest ShadowBrokers release: Matt Suiche explores the latest ShadowBroker dump of EquationGroup files which were Windows binaries this time.
  • The line of death: Eric Law explains the UI side of security by pointing out the visual areas of applications that can potentially become attacker controlled.