Skip to main content

Web Application Footprinting & Assessment with MSN Search

posted onDecember 12, 2005
by hitbsecnews

By: Shreeraj Shah

Introduction

Any search engine database is a very powerful source of information for web applications. The
Search Engine’s spiders are well-powered to run frequently on sites and capture all possible
links. As an end user, however, we are more interested in the searching interface and criteria
these engines provide. By using their search options, end users can craft intelligent queries
against a database and fetch critical information. There are several tools out there that query the
Google database and fetch this sort of security-related information about web applications.

This
paper describes some of the queries that can be run against SEARCH.MSN in order to fetch
important information that would eventually help in web application assessment.
SEARCH.MSN provides web services APIs to build applications using their search interface.

More information can be gathered from http://search.msn.com/developer/
To be able to use SEARCH.MSN, you will require an Application ID. This can be obtained
using MSN passport. Queries are limited to 10,000 a day and allow a total of 50 results for each
query. This provides great flexibility to the application. As a security tool, substantial
information can be queried from MSN search, making it a handy tool to have in your toolkit. For
the examples outlined in this paper, some of the information is retrieved using this interface, with
a sample application called wapawn.
Web application footprinting with MSN search

One of the challenging tasks for security professionals is to discover web applications belonging
to specific clients, using a limited set of information. Often, the only information we have in
place is an IP address or a higher-level domain, like, for instance, “icenet.net” (a local ISP of the
city). Beginning with this zero-level information, we attempt to see what else we can discover.
We can divide our footprinting exercise into two sections – host-level and domain-level.

Host footprinting

One of the problems faced, is to find reverse DNS lookup in a multihosting scenario. When more
than one web applications is hosted on one IP address, it is important to know the correct
application host name in order to retrieve information related to this specific web application.
This host information can be passed to “Host:” in the HTTP header section, while making
HTTP requests to specific IP addresses.

Here is a result of a query run using the IP directive – ip:203.88.128.11 – on a web API
interface. This is a sample application to query MSN search over their web services. The same
objective can also be achieved on the traditional web interface provided on their web site.

We have successfully obtained the above hosts running on specific IP address, 203.88.128.11.
Shown below is a screenshot of running the exact same query on their web interface.

This directive is very useful in doing reverse host finding despite DNS not having a PTR record.
MSN search discovers an IP address and reports each web application host found pointing to this
IP address.
It is possible to choose how results of a search query appear. To get a unique value or just one
value for each of the sites “discovered”, use settings. This is very useful to make sure we get just
one value. In the above example, we were interested only in unique hosts pointing to a particular
IP address. Here is the option that needs to be modified that would allow you to set up just such a
scenario.

Domain footprinting

MSN search supports the “site” directive that fetches all possible applications running on that
particular domain and any child domains. For example, we can run the following query and fetch
this result set.

The above screenshot shows all the different applications running on the “icenet.net” domain.
All applications running on the child domain are also fetched. This is the easiest way of getting
all applications belonging to a sample domain. Here is how you can get it from their web
interface instead of from web services.

Getting cross-domains pointing to a domain

Cross-domains are domains that point to the application but do not reside on the same domain
despite belonging to the same client or group. Such domains cannot be footprinted using either
DNS or the “site” directive. But if we are able to analyze and somehow obtain a list of web
applications or sites that are pointing to this particular application, we will be able to get access
to all cross-domain references.

An example should make things clearer: Let us assume that the application called
www.icetel.co.in” belongs to the “icenet.net” domain and is part of their IP address
range. How do we go about footprinting this domain? In other words, is there a way to discover
domains or applications that are pointing to the “icenet.net” domain?

Incidentally, there is a way. The “linkdomain” directive on MSN does precisely this – retrieve a
list of pages that point to any page residing on this particular domain. Interestingly, the
following query can fetch an important list of hosts and domains.

linkdomain:icenet.net –site:icenet.net

There are two parts to this query: one, we search for “linkdomain:
results and the second, we negate(–) any of the results that are part
condition “–site:icenet.net”. Shown below is the screenshot:

And here’s the result from the web interface.

This cross-domain harvesting method gives us access to another set of applications that belong to
the same family or group, based solely on their IP range. Needless to say, “linkdomain” is an
interesting switch to explore while performing web application footprinitng; it may throw up
some unexpected sets of results.

Other tricks and tips that can be leveraged in web application
assessment

1. Tuning search with interesting directives
One of the interesting directives that MSN search supports is selecting parameters for tuning
search results, as is shown in the screenshot below:

This can help in generating “fuzzy” search results as well as recently updated pages. Using this
directive we can locate the most recently updated pages and can differentiate these from the last
set of links or pages collected. This differentiation method is required in order to generate
incremental security assessment and perform assessment on newly added resources from the
clients.
For example, here’s how we can obtain fresh search results for “icenet.net”:
site:icenet.net {frsh=100}

2. Web application profiling

We can also use the “site” directive to grab all links for specific web applications.
Simultaneously, we can also fetch cached pages and perform HTML sifting. This would provide
information such as forms, applets, objects, etc. With this information in place, resource mapping
can be performed on the application to define attack points for SQL injection or Java
decompilation.

3. Assessment and file search

MSN provides directives like “contains” and “filetype”. contains provide a page which
points to specific file types. For instance, the following search would return a page location that
points to the location of the “pdf” files, residing on, say, the “icenet.net” domain.
site:icenet.net contains:pdf
This directive can help in profiling high value targets and resources which point to important
resources. “filetype” is the directive that can help in locating different file extensions such as
html and pdf.

4. Page scrubbing with in* directives

It is possible to look for specific information at specific locations within an HTML page with
different directives like inurl, inanchor, inbody, intitle, etc. These directives allow
crafty search queries to be built to look for specific information. For example, if we want to find
all PHP pages residing on the“icenet.net” domain, our query would be “site:icenet.net
inurl:php”. Such queries assist in web application assessment for large domains.

5. Restricting query with respect to location

MSN has an interesting directive called “loc” which can be used to find specific resources
located in specific countries. For instance, to see all pages of the “icenet.net” domain residing in
India only, our query would be “site:icenet.net loc:IN”. This can be useful in cases where
the scope of assessment on large domains is limited to specific geographic locations.

Conclusion

Web application security assessment is always a challenge; more so, when beginning with zerolevel
information about the application. Out of intense complexities emerge intense simplicities.
By utilizing the extremely powerful search options provided by the MSN search engine to
construct intelligent queries that fetch critical information, this article seeks to offer simple
solutions to footprinting web applications in different domains or those that are mapped to a
single IP address.

1.) Web Application Footprinting & Assessment with MSN Search - Shreeraj Shah
2.) Biometrics and You - Don Parker
3.) Review: Mac OS X x86 10.4.1 & 10.4.3 - L33tdawg
4.) eXploiting Local Stack on Windows - Nish Bhalla
5.) Reverse engineering a shareware tool and writing a proper keygen for it - azerton
6.) Story of a dumb patch - Cesar Cerrudo

Source

Tags

Articles

You May Also Like

Recent News

Wednesday, May 8th

Tuesday, May 7th

Monday, May 6th

Friday, May 3rd

Thursday, May 2nd

Wednesday, May 1st

Tuesday, April 30th