The following is an excerpt from the book Hacking Exposed: Network Security Secrets & Solutions. In this section of Chapter 11: Web Hacking (.pdf), authors Stuart McClure, Joel Scambray and George Kurtz describe webhacking and explain how to avoid becoming a target.
Nearly synonymous with the modern Internet, the World Wide Web has become a ubiquitous part of everyday life. Widespread adoption of high-speed Internet access has paved the way for content-rich multimedia applications. Web 2.0 technologies have marshaled dramatic advances in usability, bridging the gap between client and server and virtually eliminating any user distinction between remote and local applications.
Millions of people share information and make purchases on the Web every day, with little consideration for the security and safety of the site they're using. As the world becomes more connected, web servers are popping up everywhere, moving from the traditional website role into interfaces for all manner of devices, from automobiles to coffee makers.
However, the Web's enormous popularity has driven it to the status of prime target for the world's miscreants. Continued rapid growth fuels the flames and, with the evergrowing amount of functionality being shifted to clients with the advent of Web 2.0, things are only going to get worse. This chapter seeks to outline the scope of the webhacking phenomenon and show you how to avoid becoming just another statistic in the litter of web properties that have been victimized over the past few years.
Web Server Hacking
Before we begin our sojourn into the depths of web hacking, a note of clarification is in order. As the term "web hacking" gained popularity concomitant with the expansion of the Internet, it also matured along with the underlying technology. Early web hacking frequently ...
To continue reading for free, register below or login
To read more you must become a member of SearchSecurityChannel.com
meant exploiting vulnerabilities in web server software and associated software packages, not the application logic itself. Although the distinction can at times be blurry, we will not spend much time in this chapter reviewing vulnerabilities associated with popular web server platform software such as Microsoft IIS/ASP/ASP.NET, LAMP
(Linux/Apache/MySQL/PHP), BEA WebLogic, IBM WebSphere, J2EE, and so on.
These types of vulnerabilities are typically widely publicized and are easy to detect and attack. An attacker with the right set of tools and ready-made exploits can bring down a vulnerable web server in minutes. Some of the most devastating Internet worms have historically exploited these kinds of vulnerabilities (for example, two of the most recognizable Internet worms in history, Code Red and Nimda, both exploited vulnerabilities in Microsoft's IIS web server software). Although such vulnerabilities
provided great "Low Hanging Fruit" for hackers of all skill levels to pluck for many years, the risk from such problems is gradually shrinking for the following reasons:
- Vendors and the open-source community are learning from past mistakes -- take the negligible number of vulnerabilities found to date in the most recent version of Microsoft's web server, IIS 7, as an example.
- Users and system administrators are also learning how to confi gure web server platforms to provide a minimal attack surface, disabling many of the common footholds exploited by attackers in years past (many of which will be discussed in this section). Vendors have also helped out here by publishing configuration best practices (again, we cite Microsoft, which has published "How to Lock
Down IIS" checklists for some time now). This being said, misconfi guration is still a frequent occurrence on the Internet today, especially as web-based technologies proliferate on nonprofessionally maintained systems such as home desktops and small business servers.
- Vendors and the open-source community are responding more rapidly with patches to those few vulnerabilities that do continue to surface in web platform code, knowing with vivid hindsight what havoc a worm like Code Red or Nimda could wreak on their platform.
- Proactive countermeasures such as deep application security analysis products (for example, Sanctum/Watchfi re's AppShield) and integrated input-validation features (for example, Microsoft's URLScan) have cropped up to greatly blunt the attack surface available on a typical web server.
- Automated vulnerability-scanning products and tools have integrated crisp checks for common web platform vulnerabilities, providing quick and efficient identification of such problems.
Don't for a minute read this list as suggesting that web platforms no longer present significant security risks -- it's just that the maturity of the current major platform providers has blunted the specific risks associated with using any one platform versus another.
TIP: Be extremely suspicious of anyone trying to convince you to implement a web platform designed from
scratch (yes, we've seen this happen). Odds are, they will make the same mistakes that all prior web
platform developers have made, leaving you vulnerable to a litany of exploits.
Web server vulnerabilities tend to fall into one of the following categories:
- Sample files
- Source code disclosure
- Canonicalization
- Server extensions
- Input validation (for example, buffer overflows)
This list is essentially a subset of the Open Web Application Security Project (OWASP) "Insecure Configuration Management" category of web application vulnerabilities (see http://www.owasp.org/documentation/topten/a10.html). We will spend a few words discussing each of these categories of vulnerabilities next, and wind up with a short examination of available web server vulnerability-scanning tools.
Sample Files
Web platforms present a dizzying array of features and functionality. In the desire to make their products easy to use, vendors frequently ship them with sample scripts and code snippets demonstrating the product's rich and full feature set. Much of this
functionality can be dangerous if poorly configured or left exposed to the public. Fortunately, in recent years vendors have learned that customers do not appreciate a vulnerable-out-of-the-box experience, and most major vendors now audit their sample
files and documentation as part of their prerelease security review process.
One of the classic "sample file" vulnerabilities dates back to Microsoft's IIS 4.0. It allows attackers to download ASP source code. This vulnerability wasn't a bug per se, but more an example of poor packaging—sample code was installed by default, one of the more common mistakes made by web platform providers in the past. The culprits in this case were a couple of sample files installed with the default IIS4 package called showcode.asp and codebrews.asp. If present, these files could be accessed by a remote attacker and could reveal the contents of just about every other file on the server, as shown in the following two examples:
http://192.168.51.101/msadc/Samples/SELECTOR/showcode.asp?source=/../..
/../../../boot.ini
http://192.168.51.101/iissamples/exair/howitworks/codebrws.asp?source=
/../../../../../winnt/repair/setup.log
The best way to deal with rogue sample files like this is to remove them from production web servers. Those that have built their web apps to rely on sample file functionality can retrieve a patch to mitigate the vulnerabilities in the short term.
Source Code Disclosure
Source code disclosure attacks allow a malicious user to view the source code of application files on a vulnerable web server that is intended to remain confidential. Under certain conditions, the attacker can combine this with other techniques to view important protected files such as /etc/passwd, global.asa, and so on.
Some of the most classic source code disclosure vulnerabilities include the IIS +.htr vulnerability and similar issues with Apache Tomcat and BEA WebLogic related to appending special characters to requests for Java Server Pages (JSP). Here are examples of attacks on each of these vulnerabilities, respectively:
http://www.iisvictim.example/global.asa+.htr
http://www.weblogicserver.example/index.js%70
http://www.tomcatserver.example/examples/jsp/num/numguess.js%70
These vulnerabilities have long since been patched, or workarounds have been published (for example, manually removing the sample files showcode.asp and codebrews.asp; see http://www.microsoft.com/technet/security/bulletin/MS01-004 .mspx for +.htr, http://jakarta.apache.org, and http://dev2dev.bea.com/resourcelibrary/ advisories.jsp?highlight=advisoriesnotifications for JSP disclosure issues). Nevertheless, it is good practice to assume that the logic of your web application pages will be exposed to prying eyes, and you should never store sensitive data, such as database passwords or encryption keys, in your application source.
Reprinted with permission from The McGraw-Hill Companies Inc. Copyright 2009. "Hacking Exposed, Sixth Edition" by Stuart McClure, Joel Scambray and George Kurtz. For more information about this title and other similar books, please visit http://www.mhprofessional.com.
