Target Breach: Vendor Password Exploit
While not yet confirmed by the company, KrebsonSecurity.com has released even more updates on what may have really happened in the Target data breach that resulted in 40 million stolen credit and debit cards, and the loss of 70 million records of personal Target customer data.
The clues all indicate it was another case of an exploited password - on Wednesday, Dell SecureWorks released a private analysis to some of their clients that details how attackers uploaded malware to Symantec’s ThreatExpert scanning device. The attackers used the malware to move the stolen data to a dump server, then an exfiltration server, and eventually their drop site, according to Krebs.
The interesting part is that the username used to create a remote network connection and move the data to a central repository server was the same as the one hardcoded into a certain vendor’s software.
The account name “Best1_user” is used with an IT infrastructure management software, BMC’s Performance Assurance for Microsoft Servers. According to BMC and InformationWeek.com, “Best1_user” is the username used by its software to provide admin-level access to the software’s host machine. However, the company released a statement denying that the password “BackupU$r” (also used by attackers to access the shared drive) was, in fact, a BMC-generated password.
A knowledge article released by the company assures that the BPA (Business Performance Assurance) agent doesn’t have privileged account access - the only privilege granted to the account is the ability to run as a batch job. However, it’s possible that the attackers changed whatever the default password was to “BackupU$r” and then changed the account’s permissions.
According to PCWorld.com, Target confirmed that attackers accessed its system using stolen vendor credentials, but didn’t identify the vendor name. Other reports suggest that the Target compromise may have stemmed from an SQL injection.
##Integrating Two-Factor for App Security As this situation points out, relying on passwords alone to keep attackers from accessing retail networks and payment card data is a poor line of defense. Integrating two-factor authentication with your third-party applications (both hosted in the cloud or on-premises) can provide another layer of defense.
One example involves two-factor integration with web applications (seen above). By leveraging Duo’s web SDK, you can easily add a second factor to your login process that requires a user to verify their identity with their own personal phone. Check out a customer story of how a cloud-based software as a service (SaaS) company successfully integrated two-factor to protect their clients.