Welcome to AppFail
You last visited: never

Welcome to AppFail

Posted on 2009-07-25

Security Post

Network Solutions' web servers were compromised, and some extra code was added to their payment processing service, allowing the perpetrators to syphon off the credit and debit card information for all transactions processed through the Network Solutions payment service. This breach not only affected customers of Network Solutions, but the customers of the over 4500 e-commerce sites that use the service.

The breach was said to have occurred around March 12, 2009, and all transactions processed from that point on, until it was discovered on June 8, 2009 were captured and sent off site by the perpetrators. However, Network Solutions did not start to notify customers until July 24th, 2009. Network Solutions has opted to notify the effected persons and businesses directly, to avoid placing this expensive burden on their own small e-commerce business customers, and they are also offering 12 months of free credit monitoring services from TransUnion. While these are respectable actions on behalf of Network Solutions, It doesn't explain the 6+ week long delay between discovery of the breach and notification of the effected customers. Knowing that your credit card has been stolen 6 weeks earlier is a far more effective way to prevent loss than a year of credit monitoring services after the fact. Network Solutions has not released any details about how the breach occurred or how exactly the additional code was added to their payment processing system.

Network Solutions is only the latest, and actually one of the smallest in a series of information disclosures that have occurred recently in the payment processing industry. What makes the Network Solutions breach interesting is that is was on going, not a single attack that took all of the records and made off with them, but instead installed itself as part of the system and continued to syphon off new records for months. Large payment processors such as Heartland Payment Systems (100 million credit cards disclosed), TJX (94 million), CardSystems Solutions (40 million) and Hannaford Supermarkets (4 million) have all been victims of these attacks. I hesitate to actually call these payment processors victims in this case, as they all should have had much stronger Information Assurance policies and procedures to prevent these specific types of breach. A database of 100 million credit cards is a very large bullseye to have painted on your systems; as such, steps need to be taken to safeguard that data. Another part of the system that seems to fail is the 'CVV' system, the 3 digit verification code on the back of your credit card, is not supposed to be stored by anyone. The idea behind this is to prevent attacks like this from disclosing the CVV value, so the hacker only gets the credit card number, and when they go to use it, they are prompted to provide the CVV which they do not have, as they do not physically have the credit card. It is against the Visa and MasterCard Merchant terms of service to store this value, however I do not feel that this rule is enforced strongly enough, and doubtless some of these breaches have includes this information, the Network Solutions attack is different in that it was not the database that was compromised, but the live transaction system.

Proper information security should implement defence in depth, reducing the exposed attack vectors by layering or stacking security systems, so that a successful attacker is required to defeat more than one layer of security. This eliminates the "single point of failure", meaning that even a 0day exploit cannot leave your secure system exposed to the world. One way that this can be implemented specifically in the payment processing arena, is using the public key cryptography for credit card transactions. Some of you will be quick to point out that most credit card transactions do take place over an SSL/TLS encrypted connection, while this is true, TLS is providing transport encryption, and preventing someone from eavesdropping on the transaction, it does nothing to protect the credit card once it arrives at the payment processor; as such, Storage Encryption is required to prevent unauthorized parties from making use of the data in the database. Traditional (symmetric) encryption for a web system that accepts credit cards, such as Network Solutions, is of dubious value, as the key used to decrypt the credit card information would necessarily be the same as the one used to encrypt it, so the web server would require that key in order to encrypt the cards to store them in the database. If that web server is compromised, that key is also compromised, and therefore the credit card data is compromised as well. With public key cryptography, separate keys are used for encryption and decryption, allowing the web server to store the data encrypted but not have the ability to decrypt it. This way if the web server is compromised then only the key used for encryption (the public key) is exposed, and as the name suggests there is no harm in exposing the public key. The decryption and processing of the credit card transactions should be done offline or out-of-band, so that this process cannot be compromised in the same way that the web server was. Even if it is not possible to implement such a complex solution as this, having the database fields that store the credit card data be write-only for the web server, so if it is compromised, the credit card data cannot be read back via the compromised system. This solution does not necessarily address the specific problem that Network Solutions was faced with, their system was modified to intercept the transactions and mirror them to another location. What they needed in this situation was a proper Intrusion Detection System (IDS) that would have detected the unauthorized changes or additions to the payment processing system, and made the attack immediately apparent. It would seem that Network Solutions does not have a proper auditing and access control system, to prevent unauthorized access to such a sensitive machine. FreeBSD, the popular Unix/NOS, also offers another solution for secure systems such as this known as Secure Levels. In its more secure mode FreeBSD will prevent raw access to unmounted disks, kernel modules cannot be loaded, the clock cannot be changed by more than +/- 1 second, and the firewall rules cannot be tampered with. Secure Levels range from -1 to 3, and can only even be raised, never lowered, in order to lower the secure level, a reboot is required, which would be a very obvious sign of unauthorized access. Another feature of many IDS's and some backup systems is the ability to take hashes of important system files, and compare them on a regular basis, allowing any modification to a file to be detected on the next scan. Bacula in 'Verify' mode has this feature, and I've written about it before.

Via: Slashdot and Washington Post - Security Fix

blog comments powered by Disqus

Cuiusvis hominis est errare; nullius nisi insipientis in errore perseverare - Any man can make a mistake; only a fool keeps making the same one.

Digg Proof Hosting
The key to surviving Digg and Slashdot is Infrastructure. You can't get it from a regular web host, it requires experience. The High Load Hosting Experts at ScaleEngine can make your site thrive, and avoid having your site featured on AppFail.

Cyber Security Alerts

Page Generated in 934ms