Free Article

3/2011

HEURISTIC METHODS VS. AUTOMATED SCANNERS

Which Is The Most Efficient? by Hans-Michael Varbaek

Page 1

Heuristic Methods vs. Automated Scanners

Which is the most efficient? Humans? Machines? Or the two in tandem?
As most penetration testers know, a manual check of a Web Application can be much more thorough than a completely automated one. By combining a few assistant tools for example, an intercepting proxy (see Figure 1) and perhaps a vulnerability scanner that may find overlooked parts one can improve his or her assessment of actual vulnerabilities.

he manual methodology, however differs appreciably from one ethical hacker to another, and in many cases only very basic (common) ways of approach are used. By using a heuristic method manually, the efficiency of finding a vulnerability within the target web application can increase drastically. So what exactly is this methodology to which Im referring? It may seem quite common to some individuals even though it hasnt been publicly sharedyet (except, of course, in this magazine). Creating a fuzz-word (also known as a XSS-locator string) is the first step, as this can break almost any non-sanitized function relying

on proper syntax, Cross-Site Scripting (XSS) issues, and almost any other input validation vulnerability. This is only the first step; the second step or goal is to know how WordPress, vBulletin, Joomla, etc. looks not only in HTML source code but also by design. The colours and various other elements may have been changed, but generally the blocks where information is displayed are usually at the same location on every site. This makes it easy to see if the site runs a custom-made or a well-known CMS. For example, vBulletin 4 almost always has the login field in the top right, and within the source code in the header fields, theres usually a line of included JavaScript code (see Figure 2) which reveals the overall version (rarely patch level). This would indicate that the target is running vBulletin 4.1.2, and by looking in the JavaScript file the patch level may be revealed, depending on how the administrator updated the forums the last time he or she did so. With Joomla its common to see com_xxx in the source, and with WordPress a common item within the source would be wp-content.

Figure 1. Burp Suite Free: Spidering a website

Figure 2. Firebug: Viewing a JavaScript le

03/2011 (3) July

Page 1

http://pentestmag.com

FREE ARTICLE

Figure 4. Exploit-DB: Searching for vBulletin Exploits

Figure 3. FireFox: Viewing the HTML source of a website

Those are just examples, but more important is to know how a default installation looks like as compared to one with add-ons. Some add-ons are hard to spot, almost transparent while some leave comments within the source like <-- Super Insecure Addon 1.2.3 --> (see Figure 3) which gives the advanced penetration tester an advantage, since he can then just download the addon and look for vulnerabilities within this him- or herself and perhaps find a 0day exploit! But why find an unknown vulnerability within the target web application? Maybe its fully up to date and patched, so there are no other ways of entry after a very thorough and automated scan has been done. In these cases a penetration tester could, if time allows it, look for these so-called 0days.

The Difference in Development Life Cycles

So far, many automated scanners would have found nothing or almost nothing, because theyre not designed

to find all kinds of 0days, but hopefully most penetration testers are. One should understand, however, that it may be extremely time-consuming to do find some of these exploits by hand. Some of these unknown vulnerabilities are often found by accident, if the target web application is a well-known one or has at least had a good Secure Development Life Cycle (SDLC). If the target web application didnt have any security applied at the development phase, an automated scanner would probably pick up vulnerabilities in a matter of seconds, and if the web application did have security somewhat applied, an automated scanner might not find any of the vulnerabilities, but a penetration tester with the right knowledge, not wanting to look through hundreds or thousands lines of code, would probably find one or several vulnerabilities. The biggest danger is that the developer decides that the scanner he has chosen is the best and the only right tool to use, and if that returns no vulnerabilities (false negatives), then there arent any. Therefore, if a human penetration tester and not just an automated scanner

Contribute
Penetration Testing Magazine is a community-oriented magazine. We want IT security specialists and enthusiasts to work together and create a magazine of the best quality, attractive to every individual and enterprise interested in the penetration testing eld. If you are interested in being a part of our community submit an article or bring up a subject you consider important and up-to-date. Are there any trends on the market youd like to take a closer look at? Are there any tools or solutions worth reviewing or presenting to the community? Are there any touchy and controversial issues you feel have to be discussed in public? Then share your opinions with us. If you run an IT security company, your contribution is the most welcome. Tell us about your solutions and advertise in the magazine for free, or have a special issue devoted exclusively to you. As long as you provide top-notch quality of you writings, we are always ready to cooperate and help your company develop with us. Are you a student? Were looking forward to you articles! Fresh attitude, opinions and beliefs of the young and budding IT security gurus are invaluable for us. You will give your career a great start when you write to a respectable IT magazine.
03/2011 (3) July

Showing an issue with your name among the names of other authors and often famous ones will be your great asset during a job interview. If you think you dont have enough time to create an article from scratch, but feel interested in the magazine become one of our beta testers. This way you will get the opportunity to look at a new issues contents before its even published, and your name, too, will appear in the magazine. If you feel the need to contribute and share you knowledge, but dont have enough spare time for creative writing beta testing is just for you.

