Software Vulnerabilities and Threats

This guide describes different types of software vulnerabilities and associated threats. It also describes various defense mechanisms that are typically needed to be prepared for software attacks.

For guidance on how to handle vulnerabilities in ABB software, see How-to Handle Software Vulnerabilities.

Intended for

Product managers, product owners, software engineers, and anyone who'd like to learn more about software vulnerabilities and threats.

Software vulnerabilities

A software vulnerability is a weakness that enables a way of realizing a threat. While there’s no unified definition of "software vulnerability", these examples from reputable sources provide a clear understanding:

• RFC 2828, Internet Security Glossary: “A flaw or weakness in a system’s design, implementation, or operation and management that could be exploited to violate the system’s security policy.”

• CNSSI 4009, Committee on National Security Systems (CNSS) Glossary: “Weakness in an information system, system security procedures, internal controls, or implementation that could be exploited by a threat source.”

Threats

A threat is anything that could exploit a vulnerability, which could affect the confidentiality, integrity or availability of systems, data, people, and more. In software, threats can typically be of the following types, based on Microsoft’s STRIDE model:

Threat	Security Property	Definition	Examples
Spoofing	Authentication	An attacker poses as something or somebody else.	Login possible without password. Accepting communication only based on IP address.
Tampering	Integrity	An attacker modifies data or code.	File modification cannot be detected. Firmware loading to controller.
Repudiation	Non-repudiation	An attacker does something to a system without leaving any evidence.	Not possible to know who reconfigures.
Information disclosure	Confidentiality	Information is exposed to users who are not authorized to see it.	Password in clear text in log file. Hardcoded encryption key
Denial-of-service	Availability	An attacker prevents legitimate users from using the system or any part of it.	Malformed packet causes service to stop.
Elevation of privilege	Authorization	An attacker gains capability without proper authorization.	Normal operator allowed to download to controller.

Defense mechanisms

To prevent an attack from succeeding, some type of defense mechanism is typically needed. For many threats, the defense against them may be of many different types, e.g.:

• A protection mechanism that prevents an attack from achieving anything, preferably linked with a capability to inform that an attack was attempted but most likely failed, e.g. by providing log information.
• A detection mechanism linked with a capability to limit the negative impact of the attack, e.g. by stopping the affected function. This means that the attack will be converted to a denial-of-service (DoS) attack, with preferred consequences. It might be better that an attacked function stops working, than that it continues to run doing something else than it's intended to. This type of defense should include informing about the detected problem and what actions have been taken.
• A detection mechanism that only informs that a problem was discovered but leaves any actions to some other function or the user.
• Avoiding the vulnerability by a different design. It is for example not possible to attack a data exchange by file manipulations if no files are used.

Software vulnerabilities examples

The following sections provide descriptions of software vulnerabilities related to the STRIDE threats, and examples of what is considered a vulnerability and not.

Spoofing vulnerabilities

A spoofing vulnerability is a product defect that allows an attacker to avoid authentication and pose as something or somebody else.

Examples:

• IP address spoofing

  An attacker connects a rogue unit to a network and gives it an address that is expected to be used by some other unit. This is a spoofing attack.

  If a unit V on the network “believes in the fraud”, i.e. is not able to detect that the rogue unit is not really what it poses as and acts accordingly, e.g. by denying access, unit V has a spoofing vulnerability.

• User spoofing

  An attacker logs in to a system claiming to be some other person. This is also a spoofing attack.

  If the system is not able to detect that the rogue person is not really who he/she poses as and to treat it accordingly, the system has a spoofing vulnerability.

Examples not regarded as spoofing vulnerabilities:

• Starting a fire alarm

  A person starts a fire alarm by breaking the glass and pushing the alarm button without authenticating. This is not a spoofing vulnerability since the safety function of the fire alarm is designed to not require authentication.

• Insecure standard protocols

  A protocol stack implemented according to an international standard, e.g. Modbus TCP, that does not describe any security mechanism, e.g. no authentication. According to ABB Software Vulnerability Handling Policy this is not a software vulnerability:

"If the discovered or reported vulnerability is a “design vulnerability” then based on an informed business decision this policy might not have to be complied with. For this policy, a “design vulnerability” shall mean a vulnerability that exists because of a deliberate design decision where the relevant feature is clearly documented for customers. An example of such “design vulnerabilities” is the use of protocols like Telnet or FTP that do not have built-in security".

