Feline Hackers Among Us? (A Deep Dive and Simulation of the Meow Attack)

Introduction

In the perpetually evolving field of cybersecurity, new threats materialize daily. Attackers are on the prowl for weaknesses in infrastructure and software like a cat eyeing its helpless prey.

One of the more peculiar and distressing incidents in recent history was the so-called “Meow” attack, where hackers (clearly not content with just knocking over glasses of water) determined it was a great idea to target and wreak havoc on unsecured databases such as Elasticsearch and MongoDB just for the fun of it. While most compromises occur to either steal money or valuable data that can be turned into cash, the Meow attack exists simply to destroy data and cause a massive headache for the victims.

We will look into the nature of these attacks, the security issuesthat were exploited (like leaving the door open for a cat to sneak in), its current state in mid-2024 (a "purr-sistent" problem), the total anarchy unleashed on affected organizations, and the costly lessons learned from these feline-inspired attacks. Alright, enough of the cat puns; let’s take a deep dive into the vulnerability details of the Meow attack.

Vulnerability Details

The primary targets of the Meow attacks were Elasticsearch and MongoDB. Elasticsearch is a search and analytics engine built on the Apache Lucene library and is widely used for log and event data analysis, text search, and data storage. It stores data as documents in the JSON format and organizes them into indices, which enables fast, full-text searches.

Elasticsearch uses an inverted index that maps terms to document locations, allowing for a more efficient query retrieval as well as powerful real-time data analysis across multiple nodes. On the other hand, MongoDB is a NoSQL database that stores data in flexible JSON-like documents within collections. It uses a schema-less model that allows dynamic document structures and is widely known for its ease of use, scalability, and flexibility. Queries are created via the BSON (binary JSON) format, and data is indexed for efficient retrieval.

MongoDB is ideal for handling large datasets and supports high availability and horizontal scaling. Elasticsearch and MongoDB are both open-source databases well known for being utilized by organizations worldwide for a variety of applications. Nevertheless, their prevalence and widespread usage also made them prime targets for the Meow attack.

A large part of how immensely widespread this attack was can be attributed to its automation. The Meow attack was automated to swiftly scan the internet and find targets with exposed and vulnerable databases (either with flawed configurations and/or default or sometimes non-existent credentials). The attackers typically targeted configuration failures like default or non-existent credentials left in place as opposed to specific vulnerability exploits.

From there, data can be maliciously overwritten and modified to the attacker’s whim. The one unique aspect of the Meow attack was its destructive nature. Typically, attackers that have a hold on an organization’s data will demand a ransom (e.g., ransomware attacks) to retrieve and/or recover the held-up data. However, the Meow attack actors do not make such demands and proceed with the attack without any communication with the victimized organization.

There is no concrete evidence that the attackers take a copy of the data before corrupting them. However, there is a possibility that they did so in some cases. In addition, attacks were conducted without prejudice to the target's size or type. This means, the attackers targeted both Enterprise sized organizations and SMB sized companies alike. .

There is no definitive public information about the specific weaknesses exploited by these attackers. Understandably so, as the apathetic approach to database security by many may cause sentiments of distrust towards affected organizations.

The most probable vulnerabilities exploited by the Meow attack were presumed to be open ports and default configurations. If ports for databases such as Elasticsearch and MongoDB were open to the internet to be probed and enumerated, then attackers will have a field day extracting critical information to aid their attacks. In some versions of Elasticsearch and MongoDB, the default configurations would not require authentication for access. Therefore, databases that were exposed to the internet would enable literally anybody access to them without needing a username or password.

Exploit Demo via Docker

Docker is used by cybersecurity teams to test vulnerabilities by creating isolated, reproducible environments. It allows security professionals to simulate attacks, run exploits, and analyze responses without affecting the host system. Docker's containerization ensures consistent testing conditions, making identifying, assessing, and mitigating security flaws easier.

Docker can be used to carry out experiments, allowing cybersecurity professionals to have first-hand experience conducting this attack. The goal is to pull an older (probably vulnerable) version of MongoDB and set up the environment so that a Meow attack would be made possible.

