1.  It's certainly not bad -- at a minimum, it will give you an idea of the modules that are covered on the test and the depth to which they are tested.

2.  Honestly, I think you'd get more out of independent research on topics that you're not familiar with.   Use the book that you have to identify areas that you're not entirely comfortable and then find good references on those areas.

3.  The exam is (similar to many others) a random selection of 150 questions from an increasingly large pool of available questions.   This means you may get an easier draw or you may get a brutal draw.   Further compounding things is that the answers are handled the same way:  randomly drawn from a pool of available answers.   This was originally done to randomize the order of the answers on your question (so you couldn't just memorize "B" for the answer).   Over time, as the pool of available answers on any given question grew, you started to run into the situation where the "correct" answer may not be randomly selected -- i.e. you may not be able to get the question right.

The CEH is a good test in that it tests for technical knowledge that is required to get started hacking/pen-testing.   It does a good job of eliminating false-positives (you generally won't pass it unless you have at least some knowledge of the materials)....not so good at eliminating false negatives.   Like anything else, it simply means that you have the requisite knowledge to get started -- not that you're a hacker.  Like a college degree, it's a tool to open doors and create opportunities that may not otherwise be available to you.

4.  After you have the C|EH, you can test for the ECSA -- it's a cakewalk in comparison.

One thing to keep in mind on the C|EH is the nature of the exam:  it's  a random draw of questions from an increasingly large pool.

In the exams that I've proctored, I've seen some very bright guys get a rough draw of questions and have a hard time with the exam.   I've also seen some "not so bright" guys (to put it lightly) get an easy draw on questions and coast right on through.

In the last round of proctoring, one guy failed the exam and decided to re-sit it immediately (it's a 4 hour exam).   He passed on the second try, saying that the questions he got on the second round were a LOT easier than the first.

It's all about the draw.

I tend to think of it as: the exam does a decent job of eliminating false positives (you need to know the subject matter to pass)....not so good at eliminating false negatives.

Note:  I'm somewhat biased in this answer

I think that a cert is just a means to opening up doors that may otherwise be closed to you.  Same as a college degree -- they don't mean that you are an expert in the field, but they're at least an indication that you have the knowledge and capability to learn.  A C|EH doesn't mean you're a hacker....but it is an indication that you can learn the skills needed and gain the experience.

I've found the C|EH to be one of the more technical certs out there for hacking (more decidedly in the "gray" range than others).   For a beginner, it's very tough....one of the harder exams some of the rookies at my office have had to take.   For someone with experience, it's really not so bad (as you surmised).   To me, that's a sign of a good test in that it means the test checks for knowledge that you actually apply.

There's a number of things that I don't like about the exam, but the good outweigh the bad for me.

What encryption are you running?  WEP?  WPA?  WPA2?

If WEP, you can do WEP cracking pretty easily.  I normally recommend aircrack-ng suite of  tools (included in Backtrack3), but there's a large number of options out there for you.

If WPA, you're looking at more of a dictionary or brute-force attack on the password.   Tends to take a bit longer, depending on the password strength.

Well...I can see a couple of reasons:

1.  You (by and large) make more money on the legit side of the fence.   The VAST majority of the black hat and script kiddie market is working for rates that we wouldn't even bother laughing at.

2.  You don't have to worry about spending 6 months in jail while you await trial and hope for a lenient judge.

Both of those are pretty big reasons for me, personally....#2 more than #1, but still....

The privileged account is what allows you to get at xp_cmdshell (eventually), which is what gives you the ability to expand your influence from the database to the server itself (and then the world).   I see that often.  Normally just laziness on the part of the developer, I guess....or lack of knowledge.

That's part of the hack.   Other parts are bypassing the developer's "protection" -- padding single quotes (which I see often), removing whitespace (which I see VERY often in older apps).  And, of course, bypassing the application firewall, which just takes a little ingenuity to write SQL that doesn't look like SQL to the firewall (and is therefore allowed).

To expand a little on the stored proc comment above, if the developer is using bind variables in his code (the recommended practice), then there is no possibility for SQL Injection.   This statement holds whether or not he is calling a stored proc or a simple SELECT statement.   If the developer is not using bind variables and is inserting user input directly into the SQL statement being executed, then the use of stored procs does not protect you from SQL injection -- all it does is forces the injection to go (mostly) into batch queries.  Consider the following:

SELECT * FROM users WHERE username = '$user$' AND password = '$pass$'

sp_login('$user$', '$pass$')

in the first statement, you have full control.   Inject into $user$ and you can change the statement to:

SELECT * FROM users WHERE username = 'foo' OR 'a' = 'a' -- AND password = 'bar'

Injected value:  $user$ = "foo' OR 'a' = 'a' --"

Or really anything else that you want....including batch statements.

In the second statement, you can't inject into the parameter itself, you have to close out the stored proc call in order to get valid SQL, so injecting into $user$ becomes:

sp_login('foo', null); exec xp_somethingbad 'other params'; -- 'bar');

Injected value:  $user$ = "foo', null); exec xp_something bad 'other params'; --"

Certainly -- it all depends on how the stored procedure is called by the code.   If the code uses dynamic SQL, then the only thing stored procedures protect you from is bundling additional data into the original query (ala "UNION ALL" or equality statements).

If parm1 and parm2 in your example above were passed in via a query string along the lines of:  http://hackme.com/hack.cfm?parm1=foo&parm2=bar, injection on parm2 would go along the lines of:

http://hackme.com/hack.cfm?parm1=foo&parm2=bar');+exec+master..xp_cmdshell+'evil.exe'+--

For your enjoyment:

http://www.ethicalhacker.net/component/option,com_smf/Itemid,54/topic,2814.0/

OK...by request, here goes (warning:  gets a bit technical):

---

The Situation:
You have a web application (say, http://hackme.com). 
You've identified a page on it that is vulnerable to SQL Injection (say, http://hackme.com/hacked.cfm?id=123)

---

Your Knowledge (via error messages and/or information gathering):
The target is running MS SQL Server 2005
The target is running an application firewall (let's say ISS, though it could just as easily be Barracuda or others)
The "id" field in the URL is passed verbatim into a dynamic SQL query as an integer (bad developer, no cookie!)
The developer (not wanting to be hacked), passes all user input through a filter that pads single quotes (adding an additional single quote so that it's treated as a literal)
The developer (really not wanting to be hacked), strips all whitespace (internal and external) from input
Developers being developers, we believe that the web application connects to the database as a user with administrative privileges

---

Your Goals:
Get access to the command line on the database server (via xp_cmdshell, of course)
Take over the server
Expand your access out into the network
Conquer the planet

For the purposes of this discussion, we'll leave it at wanting to get something along the following lines to execute in the database:

exec master..xp_cmdshell 'echo pwn3d>hack.txt'

Not terribly exciting, but it shows all the access we need to accomplish all of the above (with the possible exception of conquering the planet).

---

Problems:
Every application firewall on the planet will pick up on xp_cmdshell
Padding of single quotes, while not preventing us from injecting on a numeric field, does make life difficult for passing string-based arguments to functions in our SQL
Removing all whitespace from our input ticks us off and prevents normal SQL from executing
MS SQL Server 2005 disables xp_cmdshell by default.   It has to be explicitly enabled before anyone (even sa) can call it.

---

The Hack:
First off, we deal with those pesky single quotes.   Little known fact:  SQL Server will treat hex as a varchar.   So the following are equivalent:

'echo pwn3d>hack.txt'
0x6563686F2070776E33643E6861636B2E747874

This changes the string that we want to execute to:

exec master..xp_cmdshell 0x6563686F2070776E33643E6861636B2E747874

Ok...so far so good (no single quotes)....but there's still that application firewall (that hideously expensive appliance designed to keep us from doing exactly what we're looking to do).

Application firewalls (even the big, expensive ones) effectively operate off of black lists.   Powerful, somewhat dynamic black lists, but black lists nonetheless.   While they will definitely pick up on "xp_cmdshell", we may be able to write things in a way that they don't know about.

Enter Transact SQL (in this case)....plus a second little known fact:  the "exec" statement can take an nvarchar as an argument.   So we write some TSQL  (note, the hex for xp_cmdshell is 0x78705F636D647368656C6C):



I use "execute" rather than "exec" as some application firewalls (*cough*Barracuda*cough*) will pick up on "exec" as perl command line injection.

Finally, we deal with that pesky stripping of whitespace.   Little known fact number 3:  SQL Server will treat inline comments as whitespace, so "SELECT * FROM sysobjects" and "SELECT/**/*/**/FROM/**/sysobjects" are the same.   Applying this to our TSQL, we get the marvelously hideous string:


Dropping this into our URL (and URL-encoding), we get:

We hit this page and.....DRAT!   It doesn't work.   They must not have enabled xp_cmdshell on the SQL Server 2K5.

Never fear, this is why life is fun.   If you have admin privileges, you can enable xp_cmdshell via the following:

sp_configure 'show advanced options',1
reconfigure
sp_configure 'xp_cmdshell',1
reconfigure

Note that you can't call CONFIG (a.k.a. reconfigure) during a user transaction, so you'll want to do some commits.

Applying what we learned above, we can make a new statement:


Then, our nefarious work done, we call our newly enabled xp_cmdshell:

---

Conclusions:
The above code is one means to an end.   There's a large number of variations on this (PL-SQL, Java, other forms of T-SQL, etc.).  The main gist is that you're passing information into the App Firewall that it has no idea what to do with (it's not in the black list), so it lets it go.   This is not a flaw in the application firewall....it's just the nature of the beast.

If you can get one of the T-SQL statements to go through, you can execute any SQL that you want -- all of the actual "work" is done in the hex strings.

I've done pretty much this exact attack on numerous clients (most recently just this week) to take over the database server, establish a command shell, and proceed to expand out into the network.

Certainly....though to avoid derailing the thread, we should probably take it to PM (or a new thread, if you prefer).

Drat!   Right you are!

That'll teach me to post in between rounds of caffeine

WebInspect and AppScan have historically jockeyed for the "top spot" (though this distinction is not without debate).    I wonder what's going to happen now that they're both owned by IBM?

As an aside, Paros can certainly maintain a login session -- just enable Session Tracking within Paros and login to the app from your browser.   Paros will maintain the sessionid during the scan.   So long as you don't include the logout page (or similar) in your paros scan, I've found it to actually be more reliable than WI (since it can handle things like SSO through a different domain).

Heck....SE is some of the most fun you get to have as a hacker

I'm not sure that I agree entirely on the rarity of shell access remotely through web apps, though.   I just pulled one today (SQL Server 2k5, with an ISS IPS in place, so it was a bit tricky).   

I will certainly agree that they're becoming more scarce in current iterations of web programming languages (.NET is vastly better with security than classic ASP)....but legacy code and vulnerable applications in current languages are not too difficult to come by....at least, not yet

Won't do much good against any sort of modern OS.

Now, if he has a network that is vulnerable to Smurf- or Fraggle-style attacks, he may be able to DDoS the guy.....but that (by definition) will also be hitting his own connection, so is a bit questionable as a concept for revenge.

Firing up Ettercap and injecting himself into they guy's traffic may allow for some fun (from the harmless -- switching images, etc. -- to the not so harmless -- harvesting of passwords, session hijacking, etc.)

All in all, though, I would take the advice above and just get rid of the guy rather than risk him knowing more than you do.

If you _really_ want to go after him, do yourself a favor and move any sensitive machines onto a separate network/wireless first.....then tie your attack box into the compromised wireless and go after him with at least a modicrum of impunity.

Hailstorm isn't doing anything that the others aren't doing (unless by "robust" you mean stable and doesn't chew up system resources).

In order for a web app scanner to be effective, it needs to submit forms.  Often many times, as it should ideally only be testing a single parameter at any given time to avoid running afoul of simple input validation checks.    This is the main source of "garbage" being injected into a database and one of the biggest drawbacks to automated vulnerability scanners on web apps (IMO) -- they're extremely noisy and have a strong tendency to alter the database (not to mention sending LOTS of emails, if the website has email functionality).

If you're going against a production environment, I would strongly suggest avoiding the automated scanners altogether -- stick with manual checks where you can be a bit more intelligent about what you inject.    If you're going against a testing/staging environment that can be reset after your testing is complete, then go to town with the scanner -- the garbage data won't matter and it's a good, quick way to give you a high-level overview of the application so that you can target your manual efforts more effectively.

Hope this helps!