1BO4r2U

Recommendations

Info

169 170 Web Application Penetration Testing Web Application Penetration Testing [*] Vulnerability Status: No ===================================== Checking localhost:443 for TLS Compression support against CRIME (CVE-2012-4929) & TIME attack ... [*] TLS Compression : DISABLED [*] Immune from CRIME & TIME attack mentioned in https:/ media.blackhat.com/eu-13/briefings/Beery/bh-eu-13-a-perfect-crime-beery-wp.pdf [*] Vulnerability Status: No ===================================== • Victim logs into the secure website at https://somesecuresite/. • The secure site issues a session cookie as the client logs in. • While logged in, the victim opens a new browser window and goes to http:// examplesite/ • An attacker sitting on the same network is able to see the clear text traffic to http://examplesite. • 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. • 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 • The attacker sees this traffic and logs the cookie for later use. To test if a website is vulnerable carry out the following tests: Configuration Review Testing for Weak SSL/TLS Cipher Suites 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. Example 9. Windows Server Check the configuration on a Microsoft Windows Server (2000, 2003 and 2008) using the registry key: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\ that has some sub-keys including Ciphers, Protocols and KeyExchangeAlgorithms. [+] Breacher finished scanning in 12 seconds. [+] Get your latest copy at http:/yehg.net/ Testing SSL certificate validity – client and server 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. 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. 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. Example 1. Testing for certificate validity (manually) 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. 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. Warning issued by Microsoft Internet Explorer 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. Warning issued by Mozilla Firefox Testing for other vulnerabilities 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. Surf Jacking 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. The following is a scenario of how the attack can take place: [1] Check if website supports both HTTP and HTTPS protocols [2] Check if cookies do not have the “Secure” flag SSL Strip 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. 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. Testing via HTTP proxy 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. Example 8. Testing via HTTP proxy To connect to destined.application.lan:443 via proxy 10.13.37.100:3128 run socat as follows: $ socat TCP-LISTEN:9999,reuseaddr,fork PROXY:10.13.37.100:destined.application.lan:443,proxyport=3128 Then the tester can target all other tools to localhost:9999: $ openssl s_client -connect localhost:9999 All connections to localhost:9999 will be effectively relayed by socat via proxy to destined.application.lan:443. Example 10: Apache 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. Testing SSL certificate validity – client and server 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. Tools • [21][Qualys SSL Labs - SSL Server Test | https://www.ssllabs.com/ ssltest/index.html]: internet facing scanner • [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. • [32] [TestSSLServer | http://www.bolet.org/TestSSLServer/]: a java scanner - and also windows executable - includes tests for cipher suites, CRIME and BEAST • [33] [sslyze | https://github.com/iSECPartners/sslyze]: is a python script to check vulnerabilities in SSL/TLS. • [28] [SSLAudit|https://code.google.com/p/sslaudit/]: a perl script/ windows executable scanner which follows Qualys SSL Labs Rating Guide. • [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. • [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. • [30] [curl|http://curl.haxx.se/] and [openssl|http://www.openssl. org/]: can be used to query manually SSL/TLS services • [9] [Stunnel|http://www.stunnel.org]: a noteworthy class of SSL
171 172 Web Application Penetration Testing Web Application Penetration Testing 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) • [37] [socat| http://www.dest-unreach.org/socat/]: Multipurpose relay • [38] [testssl.sh| https://testssl.sh/ ] References OWASP Resources • [5] [OWASP Testing Guide - Testing for cookie attributes (OTG- SESS-002)|https://www.owasp.org/index.php/Testing_for_cookies_attributes_(OTG-SESS-002)] • [4][OWASP Testing Guide - Test Network/Infrastructure Configuration (OTG-CONFIG-001)|https://www.owasp.org/index.php/ Test_Network/Infrastructure_Configuration_(OTG-CONFIG-001)] • [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)] • [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)] • [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)] • [22] [OWASP Cheat sheet - Transport Layer Protection|https:// www.owasp.org/index.php/Transport_Layer_Protection_Cheat_ Sheet] • [23] [OWASP TOP 10 2013 - A6 Sensitive Data Exposure|https:// www.owasp.org/index.php/Top_10_2013-A6-Sensitive_Data_Exposure] • [24] [OWASP TOP 10 2010 - A9 Insufficient Transport Layer Protection|https://www.owasp.org/index.php/Top_10_2010-A9-Insufficient_Transport_Layer_Protection] • [25] [OWASP ASVS 2009 - Verification 10|https://code.google. com/p/owasp-asvs/wiki/Verification_V10] • [26] [OWASP Application Security FAQ - Cryptography/ SSL|https://www.owasp.org/index.php/OWASP_Application_Security_FAQ#Cryptography.2FSSL] Whitepapers • [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] • [36] [RFC2817 - Upgrading to TLS Within HTTP/1.1|] • [34] [RFC6066 - Transport Layer Security (TLS) Extensions: Extension Definitions|http://www.ietf.org/rfc/rfc6066.txt] • [11] [SSLv2 Protocol Multiple Weaknesses |http://osvdb. org/56387] • [12] [Mitre - TLS Renegotiation MiTM|http://cve.mitre.org/cgi-bin/ cvename.cgi?name=CVE-2009-3555] • [13] [Qualys SSL Labs - TLS Renegotiation DoS|https://community.qualys.com/blogs/securitylabs/2011/10/31/tls-renegotiation-and-denial-of-service-attacks] • [10] [Qualys SSL Labs - SSL/TLS Deployment Best Practices|https://www.ssllabs.com/projects/best-practices/index.html] • [14] [Qualys SSL Labs - SSL Server Rating Guide|https://www. ssllabs.com/projects/rating-guide/index.html] • [20] [Qualys SSL Labs - SSL Threat Model|https://www.ssllabs. com/projects/ssl-threat-model/index.html] • [18] [Qualys SSL Labs - Forward Secrecy|https://community. qualys.com/blogs/securitylabs/2013/06/25/ssl-labs-deploying-forward-secrecy] • [15] [Qualys SSL Labs - RC4 Usage|https://community.qualys. com/blogs/securitylabs/2013/03/19/rc4-in-tls-is-broken-nowwhat] • [16] [Qualys SSL Labs - BEAST|https://community.qualys.com/ blogs/securitylabs/2011/10/17/mitigating-the-beast-attack-ontls] • [17] [Qualys SSL Labs - CRIME|https://community.qualys.com/ blogs/securitylabs/2012/09/14/crime-information-leakage-attack-against-ssltls] • [7] [SurfJacking attack|https://resources.enablesecurity.com/resources/Surf%20Jacking.pdf] • [8] [SSLStrip attack|http://www.thoughtcrime.org/software/ sslstrip/] • [19] [PCI-DSS v2.0|https://www.pcisecuritystandards.org/security_standards/documents.php] • [35] [Xiaoyun Wang, Hongbo Yu: How to Break MD5 and Other Hash Functions| http://link.springer.com/chapter/10.1007/11426639_2] Testing for Padding Oracle (OTG-CRYPST-002) Summary A padding oracle is a function of an application which decrypts encrypted data provided by the client, e.g. internal session state stored on the client, and leaks the state of the validity of the padding after decryption. The existence of a padding oracle allows an attacker to decrypt encrypted data and encrypt arbitrary data without knowledge of the key used for these cryptographic operations. This can lead to leakage of sensible data or to privilege escalation vulnerabilities, if integrity of the encrypted data is assumed by the application. Block ciphers encrypt data only in blocks of certain sizes. Block sizes used by common ciphers are 8 and 16 bytes. Data where the size doesn’t match a multiple of the block size of the used cipher has to be padded in a specific manner so the decryptor is able to strip the padding. A commonly used padding scheme is PKCS#7. It fills the remaining bytes with the value of the padding length. Example: If the padding has the length of 5 bytes, the byte value 0x05 is repeated five times after the plain text. An error condition is present if the padding doesn’t match the syntax of the used padding scheme. A padding oracle is present if an application leaks this specific padding error condition for encrypted data provided by the client. This can happen by exposing exceptions (e.g. BadPaddingException in Java) directly, by subtle differences in the responses sent to the client or by another side-channel like timing behavior. Certain modes of operation of cryptography allow bit-flipping attacks, where flipping of a bit in the cipher text causes that the bit is also flipped in the plain text. Flipping a bit in the n-th block of CBC encrypted data causes that the same bit in the (n+1)-th block is flipped in the decrypted data. The n-th block of the decrypted cipher text is garbaged by this manipulation. The padding oracle attack enables an attacker to decrypt encrypted data without knowledge of the encryption key and used cipher by sending skillful manipulated cipher texts to the padding oracle and observing of the results returned by it. This causes loss of confidentiality of the encrypted data. E.g. in the case of session data stored on the client side the attacker can gain information about the internal state and structure of the application. A padding oracle attack also enables an attacker to encrypt arbitrary plain texts without knowledge of the used key and cipher. If the application assumes that integrity and authenticity of the decrypted data is given, an attacker could be able to manipulate internal session state and possibly gain higher privileges. How to Test Black Box Testing Testing for padding oracle vulnerabilities: First the possible input points for padding oracles must be identified. Generally the following conditions must be met: [1] The data is encrypted. Good candidates are values which appear to be random. [2] A block cipher is used. The length of the decoded (Base64 is used often) cipher text is a multiple of common cipher block sizes like 8 or 16 bytes. Different cipher texts (e.g. gathered by different sessions or manipulation of session state) share a common divisor in the length. Example: Dg6W8OiWMIdVokIDH15T/A== results after Base64 decoding in 0e 0e 96 f0 e8 96 30 87 55 a2 42 03 1f 5e 53 fc. This seems to be random and 16 byte long. If such an input value candidate is identified, the behavior of the application to bit-wise tampering of the encrypted value should be verified. Normally this Base64 encoded value will include the initialization vector (IV) prepended to the cipher text. Given a plaintext p and a cipher with a block size n, the number of blocks will be b = ceil( length(b) / n). The length of the encrypted string will be y=(b+1)*n due to the initialization vector. To verify the presence of the oracle, decode the string, flip the last bit of the second-to-last block b-1 (the least significant bit of the byte at y-n-1), re-encode and send. Next, decode the original string, flip the last bit of the block b-2 (the least significant bit of the byte at y-2*n-1), re-encode and send. If it is known that the encrypted string is a single block (the IV is stored on the server or the application is using a bad practice hardcoded IV), several bit flips must be performed in turn. An alternative approach could be to prepend a random block, and flip bits in order to make the last byte of the added block take all possible values (0 to 255). The tests and the base value should at least cause three different states while and after decryption: • Cipher text gets decrypted, resulting data is correct. • Cipher text gets decrypted, resulting data is garbled and causes some exception or error handling in the application logic. • Cipher text decryption fails due to padding errors. Compare the responses carefully. Search especially for exceptions and messages which state that something is wrong with the padding. If such messages appear, the application contains a padding oracle. If the three different states described above are observable implicitly (different error messages, timing side-channels), there is a high probability that there is a padding oracle present at this point. Try to perform the padding oracle attack to ensure this. Examples: • ASP.NET throws “System.Security.Cryptography.Cryptographic- Exception: Padding is invalid and cannot be removed.” if padding of a decrypted cipher text is broken. • In Java a javax.crypto.BadPaddingException is thrown in this case. • Decryption errors or similar can be possible padding oracles. Result Expected: A secure implementation will check for integrity and cause only two responses: ok and failed. There are no side channels which can be used to determine internal error states. Grey Box Testing Testing for padding oracle vulnerabilities: Verify that all places where encrypted data from the client, that should only be known by the server, is decrypted. The following conditions should be met by such code: [1] The integrity of the cipher text should be verified by a secure mechanism, like HMAC or authenticated cipher operation modes like GCM or CCM. [2] All error states while decryption and further processing are handled uniformly. Tools • PadBuster - https://github.com/GDSSecurity/PadBuster • python-paddingoracle - https://github.com/mwielgoszewski/python-paddingoracle • Poracle - https://github.com/iagox86/Poracle • Padding Oracle Exploitation Tool (POET) - http://netifera.com/research/ Examples • Visualization of the decryption process - http://erlend.oftedal.no/ blog/poet/ References Whitepapers • Wikipedia - Padding oracle attack - http://en.wikipedia.org/wiki/ Padding_oracle_attack • Juliano Rizzo, Thai Duong, “Practical Padding Oracle Attacks” - http://www.usenix.org/event/woot10/tech/full_papers/Rizzo.pdf Testing for Sensitive information sent via unencrypted channels (OTG-CRYPST-003) Summary Sensitive data must be protected when it is transmitted through the network. If data is transmitted over HTTPS or encrypted in another way the protection mechanism must not have limitations or vulnerabilities, as explained in the broader article Testing for Weak SSL/TLS Ciphers, Insufficient Transport Layer Protection (OTG- CRYPST-001) [1] and in other OWASP documentation [2], [3], [4], [5]. As a rule of thumb if data must be protected when it is stored, this data must also be protected during transmission. Some examples for sensitive data are:
Page 1 and 2:
1 2 THE ICONS BELOW REPRESENT WHAT
Page 3 and 4:
3 4 Testing Guide Frontispiece Test
Page 5 and 6:
7 8 Testing Guide Introduction Test
Page 7 and 8:
11 12 Testing Guide Introduction Te
Page 9 and 10:
15 16 Testing Guide Introduction Te
Page 11 and 12:
19 20 Testing Guide Introduction of
Page 13 and 14:
23 24 Web Application Penetration T
Page 15 and 16:
Page 17 and 18:
Page 19 and 20:
Page 21 and 22:
Page 23 and 24:
Page 25 and 26:
Page 27 and 28:
Page 29 and 30:
Page 31 and 32:
Page 33 and 34:
Page 35 and 36: 67 68 Web Application Penetration T
Page 51 and 52: 99 100 Web Application Penetration
Page 85: 167 168 Web Application Penetration
Page 107 and 108: 211 212 Reporting Appendix Test ID
Page 109 and 110: 215 216 Appendix Appendix Testing -
Page 111: 219 220 LDAP Injection For details
show all

1BO4r2U

You also want an ePaper? Increase the reach of your titles

Delete template?

Save as template?