September 24, 2020

GHR 116 – Point-Of-Sale (POS) Hacking

Threats

  • Keystroke loggers grabbing the track 1 and/or track 2 from the credit/debit cards
    • Keystroke logger installed via USB
    • Keystroke logger installed from an attacker’s laptop on the POS VLAN.  Unplugging a terminal, jacking in, exploit the other non-protected terminals in the POS VLAN.
    • Keystroke logger installed via the internet because we failed to stop the terminal from reaching it.
  • Memory scrappers to collect the clear text track1/2 data in memory
    • Installed in the same ways as above.
  • Card Holder Data (CHD) extracted at rest and/or in transit while operating in Store & Forward (S&F) mode.
  • Card Holder Data (CHD) extracted at rest and/or in transit while creating a Timeout Reversal.
  • Card Holder Data (CHD) extracted at rest and/or in transit while performing for batch settlements.
  • CHD sniffed and collected in transit, ANYWHERE along the path.

Questions for Oracle/Micros

  • Is CHD kept on the terminal during S&F operations?  In other words, if the terminal loses communication with the server, do the terminal itself store the CHD?
  • If the server(s) goes down or is otherwise unreachable, do ALL terminals stop functioning or can they function independently using offline authorization mode of some sort?
  • If the terminals and servers are online, but the network path upstream to the payment gateway/processor drops, does the S&F operation happen on the server?
  • Do the Micros terminals emulate a keyboard from the Mag Stripe Reader (MSR)?  If so, a simple keystroke logger is in play here.
  • Are there application logs on the terminals themselves that can be exploited?  If so, this opens up another data at rest attack surface.
  • Are the records in the SQL DB hashed and salted?
  • Tokenization and/or point-to-point encryption start and end where?  (e.g. Server to payment processor only, MSR to server, all the way MSR to Issuer, etc.)