Vulnerability scans search your network and provide a logged summary of alerts you can review and act on. Here are the top 15 ASV scan vulnerabilities and how to fix them.
ASV stands for “Approved Scanning Vendor.” The Payment Card Industry Data Security Standard (PCI DSS) requirement 11.2.2 calls for regular vulnerability scanning from an ASV. These are vendors with scanning solutions that have been tested, approved, and added to a list of approved solutions that can help fulfill this PCI compliance requirement.
Learn about what qualities to look for in an ASV.
Vulnerability scanners are technically computer programs that search systems for weaknesses. Hackers can take advantage of these weaknesses to breach a network and steal data or install malware.
Vulnerability scans are automatic. They’re nonintrusive, similar to a security professional checking whether or not your front door is unlocked and letting you know if it is (while not entering your house). Vulnerability scans search your network and provide a logged summary of alerts you can review and act on.
If you are using SecurityMetrics’ ASV vulnerability scans and have an intrusion detection system or intrusion prevention system protecting your network, you may need to add our scanner's IP range to a whitelist or exclusion list for the scan to complete accurately.
Grouped together because they have a common solution. SSL, or “Secure Sockets Layer,” was an earlier protocol and precursor to TLS or “Transport Layer Security.” Both are designed for use in data transmission over the open public internet.
Resolution: According to the PCI DSS and security best practice, all versions of SSL (SSLv2 and SSLv3), as well as early versions of TLS (TLS 1.0), should be disabled from use on all open connections into the CDE.
This extensive list of cipher/algorithm vulnerabilities all come down to very similar fixes or resolutions.
Resolution: In each one of these vulnerabilities, the ciphers that cause these to flag have to be disabled. Those ciphers/algorithms are located in the “Data Received” section of the scan vulnerability details. Once disabled, rescans should clear these from flagging in the future.
These are all SSL Certificate related vulnerabilities. As the third most common vulnerability we see, most merchants will come across this at some point.
Resolution: The suggested resolutions are similar with slight variances, but they all boil down to one core concept: Open, Public ports that use encryption are required to have a Valid SSL Certificate signed by a Certificate Authority (CA). This means that the common name needs to match the target, the issuer needs to be a CA, and the certificate cannot be expired.
This vulnerability often appears on websites as well as simple login pages found on the network side. With clickjacking, a hacker or malicious individual loads a webpage or a button/link from a webpage into an I-Frame. A visitor may then unknowingly click on a malicious link and be sent to a completely different site–typically a duplicate page made to look like the valid webpage. I-Frames need to be restricted by implementing a security header.
Resolution: Regardless of where Clickjacking is vulnerable, the same fix applies. Pages that are vulnerable to Clickjacking are required to implement either X-Frame-Options or Content-Security-Policy security headers that prevent I-Frames from loading affected web pages.
POODLE only shows up when SSLv3 is enabled. The remote host is affected by a man-in-the-middle (MitM) information disclosure vulnerability. MitM attackers can decrypt a selected byte of a cipher text in as few as 256 tries if they are able to force a victim application to repeatedly send the same data over newly created SSL 3.0 connections.
Resolution: Once SSLv3 is disabled, this vulnerability will no longer show up.
This vulnerability has alerted 23,000 times in the last six months and is number six on the list. In this case, the remote host is running a Microsoft Windows operating system or Samba, a CIFS/SMB server for Unix.
It’s possible that by having this set up, someone could log into the system with the following account information:
Resolution: Often this vulnerability requires the scan customer to contact their Vendor or OEM for an applicable vendor supplied patch.
See also: Vulnerability Scanning 101
These three vulnerabilities are all very similar. But despite these similarities, there are some key differences. SMTP Service Cleartext Login Permitted is on a completely different protocol than the other two, which function over HTTP.
Resolution: The recommended fix for these vulnerabilities is to disable any insecure service that supports remote logins and migrate everything over to a secure version of that service. So, rather than having login pages over the HTTP protocol, you would move them to HTTPS. The same with SMTP to SMTPS.
Number eight on our list of top ASV scan vulnerabilities has to do with an IPsec VPN technology that functions over the IKE protocol on port 500.
Resolution: There are a few resolutions that can be applied by the scan customer to resolve this vulnerability.
If SMB servers are used, SMB Signing Not Required could appear as a valid vulnerability. The idea behind this vulnerability is that, if found, signing is not required on the remote SMB server. This means that an unauthenticated, remote attacker can exploit this to conduct MitM attacks against the SMB server.
Possible Resolutions:
This vulnerability only shows up due to the support of certain versions of OpenSSL.
Resolution: For all OpenSSL 0.9.8 SSL/TLS users, upgrade to 0.9.8za; for the OpenSSL 1.0.0 SSL/TLS users, upgrade to 1.0.0m; and for OpenSSL 1.0.1 SSL/TLS users, upgrade to 1.0.1h.
Although this vulnerability shows up frequently, it is often prone to False Positives which are often disputed by proving they are on newer versions of OpenSSL than those listed above as vulnerable.
This alert appears if an RDP or Remote Desktop Protocol service is enabled on the scan customer’s network. NLA uses strong server authentication which protects against MitM attacks during transmission. It also protects the remote computer from malicious users and software by completing user authentication before a full RDP connection is established.
Resolution: Enable Network Level Authentication (NLA) on the remote RDP server. This can be found on the ‘Remote’ tab of the ‘System’ settings on Windows.
Usually found on port 21 (but can be configured to be on other non-standard ports) the FTP Supports Cleartext Authentication vulnerability flags if the FTP service supports a login without a means to encrypt.
Resolution: Either switch to the FTPS protocol, which uses TLS/SSL to encrypt, or use the SFTP protocol handled over the SSH encryption suite.
This alert will show up on a scan customer’s results if they are supporting certain versions of RDP. In this case, the RDP client makes no effort to validate the identity of the server when setting up encryption. An attacker with the ability to intercept traffic from the RDP server can establish encryption with the client and server without being detected. A MiTM attack of this nature would allow the attacker to obtain any sensitive information transmitted, including authentication credentials. This flaw exists because the vulnerable version of this RDP server stores a hard-coded RSA private key in the mstlsapi.dll library. Any local user with access to this file (on any Windows system) can retrieve the key and use it for this attack.
Resolution: A scan customer should force the use of SSL/TLS as a transport layer for this service if supported, and/or select the 'Allow connections only from computers running Remote Desktop with Network Level Authentication' setting if it is available.
This vulnerability also has to do with the RDP service the scan customer is running. The idea here is that the remote Terminal Services service is not configured to use strong cryptography. If by using this service and having weak cryptography implemented may allow an attacker to eavesdrop on the communications more easily and obtain screenshots and/or keystrokes.
Resolution: The recommended fix for this vulnerability is to change the RDP encryption level to either option below:
This relatively new vulnerability has made it onto the top vulnerabilities that we flag for. In this situation, the remote host may be vulnerable to payment entry data exfiltration due to javascript included from potentially untrusted and unverified third parties’ script src.
Resolution: The recommended fix for this issue is to set script integrity checking on the target script or to remove target script.
Oftentimes, the scan customer can run their javascript link found in the data received through an SRI hash generator to get that hash and digest.
While these 15 vulnerabilities are the most frequently seen vulnerabilities right now, the list can change. Due to the nature of cybersecurity and the fact that new vulnerabilities arise all the time, we always recommend that in order to harden their systems customers should first determine if any open port or service can either be closed, filtered, or disabled to prevent access into the Cardholder Data Environment (CDE).
If CDE access can be restricted to only those who need access, these vulnerabilities should not alert on scan results for our scan customers. Second, customers should see if segmentation can be set up to segment insecure portions of the network away from secure portions of the network or the CDE. By ensuring segmentation through strong means, actual attack vectors and threats found in the vulnerability assessment scan could be considered outside of the scope of PCI Compliance.
If you have a question about your ASV scan or ASV scan results, please contact our support team.
.svg)
