An Integrator s Worst Nightmare

Transcription

1

2 An Integrator s Worst Nightmare Presented by: Nicholas J. Percoco Vice President, SpiderLabs

3 Agenda Introduction Case Study About the Integrator Support Structure Timeline of Events Aftermath Prevention Questions

4 Introduction Many Retail and Restaurants have a HIGH level of risk for compromise. 75% of these merchants are Level 4 (PCI) Nearly 100% relay on Integrators for installations, maintenance, and support. Compromised Merchants usually go out of business or are severely impacted, if hacked.

5 Case Study: About the Integrator Regionally based in Illinois, Wisconsin, and Michigan. Over 500 customers all running HackMe POS. Centralized call center and remote field support. Never had a compromised merchant until now.

6 Case Study: About the Integrator Spent most of 2007 working to Merchants upgrade the HackMe POS PABP version. About 90% of their clients have purchased upgrades. Field support teams performed the upgrades based upon the instructions of HackMe.

7 Case Study: Support Structure Merchants place calls into number. Support Tech looks up their company information in a spreadsheet and logs a support ticket (e mail to team). Someone picks up the ticket and begins working with the Merchant. If the support can be performed remotely, it is. If not, a Field Support Tech is dispatched.

8 Case Study: Support Structure Remote Access Support Tech looks up the IP address (or modem number) in a spreadsheet. A unique support password is used for each location. The password is stored in the spreadsheet. The password is never changed after the installation of the POS system.

9 Case Study: Support Structure Onsite Support Field Support Tech brings a USB key fob with them that contains: The same spreadsheet used by Remote Support The remote access client software A copy of the latest HackMe POS software Master license key for HackMe POS Field Support Tech looks up the passwords and logs into the system. If needed, he/she copies the required software over to the system.

10 Case Study: Timeline of Events May 8 th, 2008 Merchant X is notified they are a CPP. What is a CPP? May 9 th, 2008 Merchant X contracts with Trustwave to begin an investigation. May 10 th, 2008 Trustwave arrives onsite and gathers evidence: Forensic Disk Images Firewall Logs

11 Case Study: Timeline of Events May 11 th, 2008 Trustwave begins analysis of systems and logs. The results reveal the following historical events: System was first installed January 10 th, 2007 by Integrator. System was upgraded on March 1 st, 2008 by Integrator. Upgrade was performed onsite by Field Support Tech who also upgraded about 20 other locations during that month. March 22 nd, 2008 Successful Login from IP addresses in Russia, Brazil, and Thailand. March 23 rd, 2008 Someone installs Network Sniffer March 28 th, 2008 Someone installs Serial Sniffer

12 Case Study: Timeline of Events Analysis of the Sniffer output revealed: Network Sniffer was NOT successful at capturing credit card data due to the HackMe POS being PABP compliant (upgraded March 1 st ) Serial Sniffer WAS successful at capturing credit card data including Full Track data. Files Recovered included: comcopy.sys, delete.bat, install.bat, settings.reg, wdreg.exe, wsus.ini, psexec.exe Windows Systems Event Logs recovered from several of the POS terminals contained log records for the creation and start of services named comcopy and PsExec by the Windows Administrator. The wsus.ini files recovered were found to contain serial port traffic captures. Analysis of the logs revealed the presence of track data.

13 Case Study: Timeline of Events Questions left unanswered: How did the attacker get the password for the location? Was it an internal threat? Someone working at the Integrator perhaps? If it wasn t an internal threat, how else could the attacker get the password? Trustwave reviewed the remote access process, and external vulnerability profile of the merchant and nothing stood out other than static passwords. Where any other merchants supported by Integrator having similar issues? But At the time Trustwave s investigator report, the answer was No.

14 Case Study: Aftermath 3 weeks after Trustwave issued their investigation report, 10 more CPPs were identified. ALL were support by the Integrator!! Trustwave launched an investigation into these merchants and found

15 Case Study: Aftermath 9 of 10 had identical POS and network configurations to the original merchant. All running PABP compliant software All had firewalls in place All had remote access in place using unique passwords 1 Merchant was different

16 Case Study: Aftermath This Merchant had: An older version of the POS software running No Firewall in place Had been patched only once since it was installed The system was vulnerable to dozens of remote exploits It also had something very special located on its hard drive

17 Case Study: Aftermath A Spreadsheet containing details on over 300 different merchants, including: The name and location The IP address Remote Access PASSWORDS The spreadsheet was found in a directory with HackMePOS install packages and the remote access client software.

18 Prevention Use Hardware based Firewalls Managed if no skill sets exist Use only PABP/PA DSS Software Secure Remote Access: Enabled Only When Needed Strong Password / 2 factor Source IP ACLs Keep AntiVirus Updated Do NOT allow employees to use systems for non business related activity.

19 Questions? Nicholas J. Percoco Vice President, SpiderLabs