Outpost24 detects critical SCADA vulnerabilities

Reference: https://ics-cert.us-cert.gov/advisories/ICSA-16-033-01

In essence, this advisory will, at a high level, describe the elevation of privileges, authentication bypass and account takeover in the SAUTER ModuWEB Vision.

Apart from the CVE vulnerabilities, other issues were identified including;

• Undocumented default accounts (resolved by vendor)
• Presentation of configured credentials for other systems in plain text (resolved by vendor)

Combination:
Over the network, without credentials, it is possible to obtain full control of the system provided a series of relatively uncomplicated steps.

Exploitability: Proven
Private exploit: Exists

Affected products:
EY-WS505F0x0 modoWeb Vision Versions 1.5.5 and older.

It should be noted that while all issues are resolved by the vendor in the latest version, unpatched systems remain. Hence, the default low privilege accounts present on unpatched systems will not be included in this information release.

INSECURE CREDENTIAL STORAGE (Pass the Hash) CVE-2015-7914

“The moduWeb Vision stores credential elements in an encrypted format that use the same encryption scheme as the authentication mechanism, allowing for use of a pass-the-hash attack against the system. This would allow an attack to use these elements to bypass authentication and use the system without authorization.”

INSECURE TRANSMISSION OF CREDENTIALS CVE-2015-7915

“The moduWeb Vision application transmits information in plain text including credentials. This allows malicious parties with access to the transmitted data to obtain credentials and bypass authentication.”

CROSS-SITE SCRIPTING CVE-2015-7916

“The web server of the moduWeb Vision application allows for certain queries that would allow an attacker to obtain and change protected information from the system. A malicious user could add or modify accounts and credentials or potentially redirect other users of the application to malicious locations or sites.”

Summary

The moduWEB Vision system uses default accounts as “profiles” for configuring the system. While hardening instructions are available in the vendor documentation, and recommends replacing the admin account or change its password, there are no instructions to change the default built in passwords of other accounts.
Two of those accounts have access to the password hash of the admin account by use of the backup feature introduced in more recent version of the moduWEB Vision.

Without cracking the hash, the same hash is used as an authentication token by passing it as an authentication cookie to the platform, again a feature introduced in more recent version of the moduWEB Vision.

This in turn allows privilege escalation from the undocumented low level access account to administration level.

This then allows configuration changes, for example:
Resetting the device to defaults

Misconfiguring or disabling the device
Changing all passwords

Further, the backup contain other encrypted authentication information for other systems, however in some cases those passwords are sent in clear text populating password-fields in the interface during configuration. This in turn gives access to the SMTP accounts used by the clients for monitoring and alerting, including common information on other SCADA devices also sending results to the same server.

Do note that in older systems, prior to the introduction of the “keep me logged in feature”, this vulnerability were not present.

Setting the foundation – Remember me functionality

It’s intereresting to note that if a user logs in setting the “remember me” option, two cookies are set.

Logging in as admin with default password:

Cookies: uid=0, pw=[REDACTED PENDING WIDER UPDATES]

This is interesting, as it means a password hash is used for the purpose of authentication, i.e. the hash is used in place of a password. In essence, it’s a plain storage of a password as we can set a hash rather than attempt a password, it’s just longer, and thereby more complex.

Backup functionality

Looking at the BACKUP-FUNCTION, we note that there are a range of users in the users.xml file.
It should be noted that the password hash is the same hash used for the cookie pw.
Also note that the same password is used for the other default accounts.
In the notification_settings.xml, we see that the password for SMTP is stored in an encrypted format.

More interesting is review of the user-list from the users.xml file included in the backup.

The above extract is edited to remove parts of the HASH, but the same hash is in use for all subaccounts.

In essence, this means that the default password is not applicable only to admin, but also to specialist, user and guest.

Information disclosure

http://SERVERNAME/notifications/global/server

By going to Server settings, the page loaded contain SMTP Server, Port, Sender email address, Username, Password

The password is masked as a password field, but is populated with the SMTP password.

The emails are used to gather SCADA events and other information about enrolled systems, and this gets the attacker an initial foothold where additional information can be acquired, not only about the current SCADA system but regarding any other SCADA systems setup to use the same event management email account.

PUTTING IT ALL TOGETHER TO ATTACK

If default credentials does not work to access the device, attempt the low privilege versions and login as either “specialist” or “user” as those accounts are defined as “roles” and not accounts in the interface, and hence even during hardening most users do not adjust the passwords. The vendor instructions for hardening does not detail this step in hardening either. Those accounts, or “roles”, are no longer present in updated systems.

Access the Extras -> Backup -> HTTP BACKUP

The backup is downloaded, in a GZ archive with the backup data, which can be opened by, for example, WINRAR or any other similar decompression tool.
In the data is the /RW/users.xml file
In this file we can now see all the users
We note that the password hashes are available.

What is the admin account is removed?

Specialist-users can not see users of access level admin in the interface. If with the specialist user we look at the user-list, we notice that one or more users are not visible there, who are present in the backup.xml file
In hardened systems, user 0 (admin) is removed.

By quickly comparing the two lists, we now have the hash of the actual admin user, regardless of the used id/username. Commonly, it will be the first custom user (uid 4) but it can of course be any user. But in short – When in specialist access level, any users not seen in the GUI but present in the backup is an admin, and hence you have both the UID and the PW cookies required to gain administrative access to the target.

Using those settings, we have elevated privileges and are now administrators on the equipment. And of course, on our way out, we steal the SMTP credentials. This most of the time gives us the inbox used to monitor (and password reset) a lot of SCADA/PLC equipment.

Cross Site Scripting

The XSS issues in the platform relate to usernames, and are made present into user management, events management and user administration.

In essence they allow for a user to change his information in such a manner that any administrator logging into the device and accessing any of those parts of the interface will trigger the attacks, and hence, there is a second path to efficient privilege escalation, either via adding additional users, elevate the access level of the attackers account, or directly act as the administrator using the XSS vulnerability.

This is just common XSS, albeit in a bad place, and hence have not been subjected to any in depth inclusion in this write-up, we all know what a persistent XSS is, we know it is not good, and we know that if it affects an admin in an application depending solely on the web application for configurations, it is a likely game over. But it does require authenticated access to the device, and hence only pose a problem in cases where a low privilege account can get stolen or brute-forced, and then to elevate access.

There were more than one, but the most interesting were found at
/settings/usermanagement/metadata

Image below showing the admin user accessing the user-management interface triggering the persistent XSS:

Quite frankly, this is just not interesting enough to deserve more of a writeup.
 

Final words;
Many thanks to the vendor who have invested a lot of work to address not only the authentication issues but all issues discussed with them in a manner which for this business is quite unique. Also thanks to ICS-CERT for their work on coordination.

Martin Jartelius
CSO
Outpost24