Tag Archives: PCI

Strong ciphers on Foundry ServerIron

Posted on by | Leave a reply

When setting up SSL offloading on a Foundry ServerIron 4G-SSL the default installation allows weak (eg. DES, 56bit) ciphers and SSLv2. This is not a recommended setup, especially if you have to comply to certain security certifications, like PCI. The Foundry documentation does not give a lot of information on the ciphers that are supported. Below the commands to disable SSLv2 and allow only strong ciphers on an ssl accelerated host.

To change the ssl profile of a virtual server, always follow the following steps:

  1. Remove the ssl profile from the virtual server
  2. Change the ssl profile settings
  3. Enable the ssl profile on the virtual server


server virtual vservername
no port ssl ssl-terminate sslprofilename

exit

ssl profile sslprofilename
disable-ssl-v2
no cipher-suite all-cipher-suites
cipher-suite rsa-with-3des-ede-cbc-sha
cipher-suite rsa-with-aes-128-sha
cipher-suite rsa-with-aes-256-sha
cipher-suite rsa-with-rc4-128-md5
cipher-suite rsa-with-rc4-128-sha

exit

server virtual vservername
port ssl ssl-terminate sslprofilename

Ten-thousands credit cards blocked

Posted on by | Leave a reply

Ten-thousands Belgian credit cards were blocked because hackers copied cardnumbers. This was published by Febelfin (the Federation of the Belgian finance sector) on tuesday October 20th 2009. It was stated that the criminals copied the numbers after they gained access to computer files. The hackers did not succeed in retrieving the pincodes.

I find it very strange that hackers were able to retrieve creditcard numbers from computer files. Specifically since PCI puts great restrictions on storing this stuff:

  1. PCI 3.1 – Keep cardholder data storage to a minimum
  2. PCI 3.2 – Do not store sensitive authentication data after authorization
  3. PCI 3.4 – Render PAN (PAN == cc-number), at minimum unreadable anywhere it is stored by using one of the following: one-way hash, truncation, strong cryptography with associated key-management processes and procedures
  4. PCI 3.4.1 – If dis encryption is used rather then file or database encryption, logical access must be managed independently of native OS access control

There are other requirements but the above give a good idea of the caution you must take when deciding to store this data. The full list of requirements can be downloaded from https://www.pcisecuritystandards.org/security_standards/pci_dss_download.html

Personally, I think these news items should contain more information, or should be evaluated somewhere so people can learn from the mistakes made by others. By being open on the causes of these problems people can easily prevent the holes that others left open. I know, this will probably not happen any time soon… 🙂

Link to original story: http://www.elsevier.nl/web/Nieuws/Internet-Gadgets/248802/Duizenden-creditcards-geblokkeerd-na-aanval-hackers.htm#

Creditcard data stolen at Network Solutions

Posted on by | Leave a reply

Yesterday I read an article in the Washington Post about a big security breach at Network Solutions where >500.000 credit and debit cards are stolen. Network Solutions acknowledge this security incident on their site. They claim the cause of this incident was malicious code that was uploaded to a platform supporting their merchants sites. How this was possible and how this could lead to the possible theft of half a million credit card numbers is unclear.

I’ve been involved in several PCI projects to help our customers become PCI compliant as required by the credit card issuing companies. While the need for most of the procedures and measures required by PCI is clear, some seem useless, costly and/or superfluous to implement. But after incidents like these, it is a lot easier to explain customers the point of the measures PCI requires of companies handling credit card data. Basically everything is aimed at protecting the creditcard data, and making sure in case of a security incident all needed audit trails are available to investigate the cause and source of the attack. At least that is how I look at it.

For instance, PCI requires you to audit the integrity of the files present on the system. This should not only include OS files, but also the (web) application code. It is premature to speculate if this ‘malicious code’ could have been detected by running a properly configured host-based IDS on the platform, such as Tripwire or Samhain.

Secondly, PCI requires you to establish roles that have access to a production platform to upload code. Staff members should be part of a role that authorizes them for the access they need to do their job. Access should be restricted to allow only this traffic. Not only should access be locked, but audit trails of all activity should be available upon request. These audit trails not only include who logged in to the systems, but should also include network IDS logs (eg. SNORT), commands that are executed (eg. sudo), output of these commands (eg. rootsh) and the reports of host-based IDS’s. Together these tools should give an auditor a good insight in the activity on a (compromised) server. Also SElinux could be a big help in restricting access. Strangely PCI does not require or advise the use of SElinux, while it does require the use of application level firewalls (eg. mod_security in Apache). But this is a different discussion 🙂

To secure the creditcard data itself, PCI requires that all creditcards should be stored in encrypted from. Manual access to keys to decrypt this data should not be possible. Based on this you can infer that the creditcard data is compromised by some sort of ‘man-in-the-middle’ attack. The malicious code could have intercepted the data after it was decrypted in the webserver, leaving the SSL tunnel, and before it was encrypted and stored in the database. But this is just speculating of course…

I’m looking forward to more details on this incident. I hope this is made publicly available so we can learn from the mistakes that were made.