In this example, as shown in Figures 1 and 2, a relatively older version of MongoDB was pulled, as it may have a higher probability of being susceptible to the Meow attack. In this particular case, the Docker image was pulled from the official MongoDB registry to ensure reliability.

Figure 1. A relatively old version of a MongoDB Docker image is pulled.

Figure 2. The 'docker images' command is executed to confirm pulled images.

The 'docker run' command is then executed on this pulled Docker image to enable the MongoDB instance to start. As shown in Figure 3, the flags include '-it' and '-p'.

The '-it' flag is the combination of two flags, which are, '-i' and '-t', respectively. The '-i' flag enables users to interact with the container's processes, while the '-t' flag makes the container's output more readable and allows for features including command-line editing and history. When combined, it provides an interactive shell session where users can run commands as if they were directly logged into the container.

The '-p' flag allows the mapping of ports between the Docker container and the host machine. It specifically sets which port of the container should be exposed and which port of the host should receive traffic. This flag’s syntax is as follow: `p [host_port]:[container_port]`. Therefore, this allows external access to the container's services.

Figure 3. The 'docker run' command is executed to start the MongoDB Docker instance.

Before going further with the running MongoDB Docker instance, we need sample data upon which we will simulate the Meow attack. A simple search on Google for a sample CSV file will lead to a GitHub page by RobVanGroenewoud with a small CSV dataset that we can work with. The contents of this CSV file are shown in Figure 4. A copy of this file will be required on the host machine to conduct the simulation. Using the `wget` command, the CSV file is then downloaded into the host machine and its contents are displayed as shown in Figures 5 and 6, respectively.

Figure 4. The 'sample.csv' file used for the exploit.

Figure 5. Using the 'wget' command to download the 'sample.csv' file into the host machine.

Figure 6. Using the 'cat' command to ensure the output of the 'sample.csv' file contents.

The 'mongoimport' tool can import content from TSV, CSV, an Extended JSON export created by mongoexport, or from an external source. In this case, it is the latter. As shown in Figure 7, this tool is executed to create a database (e.g. 'mydatabase') and then create a collection (e.g. my_collection) which is populated with the contents of the 'sample.csv'.

Figure 7. The 'mongodbimport' tool is executed successfully.

The attack simulation is halfway there. Before proceeding any further, it is best to confirm that everything is in place within the MongoDB Docker instance. First, the `docker exec` command was used to access the MongoDB CLI (Figure 8). Then, the `show dbs` command is executed to ensure that the database for the attack has been successfully created (Figure 9). After that, we execute the `use my_database` command to switch the context to the database created for this attack (Figure 10). Then, we execute the `show collections` command to ensure the collection has been successfully created (Figure 11). Finally, the `db.my_collection.find().pretty()` command is executed to retrieve the contents of the specified collection (my_collection) and ensure the CSV file contents were successfully imported (Figure 12). As shown in Figures 8 to 12, everything is in place regarding the target setup.

Figure 8. The 'docker exec' command is executed with the 'mongo' command to access the MongoDB CLI.

Figure 9. The 'show dbs' command is executed in MongoDB CLI.

Figure 10. The 'use my_database' command is executed in MongoDB CLI.

Figure 11. The 'show collections' command is executed in MongoDB CLI.

Figure 12. The 'db.my_collection.find().pretty()' command is executed in MongoDB CLI.

The next component of this simulation is the exploit, which will be a Python script. In summary, the Python script in Figure 13 is designed such that the target MongoDB client is accessed without authentication on the MongoDB default port of 27017, and then only the non-default databases (e.g. my_database) are processed further while ignoring default system databases 'admin,' 'local,' and 'config.' The non-default database lists and processes its collections (e.g. mycollection) . Then, the collection keys are left intact while it modifies the collection values (specifically strings and integers) by replacing half of the string characters with 10 random alphanumeric characters and replaces the other half with the string 'MEOW.' Based on research, this is the exact pattern observed by those affected by the Meow attack.

Figure 13. Python Exploit for the Meow attack.

