Waraxe IT Security Portal  
  Login or Register
::  Home  ::  Search  ::  Your Account  ::  Forums  ::   Waraxe Advisories  ::  Tools  ::
November 17, 2019
Menu
 Home
 Logout
 Discussions
 Forums
 Members List
 IRC chat
 Tools
 Base64 coder
 MD5 hash
 CRC32 checksum
 ROT13 coder
 SHA-1 hash
 URL-decoder
 Sql Char Encoder
 Affiliates
 y3dips ITsec
 Md5 Cracker
 User Manuals
 AlbumNow
 Content
 Content
 Sections
 FAQ
 Top
 Info
 Feedback
 Recommend Us
 Search
 Journal
 Your Account



User Info
Welcome, Anonymous
Nickname
Password
(Register)

Membership:
Latest: MichaelSnaRe
New Today: 0
New Yesterday: 0
Overall: 9145

People Online:
Visitors: 597
Members: 0
Total: 597
PacketStorm News
Currently there is a problem with headlines from this site
Log in Register Forum FAQ Memberlist Search
IT Security and Insecurity Portal

www.waraxe.us Forum Index -> How to fix -> Question about fix to 008 hole
Post new topic  Reply to topic View previous topic :: View next topic 
Question about fix to 008 hole
PostPosted: Fri Jul 16, 2004 12:36 am Reply with quote
rnovice
Regular user
Regular user
 
Joined: Jul 16, 2004
Posts: 5




http://www.waraxe.us/?modname=sa&id=008

add_author vulnerability. We have closed this vulnerability... but closing registering new admins at all:-)

But the question is how to fix all SIMULAR holes. Don't want to post it in open code here, but as soon as this is the way to call any script, for example deactivate the module and so on... Please, tell us the way how to secure php-nuke... or phpbb... or any other script which allows to insert images through tags?

We really need it.
View user's profile Send private message
PostPosted: Fri Jul 16, 2004 11:48 am Reply with quote
SteX
Advanced user
Advanced user
 
Joined: May 18, 2004
Posts: 181
Location: Serbia




All newer versions of php-nuke are immune to this exploit..

_________________

We would change the world, but God won't give us the sourcecode...
....Watch the master. Follow the master. Be the master....
-------------------------------------------------------
View user's profile Send private message
PostPosted: Fri Jul 16, 2004 1:57 pm Reply with quote
rnovice
Regular user
Regular user
 
Joined: Jul 16, 2004
Posts: 5




SteX wrote:
All newer versions of php-nuke are immune to this exploit..

Please, read our first post more carefully.
We are talking not about this exploit exactly, but about this way to explode scripts and defence against it.
View user's profile Send private message
hey
PostPosted: Sat Jul 17, 2004 12:48 am Reply with quote
icenix
Advanced user
Advanced user
 
Joined: May 13, 2004
Posts: 106
Location: Australia




dissable the [img] tags,
if its currently not vulnerable...then what are you trying to fix?

_________________
=[WWW.WARAXE.US]=
-Forum Rules
View user's profile Send private message Send e-mail Visit poster's website MSN Messenger
Re: hey
PostPosted: Sat Jul 17, 2004 7:06 am Reply with quote
rnovice
Regular user
Regular user
 
Joined: Jul 16, 2004
Posts: 5




icenix wrote:
dissable the [img] tags,
if its currently not vulnerable...then what are you trying to fix?

No, this is not option.
Same thing could appears in guestbook or somethine else.
And we have to leave ability to include [img] tags.
We try to find out if there are any way to disable these thing at all, leaving all possibilities.
Though not sure if this is possible.
View user's profile Send private message
Re: hey
PostPosted: Sat Jul 17, 2004 7:32 pm Reply with quote
Jeruvy
Regular user
Regular user
 
Joined: Jun 17, 2004
Posts: 6




rnovice wrote:
icenix wrote:
dissable the [img] tags,
if its currently not vulnerable...then what are you trying to fix?

No, this is not option.


Why?

Quote:

Same thing could appears in guestbook or somethine else.

Example?

Quote:

And we have to leave ability to include [img] tags.


Then don't mess with it. I'm sure it's there already. Or are you converting <img> to [img]?

Quote:

We try to find out if there are any way to disable these thing at all, leaving all possibilities.
Though not sure if this is possible.


I read this as "Can I disable a function and have the function still work?"

Could you elaborate a bit more...
View user's profile Send private message
Re: hey
PostPosted: Sat Jul 17, 2004 7:46 pm Reply with quote
rnovice
Regular user
Regular user
 
Joined: Jul 16, 2004
Posts: 5




Jeruvy wrote:
rnovice wrote:
icenix wrote:
dissable the [img] tags,
if its currently not vulnerable...then what are you trying to fix?

No, this is not option.

Why?

Users need ability to insert their pictures.
Quote:
Quote:

Same thing could appears in guestbook or somethine else.

Example?

Regular Submit_News, img src tag allowed for users. Again, they need it.
Quote:
Quote:
And we have to leave ability to include [img] tags.

