Oh the POSsibilities - Speaker Deck

Slide 1

Slide 1 text

Oh the POSsibilities

Slide 2

Slide 2 text

Who are we? •Anthony Sasadeusz (@_nullsector_) •Security Researcher @VerSprite •Interested in hardware security, communication protocols, reverse engineering, and vulnerability research. •Fabius Watson (@FabiusArtrel) •Security Researcher @VerSprite •Interested in reverse engineering, vulnerability research, exploit development, and post-exploitation tactics.

Slide 3

Slide 3 text

Overview - n00bz • This was our first security research project. We came into this having never held a security research position. • We were tasked with researching Point-of-Sale security due to it's huge scope, giving us tons of creative freedom as new researchers. • We had to learn which resources, tools, and techniques were best suited for the task at hand.

Slide 4

Slide 4 text

Overview - POS • POS security affects several service industries such as food, retail, and hospitality as well as those involved with financial technology. • Our initial research revealed a number of high-profile security breaches resulting from the abundance Point-of- Sale malware. • We decided to further investigate POS malware in order to better understand adversarial objectives and attack methodology.

Slide 5

Slide 5 text

POS Malware

Slide 6

Slide 6 text

POS Malware • Infection Vectors • Phishing • Brute Force Attacks • Credential Theft • CC Data Theft • RAM Scraping • Keylogging Risk model has not changed significantly enough for criminals to adopt new techniques.

Slide 7

Slide 7 text

Track Data • Track1/Track2 data defined by ISO/EIC 7813 • Parsing is done based on known sentinel values. • Includes, PAN, cardholder name, expiration date, CVV.

Slide 8

Slide 8 text

Malware Attack Surface - POS Terminals • Top Supported Platforms • Windows 7 • Windows 10 • Windows Server Edition • Windows 8.1 • Windows POSReady 7 • Less Often… • RHEL • CentOS • Ubuntu • Solaris • Mac OSX

Slide 9

Slide 9 text

Malware Attack Surface - POS Software • There are thousands of options for payment application software. • Examples • Oracle MICROS Systems • Oracle NetSuite • NCR AlohaPOS • Diverse Landscape • Difficult to verify the security of 3000+ applications.

Slide 10

Slide 10 text

POS Malware - BlackPOS • Since its discovery in 2012, several variants have emerged. • A variant of this malware was detected during forensic analysis of the 2013 Target breach. • Methods of exfiltration include E-mail, FTP, and SMB.

Slide 11

Slide 11 text

POS Malware - Dexter • While most RAM scrappers utilize regular expressions, Dexter implements a custom byte-wise RAM scraping algorithm for efficiency. • Drops a custom keylogging library. • The leaked source code is available online on GitHub. • https://github.com/nyx0/Dexter

Slide 12

Slide 12 text

POS Malware - MajikPOS • Attackers scan for VNC and RDP services with weak passwords to gain entry into the system. • Once access is established, the malware is installed. • This malware is written in .NET and is built for modularity.

Slide 13

Slide 13 text

POS Malware - UDPoS • UDPoS masquerades as the “LogMeIn” secure remote desktop software. • It incorporates anti-virus and virtual machine detection. • The data captured by the malware is exfiltrated via DNS.

Slide 14

Slide 14 text

POS Malware - PinkKite • PinkKite is believed to be a successor of the AbaddonPOS malware. • It’s extremely light weight at only 6KB in size on disk. • Programmed to run only for 12 hours and does not persist. • Performs data exfiltration via the RDP protocol.

Slide 15

Slide 15 text

Case Study #1 POSIM EVO

Slide 16

Slide 16 text

What is POSIM EVO? • A Point-Of-Sale and inventory management system. • POSIM EVO’s core components are written in Java. • The main application is started by a C++ launcher. • MariaDB is used for the database backend. • Includes Java 8 and MySQL utilities.

Slide 17

Slide 17 text

Reversing Java Applications • Java is a “write once, run anywhere” (WORA) programming language that runs on a Java Virtual Machine (JVM). • Java applications are compiled to bytecode rather than machine code. • Bytecode may be reconstructed into relatively accurate Java source code representation.

Slide 18

Slide 18 text

