26/12/2012

CSRFing the Web...

Introduction

Nowadays hacking, as already mentioned in my previous articles, has been industrialized, meaning that professional hackers are constantly hired to make money out of practically anything and therefore all Web Application vulnerabilities have to be understood and defeated.

This article is going to talk about what Cross Site Request Forgery (CSRF) is, explain how can someone perform a successful CSRF attack and describe how to amplify a CSRF attack (e.g. combine CSRF with other vulnerabilities). CSRF is an attack which forces an end user to execute unwanted actions on a web application in which he/she is currently authenticated (simplistically speaking). With a little help from social engineering (like sending a link via email/chat), an attacker may force the users of a web application to execute actions of the attacker's choosing.

A successful CSRF exploit can compromise end user data and operation in case of a normal user. If the targeted end user is the administrator account, this can compromise the entire web application. More specifically CSRF is a Web Application vulnerability that has to exploit more than one design flaws in order to be successful. The design flaws that a CSRF attack can take advantage of are:

Input Validation (e.g. Convert POST to GET)
Access Control (e.g. Session Fixation)
Privilege Assignment (e.g. Horizontal Privilege Escalation)

Note: Of course depending on the situation other type of vulnerabilities can be combined with a CSRF as part of a post exploitation process such as SQL Injection (e.g. SQL Inject the cookie and get access to valid cookie repository in the database).

History of CSRF

CSRF vulnerabilities have been known and in some cases exploited since 2001. Because it is carried out from the user's IP address, some website logs might not have evidence of CSRF. Exploits are under-reported, at least publicly, and as of 2007 there are few well-documented examples. About 18 million users of eBay's Internet Auction Co. at Auction.co.kr in Korea lost personal information in February 2008. Customers of a bank in Mexico were attacked in early 2008 with an image tag in email. The link in the image tag changed the DNS entry for the bank in their ADSL router to point to a malicious website impersonating the bank.

Severity of CSRF

According to the United States Department Of Homeland Security the most dangerous CSRF vulnerability ranks in at the 909th most dangerous software bug ever found. Other severity metrics have been issued for CSRF vulnerabilities that result in remote code execution with root privileges as well as a vulnerability that can compromise a root certificate, which will completely undermine a public key infrastructure.

But what exactly is a CSRF

CSRF is a form of confused deputy attack. Imagine you’re a malcontent who wants to harm another person in a maximum security jail. You’re probably going to have a tough time reaching that person due to your lack of proper credentials. A potentially easier approach to accomplish your misdeed is to confuse a deputy to misuse his authority to commit the dastardly act on your behalf. That’s a much more effective strategy for causing mayhem.

In the case of a CSRF attack, the confused deputy is your browser. After logging into a website, the website will issue your browser an authentication token within a cookie (well not always). Within each subsequent http POST or GET requests send, the cookie bind to the request will let the site know that you are authorized to take whatever action you’re taking. Here I am referring to a typical authentication and authorization scheme that most Web Application use.

Suppose you visit a malicious website soon after visiting your bank website or visit another website while being logged to your bank web account. Your session on the previous site might still be valid (btw please de-validate session before closing the browser). Thus, visiting a carefully crafted malicious website (perhaps you clicked on a spam link) could cause an Html form post to the previous website. Your browser would send the authentication cookie back to that site and appear to be making a request on your behalf, even though you did not intend to do so.

Yes but what is a CSRF

A CSRF is a POST or GET http request that when send to the vulnerable Web Application under certain conditions can cause the Web Application to perform an action on behalf of the user. Now meaningful CSRF attacks are those that can cause loss of Integrity or Confidentiality or Availability of the victim user data. For example if an e-Banking Web site is vulnerable to CSRF and the function of the Web Site that is vulnerable is responsible for transferring money, then this is a CSRF with high severity and should be fixed.

This is an example of a simple CSRF:

http://www.vulnerable.com/?transferEuros=3000?maliciousUserAccount=9832487

Note: The link displayed above when clicked can authorize a malicious user to transfer 3000 euros from of the victim user account to the malicious user account with id 9832487, assuming of course that no proper counter measures have been taken.

The following diagram shows how can this happen more analytically:

Note: The diagram above shows the steps an attacker can take to exploit the vulnerability (step 4 designtes the execution of the CSRF payload that performs the malicious action). It is pretty much similar to a Cross Site Script attack scenario. An attacker sends an e-mail to an Html enabled e-mail client that contains some sample images deliberately uploaded to a malicious server (controlled by the attacker), along with the malicious URL (or a malicious html form) that performs the CSRF function, waits until the user opens the e-mail and downloads the images or sets his/her e-mail to receive a notification when the victim user reads his/her e-mail. Thens he/she waits infront of the logs of the malicious image server or waits to receive a read e-mail receipt in his/her mailbox. After the image is downloaded or the read receipt is received he/she will try to verify that the malicious function was executed. Another scenario would be to calculate what times user interact with the web site and calculate the attack times before sending the malicious URL/Html form.

The diagram above explains that the CSRF (meaning the vulnerable link described previously) can be injected into an HTML enabled e-mail and be executed by a legitimate user. Now if the link (or else the CSRF vulnerable link) is bind to the Web Application session (which it should be) then the victim user would have to be logged to the vulnerable Web Application for the attack to be successful. If the link is not bind to the Web Application session then the this is not a CSRF vulnerability, is an Insecure Direct Object References vulnerability or Failure to Restrict URL Access also described by OWASP top 10 chart. Both vulnerabilities have to do with inappropriate access control and are completely irrelevant to CSRF or CSRF like vulnerabilities.

Now that you got a better grasp of what a CSRF attack is I can be more technical and explain more on how a CSRF attack look like by using http requests. So again the link described above looks as a Http request like that:

GET /homepage/transferEuros=3000?maliciousUserAccount=9832487 HTTP/1.1

Host: victim.com

Keep-Alive: timeout=15

Connection: Keep-Alive

Cookie: Authentication-Token

