We use cookies to ensure you get the best experience on our website.Read moreRead moreGot it

close
  • Products
    • Products
      • Snyk Open Source
        Avoid vulnerable dependencies
      • Snyk Code
        Secure your code as it’s written
      • Snyk Container
        Keep your base images secure
      • Snyk Infrastructure as Code
        Fix misconfigurations in the cloud
    • Platform
      • What is Snyk?
        See Snyk’s developer-first security platform in action
      • Developer Security Platform
        Secure all the components of the modern cloud native application in a single platform
      • Security Intelligence
        Access our comprehensive vulnerability data to help your own security systems
      • License Compliance Management
        Manage open source license usage in your projects
    • Self-paced security education with Snyk Learn
  • Resources
    • Using Snyk
      • Documentation
      • Vulnerability intelligence
      • Product training
      • Customer success
      • Support portal & FAQ’s
    • learn & connect
      • Blog
      • Community
      • Events & webinars
      • DevSecOps hub
      • Developer & security resources
    • Self-paced security education with Snyk Learn
  • Company
    • About Snyk
    • Customers
    • Partners
    • Newsroom
    • Snyk Impact
    • Contact us
    • Jobs at Snyk We are hiring
  • Pricing
Log inBook a demoSign up
All articles
  • Application Security
  • Cloud Native Security
  • DevSecOps
  • Engineering
  • Partners
  • Snyk Team
  • Show more
    • Vulnerabilities
    • Product
    • Ecosystems
https://res.cloudinary.com/snyk/image/upload/v1645713086/snyk-marketingwp/snyk-default-blog-hero.jpg
VulnerabilitiesDevSecOps

The MongoDB hack and the importance of secure defaults

Tim Kadlec
Tim KadlecJanuary 10, 2017

If you have a MongoDB installation, now would be the time to verify that it is secure. Since just before Christmas, over 28,000 public MongoDB installs have been hacked. The attackers are holding the hacked data ransom, demanding companies pay using Bitcoins to get their data back. From the looks of it, at least 20 companies have given in and paid the ransom so far. This post explains the hack, how to protect yourself, and what we can learn from it.

Understanding the hack

The hack itself is alarmingly simple. In versions >= 2.6.0, MongoDB includes a default configuration file that binds MongoDB to 127.0.0.1 by default. As a result, the database will only listen to local connections.

Before version 2.6.0, that wasn’t true. By default, MongoDB was left open to remote connections. Authentication is also not required by default, which means that out of the box installs of MongoDB before version 2.6.0 happily accept unauthenticated remote connections.

Users could still restrict access to local connections if they took the time to configure the install but that meant manually adding a line to their mongodb.conf file. Since that wasn’t the default configuration, many existing installs never included this critical step.

Making matters worse is that it’s easy to identify potential MongoDB attack candidates. MongoDB’s default port is 27017. Using a search engine such as ZoomEye, you can query for MongoDB installs, see what port they’re available over, and find around 100,000 vulnerable candidates.

The vulnerability itself is hardly new. The issue was first raised back in 2012 and released somewhere around 2015. Also, in early 2015, John Matherly made some noise when he reported finding around 30,000 insecure installs of MongoDB. In other words, this is something that everyone could have known about for a while.

The trouble with insecure defaults

The lack of insecure defaults is no minor issue. Study after study after study has shown that most people stick to the defaults a system presents to them. Defaults matter.

Now, some folks might argue that some of these insecure defaults are an attempt to balance usability and security, and that they are based on reasonable assumptions. If you can safely assume a database will be installed behind a firewall in the vast majority of cases, for example, then you may decide that not binding a database to local connections would be a reasonable default.

But assumptions like that are dangerous because when not if someone does something that breaks that assumption, they’re now vulnerable to attacks—and they may not even know it. Understanding of the potential security risks presented by these defaults is not exactly mainstream knowledge. Unless a company has security experts in place reviewing each decision (a good idea, but not a given), these insecure defaults can—an often do—remain overlooked.

Test your application for known vulnerabilities

 

By submitting this form you consent to us emailing you occasionally about our products and services.
You can unsubscribe from emails at any time, and we will never pass your email onto third parties. Privacy Policy

Tracking insecure defaults

The trouble with insecure defaults gets worse.

