Search engines have always been a hacker’s best friend. It’s a good bet that at least one of the major Internet search engines has indexed your target web application at least once in the past. The most popular and effective search engines at the time of this writing include Google, Bing, Yahoo!, Ask, AOL, and many others (you can find links in the
“References & Further Reading” section at the end of this chapter).
Our personal favorite is Google. Here are some of the basic techniques we employ when taking a search engine–based approach to web application profiling (the following examples are based on Google’s syntax):
• Search for a specifi c web site using “site:www.victim.com” (with the quotation marks) to look for URLs that contain www.victim.com.
• Search for pages related to a specifi c web site using related:www.victim.com to return more focused results related to www.victim.com.
• Examine the “cached” results that pull the web page’s contents out of Google’s archive. Thus, you can view a particular page on a site without leaving the comfort of www.google.com. It’s like a superproxy!
Software Cookie Structure
IIS 5/6 ASPSESSIONID=[string]
ColdFusion cfid=[number] cftoken=[number]
J2EE Applications jsessionid=[string]
Table 2-5 Common Cookies Used by Off-the-Shelf Web Software
• Investigate search results links called similar pages. These work like the “related”
keyword noted earlier.
• Examine search results containing newsgroup postings to see if any relevant information has been posted about the site. This might include users
complaining about login diffi culties or administrators asking for help about software components.
• Make sure to search using just the domain name such as site:victim.com. This can return search results such as “mail.victim.com” or “beta.victim.com”.
• To locate specifi c fi le types use the fi letype operator, such as “fi letype:swf”, which will fi lter the results to only include Flash SWF fi les that contain the corresponding keywords of your search.
Another really effective way to leverage search to profile a site is to pay close attention to how the application interacts with its URLs while inspecting a site. Attempt to pick out what is unique about the URL. For instance, it could be a filename or an extension or even the way the parameters work. You want to try to identify something fixed, and then perform a Google search on that and see if you can find any documentation or other sites that might be running it. For example, during a recent assessment of an application, we were clicking through and studying how the URLs were set up. The homepage URL looked something like the following:
http://site/wconnect/ace/home.htm
A link on the homepage to “online courses” appeared as follows:
https://site/wconnect/wc.dll?acecode%7ESubGroup%7EONL%7EOnline%2BCourses Following this link, we navigated our way further into the site, noting the following URLs:
https://site/wconnect/ wc.dll?acecode~GroupCatalog~GROUP~ONLFIN~Financial+
Planning+Online~ONL
https://site/wconnect/ wc.dll?acecode~GroupCatalog~GROUP~ONLFIN~Financial+
Planning+Online~ON L~&ORDER=LOCATION
Notice that everywhere we turned, parameters were being passed to wc.dll. So we needed to find out just a little bit more about this file. To do so, we took /wconnect/ wc .dll to Google and ran a search. The results gave us a list of other sites also running this file. After some quick research, we identified the file as belonging to an application called
“Web Connection” developed by West-Wind. Digging even further, we went to the support section on West-Wind’s site and found the administration guide. And while reading the documentation, we noticed a web-based administration page available at http://site/wconnect/admin.asp. So we returned to the web site and attempted to access this page. But our request for the administration page was welcomed with an “IP address rejected” error because we were attempting to access a restricted area from an unauthorized IP address. This appears to be good use of access control lists (ACLs) by
the administrator. We figured this could really be a dead end because we wouldn’t be able to figure out a way to spoof our IP address. Because we live for challenges, however, we returned to the documentation once again. It was then that we noticed there was a URL that allowed us to access a status page of the application just by inputting http://
site.com/wconnect/wc.dll?_maintain_ShowStatus. This page is shown in Figure 2-5.
Through this request, we managed to access the application’s status page successfully.
When we looked closely at the status page, we noticed something interesting: a link that read “Back to Admin Page.” This was noteworthy, as we hadn’t come to this page from the admin page! When clicking the link, it sent us back to the admin.asp page, which was denied (as expected). But we knew we were onto something worth investigating. We felt we were on the brink of a penetration as we had just accessed an administrative function without accessing the administrative page. After returning once again to the documentation, we learned that the administration page is simply a jump-off page from the function calls implemented by wc.dll. Thus, if we knew the administrative function calls, we could just call them directly through the wc.dll file without having to access the admin.asp page. This is just the kind of breakthrough that makes all of the work and the research of profiling worthwhile!
We returned to the documentation to identify all of the function calls that may provide deeper access into the system and find anything interesting that could prove helpful in our task. Within the manual, we found a description of the parameters of the wconnect.ini file from which the application reads its settings. The documentation mentioned a parameter that can be defined that runs an .exe file. This is what the documentation stated:
Figure 2-5 The _maintain~ShowStatus parameter output from the wc.dll dynamic page generation component
“StartEXE: Starts an EXE specified in ExeFile in the DLL ini file for file based messaging. The EXE is started in the System context so it will run invisibly when started from a service.”
This was exactly what we were looking for. Now we needed a way to modify the value of this parameter so it would launch the .exe file that we would define. Luckily, we found an API in the documentation called “wwMain~EditConfig.” The documentation noted that this API call permitted editing of the Web Connection Configuration files remotely. The documentation helpfully described a link that displays a page with the server’s config files for remote editing:
http://site.com/wconnect/wc.dll?wwMain~EditConfi g
Bingo, just what we needed! We inserted this URL into our browser and up popped the page we needed to edit and update the .ini files. We then found the ExeFile parameter and changed the value to c:\winnt\system32\cmd.exe /c "dir /S c:\ > d:\
inetpub\ wwwroot\dir.txt". This is shown in Figure 2-6.
That gave us the full directory listing of all of the files on the system and dumped them into a text file located in the web root. We updated the .ini file. Now, the only thing left to do was to figure out a way for the appserver to reread the configuration file so that our command would be executed.
Looking back in the documentation, we found exactly what we needed: http://site .com/wc.dll?_maintain~StartExe. This would cause the application to restart and run our command. When it was finished, we had access to our newly created file by accessing http://site.com/dir.txt.
All this started from a simple Google query! Remember this as you consider the structure and logic of your web site. We’ll talk about possible countermeasures to this approach in the “General Countermeasures” section later in this chapter.
Figure 2-6 Manipulating the ExeFile parameter to execute arbitrary commands on a victim system.
My, what you can fi nd with Google!