ISPConfig exploit

Discussion in 'Developers' Forum' started by Piega, May 7, 2006.

Thread Status:
Not open for further replies.
  1. Piega

    Piega New Member

    Piega, May 7, 2006
    #1
  2. till

    till Super Moderator Staff Member ISPConfig Developer

    Hi Piega,

    thank you for posting the information about the exploit.

    First, i think this exploit will not affect any ISPConfig installation.

    Explanation:

    The Exploit tries to reach the file session.inc.php in a browser.
    This is impossible because the file is not inside the web root.

    The web root in every ISPConfig installation is:

    /home/admispconfig/ispconfig/web/

    The session.inc.php is located in:

    /home/admispconfig/ispconfig/lib/session.inc.php


    You can try this with your ISPCOnfig installation:

    https://www.yourdomain.com:81/lib/session.inc.php

    You will get an 404 page not found error.

    Nevertheless, we will add some code to the session.inc.php file
    to prevent remote code inclusions even when the file is copied
    inside the web root.

    If you feel insecure until we release the update, you may add this
    line as second line to the session.inc.php file:

    if(isset($_REQUEST["go_info"])) die();



    Please send security related informations about ISPConfig first to
    dev [at] ispconfig [dot] org and give the development team some time
    to review them and relaese a patch if nescessary before you post them
    to the forum.
     
    till, May 8, 2006
    #2
  3. webstergd

    webstergd New Member

    hey

    I am going to agree with you guys on this one. I dont see how this exploit could work. I just played around with it to see if I can get anything. But, I could not get into my servers using this exploit. This is mostly because in the recent versions the filters are good and this file isn't in server space.

    In sum, I studied and tested this exploit and I am going to say it doesnt work on the recent versions.

    P.S. Falko or Till, message me if you want some of my friends to try to this exploit.
     
    webstergd, May 8, 2006
    #3
  4. falko

    falko Super Moderator Howtoforge Staff

    We've tested it, it doesn't work. :)
     
    falko, May 8, 2006
    #4
  5. djtremors

    djtremors New Member

    Since everything works from index.php, wouldn't be easier to add a simple

    define( "_VALID_ISPC", 1 );

    to the index.php and then every module or file etc would have something like

    defined( '_VALID_ISPC' ) or die( 'Direct Access to this location is not allowed.' );

    would this kind is protection help? I should stop direct access to files and only allow it included from index.php
     
    djtremors, May 9, 2006
    #5
  6. falko

    falko Super Moderator Howtoforge Staff

    That's wrong, not everything works from index.php. It's a frameset, and in the frameset other files are loaded.
     
    falko, May 9, 2006
    #6
  7. djtremors

    djtremors New Member

    ok fairys muff, but then in that case that direct accessed file would have the same tests because they really should be doing it anyway.
    So only files that are dirctly accessed are allowed and any others are all blocked if they weren't loaded from index.php or any of the other directly accessed frameset files.
     
    djtremors, May 10, 2006
    #7
  8. till

    till Super Moderator Staff Member ISPConfig Developer

    All files that shall not be called directly are not in the web root, so calling them is not possible. Also register_globals is off in ISPConfig, which also prevents the attack described in the exploit. Nevertheless I agree with you that securing these files in the PHP source is a good idea and I will add some "direct call" detection code.

    I've added already some additional tests to session.inc.php
     
    till, May 18, 2006
    #8
Thread Status:
Not open for further replies.

Share This Page