Accept: */*

Note: The vulnerable link when clicked will generate the GET request shown above and will, if it is successful, generate a 200 Http response message saying that the transaction was completed successfully.

Explaining more what a CSRF is

The following diagram shows thoroughly how a CSRF can be exploited:

Step 1: Mallory sends a phishing email to Bob, inviting him to visit her web server in order, for example, to win an iPhone 5. She has already created a web page at her web server with a hidden request to the Web Application where Bob is logged in. She has added some buttons to lure the victim in order to click on her page and win the iPhone!

Step 2: Bob visits the page at Mallory's Web server. Maybe he is greedy or he may not, however he clicks on the button in order to win the iPhone!...

Step 3: The forged request is "legitimized" with Bob's logged-in session and is executed at the web application.

A real-world analogy would be the following: Mallory presented a bank cheque to Bob and Bob puts under his name and signature, but haven't examined what sum of money is written on the cheque.In the following attack scenario, we can see how a malicious user can add a user to a web application just by fooling a logged-in administrator to click on a link.

A different approach to CSRF

Now that I explained a simple CSRF attack it is time to explain a more advanced scenario on how to exploit a CSRF. A CSRF most of the time is not easily recognizable and that is why lots of people cannot identify a CSRF unless it is really obvious, just like the one I just described. A CSRF issue raises when:

A Web Application performs critical functions using GET Http requests (e.g. to transfer money, add users by just clicking a link etc).
Does not distinguish between POST and GET requests (e.g. a Html form can be easily converted into a GET request, meaning that a Html POST request can be converted to a link etc).
Has a loose association or else not tight access control (e.g. does not use AntiCSRF tokens, is vulnerable to session fixation e.t.c).
Is vulnerable to Cross Site Scripting (e.g. someone can use JavaScript to formate a valid Html POST form by using the XMLHTTP object along with an auto submit script etc).
The application is passing the session to the URL along with the AntiCSRF token.
The session can be fixated and the AntiCSRF token is predictable or static.

Note: There are a lot more ways to perform a CSRF attack, but there are out of scope.

CSRF and POST to GET Interchange

It is common knowledge that when the Web Application does not distinguish between POST and GET requests an attacker can convert a POST Http request to a GET Http request and generate a link equivalent to the one described previously. Burp Suite does that automatically that from the proxy tab by right clicking the request and doing a change method (it also recalculates the Http request size in the content size field).

The attack just described is can be enhanced by using an auto submit script such as this one:

"JavaScript"> setTimeout('document.CSRFHtmlForm.submit()',5000);

Note: A very useful tool is the CSRF PoC tool also found in Burp Suite. Burp Suit CSRF PoC will generate a quick CSRF PoC for you (most of the time you would have to modify that to be realistic).

CSRF and Cross Site Scripting (XSS)

Cross-Site Scripting (XSS) attacks are a type of injection problem, in which malicious scripts are injected into the otherwise benign and trusted web sites. Cross-site scripting (XSS) attacks occur when an attacker uses a web application to send malicious code, generally in the form of a browser side script, to a different end user. Flaws that allow these attacks to succeed are quite widespread and occur anywhere a web application uses input from a user in the output it generates without validating or encoding it.

An attacker can use XSS to send a malicious script to an unsuspecting user. The end user’s browser has no way to know that the script should not be trusted, and will execute the script. Because it thinks the script came from a trusted source, the malicious script can access any cookies, session tokens, or other sensitive information retained by your browser and used with that site. These scripts can even rewrite the content of the HTML page. But can also inject an Html form with an auto submit script to execute the malicious CSRF. The example is very easy to understand so I wont have to give an example.

Note1: You can see how an XSS vulnerability can be combined with a CSRF attack at the CSRF tool section (e.g. by injection also the auto submit javascript code along with the CSRF).

Note2: Of course an XSS can be combined with a CSRF attack using the XMLHTTP and auto submit javascript features. A very good XSS (XMLHTTP)/CSRF example can be found here. The specific post explains an XSS/CSRF bug found in gmail.

CSRF and Session Fixation

Session Fixation is an attack that permits an attacker to hijack a valid user session. The attack explores a limitation in the way the web application manages the session ID, more specifically the vulnerable web application. When authenticating a user, it doesn’t assign a new session ID, making it possible to use an existent session ID. The attack consists of inducing a user to authenticate himself with a known session ID, and then hijacking the user-validated session by the knowledge of the used session ID. The attacker has to provide a legitimate Web application session ID and try to make the victim's browser use it.

The session fixation attack is a class of Session Hijacking, which steals the established session between the client and the Web Server after the user logs in. Instead, the Session Fixation attack fixes an established session on the victim's browser, so the attack starts before the user logs in. There are several techniques to execute the attack; it depends on how the Web application deals with session tokens. Below are some of the most common technique:

Session token in the URL argument: The Session ID is sent to the victim in a hyperlink and the victim accesses the site through the malicious URL.

Session token in a hidden form field: In this method, the victim must be tricked to authenticate in the target Web Server, using a login form developed for the attacker. The form could be hosted in the evil web server or directly in html formatted e-mail.

Session ID in a cookie:

Client-side script:

Most browsers support the execution of client-side scripting. In this case, the aggressor could use attacks of code injection as the XSS (Cross-site scripting) attack to insert a malicious code in the hyperlink sent to the victim and fix a Session ID in its cookie. Using the function document.cookie, the browser which executes the command becomes capable of fixing values inside of the cookie that it will use to keep a session between the client and the Web Applicatio

<META> tag:

<META> tag also is considered a code injection attack, however, different from the XSS attack where undesirable scripts can be disabled, or the execution can be denied. The attack using this method becomes much more efficient because it's impossible to disable the processing of these tags in the browsers.

After describing the Session Fixation attack I will explain the attack scenario described in the picture using new chain of vulnerabilities (e.g. Session Fixation -> CSRF). An attacker sends an e-mail to an Html enabled e-mail client that contains some sample images uploaded to a malicious server, along with the malicious URL that performs the CSRF function and this time is bind to the fixed session (by using one or more of the techniques described above), waits until the user opens the e-mail and downloads the images or sets his/her e-mail to receive a notification when the victim user reads his/her e-mail. Thens he/she waits the logs of the malicious image server to be updated or waits to receive a read e-mail receipt in his/her mailbox. After the image is downloaded (and he/she sees that from e.g. /www/var/apache.logs etc) or the read receipt is received he/she will try to verify that the malicious function was executed.

The link with the fixated token will produce a GET Http request that looks like this:

GET /homepage/transferEuros=3000?maliciousUserAccount=9832487 HTTP/1.1

Host: victim.com

Keep-Alive: timeout=15

Connection: Keep-Alive

Cookie: Fixated Session

Note1: Obviously a Session Fixation attack can have devastating results even without the use of CSRF flaw. What I am saying here is that a Session Fixation combined with a CSRF attack amplifies the attack (e.g. the attacker will optimize his/her time attack frame by exploiting a chain of vulnerabilities rather than a single vulnerability).

Note2: Similar exploitation scenarios you can have when the web application does not provide the user with an authentication mechanism e.g. open registration forms used for submitting credit card details.

CSRF and bad architecture design

Although this category might not be exactly a CSRF issue, it is still very similar to a CSRF attack. This type of attack refers to the occasions were no proper random values are generated (based on user credentials) or values that are generated but do not have a session like behavior e.g. lack of authorization, none random CAPTCHA, lack of entity authentication etc. By integrating this type of behavior to your application you endanger the application to became victim to multiple type of attacks.

CSRF and Clickjaking

Clickjacking, also known as a "UI redress attack", happens is when an attacker uses multiple transparent or opaque layers to trick a user into clicking on a button or link on another page when they were intending to click on the the top level page. Thus, the attacker is "hijacking" clicks meant for their page and routing them to other another page, most likely owned by another application, domain, or both. Using a similar technique, keystrokes can also be hijacked. With a carefully crafted combination of stylesheets, iframes, and text boxes, a user can be led to believe they are typing in the password to their email or bank account, but are instead typing into an invisible frame controlled by the attacker.

For example, imagine an attacker who builds a web site that has a button on it that says "click here for a free iPod". However, on top of that web page, the attacker has loaded an iframe with your vulnerable e-banking account, and lined up exactly the "transfer money" button directly on top of the "free iPod" button. The victim tries to click on the "free iPod" button but instead actually clicked on the invisible "transfer money" button. In essence, the attacker has "hijacked" the user's click, hence the name "Clickjacking". Again the attack scenario would be the similar to the ones just described above so there is no need for me to modify and explain again the attack scenarion. What is interesting though would be to show you an iframe that performs a CSRF attack.

Well an iframe that performs a CSRF attack would look something like that:

Note: You can see how beautiful this attack is and how simple and smooth can be implemented.

CSRF and Exposed Session Variables

By simply passing the session or other session variables in the URL e.g. such the AntiCSRF token, means asking for trouble. The Session Tokens (Cookie, SessionID, Hidden Field), if exposed, will usually enable an attacker to impersonate a victim and access the application illegitimately. As such, it is important that they are protected from eavesdropping at all times – particularly whilst in transit between the Client browser and the application servers.

The information here relates to how transport security applies to the transfer of sensitive Session ID data rather than data in general, and may be stricter than the caching and transport policies applied to the data served by the site. Using a personal proxy, it is possible to ascertain the following about each request and response:

Protocol used (e.g., HTTP vs. HTTPS)
HTTP Headers
Message Body (e.g., POST or page content)

Each time Session ID data is passed between the client and the server, the protocol, cache, and privacy directives and body should be examined. Transport security here refers to Session IDs passed in GET or POST requests, message bodies, or other means over valid HTTP requests. As you already understand stealing the Session ID and/or the AntiCSRF token might result in the attacker being able to form links such as the following one:

http://www.vulnerable.com/?sessionid=ligdlgkjdng?anticsrftoken=kjnsdldfksjdnk?transferEuros=3000?maliciousUserAccount=9832487

Note: The above information can be used to generate a link for a malicious user.

The attack scenario?

For my demo I choose multidae vulnerable web application which can be found on OWASP's Vulnerable Apps VM, an intercepting proxy tool (I used Portswigger's Burp Proxy, however it is not essential, just a "View Source" from any browser can work on most cases) and an Apache web server.

In the following picture you can see the main page of Multidae's web application as it can be browsed by any -non authenticated- user.

In this web application any user can register an account, but our goal is to register the account with the administrator's privileges. Below is the "register user" page that any, unauthenticated user can see.

If we view the source of the "Register Account" page, we can identify the forms (and therefore the POST request) that are being sent to the web application. That data are then processed by the application and the user is created.

Now, the attacker can create his own form at his web server and populate the HTML fields with the data of the user he wants to create on the system. (Note: no code expertise is needed in order to create this HTML page!). The following picture, you can see the HTML page that creates on his web server. He creates a user named "andrew", with password "qwerty".

Now he launches the web server (192.168.200.14) hosting this page. At this point, he needs the user's interaction. This could be accomplished, for example, by a phishing attack scenario: the victim receives an email inviting the victim to visit the attacker's page saying "click here to win an iPhone 5", or he could attach this message this "iPhone 5 message" at the page he created!

Just imagine:

And this is how it will appear on the victim's web browser:

The victim, which is at the same time logged in with this account at Multidae web application, is now tricked to click on the button and submit a register user form with the username and password set by the attacker.

Now user "andrew" can log in with the password set during the CSRF request.

At point the CSRF attack scenario is completed. We sucessfuly managed to exploit a CSRF vulnerability and add a user to the vulnerable web application.

The CASE studies for CSRF

This site here contains many popular web sites that were vulnerable to CSRF attacks. An interesting extract from the article can be found here:

"1. ING Direct (ingdirect.com)

Status: Fixed

We found a vulnerability on ING’s website that allowed additional accounts to be created on behalf of an arbitrary user. We were also able to transfer funds out of users’ bank accounts. We believe this is the first CSRF vulnerability to allow the transfer of funds from a financial institution. Specific details are described in our paper.

2. YouTube (youtube.com)

Status: Fixed

We discovered CSRF vulnerabilities in nearly every action a user could perform on YouTube. An attacker could have added videos to a user’s "Favorites," added himself to a user’s "Friend" or "Family" list, sent arbitrary messages on the user’s behalf, flagged videos as inappropriate, automatically shared a video with a user’s contacts, subscribed a user to a "channel" (a set of videos published by one person or group) and added videos to a user’s "QuickList" (a list of videos a user intends to watch at a later point). Specific details are described in our paper.

3. MetaFilter (metafilter.com)

Status: Fixed

A vulnerability existed on Metafilter that allowed an attacker to take control of a user’s account. A forged request could be used to set a user’s email address to the attacker’s address. A second forged request could then be used to activate the "Forgot Password" action, which would send the user’s password to the attacker’s email address. Specific details are described in our paper.

(MetaFilter fixed this vulnerability in less than two days. We appreciate the fact that MetaFilter contacted us to let us know the problem had been fixed.)

4. The New York Times (nytimes.com)

Status: Not Fixed. We contacted the New York Times in September, 2007. ~~As of September 24, 2008, this vulnerability still exists.~~ This problem has been fixed."

Note: You can see from the above extract that CSRF issues are very popular these days.

Tools for CSRFing the Web

The Burp Proxy tool (the Pro version of course) can be used to generate a proof-of-concept (PoC) cross-site request forgery (CSRF) attack for a given request.To access this function, select a URL or HTTP request anywhere within Burp, and choose "Generate CSRF PoC" within "Engagement tools" in the context menu.

When you execute this function, Burp shows the full request you selected in the top panel, and the generated CSRF HTML in the lower panel. The HTML uses a form with a suitable action URL, encoding type and parameters, to generate the required request when the browser submits the form.You can edit the request manually, and click the "Regenerate" button to regenerate the CSRF HTML based on the updated request.

You can test the effectiveness of the generated PoC in your browser, using the "Test in browser" button. When you select this option, Burp gives you a unique URL that you can paste into your browser (configured to use the current instance of Burp as its proxy). The resulting browser request is served by Burp with the currently displayed HTML, and you can then determine whether the PoC is effective by monitoring the resulting request(s) that are made through the Proxy.Some points should be noted regarding form encoding:

    •    Some requests (e.g. those containing raw XML or JSON) have bodies that can only be generated using a form with plain text encoding. With each type of form submission using the POST method, the browser will include a Content-Type header indicating the encoding type of the form that generated the request. In some cases, although the message body exactly matches that required for the attack request, the application may reject the request due to an unexpected Content-Type header. Such CSRF-like conditions might not be practically exploitable. Burp will display a warning in the CSRF PoC generator if this is liable to occur.

    •    If you manually select a form encoding type that cannot be used to produce the required request, Burp will generate a best effort at a PoC and will display a warning.

    •    If the CSRF PoC generator is using plain text encoding, then the request body must contain an equals character in order for Burp to generate an HTML form which results in that exact body. If the original request does not contain an equals character, then you may be able to introduce one into a suitable position in the request, without affecting the server's processing of it.

CSRF PoC Options

The following options are available:

    •    Include auto-submit script - Using this option causes Burp to include a small script in the HTML that causes a JavaScript-enabled browser to automatically submit the form (causing the CSRF request) when the page is loaded.

    •    Form encoding - This option lets you specify the type of encoding to use in the form that generates the CSRF request. The "Auto" option is generally preferred, and causes Burp to select the most appropriate encoding capable of generating the required request.

The following picture shows a screen shot from Burp CSRF PoC tool while doing right click on an intercepted request:

The following picture shows the generated CSRF PoC:

Note: Right click the intercepted Http GET or POST request and click CSRF PoC. It should not be a problem if the web application accepts POST to GET interchanges for obvious reasons.

Prevention Measures That Do NOT Work

Using a Secret Cookie:

Remember that all cookies, even the secret ones, will be submitted with every request. All authentication tokens will be submitted regardless of whether or not the end-user was tricked into submitting the request. Furthermore, session identifiers are simply used by the application container to associate the request with a specific session object. The session identifier does not verify that the end-user intended to submit the request.

Only Accepting POST Requests:

Applications can be developed to only accept POST requests for the execution of business logic. The misconception is that since the attacker cannot construct a malicious link, a CSRF attack cannot be executed. Unfortunately, this logic is incorrect. There are numerous methods in which an attacker can trick a victim into submitting a forged POST request, such as a simple form hosted in an attacker's Website with hidden values. This form can be triggered automatically by JavaScript or can be triggered by the victim who thinks the form will do something else.

Multi-Step Transactions:

Multi-Step transactions are not an adequate prevention of CSRF. As long as an attacker can predict or deduce each step of the completed transaction, then CSRF is possible.

URL Rewriting:

This might be seen as a useful CSRF prevention technique as the attacker can not guess the victim's session ID. However, the user’s credential is exposed over the URL.

CSRF countermeasures

CSRF attacks are very hard to trace and probably are not traceable unless one the two or more of the following conditions are met:

Detailed Web Application user auditing exists and is enabled.
Concurrent logins are not allowed (allowing concurrent logins would remove none repudiation).
The Web Application binds the Web Application session with the user IP (that way if the user is behind a NAT only users from the same intranet would be able to perform a CSRF attack).
AntiCSRF tokens are used per Web Application function. An AntiCSRF token in order to be effective would have to be:

Truly Random.
Bind to every Web Application function (different per Web Application function).
Behave like a session (e.g. expire after a certain time, expire e.t.c).
Use a two factor authentication per token (e.g make of a RSA token to generate the AntiCSRF to perform a transaction etc).

Other technologies for protecting against CSRF

In the web there are numerous references regarding the implementation of anti-CSRF tokens. Some examples can be found here:

Using View State to prevent CSRF attacks (example here)
OWASP CSRFGuard Project for Java
PHP CSRF Guard
.Net CSRF Guard
Anti CSRF for Joomla!

The mentality promoted by the above technologies is abvious, we should deploy a mechanism that would make unique every session initiated by the user. This can be achieved by sending the browser an anti-CSRF token that would be appended in every request the browser sends to the server. The above technique is being explained in more technical terms in OWASP's CSRF Prevention cheat sheet:

"These challenge tokens are the inserted within the HTML forms and links associated with sensitive server-side operations. When the user wishes to invoke these sensitive operations, the HTTP request should include this challenge token. It is then the responsibility of the server application to verify the existence and correctness of this token. By including a challenge token with each request, the developer has a strong control to verify that the user actually intended to submit the desired requests. Inclusion of a required security token in HTTP requests associated with sensitive business functions helps mitigate CSRF attacks as successful exploitation assumes the attacker knows the randomly generated token for the target victim's session. This is analogous to the attacker being able to guess the target victim's session identifier."

Epilogue

This blog post attempted to cover thoroughly the subject of CSRF and I believe that I managed to do that. Now there are obviously a lot more things to say about how to protect against a CSRF but for the purposes of this post is out of scope. Merry Christmas and a Happy New year.

References:

06/11/2012

The Da Vinci Cod(e) Review

Introduction

This article is going to talk about performing Web Application security code reviews the proper way (also known as my way). The best approach to perform a Web Application security code review would be to have at your disposal the Web Application (uploaded and running in a Web Server) and of course the Web Application code itself, because you would be able to verify your findings in real time (e.g. exploit an Cross Site Scripting Issue immediately after you identify the issue in the code).

But first lets define what is a security source code review. A security code review is a systematic examination of a Web Application source code that is intended to find and fix security mistakes overlooked in the initial development phase, improving both the overall security of the software. Reviews are done in various forms such as pair programming, informal walkthroughs, and formal inspections. It is often done by independent contractors or an internal security team, hiring a third independent party to perform the code review adds value because it gives to the company the chance to examine its code by a person that has been engaged in the last stage of the development process and has no "emotional attachements to the code" therefor has a unique perspective on the subject.

Types of code review

Code review practices fall into three main categories: 1) pair programming, 2) formal code review and 3) lightweight code review. Formal code review, such as a Fagan inspection, involves a careful and detailed process with multiple participants and multiple phases. Formal code reviews are the traditional method of review, in which software developers attend a series of meetings and review code line by line, usually using printed copies of the material. Formal inspections are extremely thorough and have been proven effective at finding defects in the code under review. Lightweight code review typically requires less overhead than formal code inspections, though it can be equally effective when done properly.

Lightweight reviews are often conducted as part of the normal development process:

Over-the-shoulder – One developer looks over the author's shoulder as the latter walks through the code.
Email pass-around – Source code management system emails code to reviewers automatically after checkin is made.
Pair Programming – Two authors develop code together at the same workstation, such is common in Extreme Programming.
Tool-assisted code review – Authors and reviewers use specialized tools designed for peer code review.

Important note: Tools can be used to perform this task but they always need human verification. Tools do not understand context, which is the keystone of security code review. Tools are good at assessing large amounts of code and pointing out possible issues but a person needs to verify every single result to determine if it is a real issue, if it is actually exploitable, and calculate the risk to the enterprise.

What is the most important thing in a code review

The most important is applying the proper Thread modeling. Threat modeling is an approach for analyzing the security of an application. It is a structured approach that enables you to identify, quantify, and address the security risks associated with an application. Threat modeling is not an approach to reviewing code but it does complement the security code review process. The inclusion of threat modeling in the SDLC can help to ensure that applications are being developed with security built-in from the very beginning. This, combined with the documentation produced as part of the threat modeling process, can give the reviewer a greater understanding of the system. This allows the reviewer to see where the entry points to the application are and the associated threats with each entry point. The concept of threat modeling is not new but there has been a clear mindset change in recent years.

Modern threat modeling looks at a system from a potential attacker's perspective, as opposed to a defender's view point. Microsoft have been strong advocates of the process over the past number of years. They have made threat modeling a core component of their SDLC which they claim to be one of the reasons for the increased security of their products in recent years.

There are at least three general approaches to threat modeling:

Attacker-centric

Attacker-centric threat modeling starts with an attacker, and evaluates their goals, and how they might achieve them. Attacker's motivations are often considered, for example, "The NSA wants to read this email," or "Jon wants to copy this DVD and share it with his friends." This approach usually starts from either entry points or assets.

Software-centric

Software-centric threat modeling (also called 'system-centric,' 'design-centric,' or 'architecture-centric') starts from the design of the system, and attempts to step through a model of the system, looking for types of attacks against each element of the model. This approach is used in threat modeling in Microsoft's Security Development Lifecycle.

Asset-centric

Asset-centric threat modeling involves starting from assets entrusted to a system, such as a collection of sensitive personal information.

The threat modeling

The threat modeling process can be decomposed into 3 high level steps:

Step 1: Decompose the Application:

Create use-cases to understand how the application is used.
Identifying entry points.
Identifying assets.
Identifying trust levels to external entities.

Note: This stage has to do with understanding the context of the Web Application and its surrounding entities.

The following images show the Business Architecture (Business Owner's Perspective) and Business Architecture Behavior of a Web Application:

Note: Lists the entities important to the business. Business entities can be a person, a thing or a concept that is part of or interacts with the business process (Proforma 2003). In the example of "XYZ-Match", the business entities include the following: Investors, Entrepreneurs, "XYZ-Match" web system.

Note: Lists the processes in which the business operates. In the example of "XYZ-Match", "Investor listing information to Venture Capital Directory" is one of such business processes.

Step 2: Determining and rank threats or else the threat categorization methodology:

Auditing & Logging
Authentication
Authorization
Configuration Management
Data Protection in Storage and Transit

Note: This stage has to do with mapping the vulnerabilities to a category.

Threat listing is an important part of a Web Application code auditing. Threat lists based on the STRIDE model for example are useful in the identification of threats with regards to the attacker goals. For example, if the threat scenario is attacking the login, would the attacker brute force the password to break the authentication? If the threat scenario is to try to elevate privileges to gain another user’s privileges, would the attacker try to perform forceful browsing? Categorizing and grouping the Web Application threats will help to see which Web Application security controls have the majority of the problems, it is like a blinking led that says "Hey I have multiple problems, save me please I am a poor cod dying out, save me".

Step 3: Determine countermeasures and mitigation.

Note: Such countermeasures can be identified using threat-countermeasure mapping lists.The risk mitigation strategy might involve evaluating these threats from the business impact that they pose and reducing the risk.

The objective of risk management should be to reduce the impact that the exploitation of a threat can have to the application (not to necessarily mitigate the risk!). This can be done by responding to a theat with a risk mitigation strategy. In general there are five options to mitigate threats

Do nothing: for example, hoping for the best.
Informing about the risk: for example, warning user population about the risk.
Mitigate the risk: for example, by putting countermeasures in place.
Accept the risk: for example, after evaluating the impact of the exploitation (business impact).
Transfer the risk: for example, through contractual agreements and insurance.

The decision of which strategy is most appropriate depends on the impact an exploitation of a threat can have, the likelihood of its occurrence, and the costs for transferring (i.e. costs for insurance) or avoiding (i.e. costs or losses due redesign) it.

Define the application requirements:

Identify business objectives
Identify user roles that will interact with the application
Identify the data the application will manipulate
Identify the use cases for operating on that data that the application will facilitate

Model the application architecture:

Model the components of the application
Model the service roles that the components will act under
Model any external dependencies
Model the calls from roles, to components and eventually to the data store for each use case as identified above

Identify any threats to the confidentiality, availability and integrity of the data and the application based on the data access control matrix that your application should be enforcing
Assign risk values and determine the risk responses
Determine the countermeasures to implement based on your chosen risk responses
Continually update the threat model based on the emerging security landscape.

Simple tools to use for code auditing

Graudit is a simple script and signature sets that allows you to find potential security flaws in source code using the GNU utility grep. It's comparable to other static analysis applications like RATS, SWAAT and flaw-finder while keeping the technical requirements to a minimum and being very flexible. Graudit supports scanning code written in several languages; asp, jsp, perl, php and python.

Graudit usage: graudit /path/to/scan

Graudit prerequisites: bash, grep, sed

The following picture shows a screenshot of the tool:

Note: You can download Graudit from this link. The basic concept behind this tool is to that you provide the tool with a list chunk of code lines searches for them. As an alternative of Graudit you can use common command windows tools such as findstr and find.

The findstr command line windows tools allows to search for text (as specified with pattern in the file file-name. If file-name contains wildcards (* or ?), it searches in all files that match. The option /S searches in the current directory as well as in its subdirectories. If pattern contains spaces, it must be specified like so /C:"some text to be searched". In order to turn pattern into a regular expressions, the /R option must be used. The /I option searches case insensitive. It is possible to pipe the result of another command through findstr.

For example, the following command finds all files whose name contain either an m or a p:

C:\> dir /B | findstr /R /C:"[mp]"

Note: You can find more examples for findstr in the Microsoft command line page.

Cod(e) reviewing for SQL Injection

Use Database stored procedures, but even stored procedures can be vulnerable. Use parameterized queries instead of dynamic SQL statements. Data validate all external input: Ensure that all SQL statements recognize user inputs as variables, and that statements are precompiled before the actual inputs are substituted for the variables in Java. A simplified way of thinking about SQL injection when talking about security code reviews would be to emphasize in multiple type casting checks through out the whole Web Application system. For example type casting should occur in at least two different places the Web Application input validation filter and the Web Application connected database. Additional layers of defense can be added through a Web Application Firewall (WAF) and a Database Application Firewall.

The following picture shows a sequence of yes and no flow chart explaining an SQL injection flow:

Note: This is a very simplified SQL Injection threat model.

The actual code in java that introduces the SQL Injection vulnerability originally to the code:

// Define variable to use

String DRIVER = "com.ora.jdbc.Driver";
String DataURL = "jdbc:db://localhost:5112/users";
String LOGIN = "admin";
String PASSWORD = "admin123";

Class.forName(DRIVER);

//Make connection to DB

Connection connection = DriverManager.getConnection(DataURL, LOGIN, PASSWORD);

String Username = request.getParameter("USER"); // From HTTP request
String Password = request.getParameter("PASSWORD"); // From HTTP request
int iUserID = -1;
String sLoggedUser = "";
String sel = "SELECT User_id, Username FROM USERS WHERE Username = '" +Username + "' AND Password = '" + Password + "'";

Statement selectStatement = connection.createStatement ();

ResultSet resultSet = selectStatement.executeQuery(sel);

if (resultSet.next()) {

iUserID = resultSet.getInt(1);

sLoggedUser = resultSet.getString(2);
}

PrintWriter writer = response.getWriter ();

if (iUserID >= 0) {

writer.println ("User logged in: " + sLoggedUser);

} else {

writer.println ("Access Denied!")

}

When SQL statements are dynamically created as software executes, there is an opportunity for a security breach as the input data can truncate or malform or even expand the original SQL query. Firstly, the request.getParameter retrieves the data for the SQL query directly from the HTTP request without any data validation (Min/Max length, Permitted characters, Malicious characters). This error gives rise to the ability to input SQL as the payload and alter the functionality in the statement.

Epilogue

Educating developers to write secure code is the paramount goal of a secure code review. Taking code review from this standpoint is the only way to promote and improve code quality. Part of the education process is to empower developers with the knowledge in order to write better code. This can be done by providing developers with a controlled set of rules which the developer can compare their code to. Automated tools provide this functionality, and also help reduce the overhead from a time perspective. A developer can check his/her code using a tool without much initial knowledge of the security concerns pertaining to their task at hand. Also, running a tool to assess the code is a fairly painless task once the developer becomes familiar with the tool(s).

References:

03/11/2012

Crypto for pentesters

Introduction

The purpose of this paper is to emphasize in the importance of cryptography, focus in RSA asymmetric cryptographic algorithm and explain:

What is cryptography

Why cryptography is important

History of Cryptography

Mathematical RSA operations

How to perform an RSA brute-force

What is Cryptography

Cryptography (or cryptology; from Greek κρυπτός, kryptos, "hidden, secret"; and γράφω, gráphō, "I write", or -λογία, -logia, respectively) is the practice and study of hiding information. Modern cryptography intersects the disciplines of mathematics, computer science, and engineering. Applications of cryptography include ATM cards, computer passwords, and electronic commerce. [2]

Until recently cryptography referred mostly to encryption, which is the process of converting ordinary information (plaintext) into unintelligible gibberish (i.e. cipher-text). [4] Decryption is the reverse, in other words, moving from unreadable cipher-text back to plaintext. A cipher is a pair of algorithms that create the encryption and the reversing, also called decryption. [4] The operation of an algorithmic cipher is controlled by both the algorithm and in each instance by a key. The key is a secret parameter (ideally known only to the communicants) for a specific message exchange context. [4]

In order for two parties to exchange a cryptographic message both must have one or two secret keys (it depends if the parties use an asymmetric or a symmetric algorithm) and a known mathematical cryptographic algorithm (both parties must know the details of the cryptographic algorithm) the following diagram shows the process.

Picture2: Simple encryption decryption operation (if the cryptography used is symmetric then key1=key2) [3]

Note: Secret keys are very important, as ciphers without variable size keys can be trivially broken with only the knowledge of the cipher used and are therefore not useful at all in most cases.

History of Cryptography

Before the modern era, cryptography was concerned solely with message confidentiality (i.e., encryption) — conversion of messages from a comprehensible form into an incomprehensible one and back again at the other end, rendering it unreadable by interceptors or eavesdroppers without secret knowledge (namely the key needed for decryption of that message). Encryption was used to (attempt to) ensure secrecy in communications, such as those of spies, military leaders, and diplomats. [6]

The earliest forms of secret writing required little more than local pen and paper analogy, as most people could not read. More literacy, or literate opponents, required actual cryptography. The main classical cipher types are transposition ciphers, which rearrange the order of letters in a message (e.g., 'hello world' becomes 'ehlol owrdl' in a trivially simple rearrangement scheme), and substitution ciphers, which systematically replace letters or groups of letters with other letters or groups of letters (e.g., 'fly at once' becomes 'gmz bu podf' by replacing each letter with the one following it in the Latin alphabet). [6]

Asymmetric and Symmetric Cryptography

Cryptography consists from two main categories (some people might claim more categories but for the papooses of this paper two categories cover the needs of this paper). The fist category is symmetric cryptography and the second category is asymmetric cryptography.

Symmetric Cryptography

Symmetric Cryptography uses cryptographic algorithms that use identical cryptographic keys for both decryption and encryption (this is not entirely true, but again for the purposes of this paper we accept it as a fact).The Symmetric Cryptography keys, in practice, represent a shared secret between two or more parties that can be used to maintain a private information link. [5] The following simple mathematical relationships can describe the relation between decryption and encryption in Symmetric Cryptography.

Encryption ( k , Plaintext ) = Cipher (1)

Decryption ( k , Cipher ) = Plaintext (2)

Where k a secret shared value and Plaintext the data input we want to convert into cipher. From relationships (1) and (2) we can conclude that:

Plaintext = Decryption ( k , Cipher ) = Decryption ( k , Encryption ( k , Plaintext )) (3)

Note: Among the most popular and well-respected symmetric algorithms ARE Twofish, Serpent, AES (Rijndael), Blowfish, CAST5, RC4, TDES, and IDEA.

Picture3: Symmetric cryptography [7]

Asymmetric Cryptography

Asymmetric Cryptography also known as Public key cryptography is a cryptographic category which involves the use of asymmetric cryptographic key algorithms.The asymmetric key algorithms are used to create a mathematically related key pair: a secret private key and a published public key. [6]

The following simple mathematical relationships can describe the relation between decryption and encryption in Asymmetric Cryptography.

Encryption ( k1 , Plaintext ) = Cipher (4)

Decryption ( k2 , Cipher ) = Plaintext (5)

Where k2 a secret non shared value, k1 a non secret shared value and Plaintext the data input we want to convert into cipher. From relationships (4) and (5) we can conclude that:

Plaintext = Decryption ( k2 , Cipher ) = Decryption ( k2 , Encryption ( k1 , Plaintext )) (6)

In relationship we can realize that the decryption of the Plaintext is a more complex relationship that is dependents to both keys to be used.Public key cryptography is used widely. It is the approach which is employed by most cryptosystems. It underlies such Internet standards as Transport Layer Security (TLS), PGP, and GPG.The most famous asymmetric algorithm is RSA. In cryptography, RSA (which stands for Rivest, Shamir and Adleman who first publicly described it) is an algorithm for public-key cryptography. RSA is widely used in electronic commerce, and is believed to be secure when proper secret keys are used.

Picture4: Asymmetric cryptography [7]

Asymmetric and Symmetric Cryptography revised

Unlike Symmetric Cryptography, Asymmetric Cryptography uses a different key for encryption than for decryption. I.e., a user knowing the encryption key of an asymmetric algorithm can encrypt messages, but cannot derive the decryption key and cannot decrypt messages encrypted with that key. This difference is the most obvious difference of Symmetric and Asymmetric Cryptography. Another difference of Symmetric and Asymmetric Cryptography is the mathematical properties of each type of algorithm and they way the mathematical algorithm is implemented in a hardware or software device (further explanation of these differences are out of the scope of this paper).

Why RSA is important

The RSA Cryptographic algorithm is being exploited by a company named also RSA. The company RSA is the security division of EMC (EMC acquired RSA for its security products in 2006). RSA Laboratories is the research center of RSA, The Security Division of EMC, and the security research group within the EMC Innovation Network. The group was established in 1991 at RSA Data Security, the company founded by the inventors of the RSA public-key cryptosystem. Through its applied research program and academic connections, RSA Laboratories provides state-of-the-art expertise in cryptography and data security for the benefit of RSA and EMC. [10]

Represented by the equation "c = me mod n," the RSA algorithm is widely considered the standard for encryption and the core technology that secures the vast majority of the e-business conducted on the Internet. The U.S. patent for the RSA algorithm (# 4,405,829, "Cryptographic Communications System And Method") was issued to the Massachusetts Institute of Technology (MIT) on September 20, 1983, licensed exclusively to RSA Security and expires on September 20, 2000. [9]

For nearly two decades, more than 800 companies spanning a range of global industries have turned to RSA Security as a trusted, strategic partner that can provide the proven, time-tested encryption implementations and resources designed to speed time to market. These companies, including nearly 200 so far in 2000, rely on RSA BSAFE® security software for its encryption implementation and value-added services for a broad range of B2B, B2C and wireless applications. [9]

Math’s behind RSA

The RSA algorithm involves the three following steps:

Key generation.
Encryption.
Decryption.

Note: This is a simplistic approach of RSA.

RSA Key generation

RSA includes a public key and a private key. The public key can be known to everyone and is used for encrypting messages. Messages encrypted with the public key can only be decrypted using the private key. The keys are generated the following way:

1. Choose two distinct prime numbers p and q. In mathematics, a prime number (or a prime) is a natural number that has exactly two distinct natural numbers 1 and itself. That means that a prime number can only be divided by 1 and itself: [13]

Example 1: 5/5 = 1

Example 2: 5/1 = 5

Very simplistically talking, it means that the remainder of the division of a prime number with any integer besides 1 and itself should be 0!!

Example 3: 5/2 = 2, 5 (2, 5 is not an integer)

The first fifteen prime numbers are:

Example 4: 2, 3, 5, 7, 11, 13, 17, 19, 23, 29, 31, 37, 41, 43, 47

Note: For security purposes, the integer’s p and q should be chosen uniformly at random and should be of similar bit-length. [8]

2. Compute n = pq (a), where n is used as the modulus for both the public and private keys. For the purposes of this paper we will not use long secure integers. (as soon as we have the values n and φ, the values p and q will no longer be useful to us).

Note: For the algebra to work properly, these two primes must not be equal. To make the cipher strong, these prime numbers should be large, and they should be in the form of arbitrary precision integers with a size of at least 1024 bits (bits are used when cryptography is applied in real life examples).

Example 3: (a) n = pq (b) which means that if p = 2 and q = 3 then n = 2*3 = 6 (both 2 and 3 are prime based in Example 4).

Now that we have the values n and φ, the values p and q will no longer be useful to us. However, we must ensure that nobody else will ever be able to discover these values. Destroy them, leaving no trace behind so that they cannot be used against us in the future. Otherwise, it will be very easy for an attacker to reconstruct our key pair and decipher our cipher text.

3. Compute φ(pq) = (p − 1)(q − 1) (c) or φ(n) = (p − 1)(q − 1). (φ is Euler's totient function [11], Euler's totient function is out of the scope of this paper).

4. Choose an integer e such that:

· 1 < e < φ (pq) or

· 1 < e < φ (n) or

· 1 < e < (p − 1) (q − 1) (d)

And e and φ (pq) have no common divisors other than 1. We randomly select a number e (the letter e is used because we will use this value during encryption) that is greater than 1, less than φ, and relatively prime to φ. Two numbers are said to be relatively prime if they have no prime factors in common. Note that e does not necessarily have to be prime.

The value of e is used along with the value n to represent the public key used for encryption.

· e is released as the public key exponent

5. Determine d (using modular arithmetic) which satisfies the relation:

This is often computed using the extended Euclidean algorithm [12] (Euclidean algorithm is out of the scope of this paper).

· d is kept as the private key exponent.

Note: To calculate the unique value d (to be used during decryption) that satisfies the requirement that, if d * e is divided by φ, then the remainder of the division is 1. The mathematical notation for this (as already described above) is d * e = 1(mod φ).

In mathematical jargon, we say that d is the multiplicative inverse of e modulo φ [15]. The value of d is to be kept secret. If you know the value of φ, the value of d can be easily obtained from e using a technique known as the Euclidean algorithm. If you know n (which is public), but not p or q (which have been destroyed), then the value of φ is very hard to determine. The secret value of d together with the value n represents the private key. The public key consists of the modulus n and the public (or encryption) exponent e. The private key consists of the modulus n and the private (or decryption) exponent d which must be kept secret.

RSA Encryption

RSA Cryptographic User A transmits his public key

(n, e)

to RSA Cryptographic User B and keeps his private key secret

(d, e)

. RSA Cryptographic User B then wishes to send a secret integer m to RSA Cryptographic User A. He first turns m into an integer

0 < m < n

by using an agreed-upon reversible procedure (only known to Users A and B). He then computes the cipher text

c

corresponding to: [9]

Note: And the encryption is successful. User A is the only person that can decrypt the secret integer m.

RSA Decryption

RSA Cryptographic User A can recover m from c by using her private key exponent d by the following computation:

Note: Given

m

, he can recover the original message m by using the agreed-upon reversible procedure.

RSA Encryption/Decryption Simple example

For the purposes of this paper we are going to use a very simple number example. Based on Example 4 we have to:

1. Choose q = 47 and q = 73. Based in mathematical relationship (b) is n = pq => n = 3431 also from relationship (c) we conclude that:

2. Now that we have n and φ, we should discard p and q, and destroy any trace of their existence.

3. Next, we randomly select a number e, that

e

> 1

and e is coprime [16] to 3312 (which is φ). We choose e = 425

4. Then the modular inverse of e is calculated to be the following: d = 1769

5. We now keep d private and make e and n public.

6. Assume that we have plaintext data represented by the following simple number:

Plaintext = 707

7. The encrypted data is computed by c = m^e (mod n) as follows:

Cipher text = 707^425(mod 3431) = 2142

8. The cipher text value cannot be easily reverted back to the original plaintext without knowing d (or, equivalently, knowing the values of p and q). With larger bit sizes, this task grows exponentially in difficulty. If, however, you are privy to the secret information that d = 1769, then the plaintext is easily retrieved using m = c ^d(mod n) as follows:

Plaintext = 2142^1769(mod 3431) = 707

Why RSA can’t break

The security of the RSA cryptosystem is based on two mathematical problems:

The problem of factoring large numbers

The RSA problem.

In number theory, integer factorization or prime factorization is the breaking down of a composite number into smaller non-trivial divisors, which when multiplied together equal the original integer. [17] In cryptography, the RSA problem summarizes the task of performing an RSA private-key operation given only the public key. [18] Full decryption of an RSA cipher text is thought to be infeasible on the assumption that both of these problems are hard because no efficient algorithm exists for solving them.

Appendix

C

Cryptography: Is the process of converting ordinary information (plaintext) into unintelligible gibberish.

Cipher: Is unintelligible gibberish

Coprime: In mathematics, two integers a and b are said to be coprime or relatively prime if they have no common positive factor other than 1 or, equivalently, if their greatest common divisor is 1. [16]

D

Decryption: Is the reverse process of encryption

M

Multiplicative inverse: In mathematics, a multiplicative inverse or reciprocal for a number x, denoted by ¹⁄_x or x ⁻¹, is a number which when multiplied by x yields the multiplicative identity, 1. [15]

P

Plaintext: Is ordinary readable information

Problem of factoring large numbers: In number theory, integer factorization or prime factorization is the breaking down of a composite number into smaller non-trivial divisors, which when multiplied together equal the original integer. [17]

Prime numbers: In mathematics, a prime number (or a prime) is a natural number that has exactly two distinct natural number divisors: 1 and itself. [13]