17/04/2014

PHP Source Code Chunks of Insanity (Delete Post Pages) Part 4

Intro 

This post is going to talk about source code reviewing PHP and demonstrate how a relatively small chunk of code can cause you lots of problems.

The Code

In this article we are going to analyze the code displayed below. The code displayed below might seem innocent for some , but obviously is not. We are going to assume that is used by some web site to delete posts from the logged in users securely.
 <?php  
 require_once 'common.php';   
 validatemySession();   
 mydatabaseConnect();  
  $username = $_SESSION['username'];// Insecure source  
 $username = stripslashes($username);// Improper filtering  
 $username = mysql_real_escape_string($username);//Flawed function  
 // Delete the post that matches the postId ensuring that it was created by this user  
  $queryDelete = "DELETE FROM posts WHERE PostId = " . (int) $_GET['postId']. " AND Username = '$username'";  
  if (mysql_query($queryDelete))// Bad validation coding {  
       header('Location: myPosts.php'); }  
  else {  
      echo "An error has occurred.";   
      }  
 ?>  

If you look carefully the code you will se that the code is vulnerable to the following issue: SQL Injection!!
    
Think this is not accurate , think better.

The SQL Injection

An adversary in order to exploit this vulnerability would not have to script custom tools, would only have to have good knowledge of SQL injections methodologies and exposure to PHP coding.

Vulnerable Code:

1st Code Chunk 
 $username = $_SESSION['username'];// Insecure source  
 $username = stripslashes($username);// Improper filtering 
 $username = mysql_real_escape_string($username);//Flawed function  
2nd Code Chunk: 
 $queryDelete = "DELETE FROM posts WHERE PostId = " . (int) $_GET['postId']. " AND Username = '$username'";  
3rd Code Chunk:    
 if (mysql_query($queryDelete))  

The mysql_real_escape_string function is based in the black list mentality. What it does is that escapes special characters in the un-­‐escaped string, taking into account the current character set of the connection so that it is safe to place it in a mysql_query. More specifically mysql_real_escape_string calls MySQL's library function mysql_real_escape_string, which prepends backslashes to the following characters:

1. \x00 
2. \n
3. \r
4. \
5. '
6. “

7. \x1a.

Due to this odd behavior characters such as the % and SQL keywords are not being affected, so queries that have the form of e.g. SELECT BENCHMARK(50,MD5(CHAR(118))) would be executed normally. A realistic scenario would be to use a query such as the one below:

Step1: SQL Payload that would cause the post to delete without the postId be known. 
 LIKE %’s’  

Note1: At this point we assume that the attacker knows the format of the username e.g. its user plus a two-­‐digit number. 

Step2: SQL Payload mutated in order to bypass the filters.
 LIKE CHAR(37, 8217, 115, 8217)  

Note2: Further expanding on the attack if the Web App does not have a standard format for the usernames then the adversary can brute-­‐force the username first latter e.g. try out all English letters e.g. LIKE %’a’, LIKE %’b’, LIKE %’c’ ... etc. and eventually execute the query with a valid first username letter. Translating that to an obfuscated SQL Payload would be LIKE CHAR(39, 97, 37, 39), LIKE CHAR(39, 98, 37, 39) etc.

Note3: The mysql_real_escape_string function is deprecated as of PHP 5.5.0, and will be removed in the future. Instead, the MySQLi or PDO_MySQL extension should be used. Alternatives to this function include: mysqli_real_escape_string and PDO::quote. The mysql_query() function sends a unique query (multiple queries are not supported) to the currently active database on the server that's associated with the specified link_identifier. In this specific code example the query returns true if a record is found (any record). This obscure behavior introduces the vulnerability combined of course with the above code. The function used in the mysql_query statement should return a record set only if the correct record set is returned and not just any match.

Note4: This extension is deprecated as of PHP 5.5.0.

Remedial Code:

Provide Server Side filters filter for remediating the vulnerability. Make use of strongly typed parameterized queries (using the bind_param).
 // Using prepared Statements.  
 if ($stmt = $mysqli-­‐>prepare("DELETE FROM posts WHERE PostId = ? AND Username = ? LIMIT 1"))  
 {  
 $stmt-­‐>bind_param('s', $ username); // Bind "$ username" to parameter. 
 $stmt-­‐>execute(); // Execute the prepared statement.  
 ...  
 }  

15/04/2014

PHP Source Code Chunks of Insanity (Post Pages) Part 3

Intro 

This post is going to talk about source code reviewing PHP and demonstrate how a relatively small chunk of code can cause you lots of problems.

The Code

In this article we are going to analyze the code displayed below. The code displayed below might seem innocent for some , but obviously is not. We are going to assume that is used by some web site to post the user comments securely.
<?php require_once 'common.php'; validateMySession(); ?> <html> <head> <title>User Posts</title> </head> <body> <h1>Showing current posts</h1> <form action='awsomePosts.php'>
<p>MySearch: <input type='text'  value='<?php if (isset($_GET['search'])) echo htmlentities($_GET['search'])?>'></p> <p><input type='submit' value='MySearch'></p>
</form> <?php showAwsomePosts();?> </body>
</html>
If you look carefully the code you will se that the code is vulnerable to the following issue: Stored XSS!!
    
Think this is not accurate , think better.

The Stored XSS

An adversary would need to have very good knowledge of encoding/XSS attacks to exploit this vulnerability. This vulnerability is based on a well known UTF-­‐7 encoding attack that is considered to be old. Other filter bypassing techniques can be used to bypass htmlentities such as JavaScript events.

Vulnerable Code: 
1:  <p>MySearch: <input type='text' value='<?php if (isset($_GET['search'])) echo htmlentities($_GET['search'])?>'></p>// Vulnerable to XSS UTF-­‐7 attack  
The page that the potential XSS resides on doesn't provide a page charset header (e.g. header('Content-­‐ Type: text/html; charset=UTF-­‐8'); or <HEAD><META HTTP-­‐EQUIV="CONTENT-­‐TYPE" CONTENT="text/html; charset=UTF-­‐8">), any browser that is set to UTF-­‐7 encoding can be exploited with the following XSS input (she don't need the charset statement if the user's browser is set to auto-­‐ detect and there is no overriding content-­‐types on the page in Internet Explorer and Netscape rendering engine mode). This does not work in any modern browser without changing the encoding type.

Example1 UTF-­‐7 Encoding

Input Payload :

1:  <script>alert(1)</script>  

Output (UTF-­‐7): 
1:  +ADw-­‐script+AD4-­‐alert('XSS')+ADw-­‐/script+AD4APA-­‐/vulnerable+AD4-­‐  

Example2 JavaScript Events

Injecting also JavaScript events to the htmlentities function of php will also by pass the filter.

The code before injection:     
1<p>MySearch: <input type='text' value='<?php if (isset($_GET['search'])) echo htmlentities($_GET['search'])?>'></p>  

The code after injection:
<p>MySearch: <input type='text' value='onerror='alert(String.fromCharCode(88, 83, 83))'></p>  


Note: This example needs further testing to see if it is applicable.

Remedial Code:

Provide Server Side filters for the vulnerability. Make use of regular expressions and html encode the variables whether displayed back to the user or not.

1st Layer of defense 
1:  //XSS filter the value because this value might be printed later on back in the user. if preg_match ("/[a-­‐zA-­‐Z]+/", "", $search){  
2:  showPosts();  
3:  }  
Note: Using regular expressions to replace parts of the input and proceed with further processing the input is not recommended, once a malicious input is identified should be rejected (e.g. using preg_match instead of preg_replace).

2nd Layer of defense 
1:  header('Content-­‐Type: text/html; charset=UTF-­‐8');  
2:  // This function will convert both double and single quotes. mb_convert_encoding($search, 'UTF-­‐8');  


