New Web Application Attack - Insecure Indexing

An anonymous reader writes "Take a look at 'The Insecure Indexing Vulnerability - Attacks Against Local Search Engines' by Amit Klein. This is a new article about 'insecure indexing.' It's a good read -- shows you how to find 'invisible files' on a web server and moreover, how to see contents of files you'd usually get a 401/403 response for, using a locally installed search engine that indexes files (not URLs)."

Re:indexing google

[Neil Blender]

Even though here's about internal indexing, it reminded me of the old fashion google indexing: Search google with some sensitive terms such as : 'index of /' *.pdf *.ps

This is an execellent trick for searching for porn (ie "index of /" lesbian).

Re:Interesting. Brief summary.

[tetromino]

Does anyone know if the Google search applicance is affected by this?

No. First of all, the Google Search Appliance crawls over http, and therefore obeys any .htaccess rules your server uses. Second, you can set it up so that users need to authenticate themselves. Third, there are many filters you can set up to prevent it from indexing sensitive content in the first place (except that since any sensitive content the google appliance indexes must already be accessible via an external http connection, one hopes it's not too sensitive).

RTFM

[Tuross]

My company specialises in search engine technology (for almost a decade now). I've worked quite in-depth with all the big boys (Verity, Autonomy, FAST, ...) and many of the smaller players too (Ultraseek, ISYS, Blue Angel, ...)

I can't recall the last time this kind of attack wasn't mentioned in the documentation for the product, along with instructions on how to disable it. If you choose to ignore the product documentation, you get what you deserve.

It's quite simple folks. Don't open the search engine. ACL query connections. Sanitize queries like you (should?) do other CGI applications. Authenticate queries and results. If you can't be bothered, hire someone who can.

Google Hacks Database

[giant_toaster]

I guess a lot of people have seen this site before, but http://johnny.ihackstuff.com/index.php?module=prod reviews [ihackstuff.com] has a lot of these google exploits etc, he is posting them up so people can check if their sites are secure. There are some interesting presentations by him on the main site about how search engines can be exploited.

Re:Assumptions

[SharpFang]

Im pretty sure the indexing server on Windows won't return 'search results' for files you dont have permissions to list.
The problem and vulnerablity lies in definition of "you".
The indexing program runs on privledges of a local user with direct access to the harddrive. Listing directory contents, reading user-readable files. "you" are the user, like one behind the console, maybe without access to sensitive system files, but with access to mostly everything in the htroot tree the administrator hasn't blocked using the OS permissions, not the httpd features.
As a webpage visitor "you" are "guest", filtered through httpd, with all httpd restrictions applied. No directory listing, obscure blocking methods (.htaccess, config files, redirects, CGI wrapping) working. Your access is limited to what httpd lets you do, not just what the OS does. Now if you access the search engine database, you can see mostly everything the engine saw, including things it wouldn't see if it was running through httpd, not directly accessing the filesystem.

Re:Uh huh....

[conran]

Did you RTFA?

Yep. Did you keep reading it? I'm referring to the methods for when no excerpts are given.