~ Scripting Bugs ~

				essays

(Courtesy of fravia's advanced searching lores)

(¯`·.¸ Looking behind the curtains of server side scripts ¸.·´¯)
Based on information kindly submitted by Entr0py
published at fravia's searchlores in August 2000

A huge amount of web pages are generated dynamically by server side scripts, like ASP from Microsoft, PHP or Perl. As such, it should be quite obvious how much extra and unfiltered info you can get if you manage to look at the sources of these scripts. You'll be able to fetch original URLs for articles, user names and passwords required to log to reserved areas, databases, more exploitable bugs to get even more stuff, like hidden directory listings, etc.

Microsoft's Translate:f bug

The first exploit is related to the severe "Translate:f" bug published 5th of June 2000. The full article should be available here: Translate:f - history, remedy and thoughts. Otherwise check google's cache or other mirrors hosting this same article.
This is an easy method to retrieve source code of ASP scripts by simply including Translate:f in the headers forming the GET request, and by terminating the requested URL with a backslash.
By now you should realize the power of client side proxies like Proxomitron ;-)

BTW, you should check out the reaction from Microsoft to this bug, especially if you buy and blindly trust in technology from "closed source preacher" Microsoft ;-)

The silent evolution of Microsoft's Knowledge Base based on Microsoft's Knowledge Bug Q256888 Last Reviewed: June 8, 2000 hosted on Google's cache Last Reviewed: August 16, 2000 links to Microsoft's current version Internet Information Service Returns Source of Active Server Pages File When Request Contains Translate:f and Ends with a Backslash Internet Information Service may Return Source of Active Server Pages File SYMPTOMS A specially formatted GET request that includes a trailing backslash (\) and contains a "Translate: f" header may cause Internet Information Server (IIS) to return the contents of the Active Server Pages (ASP) page. SYMPTOMS If an Internet Information Services (IIS) server receives a file request that contains a specialized header as well as one of several particular characters at the end, the expected ISAPI extension processing may not occur. The result is that the source code of the file would be sent to the browser.

Fishing the web pond for include files

The next exploit is more generic and related to the information slip found on error messages of badly implemented server side scripts. This one can be applied to pages processed through ASP or PHP.

Try feeding these script generated pages with extraneous or impossible input, and watch the reaction. If you are lucky, you'll get an error message similar to this example:
Parse error on line XYZ in file /home/www/htdocs/include/filter.inc
In this case, just point your browser to http://www.example.com/include/filter.inc and check if you're able to retrieve that file as simple text. Just to wet your appetite, here you'll see the standard behaviour when entering URLs pointing directly to these *.inc files. http://www.php.net/include/shared.inc or http://www.php.net/include/site.inc

A better approach is asking the many search engines for help, especially those with an active cache, like google. Tell them to show all pages that came up with a similar error message when the search robot visited those pages.
This feature/bug was found by Jerry Walsh as reported on this bugtraq article
Try out this link, asking raging what it knows about the subject ;-)
Hey, raging, tell me about +"Microsoft VBScript runtime error" +".inc, "

Avoiding leaks from include files

Information slipping out of include files can be stopped several different ways:

1. Store the include files out of the directory branch accesible through http requests.
   For example, if all your pages are served out of directory /home/www/htdocs then store the include files and other auxiliary private files in a parallel branch, like /home/www/includes but never in a subdirectory under htdocs, like /home/www/htdocs/includes
2. Rename all include files to *.php or *.asp, depending if you're using the PHP or ASP parser.
   This doesn't solve everything. Include files are no longer listed, but they can be executed, thus, behaving perhaps in an unwanted or unexpected way.
3. Enable PHP or ASP parsing for *.inc include files. This has the same drawback as the previous patch.
4. Disable retrieval of include files. In the case of Apache web server, you can include the next statements in an .htaccess file to deny browser access:
     <Files *.inc>
       Order allow,deny
       Deny from all
     </Files>
5. Disable error feedback to the user so as not to disclose any path information about include file locations.
   In the case of PHP, this is done by inserting this next line at the beginning of all your scripts
     error_report(0);
   Of course, as long as you're debugging, revert this to
     error_report(63);
   Remember, security through obscurity should only be a last resort, as this is quite weak. Just look at the number of "Scr1pt  |<1dd13s" trying out brute force scanners and other bandwidth hogging tools.

Knocking on heaven's door

Here's an incomplete list of server side scripting features/bugs. Use it to protect your own site against these attacks, or to find what you're looking for ;-)

Regular expressions - too much power?

It's incredible what can be done with regular expressions.
At times, you can even remotely execute PHP4 scripting commands on the server ;-)

Find out if there's a web form with regular expression search and replace fields, study the preg_replace() function from PHP4, and start digging into the remote server aided by the /e option.

Exploiting JavaScript frontend filters

Blindly trusting correct input from clients is a clear NO. That's the reason why many form based interactive web pages use hard coded limits in these forms, and JavaScript based filters to check for correct input.
Needless to say, any implementation of client-side filters can be disabled. So it is of utmost importance to also write input checking filters at the server side, doublechecking any client input.
Sadly, this security crosschecking is ignored by most webmasters, who blindly trust their JavaScript skills to keep lurkers away.

If you are interested at specific server side scripts, disable all JavaScript filters and start feeding bogus information until you hit error messages from included files, which, in most cases, are not protected against direct leeching ;-)

Using the 127.0.0.1 backdoor

Most servers have restricted web pages, only available to a certain group, for example, for local users using IP address 127.0.0.1.
It would be nice to access these pages remotely, by disguising ourselves as local users, thus, replacing our true IP source address with the loopback address.
This can be done by abusing some weak server side scripts to request documents from the local domain.
In the case of PHP, the standard fopen() function also allows fetching files over HTTP or FTP protocols. It's just a matter of replacing a filename, perhaps encoded within a POST or GET request, with an interesting URL, for example, http://127.0.0.1/server-status.

More information about the restricted server-status page, generated by the module mod_status, is available on the Apache site.

To avoid this kind of information leak, all scripts should check their parameters, rejecting everything suspicious.
Also, Access Control Lists should deny access to the loopback address wherever possible.
A last radical measure is to recompile PHP without socket support, thus, disabling this specific backdoor.

Final words

Server side scripts are a powerful extension to make the internet experience more interactive.
All web portals use them to track their visitors, to give them feedback forms, to set up messageboards, etc.
As powerful as these extensions are, they are also pretty sharp. So beware of cutting your own fingers with these tools!
Learn to use server side scripts wisely, checking once, twice, and many times all likely and unlikely input combinations from browser clients.
Don't trust anything running on client machines, no JavaScript, no length limits as in <INPUT NAME="Key" TYPE="PASSWORD" MAXLENGTH=10>, and no Java applets.

New bugs are discovered on a daily basis, so be sure to check the relevant security forums (sp: fora, forii?) for updated material.

Please send feedback to the folks at the PHPlab.

---

(c) 2000: [fravia+], all rights reserved