Tampering vulnerabilities

A tampering vulnerability is a product defect that allows an attacker to affect a system's integrity by modifying data or code in an unauthorized way.

Examples:

• Illegal file modifications

  An attacker tries to modify the content of a configuration file in an unauthorized way. This is a tampering attack.

  If the attacker can modify the file and the functions using this file are not able to detect that the content has been modified in an unauthorized way and to react accordingly, e.g., by blocking usage of the file or informing that the file may have been tampered with, this function has a tampering vulnerability.

• Buffer overruns

  An attacker sends a malformed message with the potential to modify the code of a running process in the memory of the computer. This is a tampering attack.

  If the system is not able to avoid the malformed message that modifies the code or to detect that it has happened and to react accordingly, e.g., by stopping the running process, the system has a tampering vulnerability.

• Replacing an executable file part of the PCP system/software installation.

  An attacker without administrative privileges loads a modified version of an executable file to a system node and replaces the original file with this file. This is a tampering attack.

  If the system is not able to block a non-privileged user from exchanging executable files, the system has a tampering vulnerability.

Examples not regarded as tampering vulnerabilities:

• Exchange of controller firmware via SD card

  A person exchanges the firmware via the SD card.

  This is not a tampering attack if this is a design feature of the controller. Unauthorized loading of firmware via SD card should be prohibited by other measures, e.g. by preventing unauthorized physical access to the controller by installing it in a locked cabinet or room.

Repudiation vulnerabilities

A repudiation vulnerability is a product defect that allows an attacker to do something to a system without leaving any evidence that he/she did it. This applies to actions that can be expected to be registered in some way.

Examples:

• Missing logging of system reconfiguration

  An attacker makes a system configuration change of a type that is expected to be registered and tries to prevent the action from being registered or to remove the evidence of the action, this is a repudiation attack.

  If it is possible for the attacker to succeed in avoiding the creation of the evidence of the action or by removing the evidence afterward, the system has a repudiation vulnerability.

• Avoiding audit trails

  An operator issues a command which is expected to generate an audit trail entry and tries to prevent the audit trail entry from being created, this is a repudiation attack.

  If it is possible for the operator to succeed in avoiding the creation of the audit trail entry, the system has a repudiation vulnerability.

Examples not regarded as repudiation vulnerabilities:

• Commissioning actions not recorded

  A commissioning engineer exchanges a controller in the system. It is not possible to see in the system who this person was.

  This is not a repudiation vulnerability since the system is not expected to record such actions. A system owner who wants to keep track of such actions may decide to install physical protection solutions, e.g. an electronic lock system that registers who opens which doors.

• Administrator actions not recorded

  A system administrator formats the disk of a single-node system and installs a new version of a product. It is not possible to know who the person was that did this.

  This is not a repudiation vulnerability since the system is not expected to record such actions. A system owner who wants to keep track of such actions may decide to install physical protection solutions, e.g. an electronic lock system that registers who opens which doors.

• Unknown service engineer replaces system hardware

  A service engineer replaces control system hardware in a cabinet in an instrumentation room. Identifying the individual responsible is desired, but not possible because the locks on the room and the cabinets were not unique to each engineer, and the surveillance camera was manually turned off. The camera being off is not considered a software vulnerability, as it was functioning correctly but manually disabled.

Information disclosure vulnerabilities

An information disclosure vulnerability is a product defect that allows an attacker to expose information to persons who are not authorized to see it, or in other words to damage the confidentiality of the system.

Examples:

• Passwords sent in clear text on the network

  An attacker records network traffic and analyses the content without permission from a system owner. This can be considered as an eavesdropping attack and is one type of attack against the confidentiality of the system.

  If it is “too easy” to find confidential data this way, e.g. if passwords are sent in clear text, the system has an information disclosure vulnerability.

• Too easy to open hidden application code

  An attacker processes an encrypted file with application code. This is an attack against the confidentiality of the system.

  If it is “too easy” to decode the application code, the system has an information disclosure vulnerability.

• Confidential data is written in the log file

  Log printouts are not planned with confidentiality in mind and low-privileged users can access the log file.

  If confidential data is included in the log files, this is an information disclosure vulnerability.

Examples not regarded as an information disclosure vulnerability:

• Possible to crack temporary keys

  An attacker records network traffic and is after some hours of processing of the recorded traffic able to crack/extract a key, but this key is only valid for some minutes.

  This is not an information disclosure vulnerability since the extracted key is no longer valid and cannot be used.

