Saturday, December 5, 2009

Locating Exploits and Finding Targets

Introduction

Exploit code, collectively called exploits, is a tool of the hacker trade. Designed to penetrate a target, most hackers have many different exploits at their disposal. Some exploits, termed zero day or Oday, remain underground for some period of time, eventually becoming public, posted to newsgroups or Web sites for the world to share. With so many Web sites dedicated to the distribution of exploit code, it's fairly simple to harness the power of Google to locate these tools. It can be a slightly more difficult exercise to locate potential targets, even though many modern Web application security advisories include a Google search designed to locate potential targets.

In this chapter we explore methods locating exploit code and potentially vul­nerable targets.These are not strictly "dark side" exercises, since security profes­sionals often use public exploit code during a vulnerability assessment. However, only black hats use those tools against systems without prior consent.

Locating Exploit Code

Untold hundreds and thousands of Web sites are dedicated to providing exploits to the general public. Black hats generally provide exploits to aid fellow black hats in the hacking community. White hats provide exploits as a way of elimi­nating false positives from automated tools during an assessment. Simple searches such as remote exploit and vulnerable exploit locate exploit sites by focusing on common lingo used by the security community. Other searches, such as inurl:0day, don't work nearly as well as they used to, but old standbys like inurl:sploits still work fairly well.The problem is that most security folks don't just troll the Internet looking for exploit caches; most frequent a handful of sites for the more mainstream tools, venturing to a search engine only when their book-marked sites fail them. When it comes time to troll the Web for a specific secu­rity tool, Google's a great place to turn first.

Locating Public Exploit Sites

One way to locate exploit code is to focus on the file extension of the source code and then search for specific content within that code. Since source code is the text-based representation of the difficult-to-read machine code, Google is well suited for this task. For example, a large number of exploits are written in C, which generally uses source code ending in a .c extension. Of course, a search

for filetype:c c returns nearly 500,000 results, meaning that we need to narrow our search. A query for filetype:c exploit returns around 5,000 results, most of which are exactly the types of programs we're looking for. Bearing in mind that these are the most popular sites hosting C source code containing the word exploit, the returned list is a good start for a list of bookmarks. Using page-scraping tech­niques, we can isolate these sites by running a UNIX command such as:

grep Cached exp | awk -F" -" '{print $1}' | sort -u

against the dumped Google results page. Using good, old-fashioned cut and paste or a command such as lynx —dump works well for capturing the page this way. The slightly polished results of scraping 20 results from Google in this way are shown in Table 6.1.

Table 6.1 Most Common Hits for the Query filetypex exploitSite

Google also makes a great tool for performing digital forensics. If a sus­picious tool is discovered on a compromised machine, it's pretty much standard practice to run the tool through a UNIX command such as strings -8 to get a feel for the readable text in the program. This usually reveals information such as the usage text for the tool, parts of which can be tweaked into Google queries to locate similar tools. Although obfus-cation programs are becoming more and more commonplace, the com­bination of strings and Google is very powerful, when used properly—capable of taking the mystery out of the vast number of suspi­cious tools on a compromised machine.

Locating Exploits

Via Common Code Strings

Since Web pages display source code in various ways, a source code listing could have practically any file extension. A PHP page might generate a text view of a C file, for example, making the file extension from Google's perspective .PHP instead of .C.

Another way to locate exploit code is to focus on common strings within the source code itself. One way to do this is to focus on common inclusions or header file references. For example, many C programs include the standard input/output library functions, which are referenced by an include statement such as #include within the source code. A query such as "#include " exploit would locate C source code that contained the word exploit, regardless of the file's extension.This would catch code (and code fragments) that are displayed in HTML documents. Extending the search to include programs that include a friendly usage statement with a query such as "#include " usage exploit returns the results shown in Figure 6.1.


This search returns quite a few hits, nearly all of which contain exploit code. Using traversal techniques (or simply hitting up the main page of the site) can reveal other exploits or tools. Notice that most of these hits are HTML docu­ments, which our previous filetype:c query would have excluded.There are lots of ways to locate source code using common code strings, but not all source code can be fit into a nice, neat little box. Some code can be nailed down fairly neatly using this technique; other code might require a bit more query tweaking.Table 6.2 shows some suggestions for locating source code with common strings.

Table 6.2 Locating Source Code with Common Strings



Language


Extension (Optional)


Sample String

Perl


PERL, PL, PM


"#!/usr/bin/perl"

Python


Py


"#!/usr/bin/env"

VBScript


.vbs


