When getting PCI compliant, organisations are required to have a penetration test performed annually or after any significant changes to systems. Having extensive experience in performing these tests Samurai has, over the years, seen many reasons why organisations fail which has led us to create this blog post. We hope that by reading this, common reasons for failure can be avoided before your next test.
Telnet and Other Legacy Services
We all know Telnet to be a hideously outdated protocol at this point, however, even despite its reputation Samurai still catch it out in the wild. Telnet, officially defined in 1973, doesn’t use any form of encryption to communicate, sending all data in plain text. This is obviously an issue and yet some modern devices still have it running by default.
Checking for out of date services can be difficult, especially across a large corporate estate or if the person checking isn’t aware which services are insecure. As a note, some other insecure legacy services off the top of my head are; rservices, HTTP and SSL, however, this is far from an exhaustive list.
A simple method to check for these legacy services is to try and connect to them on the machine. For Telnet, as an example, you could try and establish a Telnet session to that machine or piece of networking equipment. Unfortunately, this method does not scale well beyond just a handful of machines, and therefore it is recommended that a tool is used.
NMAP is a network scanning tool which we highly recommend, and it is used by IT staff and hackers alike. Using NMAP, it is possible to scan every system on the network, checking for open ports that correspond to outdated services, like Telnet. Once NMAP has scanned the network it will generate a list of open ports for each machine, from this you can decide which services are insecure and should be removed.
TLSv1 or Worse… NO TLS!
On the 30th of June 2018, an update to the PCI standard was made, which, stated that communications on a network should be secured using TLSv1.1, 1.2 or 1.3. Despite the change receiving plenty of media attention, Samurai still come across organisations which failed to comply with the updated standard.
While encryption standards are always being updated, it is recommended that they are kept on top of and that systems utilise the most up to date version supported. Without TLS attackers are free to sniff traffic on the network and see sensitive information. For example, if a web server has no TLS implemented an attacker could watch the network communication, wait for a victim to login and then see those credentials in cleartext.
There is no easy way to check all supported versions of TLS as most common browsers will use the most secure version by default. One method it can be done though is with, the previously mentioned tool, Nmap. While Nmap is a port scanner first, it also contains many scripts which perform a range of operations. The one to check supported SSL/TLS versions is called ssl-enum-ciphers, which, when run, will output a list of all of the SSL ciphers it was able to connect to a system using.
Example of command to use: Nmap -sV –script ssl-enum-ciphers -p 443 <host>
Luckily for those readers that may not want to fire up a terminal and use Nmap, Qualys has a program which can check the security of your website, in which the version of TLS is checked.
Out of Date/Unpatched Operating Systems
Still running Windows 2003? Or just haven’t ensured the latest security patches are applied? Either of these things can cause serious issues on your network and can lead to failing PCI. In most companies, business-critical systems are approached with an “If it ain’t broken don’t fix it” attitude, as, understandably, any downtime can cause serious issues. Handling end of life software correctly is another stumbling block for many organisations as they fail to protect systems which are still critical but cannot be updated.
Patch management is another key issue. Most security patches require the system to restart, making it difficult to apply them as no sysadmin wants downtime or headaches to arise if the patch breaks the system. Due to this, patches end up being delayed or worse forgotten about.
Checking for outdated systems is sometimes as simple as connecting to them and checking the version number against the online documentation. For patch levels on systems such as Microsoft Windows, there are multiple tools, such as Microsoft own Microsoft Baseline Security which can scan your systems and recommend missing patches.
Weak or Default Passwords
In any company network, there will be many systems which require authorisation (hopefully). Switches, Routers, UPS systems, Windows endpoints and many more. When setting up these systems, not all require administrators to change the default password or, if they are changed, do not have strong enough password complexity requirements. It is a common issue that systems are set up with poor passwords which then get forgotten about, or, become entrenched in the organisation as the credentials get passed around to too many people for them to be easily changed.
Unless the storage of passwords is actively managed, there is a high chance this will undermine all other security implemented in the network, as it gives attackers easy paths into the network. There numerous news stories about “hackers getting into company’s” or “new virus effects this technology” which when it comes down to it is just that a password was guessed. Equifax anyone?
Checking for default passwords can be as easy as finding the user manual for the device, looking up the default password and attempting to log in using that. If you don’t have the user manual a quick google for the device’s default credentials is more than enough. Be aware though, if you get too trigger-happy entering passwords it could lead to accounts being locked out, so be prepared for this.
If you do try this and find that it has been changed try some easily guessable passwords such as password1, CompanyName, or even one from the top 5 passwords of 2019:
- 123456
- 123456789
- qwerty
- 12345678
- 111111
VLAN Segmentation
Modern corporate networks there are often very diverse, supporting a wide range of systems. Servers, employee endpoints, networking devices and guest devices all have different requirements and should be treated as such. Having every device able to communicate to every other device on the network may sound like the simplest setup but doing this not recommended to ensure security. This design could allow guest devices or any employee’s device to attack key infrastructure, whether intentional or not. A famous example of where a flat network design led to serious issues for organisations is the malware WannaCry. On poorly segmented networks it could thrive, infecting all vulnerable machines and leaving a wake of destruction behind it.
Robust network segmentation can be achieved using VLANs, with each area of the network corresponding to a VLAN. Checking your network for segmentation can be done by trying to connect to various devices from different points of the network if the access changes then it is likely some segmentation is implemented. For example, an employee who works in sales should be able to connect to the payroll server. Check this by attempting a connection from a sales machine with the standard process your systems use.
These were the most commonly seen PCI compliance fails by Samurai staff. While all organisations are different in both the skills of their staff and the types of systems they use, the same issues occur again and again. It may seem like basic knowledge for some companies, a good baseline of network security is required for PCI compliance. Samurai are happy to help with any issues or answer any questions you may have after reading this blog.