Joined: Jun 04, 2004 Posts: 119 Location: Chicago IL USA
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 to the forums!
, 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.
Joined: Apr 06, 2006 Posts: 2401 Location: Iowa, USA
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:
Only registered users can see links on this board! Get registered or login to the forums!
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.
Joined: Apr 06, 2006 Posts: 2401 Location: Iowa, USA
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.
Joined: Oct 30, 2002 Posts: 1039 Location: RedNeck Land (known as Kentucky)
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 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
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.
View next topic View previous topic
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum
![[Valid RSS]](http://ravenphpscripts.com/images/valid-rss.png "Validate my RSS feed"){kind=small}
:: 
::