"<%@ language="vbscript" %>"

Visual Basic


Vb


"Private Sub"

In using this table, a filetype search is optional. In most cases, you might find it's easier to focus on the sample strings so that you don't miss code with funky extensions.



Locating Vulnerable Targets

Attackers are increasingly using Google to locate Web-based targets vulnerable to specific exploits. In fact, it's not uncommon for public vulnerability announce­ments to contain Google links to potentially vulnerable targets, as shown in Figure 6.2.

Locating Targets Via Demonstration Pages

The process of locating vulnerable targets can be fairly straightforward, as we'll see in this section. Other times, the process can be a bit more involved, as we'll see in the next section. Let's take a look at a Web application security advisory posted to Secunia (www.secunia.com) on October 10,2004, as shown in Figure 6.3.

This particular advisory displays a link to the affected software vendor's Web site. Not all advisories list such a link, but a quick Google query should help you locate the vendor's page. Since our goal is to develop a query string to locate vulnerable targets on the Web, the vendor's Web site is a good place to discover what exactly the product's Web pages look like. Like many software vendors' Web sites, the CubeCart site shows links for product demonstrations and live sites that are running the product, as shown in Figure 6.4.

At the time of this writing, this site's demonstration pages were offline, but the list of live sites was active. Live sites are often better for this purpose because we can account for potential variations in how a Web site is ultimately displayed. For example, some administrators might modify the format of a vendor-supplied Web page to fit the theme of the site.These types of modifications can impact the effectiveness of a Google search that targets a vendor-supplied page format.

Perusing the list of available live sites in Figure 6.4, we find that most sites look very similar and that nearly every site has a "powered by" message at the bottom of the main page, as shown in the (highly edited) example in Figure 6.5.

In this case, the live page displays "Powered by CubeCart 2.0.1" as a footer on the main page. Since CubeCart 2.0.1 is the version listed as vulnerable in the security advisory, we need do little else to create a query that locates vulnerable targets on the Web.The final query, "Powered by CubeCart 2.0.1", returns results of over 27,000 potentially vulnerable targets, as shown in Figure 6.6.

Combining this list of sites with the exploit tool released in the Secunia security advisory, an attacker has access to a virtual smorgasbord of online retailers that could likely be compromised, potentially revealing sensitive cus­tomer information such as address, products purchased, and payment details.

Locating Targets Via Source Code

In some cases, a good query is not as easy to come by, although as we'll see, the resultant query is nearly identical in construction. Although this method is more drawn out (and could be short-circuited by creative thinking), it shows a typical process for detecting an exact working query for locating vulnerable targets. Here we take a look at how a hacker might use the source code of a program to discover ways to search for that software with Google. For example, an advisory was released for the CuteNews program, as shown in Figure 6.7.

As explained in the security advisory, an attacker could use a specially crafted URL to gain information from a vulnerable target. To find the best search string to locate potentially vulnerable targets, we can visit the Web page of the software vendor to find the source code of the offending software. In cases where source code is not available, an attacker might opt to simply download the offending software and run it on a machine he controls to get ideas for potential searches. In this case, version 1.3.1 of the CuteNews software was readily available for download from the author's Web page.

Once the software is downloaded and optionally unzipped, the first thing to look for is the main Web page that would be displayed to visitors. In the case of this particular software, PHP files are used to generate Web pages. Figure 6.8 shows the contents of the top-level CuteNews directory.

Of all the files listed in the main directory of this package, index.php is the most likely candidate to be a top-level page. Parsing through the index.php file, line 156 would most likely catch our eye.

156 // If User is Not Logged In, Display The Login Page

Line 156 shows a typical informative comment. This comment reveals the portion of the code that would display a login page. Scrolling down farther in the login page code, we come to lines 173—178:

173 Username:

174
name=username value='$lastusername' style=\"width:134\">

175

176

177 Password:

178

These lines show typical HTML code and reveal username and password prompts that are displayed to the user. Based on this code, a query such as "user-name:" "password:" would seem reasonable, except for the fact that this query returns over 12 million results that are not even close to the types of pages we are looking for. This is because the colons in the query are effectively ignored and the words username and password are far too common to use for even a base search. Our search continues to line 191 of index.php, shown here:

191 echofooter();

This line prints a footer at the bottom of the Web page.This line is a func­tion, an indicator that it is used many times through the program. A common footer that displays on several CuteNews pages could make for a very nice base query. We'll need to uncover what exactly this footer looks like by locating the code for the echofooter function. Running a command such as grep —r echofooter * will search every file in each directory for the word echofooter'.This returns too many results, as shown in this abbreviated output:

