Simple to Find, Simple to Fix – Locating Weak File Permissions in Advantech WebAccess

My colleagues in the Zero Day Initiative (ZDI) have recently written many blog posts detailing complex vulnerabilities in many products. Who can blame them. While subtle vulnerabilities and sophisticated exploits are quite exciting for security researchers, I think there is also value in looking for simple vulnerabilities that should no longer exist in shipping software. As such, this in my first blog post of a series showing simple vulnerabilities that should be rooted out. Simple to find. Simple to fix. We’ll start by looking at bugs in the Advantech WebAccess product that – despite multiple patches – continue to exist.

The bug – Weak Access Controls for Executable Files

Executable files for programs installed on Windows systems are supposed to be installed in directories under the root directory “Program Files”. Microsoft’s goal in creating this directory was to provide a consistent location for software installation and, very importantly, consistent and secure access control for program executables. Access control in “Program Files” is locked down so that only Administrators can do anything beyond reading and executing files within that tree. In a 64-bit system, there is also a “Program Files(x86)” root directory, which has the same access controls and serves the same purpose.

WARNING – Access Control Details Ahead! 

A great article describing the format of icacls output can be found on Microsoft’s TechNet. This article can help you understand the output of the icacls command not look like a mysterious language.

Let’s take a look at how permissions should be set. This is from a standard Windows 7 installation:

This output means the Trusted Installer has Full Control of the files in Program Files. That is the (F). And this permission is inherited down the tree. That is the (CI) and (OI) – container inherit and object inherit respectively. This makes sense – an installer can install. SYSTEM and Administrators similarly have Full Control. Users have only Read and Execute permissions. And all of these inherit down the tree.

So basically, a User can execute the programs installed in Program Files but cannot change any of the files.

If we go down one level in the tree, we see that inheritance does its work by examining an installation of IDA 6.8:

Note that, as expected, files in the IDA 6.8 directory are protected from modification from standard users.

A significant number of companies prefer putting their software in a top-level folder instead of using Program Files. One example that is probably on the systems of most Windows users who read this blog - Python:

This means that any user of the system can modify all of the Python 2.7 binaries. In a multi-user system, this can be a serious issue. But development machines tend to be single-user. A benefit of this, on a single-user machine, is that the user can update Python without having to elevate to Administrator.

In contrast to Python 2.7, installation of Python 3.5 puts executables inside an individual user AppData directory. Those executables are controlled by the specific user who installed the package and will be executed by that user and can be updated by that user. If the system had multiple users, each will have their own Python installation.

There are a number of reasons the pattern of not using the Program Files tree might occur:

1.  The corporation really wants its name in a directory at the root of the drive.
2.  The corporation has made minimal changes to the software since the days of Windows 95.
3.   The software is unable to handle paths with embedded spaces. Terrifying, to be sure, but not unexpected.
4.   Inertia.
5.   Compatibility of software paths between Windows and Linux versions of the software. It could also possibly result from a port of the product from Linux to Windows.
6.   Product design that comingles software and global data, meaning data that can be changed by any user. This is a poor security design in the first place. Implementing the design by allowing all users to modify the software as well as the global data is far worse.
7.   Product design that allows upgrade of packages without Administrator credentials, which is certainly problematic.

Some of these reasons actually require insecure implementation. Most of them do not, but it is very easy to generate insecure access rights.

Let me be clear – it is not inherently insecure to install software outside of the Windows Program Files trees. But if you do so, you need to set access control correctly – and it is very easy to do it wrong.

OK – here we go!  Case study time!

In June of 2015, I looked at Advantech WebAccess 8.0. I found some Access Control vulnerabilities, and the ZDI disclosed the information to Advantech through ICS-CERT, which released ICSA-16-014-01 detailing this and other vulnerabilities.

In June of this year, I took a look at issues in version 8.2. This time, I did a more detailed scan of the file system. Again, vulnerabilities were found and reported to Advantech through ICS-CERT. Following the publication of ICSA-17-241-02 and issuance of CVE-2017-12713 and CVE-2017-12711, the ZDI publicly disclosed the case.

This is from the June binaries for WebAccess 8.2.

We can see that the ACLs in the WebAccess folder are very similar to the ACLs in the Python 2.7 folder. Again, all authenticated users can modify all of the files under the WebAccess root directory. This has somewhat more serious ramifications since a number of the binaries in that tree will run, in normal operation, with full System Administrator privileges. If an attacker can get low-level access to the machine, they can drop in binaries in that directory that will run with System Administrator rights.

The rest of the information in this post comes from the V8.2_20170817 version of Advantech WebAccess, which was identified by ICS-CERT as the version that fixes the deficiencies that were reported.

The ACL for WebAccess was fixed. It now is:

As you can see, Authenticated Users no longer have Modify permissions. However, Advantech did not correct the ACLs on the Node subdirectory. Which is where all of the binaries reside.

The c:\WebAccess\node folder permissions are:

Yes, you’re reading that right – Everyone has full permissions, which seems pretty thorough, especially since many COM objects that run in the context of System Administrator reside in that folder. It doesn’t help to fix the ACLs on one level of your tree if you destroy the ACLs on the next level down.

But Wait – there’s more!

I have seen many cases of bad access controls when a vendor builds a directory under the root directory, but WebAccess also makes some very unusual changes in the System32 directory. Here is information about one file that is normally in \Windows\SysWow64, which is the version of System32 that exists in a 64-bit Windows installation to hold 32-bit files.

This is the standard. System and Administrators have full control, but Users have only Read and Execute permissions.

Here is that same information on a system with the latest Advantech WebAccess installed:

Note that neither the size nor the date on the file has been changed. However, its Access Control has been smashed and replaced with Everyone having full access. This is true for approximately 40 files in system directories. I have no explanation for why this was done by the software installer.

And Just to Round It Out!

WebAccess installs a Web Server, so it creates an InetPub root-level directory, which is typical for a Microsoft IIS installation. The permissions in that directory are fine. But during installation, it creates a number of files that, like the ones it modifies in the Windows tree, have their access control destroyed and replaced with Everyone having Full Access.

Whew….

Vulnerability Effects

Honestly, these types of bugs do not tend to lead to “sexy” exploits. As a program, the ZDI rarely buys these types of bug reports and are only interested in them in certain extreme cases. These vulnerabilities usually require an attacker to already be able to run code as a user on the target system. On the other hand, if you can have other vulns that give you standard user access to a system (think malware), this type of configuration vulnerability allows you to attain great persistence.  

In Conclusion

These bugs are the ultimate in low-hanging fruit. They have no reason to exist. They are simple to find and simple to fix. Vendors should be weeding these types of configuration errors out early in the development of a program. If you are interested in other bugs impacting SCADA systems, especially those affecting the Human Machine Interface (HMI), be sure to check out the whitepaper we released earlier this year on the state of SCADA HMI security.

In the coming months, I’ll detail other vulnerabilities in systems both simple and complex. Until then, you can find me on Twitter at @FritzSands, and follow the team for the latest in exploit techniques and security patches.