The very fact this article came to be implies the answer – yes, they are. Readers who are interested in knowing the rationale behind this statement are encouraged to continue reading.
The main motivation behind writing this article was a padding oracle vulnerability (
) found on May 2016 in a popular OpenSSL cryptographic toolkit. Authors of this article decided that it is a great occasion to revisit this area and to refresh information about the padding oracles.
What is padding oracle? What can happen if someone finds this vulnerability in my application and will be able to exploit it? How can I test, identify and avoid this type of attack? Let’s address these and other questions in the following sections.
First things first. Let’s refresh on what the padding oracle attack is. The definition according to
“An attacker is able to efficiently decrypt data without knowing the decryption key if a target system leaks data on whether or not a padding error happened while decrypting the ciphertext.
In addition to performing decryption, an attacker is also able to produce valid ciphertexts
(i.e., perform encryption) by using the padding oracle, all without knowing the encryption key”.
For those of you paying attention to mailing lists early last night, you may have noticed a curious email come through, regarding a “Truly scary” SSL3.0 vulnerability about to drop – and drop it did today.
The vulnerability, known as
, allows attackers to partially decipher bits of plaintext, such as session cookies, in conjunction with a man-in-the-middle attack where an attacker can modify traffic. The really scary part (imo) is on Page 3 of the whitepaper:
The expected overall effort is 256 SSL 3.0 requests per byte.
This is amazingly low, meaning that depending on the circumstances of exploitation, your typical web app session cookie can be broken in minutes.
Recently, I presented a lightning talk at Ruxcon 2014, on a cross-site scripting issue we discovered on a client engagement, and two interesting ways in which we could bypass the WAF present (as well as Firefox’s cross-site scripting filter).
The cross-site scripting issue we found was fairly standard at first, with an initial URI like the following:
(A little bit of background on this post – one of my colleagues, Norman Yue, posted something about the Internet being on fire to LinkedIn yesterday, regarding the bash bug. This blog post tries to explain a bit more about why exactly this is such a big issue, and also provides a proof-of-concept exploitation).
Firstly, the vulnerability itself. The
actual vulnerability itself
is amusing and unique, but otherwise, isn’t the magical everything-is-owned vulnerability that everyone makes it out to be. To paraphrase, if you are able to set an environment variable through the Bash shell, you can execute commands.
The interesting part is that this vulnerability may have existed for more than 20 years, in an application which is part of pretty much every Unix system since a long time ago. The vulnerable versions start from cpe:/a:gnu:bash:1.14.0 to cpe:/a:gnu:bash:4.3, which covers pretty much every Unix-based operating system available today (and by extension, a tremendous chunk of the Internet).
One of the things I do, under the guise of OWASP Sydney Chapter Lead, is run a weekly workshop – every week, a small group of people get together to work on some security topics ranging from reverse engineering to web-based wargames, followed by security chit-chat over dinner.
Recently, at one of these get togethers, a (very smart)
pointed me to PHP’s lcg_value function.
First looked at by
in 2010, lcg_value is a PHP pseudo-random number generator, which generates a random 64-bit floating point. To cut a long story short, this function works as follows (variable names taken from samy’s lcg_state_forward.c):
We have been investigating RFID access control security and the models typically implemented by businesses in Australia. The iClass line of devices developed by HID are an interesting subject as they are commonly used throughout Australia (and globally) and have been proven to have security flaws. We conducted some research to see if we could create a covert cloning device for use in our engagements. Read on for more details of our successes!
A few weeks ago, we posted a security challenge in our “How I got root with Sudo”
on how to escalate privileges on real world examples of insecure
configurations. Now that everyone’s had the time to have a go, we are finally publishing the answers!
During security engagements, we regularly come across servers configured with the privilege management software Sudo. As with any software, the principle of least privilege must be closely followed, users must be granted the minimum possible privileges to perform necessary tasks or operations. Therefore to securely configure Sudo, user accounts must be restricted to a limited set of commands that they can legitimately execute with elevated privileges (usually those of the root account).
Out in the real world, we don’t often see Sudo configured according to the principle of least privilege. But when we do, we always uncover a mistake or two that allows us to escalate our privileges to root, at which point it’s game over. We win.
The purpose of this post is to present a series of examples of common mistakes and insecure configurations that we have seen and leveraged on production environments during security assessments and how you can make our team’s life that little bit harder.
During a recent penetration test against an ASP.NET web application, we gained a significant level of control over the server and leveraged our access to get a copy of the application’s database, where the user password hashes were stored.
This post provides details of how we recovered passwords from the hashes. Read on if you want to play along at home and crack them as we did!
With the rising popularity of iPhone and iPad devices, we are running into more and more applications which require a valid SSL certificate for all connections. In order to properly assess the security of these applications, we need to intercept the SSL connections they make. This post shows our technique for doing this.
Please note that this is not a vulnerability in iOS, and that everything is working as intended. This is the method we use for intercepting SSL connections made by iOS applications, and assumes you’re already able to forward such connections (using pf, iptables, or something similar) to your machine. This also assumes that you will be using burp suite proxy
Firstly, set up a working directory. This blog post assume you’re working with the following working directory structure:
echo 01 > serial
Then, copy your “openssl.cnf” file from somewhere in “/etc” into “conf/caconfig.cnf”
The location of your “openssl.cnf” file may vary “find /etc | grep openssl.cnf” may help.