Trustwave SpiderLabs Uncovers Unique Cybersecurity Risks in Today's Tech Landscape. Learn More

Trustwave SpiderLabs Uncovers Unique Cybersecurity Risks in Today's Tech Landscape. Learn More

Services
Capture
Managed Detection & Response

Eliminate active threats with 24/7 threat detection, investigation, and response.

twi-managed-portal-color
Co-Managed SOC (SIEM)

Maximize your SIEM investment, stop alert fatigue, and enhance your team with hybrid security operations support.

twi-briefcase-color-svg
Advisory & Diagnostics

Advance your cybersecurity program and get expert guidance where you need it most.

tw-laptop-data
Penetration Testing

Test your physical locations and IT infrastructure to shore up weaknesses before exploitation.

twi-database-color-svg
Database Security

Prevent unauthorized access and exceed compliance requirements.

twi-email-color-svg
Email Security

Stop email threats others miss and secure your organization against the #1 ransomware attack vector.

tw-officer
Digital Forensics & Incident Response

Prepare for the inevitable with 24/7 global breach response in-region and available on-site.

tw-network
Firewall & Technology Management

Mitigate risk of a cyberattack with 24/7 incident and health monitoring and the latest threat intelligence.

Solutions
BY TOPIC
Microsoft Exchange Server Attacks
Stay protected against emerging threats
Rapidly Secure New Environments
Security for rapid response situations
Securing the Cloud
Safely navigate and stay protected
Securing the IoT Landscape
Test, monitor and secure network objects
Why Trustwave
About Us
Awards and Accolades
Trustwave SpiderLabs Team
Trustwave Fusion Security Operations Platform
Trustwave Security Colony
Partners
Technology Alliance Partners
Key alliances who align and support our ecosystem of security offerings
Trustwave PartnerOne Program
Join forces with Trustwave to protect against the most advance cybersecurity threats
SpiderLabs Blog

Protecting Yourself from MongoDB Ransomware

In the realm of malware, ransomware has been king for the last few years, compromising unsecured hosts and kindly requesting payment from their rightful owners. Back in January 2017, an attacker extended the concept to MongoDB and was hitting unsecured servers and demanding bitcoin ransom to return the compromised data. By leveraging unauthenticated access, this attacker could gain control over sensitive data, export it to his domain, and leave a database/collection of his own explaining to the owners what he had done. Owners of these MongoDB installations were then forced to pay up or lose their data forever.

It's not really clear why so many MongoDB databases in use today are left unsecured and publicly accessible. Are admins lazy? Do they not follow the Security Checklist that is published by MongoDB? The number is staggering. In 2015 a Shodan search revealed at least 35,000 unsecured, publicly internet facing instances of MongoDB were. Today, in 2017, that number is predicted to grow over 90,000.

Running a business around a database environment that isn't secured is like playing Russian roulette. In this roulette game, with each click of the trigger, you may end up bringing your operation to a standstill, potentially losing out on crucial revenue needed to keep commerce going. When it comes to MongoDB, if you follow a few simple steps, you can ensure that your database has some basic protections.

MongoDB is a NoSQL database built on an architecture of collections and documents, as opposed to the standard rows and tables commonly found in more 'traditional' database formats. Configuring MongoDB is easy, by altering the YAML-based configuration file, mongod.conf, you can set certain reserved parameters to values that will ultimately secure the database instance.

NOTE: Although these parameters can be used in conjunction with others to provide a more astute database environment, here they are meant for single, non-sharded database instances.

Those parameters are:

authorization: true

When this parameter is set, the default authentication mechanism is SCRAM-SHA-1 which verifies the username and password to what is included within the authentication database. The authentication database is whichever database the user was created in.

What does this mean? By enabling the authorization parameter, you will need a user and password to connect to that MongoDB database. Simple, huh?

There is a caveat to this, you must create an admin/superuser account to administer user/role access BEFORE setting the authorization parameter. MongoDB, by default, doesn't create this account leaving it the number one thing an attacker will do when compromising your unsecured database. To create this account, follow the steps here.

 

port: <non-default port>

The default port for MongoDB is 27017. By changing this port, it makes it a bit more difficult for attackers to find the database.

 

bindIp: <comma separated IP addresses>

This parameter allows you to explicitly bind certain IP addresses to listen for connections from incoming applications. By binding MongoDB to only the appropriate network interface, you may be able to prevent the database from accidentally listening for connections on a publicly exposed address.

Along with applying certain parameters to the configuration file, you can also go one step further with enabling role-based access. By creating roles and assigning them certain aspects of database administration/access, you are establishing another layer of security.

To read more about RBAC (Role-based Access Control), please check out the MongoDB documentation.

In addition to these suggestions, as mentioned before, MongoDB publishes a Security Checklist. This checklist goes beyond what is mentioned here and helps to paint a complete security footprint for securing your MongoDB database. As a database security professional, I encourage you to evaluate your security posture when it comes to databases and ensure that you are protected from outside (and inside) attacks. In addition to this Checklist, Trustwave has tools available that will perform the compliance scanning and present the level of security to you. By following a few simple procedures, you are saving yourself countless hours of unneeded work and saving your organization revenue in the end.

 

Latest SpiderLabs Blogs

Why We Should Probably Stop Visually Verifying Checksums

Hello there! Thanks for stopping by. Let me get straight into it and start things off with what a checksum is to be inclusive of all audiences here, from Wikipedia [1]:

Read More

Agent Tesla's New Ride: The Rise of a Novel Loader

Malware loaders, critical for deploying malware, enable threat actors to deliver and execute malicious payloads, facilitating criminal activities like data theft and ransomware. Utilizing advanced...

Read More

Evaluating Your Security Posture: Security Assessment Basics

This is Part 4 in my ongoing project to cover 30 cybersecurity topics in 30 weekly blog posts. The full series can be found here.

Read More