Then don't mess with it. I'm sure it's there already. Or are you converting <img> to [img]?

Not quite sure that do you mean. Could you please explain it.
Quote:
Quote:

We try to find out if there are any way to disable these thing at all, leaving all possibilities.
Though not sure if this is possible.

I read this as "Can I disable a function and have the function still work?"

Wrong:-)
It should be read like
"Could we allow users to paste their images through img src or [img ] tag, but filter somehow if users insert valid thing in this tag, or disable call of script from inside if <img src, or to have possibility in script to detect the way how it were called".
View user's profile Send private message
PostPosted: Sun Jul 18, 2004 2:10 pm Reply with quote
waraxe
Site admin
Site admin
 
Joined: May 11, 2004
Posts: 2407
Location: Estonia, Tartu




This is simple - GET method for passing data from user (browser) to server is not secure enough. If you look at http standard (RFC), then they suggest to use POST method to deliver mission-critical data to server.
If attacker uses [img] tag - it can exploit it only, if script accepts GET method for doing some tasks. If script needs POST variables, then believe me, [img] exploit can't make POST request.
If you look at phpbb code, then you see, that all the critical operations, like user permission administration, etc, is protected by variable "submit", which MUST come from $_POST['submit'] ...
And it works perfectly. So - phpnuke code must be rewritten little bit.
View user's profile Send private message Send e-mail Visit poster's website
PostPosted: Sun Jul 18, 2004 2:37 pm Reply with quote
rnovice
Regular user
Regular user
 
Joined: Jul 16, 2004
Posts: 5




waraxe wrote:
This is simple - GET method.....
the post method...
And it works perfectly. So - phpnuke code must be rewritten little bit.

Thank you waraxe for your response. You are doing great job.
It's reasonable way, but ... after your message we look at phpnuke code inside and realize that almost each module have to be rewriten:-(
Hell. More faster will be to write own CMS Twisted Evil Twisted Evil Twisted Evil

Is there any "general" and "overall" way?

Like... for example...
in the beginning of each file in php-nuke there are check
eregi ($php_self,"modules.php") or something like this.
So this is the way to know which script are parent for current code.
Is there any way to determinate were script called from img src tag or from address string?

Inserting some kind of such check in beginning of each script is more acceptable rather than examining scripts to search critical and unsafe variables.
View user's profile Send private message
PostPosted: Sun Jul 18, 2004 3:53 pm Reply with quote
waraxe
Site admin
Site admin
 
Joined: May 11, 2004
Posts: 2407
Location: Estonia, Tartu




Still, i prefer to fix the REASON of the [img] exploit - using GET method for critical operations.

Snippet from my version of "/admin/modules/authors.php":

Code:

case "UpdateAuthor":
   
   // security measures by waraxe, refference http://www.waraxe.us/?modname=sa&id=008
   $chng_aid = $_POST['chng_aid'];
    $chng_name = $_POST['chng_name'];
   // -------------------------------------------------------------------------------
   
    updateadmin($chng_aid, $chng_name, $chng_email, $chng_url, $chng_radminarticle, $chng_radmintopic, $chng_radminuser, $chng_radminsurvey, $chng_radminsection, $chng_radminlink, $chng_radminephem, $chng_radminfaq, $chng_radmindownload, $chng_radminreviews, $chng_radminnewsletter, $chng_radminforum, $chng_radmincontent, $chng_radminency, $chng_radminsuper, $chng_pwd, $chng_pwd2, $chng_admlanguage, $adm_aid);
    break;

    case "AddAuthor":
   
   // security measures by waraxe, refference http://www.waraxe.us/?modname=sa&id=008
   $add_aid = $_POST['add_aid'];
    $add_name = $_POST['add_name'];
   // -------------------------------------------------------------------------------


I think, that simplest method is to search out from script all the critical variables, which have in reality POST-ed by user browser form(s) and then in the beginning of the script, in one place (for simplicity) initialize them from POST variables.

Something like:

Code:

$chng_aid = $_POST['chng_aid'];
$chng_name = $_POST['chng_name'];
$add_aid = $_POST['add_aid'];
$add_name = $_POST['add_name'];
$del_aid = $_POST['del_aid'];


It's simple and effective and should not induct compatibilty problems (if done properly).

By the way - seems, like i will publish some improved files for phpnuke 7.3 - like some admin scripts and search module script. Because they are written so badly and its better, when people can download allready patched version, not patch them manually. And because i will not touch the functionality of the scripts and featureset, then there should be no compatibility problems with other nuke code.

Any opinions? Question
View user's profile Send private message Send e-mail Visit poster's website
Question about fix to 008 hole
  www.waraxe.us Forum Index -> How to fix
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
All times are GMT  
Page 1 of 1  

  
  
 Post new topic  Reply to topic  




Powered by phpBB 2001-2008 phpBB Group






All logos and trademarks in this site are property of their respective owner. The comments and posts are property of their posters, all the rest (c) 2004-2013 Janek Vind "waraxe"
Page Generation: 0.088 Seconds