1BO4r2U
1BO4r2U
1BO4r2U
Create successful ePaper yourself
Turn your PDF publications into a flip-book with our unique Google optimized e-Paper software.
171 172<br />
Web Application Penetration Testing<br />
Web Application Penetration Testing<br />
clients is that of SSL proxies such as stunnel available at which can<br />
be used to allow non-SSL enabled tools to talk to SSL services)<br />
• [37] [socat| http://www.dest-unreach.org/socat/]: Multipurpose<br />
relay<br />
• [38] [testssl.sh| https://testssl.sh/ ]<br />
References<br />
OWASP Resources<br />
• [5] [OWASP Testing Guide - Testing for cookie attributes (OTG-<br />
SESS-002)|https://www.owasp.org/index.php/Testing_for_cookies_attributes_(OTG-SESS-002)]<br />
• [4][OWASP Testing Guide - Test Network/Infrastructure Configuration<br />
(OTG-CONFIG-001)|https://www.owasp.org/index.php/<br />
Test_Network/Infrastructure_Configuration_(OTG-CONFIG-001)]<br />
• [6] [OWASP Testing Guide - Testing for HTTP_Strict_Transport_<br />
Security (OTG-CONFIG-007)|https://www.owasp.org/index.php/<br />
Test_HTTP_Strict_Transport_Security_(OTG-CONFIG-007)]<br />
• [2] [OWASP Testing Guide - Testing for Sensitive information sent<br />
via unencrypted channels (OTG-CRYPST-003)|https://www.owasp.<br />
org/index.php/Testing_for_Sensitive_information_sent_via_unencrypted_channels_(OTG-CRYPST-003)]<br />
• [3] [OWASP Testing Guide - Testing for Credentials Transported<br />
over an Encrypted Channel (OTG-AUTHN-001)|https://www.<br />
owasp.org/index.php/Testing_for_Credentials_Transported_over_<br />
an_Encrypted_Channel_(OTG-AUTHN-001)]<br />
• [22] [OWASP Cheat sheet - Transport Layer Protection|https://<br />
www.owasp.org/index.php/Transport_Layer_Protection_Cheat_<br />
Sheet]<br />
• [23] [OWASP TOP 10 2013 - A6 Sensitive Data Exposure|https://<br />
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.<br />
com/p/owasp-asvs/wiki/Verification_V10]<br />
• [26] [OWASP Application Security FAQ - Cryptography/<br />
SSL|https://www.owasp.org/index.php/OWASP_Application_Security_FAQ#Cryptography.2FSSL]<br />
Whitepapers<br />
• [1] [RFC5246 - The Transport Layer Security (TLS) Protocol Version<br />
1.2 (Updated by RFC 5746, RFC 5878, RFC 6176)|http://www.<br />
ietf.org/rfc/rfc5246.txt]<br />
• [36] [RFC2817 - Upgrading to TLS Within HTTP/1.1|]<br />
• [34] [RFC6066 - Transport Layer Security (TLS) Extensions: Extension<br />
Definitions|http://www.ietf.org/rfc/rfc6066.txt]<br />
• [11] [SSLv2 Protocol Multiple Weaknesses |http://osvdb.<br />
org/56387]<br />
• [12] [Mitre - TLS Renegotiation MiTM|http://cve.mitre.org/cgi-bin/<br />
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.<br />
ssllabs.com/projects/rating-guide/index.html]<br />
• [20] [Qualys SSL Labs - SSL Threat Model|https://www.ssllabs.<br />
com/projects/ssl-threat-model/index.html]<br />
• [18] [Qualys SSL Labs - Forward Secrecy|https://community.<br />
qualys.com/blogs/securitylabs/2013/06/25/ssl-labs-deploying-forward-secrecy]<br />
• [15] [Qualys SSL Labs - RC4 Usage|https://community.qualys.<br />
com/blogs/securitylabs/2013/03/19/rc4-in-tls-is-broken-nowwhat]<br />
• [16] [Qualys SSL Labs - BEAST|https://community.qualys.com/<br />
blogs/securitylabs/2011/10/17/mitigating-the-beast-attack-ontls]<br />
• [17] [Qualys SSL Labs - CRIME|https://community.qualys.com/<br />
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/<br />
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<br />
and Other Hash Functions| http://link.springer.com/chapter/10.1007/11426639_2]<br />
Testing for Padding Oracle (OTG-CRYPST-002)<br />
Summary<br />
A padding oracle is a function of an application which decrypts encrypted<br />
data provided by the client, e.g. internal session state stored<br />
on the client, and leaks the state of the validity of the padding after<br />
decryption. The existence of a padding oracle allows an attacker to<br />
decrypt encrypted data and encrypt arbitrary data without knowledge<br />
of the key used for these cryptographic operations. This can<br />
lead to leakage of sensible data or to privilege escalation vulnerabilities,<br />
if integrity of the encrypted data is assumed by the application.<br />
Block ciphers encrypt data only in blocks of certain sizes. Block sizes<br />
used by common ciphers are 8 and 16 bytes. Data where the size<br />
doesn’t match a multiple of the block size of the used cipher has to<br />
be padded in a specific manner so the decryptor is able to strip the<br />
padding. A commonly used padding scheme is PKCS#7. It fills the remaining<br />
bytes with the value of the padding length.<br />
Example:<br />
If the padding has the length of 5 bytes, the byte value 0x05 is repeated<br />
five times after the plain text.<br />
An error condition is present if the padding doesn’t match the syntax<br />
of the used padding scheme. A padding oracle is present if an application<br />
leaks this specific padding error condition for encrypted data<br />
provided by the client. This can happen by exposing exceptions (e.g.<br />
BadPaddingException in Java) directly, by subtle differences in the<br />
responses sent to the client or by another side-channel like timing<br />
behavior.<br />
Certain modes of operation of cryptography allow bit-flipping attacks,<br />
where flipping of a bit in the cipher text causes that the bit is<br />
also flipped in the plain text. Flipping a bit in the n-th block of CBC encrypted<br />
data causes that the same bit in the (n+1)-th block is flipped<br />
in the decrypted data. The n-th block of the decrypted cipher text is<br />
garbaged by this manipulation.<br />
The padding oracle attack enables an attacker to decrypt encrypted<br />
data without knowledge of the encryption key and used cipher by<br />
sending skillful manipulated cipher texts to the padding oracle and<br />
observing of the results returned by it. This causes loss of confidentiality<br />
of the encrypted data. E.g. in the case of session data stored<br />
on the client side the attacker can gain information about the internal<br />
state and structure of the application.<br />
A padding oracle attack also enables an attacker to encrypt arbitrary<br />
plain texts without knowledge of the used key and cipher. If<br />
the application assumes that integrity and authenticity of the decrypted<br />
data is given, an attacker could be able to manipulate internal<br />
session state and possibly gain higher privileges.<br />
How to Test<br />
Black Box Testing<br />
Testing for padding oracle vulnerabilities:<br />
First the possible input points for padding oracles must be identified.<br />
Generally the following conditions must be met:<br />
[1] The data is encrypted. Good candidates are values which appear<br />
to be random.<br />
[2] A block cipher is used. The length of the decoded (Base64 is used<br />
often) cipher text is a multiple of common cipher block sizes like 8 or<br />
16 bytes. Different cipher texts (e.g. gathered by different sessions or<br />
manipulation of session state) share a common divisor in the length.<br />
Example:<br />
Dg6W8OiWMIdVokIDH15T/A== results after Base64 decoding in<br />
0e 0e 96 f0 e8 96 30 87 55 a2 42 03 1f 5e 53 fc. This seems to be<br />
random and 16 byte long.<br />
If such an input value candidate is identified, the behavior of the<br />
application to bit-wise tampering of the encrypted value should be<br />
verified. Normally this Base64 encoded value will include the initialization<br />
vector (IV) prepended to the cipher text. Given a plaintext p<br />
and a cipher with a block size n, the number of blocks will be b = ceil(<br />
length(b) / n). The length of the encrypted string will be y=(b+1)*n<br />
due to the initialization vector. To verify the presence of the oracle,<br />
decode the string, flip the last bit of the second-to-last block b-1<br />
(the least significant bit of the byte at y-n-1), re-encode and send.<br />
Next, decode the original string, flip the last bit of the block b-2 (the<br />
least significant bit of the byte at y-2*n-1), re-encode and send.<br />
If it is known that the encrypted string is a single block (the IV is<br />
stored on the server or the application is using a bad practice hardcoded<br />
IV), several bit flips must be performed in turn. An alternative<br />
approach could be to prepend a random block, and flip bits in order<br />
to make the last byte of the added block take all possible values (0<br />
to 255).<br />
The tests and the base value should at least cause three different<br />
states while and after decryption:<br />
• Cipher text gets decrypted, resulting data is correct.<br />
• Cipher text gets decrypted, resulting data is garbled and causes<br />
some exception or error handling in the application logic.<br />
• Cipher text decryption fails due to padding errors.<br />
Compare the responses carefully. Search especially for exceptions<br />
and messages which state that something is wrong with the padding.<br />
If such messages appear, the application contains a padding<br />
oracle. If the three different states described above are observable<br />
implicitly (different error messages, timing side-channels), there is<br />
a high probability that there is a padding oracle present at this point.<br />
Try to perform the padding oracle attack to ensure this.<br />
Examples:<br />
• ASP.NET throws “System.Security.Cryptography.Cryptographic-<br />
Exception: Padding is invalid and cannot be removed.” if padding of a<br />
decrypted cipher text is broken.<br />
• In Java a javax.crypto.BadPaddingException is thrown in this case.<br />
• Decryption errors or similar can be possible padding oracles.<br />
Result Expected:<br />
A secure implementation will check for integrity and cause only two<br />
responses: ok and failed. There are no side channels which can be<br />
used to determine internal error states.<br />
Grey Box Testing<br />
Testing for padding oracle vulnerabilities:<br />
Verify that all places where encrypted data from the client, that<br />
should only be known by the server, is decrypted. The following conditions<br />
should be met by such code:<br />
[1] The integrity of the cipher text should be verified by a secure<br />
mechanism, like HMAC or authenticated cipher operation modes<br />
like GCM or CCM.<br />
[2] All error states while decryption and further processing are handled<br />
uniformly.<br />
Tools<br />
• PadBuster - https://github.com/GDSSecurity/PadBuster<br />
• python-paddingoracle - https://github.com/mwielgoszewski/python-paddingoracle<br />
• Poracle - https://github.com/iagox86/Poracle<br />
• Padding Oracle Exploitation Tool (POET) - http://netifera.com/research/<br />
Examples<br />
• Visualization of the decryption process - http://erlend.oftedal.no/<br />
blog/poet/<br />
References<br />
Whitepapers<br />
• Wikipedia - Padding oracle attack - http://en.wikipedia.org/wiki/<br />
Padding_oracle_attack<br />
• Juliano Rizzo, Thai Duong, “Practical Padding Oracle Attacks” -<br />
http://www.usenix.org/event/woot10/tech/full_papers/Rizzo.pdf<br />
Testing for Sensitive information sent via<br />
unencrypted channels (OTG-CRYPST-003)<br />
Summary<br />
Sensitive data must be protected when it is transmitted through<br />
the network. If data is transmitted over HTTPS or encrypted in another<br />
way the protection mechanism must not have limitations or<br />
vulnerabilities, as explained in the broader article Testing for Weak<br />
SSL/TLS Ciphers, Insufficient Transport Layer Protection (OTG-<br />
CRYPST-001) [1] and in other OWASP documentation [2], [3], [4], [5].<br />
As a rule of thumb if data must be protected when it is stored, this<br />
data must also be protected during transmission. Some examples<br />
for sensitive data are: