Professional Documents
Culture Documents
Pci Indicator Sample Report
Pci Indicator Sample Report
RONLAB
IP Address NetBIOS Name DNS Name MAC Address Score OS CPE Total
WORKGROUP\TARGET- cpe:/
192.168.1.11 win7-pc.lab 00:21:70:38:fb:9f 10 1
WIN7 o:microsoft:windows_7:::ultimate
Insecure Communications
Applications that fail to adequately encrypt network traffic using strong cryptography are at increased risk of being compromised and exposing cardholder data. If an
attacker is able to exploit weak cryptographic processes, he/she may be able to gain control of an application or even gain clear-text access to encrypted data.
IP Address NetBIOS Name DNS Name MAC Address Score OS CPE Total Info
WORKGROUP\ cpe:/
192.168.1.11 win7-pc.lab 00:21:70:38:fb:9f 0 1 1
TARGET-WIN7 o:microsoft:windows_7:::ultimate
Internet Reachable DB
The remote host is running a database server that is reachable from the Internet. This violates PCI DSS, section 1.3.7.
Web Vulnerabilities
Web Vulns
Web Server Plugins (Active & Passive) - Active plugins that check for vulnerabilities in web servers such as Apache HTTP Server, IBM Lotus Domino, Microsoft IIS,
and many more. Note: These checks only test the web server software, not the web applications hosted on the server. A set of plugins to passively detect traffic
and vulnerabilities in web servers.
CGI Abuses (Active & Passive) - Active plugin checks for web-based CGI programs with publicly documented vulnerabilities. These checks include SQL injection,
Local File Inclusion (LFI), Remote File Inclusion (RFI), Directory Traversal, and more. This family does not include checks for cross-site scripting. Active plugin checks
for web-based CGI programs with publicly documented cross-site scripting (XSS) vulnerabilities. A variety of passive plugins that check for the presence of CGI
programs, web applications, and vulnerabilities associated with them.
Web Vulnerabilities
Web Vulns
Web Vulnerabilities
Web Vulnerabilities
Web Vulnerabilities
Web Vulnerabilities
Web Vulnerabilities
CVSS >4
This section reports on any active or passive plugins within the Web Server or CGI Abuse families that have a CVSS score greater than 4.0 and less than 10.0.
Web Vulnerabilities
CVSS >4
Web Vulnerabilities
Web Vulnerabilities
Web Vulnerabilities
Web Vulnerabilities
Web Vulnerabilities
Exploitable
This section reports on any active or passive plugins within the Web Server or CGI Abuse families that have publicly available exploits.
Web Vulnerabilities
Exploitable
Web Vulnerabilities
Web Vulnerabilities
Web Vulnerabilities
Web Vulnerabilities
Web Vulnerabilities
Web Application
This section reports on any active or passive plugins that test for generic CGI vulnerabilities.
Web Application
Web Vulnerabilities
XSS
Checks for web-based CGI programs with publicly documented cross-site scripting (XSS) vulnerabilities.
XSS
Web Vulnerabilities
SQL Injection
Listed below is the IP summary of systems with SQL injection vulnerabilities.
Web Vulnerabilities
The fix for CVE-2012-1823 does not completely correct the CGI query
vulnerability. Disclosure of PHP source code and code execution via
query parameters are still possible.
10.224.32.190
10.127.106.141 - DNS : hosted-by.labtesting.int
10.61.237.32
10.126.152.2 - DNS : user.10.126.222.labtesting.int
Web Vulnerabilities
10.152.216.114 - DNS
: h10-10-216-114.host.labtesting.int
10.143.12.173 - DNS: hosted-by.labtesting.int
10.18.172.206
10.174.198.14
10.248.6.206 - DNS
Web Vulnerabilities
'readline_read_history'.
10.152.216.114 - DNS
Web Vulnerabilities
Note that Nessus did not actually test for the flaws but instead has
relied on the version in Tomcat's banner or error page.
Hosts in Repository 'RonLab Remote':
10.98.233.219
10.160.194.27
Web Vulnerabilities
multiple vulnerabilities :
Note that Nessus did not actually test for the flaws but instead has
relied on the version in Tomcat's banner or error page so this may
be a false positive.
Also note, in the case of 5.0.x versions, the issues have been fixed
by SVN revision number 588821.
Hosts in Repository 'RonLab Remote':
Web Vulnerabilities
Note that the remote web server may not actually be affected by these
vulnerabilities. Nessus did not try to determine whether the affected
modules are in use or to check for the issues themselves.
Hosts in Repository 'RonLab Remote':
Web Vulnerabilities
Web Vulnerabilities
Note that Nessus did not actually test for these flaws but instead has
relied on the version in Tomcat's banner or error page so this may
be a false positive.
Hosts in Repository 'RonLab Remote':
10.234.2.5
10.251.11.58 - DNS: abs-static-10.11.251.27.labtesting.int
10.18.172.206
10.162.110.11
10.90.230.187 - DNS
Web Vulnerabilities
10.61.218.58
10.126.152.2 - DNS : user.10.126.222.testinglab.int
Web Vulnerabilities
10.152.216.114 - DNS
: h10.10-216-114.host.testinglab.int
10.18.172.206
10.174.198.14
10.248.6.206 - DNS
Web Vulnerabilities
Weak Hash
Valid In Future
The SSL certificate for the remote SSL-enabled service is not yet valid.
Valid In Future
Expires Soon
The SSL certificate associated with the remote service will expire soon.
Expires Soon
Wrong Name
The commonName (CN) of the SSL certificate presented on this service is for a different machine.
Wrong Name
Blacklisted CERT
Blacklisted SSL Certificate - The remote service uses an SSL certificate that is either fraudulent or was issued from a certificate authority that is considered to be
untrustworthy.
SSL Certificate Signed with the Compromised Fortigate Key - The X.509 certificate of the remote host was signed by a certificate belonging to a Certificate Authority
(CA) found in Fortigate devices. The private key corresponding to the CA has been compromised, meaning that the remote host's X.509 certificate cannot be trusted.
Certificate chains descending from this CA could allow an attacker to perform man-in-the-middle attacks and decode traffic.
SSL Certificate Chain Contains Illegitimate TURKTRUST Intermediate CA - The X.509 certificate chain sent by the remote host either contains or is signed by an
intermediate Certificate Authority (CA) that was accidentally issued by TURKTRUST. Certificate chains descending from this intermediate CA could allow an attacker
to perform man-in-the-middle attacks and decode traffic.
APT1-Related SSL Certificate Detected - An SSL certificate associated with the group known as APT1 was detected on the remote host. APT1's command and
control infrastructure uses several self-signed certificates to encrypt communications in their command and control infrastructure. The remote host appears to be
using one of these certificates, which indicates it may have been compromised.
Blacklisted CERT
Known CERT
Well-known SSL Certificate Used in Remote Device - The X.509 certificate of the remote host is known to be shipping by default with the remote service / device.
The private key for this cert has been published, therefore the SSL communications done with the remote host can not be considered as being secret as anyone
with the ability to snoop the traffic between the remote host and the clients could decipher the traffic.
SSL Certificate Signed with the Publicly Known Cyberoam Key - The X.509 certificate of the remote host was signed by a certificate belonging to a Certificate
Authority (CA) found in Cyberoam devices. The private key corresponding to the CA was discovered and publicly disclosed, meaning that the remote host's X.509
certificate cannot be trusted.
Known CERT
No Trust
SSL Certificate Cannot Be Trusted - The server's X.509 certificate does not have a signature from a known public certificate authority. This situation can occur in
three different ways, each of which results in a break in the chain below which certificates cannot be trusted.
First, the top of the certificate chain sent by the server might not be descended from a known public certificate authority. This can occur either when the top of
the chain is an unrecognized, self-signed certificate, or when intermediate certificates are missing that would connect the top of the certificate chain to a known
public certificate authority.
Second, the certificate chain may contain a certificate that is not valid at the time of the scan. This can occur either when the scan occurs before one of the certificate's
'notBefore' dates, or after one of the certificate's 'notAfter' dates.
Third, the certificate chain may contain a signature that either didn't match the certificate's information, or could not be verified. Bad signatures can be fixed by getting
the certificate with the bad signature to be re-signed by its issuer. Signatures that could not be verified are the result of the certificate's issuer using a signing algorithm
that Nessus either does not support or does not recognize.
If the remote host is a public host in production, any break in the chain nullifies the use of SSL as anyone could establish a man-in-the-middle attack against the
remote host.
No Trust
Name Mismatch
SSL Certificate commonName Mismatch - This service presents an SSL certificate for which the 'commonName' (CN) does not match the host name on which
the service listens.
Name Mismatch
Revoked DigiNotar
SSL Certificate Signed with the Revoked DigiNotar Certificate Authority - The X.509 certificate of the remote host was signed by a certificate belonging to a Certificate
Authority (CA) called DigiNotar, which was revoked due to a known compromise. You should verify that the remote certificate indeed was obtained legally, and you
should get a new CA to sign it, as most web browsers are being updated to stop trusting this authority.
Revoked DigiNotar
CA Signing Issue
SSL Certificate Fails to Adhere to Basic Constraints / Key Usage Extensions - An X.509 certificate sent by the remote host contains one or more violations of the
restrictions imposed on it by RFC 5280. This means that either a root or intermediate Certificate Authority signed a certificate incorrectly. Certificates that fail to
adhere to the restrictions in their extensions may be rejected by certain software. The existence of such certificates indicates either an oversight in the signing
process, or malicious intent.
SSL Certificate Chain Not Sorted - At least one of the X.509 certificates sent by the remote host is not in order. Some certificate authorities publish certificate
bundles that are in descending instead of ascending order, which is incorrect according to RFC 4346, Section 7.4.2. Some SSL implementations, often those found
in embedded devices, cannot handle unordered certificate chains.
SSL Certificate Chain Contains Unnecessary Certificates - At least one of the X.509 certificates sent by the remote host is not required to form a path from the
server's own certificate to the CA. This may indicate that the certificate bundle installed with the server's certificate is for certificates lower in the certificate hierarchy.
Some SSL implementations, often those found in embedded devices, cannot handle certificate chains with unused certificates.
CA Signing Issue
SSL Vulns
Listed below are the Critical and High severity plugin's which are related to SSL vulnerabilities.
SSL Vulns
PCI 1.0
PCI 2.0
Requirement 2: Do not use vendor-supplied defaults for system passwords and other security parameters
Malicious individuals (external and internal to an entity) often use vendor default passwords and other vendor default settings to compromise systems. These
passwords and settings are well known by hacker communities and are easily determined via public information.
PCI 2.0
PCI 3.0
Requirement 3: Protect stored cardholder data
Protection methods such as encryption, truncation, masking, and hashing are critical components of cardholder data protection. If an intruder circumvents other
security controls and gains access to encrypted data, without the proper cryptographic keys, the data is unreadable and unusable to that person. Other effective
methods of protecting stored data should be considered as potential risk mitigation opportunities. For example, methods for minimizing risk include not storing
cardholder data unless absolutely necessary, truncating cardholder data if full PAN is not needed, and not sending unprotected PANs using end-user messaging
technologies, such as e-mail and instant messaging.
PCI 3.0
PCI 4.0
Requirement 4: Encrypt transmission of cardholder data across open, public networks
Sensitive information must be encrypted during transmission over networks that are easily accessed by malicious individuals. Misconfigured wireless networks and
vulnerabilities in legacy encryption and authentication protocols continue to be targets of malicious individuals who exploit these vulnerabilities to gain privileged
access to cardholder data environments.
PCI 4.0
PCI 5.0
Requirement 5: Use and regularly update anti-virus software or programs
Malicious software, commonly referred to as #malware#—including viruses, worms, and Trojans—enters the network during many business- approved activities
including employee e-mail and use of the Internet, mobile computers, and storage devices, resulting in the exploitation of system vulnerabilities. Anti-virus software
must be used on all systems commonly affected by malware to protect systems from current and evolving malicious software threats.
PCI 5.0
PCI 6.0
Requirement 6: Develop and maintain secure systems and applications
Unscrupulous individuals use security vulnerabilities to gain privileged access to systems. Many of these vulnerabilities are fixed by vendor- provided security patches,
which must be installed by the entities that manage the systems. All critical systems must have the most recently released, appropriate software patches to protect
against exploitation and compromise of cardholder data by malicious individuals and malicious software.
PCI 6.0
PCI 7.0
Requirement 7: Restrict access to cardholder data by business need to know
To ensure critical data can only be accessed by authorized personnel, systems and processes must be in place to limit access based on need to know and according
to job responsibilities. Need to know# is when access rights are granted to only the least amount of data and privileges needed to perform a job.
PCI 7.0
PCI 8.0
Requirement 8: Assign a unique ID to each person with computer access
Assigning a unique identification (ID) to each person with access ensures that each individual is uniquely accountable for his or her actions. When such accountability
is in place, actions taken on critical data and systems are performed by, and can be traced to, known and authorized users.
PCI 8.0
PCI 9.0
Requirement 9: Restrict physical access to cardholder data
Any physical access to data or systems that house cardholder data provides the opportunity for individuals to access devices or data and to remove systems or
hardcopies, and should be appropriately restricted.
PCI 9.0
PCI 10.0
Requirement 10: Track and monitor all access to network resources and cardholder data
Logging mechanisms and the ability to track user activities are critical in preventing, detecting, or minimizing the impact of a data compromise. The presence of
logs in all environments allows thorough tracking, alerting, and analysis when something does go wrong. Determining the cause of a compromise is very difficult,
if not impossible, without system activity logs.
PCI 10.0
PCI 11.0
Requirement 11: Regularly test security systems and processes.
Vulnerabilities are being discovered continually by malicious individuals and researchers, and being introduced by new software. System components, processes,
and custom software should be tested frequently to ensure security controls continue to reflect a changing environment.
PCI 11.0
PCI 12.0
Requirement 12: Maintain a policy that addresses information security for all personnel.
A strong security policy sets the security tone for the whole entity and informs personnel what is expected of them. All personnel should be aware of the sensitivity
of data and their responsibilities for protecting it.
PCI 12.0