PCI Compliance – Choose your ASV wisely

If you run a website that takes payments from customers then there is a good chance you have come across the term PCI Compliance – PCI being an abbreviation for the Payment Card Industry. I spend a considerable amount of time in my day job dealing with PCI ASVs (Approved Service Vendors) and the reports they produce on websites belonging to customers.

The PCI standards are a real money spinner, and compliance is often incorrectly seen by non security types as the pinnacle of the security mountain. Website owners often get the impression they can sit back let their website’s new found adamantine armour fend off the bad guys – and then later learn the hard way how foolish this attitude is – but I digress.

Inconsistency between PCI ASVs

One of the biggest problems I see in the industry is the level of inconsistency between different ASVs, and even between reports from the same ASV. I work regularly with Qualys, Security metrics, Trustwave, ControlScan and others, and whilst around 90% of their findings correlate with one another, there remains a great deal of wriggle room – and in some cases that wriggle room can mean the difference between passing and failing.

Most ASVs are quite reasonable and will work to iron out genuine false positives in a timely way, but Trustwave almost appear to completely ignore whitelist appeals, costing clients time and money. Don’t misunderstand what I’m saying – you should NEVER choose an ASV because they are more lax – but you do need your ASV to be responsive to your feedback.

Trustwave Global Security, a popular ASV that many people use – not through choice but because they are forced to by their payment gateway provider – display some bizarre reactions to secure services delivered via TLS on ports traditionally used with plain text authentication.

Googling around many people are under the impression that Trustwave will simply PCI fail any TLS based FTP, IMAP or POP3 service. This is not strictly true, nor should it be for PCI compliance, but Trustwave are very inconsistent in their approach.

For example, I recently dealt with several PCI failures on the same server. Here are the results from two clients both hosted on the same shared server.

Client 1

tcp/21 – The service running on this port appears to make use of a plaintext (unencrypted) communication channel etc…
Evidence: Details: Unencrypted authentication is allowed prior to TLS negotiation
AUTH TLS Supported: true
AUTH TLS Required: false <— Trustwave have no way to determine this accurately.
Command Sent: USER trustkeeper
Response Received: <— nothing!

tcp/143 – The service running on this port appears to make use of a plaintext (unencrypted) communication channel etc…
Evidence: Details: Authentication is allowed without an encrypted connection
Sent: A001 LOGIN N1pDPe97 tuX4wD3D
Received: A001 NO [PRIVACYREQUIRED] Plaintext authentication disallowed on non-secure (SSL/TLS) connections.

Client 2

tcp/143 – The service running on this port appears to make use of a plaintext (unencrypted) communication channel etc…
Evidence: Details: Authentication is allowed without an encrypted connection
Sent: A001 LOGIN N1pDPe97 tuX4wD3D
Received: A001 NO [PRIVACYREQUIRED] Plaintext authentication disallowed on non-secure (SSL/TLS) connections.

See the difference? After several attempts by Client 1, Trustwave have failed to whitelist the tcp/21 failure as a false positive, even though they did so for Client 2. Both clients have the same classification (remote payment processing) and are hosted on the same server.

Further, both Trustwave’s own analyses contradict themselves badly, and as I have spent so much time on this, I am documenting here so people looking for prospective PCI ASVs can see for themselves.

FTPS on TCP port 21

FTP with explicit TLS encryption requires that an initial TCP connection is opened to port 21 on the server. Once the TCP SYN, SYN ACK, ACK cycle is completed, the server sends the normal ftp server banner (redacted to remove version data) to the client. The client can then do one of two things… it can send AUTH TLS to request a secure session, or it can charge ahead and submit a USER command to initiate a plain text login. Trustwave do the latter to test if a plain text login is allowed.

At this stage in the TCP transaction, there is NO WAY for a server to stop a badly configured client from sending the USER command and a username. So for Client 1, above, we see Trustwave send USER trustkeeper  and in reply the server sends a TCP ACK – but that is all. No further response from the FTP server can be elicited.

So, provided the client has correctly configured his FTP client (as would have been attested in his SAQ – Self Assessment Questionnaire) it is IMPOSSIBLE for plain text authentication to occur. Trustwave should be able to understand this, and indeed someone there apparently did for Client 2 – but not for Client 1 – So, this is the first inconsistency from Trustwave.

IMAP on TCP port 143

Once again, IMAP with explicit TLS negotiation requires that an initial TCP connection (SYN, SYN ACK, ACK) is opened on port 143. The server then sends it’s capabilities to the client thus (I’ve removed irrelevant keys):

* OK [CAPABILITY blah blah STARTTLS LOGINDISABLED]

STARTTLS tells the client that TLS is supported and LOGINDISABLED tells the client that plain text authentication is NOT allowed. These IMAP capabilities are both covered in detail under [RFC2595] and [RFC3501]. Once again, at this stage in the TCP conversation there is NO WAY for a server to prevent a badly configured client from sending a plain text login request – this is exactly what Trustwave do – which is fine, they are testing to make sure plain text logins are not allowed. So, Trustwave send A001 LOGIN N1pDPe97 tuX4wD3D  to the server, and the server replies with:

This makes it abundantly clear that the server does not, in fact, authenticate plain text auth attempts. But hang on… lets look more closely at the evidence Trustwave cite for failing the IMAP service:

tcp/143 – The service running on this port appears to make use of a plaintext (unencrypted) communication channel etc…
Evidence: Details: Authentication is allowed without an encrypted connection
Sent: A001 LOGIN N1pDPe97 tuX4wD3D
Received: A001 NO [PRIVACYREQUIRED] Plaintext authentication disallowed on non-secure (SSL/TLS) connections.

So within the blink of an eye, they state Authentication is allowed without an encrypted connection (which we know to be wrong anyway), then then two lines later they repeat the server’s response, which is to REFUSE plaintext authentication. As I write this, the situation continues unabated with several customers now having to make the choice between trusting Trustwave, or their hosting provider. As most website owners are not technically monded to this level, they will inevitably follow Trustwave’s advice and possibly change hosts.

Conclusion

I only hope this article finds its way in front of other frustrated system admins or prospective PCI compliance customers and helps them apply further leverage to Trustwave to improve their performance. Based on my experience with this company, I would recommend any prospective company looking for an ASV to go for either Qualys or Security Metrics, both of whom have proven to be more responsive.

One Response to PCI Compliance – Choose your ASV wisely

  1. Peter Nelson January 29, 2015 at 12:40 #

    For FTP I agree, although FTPS with implicit TLS exists on port 990 which should get around it, but the IMAP issue is problematic precisely because you can’t prevent someone accidentally sending unencrypted login details. It would be better to use port 993 for implicit TLS, which is more likely to prevent accidental exposure.

    All ASVs should be open to resolving issues though, instead of treating security as a tick-box filling exercise.

Leave a Reply

Time limit is exhausted. Please reload CAPTCHA.