Jump to content

File Writing Change


Guest MrsSim

Recommended Posts

Posted

Following this topic, I think IPB may have to have its file writing system changed. Perhaps you could change it so it could only write with permission from the admin (and ask for FTP details)?

Posted

Small add-on:

what about adding feature, that won't allow hacker to upload .php (.php3, .php4, .php5, .phtml, .pl, .cgi, what are other files?) files even if it is enabled from AdminCP ?

hardly anybody need to upload this files as attachements...

(or you can add feature that user can not access files from upload/ folders directly. only via some script that don't allow for example .php files to start)

also feature which allows you to disable SQL toolbox in Admin CP can be good.

Posted

Using the attachments manager you have all the control over the filetypes IPB allows. If they upload them via a PHP exploit, they don't use IPB settings.

You can disable php from executing in uploads via a .htaccess file.

Posted

Using the attachments manager you have all the control over the filetypes IPB allows. If they upload them via a PHP exploit, they don't use IPB settings.



You can disable php from executing in uploads via a .htaccess file.


That poses a bit of a problem though; you wouldn't be able to install skins, and uploading for members would be disabled. You could install skins, but you'd have to do it manually (ex. adding the correct stuff in the database, placing the CSS in the cache folder, etc.), and some members would complain about the inabillity to upload, resulting in an error on the top of the page.

Is there a modification, for now, that modifies IPB to prompt for FTP username and password?
Posted

Skins are installed via an xml file, not php....so no, it wouldn't affect skin installation at all. :)

You wouldn't be disabling uploading in the .htaccess file. I was recommending disabling php from executing in an htaccess file in the uploads directory specifically. This discussion though should be had at IPS Beyond rather than here, as what I'm talking about isn't so much a feature suggestion.

Posted

Using the attachments manager you have all the control over the filetypes IPB allows. If they upload them via a PHP exploit, they don't use IPB settings.



You can disable php from executing in uploads via a .htaccess file.


Yes. we can. but often there is such situation:

1. attacker gets pass_hash of admin, logs to admincp
2. adds .php to allowed attachements.
3. uploads attachement.
4. points browser to http://site/upload/uploaded_file.php
>> he can run this file.

and yes, I added this info to .htaccess:

options -Includes -ExecCGI -Indexes
php_value engine off
and changed chmod of .htaccess to r--r--r-- , so hacker won't be able to do this again.

but by default, board is vulnerable to this "exploit". (it is not exploit.. )

other option can be to rename all files edned with .php , so if hacker upload .php, he gets .php.txt for example.
Posted

Yes. we can. but often there is such situation:



1. attacker gets pass_hash of admin, logs to admincp


2. adds .php to allowed attachements.


3. uploads attachement.


4. points browser to

http://site/upload/uploaded_file.php

>> he can run this file.



and yes, I added this info to .htaccess:



options -Includes -ExecCGI -Indexes


php_value engine off


and changed chmod of .htaccess to r--r--r-- , so hacker won't be able to do this again.



but by default, board is vulnerable to this "exploit". (it is not exploit.. )



other option can be to rename all files edned with .php , so if hacker upload .php, he gets .php.txt for example.




How does getting the pass_hash of Admin gain access to the ACP ... the pass_hash canot be decoded to the actual password. If they are gaining access to the ACP then they must know the password or be using brute force.
Posted

How does getting the pass_hash of Admin gain access to the ACP ... the pass_hash canot be decoded to the actual password. If they are gaining access to the ACP then they must know the password or be using brute force.


actually I don't know how they got access to Admin CP.

but I do know that they got pass_hash of member(also converge_pass_hash and converge_salt), then gained acces to admin CP, added new attachement type: .phtml and uploaded some script to upload folder.

so by hacking into admin cp (other question is how) - hacker can get access to whole site (and with wrong server's security - to whole server).

also, for example there is such situation:
we have site of programmers, who share .php files via Forum.

How administrator can do it without using mods ? :)
(Yes I know how, but still, administrators should not worry about "to enable this feature, you have to know/do this, this and this)
Posted

If im not mistaken even if they did add .php as an alloud file extension, the uploaded file is uploaded as .ipb not .php. When downloading a file it is filtered through a downloader script. And when the script is downloaded it's loaded as a generic application octet type. The only files that are uploaded directly are those with an image/* mime type. If this isnt the case, it should be anyway.

Plus you are forgetting one important fact: The attacker could just add php code to a setting block. There's a text box where you can put php code in that can be evaluated. Is it being filtered?

Right now I think the biggest issue is making sure the attacker doesnt get into adminCP at all. I'm not sure how they would possibly get the admin session, but if they are it's a pretty serious issue. One thing I would suggest though is to add a capache thing for the admin login screen to prevent brute force attacks.

Posted

Exactly...you're wrong in this case Advanced Ghost.

If you upload a .php file via IPB (as an attachment) it gets renamed in the uploads folder to .ipb, and thus is NEVER executable. Even if they guessed the filename (which wouldn't be uploaded_file.php, but something like post-119797309785.ipb) it isn't executable because Apache does not recognize it as a php file based on the extension.

When you have files uploaded to other folders, there is an exploit - a software issue, that is allowing it. It has nothing to do with IPB's attachments or attachment permissions, and any changes to the attachment system will not prevent it.

Same goes for .cgi, .pl, .phtml, etc. etc. etc.

Posted

Exactly...you're wrong in this case Advanced Ghost.



If you upload a .php file via IPB (as an attachment) it gets renamed in the uploads folder to .ipb, and thus is NEVER executable. Even if they guessed the filename (which wouldn't be uploaded_file.php, but something like post-119797309785.ipb) it isn't executable because Apache does not recognize it as a php file based on the extension.



When you have files uploaded to other folders, there is an exploit - a software issue, that is allowing it. It has nothing to do with IPB's attachments or attachment permissions, and any changes to the attachment system will not prevent it.



Same goes for .cgi, .pl, .phtml, etc. etc. etc.


try to upload .phtml as avatar -> it works :)
and it links to url:
http://forum1/uploads/av-1.phtml
just point to browser, and you are there.

(and yes, it does not work on php3, php4, .pl, .cgi)
Posted

try to upload .phtml as avatar -> it works :)


and it links to url:


http://forum1/uploads/av-1.phtml

just point to browser, and you are there.



(and yes, it does not work on php3, php4, .pl, .cgi)



It doesn't work by default. If you enable any script extension as an allowable avatar extension, then you are inviting trouble.
Posted

It doesn't work by default. If you enable any script extension as an allowable avatar extension, then you are inviting trouble.


by refering to old posts:
1. .phtml is often handled as php file.
2. if hacker get in admincp, he can add extension and upload .phtml , which can be started via browser.

(and ok, whatever. I added protection from this "bug" for my board, so there is no more problems for me..)

Archived

This topic is now archived and is closed to further replies.

  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...