“We’ve never been hacked.” Those words are generally what let IT people sleep at night (or take long breaks to go play Guitar Hero). While it gives everyone a nice warm, fuzzy feeling like a lolcat, how would you know that it is true? Cause you haven’t had a customer complain about a strange transaction? Cause the data in your database looks fine? Cause your web server hasn’t crashed recently? Often, it’s because of a strong belief that logs will tell you everything and you don’t see anything crazy in there.

While most companies do spend some time and money on log analysis, a number of web attacks can go completely undetected given common logging architectures and configurations. A very simple example of this would be POST parameters. You can check all the boxes for the IIS logging configuration, but there’s still no way to enable logging of POST parameters without some custom programming. Not logging POST parameters makes sense as they are most often used to send usernames and passwords (something you wouldn’t want sitting as plaintext in your logs); but then any SQl injection attempts to bypass login go undetected. So, some programmers take it upon themselves to add additional logging in the application itself. Items such as writing out when someone logs in, or what data they are viewing or entering. While this is recommended and can often be helpful, it can also lead to a false sense of security. Most often a vulnerability in an application occurs at a point where the developer was unaware of a security risk. Therefore, developers commonly miss logging data at the correct spots, logging the correct parameters, that are used in an attack. In a number of cases, there is often no validation or encoding of data written to these custom logs. Thus it’s rather easy for an attacker to forge entries into the logs or truncate data by appending null characters in their attacks.

Even if you do log everything properly, some attacks don’t have signatures that would stand out. Parameter manipulation attacks often take advantage of subtle changes to the information sent to the webserver.  Changing one account number to another valid account number. Flipping a zero to a one to get admin access. These attacks are going look like normal request to anyone reviewing the logs unless you already know some information about an attack that has occurred.

We have also seen a number of attacks against weak encryption that can go unnoticed for a huge amount of time. This should be painfully obvious now in the wireless world after the TJX attacks. Consider your own wireless network for a moment. Even if you are logging MAC addresses for every connection, how do you know someone is not passively capturing your traffic and decrypting it? Or has sniffed a legitimate user’s MAC address and is impersonating it?

In the web application world, we have seen weak homegrown session “encryption” for persistent logins. This didn’t take millions of sessions ids to crack, but rather just a handful any normal user would be issued. Think you would detect it based on IP addresses in your logs? Fairly unlikely, because your logs probably aren’t saving the session ids. If they are, the number of false positives is so high based on legitimate mobile users, that its often impossible to use that information to realize it’s an attack. Your IPS/IDS often will miss this attack as well since there’s nothing out of the ordinary in the requests or paths through the site.

How about Session Riding attacks? In these cases, we have a legitimately logged in user, coming from their normal IP address and standard web browser. If the attacker has done a proper job, a single Session Riding attack entry in a log file will look exactly like legitimate traffic. You would need to analyze the user’s path through the site to realize something was out of order. Again, in most cases, companies to not have the tools or resources to do this.

So before the next board meeting when someone announces “we’ve never been hacked”, take a few minutes to think about if there’s anyway you could know that is true. In most cases, there should be reasonable doubt to know the jury is out on that myth.

-b3nn

Till a couple of years ago, the input validation wand could be waved to solve almost any application security flaw - XSS, SQL Injection, Response Splitting, and the list goes on. That made it easy to become an application security consultant. If you could chant the “Input Validation” mantra you would be right most of the time. The advent of attacks like cross-site request forgery (which I prefer to call session riding) and session fixation, however, have made it difficult to pull off the input validation bluff.

Let’s talk about Cross Site Request Forgeries (XSRF) for starters. Corey Benninger explained the difference between the often confused XSS and XSRF in a previous blog post. The root cause of XSRF is the predicability of key HTTP requests that result in transactions with signifcant impacts.

E.g. If the HTTP request for transfering funds from one account to another is - http://www.hellobank.com/transfer.aspx?amt=1000&srcacct=1001829&srcaba=021000091&dstacct=9008990&dstaba=012000076

