SAP Host Agent, SAP NetWeaver and ABAP Platform allow an attacker to leverage logical errors in memory management to cause a memory corruption.

CVE-2022-29616

Europe’s proposed child protection laws could undermine end-to-end encryption for billions of people.

All of your WhatsApp photos, iMessage texts, and Snapchat videos could be scanned to check for child sexual abuse images and videos under newly proposed European rules. The plans, experts warn, may undermine the end-to-end encryption that protects billions of messages sent every day and hamper people’s online privacy.

The European Commission today revealed long-awaited proposals aimed at tackling the huge volumes of child sexual abuse material, also known as CSAM, uploaded to the web each year. The proposed law creates a new EU Centre to deal with child abuse content and introduces obligations for tech companies to “detect, report, block and remove” CSAM from their platforms. The law, announced by Europe’s commissioner for home affairs, Ylva Johansson, says tech companies have failed to voluntarily remove abuse content, and it has been welcomed by child protection and safety groups.

Under the plans, tech companies—ranging from web hosting services to messaging platforms—can be ordered to “detect” both new and previously discovered CSAM, as well as potential instances of “grooming.” The detection could take place in chat messages, files uploaded to online services, or on websites that host abusive material. The plans echo an effort by Apple last year to scan photos on people’s iPhones for abusive content before it was uploaded to iCloud. Apple paused its efforts after a widespread backlash.

If passed, the European legislation would require tech companies to conduct risk assessments for their services to assess the levels of CSAM on their platforms and their existing prevention measures. If necessary, regulators or courts may then issue “detection orders” that say tech companies must start “installing and operating technologies” to detect CSAM. These detection orders would be issued for specific periods of time. The draft legislation doesn’t specify what technologies must be installed or how they will operate—these will be vetted by the new EU Centre—but says they should be used even when end-to-end encryption is in place.

The European proposal to scan people’s messages has been met with frustration from civil rights groups and security experts, who say it’s likely to undermine the end-to-end encryption that’s become the default on messaging apps such as iMessage, WhatsApp, and Signal. “Incredibly disappointing to see a proposed EU regulation on the internet fail to protect end-to-end encryption,” WhatsApp head Will Cathcart tweeted. “This proposal would force companies to scan every person's messages and put EU citizens' privacy and security at serious risk.” Any system that weakens end-to-end encryption could be abused or expanded to look for other types of content, researchers say.

“You either have E2EE or you don’t,” says Alan Woodward, a cybersecurity professor from the University of Surrey. End-to-end encryption protects people’s privacy and security by ensuring that only the sender and receiver of messages can see their content. For example, Meta, the owner of WhatsApp, doesn’t have any way to read your messages or mine their contents for data. The EU’s draft regulation says solutions shouldn’t weaken encryption and says it includes safeguards to ensure this doesn’t happen; however, it doesn’t give specifics for how this would work.

“That being so, there is only one logical solution: client-side scanning where the content is examined when it is decrypted on the user's device for them to view/read,” Woodward says. Last year, Apple announced it would introduce client-side scanning—scanning done on people’s iPhones rather than Apple’s servers—to check photos for known CSAM being uploaded to iCloud. The move sparked protests from civil rights groups and even Edward Snowden about the potential for surveillance, leading Apple to pause its plans a month after initially announcing them. (Apple declined to comment for this story.)

For tech companies, detecting CSAM on their platforms and scanning some communications is not new. Companies operating in the United States are required to report any CSAM they find or that is reported to them by users to the National Center for Missing and Exploited Children (NCMEC), a US-based nonprofit. More than 29 million reports, containing 39 million images and 44 million videos, were made to NCMEC last year alone. Under the new EU rules, the EU Centre will receive CSAM reports from tech companies.

“A lot of companies are not doing the detection today,” Johansson said in a press conference introducing the legislation. “This is not a proposal on encryption, this is a proposal on child sexual abuse material,” Johansson said, adding that the law is “not about reading communication” but detecting illegal abuse content.