Now that the Docker setup and the Python exploit script are ready, the attack can now be conducted. As shown in Figure 14, the Python script has been executed successfully without any errors.

Figure 14. Python Exploit has been executed.

To confirm the attack was successful, the MongoDB CLI is once again used to execute the `db.my_collection.find().pretty()` command.. As shown in Figure 15, the Meow attack was successful and replaced the data with random alphanumeric characters and with "-MEOW" appended to it.

Figure 15. Attack simulation is successful.

The Current State of the Meow Attack After Four Years (Shodan)

Shodan is a search engine that indexes exposed devices and systems. It is primarily used for discovering internet-connected devices and systems, including servers, webcams, routers, industrial control systems, and many more. It enables security professionals to assess potential risks and vulnerabilities by providing insights into exposed, vulnerable, or misconfigured devices by scanning the web for publicly accessible IP addresses. In this particular case, Shodan will be used to find out precisely how pervasive the Meow attack is in mid-2024 (specifically Elasticsearch and MongoDB targets).

The query `meow indices` is searched to find the number of targets using Elasticsearch affected by the Meow attack, . Figures 16 to 20 are all interesting statistics provided by Shodan. In summary, 13 targets were affected and were mostly from the United States. There were also single entries each from China, the United Kingdom, and Sweden. In addition, all 13 were found to have Elasticsearch, so there were no false positives. Moreover, they were all labeled as “compromised” and “databases.” Finally, Figure 21 is an example of a single Elasticsearch target affected by the Meow attack with its data corrupted by 10 random alphanumeric characters appended with '-meow'.

Figure 16. Shodan search for 'meow indices'.

Figure 17. Country map of affected Elasticsearch targets.

Figure 18. Country list of affected Elasticsearch targets.

Figure 19. All 13 targets have Elasticsearch installed.

Figure 20. Shodan tags of the affected Elasticsearch targets.

Figure 21. Sample of an Elasticsearch target affected by Meow attack.

On the other hand, to find out the number of targets using MongoDB affected by the Meow attack, the query `meow port:27017` is searched. Figures 22 to 26 are all interesting statistics provided by Shodan.

In summary, 89 targets were affected and were mostly from the United States while some were from China, Japan, France, and the United Kingdom. In addition, all 89 were found to have MongoDB, so there were no false positives. Moreover, they were all labeled as “compromised” and have an End-of-Life product (probably MongoDB). Finally, Figure 27 is an example of a single MongoDB target affected by the Meow attack with its data corrupted by 10 random alphanumeric characters appended with '-meow'.

Figure 22. Shodan search for 'meow port: 27017'.

Figure 23. Country map of affected MongoDB targets.

Figure 24. Country list of affected MongoDB targets.

Figure 25. All 89 targets have MongoDB installed.

Figure 26. Shodan tags of the affected MongoDB targets.

Figure 27. Sample of a MongoDB target affected by Meow attack.

As of the date of writing this article, it has been a little more than four years since the inception of the Meow attack. To the credit of many organizations and security professionals, the number of Meow attacks has fallen below the 4,000 attack mark it was at its apex in 2020. However, despite the advancement of database technology and security over the past years, Meow attacks still persist.

Conclusion

The crux of the Meow attack all boils down to misconfiguration. Whenever databases such as Elasticsearch, MongoDB, and others are left without authentication or proper access controls, attackers may easily locate and exploit them. Security professionals should be swift to address such issues due to the potentially high negative impact it can have on an organization. This is especially true if the affected product is a database that holds sensitive data. One example of such data might be personally identifiable information (PII), which may lead to privacy invasion, fraud, or identity theft. Another example of sensitive data that might be exposed are corporate intellectual property, which can lead to the loss of competitive advantage and financial damage.

Trustwave's dbProtect and AppDetectivePro products address the aforementioned vulnerabilities such as the detection of potential misconfigurations in user authentication, alert for discovered default settings (e.g. port, access credentials), and verification of latest patch or product version installation. To deliver the most recent protection available, Trustwave SpiderLabs security researchers constantly scan the web for fresh vulnerabilities and updates that fix them, if they exist. We then incorporate these updates into our solutions.