j0hnnys-Computer: j0hnny$ grep -r echofooter * inc/about.mdu: echofooter(); inc/addnews.mdu: echofooter(); inc/categories.mdu:echofooter(); inc/editnews.mdu: echofooter();

inc/editnews.mdu: echofooter(); inc/editusers.mdu: echofooter(); inc/functions.inc.php: echofooter(); inc/functions.inc.php:// Function: echofooter inc/functions.inc.php:function echofooter(){ inc/help.mdu: echofooter();

Most of the lines returned by this command are calls to the echofooter func­tion, not the definition of the function itself. One line, however, precedes the word echofooter with the word function, indicating the definition of the function. Based on this output, we know that the file inc/functions.inc.php contains the code to print the Web page footer. Although there is a great deal of information in this function, as shown in Figure 6.9, certain things will catch the eye of any decent Google hacker. For example, line 168 shows that copyrights are printed and that the term "Powered by" is printed in the footer.



Figure 6.9 The echofooter Function Reveals Potential Query Strings



© © © vim

159


|




160


global $PHP_5ELF, $is_loged_in, tconfig_skin, $skin_footer, $lan g_content_type, $skin_rnenu, $skin_prefix, $config_version_narne;




161







162


if ($is_loged_in == TRUE){ $skin_f ooter = preg_replace("/{rnenu}/", "$ skir^menu", "$skin_footer"); }




163


else { $skin_footer = preg_replace("/{menu}/", " Јnbsp; $config_vers ion_narne", "$skin_footer"); }




164







165


$skin_footer = preg_replace("/{irnage-name}/", "${skin_pref ix}${irnage }", $skin_footer);




166


$skin_footer = preg_replace("/{header-text}/", $header_text, $skin_f ooter);




167


$skin_footer = preg_replace("/{content-type}/", $lang_content_type, $skin_footer);




168


$skin_footer = preg_replace("/{copyrights}/", "Powered by ? 20103 CutePHP-oya>.Vdiv>







", $skin_footer);




169







170 171


echo $skin_footer;




172


>




173





/a



A phrase like "Powered by" can be very useful in locating specific targets due to their high degree of uniqueness. Following the "Powered by" phrase is a link to http://cutephp.com/cutenews/ and the string $config_version_name, which will list the version name of the CuteNews program. To have a very specific "Powered by" search to feed Google, the attacker must either guess the exact ver­sion number that would be displayed (remembering that version 1.3.1 of

CuteNews was downloaded) or the actual version number displayed must be located in the source code. Again, grep can quickly locate this string for us. We can either search for the string directly or put an equal sign ( = ) after the string to find where it is defined in the code. A grep command such as grep —r "\$config_version_name =" * will do the trick:

johnny-longs-g4 root$ grep -r "\$config_version_name =" *

inc/install.mdu:\$conng_version_name = "CuteNews v1.3.1";

inc/options.mdu: fwrite($handler, "
Conngurations\n\n\$config_version_name =

\"$conng_version_name\'';\n\n\$conng_version_id = $config_version_id;\n\n"); johnny-longs-g4 root$

As shown here, the version name is listed as CuteNews vl.3.1. Putting the two pieces of the footer together creates a very specific string: "Powered by CuteNews v1.3.1".This in turn creates a very nice Google query, as shown in Figure 6.10.This very specific query returns nearly perfect results, displaying nearly 500 sites running the potentially vulnerable version 1.3.1 of the CuteNews software.

Too many examples of this technique are in action to even begin to list them all, but in the tradition of the rest of this book, Table 6.3 lists examples of some queries designed to locate targets running potentially vulnerable Web applica-tions.These examples were all pulled from the Google Hacking Database.



Table 6.3 Vulnerable Web Application Examples from the GHDB



Query Vulnerability

"Powered by A-CART" A-CART 2.x vulnerable to cross-site

scripting

inurl:"dispatch.php?atknodetype" Achievo .8.x could allow remote code | inurl:class.atkdateattribute.js.php execution

intitle:guestbook "advanced Advanced Guestbook v2.2 has an SQL

guestbook 2.2 powered" injection problem that allows unautho-

rized access

"Powered by AJ-Fork v. 167" AJ-Fork, a fork based on the CuteNews

1.3.1 core, is susceptible to multiple vul­nerabilities

"BlackBoard 1.5.1-f | -© 2003-4 BlackBoard 1.5.1 has a remote file
by Yves Goergen" inclusion vulnerability

