Recently I've been writing a talk called "Authentication Bypass Zoo: Pwnage and Poetry 2" which will attempt to discuss various reasons that applications may be subject to authentication bypasses to provide a deeper understanding about what kind of mistakes can lead to authorization bypass. It will also include limericks written about the subject matter, as a sort of sequel to the original "Windows File Pseudonyms: Pwnage and Poetry."
I realize this makes me a bit of an infosec nerd, but I get excited about interesting vulnerabilities and I thought I would recount some of the interesting authorization bypass vulnerabilities of the past and explain how they work.
Windows is silly sometimes
Windows does some strange things with file paths which aren't terribly well documented, which was the discussion of my first Pwnage and Poetry presentation. A related vulnerability is CVE-2010-2263 which points out that adding an Alternate Data Steam (ADS) marker pointing to $DATA to the end of a URI requested from old versions of nginx on Windows will throw off nginx's file extension handling and cause the source of applications to be disclosed.
Why? nginx uses regexes to determine how files should be handled, based on their extension. If a file is named "config.php" it is likely to be set up to be processed by PHP since the file ends with ".php". If it is called as "config.php::$DATA", which simply specifies in ADS notation that the data in the file is to be returned, the path does not end in ".php" and thus is served raw.
Many Web servers have struggled with such path canonicalization issues. For instance, on systems with case insensitive filesystems (Windows, Mac OS X by default), changing the case of file extensions will cause many old versions of Web servers (and likely some current versions of Web servers) to serve the file raw.
To tie this back into the topic, authentication may be required for certain directories or files, which is not the case if you can break the comparison using this trick or some other.
Old froot, new froot, red froot, blue froot
In 1994 there was a vulnerability in several distributions of UNIX out at the time, including AIX and IRIX. The vulnerability was one of shell command injection. When using rlogin to connect remotely to a host, you could specify the -f switch as part of your username, which resulted in the username being interpreted as a command line switch and value. Essentially, it meant that when rlogind called login to perform authentication, it was given a "-f" switch, which instructs it to skip authentication and log in the user specified.
As such, one could gain remote root with rlogin -l "-froot" <system>!
These days, the -f command specifically does NOT work for the root user, but when the same vulnerability appeared in Solaris' telnetd 13 years later, one could still login as any user besides root. If a name could be guessed or enumerated, one could then view the passwd file and gain privileges to any account, one of which might be root-equivalent.
You can't handle the true
Speaking of gaining privileges to any account for which you know the name, one of the most fascinating bugs I've ever seen was an authentication bypass flaw in phpBB v2.0.12. Prior to v3.x.x, the login cookies included an "autologinid" cookie for the "remember me" functionality. Essentially, this was a serialized version of a few variables, including the userid and hashed password. Without getting into the problems that having a hashed password in cookies brings, there was another issue.
There was a code block which compared the deserialized user-supplied value to the actual string of the hex digits of the MD5 hash like so:
if($uservalue == $md5string){
unicorns_and_rainbows();
} else {
pestilence_and_starvation();
}
So, what's the big deal, you ask? Well, the serialized format looks a bit like this for a md5 hash string:
s:32:"96948aad3fcae80c08a35c9b5958cd89"
The s means that the variable is a string, the 32 is the length (32 bytes) and the rest is the value itself. If we replace this with b:true (meaning a boolean value of "true") something funny happens.
You see, "==" is the equality operator, while "===" is the strict equality operator. The difference is that the equality operator will convert variables to allow comparison, whereas the strict equality operator will fail. Essentially, when we provide an autologin cookie which includes "b:true", the code struct converts the string down to boolean (any non-null non-zero string becomes "true") and compares true to true, making the code block a bit more like the following:
if($md5value){
kitties_and_sparkles();
} else {
the_ear_scene_from_reservoir_dogs();
}
In the end, dear friends
Authentication bypass flaws are numerous and varied. Moreover, they are often extraordinarily difficult to detect with automated techniques or prevent with WAF or IDS solutions, unless they are already known. Manual testing and code review are the best ways to catch and prevent these flaws.