an attacker can lure a victim to visiting a web page, that in the “background” executes such a request to transfer funds from the victim’s bank account to that of the attackers. If the victim is logged in to his/her online bank then this transaction will execute successfully. The systemic issue is the predicability of the HTTP request. The way to thwart such an attack is to introduce a random element in every request to transfer funds, and more importantly verify that the random token has not been tampered with.

Now on to session fixation. The potential impact of exploitation of this vulnerability is often underestimated; for those that feel that this is a “Medium” or “Low” risk issue check out my BlackHat 2006 presentation. The fix for this issue is real simple - invalidate and re-issue user sessions after critical events like login, and  switching from non-SSL to SSL on the website. It’s not input validation though.

I started thinking about this post while teaching my class at Carnegie Mellon University. One of the students came up to me after the web hacking class and asked me “What is the ONE thing I should take away from this session”. I said -  ”If it had to be ONE thing for application security it would still be Input Validation, but hopefully you didn’t just learn ONE thing” 

Here at Intrepidus Group, we do a lot of mobile application security reviews.  Much like standard web application reviews, some clients consistently turn out very secure apps.  However some apps have a detailed finding list longer then a copy of War and Peace.  One trend can often be seen across applications regardless of the client’s understanding of security.  Mobile applications, at some point of their process, typically rely only on a phone number and short numeric pin for authentication to a remote server.

We’ve all know that weak passwords are one of the easiest way on to a system. If you let users have the option of choosing a secure or weak password, they will often take the easier to remember, less secure choice.  I would say most major web based applications now require users to choose passwords with at least 6 characters, using mixed case and at least one number or special character.  Typing in complex passwords with your standard QWERTY keyboard isn’t such a problem, but can you imagine trying to multi-tap some of your complex passwords on a 0-9 keypad? And into a stared out password field? It’s somewhat understandable that most mobile apps only require a numeric pin for authentication.

The problem of course is that most of these server side components can’t be limited to only allowing access from mobile devices (break out your old school User-Agent hacks and give some “.mobi” addresses a try). Limiting access to restricted IP address pools usually don’t help either and typically is a nightmare if client is supporting multiple providers. So in almost all cases, you have to assume an attacker can easily script a brute force attack against some part of the authentication (with mobile apps, it’s typically not just the front door login, but also a web service burried somewhere in the site that will handle authentication).

What’s a mobile vendor to do? CAPTCHAs, you say? Some of these are barely readable on a 22″ monitor. Good luck figuring out that text on your 1.5″ Nokia screen.

Account lockouts seem to be a reasonable recommendations at this point. But even with a low number of attempts (lets say 3 just for fun), I bet I could script something to get into at least 25% of your user base. What are these magic pin numbers?

1234, 5555, 1111

Yup, that’s some 13373 H@x0r shiznit right there. And if I have more login attempts, lets try the last four digits of the mobile number as the pin. Oh, that mega-hurtz now!!! For the sake of security, we need something stronger than an all numeric pin. Maybe it’s in the form of one time token over SMS, or maybe just a decent password multi-tap box for now (I saw this well done on the Blackberry Pearl recently). If you know of any other good solutions to this issue, drop us a line. I’ll be talking about this and more mobile security issues next week at the NJ/NY OWASP meeting.

-b3nn

If you’ve been noticing a little silence on the blog recently, it’s been because a lot of the ranting has been going into developing what we think is a great anti-phishing user awareness tool. Take a peek at our main site at www.PhishMe.com

Conducting ethical phishing attacks has never been easier. User awareness will be improved, enforced, and for the first time for many users, easy to measure and trend over time. You can sign up for the mailing list right now that will let you know when the full blown service is launched. We will be offering free trial accounts that will allow you to get a taste of the features and test out if a few of your users will bite.

Another key feature of PhishMe is the built in templates to make your job of crafting phishing attacks simple yet effective and modern. How do you think your employees would respond to a message about a “virus outbreak”. Will they just follow the instruction in an email without verifying any of the information? What about a message to update their HealthCare information on a new third party site? The number of people that fall victim to these types of attacks will make you wonder why hackers even bother with anything that isn’t social engineering.

There is more to come in the future but for now, check out www.PhishMe.com

-b3nn