NewsBites Drilldown for the Week Ending 21 August 2020

by SANS Blog on August 24, 2020

John Pescatore
– SANS Director of Emerging Security Trends

Are Your Asset Inventory and Vulnerability Management Processes Robust Enough to Discover OT/IoT Devices?

This week’s Drilldown will focus on one item (included below) from NewsBites Issue 66: detailing serious vulnerabilities disclosed in Diebold and NCR ATM machines.

The vulnerabilities disclosed in the Diebold and NCR ATM software require an attacker to have physical access to the network to which the ATM kiosks are connected, which limits (but does not eliminate) the risk of exploitation. While ATMs are primarily in use at bank branches, both Diebold and NCR make freestanding or “lobby” versions that are often in use at non-banking retail environments.

The immediate and most obvious action is to check whether your company uses any Diebold Nixdorf’s ProCash 2100xe USB ATMs running Wincor ProBase software or NCR’s SelfServ ATMs running APTRA XFS software. If so, make sure that the vendor updates are applied.

Sponsorships Available

An important follow-up is to determine where other operational technology (OT) devices are in use that may have the same vulnerability. The critical question is: Do you have an accurate inventory of what is connected to your network? Does that inventory include OT and IoT devices–essentially, everything else beyond PCs, servers and network infrastructure?

All too often the answer to these two questions is: no and no. Performing a vulnerability scan and finding that 20% of the PCs and servers you discover were not on the previous scan is not unusual. Vulnerability discovery processes that rely on scans will not discover assets that don’t reply, and agent- or credential-based discovery will only find the “cooperative” assets that have agents installed or are registered in the domain. Many OT devices do not show up with these techniques.

Passive vulnerability discovery and other types of active network traffic monitoring are often required to discover OT and IoT devices that are on corporate networks. Many of those devices may have the same vulnerabilities that have been exposed in the Diebold and NCR software.

______________________________________________________________________________

Diebold and NCR Release Fixes for ATM Vulnerabilities

(August 20, 2020)

Attackers could exploit security flaws in ATMs made by Diebold Nixdorf and NCR to modify the amount of currency being deposited to a payment card, known as “deposit forgery” attacks. Vulnerability notes from Carnegie Mellon University’s CERT Coordination Center indicate that the problem is due to the fact that the affected machines “do not encrypt, authenticate, or verify the integrity of messages between [Diebold’s cash and check deposit module (CCDM) and NCR’s bunch note accepter (BNA)] and the host computer.”

[Editor Comments][Pescatore] This attack requires physical access to succeed, but it’s important to note that the Diebold Nixdorf and NCR products were built assuming that they would be used on trusted networks and “do not encrypt, authenticate, or verify the integrity of messages.” This is an all-too-common flaw in “operational technology” that was designed with the assumption that only good guys would have access to the network on which the OT device was deployed. Detailed code review by security experts often point this out; simple external vulnerability scanning usually does not. There are very few scenarios anymore where sensitive traffic over any network should not at least have integrity controls, if not encryption.

[Neely] Operational technology, such as ATMs, often depends on physical rather than logical security protections. The lock on the door, coupled with segmented or isolated networks, often do not include appropriate protections for traffic across the corporate backbone or internet. Even worse, the purpose-built systems may not have the capacity to add encryption or integrity checks, which means you need to implement external controls.

[Murray] It is ironic that the first public use of cryptography was for ATMs. The Data Encryption Standard (DES) was developed from the LUCIFER implementation used in early ATMs.