Countermeasures Summarized
  1. Specify charset clearly (HTTP header is recommended)
  2. Don't place the text attacker can control before <meta>
  3. Specify recognizable charset name by browser.
  4. Apply regular expressions based on the white list mentality.
Note: mb_convert_encoding converts the character encoding of the input string to the desired encoding. 

References:

1. https://www.owasp.org/index.php/XSS_Filter_Evasion_Cheat_Sheet#UTF-­‐7_encoding 
2. http://php.net/manual/en/function.mb-­‐convert-­‐encoding.php
3. http://shiflett.org/blog/2005/dec/google-­‐xss-­‐example
4. http://www.motobit.com/util/charset-­‐codepage-­‐conversion.asp
5. http://openmya.hacker.jp/hasegawa/security/utf7cs.html 
6. http://wiremask.eu/?p=tutorials&id=10 


PHP Source Code Chunks of Insanity (Logout Pages) Part 2

Intro 

This post is going to talk about source code reviewing PHP and demonstrate how a relatively small chunk of code can cause you lots of problems.

The Code

In this article we are going to analyze the code displayed below. The code displayed below might seem innocent for some , but obviously is not. We are going to assume that is used by some web site to de-validate the user credentials and allow the users to logout securely.

1:  <?php  
2:  require_once 'common.php';  
3:  if (isset($_SESSION['username']))//Insecure source  
4:  {  
5:  session_unset();// In properly destroyed session.  
6:  }  
7:  header('Location: index.php'); ?>  


I you look carefully the code you will se that the code is vulnerable to the following issues:
  1. NULL De-­Authentication Bypass    
  2. No Proper Session Termination    
Think this is not accurate , think better.

NULL De-­Authentication Bypass 

Exploitation:

An adversary may on purpose exploit this vulnerability possibly without the need of developing any costume tools (but needs a good understanding of PHP design flaws). More specifically an adversary can manipulate the cookie parameter and de-­‐validate the logout process by injecting a NULL value in the begging of the username (after the authentication). This would result into maintaining the user Web resources available for the specific session-­‐id even after the logout is performed. 

Vulnerable Code:    
if (isset($_SESSION['username']))// Malicious de-­validation cancel  
Assuming that the target username is user12 potential malicious payloads that could exploit the vulnerability displayed above would be user[space]12 , %4e%55%4c%4c,user12, user12[space], %20user12, [space] [space]user12 [space],user12 , user12, user12,, user12NULL NULLuser12 etc. This is applicable due to the fact that if multiple parameters are supplied then the isset will return TRUE only if all of the parameters are set. Evaluation goes from left to right and stops as soon as an unset variable is encountered. The attack should occur after the user successfully authenticates her self.

Note1: At this point it should be noted that when on, register_globals (which is on by default in PHP < 5.3.0), will allow an adversary to populate the cookie username variable from various user input such request variables from HTML hidden form fields, Web Application URL’s etc. which translates into working as a vulnerability amplifier! Also this might lead into allowing POST to GET interchanges, promoting CSRF like attacks (e.g. the web app does not distinguish POST from GET).

Note2: This feature has been DEPRECATED as of PHP 5.3.0 and REMOVED as of PHP 5.4.0. 

Remedial Code:
1:  //the filter makes sure the username has no spaces. if (strpos($username, " ") !== false){  
2:  // De-­‐validate the session  
3:  }  

2nd Code Chunk:
1:  trim("^$", $username)//Not recommended to process malicious payloads, only identify.  

Note: The NULL value translates into an empty string when validations come. 

No Proper Session Termination

An adversary may on purpose exploit this vulnerability without the need of developing any costume tools. This attack might be used to perform vertical/horizontal user escalation (e.g. the cookie session-­‐ id is assigned to a new user, and the new user automatically gains access to previous user Web resources, assuming that the Web Apps makes access control decisions by using only the session-­‐id. Another attack scenario would be that the session is leaked though a blog post and the adversary makes use of the non de-­‐validated leaked session to gain access to the Web Application user resources etc.).

