©2009 Justin C. Klein Keane

PHP Code Auditing

Session 4.3 – Information Disclosure &Authentication BypassJustin C. Klein Keane

jukeane@sas.upenn.edu

Auth Bypass

Authentication bypass is a vulnerability that allows an attacker to gain access to functionality without providing valid credentials

Attackers may seek to steal an authenticated users session

May also be possible to initiate a privileged session without credentials

Some functionality may not need a session

Session Handling

PHP controls “session” data via a PHPSESSID cookie

Session Cookies

Difficult to predict/guess However, stored on the filesystem Location determined by settings in /etc/php.inisession.save_path = "/var/lib/php/session"

; Whether to use cookies.session.use_cookies = 1; This option enables administrators to make their users invulnerable to; attacks which involve passing session ids in URLs; defaults to 0.; session.use_only_cookies = 1; Name of the session (used as cookie name).session.name = PHPSESSID; Initialize session on request startup.session.auto_start = 0; Lifetime in seconds of cookie or, if 0, until browser is restarted.session.cookie_lifetime = 0; The path for which the cookie is valid.session.cookie_path = /; The domain for which the cookie is valid.session.cookie_domain =

Permissions on Session Dir

# ls -lah /var/lib/phptotal 156K

drwxr-xr-x 3 root root 4.0K Jun 2 12:13 .drwxr-xr-x 21 root root 4.0K Jun 2 12:42 ..drwxrwx--- 2 root apache 132K Jun 22 14:37 session

Note that apache can read and write in this directory

phpinfo() Disclosure

Data Can be Leaked

If attacker can leverage webapp to list the cookie directory they can modify their own cookies

Cookie isn't tied to an IP, so cookie holder automatically gains session access

Cookie can also be stolen from the end user JavaScript can access cookies with domain

restrictions

Logical Flaws

Application fails to check credentials properly Name collisions for instance These will not be programming errors so are

much more difficult to detect

Limited Authentication

Application may only check for authentication in one place

Some files may assume that authentication has taken place but may be accessible outside of that flow

Brute Force

Steps should be taken to limit authentication attempts

At the very least log auth attempts and alert someone on multiple failures

Be sure to limit login failure feedback (don't alert an attacker to whether or not a username or password exists)

Be wary of password recovery functionality and information it might disclose to an attacker

Logout Failure

Applications that don't properly end sessions could leave them open for exploitation

Kiosks or other public terminals are prime offenders in these circumstances

Unencrypted Authentication

Cookies and/or post data may be stolen Forms themselves should be encrypted, not just

their post targets MITM plain text keystroke loggers could be

utilized on unencrypted login forms

Information Disclosure

There are many seemingly innocuous ways that information valuable to an attacker can be disclosed

Debugging messages phpinfo() output can reveal configuration informaiton Plain text files such as .ini or .htaccess or .htpasswd

files could be exposed Directory listing could show files that would otherwise

be difficult to find HTML comments

Exposed Information

Assume any web accessible file can be read by an attacker

Tools for brute force guessing filenames and directories exist

Look at include files to make sure they can't be abused by being called directly

For Next Time

Download the next exercise Identify at least one of the following:

Arbitrary code execution vulnerability Information disclosure vulnerability Arbitrary file include vulnerability Arbitrary file upload vulnerability Authentication bypass vulnerability Credential exposure (how can the admin

password be easily recovered)