Page 2

Sections: White Box Black Box Web Security Network Security Wireless Security

Application Security Standards and Methodologies How To Open Source Intelligence Vulnerabilities http://pentestmag.com

had tested the application, it wouldve been more secure and not contained several security issues.

The Backend + (Fingerprinting & Subdomains)

Another important factor is the backend: the webserver is a major part of this, but so also is the coding language used, both of which may give the penetration tester an idea of which vulnerabilities to expect. A common vulnerability for too many ASP(x) powered sites, would be the infamous search.asp?q=XSS vulnerability, which is often non-persistent (reflected) yet still a vulnerability. Imagine a website running vBulletin, which is a forum web application. The footer containing the version information is removed, and the generator meta header is also removed. The general design is heavily altered, but it still looks somewhat like vBulletin. So the penetration tester assumes he or she can use the Version Disclosure trick shared earlier in this article, to find out which version is installed. If a vulnerable version is found and theres a public Proof of Concept available (see Figure 4), then the penetration tester has already made one foothold, depending on the type of vulnerability. Now imagine another website, perhaps a custom-built one where an automated scanner returns no results. Still, almost all web applications or custom websites contain at least one vulnerability, because sometimes the vulnerable applications are located on outdated subdomains. In order to find these subdomains, which are often on the same server, the penetration tester can use (e.g.) Google if the targets nameserver does not allow AXFR requests which potentially could return a zone-transfer. (see Figure 5.) In this case all the subdomains points to the same IPaddress, which the penetration tester is allowed to test, including all vhosts (Virtual Hosts) on the webserver. Each virtual host can have its own physical directories separate from the others, and these can even contain vulnerable code as well! Therefore it is logical to test these if they are within reach of the penetration. The query that most automated scanners would most likely not even try could look like the one in Figure 6. Assume the target runs PHP, which Apache usually

does. In case of ASP, its most likely powered by an IIS webserver. The above query returns the main domain and subdomains (excluding the forum), where the fileextension is .php. It can also be modified to exclude directories and several other subdomains, so instead of excluding the forum, www is often used in my queries, which filters most of the main website away, making it easier to find potential subdomains with dynamic PHP scripts, for example. Usually it is possible to just look at error pages (e.g., 404) served by the webserver, or HTTP headers for that sake, in order to determine the scripting language and webserver. The problem is that some administrators change these headers and error pages, but rarely the file extension, except in SEO cases where .php might be .html instead, but on the backend its still PHP files used to serve the website. The reason why this query is used is because many websites use rewrite-rules (e.g., mod_rewrite) these days, so its sometimes hard to guess whats powering the target website. Especially when theres no default index file such as index.php. So by finding just one dynamic file with the .php extension, its easier not only to assume which vulnerabilities to look for, but also to test this mentioned file or perhaps several returned files from the search query. Most PHP files without any visible GET or POST requests visible are not much help, and some do not show even if these files are accessed directly; however, if theres a link to one of these, then Google will most likely know some or all of the requests that may contain a vulnerability due to non-sanitized input.

Heuristically Approaching & Avoiding WAFs

Imagine you see that the file accepts 2 GETrequests, the first one is loggedin=1 and the second is downfile=info.pdf. Obviously if the pseudo-file info.pdf can be downloaded with this call, the penetration tester should try to download other files, perhaps the well-known /etc/passwd. An automated scanner will try

Figure 5. dig: Requesting a DNS Zone-Transfer

Figure 6. Google: Using Operators for Recon and Enumeration

03/2011 (3) July

Page 3

http://pentestmag.com

FREE ARTICLE
predefined strings until it finds something useful, while a manual and heuristic method would probably be much more fruitful. (see Figure 7) Using a program to find these possible vulnerable files is a good idea, but testing them manually may return more interesting results, such as shown below. In this case, a locator-string like pentest01/\>< could be used. It doesnt look like much, but if all characters are returned without being sanitized, then its possible to perform XSS. If a SQL-error is returned, perhaps invalid syntax then or broke the SQL-query, which thereby allows a possible SQL-injection. If a file-error is returned, then LFI or RFI may be possible. In case of no such command, perhaps RCE (Remote Code Execution) could be attempted. This way of finding vulnerabilities only applies to input validation vulnerabilities, which are often the most dangerous vulnerabilities. Because the penetration testers goal is to gain access to the server backend, its logical to assume that high-risk vulnerabilities are the most valuable. Its true that XSS can lead to Remote Code Execution as well (see Figure 8), but this approach requires user interaction. Our locator-string (a.k.a. fuzz-word) required 1 query (see Figure 9) while the automated scanner created most likely a massive overhead by sending perhaps 10 different strings to determine if there was a vulnerability and what it might have been. Most Intrusion Detection Systems (IDS) wouldve picked up on this amount of attempts and traffic, while the fuzz-word may not have been detected at all. Most Web Application Firewalls (WAF) would not get triggered by this fuzz-word either, except that some including web applications may not respond very well to the slash (/) due to mod_rewrite or > and < since they are uncommon in most queries. Hence the reason some WAFs are triggered by them. Theres a reason why the locator-string is written like >< in the end, and not <>. This is because most

