Inductive Automation Ignition Software

Risk Summary

Successful exploitation of this vulnerability could allow an attacker to execute malicious code with OS application service account permissions that the authenticated, privileged application user did not intend on running.

CVEs (1)

Remediations

• Fix - upgrade Ignition software from 8.1.x to 8.3.0 or greater.
• MITIGATION (8.1.x Linux). Implement Ignition Security Hardening Guide Appendix A. https://inductiveautomation.com/resources/article/ignition-security-hardening-guide
• MITIGATION (8.1.x Windows). Covered in Ignition Security Hardening Guide Appendix A. 1. Create a new dedicated local Windows account that will be used exclusively for the Ignition service (e.g. svc-ign). a. The best security practice is that the Ignition service should not be a domain account (unless otherwise needed). b. Remove all group memberships from the service account (including Users and Administrators). c. Add to security policy to log in as a service. d. Add to "Deny log on locally" security policy. 2. Provide full read/write access only to the Ignition installation directory for the service account created in #1. a. Add read/write permissions to other directories in the local filesystem as needed (e.g.: if configured to use optional Enterprise Administration Module to write automated backups to the file system). 3. Set deny access settings for service account on other directories not needed by the Ignition service. a. Specifically the C:\Windows, C:\Users, and directories for any other applications in the Program Files or Program Files(x86) directories. b. Use java param to change temp directory to a location within the Ignition install directory so the Users folder can be denied access to the Ignition service account.
• BEST PRACTICES (8.1.x and 8.3.x)4. Restrict project imports to verified and trusted sources only, ideally using checksums or digital signatures.5. Use multiple environments (e.g. Dev, Test, Prod) with a staging workflow so that new data is never introduced directly to Production environments. See Ignition Deployment Best Practices.6. When feasible, segment or isolate Ignition gateways from corporate resources and Windows Domains.a. The Ignition service account or AD server object should never need Windows Domain or Windows Active Directory privileges. This would only be needed if an Asset Owners IT or OT department uses this for management outside Ignition.b. Ignition may be federated with Active Directory environments (e.g. OT domains) by entering "Authentication Profile" credentials within the Ignition gateway itself. This could use secure LDAP, SAML, or OpenID Connect.7. When feasible, enforce strong credential management and MFA for all users with Designer permissions (8.1.x and 8.3.x), Config Page permissions (8.1.x), and Config Write permissions (8.3.x).8. When feasible, deploy Ignition within hardened or containerized environments.

Affected Vendors

Affected Products (1)

Affected Sectors

Information Technology