At the moment, tech companies find CSAM online in different ways. And the amount of CSAM found is increasing as tech companies get better at detecting and reporting abuse—although some are much better than others. In some cases, AI is being used to hunt down previously unseen CSAM. Duplicates of existing abuse photos and videos can be detected using “hashing systems,” where abuse content is assigned a fingerprint that can be spotted when it’s uploaded to the web again. More than 200 companies, from Google to Apple, use Microsoft's PhotoDNA hashing system to scan millions of files shared online. However, to do this, systems need to have access to the messages and files people are sending, which is not possible when end-to-end encryption is in place.

“In addition to detecting CSAM, obligations will exist to detect the solicitation of children (‘grooming’), which can only mean that conversations will need to be read 24/7,” says Diego Naranjo, head of policy at the civil liberties group European Digital Rights. “This is a disaster for confidentiality of communications. Companies will be asked (via detection orders) or incentivized (via risk mitigation measures) to offer less secure services for everyone if they want to comply with these obligations.”

Discussions about protecting children online and how this can be done with end-to-end encryption are hugely complex, technical, and combined with the horrors of the crimes against vulnerable young people. Research from Unicef, the UN’s children’s fund, published in 2020 says encryption is needed to protect people’s privacy—including children—but adds that it “impedes” efforts to remove content and identify the people sharing it. For years, law enforcement agencies around the world have pushed to create ways to bypass or weaken encryption. “I’m not saying privacy at any cost, and I think we can all agree child abuse is abhorrent,” Woodward says, “but there needs to be a proper, public, dispassionate debate about whether the risks of what might emerge are worth the true effectiveness in fighting child abuse.”

Increasingly, researchers and tech companies have been focusing on safety tools that can exist alongside end-to-encryption. Proposals include using metadata from encrypted messages—the who, how, what, and why of messages, not their content—to analyze people’s behavior and potentially spot criminality. One recent report by the nonprofit Business for Social Responsibility, which was commissioned by Meta, found that end-to-end encryption is an overwhelmingly positive force for upholding people's human rights. It suggested 45 recommendations for how encryption and safety can go together and not involve access to people’s communications. When the report was published in April, Lindsey Andersen, BSR's associate director for human rights, told WIRED: “Contrary to popular belief, there actually is a lot that can be done even without access to messages.”

The EU Wants Big Tech to Scan Your Private Chats for Child Abuse

Under certain conditions, the SAP Host Agent logfile shows information which would otherwise be restricted.

CVE-2022-28774

SAP NetWeaver Application Server ABAP allows an authenticated attacker to upload malicious files and delete (theme) data, which could result in Stored Cross-Site Scripting (XSS) attack.

CVE-2022-29610

During an update of SAP BusinessObjects Enterprise, Central Management Server (CMS) - versions 420, 430, authentication credentials are being exposed in Sysmon event logs. This Information Disclosure could cause a high impact on systems’ Confidentiality, Integrity, and Availability.

CVE-2022-28214

Due to insufficient input validation, SAP Employee Self Service allows an authenticated attacker with user privileges to alter employee number. On successful exploitation, the attacker can view personal details of other users causing a limited impact on confidentiality of the application.

CVE-2022-29613

SAP NetWeaver Application Server for ABAP and ABAP Platform do not perform necessary authorization checks for an authenticated user, resulting in escalation of privileges.

CVE-2022-29611

A zip slip vulnerability in XINJE XD/E Series PLC Program Tool up to version v3.5.1 can provide an attacker with arbitrary file write privilege when opening a specially-crafted project file. This vulnerability can be triggered by manually opening an infected project file, or by initiating an upload program request from an infected Xinje PLC. This can result in remote code execution, information disclosure and denial of service of the system running the XINJE XD/E Series PLC Program Tool.

****By Mashav Sapir | May 11, 2022******Executive Summary**

*   Team82 has uncovered two vulnerabilities in XINJE’s PLC Program Tool, an engineering workstation. 
*   Version 3.5.1 is affected, and likely other versions. 
*   Team82 began disclosure efforts in August 2020. More than a year later, XINJE acknowledged our disclosure in September 2021. 
*   XINJE at that time refused to cooperate with Team82 and asked us to stop communication with them.
*   We extended the terms of our coordinated disclosure policy beyond 90 days to nine months before disclosing limited details today to help asset owners prioritize any mitigations. 
*   An attacker may use a crafted project file to trigger these vulnerabilities. 
*   Arbitrary project files may be written to a project file to gain code execution.

