Oh the POSsibilities

Transcript

1. Oh the POSsibilities
2. 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.
3. 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.
4. 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.
5. POS Malware
6. 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.
7. 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.
8. 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
9. 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.
10. 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.
11. 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
12. 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.
13. 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.
14. 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.
15. Case Study #1 POSIM EVO
16. 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.
17. 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.
18. 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.
19. Decompilation Analysis • Authentication Routines • Cryptographic Routines • Constant Fields • Hard-Coded Credentials • Model-View-Controller • External Dependency Usage • Networking Operation
20. 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.
21. 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.
22. Finding #2 - Override We noticed an “Override” button presented by the Employee Login dialog. Override Button Override Code
23. Finding #2 - Override • The override code provided by the override dialog is used to determine the correct override key.
24. 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
25. 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.
26. 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.
27. 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.
28. 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”.
29. 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.
30. Case Study #2 AmigoPOS
31. 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.
32. 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
33. 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.
34. Case Study #3 AccuPOS
35. 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.
36. 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 …
37. What Next?
38. 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
39. 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
40. 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
41. 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
42. 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.
43. 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.
44. RunawayReptar Infector + Implant + C2 Photo credit: Phil from Sydney, Australia (Themeparkgc)
45. 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
46. Architecture • Ruby Infector (MSF Post Module) • Java Implant w/JNA C++ Module • Python C2 (Flask)
47. 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.
48. 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
49. 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.
50. 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
51. RAM Scraping
52. 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)
53. 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.
54. 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
55. 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.
56. 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.
57. Track Search • Implements a “byte-wise” search to find complete Track1/Track2 data. • Adapted from the track searching algorithm used by Dexter.
58. Infector
59. 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
60. Infector - Initialization • The Infector post module accepts the following options: • c2host • c2port • callback • jar_path
61. 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.
62. 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.
63. 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.
64. 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.
65. 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.
66. Future Research • RunawayReptar • Universal JAR Jacker • SSL Encryption • Pure Java implementation • Payment Terminal Research • POI Traffic Intercept • Embedded Memory Corruption • Unsigned Code Execution
67. 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.
68. 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
69. ?