More charges filed against TJMax hackers
It appears that yesterday more charges were filed against the TJ Max hacker Albert “Segvec” Gonzalez. These new charges stem from electronic break-ins to the Heartland Payment Systems credit card processing center as well as Hannaford Brothers, 7-Eleven as well as two additional un-named victims.
Gonzalez, who is a former US Secret Service informant, is already in custody on charges related to the TJ Max break in. Also charged as two unnamed Russian persons who are suspected of being Gonzalez’s partners in the operation.
Based on information released these attacks do not appear to be the standard “script kiddy attacks” that we as sysadmins are used to dealing with. These attacks were well thought out and well executed, granting the attackers access to corporate and production networks for months in some cases.
The software, which was custom written for these attacks when tested against a variety of anti-virus and anti-spyware software before the attack was launched. Additionally it was written to delete all trace of itself in order to avoid detection.
The truly pathetic thing about this is that according to the documents, the attacks all started via SQL Injection attacks. Which means that they could have been avoided if basic security protocols and procedures were being followed on the websites in question. These basic security protocols include:
- No dynamic SQL either in stored procedures or from the websites directly.
- If dynamic SQL must be used in stored procedures, use as few actual values from the Website as possible. (For example if sorting a result set which must be done through dynamic SQL don’t pass in the column name from the website, pass in an ID which means nothing except that the stored procedures knows that 1 = Column2, 2 = Column4, etc.
- Clean the data before you pass it to the database. This is where the website developers and the DBAs really need to get along. The database can’t secure it self, the Website has to check each value that is being passed in and ensure that the values won’t harm the database in any way.
- Disable xp_cmdshell as well as anything else that you aren’t using (oh yeah and don’t use xp_cmdshell on SQL Servers that websites have access to).
- Don’t allow the account that the website uses to do anything more than it needs. This means not using ANY fixed server or fixed database roles. Just the minimum rights that are possible, in a perfect world this means execute rights to stored procedures only.
If these basic rules had been followed then the hackers probably wouldn’t have been able to get into the system and we wouldn’t have had these problems to begin with.
It also would have helped if these companies were actually following the PCI rules which they are required to follow but apparently weren’t. If they were then this wouldn’t have been an issue either as they wouldn’t have been storing anything, and everything in flight would have been encrypted and basically worthless.
Denny