Engineering workstations are among the most critical operational technology (OT) assets. Engineers use these platforms to configure and maintain control system applications and devices at lower levels of the Purdue Model for industrial control systems. A threat actor who can access and use an engineering workstation as an attack vector is in position to disrupt industrial processes and cause damage that could put public safety at risk or interrupt the delivery of critical services. 

Team82’s latest research is an examination of engineering workstation applications sold by XINJE, a Chinese automation company. We uncovered two vulnerabilities in the XINJE PLC Program Tool (CVE-2021-34605 and CVE-2021-34606) in v3.5.1. Team82 tested only v3.5., we believe other versions may be vulnerable too. 

These flaws can be triggered by a crafted project file. An attacker can use these vulnerabilities to write arbitrary project files to a PLC and gain code execution. 

Team82 is disclosing limited information today about these vulnerabilities, details of which were privately disclosed at the end of August 2021 after a year of attempting to connect with representatives of the company. The vendor was not receptive to our attempts to share technical information and collaborate on a fix and response. Finally, on Sept. 8, 2021, XINJE representatives asked that Team82 stop communication. Team82 extended the terms of its coordinated disclosure policy beyond 90 days to nine months before disclosing limited details today to help asset owners prioritize any mitigations. 

**Engineering Workstation Programs**

XINJE’s PLC Program Tool is an engineering workstation program, used in OT environments to communicate with XINJE-produced PLCs. These devices, according to XINJE, are sold not only in China, but also in Europe, North America, Southeast Asia, and elsewhere in a number of markets, including energy, manufacturing, and engineering. 

From a security perspective, gaining access to a machine containing the engineering workstation program can allow an attacker to fully meddle with PLCs and other highly sensitive OT equipment with adverse consequences. Therefore, exploiting vulnerabilities in these applications can be used by attackers as a final step toward taking full control of an OT network.

**_**An attacker targeting an engineering workstation could infect lower-level devices such as PLCs, sensors, or pumps.**_****Malicious Project Files at Heart of a Class of Vulnerabilities**

Team82 has taken a special interest in a class of vulnerabilities that involve project files. 

Project files are usually archive file formats that contain OLE files, SQLite databases, proprietary binary formats, text files, and directories created within engineering workstations. These programs are used by engineers to monitor, configure, and communicate with programmable logic controllers (PLCs) and other control systems.

The program logic contained in a project file governs ICS devices and oversees processes, and it also may include network configuration data and—at times—a complete OT network layout. For attackers targeting industrial networks—and many of late have been state actors—weaponized project files would likely be central to such a campaign.  

When a project file is opened with an engineering station program, the program can quickly communicate with the relevant equipment. Alternatively, the OT engineer can sometimes upload the project file from a PLC, but this requires either running a network discovery tool to find the PLC’s network address (a procedure not supported by all PLCs) or manually entering the relevant network parameters. As a result, many companies opt to use project files, each including the configuration for one or more PLCs.

Vulnerabilities can be triggered by specially crafted project files composed by an attacker when opened by the engineering station program. In this scenario, an attacker could, for example,  replace a legitimate file in a network share used to store the files with a crafted file that would  trigger a vulnerability in the program. We discovered such vulnerabilities in the XINJE PLC Program Tool, which can allow an attacker to run arbitrary code on a vulnerable endpoint upon opening an exploited project file.

**Research Environment Setup a Crucial First Step**

As part of our work, we often receive requests to research proprietary protocols in order to maximize our customers’ ability to observe the traffic in their network. At times we have to support older equipment still used in critical roles in production sites, and at other times we even stumble onto equipment manufactured by smaller OT vendors. 

The request we received from a customer to analyze protocols used by equipment manufactured by XINJE fell into the latter category.

Our  first step was to create a lab setup; this usually requires purchasing equipment and connecting it to the relevant engineering workstation program. In some cases, even purchasing the equipment can be difficult because the vendor might no longer offer the exact models we need.

What we discovered over time is that a surprisingly wide range of OT equipment can be purchased through eBay. In many cases, once a factory changes its OT equipment, the older, used equipment winds up on eBay and can be purchased easily and shipped to your doorstep.  Equipment offered by XINJE was no exception, and a variety of XINJE products can be purchased through eBay:

**_**Ebay listings for XINJE industrial equipment.**_ **

Once we purchased a PLC, the next step was to install it in our lab, along with a multitude of other OT equipment, and connect it to the engineering workstation program used to configure it.

**_**A XINJE PLC running in a lab setup.**_ ****Chaining Two Vulnerabilities to Load a Malicious File**

Once we’ve constructed a suitable setup and finished researching the different protocols used by the equipment, we’re often asked by our customers to look for security issues with the setup. 

Pointing out these issues can help users improve their security posture immediately. Responsibly reporting these vulnerabilities to the vendor, can help fix them and improve security across the entire OT space.

In XINJE’s case, we decided to focus on the engineering workstation program called XINJE PLC Program Tool. As mentioned earlier, in such cases project file vulnerabilities are of particular interest. Usually, searching for project file vulnerabilities begins with investigating the structure of the project file used by the engineering workstation program. In the case of XINJE PLC Program Tool, the relevant files are \*.xdp files:

**_**XINJE PLC project file structures are .xdp files.**_ **

These project files can be easily identified as zip files, as indicated by the PK\\x03\\x04 magic, below:

And they can be extracted by almost any archive utility (e.g. 7z). What’s even more interesting, is that when the the program opens a project file, it immediately extracts it to a temporary directory located within its installation directory:

**_**XDPPro.exe writes several files to C:\\Program Files\\XINJE\\XDPPro\\tmp**_**

This behavior indicates that the program assumes it’s being executed with administrator privileges. This, in combination with the extracted file being a zip file, immediately makes one wonder whether a zip slip vulnerability (an arbitrary file-overwrite vulnerability) can be leveraged to obtain arbitrary write privileges.

Soon enough we did find a zip slip vulnerability (CVE-2021-34605), which can provide an attacker with arbitrary write privileges with the permissions of the program; in most cases these will be administrator privileges.

The next question is how to reach code execution from an arbitrary file write. Since it makes the most sense for the code to be executed right after the project file is loaded, we can check what the program is doing while opening the project file:

**_**XDPPro.exe attempts to load DNSAPI.dll from C:\\Program Files\\XINJE\\XDPPro, doesn’t find it and falls back to C:\\Windows\\System32**_**

Interestingly, it’s trying to load .dll files from its local directory with LoadLibrary. When LoadLibrary doesn’t find them, it reverts to searching for them in C:\\Windows\\System32. Here is where we found our second vulnerability, CVE-2021-34606, a classic DLL hijacking vulnerability.

In order to create a fully-working exploit, we chained our two vulnerabilities:  
Once a specially crafted malicious project file is opened by XINJE PLC Program Tool, the zip slip vulnerability will be triggered and a .dll file will be written to the program’s directory in Program Files. Later in the process of loading a new project, this DLL will be loaded instead of the real DLL (located in Windows\\System32). 

Once the DLL is loaded, malicious code is executed during its DLLMain procedure or in one of the functions imported by the program. An attacker now may gain a foothold on an OT network.

**_**A demonstration of Team82’s proof-of-concept exploit.**_ ****Wrapping Up**

Despite the fact that awareness of cybersecurity has been steadily increasing in recent years in the OT world, many engineering workstation programs are still vulnerable to easily exploitable vulnerabilities. 

Not all vendors are aware of the fact that project files can be weaponized by attackers as a method to take control of critical OT resources; this is true for most OT personnel as well. 

In addition, many vendors still do not have well-defined interfaces for coordinated disclosure of vulnerabilities. As a result, disclosure can take an unnecessarily long time, often passing through sales and/or technical support teams without security knowledge, before reaching the teams responsible for the development of the affected products.

This was a challenging disclosure with XINJE, which thankfully is not the norm within the majority of OT vendors.

CVE-2021-34605: Code Execution Vulnerabilities Found in XINJE PLC Application

****By Mashav Sapir | May 11, 2022******Executive Summary**

*   Team82 has uncovered two vulnerabilities in XINJE’s PLC Program Tool, an engineering workstation. 
*   Version 3.5.1 is affected, and likely other versions. 
*   Team82 began disclosure efforts in August 2020. More than a year later, XINJE acknowledged our disclosure in September 2021. 
*   XINJE at that time refused to cooperate with Team82 and asked us to stop communication with them.
*   We extended the terms of our coordinated disclosure policy beyond 90 days to nine months before disclosing limited details today to help asset owners prioritize any mitigations. 
*   An attacker may use a crafted project file to trigger these vulnerabilities. 
*   Arbitrary project files may be written to a project file to gain code execution.