Vulnerable Code: 
1:  session_unset(); // Improper handling of the session.  
Note1: The function shown above does not properly de-­‐validate the session. The session_unset function just clears the $_SESSION variable. It’s equivalent to doing $_SESSION = array(); So this does only affect the local $_SESSION variable instance, but not the session data in the session storage, everything else remains unchanged (including the session identifier). In this occasion the session_unset is used to destroy/reset the session instead of the session_destroy function in the logout page. The session_destroy() function destroys all of the data associated with the current session.

Note2: The variable session_unset is considered to be deprecated code that does not use $_SESSION.

Remedial Code: 
1:  function destroySession() {  
2:  $params = session_get_cookie_params(); setcookie(session_name(), '', time() -­‐ 42000,  
3:  $params["path"], $params["domain"],  
4:  ... );  
5:  session_destroy(); }  




References:

1. http://php.net/manual/en/security.globals.php
2. https://www.owasp.org/index.php/Unvalidated_Input
3. http://php.net/manual/en/function.isset.php
4. http://php.net/manual/en/function.trim.php 

14/04/2014

PHP Source Code Chunks of Insanity (Logins Pages) Part 1

Intro 

This post is going to talk about source code reviewing PHP and demonstrate how a relatively small chunk of code can cause you lots of problems.

The Code

In this article we are going to analyze the code displayed below. The code displayed below might seem innocent for some , but obviously is not. We are going to assume that is used by some web site to validate the credentials and allow the users to login.

 <?php  
     require_once 'commonFunctionality.php';  
        if (validateCredentials($someUsername, $somePassword)) {  
           header('Location: myIndex.php'); }  
        else {  
           header('Location: wrong_login.php'); }  
 ?>  

If you look carefully the code you will se that the code is vulnerable to the following issues:
  1. Reflected/Stored XSS
  2. Session Fixation/Session Hijacking 
  3. Lock Out Mechanism Not In Place
Think this is not accurate , think better.

Session Fixation/Session Hijacking

An adversary may on purpose exploit this vulnerability without the need of developing any costume tools (e.g. the session gets exposed in a blog post or within the same application or is passed in the http referrer and gets cached in a Web Proxy controlled by an adversary). Also this attack might be used to abuse user privileges (e.g. escalate privileges of one user by manipulating the session identifier, perform vertical and horizontal privilege escalation etc.). It should be noted at this point that the issues described above are possible only if the web application makes decisions based only on the session identifier.

Vulnerable Code:
session_unset(); // Improper handling of the session.  

Explanation:

The function shown above does not properly handle the session. The session_unset function just clears the $_SESSION variable. It’s equivalent to doing $_SESSION = array(); So this does only affect the local $_SESSION variable instance, but not the session data in the session storage, everything else remains unchanged, including the session identifier. In this occasion the session_unset is used to clear the session from user information, instead of the session_destroy function in the login page (instead of the logout page), which translates into not logging out properly the previous user (e.g. the next user will possibly again access to the account of the previous user).The Web Application makes decisions without evaluating other cookie parameters to give access to Web Resources (e.g. the decision making process is the username, a variable called logged_in and the session id). Ideally this should partly be fixed by using also another variable e.g. $_SESSION[‘logged_in’] = true (see code below). 

Exploitation:

An adversary may on purpose exploit this vulnerability without the need of developing any costume tools (e.g. the session gets exposed in a blog post or within the same application or is passed in the http referrer and gets cached in a Web Proxy controlled by an adversary). Also this attack might be used to abuse user privileges (e.g. escalate privileges of one user by manipulating the session identifier, perform vertical and horizontal privilege escalation etc.). It should be noted at this point that the issues described above are possible only if the web application makes decisions based only on the session identifier.

Business Impact:

