Following the White Rabbit Blog : hacking

Web Application Security - Vital in Academia

RafalLos — Tue, 20 Jan 2009 03:05:00 GMT

"Police: School data hacked, grades altered"

http://www.republicanherald.com/articles/2009/01/15/news/local_news/pr_republican.20090115.a.pg1.pr15hacker_s1.2230498_top4.txt

Every once in a while, we get a great example of why web application security is vital no matter where in the world you operate. Even though academia often feels like they are the exception due to lack of funding, chaotic environments and a cornucopia of other reasons we occasionally read a news nugget that proves they are just as needy as the rest of the business world of good web application security.

An article in the Pottsville, PA Republican Herald, posted last Thursday January 15th, 2009 identified an incident that caused a bit of a ruckus.

"Pottsville police anticipate filing charges against one or more computer hackers who unlawfully made changes to an online grading system used by Pottsville Area School District.

“You had some people who hacked into a school-functioned, online site and found ways to change data that was put in there,” Pottsville police Capt. Ronald J. Moser said Wednesday

“In this case, someone figured out a teacher’s login and password. It is still a federal offense,” said Monica Langenberg, Shawnee, Okla., director of business development for Classroll.com."

There are several things we can gleam just from that critical quote... let's address:

First, this incident highlights the dangers of having publicly accessible grading systems and school-tied information available on the public Internet. Perhaps the school system should evaluate the sanity of having such critical information for its students protected by a simple username/password system available to the whole of the Internet?
Unless I misunderstand the content of this article... no one "hacked into" anything... the students simply guessed the login credentials of a teacher, who, coincidentally should be held accountable as well for having easily guessable credentials to such a system
A "federal offense"? That's fascinating...
The student demonstrated lack of malicious intent in my view, simply by making the types of changes that would get them caught... it very well could have been done silently over time to really cause some damage

What does this teach you, if you've in academia and evaluating or building an online system like this? Secure it. Base-level login/password authentication from 1999 isn't going to work... Also because of COPPA (Child Online Privacy Protection Act) there is some much greater accountability for academic environments when it comes to protecting children and their information.

Hacking: Next Up Movie Theaters

RafalLos — Thu, 18 Dec 2008 08:25:00 GMT

Reference: http://breachblog.com/2008/12/16/zyacorp.aspx

In one of those "I bet they didn't see this coming" moments a CineMagic movie theater in Merrimack, NH has fallen victim to digital thieves (or hackers, if you prefer). What I see here is a rather obvious comparison case for tackling the "we're too insignificant to be hacked" argument. If you have data or click-stream... you have something of value.

I've said it before and I'll say it again - hackers aren't just targeting the huge repositories of information. They're coming after anyone and everyone with exposures and unmitigated risks. While there is direct indication that this was done with a web application hack... I wouldn't discount it as an avenue for easy attack.

Think of how many times you've bought movie tickets online or anything else that you wouldn't think twice about... what if that entity was compromised?

In what I can only call an unfunny twist of comedy, the article's writer comments -

"Anytime I read about credit card breaches, PCI compliance comes to mind. If I were to guess, I would guess that there is a 50/50 chance that Zyacorp is compliant. Not that compliance = secure."

Web Application Security 101: Simple SQL Injection

RafalLos — Sat, 04 Oct 2008 05:08:00 GMT

Web application security is a hot topic, no doubting that these days. The awareness is growing and developers are starting to take notice of the security shortfalls in their code. Awareness of attacks like SQL injection, cross-site scripting, and CSRF (Cross-Site Request Forgery) is starting to spread and so are ways to protect against these types of attacks.

With this Security 101 post I'd like to call attention to a particular type of attack that (after nearly 5 years of executing it successfully) is finally starting to trend towards extinction - but sadly still is all-too-common. Let's do this by example...

As you visit your favorite site one of the first thing that the server on the other end of your connection does is checks your browser. It does this for an obvious reason: it needs to know whether to serve you java or ActiveX/.Net -based content. This isn't going to go away since I don't see either Microsoft or Mozilla dropping out of the browser game, so the checking of "user-agent" will continue. Moving on in our example, the server pulls the "user-Agent" header component and has to compare it against known types of browsers. Now, there are a number of ways that the server can check your browser version (against an XML file, using JavaScript from within the page, or using a database call) but it is fairly likely that it will be done with a database call to the back-end database server against a table of supported browsers. Here's where the magic happens if you're an attacker. Most of the time, if the developer is making a database call to check browser version compatibility they are *not* sanitizing that parameter before passing it into the database server. This, of course, leads to SQL Injection.