Bytecode Viewer • Bytecode Viewer is an advanced, lightweight Java bytecode viewer and GUI Java decompiler. • We used Bytecode Viewer to decompile POSIM EVO’s main application. • This allowed us to analyze the source code of POSIM EVO for security vulnerabilities.

Slide 19

Slide 19 text

Decompilation Analysis • Authentication Routines • Cryptographic Routines • Constant Fields • Hard-Coded Credentials • Model-View-Controller • External Dependency Usage • Networking Operation

Slide 20

Slide 20 text

Finding #1 - Hard-coded Credentials • We identified root database credentials defined as a password constant in the application source. • We found several usages of the database password constant within the application.

Slide 21

Slide 21 text

Finding #1 - Hard-coded Credentials • Using the credentials we found, we can authenticate to MariaDB on port 13306. • User-Defined Functions (UDF) may be used to achieve code execution by the MariaDB root user. • MariaDB is started by the MariaDB_EVO service which runs as LocalSystem. • We are able to demonstrate an attack that leverages these components in order to achieve SYSTEM code execution against the POSIM database server.

Slide 22

Slide 22 text

Finding #2 - Override We noticed an “Override” button presented by the Employee Login dialog. Override Button Override Code

Slide 23

Slide 23 text

Finding #2 - Override • The override code provided by the override dialog is used to determine the correct override key.

Slide 24

Slide 24 text

Finding #2 - Override • The override key is calculated using the override code • We noticed that there weren’t any complex cryptographic operations involved, so we decided to try and write a keygen. GIF ME

Slide 25

Slide 25 text

Finding #2 - Override • We reimplemented the key generation algorithm in Python allowing us to generate valid override keys for any given override code. • This allows us to bypass all login dialogs throughout the application.

Slide 26

Slide 26 text

Finding #3 - Auto-Update • POSIM EVO stores an installation binary of the latest known version in its database. • We learned that when POSIM EVO is launched, the current software version is compared to the version of the stored installation binary. • If the versions are equal, POSIM EVO is launched normally. • If the database version is higher, the user is prompted to update POSIM EVO. • If the database version is lower, the current binary’s installer is uploaded to the database.

Slide 27

Slide 27 text

Finding #3 - Auto-Update • DBBackup.getSoftwareState() is called to retrieve the version of the database’s installation binary. • If the current software version is newer than the version in the database, then the database binary is replaced.

Slide 28

Slide 28 text

Finding #3 - Auto-Update • The installation routine attempts to download the latest POSIM EVO installation binary from the database. • The installerFileName must be “POSIM_EVO.exe”.

Slide 29

Slide 29 text

Finding #3 - Auto-Update • We can exploit POSIM EVO’s auto-update “feature” by manually updating the database installation binary. • In order to trigger the auto-update routine • The file name must be equal to “POSIM_EVO.exe”. • The fileVersionHash > client’s software version. • Whenever the binary download is complete, it’s automatically executed by the POSIM EVO launcher. • Using the database credentials discovered earlier, we are able to abuse POSIM EVO’s auto-update feature.

Slide 30

Slide 30 text

Case Study #2 AmigoPOS

Slide 31

Slide 31 text

What is Amigo POS? • A Point-Of-Sale software suite for the hospitality industry. • POS / Tablet POS • Back Office • Remote Display • Cloud Service • Call Center • The application is built using the .NET Framework. • SQL Server Express is used for the database backend.

Slide 32

Slide 32 text

Back Office • Through black-box testing, we discovered that Amigo POS’s “Back Office” application accepts a few interesting command line arguments. • tempuser • Creates a temporary back office admin login in case of system lockout. • Can login to the POS application. • Can login to Back Office application. • db • SQL Server settings management • SQL Server tools • SQL query window

Slide 33

Slide 33 text

Running Code with “xp_cmdshell” • Amigo POS’s default SQL Server installation settings starts the MSSQL$AMIGOPOSINSTANCE service as LocalSystem. • Standalone installations of SQL Server Express are typically configured to start as NT Service\MSSQL$SQLEXPRESS. • The xp_cmdshell extended stored procedure may allow commands to be executed using SQL queries. • By leveraging xp_cmdshell through the Back Office application’s SQL Query window, we may execute code as the SQL Server user.