"BosDates Calendar System " BosDates 3.2 is vulnerable to SQL

"powered by BosDates v3.2 by injection

BosDev"

inurl:changepassword.cgi --cvs changepassword.cgi allows for unlimited

repeated failed login attempts

"Copyright —© 2002 Agustin CoolPHP 1.0 has multiple vulnerabilities Dondo Scripts"

"Powered by CubeCart 2.0.1" CubeCart 2.0.1 has an SQL injection vul­nerability

"Powered *: newtelligence" DasBlog versions 1.3-1.6 are susceptible

("dasBlog 1.6"l "dasBlog 1.5"l to an HTML injection vulnerability in their "dasBlog 1.4"l"dasBlog 1.3") request log

"Powered by DCP-Portal v5.5" DCP-Portal version 5.5 is vulnerable to

SQL injection

"2003 DUware All Rights Reserved" DUForum 3.0 may allow a remote

attacker to carry out SQL injection and HTML injection attacks

"inurl:/site/articles.asp?idcategory=" Dwc_Articles 1.6 has multiple input vali­dation problems

inurl:custva.asp Earlylmpact Productcart v1.5 contains

multiple vulnerabilities

Continued

Table 6.3 Vulnerable Web Application Examples from the GHDB

Query

Vulnerability



inurl:"/becommunity/community/ index.php?pageurl="

intitle:"EMUMAIL - Login" "Powered by EMU Webmail"



"Powered by FUDforum"



"1999-2004 FuseTalk Inc" -site:fusetalk.com

"Powered by My Blog" intext: "FuzzyMonkey. org"

"Powered by Gallery v1.4.4"



intitle:gallery inurl:setup "Gallery configuration"

inurl:"messageboard/Forum.asp?"

intitle:welcome.to.horde



"Powered by IceWarp Software" inurl:mail



"Ideal BB Version: 0.1" -idealbb.com

"Powered by Ikonboard 3.1.1"

"Powered by Invision Power Board(U) v1.3 Final —© *

inurl:wiki/MediaWiki



"Powered by Megabook * " inurl:guestbook.cgi

"Powered by mnoGoSearch - free Web search engine software"

E-market prior to 1.4.0 contains various vulnerabilities

EMU Webmail 5.6 messaging product is susceptible to a cross-site scripting vul­nerability

FUDforum 2.0.2 allows manipulation of arbitrary server files

FuseTalk forums (v4) are susceptible to cross-site scripting attacks

FuzzyMonkey 2.11 has an SQL injection vulnerability

Gallery 1.4.4 allows remote code execution

Gallery default configuration files allow gallery modification

GoSmart Message Board (specific ver­sions) are susceptible to SQL injection attack and cross-site scripting attack

Horde Mail prior to 2.2 has had several reported vulnerabilities

IceWarp Web Mail (versions prior to 5.2.8) is reported prone to multiple input validation vulnerabilities

Ideal BB 0.1 is susceptible to multiple vulnerabilities

IkonBoard 3.1.1 allows cross-site scripting

Invision Power Board v1.3 is vulnerable to SQL injection

MediaWiki 1.3.5 has a cross-site scripting vulnerability

MegaBook 2.0 is prone to multiple HTML injection vulnerabilities

mnGoSearch 3.1.20 and 3.2.10 contain a buffer overflow vulnerability

Continued

Table 6.3 Vulnerable Web Application Examples from the GHDB

Query

Vulnerability



intitle:"MRTG/RRD" 1.1* (inurlimrtg.cgi \ inurl:14all.cgi \traffic.cgi)

filetype:cgi inurl:nbmember.cgi



"Powered by ocPortal" -demo -ocportal.com

intitle:"PHP Explorer" ext:php

(inurl:phpexplorer.php

\ inurl:list.php \ inurl:browse.php)

"create the Super User" "now by clicking here"

"Enter ip" inurl:"php-ping.php"





intitle:"phpremoteview" filetype: php "Name, Size,

inurl:"plog/register.php"





filetype:php inurl:index.php inurl: "module=subjects" inurl:"func= *" (listpages\ viewpage \ listcat)

"Online Store - Powered by ProductCart"



inurl:com_remository





inurl:"slxWeb.dll"



"File Upload Manager v1.3" "rename to"

filetype:cgi inurl:tseekdir.cgi inurl:ttt-webmaster.php

MRTG 1.1 allows viewing of arbitrary system files



nbmember.cgi 2.0 allows system and user information disclosure

