Earlier this morning a friend sent me a link he found on Reddit that pointed to a very large security hole on the Adobe.com website. It has since been patched but I thought I would take some time to explain a little bit about how it worked and how it could have been exploited further. The problem was due to a lack of sanitizing a URL path passed as a query string from the Shockwave download page to a Perl script for back end processing.

A hacker could use this flaw to enter a local server path in the query string and get the server to spit back information about itself like file directories, usernames and passwords, and even important encryption keys. The following URL used to return a long string of what appears to be garbled text.

http://www.adobe.com/shockwave/download/download.cgi?P1_Prod_Version=
../../../../../../../../../usr/local/apache/conf/ssl.key/www.adobe.com.key%00

What was happening was the path goes up to the root level of the server (the series of ../’s) and then into the local apache configuration files. Here the private encryption key used to encrypt SSL traffic would be exposed.

Whenever you conduct a secure transaction over the web, like giving a website your credit card information for a purchase, the traffic gets encrypted so it cannot be intercepted between the server and your computer. This keeps your confidential information safe and prevents a third party from sniffing your traffic to see what you are sending or receiving. You can tell you are using a secure connection by the yellow lock icon used in most browsers and the https:// instead of http:// in your address bar.

For this connection to work the server needs to have two keys; a public key and a private key. The public key is sent to your computer which it uses to encrypt a random number to send back to the server. A private key is kept on the server which is the only key that can decrypt the random numbers sent from your computer. From this transaction, both parties can generate key material used in encrypting and decrypting data. When an attacker looks at traffic over an SSL connection it looks like completely random and garbled text with no discernable pattern to it. The server and client can easily decrypt the garbled text putting it back to the original plain text.

Releasing the private encryption key of a web server into the wild compromises security allowing a 3rd party to easily decrypt SSL traffic or impersonate the server to perform a phishing attack. Adobe’s security hole wouldn’t directly break anything right away but a malicious user could use the flaw to probe for other weak spots and conduct an attack on those. Such attacks could expose personal data or intercepting sensitive traffic.

When coding a web application it is a good idea to build in a sanitize function that will strip out any non-alphanumeric characters like backslashes and periods. This can be done easily with a regular expression like replace(/\W/ig,””) that is common to most any programming language. This regular expression would change this ../../../../../../../../../usr/local/apache/conf/ssl.key/www.adobe.com.key%00 to this usrlocalapacheconfsslkeywwwadobecomkey00 . For more help with regular expressions check out this great tool I found.

For more information about SSL and Public Key Cryptogaphy check out Security Now Episode #34 Public Key Cryptography and Episode #85 Intro to Web Code Injection.

UPDATE: The Register has a complete write up about the security leak.