Slide 34

Slide 34 text

Case Study #3 AccuPOS

Slide 35

Slide 35 text

What is AccuPOS? • Provides Point-Of-Sale, inventory management, and time clock solutions. • The application and its components are written in Java. • Transaction data is stored in a cloud database backend. • Communication packets are formatted as XML and transmitted over SSL.

Slide 36

Slide 36 text

Reversing AccuPOS • We used Bytecode Viewer to analyze a decompilation of the application. • Communications between AccuPOS and its cloud database backend were treated as out-of-scope. • We approached code analysis in the same way that we have described earlier. • It took us a bit longer to find anything of interest in AccuPOS. We had to think outside of the box …

Slide 37

Slide 37 text

What Next?

Slide 38

Slide 38 text

Insecure Java Key Store? • We identified AccuPOS Java Key Store (JKS) resources. • We determined the JKS password using static analysis. • We considered using JKS keys to decrypt network traffic. • We were able to extract JKS contents using KeyStore Explorer, however, we were unsuccessful in decrypting communication traffic. FAIL

Slide 39

Slide 39 text

Open Ports? • We were curious about the network attack surface of the POS application. • We analyzed network traffic using Wireshark and noticed a connection attempt on port 12345. • We used netstat to confirm a TCP listener created by Java. TCP Listener

Slide 40

Slide 40 text

Open Ports? • We traced the network activity to the JustOneInstance class. • This class is designed to ensure that only one instance of AccuPOS is active. • No socket data is read, which makes exploitation unlikely. FAIL

Slide 41

Slide 41 text

File Permissions? • We used icacls to review the security descriptors of AccuPOS and its components. • This revealed that all Authenticated Users are provided with modify access to everything. (I)(M) = Inherited Modify Access WIN

Slide 42

Slide 42 text

JAR Jacking • JAR files are basically ZIP archives that contain Java .class files, media resources, and XML manifest data. • Java .class files contain Java bytecode that can be executed on the JVM. • JAR modification allows us to reprogram the .class files. • We decided to dig deeper into the capabilities of JAR Jacking from a post-exploitation perspective.

Slide 43

Slide 43 text

Java Implant • An implant is covert software installed for attacker defined capabilities. • What type of capabilities might a minimal implant employ? • Push - Upload files to infected host. • Pull - Download files from infected host. • Exec - Execute code on infected host.

Slide 44

Slide 44 text

RunawayReptar Infector + Implant + C2 Photo credit: Phil from Sydney, Australia (Themeparkgc)

Slide 45

Slide 45 text

Attack Plan 1. Inject attacker implant code into the Payment Application JAR from low privilege context 2. Modify a Java .class file within the Payment Application JAR to launch our implant code 3. Demonstrate capabilities (Command Execution, Persistence, RAM Scraping, Disinfection) 4. Profit!!! Report to vendor

Slide 46

Slide 46 text

Architecture • Ruby Infector (MSF Post Module) • Java Implant w/JNA C++ Module • Python C2 (Flask)

Slide 47

Slide 47 text

C2 - Design • A command-and-control (C2) server using the Flask framework for Python. • Sqlite3 database backend. • Web interface for handling operator tasks. • Web endpoints for handling Implant responses.

Slide 48

Slide 48 text

C2 - Protocol Registration • The Infector registers a target host with the C2 by providing: • Machine GUID • System Information • Registration Key • Persistence Variable • Original JAR file

Slide 49

Slide 49 text

C2 - Protocol Authentication • C2 communications are XOR encrypted with a unique key. • Initial key exchange is encrypted using the registration key. • C2 packet data is Base64 encoded prior to encryption.

Slide 50

Slide 50 text

Implant - Design • The Implant follows the singleton design pattern. • Implant classes extend java.lang.Thread for asynchronicity. • C2 commands were chosen to illustrate realistic attacker capabilities. Photo Credit: Nara.nra28 / WikiMedia Commons

Slide 51

Slide 51 text

RAM Scraping

Slide 52

Slide 52 text

Low-Level Java • Development of the Implant’s “dump” routine required us to learn more about Java internals and low-level Java capabilities. • sun.misc.Unsafe • Java Ordinary Object Pointers (OOP) • Java Compressed OOP • Java Native Access (JNA)

Slide 53

Slide 53 text

sun.misc.Unsafe • Exposes methods which allows for native memory access. • Need to jump through hoops using reflection in order to use. • Needed to leak an address of an object allocated in the JVM heap.

Slide 54

Slide 54 text

Java Ordinary Object Pointers • An OOP is just a plain address of an object in the JVM heap. • Same size as a native machine pointer • A Compressed OOP is an encoded address. • Is a 32-bit address that size scaled by a factor of 8 then added to a 64-bit base address. • Saves memory usage. • Depends on the maximum heap size of the system. Integer Object on a 32-bit VM Integer Object on a 64-bit VM without compressed OOPs Integer object on a 64-bit VM with compressed OOPs Class Pointer Mark int 96 bits Class Pointer Mark int 160 bits Class Pointer Mark int 128 bits

Slide 55

Slide 55 text

Java Native Access • JNA acts as a bridge between Java and native C code. • We use it to leverage Win32 native process memory functions. • A few steps need to be taken in order to get access of the memory region that we are interested in. • Get the PID of the Java process. • Obtain a HANDLE to the process. • Query information about the memory region. • Copy the memory region contents to a buffer.

Slide 56

Slide 56 text

Java Native Access • Now we can pass a copy of the JVM Heap to our RAM scraper. • Our RAM scraper is a native Dynamic Link Library (DLL). • The scanProcessMemory function called through JNA returns a track data buffer.

Slide 57

Slide 57 text

Track Search • Implements a “byte-wise” search to find complete Track1/Track2 data. • Adapted from the track searching algorithm used by Dexter.

Slide 58

Slide 58 text

Infector

Slide 59

Slide 59 text

Infector - JAR Jacking • The Java Archive Tool may be used for simple JAR modifications. • Our JAR Jacking operation will be performed by the Infector. • The Infector is a Metasploit Framework (MSF) post-exploitation module that leverages the Meterpreter API • In order for the Implant to be triggered, the Infector must modify an existing class. • An ideal target should have the following characteristics: • Is called soon after the application is launched • It’s functionality is easy to re-implement with accuracy

Slide 60

Slide 60 text

Infector - Initialization • The Infector post module accepts the following options: • c2host • c2port • callback • jar_path

Slide 61

Slide 61 text

Infector - Key Generation • The XOR key used for implant authentication is a randomly generated UUID. • The target host’s MachineGUID registry key is stored in the C2 database for host identification.

Slide 62

Slide 62 text

Infector - Class Patching • The c2host, c2port, and callback options are patched into the Implant class by replacing the hardcoded unique values 0x7FFFFFFF, 0x6FFFFFFF, and 0x5FFFFFFF respectively.

Slide 63

Slide 63 text

Infector - Registration • The new Implant is registered with the C2 by the Infector • Registration information including the original JAR file are submitted to the C2 web endpoint defined by c2host and c2port.

Slide 64

Slide 64 text

Infector - Resource Bundling • DLL resources and .class files are sequentially added to a copy of the original JAR file • All .class files are patched with the version number of the original JAR prior to being added.

Slide 65

Slide 65 text

Infector - JAR Upload • Finally, the modified JAR copy is uploaded to the target, replacing the original JAR with our infected copy. • Following infection, the application is started to launch our Implant. All subsequent application launches will also trigger our Implant code.

Slide 66

Slide 66 text

Future Research • RunawayReptar • Universal JAR Jacker • SSL Encryption • Pure Java implementation • Payment Terminal Research • POI Traffic Intercept • Embedded Memory Corruption • Unsigned Code Execution

Slide 67

Slide 67 text

Mitigations • Implement code signing and file signature verification. • Make sure applications run with the least privilege necessary. • Avoid assigning excessive file permissions. • Don’t include hard-coded credentials. • Don’t write your own cryptographic algorithms.

Slide 68

Slide 68 text

Takeaways • Exploits aren’t always necessary. • Java simplifies reverse engineering. • Credentials are often available in clear text. • Don’t trust POS applications with your data… • P2PE helps to remove risk from applications