ocPortal 1.0.3 allows remote file inclusion



PHP Explorer scripts reveal server information and provides remote shell access

PHP-Nuke open configuration allows arbitrary creation of admin users

php-ping prior to version 1.2 may be prone to a remote command execution vulnerability

phpRemoteView allows browsing of entire file system

pLog installation scripts should be removed after install because they allow for program compromise

Postnuke Modules Factory Subjects module has an SQL injection vulnerability



ProductCart v1.5-1.6 and v2 are vulnerable to an SQL injection vulnera­bility

ReMOSitory 4.5.1 1.09 module for Mambo is prone to an SQL injection vul­nerability

SalesLogix 2000.0 contains multiple remote vulnerabilities

thepeak file upload manager allows arbitrary user to transfer files

Turbo Seek 1.7.2 search engine reveals arbitrary file contents

Turbo traffic trader Nitro v1.0 contains multiple vulnerabilities

Continued

Table 6.3 Vulnerable Web Application Examples from the GHDB

Query

Vulnerability



ext:cgi inurl:ubb6_test.cgi



"Powered by: vBulletin * 3.0.1" inurl:newreply.php

inurl:/cgi-bin/index.cgi inurl: topics inurl:viewcat= +intext: "WebAPP" -site:web-app.org

intitle:"WebJeff - FileManager" intext:"login" intext:Pass\Passe

intitle:"Index of /" modified php.exe

"Powered by WowBB" -site: wowbb.com

"Powered by YaPig V0.92b"

UBB trial version contains files that are not safe to keep online after going live

vBulletin 3.0.1 allows arbitrary code execution

WebAPP 0.x has a serious reverse directory traversal vulnerability



WebJeff-FileManager 1.x can reveal arbitrary system files

Windows PHP parser allow an attacker to view arbitrary system files

WowBB 1.x affected by multiple input validation vulnerabilities

YaPiG 0.92b contains an HTML injection vulnerability



Locating Targets Via CGI Scanning

One of the oldest and most familiar techniques for locating vulnerable Web servers is through the use of a CGI scanner. These programs parse a list of known "bad" or vulnerable Web files and attempt to locate those files on a Web server. Based on various response codes, the scanner could detect the presence of these potentially vulnerable files. A CGI scanner can list vulnerable files and directories in a data file, such as the snippet shown here:

/cgi-bin/userreg.cgi

/cgi-bin/cgiemail/uargg.txt

/random_banner/index.cgi

/random_banner/index.cgi

/cgi-bin/mailview.cgi

/cgi-bin/maillist.cgi

/iissamples/ISSamples/SQLQHit.asp

/iissamples/ISSamples/SQLQHit.asp

/SiteServer/admin/findvserver.asp

/scripts/cphost.dll

/cgi-bin/finger.cgi

Instead of connecting directly to a target server, an attacker could use Google to locate servers that might be hosting these potentially vulnerable files and directories by converting each line into a Google query. For example, the first line searches for a filename userreg.cgi located in a directory called cgi-bin. Converting this to a Google query is fairly simple in this case, as a search for inurl:/cgi-bin/userreg.cgi shows in Figure 6.11.



Figure 6.11 A Single CGI Scan-Style Query





O O O Google Search: inurl:/cgi-biri/iiserreg.cgi





1

http://www.google.com/search7q: - Qt tnurh/cgi-


bin/userreg.cgi







Web Imaoes Groups News Frooole


more »


1




inurl :/cgi-biri/userreg.cgi