• Access to confidential information by social engineering

  A person who is not authorized to access a system persuades a legitimate user to reveal confidential data e.g. user names and/or passwords to the system.

  This is not a software vulnerability since the problem is not in the software.

DoS vulnerabilities

A DoS vulnerability is a product defect that too easily allows an attacker to prevent a legitimate user from using the system or any part of it or in other words to reduce the availability of the system.

Examples:

• A network storm causes a device to reboot

  An attacker sends abnormally much traffic on the network. This is a DoS attack. If a device stops working, i.e. stops its intended function, it has a DoS vulnerability.

  If the intended function is only related to the communication on the network, it is of course understood that a fully flooded network will not allow any nodes on the network to use it. This does normally not mean that a certain node on the network has a vulnerability as long as it survives the storm and can resume communication on the network when the storm has ended.

• A malformed packet causes a task to stop performing its intended function

  An attacker sends a packet with some specific content to a device. This is a DoS attack. If the task that handles this packet stops working as intended, it has a DoS vulnerability.

• Too easy to overload a data provider interface

  An attacker uses an interface that is intentionally publicly available and sends an abnormal number of requests. The system load generated by the requests blocks the operation of the system.

• Too easy to overload an authentication function

  An attacker connects a rogue device to a system network. The rogue device is an authentic ABB product, but it is not configured by authorized personnel, so it cannot authenticate to the system. The system load generated by the failed authentication attempts blocks the operation of the system.

Examples not regarded as cyber security DoS vulnerabilities:

• Random software faults

  A controller halts due to a fault that cannot be provoked, i.e. this is a product weakness that cannot be exploited.

• An independent function does not do anything

  A bug causes a certain function to fail without affecting any other functionality.

  An example is when an editor that was started only for editing a single file crashes when reading the file. This is a stability issue but cannot be exploited for bad purposes. If the editor was executed by a process that also handled other functions that would be affected by the crash, it would potentially be a DoS vulnerability.

• EMC disturbances

  An attacker induces electromagnetic compatibility (EMC) disturbance that causes a product to fail, e.g. exposing the system to radar radiation, electric shock, or altering the power supply.

  Depending on the nature of the EMC disturbance needed to cause the failure, this might be considered to be an availability problem for the product. However, it is not a DoS vulnerability if it's not related to software or communication.

• Mechanical attacks

  An attacker stops a controller by breaking it with a hammer.

  Depending on how hard you need to hit, this might be considered an availability problem for the product, but it is not a DoS vulnerability since it's not related to software.

• A connector falls out due to vibration

  Depending on the nature of the vibration, this might be considered an availability problem for the product, but it is not a DoS vulnerability since it's not related to software.

• Component aging

  A product fails because an electronic or mechanical component fails due to aging.

  Depending on how long time it takes for the problem to happen, this might be considered to be an availability problem for the product, but it is not a DoS vulnerability since it's not related to software.

Elevation of privilege

An elevation of privilege vulnerability is a product defect that too easily allows an attacker to gain capabilities without proper authorization.

Examples:

• Unauthorized download to a controller

  A person without engineering permissions, e.g. an operator, can download application code to a controller.

• Unauthorized control

  An operator for process section A can start a motor in process section B if the security settings for the objects in process section B have been configured not to grant “operation” permission for operators for process section A.

• Unauthorized system administration

  An unprivileged user can get system administration tasks executed because a system administration agent accepts requests from any user without authorization checks.

Examples not regarded as elevation of privilege vulnerabilities:

• Unexpected access to Windows files

  A user, who has full access rights to a certain file, can change its name via an unexpected user interface, e.g. the “Save As” dialog in a Windows application program.

  If the user has the right to modify the name of the file, this is not an elevation of privilege vulnerability. If a user should be prevented from changing the name of a file, the file should have an access control list (ACL) that prevents this action. The protection should not rely on the user's potential awareness of any user interface that allows a name change.

Training

Below are the links to a workshop and a PowerPoint about vulnerabilities for those who want more information.
Vulnerability Management Workshop-20230323_090449-Meeting Recording.mp4
Vulnerability handling in PAPCP.pptx

References

• ABB Software Vulnerability Handling Policy
• How-to Handle Software Vulnerabilities
• Microsoft’s STRIDE model