Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Oh the POSsibilities

Oh the POSsibilities

VerSprite, Inc

May 05, 2018
Tweet

More Decks by VerSprite, Inc

Other Decks in Technology

Transcript

  1. 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.
  2. 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.
  3. 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.
  4. 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.
  5. 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.
  6. 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
  7. 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.
  8. 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.
  9. 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
  10. 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.
  11. 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.
  12. 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.
  13. 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.
  14. 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.
  15. 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.
  16. Decompilation Analysis • Authentication Routines • Cryptographic Routines • Constant

    Fields • Hard-Coded Credentials • Model-View-Controller • External Dependency Usage • Networking Operation
  17. 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.
  18. 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.
  19. Finding #2 - Override We noticed an “Override” button presented

    by the Employee Login dialog. Override Button Override Code
  20. Finding #2 - Override • The override code provided by

    the override dialog is used to determine the correct override key.
  21. 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
  22. 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.
  23. 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.
  24. 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.
  25. 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”.
  26. 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.
  27. 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.
  28. 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
  29. 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.
  30. 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.
  31. 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 …
  32. 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
  33. 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
  34. 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
  35. 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
  36. 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.
  37. 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.
  38. 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
  39. 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.
  40. 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
  41. 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.
  42. 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
  43. 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)
  44. 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.
  45. 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
  46. 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.
  47. 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.
  48. Track Search • Implements a “byte-wise” search to find complete

    Track1/Track2 data. • Adapted from the track searching algorithm used by Dexter.
  49. 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
  50. Infector - Initialization • The Infector post module accepts the

    following options: • c2host • c2port • callback • jar_path
  51. 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.
  52. 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.
  53. 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.
  54. 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.
  55. 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.
  56. Future Research • RunawayReptar • Universal JAR Jacker • SSL

    Encryption • Pure Java implementation • Payment Terminal Research • POI Traffic Intercept • Embedded Memory Corruption • Unsigned Code Execution
  57. 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.
  58. 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
  59. ?