According to articles from ThreatPost and Krebs On Security, attackers were able to leverage seemingly innocuous data from multiple sites and then use that data to create fake accounts on an ADP portal and then gain access to PII for employees at victim companies.
U.S. Bank’s Ripley acknowledged that the bank published the link and company code to an employee resource online, but said the institution never considered that the data itself was privileged.
“We viewed the code as an identification code, not as an authentication code, and we posted it to a Web site for the convenience of our employees so they could access their W-2 information,” Ripley said. “We have discontinued that practice.”
What happened? ADP makes information available to employees of it’s client organizations (payroll data, tax forms, etc.). As a convenience to the client organization, the organization can a) setup an account for each employee [manually] when the organization account is setup or b) give employees a custom link and custom access code that, along with private information that should be known only to the employee (date of birth, employee ID or Social Security number) that they can use to setup their own account. Some client organizations opted for option b and posted the custom link and access code to a website that was available to the public. Attackers, armed with the custom link and access code then only needed to get the date of birth (Facebook?), employee ID and / or Social Security number (generally easy to obtain via Social Engineering attacks like phishing or vishing). Once they had both pieces of the puzzle, they were able to log into the ADP website and get the information necessary to file false tax returns (or then leverage that in another / a larger attack [identity theft, etc.]).
Who failed? ADP made the portal available but required multiple factors (the custom link, the custom access code and then the employee information [date of birth, employee ID, Social Security]) to gain access. The victim organizations posted the custom links and access codes to publicly accessible locations but did not believe these to be sensitive (after all, no PII on the employees was posted). Ultimately, I believe a strong case could be made that either party failed but the actual fault pr
What’s the take-away? Security isn’t easy and it’s not a set-it-and-forget-it process. The ADP portal presumably has HTTPS enabled (and required) by default, has been tested for obvious problems like cross-site scripting (XSS), SQL injection (SQLi), code execution, etc. and (again, presumably, I haven’t tested / confirmed this but it’s reasonable to believe that any obvious failures like this would have led to ADP being crucified by now) but they’re trusting users to understand and employ good OpSec / InfoSec. The victim organizations didn’t post anything they believed to be sensitive, but they did remove two of the three barriers (the custom link and code) that an attacker needed to gain access to sensitive information. The take-away, assume that *everything* is sensitive / privileged information. If you have links like the ADP links, don’t publish them publicly but publish them to an intranet or, at least, password protected site.