The possibility of this vulnerability going public (e.g. blog posts start appearing in the internet revealing the issue) would cause severe costumer reputation and revenue loss; this vulnerability allows an adversary to potentially launch personalized phishing attacks (e.g. deceive a user in clicking a link with a fixed session etc.) abuse web application user privileges and possibly allow phishing campaigns. 

Remedial Code: 
 function init_session() { ...  
 session_start(); // Start the php session  
 session_regenerate_id(true); // regenerated the session, delete the old one. $_SESSION['logged_in'] = true;  
 ... }  
Regenerate the session ID anytime the session's status changes. That means any of the following:
  1. User authentication (e.g. in the login page, other multiple authentication stages etc.).
  2. Storing privilege level information in the session (e.g. temporary random variables, valid only
    for the current session etc.)
  3. Regenerate the session identifier whenever the user's privilege level changes. 
Lock Out Mechanism Not In Place

An adversary may on purpose exploit this vulnerability without the need of developing any costume tools (e.g. make use of Burp Intruder or Hydra to perform online password cracking attacks etc.).

Vulnerable Code:

 $username = $_POST['username']; $password = $_POST['password'];  
Note: The Web Application should implement server side controls in the login page to prevent password brute forcing attacks.

Remedial Code:


 function lockout($username, $password) { $now = time();  
 $counter = 0  
 if (validateCredentials){  
 $counter = $counter+1// Save that in database, retrieve login attempt times and compare the  
 times ...  
 } }  

The Web Application should take the following actions to prevent online dictionary attacks:
  1. Make use of login attempt counters (e.g. allow 3 failed attempts within 30 minutes).
  2. Associate the user IP with the session (e.g. generate proper audit trails to later on ban that ip).
    Include the user's IP address from $_SERVER['REMOTE_ADDR'] in the session. Store it in
    $_SESSION['remote_ip'].
  3. Run integrity checks of the session (although this functionality might be included in another
    function).
  4. Include the user agent from $_SERVER['HTTP_USER_AGENT'] in the session. Store it in a session
    variable $_SESSION['user_agent']. Then, on each subsequent request check that it matches (Note: The user agent can be very easily spoofed). 
Note: It should also be noted that since the session parameters are also populated with sensitive information such as the username, further actions should be performed to remove all this information (e.g. replace username with temporary user-­‐id). Gaining access to the username can significantly reduce a brute-­‐force login attempt. 

Reflected/Stored XSS

An adversary can exploit this vulnerability without the need of developing any costume tools. Point and click tools are available in the Internet and might be used to exploit this vulnerability (e.g. Social Engineering Tool etc.). Further escalating on the issue an adversary might use this attack to compromise multiple company sites (e.g. make use of it as an XSS proxy).

Note: This might also lead into unrestricted redirection attacks. Due to limited amount of time in my disposal no further investigation was conducted (e.g. load the login page to an Apache as and see if the variable username is passed the URL or the location header field.) 

Vulnerable Code:
 $_SESSION['username'] = $username;  

Note: Even though we don’t have access to the rest of the Web App code, it is highly likely that the username value might be displayed back to the user and the Http header fields. 

Remedial Code: 

Provide Server Side filters for the vulnerability. Make use of regular expressions and html encode the variables whether displayed back to the user or not (for providing security in depth and making sure that the Set-­‐Cookie header field or other fields cannot be abused).

1st Layer of defense

 $username = preg_match ("/[^a-­‐zA-­‐Z0-­‐9_\-­‐]+/", "", $username)  

Note: Ideally the username should be replaced with a temporary user id (preferable random that expires along with the cookie session). Using regular expressions to replace parts of the input and proceed with further processing the input is not recommended, once a malicious input is identified should be rejected (e.g. using preg_replace instead of preg_match). Also note that this functionality should ideally be also part of the validateCredentials function or the input should be processed before used by the validateCredentials function. 

2nd Layer of defense


1. // This function will convert both double and single quotes. 
2. htmlentities($username , ENT_QUOTES);  

