Protection against all types of SQL injection -- incomplete?

Posted: Fri Jan 19, 2007 3:14 pm

For clarification, does NukeSentinel protect against most (if not all known) types of SQL injection?

According to Only registered users can see links on this board! Get registered or login!, NukeSentinel does NOT protect against certain types of SQL injection. If accurate, which forms or types of SQL injection is effective against NukeSentinel? Specifially, what types of SQL injection attacks is processed through NukeSentinel procedures (index.php >> mainfile.php >> nukesentinel.php), but is still NOT caught by NukeSentinel? That is, outside of 3rd-party modules/blocks which may have security vulnerabilities that do not invoke NukeSentinel security procedure at all.

NOTE: I'm not asking for code/PoCs that script kiddies can exploit, but merely a general discussion of the weaknesses of NukeSentinel with regards to SQL injections. I'm sure we're all of the camp that security through obscurity is not effective security.

Looking through nukesentinel.php, there are checks for all kinds of injections: UNION, CLIKE, filters, XSS, etc. But my understanding was that for most (if not all known) forms of SQL injections, NukeSentinel is hardened. I'm not touting the current version of NukeSentinel to be the be-all and end-all for security against SQL injections. That's what patches are for.

Has my trust in NukeSentinel been misplaced? Seriously, after NukeSentinel was released, my maintenance and security of my phpnuke sites became 1000% easier. I would have prolly left phpnuke long ago if not for the hard work of the NukeSentinel/RavenNuke developers.

Posted: Fri Jan 19, 2007 3:45 pm

I'm not sure you understand the full concept of SQL injection attacks. Please understand that SQL injection is a complicated thing that one piece of software can't just make go away. Sentinel is an awesome piece of software that protects against common SQL injection attacks (UNION for example). But if the underlying PHP script does not sanitize user input, then anything can happen, depending on what the script does with that user input and how much the attacker already knows about your script and your database schema. And remember that in our case, PHP-Nuke is open source so the attacker has access to the script source and database schema. He may not know your $prefix, but doesn't need that to cause trouble.

As a quickie intro, please read: http://en.wikipedia.org/wiki/SQL_Injection

Sentinel for example, I don't believe, would protect against one of the "DROP TABLE" examples in the above article. Sentinel can't know in advance that the string "DROP TABLE" is being used in an injection attack or maybe as part of a forum posting (like this one). I will try to exploit the Old Articles block tonight on my test system while Sentinel is running and see.

Ultimately it is up to the module/block/script coder to ensure he is sanitizing inputs from the outside world ($_GET, $_POST, cookies, etc) before using them. If something should be a number, he should cast it to an intval before using it. If the input is a string of arbitrary text data, it should be escaped (addslashes(), or mysql_real_escape_string()) before using it in an SQL query.

As a Nuke admin, you have to pick the add-on modules you use very carefully. You have to kind of trust the author or else google to see if any exploits exist for the prospective software. Sites that have run Sentinel have still been hacked due to vulnerabilities in add-on modules like vWar, SQuery, and coppermine gallery.

Please note that I very much appreciate what Sentinel does, I have donated several times, and wouldn't consider running without it. But you have to realize it can't protect you against all sloppy coding practices. Chatserv's patches and Raven's team go to great efforts right now to clean up the sloppy code in the Nuke code base that exposes you to these types of problems.

Posted: Fri Jan 19, 2007 6:28 pm

Well I learned something interesting. I was successful in injecting SQL into the Old Articles block with Sentinel running (and magic quotes turned off as per the security bulletin). However the mysql_query() PHP function does not allow you to run multiple SQL commands separated by a semi-colon. So I was not clever enough to actually drop any tables like I had hoped (?). But I was able to alter the SQL query enough to get results out the database that someone may not want me to know.

But I am glad to see it is signficantly harder than I thought to do damage with SQL injection.

Note that Sentinel didn't know what I was doing. That is not a knock on Sentinel. It would have to be a massively complicated program that used artificial intelligence and knowledge of what script I was trying to run to stop me.

Sells PC To Pay For Divorce Joined: Posts: 5661

Quote:

But you have to realize it can't protect you against all sloppy coding practices

exactly.......and if anyone uses vulnerable stuff then 10 sentinels wont protect you..

Posted: Fri Jan 19, 2007 6:46 pm

Wow all kinds of light bulbs are going off over my head now. Smile

So, because you can't use the semi-colon in mysql_query() calls, I now see why the UNION option on a query becomes an important tool for an attacker!

Posted: Fri Jan 19, 2007 10:25 pm

Here is another link that explains SQL injection:

http://www.unixwiz.net/techtips/sql-injection.html

registered · Posted: Sat Jan 20, 2007 1:41 am

Raven asked me to add my comments here to help answer questions.

Here's the way we code NukeSentinel(tm) to control exploits. The first versions delt with all the other known exploits. Then over time as new threats come out we code in protection for those new ones. We also try to be offensive as welll as defensive on said coding. Say for example a module is found to allow H T T P : / / thru one of it's variables we not only check that variable but look at other variables that may allow the same thing and lock them down.

We can not protect for every possible attack but we protect against as many attacks as we can without over doing it. You add NukeSentinel(tm) checks and blanaces together with ChatServ's Patched releases and you have turned your Pinto into a Tank as far as security goes.

Since I check my referers fairly often I can tell you one thing for sure, many hacker sites use NukeSentinel(tm) to protect their own sites. Which makes us/me feel fairly darn good about it's level of protection Smile

I have also found many warez sites that use NukeSentinel(tm) for the same reasons.

I hope this helps reassure you and doesn't create more questions then it answers Wink

Posted: Sat Jan 20, 2007 12:37 pm

Here is what I did to the default block-Old_Articles.php file to make it more safe:

Right after the long global statement at the top of the file, add the following:

Code:




$querylang = '';


$cat = intval($cat);


$new_topic = intval($new_topic);

That will prevent people from altering the SQL query beyond what it was meant to do.

Again, I don't fully understand what the $cat, $categories, $new_topic, and $querylang stuff was all about. They are probably left over features from an ancient release or half baked stuff.