SecPro #54: Identifying Redis, testing with SonarQube, and using httpx/EyeWitness.
Tools, tools, tools – that’s all we’ve had our minds on this week. A number of tools that we’ve been testing out or using in a production environment have suitably impressed us enough to write a few articles for you, our readers. If you’re currently looking to build your own toolkit of open source tools, we hope that our walkthroughs will help you out.
The Redis Vulnerability – CVE-2022-0543
In this article we will look at how the Muhstik Malware Group exploited the Redis Vulnerability (CVE-2022-0543) to grow their botnet. Discovered by Reginaldo Silva in January 2022, the vulnerability at that point was given a Common Vulnerability Scoring System (CVSS) score of 10.0 — the highest possible rating. Soon after, both Debian & Ubuntu released patches on 18th February, prompting Debian to release Security Advisory DSA-5081-1-redis—security update on that date, with Ubuntu issuing USN-5316-1: Redis vulnerability on 8th March.
Around this same time Reginaldo Silva also released a Proof-of-Concept code which could exploit the vulnerability. Almost immediately after, Juniper Threat Labs discovered an attack beginning on 11th March being executed by the same adversaries that were targeting systems vulnerable to Log4j. With the exploit ‘in-the-wild’ the US Cybersecurity and Infrastructure Agency (CISA) added the bug to their Known Vulnerabilities Database in late March. Researchers at Rapid7 gave indication that up to 2000 internet facing Linux servers had been exploited by April 2022, although the report did also state that number was potentially upwards of 30,000. Rapid7 were to go on to detail that a Metasploit module became available on 26th April and state that “attackers will continue to opportunistically exploit this vulnerability as long as there are internet facing targets to exploit.”
Redis is the Remote Dictionary Service Server, a NoSQL open-source data structure store. Redis has gained popularity with Developers recently due to its fast performance. Using LUA, a lightweight programming language designed specifically for embedded use in applications. This documented that a remote attacker with the ability to execute arbitrary Lua scripts could escape the sandbox and executer arbitrary code on the host.
The developers did not anticipate the flaw and released the code with the intent that the Redis client would only be able to interact with the Redis APIs within the sandbox. The expected behaviour of the sandboxed Lua would be that executing arbitrary code on the machine running Redis would not be possible. By failing to sanitize the interface the developers allowed attackers to load arbitrary libraries. The module was then able to complete execution as the ‘Redis’ user.
Being presented as a dynamic library in Debian and Ubuntu packages, thereby when the Lua interpreter is initialized the package variable is automatically populated, which in turn permits arbitrary Lua access & functionality.
The versions at risk are:
- Redis versions 5:5.0.14-1+deb10u1
Identifying the Vulnerability
Only systems that are Debian, or Debian-derived are at risk.
This means that if your system is a Windows OS or does not have a Debian derivative, then your environment is not at risk. To identify if your system is vulnerable firstly you must identify the base OS that your system is running by viewing the os-release file. To view the contents of this file run the cat /etc/os-release syntax shown in fig1 below in which we can see ‘debian’ on the ID_LIKE line.
Then we need to check the version of redis using one of the two commands that are available redis-server –v or redis-server –version
As we can see from the output, the versions running on my lab machines are vulnerable to the CVE-2022-0543.
Next, lets mitigate the vulnerability by updating our source repositories followed by
the apt repository:
Lastly updating the newest version of redis using the syntax sudo apt-install redis
(ignoring author typos…)
Now let’s verify the redis version and confirm we have mitigated the risk:
CVE-2022-0543 – Identify and update summary
In summary we have learned about the vulnerability CVE-2022-0543 which can exploit the Redis Dictionary Server. We’ve discussed how this vulnerability came to be, and how it was discovered then finally how to mitigate this risk. In the last section, we will learn how the Muhstik group exploited this vulnerability.
Muhstik & Redis
Juniper Threat Labs were to report that the Muhstik group began actively exploiting the vulnerability one day after the Proof-of-Concept was released. This was done by their use of Malware to support their Denial-of-Service Attacks. The group, thought to operate from China are thought to have been involved in targeting Oracle WebLogic Server bugs, and a Drupal RCE flaw CVE-2018-7600. The payload used in the Redis attack was named russia.sh which is downloaded using curl commands or wget from their C2 Server. The script grabs variants of the bot from their IRC server which supports parsing of shell & flood commands, and SSH brute force.
IOCs & IPs
4817893f8e724cbc5186e17f46d316223b7683dcbc9643e364b5913f8d2a9197 pty1 46389c117c5f41b60e10f965b3674b3b77189b504b0aeb5c2da67adf55a7129f pty10 95d1fca8bea30d9629fdf05e6ba0fc6195eb0a86f99ea021b17cb8823db9d78b pty2 7d3855bb09f2f6111d6c71e06e1e6b06dd47b1dade49af0235b220966c2f5be3 pty3 16b4093813e2923e9ee70b888f0d50f972ac607253b00f25e4be44993d263bd2 pty4 28443c0a9bfd8a12c12a2aad3cc97d2e8998a9d8825fcf3643d46012f18713f0 pty5 36a2ac597030f3f3425153f5933adc3ca62259c35f687fde5587b8f5466d7d54 russia.sh
It is strongly advised to update and patch systems with the Redis Server. Both Debian and Ubuntu have released security advisories. Patching and advisories are referenced in this article to assist you identify, and update your system if necessary.
Using httpx and EyeWitness
By Indrajeet Bhuyan
In my previous articles, I have talked about different tools which will help you find more flaws in the target website. Today in this article we will explore not one but two tools. Both the tools will help us increase our attack surface and also do things fast.
Often when we do bug bounty or external pentesting, we get our scope something like this: *.example.com. What this means is that all the subdomains under example.com are valid for the scope.
Here is the bugcrowd page of tesla and as you can see in the scope they have mentioned *.tesla.com which means that as a bug hunter we can find flaws in any of their subdomain and report. Whenever we see something like this, we start looking for subdomains of the website using tools like assetfinder, sublist3r, crt.sh, etc. These tools do a great job of finding most of the subdomains.
Want to find out how Indrajeet uses httpx and Eyewitness? Click the link to find out!
Beginners guide to Static Application Security Testing (SAST) using SonarQube
By Sai Adithya Thatipalli
In today’s modern world, Web applications have become part of every business and play a key role in their operations. Many businesses are hosting their applications with the help of Cloud Infrastructure making the Application development process more crucial.
The more complex and dynamic we create applications, the more secure the application should be. Since the rise of SaaS applications, user data stored by these applications are also important. To maintain that application should be testing from a security point of view along with the functional testing.
How to perform SAST using SonarQube
SonarQube is an automatic code review tool to detect bugs, vulnerabilities in your Application packages. It can integrate with your existing project life cycle or in your CI/CD if it’s a DevOps cycle.
SonarQube is a web console managed tool which can be run from a standalone machine or from a docker.
Interested in how Sai uses SonarQube for testing? Click here to find out more!
This Week’s Tutorials & Explainers
Can Cloud-Native platforms really aid security professionals? Gartner thinks so, so we did some investigating. Click the link to read the article!
No news is good news, but we’ve rounded up the big events of the last week to send to you anyway. Check out the new framework for IoT devices from Carnegie Mellon.
Secret Knowledge: Building Your Security Arsenal
Here’s another edition of Secret Knowledge, with plenty of tools to help you test and secure your infrastructure systems. All tools are chosen by our crack team of researchers on the most important metric of all – sounding a bit interesting.
- cloudflare/flan: Flan Scan is a lightweight network vulnerability scanner.
- almandin/fuxploider: File upload vulnerability scanner and exploitation tool.
- OWASP/joomscan: OWASP Joomla Vulnerability Scanner Project
- arminc/clair-scanner: Docker containers vulnerability scan
- flipkart-incubator/Astra: Automated Security Testing For REST API’s
- wpscanteam/wpscan: WPScan WordPress security scanner. Written for security professionals and blog maintainers to test the security of their WordPress websites.
- cdk-team/CDK: CDK is an open-sourced container penetration toolkit, designed for offering stable exploitation in different slimmed containers without any OS dependency.
- inspec/inspec: Chef InSpec is an open-source testing framework for infrastructure with a human- and machine-readable language for specifying compliance, security and policy requirements.
- marco-lancini/goscan: GoScan is an interactive network scanner client, featuring auto-completion, which provides abstraction and automation over nmap.
- takuzoo3868/penta: Open-source all-in-one CLI tool to semi-automate pentesting.