Input: 
 <script>alert(1)</script>   

Output:
 &#x3c;&#x73;&#x63;&#x72;&#x69;&#x70;&#x74;&#x3e;&#x61;&#x6c;&#x65;&#x72;&#x7 4;&#x28;&#x31;&#x29;&#x3c;&#x2f;&#x73;&#x63;&#x72;&#x69;&#x70;&#x74;&#x3e;  


Note: With htmlentities, all characters which have HTML character entity equivalents are translated into these entities (displayed above). 

References:

  1. https://www.owasp.org/index.php/Account_lockout_attack
  2. http://stackoverflow.com/questions/17217777/difference-­‐between-­‐unset-­‐and-­‐session-­‐unset-­‐ in-­‐php
  3. http://shiflett.org/articles/session-­‐fixation
  4. http://shiflett.org/articles/session-­‐hijacking 

06/04/2014

Clickalicious Candies...

Introduction

This articles is written by me to show that Clickjaking should not be underestimated as a vulnerability, especially when combined with other vulnerabilities. Clickjaking (User Interface redress attack) is a malicious technique of tricking a Web user into clicking on something different from what the user perceives they are clicking on, thus potentially revealing confidential information or taking control of their computer while clicking on seemingly innocuous web pages. That is good in theory , but how can someone do that in practice? The answer is simple , ridiculously easy...



Even a script kiddy can become a "hacker" con-artist when combining  vulnerabilities. In this post I am going to show how a simple CSRF attack can actually be combined with a clickjaking attack, of course the same think can happen with vulnerabilities such as session fixation and XSS.

The Clickalicious Attack

In order to perform the attack we would have to be based in the following assumptions:
  1. We identified a website that is vulnerable to Clickjaking (e.g. is missing the X-Frame-Options) .
  2. The same Web Site is also vulnerable to CSRF (e.g. the CSRF is a simple html form). 
  3. The CSRF attack exploits a vulnerability that a malicious user can actually submit the form with polluted hidden form fields (for simplicity I am going to use a simple html form for the demo).   
Step 1: Frame the vulnerable web site to our iframe, in our example I am going to use www.w3sschools.com (such a lovely site).

 <iframe src="http://www.w3schools.com"></iframe>  

The visual outcome of this code wold be:


Note: The picture above displays only the iframe and not the whole page. In this particular example the html page was loaded from my hard disk.

Step 2: Project the CSRF to the vulnerable web site within the iframe created in Step 1. The simple source code to do that would be:

 <html>  
 <body>  
 <head>  
 <style>  
 form  
 {  
 position:absolute;  
 left:30px;  
 top:100px;  
 }  
 </style>  
 </head>  
 <form>  
 First name: <input type="text" name="firstname"><br>  
 Last name: <input type="text" name="lastname">  
 </form>  
 <iframe src="http://www.w3schools.com"></iframe>  
 </body>  
 </html>  

See the CSS absolute element? The CSS 2.1 defines three positioning schemes:
  1. Normal flow
  2. Absolute positioning
  3. Position: top, bottom, left, and right
Out of these three CSS features we are interested in the Absolute positioning feature. An absolutely positioned feature has no place in, and no effect on, the normal flow of other items. It occupies its assigned position in its container independently of other items.The visual outcome of this code wold be:


Note: The same exploit can be build using a stored XSS. The only difference would be that you would have to project the vulnerable CSRF within the space controlled by the XSS (without taking advantage of a Clickjaking vulnerability).

Tools such as NoScript would be able to detect the Clickjaking attack:


Note: See the icon stating that the script was blocked.

Epiloge

Next time you run a penetration test , think again before you characterize a Clickjaking as low!! especially if it is a login page. And be aware of the Script Kiddies.


The moto of this article is going to be think before you click...

References:
  1. http://www.w3schools.com/cssref/pr_class_position.asp 
  2. http://en.wikipedia.org/wiki/Cascading_Style_Sheets#Positioning