This absolutely fundamental check can cause a site or application with *zero form inputs* to still be vulnerable to SQL Injection. I've seen it first-hand, so I know it exists in "the wild". Absolutely fascinating since I've had developers ask me why they need to sanitize parameters when they have little (or no) form inputs on a site. My answer is always this example.

The moral of this story is don't get over-confident. Just because your site/application is 'basic' or short of complex inputs it does not necessarily mean that you're invulnerable to attacks like SQL Injection. Check and sanitize all your parameters coming from the user-side. Never, ever, under any circumstances trust data coming from the client. This goes for *any* data, including header fields!

What's the point of "penetration testing"?

Rafal Los — Fri, 04 Apr 2008 14:45:00 GMT

Over the last 8 years in IT Security, I've had at least a professional interest in the idea of penetration testing and the opinion of this service has evolved as the IT Security market niche matures and grows. I wanted to take a minute to discuss it with the readers out there, and maybe solicit some opinions on the topic if you're willing to offer yours. I'll reserve my personal opinion for the end, but wanted to present some thoughts, rebuttals and commentary on these here. I'm going to address penetration testing in the context of web applications - but this can be allied virtually to any technology out there.

Let's first look at the arguments for penetration testing:

Penetration testing provies a hackers-eye view of your web application attack surface
Penetration testing provides an outsider's view of your web application attack surface
Penetration testers will often find ways to manipulate your applications in ways your developers never thought possible
Penetration testing offers the client an opportunity to get a snapshot picture of your security posture
A penetration test goes more in-depth than a "security scan" by identifying and exploiting real weaknesses

Those are some compelling points, to be sure. Security is a very strange f1sh, it changes so drastically so often it's almost impossible to be entirely up-to-date all the time, unless that is your sole job. This is precisely what penetration testers are great at - they focus their entire energy on researching, identifying, and exploiting security weaknesses in, in this example, web applications. There really isn't any amount of "scanning" that an automated tool can do which will match the power and adaptive capability of the human mind - I don't think anyone will argue that - so the value of employing someone who is extremely versed in this sort of thing is akin to having your transmission looked at by a transmission-only specialist... you do it because you want to go to the expert. There are varying degrees of expertise; of course, and let's not even try and disagree that you get what you pay for. If you want a top-notch security expert, you're likely going to be hiring someone with a shady past, and it's going to cost a lot - but at least you know you're getting the top talent matching wits with your pro-active security measures. But what about the other side of the coin?

Let's look at arguments against penetration testing:

Penetration testing can be argued to be a test of the 'tester' not the target
Penetration testing isn't an exact science, and rarely standardized
Penetration testing results are inconsistent
Penetration testing is too expensive
Penetration testing is only a snapshot in time

With those arguments against penetration testing - how can one reasonably conclude it's a good idea? Well, the fact of the matter is that penetration testing is expensive, inconsistent and rarely an exact, standardized process (unless you pick one of the top firms which have standardized). Yes, sometimes the results are inconsistent and a mere snapshot in time, not an accurate assessment of your stategy as a whole. The argument has also been made that a penetration test result is often a test of the "tester's" intelligence and hacking prowess, and not necessarily of the defenses... however I would say think twice about that argument. Isn't that the point? You hire the best, they put their mind to the test against your defenses? So now the pros are weighed against the cons... and the money issue is always on the forefront of the decision to go one way or the other. I will only offer you these words...Strike a balance in your strategy - but do not fail to test yourself.

Remember, the right balance when it comes to penetration testing is in moderation. You can't reasonably have a penetration test done once a week, as it would destroy your budget. You also shouldn't do it once a year - as that's probably too rare. The right balance is a combination of automated tools which you and your security team can use to self-assess plus a seasoned expert tester to check your sanity and environment. Heed my warning... find your vulnerabilities because if you're not testing the security of your web applications - rest-assured someone else is.