2NGA002579 · CSAF 2.0 · revision 1 · finalABB Product Security Incident Response Team (PSIRT)ABB Arctic communication solution ARM600 Vulnerabilities
The vendor explicitly identifies these products as affected by this CVE.
- ABB M2M Gateway ARM600, firmware versions >=4.1.2|<=5.0.3
- ABB M2M Gateway SW, software versions >=5.0.1|<=5.0.3
- Summary
- A specially crafted `.gitmodules` file with submodule URLs that are longer than 1024 characters can used to exploit a bug in `config.c::git_config_copy_or_rename_section_in_file()`. This bug can be used to inject arbitrary configuration into a user's `$GIT_DIR/config` when attempting to remove the con-figuration section associated with that submodule. When the attacker injects configuration values which specify executables to run (such as `core.pager`, `core.editor`, `core.sshCommand`, etc.) this can lead to a remote code execution.
- Remediation
- Mitigating factors describe conditions and circumstances that make an attack that exploits the vulnerability difficult or less likely to succeed. The following mitigations are recommended. 1. Obtain a cellular private access point (APN). A dedicated private cellular access point and respective SIM card subscriptions can be requested from your cellular service provider. This service doesn’t expose the traffic between remote sites and main site to the internet but rather uses cellular operator’s private wide area network (WAN). Therefore, the ARM600 wouldn’t need open ports to the internet. 2. Avoid exposing any system component to the internet. If, however, the ARM600 is exposed to the internet, only the VPN port should be opened towards the internet (e.g., Patrol management connections can be configured to use VPN tunnel and remote administration connections can be implemented by using OpenVPN PC-client). 4. Perform firewall configuration by the "allowlisting" principle, i.e., explicitly allowing only the required ports and protocols and blocking any other traffic. 6. If the internet is used as a WAN media for carrying VPN tunnels, use Demilitarized Zone (DMZ) for terminating connections from the internet (i.e., the remote connections should terminate to the DMZ network, which would be segregated from other networks by a firewall. The ARM600 server would be located into this DMZ). 7. Change the default user credentials of ARM600 and Arctic wireless gateways into non-defaults and use complex non-guessable passwords with special characters. Do not reuse passwords within the system. 8. Use administrator (i.e., root user) privileges only when required by the task. 9. Supporting systems, such as PCs used for configuration, should be frequently updated. If possible, use dedicated site PCs for upgrading and engineering purposes. At minimum, PCs should be investigated by running a full virus scan with recently updated signature files before introducing the PC to the OT system. Any data, such as device configurations and firmware update files transferred to the Arctic system should be virus scanned prior to transferring. 10. Introduce a backup policy, which will ensure periodical backups and backup revision numbering. Consider the following: a. Check that the entire system has backups available from all applicable parts. b. Store the backups in a safe place (e.g. in an encrypted storage), restricted by role-based access control mechanisms. c. Ensure the security of the configuration PCs that may have local copies of device configurations. d. Validate the backups to make sure that they’re working. 11. Follow cyber security best practices for installation, operation, and decommissioning as described in the product’s Cyber Security Deployment Guideline and User Manual. 12. Use continuous monitoring (e.g., intrusion detection/prevention tools) to detect anomalies in the system 13. Consider hardening the system according to the following: a. Remove any unnecessary communication links in the system. b. If possible, close unused physical ports. c. Open only the necessary TCP/UDP ports in the configuration. d. Remove all unnecessary user accounts. e. Restrict traffic by firewall. f. Allow the traffic only from/to necessary hosts' IP addresses (i.e., define both source and destination in the firewall rules, where possible). g. Define client IP address as allowed address in SCADA communication protocols, if such configuration is supported. h. Remove or deactivate all unused processes, communication ports and services, where possible. i. Use physical access controls to the system installations (e.g., to server rooms and device cabinets).