Engineering workstations are among the most critical operational technology (OT) assets. Engineers use these platforms to configure and maintain control system applications and devices at lower levels of the Purdue Model for industrial control systems. A threat actor who can access and use an engineering workstation as an attack vector is in position to disrupt industrial processes and cause damage that could put public safety at risk or interrupt the delivery of critical services. 

Team82’s latest research is an examination of engineering workstation applications sold by XINJE, a Chinese automation company. We uncovered two vulnerabilities in the XINJE PLC Program Tool (CVE-2021-34605 and CVE-2021-34606) in v3.5.1. Team82 tested only v3.5., we believe other versions may be vulnerable too. 

These flaws can be triggered by a crafted project file. An attacker can use these vulnerabilities to write arbitrary project files to a PLC and gain code execution. 

Team82 is disclosing limited information today about these vulnerabilities, details of which were privately disclosed at the end of August 2021 after a year of attempting to connect with representatives of the company. The vendor was not receptive to our attempts to share technical information and collaborate on a fix and response. Finally, on Sept. 8, 2021, XINJE representatives asked that Team82 stop communication. Team82 extended the terms of its coordinated disclosure policy beyond 90 days to nine months before disclosing limited details today to help asset owners prioritize any mitigations. 

**Engineering Workstation Programs**

XINJE’s PLC Program Tool is an engineering workstation program, used in OT environments to communicate with XINJE-produced PLCs. These devices, according to XINJE, not only in China, but in Europe, North America, Southeast Asia, and elsewhere in a number of markets, including energy, manufacturing, and engineering. 

From a security perspective, gaining access to a machine containing the engineering workstation program can allow an attacker to fully meddle with PLCs and other highly sensitive OT equipment with adverse consequences. Therefore, exploiting vulnerabilities in these applications can be used by attackers as a final step toward taking full control of an OT network.

**_**An attacker targeting an engineering workstation could infect lower-level devices such as PLCs, sensors, or pumps.**_****Malicious Project Files at Heart of a Class of Vulnerabilities**

Team82 has taken a special interest in a class of vulnerabilities that involve project files. 

Project files are usually archive file formats that contain OLE files, SQLite databases, proprietary binary formats, text files, and directories created within engineering workstations. These programs are used by engineers to monitor, configure, and communicate with programmable logic controllers (PLCs) and other control systems.

The program logic contained in a project file governs ICS devices and oversees processes, and it also may include network configuration data and—at times—a complete OT network layout. For attackers targeting industrial networks—and many of late have been state actors—weaponized project files would likely be central to such a campaign.  

When a project file is opened with an engineering station program, the program can quickly communicate with the relevant equipment. Alternatively, the OT engineer can sometimes upload the project file from a PLC, but this requires either running a network discovery tool to find the PLC’s network address (a procedure not supported by all PLCs) or manually entering the relevant network parameters. As a result, many companies opt to use project files, each including the configuration for one or more PLCs.

Vulnerabilities can be triggered by specially crafted project files composed by an attacker when opened by the engineering station program. In this scenario, an attacker could, for example,  replace a legitimate file in a network share used to store the files with a crafted file that would  trigger a vulnerability in the program. We discovered such vulnerabilities in the XINJE PLC Program Tool, which can allow an attacker to run arbitrary code on a vulnerable endpoint upon opening an exploited project file.

**Research Environment Setup a Crucial First Step**

As part of our work, we often receive requests to research proprietary protocols in order to maximize our customers’ ability to observe the traffic in their network. At times we have to support older equipment still used in critical roles in production sites, and at other times we even stumble onto equipment manufactured by smaller OT vendors. 

The request we received from a customer to analyze protocols used by equipment manufactured by XINJE fell into the latter category.

Our  first step was to create a lab setup; this usually requires purchasing equipment and connecting it to the relevant engineering workstation program. In some cases, even purchasing the equipment can be difficult because the vendor might no longer offer the exact models we need.

