(Web)Access (Un)Control
March 07, 2019 | Fritz SandsOn November 1, 2018, The Zero Day Initiative reported case ZDI-19-257 to Advantech regarding configuration weaknesses in version 8.3.3 of Advantech WebAccess. As of March 7th, 2019, the vulnerability has not been addressed by Advantech, so the Zero Day Initiative disclosed the vulnerability to the public in accordance with our disclosure policy. I was the original finder of the vulnerability.
The public advisory for the case reads:
This vulnerability allows local attackers to escalate privileges on vulnerable installations of Advantech WebAccess Node. An attacker must first obtain the ability to execute low-privileged code on the target system in order to exploit this vulnerability.
The specific flaw exists within the access control that is set and modified during the installation of the product. The product installation weakens existing access control restrictions of current system files, then sets weak access control restrictions on new files. An attacker can leverage this vulnerability to escalate privileges to the level of an administrator.
This case is not the first instance of this vulnerability in installations of Advantech WebAccess. Here is a history of the reported cases:
- ZDI-19-257 8.3.3
- ZDI-18-1319 8.3.1
- ZDI-18-500 8.3
- ZDI-17-713 8.2
- ZDI-16-155 8.0
In each case before ZDI-19-257, Advantech reported that the vulnerability had been resolved in the next version. Of course, the unbroken series of cases shows that the vulnerabilities in the Advantech software were not resolved – sometimes changed a bit, but not resolved.
I have blogged about this issue before in Advantech WebAccess – see my 2017 blog post on this issue in Advantech software. I discussed this issue in Advantech software as part of a larger presentation on SCADA vulnerabilities at the September 2017 meeting of the ICS Joint Working Group in Pittsburgh. That presentation was a direct outgrowth of the Hacker Machine Interface [PDF] talk that Brian Gorenc and I gave at DefCon 24, but with an extra section added covering the Advantech access control problems.
These are issues that simply should not still exist in commercial software. The fact that they do exist indicates that there are some fundamental misunderstandings common in the development community (and, I suspect, more common in the SCADA community than in most). So let's talk about it.
What is all of this about Access Control?
Especially with SCADA systems, there can be a lot of push back from vendors on configuration weaknesses involving access control. Here are some of the issues and my comments on them:
This product is meant to be run on a server, and only trusted system administrators should have logins on the system.
That is certainly an important reduction in the attack surface of a system. However (1) you, as a vendor, cannot control the configuration at a customer site, and (2) logged-in users are not the only attack vector into a server machine (a server opens ports and processes requests – that is what a server does).
Many SCADA servers wind up doing double-duty as workstations for operators. And, from a company's perspective, that rather makes sense. But definitely one cannot guarantee that a machine is not being used for multiple purposes.
You have to have code running on the system for access control weaknesses to be a problem.
Yes, you do. Especially for a server product, DACL controls are basically defense in depth. But defense in depth is hugely important. A system (or, scoped out, a network) is not typically compromised by exploitation of only one vulnerability. Each exploit is used in turn to expand presence, control, or persistence on the target. Once code is running at some level on the system, weak access controls can then be exploited to persist the presence through system reboots or to elevate the control from a low-value account to an administrator or system account.
This is especially true for products that implement a web server. Web servers run script at the behest of callers. It is common for exploits to be crafted against web servers so that code can be run on the server machine – which is why all web servers attempt to restrict the permissions of code running at the behest of callers. (More about this in relationship to Advantech later on).
Our products are meant to be running on a secure network segment.
Yes, they are. SCADA software should be running on secure network segments, as far from the Internet as possible. But not all customers implement such secure network segments, and those customers deserve some consideration. Also, “secure network segment” can mean different things to different customers – and security that relies on, for example, signatures and blacklists is inherently reactive.
Why is the privilege configuration of our own installed folder considered a vulnerability?
Yes, we received that exact question. Specifically, that was a question from Advantech about ZDI-19-257. So let's talk about that.
Ownership of a folder in a computer system is fundamentally defined by the Owner field and the access rights in the DACL for the folder. Period. It is not defined by, “But our installer program created it!” It is not defined by registered brand names or by trademarks. It is defined by the DACL. If the DACL your installer puts out says that Everyone has full control over your installed folder then, well, it is not your folder anymore once an attacker has any code running on the machine.
That is a cold statement, to be sure, but “It isn't your computer any more” is a pretty common theme in the humor of computer security, which does not always get us invited to the polite parties.
ZDI-19-257
I bet you thought I would never actually get to the issues in the case.
The first issue is that installation of the Advantech WebAccess 8.3.3 system weakens the Access Control restrictions on 64-bit executable files inside the \Windows\SysWow64 folder, which is the System32 folder for 32-bit apps running on a 64-bit system. The access control for all of these files has been changed so that the IUSR account has full control over them (including the ability to replace the entire file). In fairness, the account does not have FILE_WRITE or FILE_DELETE, but the account does have WRITE_DAC access, so any code running as IUSR can change the DACL to give itself WRITE permission and then overwrite the file.
In version 8.2 of Advantech WebAccess, the installer gave Everyone full access to the files. Given that, one could consider the 8.3.3 behavior to be a significant improvement.
Even better, in 8.3.5 the Advantech installer stopped weakening the ACLs of files in SysWow64. So I do have to give Advantech credit for this change.
This is a good time to talk about the IUSR account, since that account is going to feature heavily in the rest of the analysis. People who are not familiar with IIS installations may not know much about it (I didn't). Here is an introduction from Microsoft for an earlier version of IIS. To quote:
“The IUSR account is often called the Web Anonymous User or Internet Guest account…As you probably know, this is the account that is used when Anonymous authentication is enabled on the IIS server provided the IUSR account has appropriate NTFS permissions for the kind of access requested.”
In short, this is the account IIS uses for impersonating an Anonymous caller. The IUSR account should have absolutely minimal permissions. Therefore, the use of the account by the Advantech installation is absolutely inappropriate – this is exactly the account (OK, after Everyone) that should NOT be able to modify executables inside the system folder or, actually, modify any executables anywhere.
There are literally thousands of executable files inside the IIS webroot that give the IUSR account full control (the full list is in the Attack Surface Analyzer report). Some of the binaries also give full control to the World account.
More powerfully, all of the Advantech WebAccess binaries (which all run at Administrator) are contained within the \WebAccess\ Node. And all of these binaries are installed with the IUSR account having full control (OK, having WRITE_DAC permission, which is the same thing). Some of the binaries also give full control to the World account.
Please take a look at the Attack Surface Analyzer report for Advantech WebAccess 8.3.3 to see the full list of access control vulnerabilities.
Conclusions
The first, sad, conclusion is that vendors will announce vulnerabilities have been fixed in subsequent product releases when they have not been fixed at all. And will repeat the same mistakes over and over again.
I also conclude that there is some deep misunderstanding of some basic concepts among software vendors – and the role of Access Control restrictions for files is definitely in that list of misunderstandings.
You can find me on Twitter at @FritzSands, and follow the team for the latest in exploit techniques and security patches.