Let’s say you’re a responsible organization and use a tool, like Snyk, to scan your tools and dependencies for vulnerabilities. Those tools won’t report this issue because insecure defaults are typically not considered vulnerabilities. This is because the issue itself here isn’t a bug or vulnerability in the code itself—it’s a configuration issue.

It makes sense, to an extent, but it does raise the question: should there be an official identifier and database for insecure defaults?

On the one hand, a service reporting insecure defaults would undoubtedly produce some noise. There are a lot of insecure defaults and some organizations will have already addressed them. These organizations would need to determine if the issue still applies to them, which isn’t always a simple task. If it doesn’t, they could safely ignore the issue and move on.

But reporting insecure defaults could be invaluable for those users who haven’t already identified these concerns. For them, it may alert them to security risks that would otherwise remain unnoticed and untouched—potentially (as in the case of the MongoDB issue) for years.

Flagging known insecure defaults in an open-source database (the same way we flag known vulnerabilities) would not have stopped this attack, but it could have prevented at least some of the databases from being affected.

So what happens next?

First of all, go secure your MongoDB installation. We’ll wait.

Now that you’re back, what this hack demonstrates is the massive importance of secure defaults. Security is too important to leave to chance. Just as the industry has been shifting to accept that sites should be served over HTTPS by default, package authors should be doing their best to ensure that their packages are secure by default. An insecure default setting can result in just as much damage as a known vulnerability. While it’s understandable that developers of these tools want to default to an install with the least amount of friction, the danger is that if that default is also insecure, we end up with situations like the one people are dealing with now for MongoDB.

The other question these attacks pose is whether it’s time to start tracking insecure defaults in an open-source database. At Snyk, we repeatedly discuss whether we should mark such flaws as vulnerabilities or not, and we will probably continue that conversation for a long while. If you have a strong opinion either way, do let us know—either by email or on Twitter. In the meantime, if you want to find out if your dependencies hold any security surprises, test your repos quickly using Snyk.

Log4Shell resource center

We’ve created an extensive library of Log4Shell resources to help you understand, find and fix this Log4j vulnerability.

Browse Resources
Footer Wave Top
Patch Logo SegmentPatch Logo SegmentPatch Logo SegmentPatch Logo SegmentPatch Logo SegmentPatch Logo SegmentPatch Logo SegmentPatch Logo SegmentPatch Logo SegmentPatch Logo SegmentPatch Logo SegmentPatch Logo SegmentPatch Logo Segment
Develop Fast.
Stay Secure.
Snyk|Open Source Security Platform
Sign up for freeBook a demo

Product

  • Developers & DevOps
  • Vulnerability database
  • Pricing
  • Test with GitHub
  • API status
  • IDE plugins
  • What is Snyk?

Resources

  • Snyk Learn
  • Blog
  • Security fundamentals
  • Resources for security leaders
  • Documentation
  • Snyk API
  • Disclosed vulnerabilities
  • Open Source Advisor
  • FAQs
  • Website scanner
  • Japanese site
  • Audit services
  • Web stories

Company

  • About
  • Snyk Impact
  • Customers
  • Jobs at Snyk
  • Snyk for government
  • Legal terms
  • Privacy
  • Press kit
  • Events
  • Security and trust
  • Do not sell my personal information

Connect

  • Book a demo
  • Contact us
  • Support
  • Report a new vuln

Security

  • JavaScript Security
  • Container Security
  • Kubernetes Security
  • Application Security
  • Open Source Security
  • Cloud Security
  • Secure SDLC
  • Cloud Native Security
  • Secure coding
  • Python Code Examples
  • JavaScript Code Examples
Snyk|Open Source Security Platform

Snyk is a developer security platform. Integrating directly into development tools, workflows, and automation pipelines, Snyk makes it easy for teams to find, prioritize, and fix security vulnerabilities in code, dependencies, containers, and infrastructure as code. Supported by industry-leading application and security intelligence, Snyk puts security expertise in any developer's toolkit.

Resources

  • Snyk Learn
  • Blog
  • Security fundamentals
  • Resources for security leaders
  • Documentation
  • Snyk API
  • Disclosed vulnerabilities
  • Open Source Advisor
  • FAQs
  • Website scanner
  • Japanese site
  • Audit services
  • Web stories

Track our development

© 2022 Snyk Limited
Registered in England and Wales
Company number: 09677925
Registered address: Highlands House, Basingstoke Road, Spencers Wood, Reading, Berkshire, RG7 1NT.
Footer Wave Bottom