Foregenix Forensic Update
Small Merchant Cardholder Data Compromises - Notes from PFI Lite Investigations
One of the very common security faux pas that we are still encountering seems to be the result of a misunderstanding by hosting providers, web developers and general IT staff about how to restrict access to remote administration services.
In cases where firewall controls have been implemented on the eCommerce systems we've investigated, they have typically been used with good intentions to only allow access to the web service ports (obviously necessary) and the remote administration services such as the File Transfer Protocol (FTP) service and interactive login services for administration, e.g. Telnet or Secure Shell (SSH) on Linux servers, and Terminal Services / Remote Desktop on Microsoft Windows servers, among others. A primary mistake that is often made is in terms of how the restrictions are applied, or more specifically: who is permitted access vs who is not permitted access. In most of our investigations, we've round that the firewall rules were applied using a blanket approach, i.e. the all or nothing approach: if the web developers need remote login capabilities, the firewall rules permit all Internet sources to connect to the remote login service port(s) and reliance is placed on the protection provided by authentication controls - user IDs and passwords. It would be a far better security practice to disallow access from all the Internet and then only implement specific rules granting access to administrators from specifically authorised, static source IP addresses. Better yet, would be to manage those permissions with formal change control procedures that ensure you only permit that kind of administrative access when it is needed, and block all access again after the changes have been signed off. Taking the defence-in-depth principle a step further, it is recommended to implement a second factor for the authentication controls, such as using digital certificates or tokens.
Implementation of the firewall rules is vital - in almost every website investigation we have conducted, we have found that the remotely accessible administration services were subjected to regular and extensive brute force attacks. By not managing who is prevented from attempting to see the login prompts, the system becomes an easy target for attackers to focus their automated user ID and password guessing tools on. The source locations from which these types of attacks have been originating are widely varied, from the usual suspects of Russia, China and America, to just about any country you could randomly select. In addition to the extra load put onto the web server by such activities, the problem is often compounded by lazy developers who take the easy route when it comes to selecting their passwords. And easily guessable passwords amount to easy pickings for the attackers.
So while it is important to be aware of the constant stream of new and technically complicated vulnerabilities that are being identified and used to exploit systems, it is just as important as it ever has been, to ensure that the basics in terms of security controls are taken care of.
A few of the important security controls that the above discussions lead onto, are:
Keep your software versions patched and up-to-date. Preferably ensure you implement a regime of evaluating and implementing software updates on a weekly, or at least monthly, basis.
Always ensure your systems have antivirus software updated and actively monitoring and scanning your system(s). And remember that this is equally important on Linux and other operating systems, as it is on servers running Microsoft Windows.
Don't just put in some firewall rules and expect that to be the end of it – be sure to confirm that they are going to provide the right kind of protection that is suitable for your environment.
Simple passwords are an absolute no-no for any environment, as they have always been! Never permit remote users to login directly using the system's superuser account – always ensure that some level of accountability for actions is maintained by forcing users to login with an account that is uniquely attributable to them, before they gain any enhanced privileges that might be needed to complete the administrative tasks that they need to get done. And ensure that logs are kept of all their actions.
Always ensure that sensitive data such, especially user credentials, are never transmitted in clear-text. We strongly suggest disabling the use of any clear-text service over which sensitive information is transmitted, such as standard FTP, in favour of using the versions that implement encryption, such as Secure FTP (SFTP or FTPS) or secure copy (SCP) for example.
Enhance your security by implementing two (or more!) factor access controls. One of the simplest recommendations we can make for smaller organisations that don't have the budget or inclination to implement tokens, is to enforce the use of digital certificates.
Logging. The PCI DSS stipulates that a business should have at least 3 month's worth of logs available online, and at least 12 months available in archives (offline). This applies to ALL logs – firewalls, routers, web server operating system, web application, database, et al. Without them, you not only hamper your own ability to troubleshoot problems, but you greatly reduce the ability to swiftly and effectively investigate incidents.
And one more thing to add: don't forget to ensure your system's time is synchronised with a suitable time source – logs that aren't time-synchronised can be just as difficult to work with as when there are no logs at all.
We will be discussing logging in more detail in upcoming articles. If you have any questions about any of the information in this article, please get in touch.
Foregenix Forensic Update
Small Merchant Cardholder Data Compromises
Over the past year many smaller account data compromises, mostly involving eCommerce merchants, have been investigated by Foregenix’ PCI Forensic Investigative team. The trend has remained consistent over the past few years with the move from Card Present to Card Not Present compromises largely due to the successful rollout of Chip and PIN in protecting face-to-face cardholder data but also we’ve seen increased levels of investigations in smaller merchants as part of a VISA Europe initiative to help smaller merchants deal with their security incidents quickly and cost effectively.
One of the more interesting aspects of these investigations is an apparent resurgence of maliciously uploaded remote access 'web shells'. When they first became prevalent during 2005/2006, large numbers of hosts were compromised and had the tools installed, providing attackers almost complete remote control of the system through their web browser. Sightings of the tools (such as C99shell or r57shell) wained and were seldom seen after 2008/2009; however, now they seem to be on the increase again. We’ve seen some recent articles reporting a resurgence in Blackhat SEO* , which invariably includes a remote access webshell, which in turn implies that a greater amount of poisoned links are being presented to users but we’re still working to find a link between this and the fact that a greater number of compromises appear to be utilising web shells. Any comments and/or ideas from you, our readers, would be welcomed!
Users can go a long way to protect themselves by simply checking their web sites for new or changed files on a regular basis (these unexpectedly changed files would be identified through the implementation of PCI DSS controls, specifically Requirement 11.5 – File Integrity Monitoring). This small step would identify the introduction of web shells as well as a myriad of other threats, including alterations to their checkout procedure.
While Foregenix would strongly recommend processing eCommerce transactions through a PCI DSS certified payment processor, rather than the merchant accepting, processing and often storing the transaction details themselves, it is clear that many companies still wish to handle the transaction on their own systems. In such systems, we regularly investigate compromises where intruders have altered the checkout procedure code and while the merchant receives the payment details as normal the attacker also receives a copy or at least access to a copy. We’re also finding instances of anti-forensics techniques where the hackers attempt to hide their stolen cardholder data and this can take various forms, but favourites include concatenating the payment details, (cardholder name, address, card number, expiry and security code for example) onto the end of an image file and FTP’ing or emailing the details to an anonymous email address. In the case of the image file, if the image (icon or picture) file were viewed it would seem to be a normal image, but if the file were scanned using a cardholder data discovery solution like FScout, it would show the file holding all the details mentioned. We’ll be talking about this further in the next edition.
Simple reviews of the web site on a regular basis, noting the file names and sizes can go a long way to identifying these exposures while efforts are made to improve the security posture of the web site. However, it has to be said that this is simply addressing the symptoms rather than the cause. A more secure strategy would be to move to a secure environment and having the payment details handled by a PCI DSS Compliant payment service provider, thereby providing a considerably lower risk solution for the merchant.
However, let’s not forget that even in the redirect model described above, there are still significant security aspects to be considered on the merchants e-commerce website. Believing that the redirect model solves all the security issues for the merchant is done at their peril and we’ve seen cases where this has been exploited. Thus, even those websites redirecting the payment elsewhere must still be monitored and protected!
If you have a security issue, or requirement, please get in touch with us for assistance on:
+44 (0) 845 3096232 or firstname.lastname@example.org.