CVE-2012-4929
lowPriorität · verfolgen · 22EPSS 0.043 · 91. PerzentilExploit · PoCCHEUJPUSEPSS · bewertet 2026-10-22
The TLS protocol 1.2 and earlier, as used in Mozilla Firefox, Google Chrome, Qt, and other products, can encrypt compressed data without properly obfuscating the length of the unencrypted data, which allows man-in-the-middle attackers to obtain plaintext HTTP headers by observing length differences during a series of guesses in which a string in an HTTP request potentially matches an unknown string in an HTTP header, aka a "CRIME" attack.
Behebungen
Hersteller-Fix, Mitigation oder Workaround, wie von den Quellen veröffentlicht.
Noch kein Hersteller-Fix; eine Mitigation ist verfügbar.
- MitigationARM600abb_psirt
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).
- MitigationSWabb_psirt
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).
- MitigationARM600cisa_csaf_ot
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).
- MitigationSWcisa_csaf_ot
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).
cvss
Technischer Schweregrad, 0–10. Eine Zeile je Quelle.
Basiswert 0–10 · höher = schwerwiegender · Vektor überfahren zum Auflösen
schwächen
Die CWE-Schwächeklassen, zu denen dies gehört.
Exploits (2)
Öffentlicher Proof-of-Concept- und Exploit-Code.
betroffene Produkte (11)
Betroffene Produkte und Versionsbereiche.
Advisories (3)
Hersteller- und Ökosystem-Meldungen dazu.
- 2NGA002579ABB Arctic communication solution ARM600 Vulnerabilities2025-04-07csaf · abb_psirtCH
ABB is aware of public reports of a vulnerabilities in product versions listed as affected in this advisory. An attacker who successfully exploited these vulnerabilities could cause the product to stop, make the product inacces-sible, take remote control of the product or insert and run arbitrary code. As part of ABB product lifecycle policy, once a product transitions to end-of-life, we discontinue maintenance, security patches, and technical support to focus on current and future technologies. While the product will continue to function, we strongly recommend implementing mitigations defined in this document, such as using a private APN cellular network between Arctic wireless gateways and ARM600 for establishing VPN tunnels, to mitigate security risks and avoid potential vulnerabilities. As part of ABB product lifecycle policy, once a product transitions to Limited state, we discontinue maintenance, security patches, and technical support to focus on current and future technologies. While the product will continue to function, we strongly recommend implementing mitigations defined in this document to mitigate security risks.
- ICSA-25-105-08ABB M2M Gateway2025-04-07icsa · cisa_csaf_otUS
ABB is aware of public reports of a vulnerabilities in product versions listed as affected in this advisory. An attacker who successfully exploited these vulnerabilities could cause the product to stop, make the product inacces-sible, take remote control of the product or insert and run arbitrary code. As part of ABB product lifecycle policy, once a product transitions to end-of-life, we discontinue maintenance, security patches, and technical support to focus on current and future technologies. While the product will continue to function, we strongly recommend implementing mitigations defined in this document, such as using a private APN cellular network between Arctic wireless gateways and ARM600 for establishing VPN tunnels, to mitigate security risks and avoid potential vulnerabilities. As part of ABB product lifecycle policy, once a product transitions to Limited state, we discontinue maintenance, security patches, and technical support to focus on current and future technologies. While the product will continue to function, we strongly recommend implementing mitigations defined in this document to mitigate security risks.
- JVNDB-2016-000129JVN iPedia advisory JVNDB-2016-0001292025-04-18vendor · jvndbJP
auch bekannt als (3)
Weitere Namen und Kennungen dieser Entität.
quellen
Welche Quellen diesen Datensatz belegen und wann.
Referenzen (71)
Externe Belege — Patches, Meldungen, Analysen.
- https://gist.github.com/3696912Patchcnnvd
- https://www.auscert.org.au/bulletins/ESB-2022.0696cnnvd
- https://www.ibm.com/blogs/psirt/security-bulletin-ibm-integrated-management-module-ii-imm2-is-affected-by-vulnerability-in-openssl-cve-2012-4929/cnnvd
- http://arstechnica.com/security/2012/09/crime-hijacks-https-sessions/enisa_euvd
- http://code.google.com/p/chromium/issues/detail?id=139744enisa_euvd
- http://isecpartners.com/blog/2012/9/14/details-on-the-crime-attack.htmlenisa_euvd
- http://jvn.jp/en/jp/JVN65273415/index.htmlenisa_euvd
- http://jvndb.jvn.jp/en/contents/2016/JVNDB-2016-000129.htmlenisa_euvd
Angreifer nutzen Schwachstellen wie diese gegen im Internet exponierte Dienste aus. Sehen Sie mit einem kostenlosen Passiv-Scan, was exponiert ist.
Kostenloser Scan