ATM Application Whitelisting Security Assessment

During a recent engagement, we were asked to test the security level of an application white-listing solution deployed on the Windows XP ATMs of one of the largest ATM manufacturers in the world. The reason such solutions are in vogue is that Windows XP is no longer supported by Microsoft and no security patches are being released. In order to counter the threat from malware attacking such unpatched ATMs, a number of application white-listing solutions have come about. Prominent among these are Bit9, WincorNixdorf, Mcafee Application Control, etc.

The setup

The solution we tested had two components

• One component secures the user accounts on the systems
• Second component manages the policies which would be implemented on the Windows XP system.

It does not have any pre-requisite with respect to the minimum Service Pack installed on the ATM system. This is the USP for the solution – it does not depend on the security of the underlying system. The solution is expected to protect the system in any scenario.

Two primary accounts are configured during installation:

• Account 1: This is the administrator account created during application installation. It is supposed to be used by engineers who visit onsite for any major ATM maintenance
• Account 2: This is the default account with which system auto-logs on. It is a low-privileged account and is highly restricted in terms of desktop interaction. At startup, all ATM applications are launched and user has no permissions to interact with the desktop interface.

The approach

Since this was not a regular security assessment, we decided on a different approach to testing.

Primary level of testing would be the standard VAPT of the Windows XP system.As per normal process, we ran full port Nmap and Nessus scans to enumerate open ports and known vulnerabilities. However, the application whitelisting solution had additional features which allowed it to restrict network access from specific IP addresses only. In addition to this, it was also able to restrict applications which can access networking services. Access to the exposed services were found to be filtered when the security solution is enabled.

To further test restrictions implemented for remote access to the ATM server, we launched nc.exe on the ATM and tried to remotely connect to it and obtain a shell (cmd.exe). We even assigned ourselves one of the trusted IP address. Since nc.exe was not part of the whitelisted application which had network access, the test case failed. As seen in the screenshot below, disabling the security solution allows us to pass cmd.exe over netcat connection.

Nessus scan was run with credentials but due to system process and services running in a restricted environment, remote authentication could not be executed.

A different tactic

Once it was clear that standard tools and techniques would not help us identify loopholes in the system, we adopted a different approach.The simple objective of this approach was to escalate our privileges in the ATM system and disable the entire security solution. In addition to this, we also tried to identify any other information disclosures or vectors which could potentially compromise the security of an ATM.

The white-listing solution had a .bat script which could be used to enable or disable the security. Although anyone can enable the security, only SYSTEM account user can directly disable it. A token file can also be used to disable the security. However, this token is generated from the management server.

Once the security is enabled, access to application policies, executables and log files is denied. It is also not possible to execute binaries across the system which have not been white-listed.

So our sole aim was to disable the security (by running the disable.bat file)

Below are few of the test cases which we executed to try to bypass the system security.

1. ‘at’ scheduler: Windows XP provides a CLI task scheduler which can be exploited to gain SYSTEM level privileges. The command to gain elevated privileges is:
   C:\>at hh:mm /interactive cmd.exe
2. Privilege Escalation exploits: We ran popular privilege escalation exploits and techniques like kitrap0d, utilman.exe and screensaver hijacking. With the security enabled, these attack vectors failed. Even an administrator did not have permissions to tamper files in the SYSTEM32 folder or edit registry entries.
3. DLL Hijacking: Certain Windows applications are known to be vulnerable to DLL hijacking attack. We were able to execute shellcode to demonstrate custom code execution by exploiting the issue. We used HD Moore’s DLLHijackAuditKitto identify vulnerable components in the system. Only OS applications were found to be vulnerable.
4. Weak Service Permissions: The design of the whitelisting software required some services to be executed with SYSTEM privileges. Since we were running our test cases as an administrator (since this is the account that would be used by onsite engineers), we were able to modify the binary path for some of these critical services. Once we restart these services, they execute our binary with SYSTEM privileges.
5. Review of application policies: In addition to system security parameters we also reviewed the policies implemented by the white-listing tool. We identified issues like Over-ride accounts and white-listed directories.
   • As a worst-case scenario, the application provides a facility to administrators to configure over-ride accounts. These accounts have the privilege to execute the .bat script file and disable the complete security. Since we were running with administrator privileges we could use the ‘net user’ command and reset the password of such over-ride accounts and gain access to it.
   • The application allows the administrator to white-list complete directories – any executable run from within these directories are not blocked.  We ran mimikatz.exe from such directories to extract passwords from memory. Since an over-ride was configured, we could easily obtain it’s password as well.
   • Interestingly, we found that executables run from CD-ROM drives and USB removable devices were not being blocked.

Recommendations

Though the application whitelisting solution was pretty effective in blocking EXE files from be executed on the system, however by trying different tactics we were able to disable the security mechanism and take complete control of the ATM.

In this regard, well-defined processes also play an important role in the security of an ATM system.It is necessary to define when and how an engineer will be granted access to the ATM. If system configuration and troubleshooting can be executed remotely, it helps reduce the dependency on onsite engineers. Usually engineers use USB devices to deploy configuration changes and binary patches. These removable devices are the biggest threat to ATM systems.

The integrity of the deployed solution (along with Windows XP) should also be validated before deployment. The white-listing policies should be documented so that unnecessary and legacy rules are removed.Due to these unnecessary policies (white-listed folders, over-ride accounts) we were able to execute ‘hacking’ tools and gain sensitive account credentials from the system memory and thereby disarm the system security.