Threat Level: green Handler on Duty: Bojan Zdrnja

SANS ISC: InfoSec Handlers Diary Blog - Internet Storm Center Diary 2008-12-01 InfoSec Handlers Diary Blog


Sign Up for Free!   Forgot Password?
Log In or Sign Up for Free!

Call for volunteers - Web Honeypot Project

Published: 2008-12-01
Last Updated: 2008-12-04 11:41:23 UTC
by Jason Lam (Version: 1)
0 comment(s)

At SANS Internet Storm Center, we are always researching and monitoring the latest trends of attacks on the Internet. We are currently developing a web honeypot project similar to the Dshield model. The launch time is a few months away and the project is in need of volunteer researchers to help get thru the beta phase.

Here are the technical skillsets we need

  • PHP coding
  • SQL
  • Apache
  • Understanding of HTTP
  • IIS
  • Technical writing (documentation)
  • Experience with various Opensource web applications

We expect each volunteer to put in about 70 total hours in the next 3 months. Each volunteer should have at least 3-4 skills from the above list to be effective in the project. If you think you can contribute to this project, please send us an Email at isc@sans.org with "Web Honeypot volunteer" as subject line. Please include one short paragraph about your background and skillset.

UPDATE - Dec 4th: Thanks for all the volunteers who signed up. We have enough volunteers to get this project going for the moment. It is likely that we will recruit more volunteers in a few months. Stay tuned if you are interested.

0 comment(s)

Tips on Responding to DDoS Incidents (Updated)

Published: 2008-12-01
Last Updated: 2008-12-02 14:20:44 UTC
by Lenny Zeltser (Version: 5)
0 comment(s)

The incident handling cheat sheets in an earlier diary applied to many types of security incidents. Some situations, such as distributed denial-of-service (DDoS) attacks, benefit from specialized guidelines. After soliciting tips from our readers and fellow ISC handlers, I compiled the following cheat sheet to help organizations during a DDoS attack.

The cheat sheet captures advice for battling a network DDoS attack on your infrastructure. The link points to the HTML version of the cheat sheet. That page includes the printable 1-page PDF version, and the Word version of the file you can customize for your needs.

DDoS Incident Cheat Sheet Preview


What do you think? Any corrections or additions? Pointers to useful resources? Let us know.

Thanks for the insights to our readers and ISC handlers, including: Daniel Fairchild, Chris Lemieux, Peter McLaughlin, Jose Nazario, Donald Smith, and Jim Tuttle.

Additional feedback from our readers:

Adam Jarvela wrote: "From the datacenter perspective it's important to identify the specific destination of the attack... .  I'm a fan of the old method of starting at the core and following the traffic to the aggregate and eventually to the distributor.  From the distributor it's usually pretty easy to identify the destination of the attack..." "Recently, we had a very odd attack on ip protocol 255. Not the first time we've seen this, but by being able to identify the specific attack you can create an attack specific filter instead of blackholing the entire server/IP/subnet..."

Andrew wrote a shell script that, when ran on the DDoS'ed Linux web server "would terminate connections exceeding a set value (10 in this example) from the same source IP. Although not ideal, however does hopefully prevent the web server from falling over (exceeding sockets thresholds) whilst one is assessing the DDoS situation." Here's Andrew's script:

#!/bin/sh
PATH=$PATH

while true; do
sleep 60

UNIQ=`netstat -tpn | grep -i established | awk '{print $5}' | cut -d':' -f1 | uniq`

for IP in $UNIQ; do
WC=`netstat -tpn | grep $IP | wc -l`
if [ ${WC} -gt "10" ]; then
PID=`netstat -tpn | grep $IP | awk '{print $7}' | cut -d'/' -f1 | sort -n`
KILL=`echo $PID | cut -d' ' -f10-`
kill -s 9 $KILL
logger -sp daemon.notice -t Web_Server "Established threshhold exceeded for IP ${IP} and PID ${KILL}"
fi
done
done

 

-- Lenny

Lenny Zeltser
Security Consulting - SAVVIS, Inc.

Lenny teaches a SANS course on analyzing malware.

Keywords:
0 comment(s)

Input filtering and escaping in SQL injection mitigation

Published: 2008-12-01
Last Updated: 2008-12-01 15:24:56 UTC
by Jason Lam (Version: 1)
0 comment(s)

While teaching the defensive web app security classes with SANS, I often hear "I have been filtering/escaping quote character for years to prevent SQL injection, it had worked flawlessly." That's one of the common statement I get when I sell the idea of parameterized queries. We know by now that filtering single quote does not prevent all SQL injection, but how big is the risk?

I have been doing some SQL injection research with the fine folks from Security Compass on MS SQL server. Depending on your setup, you might be more vulnerable than you think. What characters do people normally filter or escape for preventing SQL injection?  Maybe quote and semi-colon?  Bad news, depending on your setup, you maybe very vulnerable even after filtering those characters.

Semicolon Not needed

Let's get some background information first. MS SQL server support query piggybacking by default, so you can execute multiple SQL statements in one single communication with the SQL server. While it is widely believed that you need a semi-colon between different logical statement while piggybacking, it is really not necessary.

Here is an example,

select * from product; select * from employee

But actually, the following version without semi-colon works too

select * from product  select * from employee

Or  even this

select 1 select 2

No semi-colon is required to delimit each statement. With Microsoft documentation, I have found that up to MS SQL 2008, semi-colon is not necessary but this will change in future version of MS SQL server

So, filtering semi-colon may not provide the protection you wanted.

Quote Not needed

Now, what about quote? This one is easy and is well publicized by other researchers such as "Advanced SQL Injection" paper by Chris Anley (back in 2002).

You simply do not need quote to SQL inject a numeric type of input, because quotes are not used for numeric type in SQL statement.

Let's look at an example of a textbook SQL injection vulnerability, assuming qty is a numeric type in the database

select * from product where qty = <USER INPUT>

An attacker can simply put in 1 or 1 = 1 and return all data. Quotes needed? Nope.

To leverage both techniques mentioned about, what an attacker might be able to do is

select * from product where qty = 1 shutdown

An instant DoS attack with the DB server shutdown, if the web app user is running as "sa".

select * from product where qty = 1 delete from product where qty = 1

Did I use quote? No....  Did I use semi-colon? No...

For some of the advanced reader, you must be saying, "Hey! There are tons more evil attacks possible with this" Sure, but ISC isn't trying to teach you how to hack (SANS has 538 and 542 on how to pentest web apps). The basics that everyone need to understand is - if you can run a full SQL statement, the possible damage is a lot higher. An attacker does not always need quote and semi-colon to run a separate SQL statement.

Now, the best fix for SQL injection is still parameterizing your SQL queries. If you still want to filter SQL characters or keyword, that's up to you, but remember that there's a good chance you will get hacked.
 

------------------------------------------
Jason Lam, author of SANS web app courses - 319, 422, 538

Keywords: SQL injection
0 comment(s)
Diary Archives