( Search^















W_b Results 1 - 6 of about 61 for inurhJcgi bin/userreg.cgi (0.23 seconds)




Personal Information Required fields are marked with a red asterisk('). First Name: " Middle Name: Last Name: " Company: * Address ...

com/coi-bin/userrea.coi - 2Bk - Oct 26. 2004 - Cached - Similar


canes







httrjs "vvwa1 com/ouestfcoi-bin/jsen'eo.coi - 17k - Cached -


Similar oaoes







t


1 >







A



This search locates over 60 hosts that are running the supposedly vulnerable program.There is certainly no guarantee that the program Google detected is the vulnerable program. This highlights one of the biggest problems with CGI scanner programs.The mere existence of a file or directory does not necessarily indicate that a vulnerability is present. Still, there is no shortage of these types of scanner programs on the Web, each of which provides the potential for many dif­ferent Google queries.

There are other ways to go after CGI-type files. For example, the filetype operator can be used to find the actual CGI program, even outside the context of the parent cgi-bin directory, with a query such as filetype:cgi inurl:userreg.cgi. This locates approximately 15 more results, but unfortunately, this search is even more sketchy, since the cgi-bin directory is an indicator that the program is in fact a CGI program. Depending on the configuration of the server, the userreg.cgi program might be a text file, not an executable, making exploitation of the program interesting, if not altogether impossible!

Another even sketchier way of finding this file is via a directory listing with a query such as intitle:index.of userreg.cgi. This query returns no hits at the time of this writing, and for good reason. Directory listings are not nearly as common as URLs on the Web, and a directory listing containing a file this specific is a rare occurrence indeed.

Automated CGI Scanning Via Google

Obviously, automation is required to effectively search Google in this way, but two tools, Wikto (from www.sensepost.com) and Gooscan (from http://Johnny.ihackstuff.com) both perform automated Google and CGI scanning. The Wikto tool uses the Google API; Gooscan does not. See the Chapter 11, Protecting Yourself from Google Hackers, for more details about these tools.Summary

There are so many ways to locate exploit code that it's nearly impossible to cate­gorize them all. Google can be used to search the Web for sites that host public exploits, and in some cases you might stumble on "private" sites that host tools as well. Bear in mind that many exploits are not posted to the Web. New (or 0day) exploits are guarded very closely in many circles, and an open public Web page is the last place a competent attacker is going to stash his or her tools. If a toolkit is online, it is most likely encrypted or at least password protected to prevent dis­semination, which would alert the community, resulting in the eventual lock-down of potential targets.This isn't to say that new, unpublished exploits are not online, but frankly it's often easier to build relationships with those in the know. Still, there's nothing wrong with having a nice hit list of public exploit sites, and Google is great at collecting those with simple queries that include the words exploit, vulnerability, or vulnerable. Google can also be used to locate source code by focusing on certain strings that appear in that type of code.

Locating potential targets with Google is a fairly straightforward process, requiring nothing more than a unique string presented by a vulnerable Web application. In some cases these strings can be culled from demonstration applica­tions that a vendor provides. In other cases, an attacker might need to download the product or source code to locate a string to use in a Google query. Either way, a public Web application exploit announcement, combined with the power of Google, leaves little time for a defender to secure a vulnerable application or server.



Solutions Fast Track

Locating Vulnerable Targets

0 Attackers can locate potential targets by focusing on strings presented in a vulnerable application's demonstration installation provided by the

software vendor.

0 Attackers can also download and optionally install a vulnerable product to locate specific strings the application displays.

0 Regardless of how a string is obtained, it can easily be converted into a Google query, drastically narrowing the time a defender has to secure a site after a public vulnerability announcement.

Frequently Asked Questions

The following Frequently Asked Questions, answered by the authors of this book, are designed to both measure your understanding of the concepts presented in this chapter and to assist you with real-life implementation of these concepts. To have your questions about this chapter answered by the author, browse to www.syngress.com/solutions and click on the "Ask the Author" form. You will also gain access to thousands of other FAQs at ITFAQnet.com.

Q: CGI scanning tools have been around for years and have large scan databases with contributions from many hackers. What's the advantage of using Google, which depends on a site having been crawled by Googlebot? Doesn't that give fewer results?

A: Although this is true, Google provides some level of anonymity because it can show the cached pages using the strip = 1 parameter, so the attacker's IP (black or white) is not logged at the server. Check out the Nikto code in Chapter 12, which combines the power of Google with the Nikto database!

Q: Are there any generic techniques for locating known vulnerable Web appli­cations?

A: Try combining INURL:["parameter="] with FILETYPE:[ext] and

INURL:[scriptname] using information from the security advisory. In some cases, version information might not always appear on the target's page. If you're searching for version information, remember that each digit counts as a word, so 1.4.2 is three words according to Google.You could hit the 10-word limit fast.

Also remember that for Google to show a result, the site must have been crawled earlier. If that's not the case, try using a more generic search such as "powered by XYZ" to locate pages that could be running a particular family of software.

Q: I suspect webapp HelloDorks.cgi is written without much attention to secu­rity issues. However, the software is not open source and can only be down­loaded for a high price. Is there another way to get the source code?

A: It's not very common, but sometimes software is installed on servers that do no longer parse PHP or Perl source (or they never got it to work). If the admins forget to clean up afterward, this means it can be downloaded or viewed in a browser, like any normal text file. Once a vulnerability is found using that source, an attacker can then proceed to active servers using the same version. Refer back to Table 6.2 for methods of finding source code.

No comments:

Post a Comment