A security vulnerability was found when enabling the SSO (Single Sign-On) feature for AD (Active Directory) User Source profiles. As a result, the feature will be disabled for both Ignition versions 8.1.17 and 7.9.20. Going forward, expect the checkbox itself to be disabled from carrying out its intended feature for the following AD user source profile configurations:
- Active Directory User Source
- Active Directory Internal Hybrid
- Active Directory Database Hybrid
We can also expect the corresponding General Security Settings for Designer SSO and the Designer's Vision Login properties to be disabled.
The SSO feature was intended to allow Vision and Designer clients automatic login during the initial application launch. This was accomplished by depending on a previous user login through Windows.
The Vulnerability
With the SSO feature enabled, an attacker will be able to carry out Remote Code Execution against the Ignition server after retrieving:
- The name of an existing Ignition project that uses an AD user source for login
- The domain name of the AD server being used for the user source
- An existing AD username to begin running Python code against the Ignition server.
All three of these requirements can be retrieved by unauthorized users through the following methods:
- A simple Get request to {IP/DNSName}:{Port}/data/perspective/projects returns a JSON object of all existing project names on the Ignition server without any login requirements to the Gateway Webpage. It is important to note this API endpoint is by design and is intended to provide only public information about a project. The JSON payload itself does not contain anything that would be considered a secret.
- Example of a returned JSON Payload:
[
{
"name": "Test",
"title": "Test",
"description": "",
"author": "admin",
"modified": "Apr 1, 2022, 8:22:07 AM",
"thumbnailUrl": "",
"launchUrl": "/data/perspective/client/Test"
}
]
- Example of a returned JSON Payload:
- AD server domain names can potentially be cracked by referring to the main company name, checking email headers, or intercepting TLS certificates.
- So long as you know the username of any user with privileges to access the Designer, you can log in as that user into the Designer without having to supply their password. Attackers can potentially disguise themselves with those usernames if acquired.
Once an attacker retrieves the information stated above, they will then attempt an HTTP request against the Ignition server using an available API endpoint. This will allow them to disguise themselves as an existing, logged-in user. If successful, a second available API endpoint will allow them to perform RCE in the form of Python syntax. It is important to keep in mind that any RCE at this point will contain the same elevated permissions applied to the Ignition service itself.
How can I re-enable SSO for my Active Directory?
Upon upgrade to versions 8.1.17 and 7.9.20 or higher, the SSO features will be removed and disabled regardless of its state before upgrade.
Going forward, the SSO feature can be re-enabled by adding an additional system property to the ignition.conf file located in the Ignition install directory and then restarting the Ignition service. Check the user manual page for more information on the file's location:
The system property can be defined under the Java Additional Parameters section by adding the following:
wrapper.java.additional.X=-Dignition.enableInsecureAdSso=true
Note: Make sure to replace the trailing "X" of the prefix "wrapper.java.additional.X" with the appropriate value that follows the ascending numerical order of the parameter list. See user manual page on Changing Java Additional Parameters for examples.
What are the implications of re-enabling this feature?
We strongly recommend keeping this feature disabled going forward due to some possible scenarios with the vulnerability:
- A successful attack can provide hackers the means of establishing a reverse shell on the Ignition server's host machine.
- A shell or any code running system calls will possess the same user permissions as the Ignition service.
- Attackers with access to the Ignition host machine may also have access to a company's internal network.
Inductive Automation would like to take this opportunity to thank the researchers at Computest for responsibly disclosing the vulnerability. IA would also like to thank the Zero Day Initiative for facilitating the disclosure though the Pwn2Own competition at the S4x22 conference.
Comments
4 comments
Is there a plan to make this safe again? SSO can be a great feature to offer...
Does 2FA mitigate the risk in your opinion?
I'd also like a bit more info regarding the method of compromise - specifically point 3:
How can a username only provide any access to the gateway? This seems like the root cause (to me anyway, without having all the details)
Must the compromised username be currently authenticated to the gateway/designer?
Must the attack vector be through the compromised user's machine?
Having SSO Disabled has really put a sour mouth in all 6000 of my employees. So much easier with SSO (microsoft environment)
Does the latest release (Ignition 8.1.24 delivers a few IdP improvements to keep you calm, cool, and authenticated) help fix or mitigate the SSO vulnerability ?
Article is closed for comments.