Figure 8. EvilWebtool: vBSEO XSS Exploit

WAFs are triggered by <[a-Z0-9]>, while they are not yet triggered by >[a-Z0-9]<. This gives the penetration tester an advantage in that it requires fewer queries for success. An experienced penetration may need to ask him- or herself, if <[a-Z0-9]> is blocked by a WAF, then how does this give a pentester an advantage over an automated scanner? Imagine an aggressive WAF on, lets say, a website many people visit within the Information Security community. A penetration tester fires up his favorite scanner, and one minute later, hes banned for a few hours. Either he learns from this mistake, and finds out it was <[a-Z0-9]> that triggered the ban, or he continues to restart the scanner whenever possible and wastes precious time. Now imagine a blackhat has discovered a Local File Inclusion (LFI) vulnerability on the same target, but the WAF blocks all malicious looking attacks and bans her temporarily for a few hours. However, this blackhat has no timeframe within which to finish the attack, so after researching the WAF she finds a DoS vulnerability enabling her to shut the WAF down and thereby abuse the LFI vulnerability she found earlier. Most automated scanners are using real attacks, of course, as they are most efficient this way and are able to determine whether there is a vulnerability or not instead of using these so called fuzz-words (see Figure 9). So the chance a WAF picks up the attacks is much higher than one single fuzz-word designed to avoid even most but not all aggressive WAFs.

Figure 7. 0day: Local File Disclosure

Figure 9. FireFox: After submitting our fuzz-word to a script

03/2011 (3) July

Page 4

http://pentestmag.com

Table 1. Humans vs. machines

Humans
Finding Advanced 0days Simultaneous Requests Smart Interpreting of Results Massive Variations in Requests Detect All Common Vulnerabilities Discover New Attack Methods Enumerate Large SQL Tables Yes No Yes Time consuming! Time consuming! Yes Time consuming!

Machines
No (Requires AI) Yes No (Requires AI) Yes Yes No (Requires AI) Yes

Why not just use or ?

A manual audit of (e.g.) access.logs would tell most aware webmasters from miles away that someone tried to perform a SQL injection. A fuzzword is harder to spot if it looks legit. But why is this important? Some penetration tests also check the skills of the administrators, internal security auditors, or perhaps just IDSs to see if they would be able to pick up a blackhat-looking attack if it happened. The target script may not break with just or , it may even require a / or \, or maybe the penetration tester does not know if a particular SQL-query breaks upon or , so its reasonable to include the most common characters a function will break upon receiving. (Including all possible special characters is not recommended, nor would it be efficient.)

After all, at many points humans are still smarter than machines, and if a penetration tester knows a web application very well, then he or she also knows which vulnerabilities to look for and where they might be based on a behavioral pattern from previous vulnerabilities. With vBulletin, for example, its obvious to look for XSS and SQL Injections in new versions with new features. Looking for LFI and RFI in this particular web application could be a complete waste of time except in the add-ons. If new developers have come aboard or an entire development team has been switched out, then the entire security of the target web application may have become insecure, so its good to know how the company behind the app is working and evolving too. What are some of the differences between humans and machines, then? A report a couple of years ago, revealed that 44 out of the 50 most visited websites in a country had at least 1 vulnerability and many of them ran custom-built websites, but it was also well-known web applications (mostly via add-ons and subdomains) that included vulnerabilities. Many of these websites had been tested with automated scanners, but apparently not properly and/or with manual methods. The third and final step is intuition applied to knowledge.

HANSMICHAEL VARBAEK
Hans-Michael Varbaek has been in the hacking community for a little over 10 years now, though with shorter and longer breaks from time to time. Around 5 years ago he decided to get back after a long period of inactivity, where he began creating custom cheats for WoW. (Mountain Climbing, No Clip, etc.) A year later he began the education as SysAdmin, and during this time he created InterN0T after brainstorming like crazy. Then he moved to Sweden to work within IT- support, with some of the big manufacturers of products like printers, cameras, and so forth. Meanwhile, he discovered his rst 0days in Web Applications, and a year later he was going for CTP+OSCE, which he completed successfully., while shortly Shortly thereafter he began blogging about Web Application Security at Exploit-DB.

When a download file script is encountered, its obvious to test for LFI, RFI, Information Disclosure, and so forth. But an automated scanner may not know the target script is actually serving files from the filesystem; it may think it serves them from a SQL Database and therefore attempt to SQL Inject instead, which may lead to no results at all.

What is considered best practice nowadays?

Dont rely too much on any automated scanner. Use them as a complement to your toolbox as well as to your own methods. While the automated scanner does all the boring work, such as crawling the website and trying the most common attack vectors, the penetration tester could simultaneous apply more advanced heuristic methods and look for vulnerabilities in the same or other places.
03/2011 (3) July

Page 5

http://pentestmag.com