What we discovered over time is that a surprisingly wide range of OT equipment can be purchased through eBay. In many cases, once a factory changes its OT equipment, the older, used equipment winds up on eBay and can be purchased easily and shipped to your doorstep.  Equipment offered by XINJE was no exception, and a variety of XINJE products can be purchased through eBay:

**_**Ebay listings for XINJE industrial equipment.**_ **

Once we purchased a PLC, the next step was to install it in our lab, along with a multitude of other OT equipment, and connect it to the engineering workstation program used to configure it.

**_**A XINJE PLC running in a lab setup.**_ ****Chaining Two Vulnerabilities to Load a Malicious File**

Once we’ve constructed a suitable setup and finished researching the different protocols used by the equipment, we’re often asked by our customers to look for security issues with the setup. 

Pointing out these issues can help users improve their security posture immediately. Responsibly reporting these vulnerabilities to the vendor, can help fix them and improve security across the entire OT space.

In XINJE’s case, we decided to focus on the engineering workstation program called XINJE PLC Program Tool. As mentioned earlier, in such cases project file vulnerabilities are of particular interest. Usually, searching for project file vulnerabilities begins with investigating the structure of the project file used by the engineering workstation program. In the case of XINJE PLC Program Tool, the relevant files are \*.xdp files:

**_**XINJE PLC project file structures are .xdp files.**_ **

These project files can be easily identified as zip files, as indicated by the PK\\x03\\x04 magic, below:

And they can be extracted by almost any archive utility (e.g. 7z). What’s even more interesting, is that when the the program opens a project file, it immediately extracts it to a temporary directory located within its installation directory:

**_**XDPPro.exe writes several files to C:\\Program Files\\XINJE\\XDPPro\\tmp**_**

This behavior indicates that the program assumes it’s being executed with administrator privileges. This, in combination with the extracted file being a zip file, immediately makes one wonder whether a zip slip vulnerability (an arbitrary file-overwrite vulnerability) can be leveraged to obtain arbitrary write privileges.

Soon enough we did find a zip slip vulnerability (CVE-2021-34605), which can provide an attacker with arbitrary write privileges with the permissions of the program; in most cases these will be administrator privileges.

The next question is how to reach code execution from an arbitrary file write. Since it makes the most sense for the code to be executed right after the project file is loaded, we can check what the program is doing while opening the project file:

**_**XDPPro.exe attempts to load DNSAPI.dll from C:\\Program Files\\XINJE\\XDPPro, doesn’t find it and falls back to C:\\Windows\\System32**_**

Interestingly, it’s trying to load .dll files from its local directory with LoadLibrary. When LoadLibrary doesn’t find them, it reverts to searching for them in C:\\Windows\\System32. Here is where we found our second vulnerability, CVE-2021-34606, a classic DLL hijacking vulnerability.

In order to create a fully-working exploit, we chained our two vulnerabilities:  
Once a specially crafted malicious project file is opened by XINJE PLC Program Tool, the zip slip vulnerability will be triggered and a .dll file will be written to the program’s directory in Program Files. Later in the process of loading a new project, this DLL will be loaded instead of the real DLL (located in Windows\\System32). 

Once the DLL is loaded, malicious שcode is executed during its DLLMain procedure or in one of the functions imported by the program. An attacker now may gain a foothold on an OT network.

**_**A demonstration of Team82’s proof-of-concept exploit.**_ ****Wrapping Up**

Despite the fact that awareness of cybersecurity has been steadily increasing in recent years in the OT world, many engineering workstation programs are still vulnerable to easily exploitable vulnerabilities. 

Not all vendors are aware of the fact that project files can be weaponized by attackers as a method to take control of critical OT resources; this is true for most OT personnel as well. 

In addition, many vendors still do not have well-defined interfaces for coordinated disclosure of vulnerabilities. As a result, disclosure can take an unnecessarily long time, often passing through sales and/or technical support teams without security knowledge, before reaching the teams responsible for the development of the affected products.

This was a challenging disclosure with XINJE, which thankfully is not the norm within the majority of OT vendors.

The Web administration UI of SAP Web Dispatcher and the Internet Communication Manager (ICM) does not sufficiently encode user-controlled inputs, resulting in Cross-Site Scripting (XSS) vulnerability.

Tag

#sap