Middle East protesters deface US Army and Nato websites

On Thursday 8 Jan, Turkish cracker "Agd_Scorp" defaced the US Army website mdw.army.mil and NATO Parliament www.nato-pa.int, by putting messages in support of the Intifada and protesting against the recent Israeli attacks in Palestine that have resulted in the death of more than 800 of Palestinians so far.

Zone-h has screenshots taken after the defacements here and here.


From what we can read on zone-h.org, Windows 2003 was the Operating System of the server hosting the domains, while the attacker exploited some Sql Injection flaws (on the ASP application powering the websites) for the break-in.

Two days after the incident, mdw.army.mil seems inaccessible, as you can see on the screenshot. 

It is interesting what we read on securityfocus for the story. "Last week, several sources reported that thousands of Web sites may have been defaced by Palestinian sympathizers. Still, this is nothing on the scale of Georgia or even more recently with the (online) attacks on Kasparov"

 

 

army.mil down

 

Domain hijacking and other malicious activities with Gmail

 google logo

A few months ago I read on Gnucitizen about the Gmail CSRF and that was what I think one of the first really big cases of a CSRF attack that became publicly known. Although Google has fixed this issue, it seems there's a new bug somehow similar to that one, and there's some great coverage on the issue at readwriteweb

The story behind this, amongst others contains the story of shocked site owners, getting their domain names hijacked by a malicious group, that asks for a fee (a few 00's dollars) in order to give them their domains back! Nasty.

CSRF is a so called 'Web 2.0 vulnerability', without this meaning that CSRF attacks didn't take place a few years ago. It is an emerging threat, not as well known and understood at the moment, as the different sorts of Injections, like SQL Injection, or Cross Site Scripting, still it is getting a lot of publicity as we hear more and more about high profile incidents .

I'm not going to dive deep into CSRF attacks, as the Wikipedia article explains very well the whole thing. In a few words, "It is a type of malicious exploit of a website whereby unauthorized commands are transmitted from a user that the website trusts." This attack class exploits the trust a site has for a particular user. Since the user is authenticated, any command issued during his sessions is supposed to be valid. So the problem is on the server side, still the user has a problem if a site is vulnerable to CSRF!

The story with Gmail and CSRF goes like this:

a) while logged on to Gmail, a person who owns a domain name and it's contact details are associated to this email address, visits a site that contains malicious code against Gmail

b) since the Gmail user is logged on Gmail, and Gmail is vulnerable to CSRF, the malicious code is executed, that adds a filter on the user's account. Gmail filters are rules to be executed, say for example that each email should be forwarded to address xxx@yyy.com. In this case, a filter is set to forward emails on the malicious guy's email address

c) since paying a close look every now and then on what are your filters isn't very usual (at least for most users, now), it is unlike that the user will notice the difference.

d) during this time, the malicious person collects the user's emails and monitors sensitive information being sent.
He can also use the password reset utilities on the domain registrant, change the password and hijack the domain.

adding filters to gmail

 adding filters to Gmail (Settings->Filters->Create a filter)

 available filters on Gmail (plus malicious ones)

filters of a domain hijack victim, with added filters (image from readwriteweb.com)


Take a moment and think the damage if your email account is compromised. This might result in a far greater loss than physical disasters, eg your hard drive crashing! Not in the case you are a plain user, exchanging mesages with friends and partners, but if your email account is the gateway for online banking systems, paypal, or other systems, or for a domain registrar, as in the scenario we are discussing.

What you can do about that

Google has fixed this vulnerability, however it's good to keep in mind some small things, cause similar scenarios might appear in future.

1) If you use Gmail, check your filters and make sure there's no filters added by others (Settings->Filters)

2) Change your reset passwords/answers. Seriously. Don't allow yourself to get owned because someone reset your password by answering the question 'What's your favorite puppy'.  (this also aplies to ALL web based email, like yahoo, hotmail etc).

3) While logged on Gmail, don't visit malicious/questionable sites.

4) Use https://mail.google.com instead of http://mail.google.com (notice the s). Thus all of your session is encrypted (HTTPS), rather than only when you login as it happens with HTTP.

 What's really important to remember is in CSRF, or XSS, or other types of attacks, we tend to underestimate the number of web sites/applications that are vulnerable. Also, as users we can't do many things to avoid these attacks (since they are server side), just be informed and suspicious :)

If this sounds interesting to you, check out geekcondition, featuring some great coverage on the issue.

Gnucitizen (what an awesome name!) is an IT security Think Tank, having produced amazing papers and coverage for many issues in the field of IT security. Moreover, the policy they've been following for publicizing vulnerabilities seems very responsive (they even prompt others to inform the vendor for a problem, let the vendor fix it and then publicize it, rather than just publicize it once discovered).

 

Fuzzing: Finding vulnerabilities in Software

Fuzzing is a well known term amongst security people, because of the buzz created around last few years and the impressive results it has given.

According to the Wikipedia articleFuzzing is a technique for testing software, by providing random data as input and monitoring if the program will fail -by crashing or consuming high system resources. If this happens, this means there are defects to correct.

As it is quoted on the wikipedia entry, Unexpected input causes unexpected results. In fuzzing, you are somehow creating 'rough clients', that send input a normal client wouldn't.

 



[Read More]