Saturday, April 21, 2012

Error Menace - Follow Up

Remember my last post about information disclosed from error messages?

Not long after I posted that (~1 week),  I was on vacation, and during my traveling I came across two examples of error messages disclosing too much.

Here they are:

#1 - Delta Airlines Touch Screen

I apologize for the blurriness of this photo.  I took this with my cell phone as it was scrolling through the boot up process.  This happened when one of the games I was playing crashed.  I was really surprised to be given this much information about the device.  I could see hardware addresses, running OS and vers, and other information that you can try to view from that picture.  A simple loading screen would've been much better and not disclosed anything.

#2 - Government Website Information Disclosure

I was searching around for things to do in the area and landed upon a Government Website.  Just by clicking on a link, I came across this error.  Some of the information has been redacted, but you still will get a good idea of what's going on.  Some information I found:

  • Hints about the running Operating System (Windows)
  • The type and version of the Web Server (Apache)
  • UNC path that discloses shared directories
  • Several function calls 
  • OS directories
If you find anything I've missed, feel free to comment or contact me, and I'll add it here.

Note: I contacted the Website Admin shortly after arriving home, and received a quick response saying they fixed it.  

Wednesday, April 4, 2012

The Basics - Part 1 - The Error Menace

While I think Website Penetration Testers will always be needed, I think there are some basic security measures that Web Developers can take to secure their sites.  These measures don’t guarantee your site is 100% secure (then again nothing does), but they may deter hackers from spending time on your site.

Think of a robber who wanders around a neighborhood looking for houses to break in.  Can they try to disable your alarm? Sure! Can they climb that tree, get access to your roof, and go in through a bedroom window? Sure! Those methods, however, also take time and some work.  The easiest target would be one whose downstairs door is unlocked. 

Now think of your website as a home.  Have you taken basic precautions to prevent users from breaking in?  When your customers ask, are you able to tell them that you integrate security measures into your development methods to block out the “low hanging fruit” so to speak?
In Part 1 of this series, let’s take a look at one of the easy things you can do to help protect yourself…..

#1 - Error Handling:

Attackers can glean very valuable information just by trying to break your site.  What types of information you might ask?  Well as a Developer, think of the types of exceptions you’ve seen.  Those exceptions give you insight into what happened in the application.  It may point to what broke.   It helps you to go to the source of the problem and fix it.  What if an attacker finds it first though? What information could they get?


DATABASE ERROR: Duplicate entry ‘0-2’ for key PRIMARY
INSERT INTO ‘ot_term_relationships’ (‘term_taxonomy_id’, ‘object_id’) VALUES (‘2’, ‘0’)

This code was returned as part of a more recent Wordpress exploit.  Take a look at the error message.  As an attacker, this tells me a lot.  Let’s take a look at what we know even if you think it’s obvious:
  •     I know there is a database
  •     I know that database is online
  •     I know there is table named ‘ot_term_relationships’
  •     I know that table has at least two columns called ‘term_taxonomy_id’ and ‘object_id’
  •     I know they both accept numbers
  •     I know there is already a record with a value of 2 in the ‘term_taxonomy_id’ and  a 0 in ‘object_id’

I was able to get this all because of an error message.  Now I know a little more about your site and how’s it organized.

 Example #2 – Login Page:

What just happened there?  Did you notice the difference in error handling?  In the first case I typed in both an invalid username and invalid password.  As an attacker, I try to create a baseline.  I’ll type in something I’m almost sure won’t exist to see what the application does and what it gives me.  In the first case, the application did what it should have.  The error didn’t tell me what was invalid only that the complete package of the username and password didn’t work.

Now it’s time to get serious.  Most applications have some type of root/admin account.  Look what happened when I typed in the admin account.  I got an error telling me I have an invalid password.  Now I can infer that the account is valid, and I just need the right password.  Now I can start enumerating this form looking for valid users because I know what the response should be.

Take a look at your login page and error handling.  Does it give away too much? Don’t just look at the code returned, but look at the URI as well.

See you next time for part 2…

UPDATE: Check out the follow up article showing examples of error disclosures including a Government Site I came across. Link