Saturday, February 25, 2006

Honeypots (Definitions and Value of Honeypots)

By Lance Spitzner
Definitions and Value of Honeypots
Lance Spitzner
With extensive help from Marty Roesch and David Dittrich

Over the past several years there has been a growing interest in honeypots and honeypot related technologies. Honeypots are not a new technology, they were first explained by a couple of very good papers by several icons in computer security, Cliff Stoll's book the Cuckoo's Egg", and Bill Cheswick's paper "An Evening with Berferd." This paper attempts to take their work further and discuss what honeypots are, how they can add value to an organization, and several honeypot solutions. There are a variety of misconceptions on what a honeypot is, how it works, and how it adds value. It is hoped this paper helps clear up those issues. Also, few people realize the risk and issues involved with honeypots. Though honeypots can add value, the time and resources involved may best focused on greater priorities. If after reading this paper you are interested in learning more about honeypot technologies, I've created a website dedicated just to honeypots, at

Before we jump into the paper, we should first agree on several definitions. Far too often I've seen people arguing on maillists about honeypots. What is so amusing is you can tell they are talking about two entirely different concepts. If they had taken a moment to agree on what they were arguing about first, life would have been much simpler for everyone (including my mailbox) To make sure we are all on the same sheet of music, I would like to first agree on some definitions. For this paper, I will first standardize on the definition of a honeypot, then the two different types of honeypots, and finaly the different categories of security and how they apply to honeypots.

I define a honeypot as "a security resource who's value lies in being probed, attacked or compromised". This means that whatever we designate as a honeypot, it is our expectation and goal to have the system probed, attacked, and potentially exploited. Keep in mind, honeypots are not a solution. They do not 'fix' anything. Instead, honeypots are a tool. How you use that tool is up to you and depends on what you are attempting to achieve. A honeypot may be a system that merely emulates other systems or applications, creates a jailed environment, or may be a standard built system. Regardless of how you build and use the honeypot, it's value lies in the fact that it is attacked.

We will break honeypots into two broad categories, as defined by Snort creator Marty Roesch. Marty pointed out to me that the two types of honeypots are "production" and "research", a breakdown I found to be very useful. The purpose of a production honeypot is to help mitigate risk in an organization. The honeypot adds value to the security measures of an organization. Think of them as 'law enforcement', their job is to detect and deal with bad guys. Traditionally, commercial organizations use production honeypots to help protect their networks. The second category, research, are honeypots designed to gain information on the blackhat community. These honeypots do not add direct value to a specific organization. Instead they are used to research the threats organizations face, and how to better protect against those threats. Think of them as 'counter-intelligence', their job is to gain information on the bad guys. This information is then used to protect against those threats. Traditionaly, commercial organizations do NOT use research honeypots. Instead, organizations such as Universities, government, military, or security research organizations use them.

Before discussing how honeypots add value to security, lets first define what security is. Security is the reduction of risk. One can never eliminate risk, but security helps reduce risk to an organization and its information related resources. When discussing security, I like to break it down into three areas, as defined by the infamous Bruce Schneier in Secrets and Lies. Bruce breaks security down into the three categories as follows.

Prevention: We want to stop the badguys. If you were to secure your house, prevention would be similar to placing dead bolt locks on your doors, locking your window, and perhaps installing a chain link fence around your yard. You are doing everything possible to keep the threat out.

Detection: We want to detect the badguys when they get through. Sooner or later, prevention will fail. You want to be sure you detect when such failures happen. Once again using the house analogy, this would be similar to putting a burglar alarm and motion sensors in the house. These alarms go off when someone breaks in. If prevention fails, you want to be alerted to that as soon as possible.

Reaction: We want to react to the badguys once we detect them. Detecting the failure has little value if you do not have the ability to respond. What good does it to be alerted to a burglar if nothing is done? If someone breaks into your house and triggers the burglar alarm, one hopes that the local police force can quickly respond. The same holds true for information security. Once you have detected a failure, you must execute an effective response to the incident.
Now that we have a better idea of what security is, lets see how honeypots add value to each one of these three categories.
Value of Honeypots
Honeypots have certain advantages (and disadvantages) as security tools. It is the advantages that help define the value of a honeypot. The beauty of a honeypot's lies in its simplicity. It is a device intended to be compromised, not to provide production services. This means there is little or no production traffic going to or from the device. Any time a connection is sent to the honeypot, this is most likely a probe, scan, or even attack. Any time a connection is initiated from the honeypot, this most likely means the honeypot was compromised. As there is little production traffic going to or from the honeypot, all honeypot traffic is suspect by nature. Now, this is not always the case. Mistakes do happen, such as an incorrect DNS entry or someone from accounting inputing the wrong IP address. But in general, most honeypot traffic represents unauthorized activity.

Because of this simplistic model, honeypots have certain inherent advantages and disadvantages. We will cover several of them.

Advantage - Data Collection
Honeypots collect very little data, and what they do collect is normally of high value. This cuts the noise level down, make it much easier to collect and archive data. One of the greatest problems in security is wading through gigabytes of data to find the data you need. Honeypots can give you the exactly the information you need in a quick and easy to understand format. For example, the Honeynet Project, a group researching honeypots, collects on average only 1-5MB of data per day. This information is normally of high value also, as not only can you show network activity, but what the attacker does once he or she gets on the system. We will go into greater depth in these advantage when we discuss how honeypots add value to detection.
Advantage - Resources
Many security tools can be overwhelmed by bandwidth or activity. Network Intrusion Detection Devices may not be able to keep up with network activity, dropping packets, and potentially attacks. Centralized log servers may not be able to collect all the system events, potentially dropping some events. Honeypots do not have this problem, they only capture that which comes to them.
Disadvantage - Single Data Point
Honeypots all share one huge drawback; they are worthless if no one attacks them. Yes, they can accomplish wonderful things, but if the attacker does not send any packets to the honeypot, the honeypot will be blissfully unware of any unauthorized activity.
Disadvantages - Risk
Honeypots can introduce risk to your environment. As we discuss later, different honeypots have different levels of risk. Some introduce very little risk, while others give the attacker entire platforms from which to launch new attacks. Risk is variable, depending on how one builds and deploys the honeypot.
It is because of these disadvantages that honeypots do not replace any security mechanisms. They can only add value by working with existing security mechanisms. Now that we have reviewed the overall value of honeypots, lets apply them to security.
As we discussed earlier, there are two types of honeypots, production and research. We will first discuss what a production honeypot is and its value. Then we will discuss research honeypots and their value.

A production honeypot is one used within an organization's environment to help mitigate risk. It adds value to the security of production resources. Lets cover how production honeypots apply to the three areas of security, Prevention, Detection, and Reaction.

I personally feel honeypots add little value to prevention, honeypots will not help keep the bad guys out. What will keep the bad guys out is best practices, such as disabling unneeded or insecure services, patching what you do need, and using strong authentication mechanisms. It is the best practices and procedures such as these that will keep the bad guys out. A honeypot, a system to be compromised, will not help keep the bad guys out. In fact, if incorrectly implemented, a honeypot may make it easier for an attacker to get in.

Some individuals have discussed the value of deception as a method to deter attackers. The concept is to have attackers spend time and resource attacking honeypots, as opposed to attacking production systems. The attacker is deceived into attacking the honeypot, protecting production resources from attack. While this may prevent attacks on production systems, I feel most organizations are much better off spending their limited time and resources on securing their systems, as opposed to deception. Deception may contribute to prevention, but you will most likely get greater prevention putting the same time and effort into security best practices.

Also, deception fails against two of the most common attacks today; automated toolkits and worms. Today, more and more attacks are automated. These automated tools will probe, attack, and exploit anything they can find vulnerable. Yes, these tools will attack a honeypot, but they will also just as quickly attack every other system in your organization. If you have a coffee pot with an IP stack, it will be attacked. Deception will not prevent these attacks, as there is no consciously acting individual to deceive. As such, I feel that honeypots add little value to prevention. Organizations are better off focusing their resources on security best practices.

While honeypots add little value to prevention, I feel they add extensive value to detection. For many organizations, it is extremely difficult to detect attacks. Often organizations are so overwhelmed with production activity, such as gigabytes of system logging, that it can be extremely difficult to detect when a system is attacked, or even when successfully compromised. Intrusion Detection Systems (IDS) are one solution designed for detecting attacks. However, IDS administrators can be overwhelmed with false positives. False positives are alerts that were generated when the sensor recognized the configured signature of an "attack", but in reality was just valid traffic. The problem here is that system administrators may receive so many alerts on a daily basis that they cannot respond to all of them. Also, they often become conditioned to ignore these false positive alerts as they come in day after day, similar to the story of "the boy who cried wolf". The very IDS sensors that they were depending on to alert them to attacks can become ineffective unless these false positives are reduced. This does not mean that honeypots will never have false positives, only that they will be dramatically fewer than with most IDS implementations.

Another risk is false negatives, when IDS systems fail to detect a valid attack. Many IDS systems, wheter they are signature based, protocol verification, etc, can potentially miss new or unknown attacks. It is likely that a new attack will go undectected by currently IDS methodologies. Also, new IDS evasion methods are constantly being developed and distributed. It is possible to launch a known attack that may not be detected, such as with K2's ADM Mutate. Honeypots address false negatives as they are not easily evaded or defeated by new exploits. In fact, one of their primary benefits is that they can most likely detect when a compromise occurs via a new or unknown attack by virtue of system activity, not signatures. Administrators also do not have to worry about updating a signature database or patching anamoly detection engines. Honeypots happily capture any attacks thrown their way. As discussed earlier though, this only works if the honeypot itself is attacked.

Honeypots can simplify the detection process. Since honeypots have no production activity, all connections to and from the honeypot are suspect by nature. By definition, anytime a connection is made to your honeypot, this is most likely an unauthorized probe, scan, or attack. Anytime the honeypot initiates a connection, this most likely means the system was successfully compromised. This helps reduce both false positives and false negatives greatly simplifying the detection process. By no means should honeypots replace your IDS systems or be your sole method of detection. However, they can be a powerful tool to complement your detection capabilities.

Though not commonly considered, honeypots also add value to reaction. Often when a system within an organization is compromised, so much production activity has occurred after the fact that the data has become polluted. Incident response team cannot determine what happened when users and system activity have polluted the collected data. For example, I have often come onto sites to assist in incident response, only to discover that hundreds of users had continued to use the compromised system. Evidence is far more difficult to gather in such an environment.

The second challenge many organizations face after an incident is that compromised systems frequently cannot be taken off-line. The production services they offer cannot be eliminated. As such, incident response teams cannot conduct a proper or full forensic analysis.

Honeypots can add value by reducing or eliminating both problems. They offer a system with reduced data pollution, and an expendable system that can be taken off-line. For example, lets say an organization had three web servers, all of which were compromised by an attacker. However, management has only allowed us to go in and clean up specific holes. As such, we can never learn in detail what failed, what damage was done, is there attacker still had internal access, and if we were truly successful in cleanup.

However, if one of those three systems was a honeypot, we would now have a system we could take off-line and conduct a full forensic analysis. Based on that analysis, we could learn not only how the bad guy got in, but what he did once he was in there. These lessons could then be applied to the remaining webservers, allowing us to better identify and recover from the attack.

As discussed at the beginning, there are two categories for honeypots; production and research. We have already discussed how production honeypots can add value to an organization. We will now discuss how research honeypots add value.

One of the greatest challenges the security community faces is lack of information on the enemy. Questions like who is the threat, why do they attack, how do they attack, what are their tools, and possibly when will they attack? It is questions like these the security community often cannot answer. For centuries military organizations have focused on information gathering to understand and protect against an enemy. To defend against a threat, you have to first know about it. However, in the information security world we have little such information.

Honeypots can add value in research by giving us a platform to study the threat. What better way to learn about the bad guys then to watch them in action, to record step-by-step as they attack and compromise a system. Of even more value is watching what they do after they compromise a system, such as communicating with other blackhats or uploading a new tool kit. It is this potential of research that is one of the most unique characteristics of honeypots. Also, research honeypots are excellent tools for capturing automated attacks, such as auto-rooters or Worms. Since these attacks target entire network blocks, research honeypots can quickly capture these attacks for analysis.

In general, research honeypots do not reduce the risk of an organization. The lessons learned from a research honeypot can be applied, such as how to improve prevention, detection or reaction. However, research honeypots contribute little to the direct security of an organization. If an organization is looking to improve the security of their production environment, they may want to consider production honeypots, as they are easy to implement and maintain. If organizations, such as universities, governments, or extremely large corporations are interested in learning more about threats, then this is where research honeypots would apply. The Honeynet Project is one such example of an organization using research honeypots to capture information on the blackhat community.

Honeypot Solutions
Now that we have been discussing the different types of honeypots and and their value, lets discuss some examples. The more and more I work with honeypots, the more I realize that no two honeypots are alike. Because of this, I have identified what I call level of interaction. Simply put, the more an attacker can interact with a honeypot, the more information we can potentially gain from it, however the more risk it most likely has.

The more a honeypot can do and the more an attacker can do to a honeypot, the more information can be derived from it. However, by the same token, the more an attacker can do to the honeypot, the more potential damage an attacker can do. For example, a low interaction honeypot would be one that is easy to install and simply emulates a few services. Attackers can merely scan, and potentially connect to several ports. Here the information is limited (mainly who connected to what ports when) however there is little that the attacker can exploit. On the other extreme would be high interaction honeypots. These would be actual systems. We can learn far much more, as there is an actual operating system for the attacker to compromise and interact with, however there is also a far greater level of risk, as the attacker has an actual operating system to work with. Neither solution is a better honeypot. It all depends on what you are attempting to achieve. Remember, honeypots are not a solution. Instead, they are a tool. Their value depends on what your goal is, from early warning and detection to research. Based on 'level of interaction', lets compare some possible honeypot solutions.

For this paper, we will discuss six honeypots. There are a variety of other possible honeypots, however this selection covers a range of options. We will cover BackOfficer Friendly, Specter, Honeyd, homemade honeypots, Mantrap, and Honeynets. This paper is not meant to be a comprehensive review of these products. I only highlight some of their features. Instead, I hope to cover the different types of honeypots, how they work, and demonstrate the value they add and the risks involved. If you wish to learn more about the capabilities of these solutions, I highly recommend you try them out on your own in a controlled, lab environment.

BackOfficer Friendly
BOF (as it is commonly called) is a very simple but highly useful honeypot developed by Marcus Ranum and crew at NFR. It is an excellent example of a low interaction honeypot.

The reason I am such a big fan of this is due to BOF's simplicity. It is a great way to introduce a begginer to the concepts and value of honeypots. BOF is a program that runs on most Window based operating system. All it can do is emulate some basic services, such as http, ftp, telnet, mail, or BackOrrifice. Whenever some attempts to connect to one of the ports BOF is listening to, it will then log the attempt. BOF also has the option of "faking replies", which gives the attacker something to connect to. This way you can log http attacks, telnet brute force logins, or a variety of other activity ( Screenshot). I like to run BOF on my laptop, as it gives me a feel for what type of activity may be occuring. The value in BOF is in detection, similar to a burglar alarm. It can monitor only a limited number of ports, but these ports often represent the most commonly scanned and targeted services.

Specter is a commercial product and what I would call another 'low interaction' production honeypot. It is similar to BOF in that it emulates services, but it can emulate a far greater range of services and functionality. In addition, not only can it emulate services, but emulate a variety of operating systems. Similar to BOF, it is easy to implement and low risk. Specter works by installing on a Windows system. The risk is reduced as there is no real operating system for the attacker to interact with. For example, Specter can emulate a webserver or telent server of the operating system of your choice. When an attacker connects, it is then prompted with a http header or login banner. The attacker can then attempt to gather web pages or login to the system. This activity is captured and recorded by Specter, however there is little else the attacker can do. There is no real application for the attacker to interact with, instead just some limited, emulated functionality. Specters value lies in detection. It can quickly and easily determine who is looking for what. As a honeypot, it reduces both false positives and false negatives, simplifying the detection process. Specter also support a variety of alerting and logging mechanisms. You can see an example of this functionality in a screen shot of Specter.

One of the unique features of Specter is that it also allows for information gathering, or the automated ability to gather more information about the attacker. Some of this information gathering is relatively passive, such as Whois or DNS lookups. However, some of this research is active, such as port scanning the attacker. While this intelligence functionality may be of value, many times you do not want the attacker to know he is being watched. Be careful when implementing any active, automated responses to the attacker.

Homemade Honeypots
Another common honeypot is homemade. These honeypots tend to be low interaction. Their purpose is usually to capture specific activity, such as Worms or scanning activity. These can be used as production or research honeypots, depending on their purpose. Once again, there is not much for the attacker to interact with, however the risk is reduced because there is less damage the attacker can do. One common example is creating a service that listens on port 80 (http) capturing all traffic to and from the port. This is commonly done to capture Worm attacks. One such implementation would be using netcat, as follows:

netcat -l -p 80 > c:\honeypot\worm

In the above command, a Worm could connect to netcat listening on port 80. The attacking Worm would make a successful TCP connection and potentially transfer its payload. This payload would then be saved locally on the honeypot, which can be further analyzed by the administrator, who can assess the threat of the Worm. Organizations such as SANS and have had success using homemade honeypots to capture and analyze Worms and automated activity.

Homemade honeypots can be modified to do (and emulate) much more, requiring a higher level of invovlement, and incurring a higher level of risk. For example, FreeBSD has a jail functionality, allowing an administrator to create a controlled environment within the operating system. The attacker can then interact with this controlled environment. The value here is the more the attacker can do, the more can be potentially learned. However, care must be taken, as the more functionality the attacker can interact with, the more can go wrong, with the honeypot potentially compromised.

Some additional examples of homemade honeypots:

Port listener coded in PERL by Johannes B. Ullrich, used to capture the W32/Leaves Worm.
Windows Inetd emulator for Windows NT and Win2000.
Sendmail Honeypots, used to identify sendmail spammers.
LaBrea Tarpit is a unique approach to honeypots, allowing you not only to capture worm activity, but potentially slow or disable worm attacks.
Created by Niels Provos, Honeyd is an extremely powerful, OpenSource honeypot. Designed to run on Unix systems, it can emulate over 400 different operating systems and thousands of different computers, all at the same time. Honeyd introduces some exicting new features. First, not only does it emulate operating systems at the application level, like Specter, but it also emulates operating systems at the IP stack level. This means when someone Nmaps your honeypot, both the service and IP stack behave as the emulated operating system. Currently no other honeypot has this capability (CyberCop Sting did have this capability, but is no longer available). Second, Honeyd can emulate hundreds if not thousands of different computers all at the same time. While most honeypots can only emulate one computer at any point in time, Honeyd can assume the identify of thousands of different IP addresses. Third, as an OpenSource solution, not only is it free to use, but it will expotentially grow as members of the security community develop and contribute code.

Honeyd is primarily used for detecting attacks. It works by monitoring IP addresses that are unused, that have no system assigned to them. Whenever an attacker attempts to probe or attack an non-existant system, Honeyd, through Arp spoofing, assumes the IP address of the victim and then interacts with the attacker through emulated services. These emulates services are nothing more then scripts that react to predetermined actions. For example, a script can be devloped to behave like a Telnet service for a Cisco router, with the Cisco IOS login interface. Honeyd's emuilated services are also OpenSource, so anyone can develop and use their own. The scripts can be written in almost any language, such as shell or Perl. Once connected, the attacker belives they are interacting with a real system. Not only can Honeyd dynamically interact with attackers, but it can detect activity on any port. Most low interaction honeypots are limited to detecting attacks only on the ports that have emulated services listening on. Honeyd is different, it detects and logs connections made to any port, regardless if there is a service listening. The combined capabilities of assuming the identify of non-existant systems, and the ability to detect activity on any port, gives Honeyd incredible value as a tool to detect unauthorzied activity. I highly encourage people to check it out, and if possible to contribute new emulated services.

Now we begin to move into more honeypots with greater levels of interaction. These solutions give us far greater information, but potentially have far greater risk. We will be discussing to such honeypots, Mantrap and Honeynets. We will begin with Mantrap.

Produced by Recourse Mantrap is a commercial honeypot. Instead of emulating services, Mantrap creates up to four sub-systems, often called 'jails'. These 'jails' are logically discrete operating systems separated from a master operating system (see Diagram.) Security administrators can modify these jails just as they normally would with any operating system, to include installing applications of their choice, such as an Oracle database or Apache webserver. This makes the honeypot far more flexible, as it can do much more. The attacker has a full operating system to interact with, and a variety of applications to attack. All of this activity is then captured and recorded. Not only can we detect port scans and telnet logins, but we can capture rootkits, application level attacks, IRC chat session, and a variety of other threats. However, just as far more can be learned, so can more go wrong. Once compromised, the attacker can used that fully functional operating system to attack others. Care must be taken to mitigate this risk. As such, I would categorize this as a mid-high level of interaction. Also, these honeypots can be used as either a production honeypot (used both in detection and reaction) or a research honeypot to learn more about threats. There are limitations to this solution. The biggest one is you are limited to what the vendor supplies you. Currently, Mantrap only exists on Solaris operating system.

Honeynets represent the extreme of research honeypots. They are high interaction honeypots, you can learn a great deal, however they also have the highest level of risk. Their primary value lies in research, gaining information on threats that exist in the Internet community today. A Honeynet is a network of production systems. Unlike many of the honeypots we have discussed so far, nothing is emulated. Little or no modifications are made to the honeypots. This gives the attackers a full range of systems, applications, and functionality to attack. From this we can learn a great deal, not only their tools and tactics, but their methods of communication, group organization, and motives. However, with this capability comes a great deal of risk. A variety of measures must be taken to ensure that once compromised, a Honeynet cannot be used to attack others. Honeynets are primarily research honeypots. They could be used as production honeypots, specifically for detection or reaction, however it is most likely not worth the time and effort. Most of the low interaction honeypots we have discussed so far give the same value for detection and reaction, but require less work and have less risk. If you are interested in learning more about Honeynets, you may want to review the book Know Your Enemy.

We have reviewed six different types of honeypots. No one honeypot is better then the other, each one has its advantages and disadvantages, it all depends on what you are trying to achieve. To more easily define the capabilities of honeypots, we have categorized them based on their level of interaction. The greater interaction an attacker has, the more we can learn, but the greater the risk. For example, BOF and Specter represent low interactions honeypots. They are easy to deploy and have minimal risk. However, they are limited to emulating specific services and operatings systems, used primarily for detection. Mantrap and Honeynets represent mid-to-high interaction honeypots. They can give far greater depth of information, however more work and greater risk is involved.

Legal Issues
No discussion about honeypots would be complete without covering the legal issues. Honeypots are just too cool not to have some legal issues. I am not a laywer. I have no real legal training or background. In fact, I was a History major at college, and not a very good one at that. So what I'm about to discuss are my own opinions, and not based on any legal precedent. When discussing honeypots, there are often two legal issues; entrapment and privacy. We will briefly review these issues. Lets start first with the issue of entrapment. The legal definition of entrapment is

A person is 'entrapped' when he is induced or persuaded by law enforcement officers or their agents to commit a crime that he had no previous intent to commit.

I personally feel that entrapment is not an issue. First, most individuals or organizations are not law enforcement, nor agents of law enforcement. We are not acting under the control of law enforcement, and we don't even have prosecution as an intent. Therefore, the legal definition of entrapment does not apply. Even for law enforcement, honeypots most likely do not represent entrapment, as they are not used to induce nor persuade attackers. Nothing is done to induce or persuade attackers to target Honeypots. Instead, attackers target and attack honeypots are there own initiative. As such, entrapment is most likely not an issue with honeypots technologies.

The next potential issue is privacy, either in the files placed on compromised systems by intruders and the interception of communication (usually IRC) relayed through Honeynets. While there is case law about the loss of the right of privacy in storing files on a stolen computer, or one that an intruder has compromised and is using without the owner's authorization, there is less case law surrounding interception of communication that is relayed through a compromised host. Privacy laws exist in the form of state statutes and federal statutes. State statutes may supersede, or may be superseded by, the federal ones.

At the federal level, the two main statutes concerning communications privacy are the Electronic Communication Privacy Act (18 USC 2701-11), and federal Wiretap Statute (Title III, 18 USC 2510-22). And don't forget that other countries may have similar privacy laws that must be considered if you are implementing honeypots outside the U.S.

The Honeynet Project is attempting to determine what issues exists and how they apply to most organizations today. Until they can establish the legal issues involved, organizations are recommended to review all legal issues with their own legal counsel before proceeding.

A honeypot are just a tool. How you use that tool is up to you. There are a variety of honeypot options, each having different value to organizations. We have categorized two types of honeypots, production and research. Production honeypots help reduce risk in an organization. While they do little for prevention, they can greatly contribute to detection or reaction. Research honeypots are different in that they are not used to protect a specific organization. Instead they are used as a research tool to study and identify the threats in the Internet community. Regardless of what type of honeypot you use, keep in mind the 'level of interaction'. This means that the more your honeypot can do and the more you can learn from it, the more risk that potentially exists. You will have to determine what is the best relationship of risk to capabilities that exist for you. Honeypots will not solve an organization's security problems. Only best practices can do that. However, honeypots may be a tool to help contribute to those best practices. For additional information on honeypot technologies, check out

Author's bio
Lance Spitzner is currently an active member of the Honeynet Project. He enjoys learning by blowing up systems in his home lab. Before this, he was an Tanker in the Rapid Deployment Force, where he blew up things of a different nature. You can reach him at .

Friday, February 24, 2006

Losing Trust In Search Engines

Privacy. It's a pretty simple concept, at least, for an individual. When you get a group of friends together, expecting your comments and actions to remain private is a little tougher to do. But what if one or two of your friends in the group told you that you could count on them to keep your comments secret? You could reasonably believe them, right? Well, if those friends were named Yahoo or Google, then no, you couldn't.

A little background before I get started with the technical data. I run a website called, I still intend to do something with it; most likely online IP tools for forum administrators, but for now the main page is blank. It's been that way since early 2004. At one point in my life, I had no job and thought I could run a little hosting/web design business right out of college. I think we all thought we could do that at some point in our lives, and some of you might do so now. You can see the Wayback Machine Archive of my hosting business here:*/

Oh wait, you can't. Why not? Because I set my robots.txt. It has been specifically set for the last two plus years as disallow all pages according to the W3C standard and even Google's own suggestion. abides by it. At least, for the main site it does.

So who doesn't? You'll actually find a large number of search engines don't...

Complete Article

Tuesday, February 14, 2006

Modifying exe's to dll's for firewall bypass

well, as it's a cloudy sat morning, i might as well do the next installment in this little series on firewall bypass.

let's review what we now know.

We have a exe like explorer.exe which the end user trusts explicitly. If the software firewall tells Mr X that explorer.exe needs to access the internet, the user is unlikely to disagree.

The malicious hacker has a special program called injector.exe that will use the api CreateRemoteThread to force explorer.exe to run the command:


and this will cause explorer.exe to load nasty.dll into it's own memory space and then execute the entry point function DllMain (residing in nasty.dll) passing the parameter DLL_PROCESS_ATTACH to dllmain.

Ok, all good so far, but what use is this to the hacker, if all her backdoors are currently .exe's?

She needs a method of rewriting the backdoor or app as a dll. It turns out this is very simple too...

To understand what needs to be done, we first must understand how DllMain and Main differ...

Here's the prototype for a typical Main:

int main( int argc[ , char *argv[ ]

(sometimes main will not have any parameters)

and here is DllMain:

DWORD fdwReason,
LPVOID lpvReserved

they are quite different and this will cause a slight problem for us. Let's look more closely at DllMain... the only relevant parameter is fdwReason. This specifies why the DllMain is being called. It might be as a response to LoadLibrary == DLL_PROCESS_ATTACH or it could be a response to FreeLibrary == DLL_PROCESS_DETACH. We are only interested in the case DLL_PROCESS_ATTACH.

So how do we proceed... One idea might be to take the source code to an application we want to inject, and change the entry point of the app to DllMain, change the compiler options to compile as a dll and then create our own DllMain that will call the normal main function.

So let's look at a simple app, e.g. the open source ftpd "Indiftpd". This is available for download here:

The method is describ in full at :

Two Way Authentication To Defeat Phishing

Phishing is becoming an increasingly big problem on the net. When the end user receives an email that for all purposes appears genuine and appears to originate from a trusted source, the psychological effect is to lower the levels of suspicion the user would normally have, when asked to provide sensitive information.

There really is very little we can do to stop Phishers from making carbon copies of websites, spoofing email addresses and even buying ssl certificates to make their site appear more genuine.

However, we can beat Phishing through implementing a process of two-way authentication. Under two-way authentiation, the customer is required to prove their identity to the bank's web site and the web site must prove its authenticity to the user. This ensures both parties can be confident that they are dealing with a legitimate source. If all financial institutions adopted this login procedure, phishing could be eliminated within the banking sector.

The method is described in full at:

Saturday, February 11, 2006

Two New Windows Wmf Flaws Found

Microsoft announced on TechNet last night two new flaws in Windows, one in viewing WMF files with older versions (pre 6.0) of Internet Explorer, and a second related to priviledge escalation in Windows XP and 2003 systems without the latest service packs.

The first flaw, which is vulnerable only to Internet Explorer 5.5 and 5.01, uses the now-familiar terminology that it "could allow an attacker to execute arbitrary code on the user's system" when they view a specially-crafted web page or email attachment. On the surface the flaw appears similar to the very critical WMF flaw discovered in late December, but is a different issue.

The second flaw affects only Windows XP SP1 and prior, along with Windows Server 2003 without SP1. Systems with the latest service packs are not vulnerabile. The vulnerability permits priviledge escalation in default Windows services as well as third party applications set with overly permissive access controls.

Patches for these two vulnerabilities are not widely expected until Microsoft's next patching cycle on February 14th.

Source :

I'm In

I'm a new member who just happened to meet the right persons on the net.
well i don't have much to say. Just a thank you to all for doing this owsome work.

Thursday, February 09, 2006

Re: ip address

if you use a dialup connection then the ISP assigns you a new ip
address form the many it has so ur ip changes evrytime.

Re: Anonymity mini HOWTO

too gud stuff. thanks man

ip address

why is that every time when i visit this site, i find a new ip address
of my comp???
somebody help me.
site is :

Wednesday, February 08, 2006

Anonymity mini HOWTO

Disclaimer: I strongly recommend that nobody attempts in anyway to gain
unauthorized access to any sort of computer system, as any kind of
attempt to gain unauthorized access sadly seems to be a serious
criminal offense. I'm in no way responsible for any kinda offence. Its
totally ethical stuff and there's even potential danger that you may
even get logged and even chance to get sniffed. So stay alive. Happy
Hacking :)

Hey fellas don't get annoyed by the disclaimer. It's just a formality
you know rules are always meant to be broken. So today's hot topic is
about how anonymous you are. Let's see what anonymity on web really
mean. In one line its nothing but how deep you can tunnel down the
rabbit hole without being noticed. If you ain't anonymous, may be your
first hack be your last one. Always cover your tracks, it's the basic
thing one should ensure before planning to hack the box. There are
loggers all the way. If you escape you ISP, there are routers waiting
to for your address. For those who are not good at root kits and
burning logs, I guess this could become a useful article. Before that
we just need to know how hackers make out by erasing the tracks. There
are number of compromised systems on internet whose network is named as
Botnet in Hackers Jargon. So when they wish to attack any specific
network with either brute force or just another DDOS, they just pass it
on the automated script on to the botnets for the attack. Burning the
logs is the most important thing that you should be knowing before you
do your first hack. As the topic indicates, it ain't about burning logs
it's about staying anonymous by using third party proxies. I don't
say that even that will provide you 100% anonymity. They log you each
and every click and keystroke for their security purpose. So this is a
mini HOWTO to get the best out of free proxies. First of all secure
spoof your Identity. Use finger print fuckers to erase the OS
fingerprint and the service finger prints from your host box. Then you
need to do is spoof you MAC. It's not a big deal on Linux, you write
a handy script which sets your MAC to some random series every time you
boot. Next thing is getting you job done through some compromised host
or some free anonymous proxies. There is thousands of free proxies out
there from different places on this planet and among them some are
really good and some even provide secured tunnel. Every thing depends
upon your choice. You can get the latest list of hot proxies from n Though it
ain't worked for me as I'm behind another proxy. There are some very
good site through we could tunnel out. Even we have many open source
alternative to tunnel down. I'll be giving you the list of very popular
Anonymous sites that I use. Before that there is some thing that you
should tweak on you host to ensure max anonymity. Before you connect to
internet install some good firewall to monitor every input and output.
I would insist Zone Alarm for window users. After that set you browser
setting to high security level where no ActiveX components, Java
applets, Scripts, Ads and some times even cookies are allowed. All
these settings ensure your anonymity for client side.

So how to ensure about anonymity after connection wid the third party
proxy is established. First thing check out is your IP same or
different from As soon as you confirm that it's
changed then go for IP test and WHOIS lookup. is
very good for going with these steps. If you sure enough that you are
invisible. If you are done with this! Its time to Ragna Rock! Check out
some of my fav anonymous browsing sites. As mentioned earlier never
pass your personal information on these site coz many of them are in
club with hacker's network. Always ensure the line is secured and
encrypted. There even some Hacking client software's which can
automate all the things I mentioned above. But I would rather insist
you to grow up. Script Kiddies need to evolve its time to be a real
hacker. Try to write your own scripts to connect to the proxies.
There's always danger with hack kits that they will be having custom
written Trojans that are undetectable by any spy wares or any
antivirus. Even the topic about how to create a custom Trojans is
pretty interesting. I'll be dealing about that later on. You are behind
proxy I would insist you a quite reliable platform independent software
called JAP. In general it connects with German based proxies. So you
will be on the other side of the globe. One thing I forgot even look
for trace route to ensure how you're routing is done. Get JAP from I guess this
information is enough for any good enough geek to put through. Here the
list of free browser based free proxies

* -It's pretty fast and highly anonymous.

This list goes on n on. You can even find better than these, what all
you need is a better googling. Btw do you want Google to be responsible
for these things there is a simple Google hack, where we can use Google
language translation as free proxy. Just check this link he's is simply exploiting the
feature by translating the page from English to English. Ok buddies my
battery may down any time. Any kinda quires do drop a mail or a
comment. Looking for constructive comments.
Happy Hacking,
--Lunatic 2.0 \m/

Monday, February 06, 2006

Lost Linux Password

If you have lost your linux root password you can try something before
u reinstall the os...

Overview of HTTP Authentication

The HTTP 1.x protocol has a built in mechanism for requiring a valid
username/ password to gain access to web resources. This mechanism is
known as HTTP Authentication and can be initiated by either a CGI
script or by the web server itself.

The overall purpose of this document is to provide the new user with
a common sense definition and understanding of HTTP authentication at
the HTTP Header Level.

There are currently 2 modes of authentication built into HTTP 1.1
termed 'Basic' and 'Digest' Access Authentication.

Basic Authentication transmits the username:password pair in an
form from browser to server and in such should not be used for
logins unless operating over an encrypted medium such as SSL [1].

Digest Authentication sends the server a one way hash of the
pair calculated with a time sensitive, server supplied salt value.

Here a couple definitions are in order:

One way hash:? A mathematical calculation of a string so that no two
can have the same hashed value. The term one way in conjunction
with this signifies that the original string cannot be recovered
from the hashed value by calculation and could only be determined
by brute force comparisons with the hashed values of known strings.

?????? Salt value: The salt value is an arbitrary string of
data generated by the
for the client to included in the hash calculation.

The use of a salt value means that every authentication attempt with
the same username:password pair will result in a unique
hash and is not vulnerable to replay attacks.

The Digest Authentication Mechanism was developed to provide a general
simple implementation, access control that could be used over
channels. Users should note that it is not as secure as Kerberos or
private-key authentication mechanisms. It is also important to note
that only the
username:pasword is protect by the hashing mechanism and that without
the use of
an encrypting medium such as SSL all retrieved documents will still be
to all parties with access to network traffic.

With the terminology and background in place we will now move on to
stepping through an
actual Basic Authentication exchange between Client (Web browser) and

1. Client sends standard HTTP request for resource

GET /download/report.doc HTTP/1.1
Accept: application/msword, */*
Accept-Language: en-us
Accept-Encoding: gzip, deflate
User-Agent: Mozilla/4.0 (compatible; MSIE 5.01; Windows NT 5.0)
Connection: Keep-Alive

2. Server reads configuration files and determines that resource
falls?within a protected directory.

Server can only allow access to known users.

3.?Server Sends HTTP 401 Authorization Required Response

HTTP/1.1 401 Authorization Required
Date: Sat, 20 Oct 2001 19:28:06 GMT
Server: Apache/1.3.19 (Unix)
WWW-Authenticate: Basic realm="File Download Authorization"
Keep-Alive: timeout=15, max=100
Connection: Keep-Alive
Transfer-Encoding: chunked
Content-Type: text/html; charset=iso-8859-1

[ html error page for browser to show if user hits cancel ]

3.?Browser displays Username/ Password prompt displaying host name
and authentication realm.
??? [image auth.jpg]

5.?Client Resubmits Request with Username/ Password

GET /download/report.doc HTTP/1.1
Accept: application/msword, */*
Accept-Language: en-us
Accept-Encoding: gzip, deflate
User-Agent: Mozilla/4.0 (compatible; MSIE 5.01; Windows NT 5.0)
Connection: Keep-Alive
Authorization: Basic ZnJlZDp0aGF0cyBtZQ==

6.?Server compares client information to its user/password list.

a. username : password is valid:? server sends requested content.
b. authorization fails:? server resends 401 Authorization Required
c. Client hits cancel:? browser shows error message sent along with
401 message.

>From the above dialogue you will notice several special fields have
been added to the
various Http headers. In step 3 when the server sends the the 401
response it includes
a special field:

WWW-Authenticate: Basic realm="File Download Authorization"

The value "Basic" denotes that we are requesting the browser to use
Basic Authentication.
The Realm information is an arbitrary string sent to be displayed to
the user commonly
containing a sight message, or feedback. The image in Step 4 shows
Internet Explorer's
HTTP Authorization Dialogue and how it displays the sight and realm
data received. [2]

The user fills in the form and clicks ok. The browser automatically
resends the request
as seen in step 5. Here you will notice a new field has been added to
the standard
http request:

Authorization: Basic ZnJlZDp0aGF0cyBtZQ==

This is where the web browser sends the actual authorization
information to the server.
The Authorization field shown is composed of two values. The word Basic
denotes that
the login is being send in accordance with the Basic Authentication
method. The block
of data that follows that is the actual login as supplied by the
browser. Dont let the
logins appearance fool you. This is not an encryption routine, but a
base 64 transfer

The plain-text Login can be trivially decoded to its underlying
username:password format

ZnJlZDp0aGF0cyBtZQ==?? -> base64Decode() -> "fred:thats me"

The Implementation of the Digest Authentication is exactly the same as
that of the Basic
Authentication process outlined above, the only difference being the
number of arguments
supplied to the Browser and the format of the login returned.

Both Basic and Digest do have respected places in the web developers
toolbox, however
they should not be considered high grade protection for sensitive
or access as they do not address network level attacks. Nevertheless
many functions
remain for which Basic and Digest authentication is both useful and

Wmf Exploit Sold For $4,000

Russian hacker groups sold exploit code for the WMF exploit in early
December, well before vulnerability research companies caught wind of
the problem, mounting evidence is suggesting.

A two-week window separated the development of the exploit and the
discovery of suspicious activity, according to an eWeek article. During
these two weeks the exploit code was available on underground websites
-- at a $4,000 cost.

Details regarding the first release of the exploit are still being
discovered, however the eWeek article mentions an early relationship
with a stock pump-and-dump scheme, where the WMF flaw was used quietly
for quick financial gain.

A BugTraq posting in late December was first to show a website actively
implementing the WMF flaw, and the flurry of activity that followed
sent the security community into overdrive -- over one thousand
malicious WMF files were detected in the days following the post.

Source :

Saturday, February 04, 2006

New Bid To Tackle Spyware Scourge

Five computer security firms are collaborating on a common naming
system for spyware and will co-produce tools to remove the malicious

The initiative hopes to remove some of the current confusion caused by
anti-spyware firms managing their own labelling and removal methods.

The group said collaboration was needed as the amount of spyware in
circulation was rising by 50-100% per year.

The initiative will see ICSA Labs, McAfee, Symantec, Thompson Cyber
Security Labs and Trend Micro join forces to tackle spyware.

Thursday, February 02, 2006

Armoring Solaris

By Lance Spitzner
Preparing Solaris 8 64-bit for CheckPoint FireWall-1 NG
Lance Spitzner
Last Modified: 20 July, 2002

Firewalls are one of the fastest growing technical tools in the field of information security. However, a firewall is only as secure as the operating system it resides upon. This article is a continuation of the original Armoring Solaris article, focusing on building a minimized Solaris 8 64-bit for CheckPoint FW-1 NG firewall. This article does not include an updated script for the automated securing of the new installation, as there was in Armoring Solaris. Instead, we will be using Solaris Security Toolkit (JASS). This is a new tool developed and released by Sun for the secure deployment of the Solaris platform. In otherwords, I'm not going to develop a tool to automate the secure build since that tool is already out there.

The best place to start in armoring your system is at the beginning, OS installation. Since this is your firewall, you cannot trust any previous installations. You want to start with a clean installation, where you can guarantee the system integrity. Place your system in an isolated network. At no time do you want to connect your unprotected system to an active network nor the Internet, exposing the system to a possible compromise. I personally witnessed a newly installed system probed, scanned and exploited within 15 minutes of connecting to the Internet. To get critical files and patches later, you will need a second box that acts as a go between. This second box will download files from the Internet, then connect to your isolated, configuration "network" to transfer critical files.

Once you have placed your future firewall box in an isolated network, you are ready to begin. The first step is selecting what OS package to load. The idea is to load the minimum installation, while maintaining maximum efficiency. The less software that resides on the box, the fewer potential security exploits or holes. I recommend Core installation. I prefer Core because this is the absolute miminum installation, creating a more secure operating system. However, packages can even be removed from a Core installation, creating a more secure platform for our firewall. Note: the package listing below is based on a Core installation using Solaris 8 distribution 04/01, which automatically includes 64-bit support with the Core installation. Regardless of which release of Solaris 8 you use, you want to have the same number of packages at the end. The installation was done on a Ultra5 sun4u with a single quad-ethernet card.

Listing of 83 packages for Core installation with 64-bit OS support.
Listing of 58 packages that are NOT required and can be removed.
Listing of 5 packages required for FW-1 NG support.
Listing of 30 total packages your installation should look like.
Listing of optional packages you may want to add to your firewall.
If you require a GUI, need additional functionality, or are new to Solaris, then you may want to consider the End User installation. Be aware, using End User installation does add almost 100 additional packages, exposing the system to far greater risk, so use Core installation whenever possible. Anything above the End User package, such as Developer, is adding useless but potentially exploitable software. For more information on building a minimal installation, refer to Solaris Minimization for Security.

Partitioning and Patching
During the installation process, you will be asked to partition your system. Partitioning helps security in two ways. First, you can protect critical patitions, such as '/' partition, from filling up by creating seperate patitions for logging and mail. Second, partitioning allows you to restrict which partitions have which capabilities, such as making the '/usr' partition, for all the system binaries, read only.

Therefore, I recommend a separate partition for both "/var" and "/usr". "/var" is where all the system and firewall logging and email spoolling goes. By isolating the /var partition, you protect your root partition from overfilling. By isoloating the /usr partition, we can create this read-only, helping to protect system binaries from modification or potential remote exploit. You may want to consider an seperate partition for "/opt' also, as this is where the FW-1 NG binaries will be located.

Firewall-1 NG logs and configuration files are located in "/var/opt/CPfw1-50". Most Solaris systems have two or more drives, such as the Ultra 10 or 2 IDE drives for an x86. If you are not mirroring the second drive, dedicate the drive for all the firewall logs and configs. Once again, this protects all the other partitions from filling up. With such a setup, a 20GB hard drive and 128MB of RAM could look as follows:

/ - everything else
swap - 256MB (or traditionally 2x amount of RAM)
/var - 400MB
/var/opt/CPfw1-50 - 15GB or 2nd drive
/usr - 500MB (if you want seperate ReadOnly partition).

Once the system has rebooted after the installation, be sure to install the Recommended and Security patch cluster from Sun. Also, FW-1 NG requires two additional patches that are not part of the cluster, specifically 108434-02 and 108435-02. You will have to download and install these patches in addition to the patch cluster. Be sure to use your go between box to get the patches, the firewall box should always remain on an isolated network. Patches are CRITICAL to maintaining a secure firewall and should be updated at least once a week. maintains an excellent vulnerability database.

Securing the System
In the original paper Armoring Solaris, I went into detail on how your Solaris system should be properly secured. In this paper I will not attempt to do that. Security engineers from Sun Microsystems have released an excellent series of papers (called the Blueprint series) which document in far better detail how to properly secure your Solaris system. I refer you to these excellent documents to learn more about securing Solaris. The Solaris Security blueprint series can be found online at In the original paper Armoring Solaris, I supplied a script that automated the armoring process of your Solaris system. Once again, I have chosen not to include such a script with this documents. Security engineers from Sun Microsystems Alex Noordergraaf and Glenn Brunette have developed a tool that automates the secure build process. The tool, called Solaris Security Toolkit (JASS), can be used to secure a system while you build it using Jumpstart, or can secure a system that is already installed. I highly recommend this tool, especially if you will be building multiple systems. JASS requires several configuration files to customize your system builds. I have included such a configuration file, called firewall.profile that can be used to customize the firewall builds. This configuration files specifices how your system is built, including what packages are added (as discussed earlier) and the partitioning table. I have also included a minimimize-firewall.fin Finish script which is used to remove all of the unecessary packages from your core installation. Both the firewall.profile and the minimize-firewall.fin Finsih script are the only two customzied files you will need for JASS to build and secure your Solaris 8 system for a CheckPoint FW-1 NG installation.

The purpose of this paper was to detail how to build a minimized, secured Solaris 8 64-bit platform for a CheckPoint FW-1 NG installation. We focused specifically on the minimal amount of packages and system partitioning required for a successful installation. This article did NOT include a step-by-step armoring process, as Sun Microsystems has released the Blueprint Series. Also, this article did NOT include a toolkit to automate the secure build process, as the tool JASS already has this functionality. However, this article does include two customized JASS configuration files to assist you in building your secured system. It is hoped that this article has helped you build the most secure system possible.

Author's bio
Lance Spitzner is currently an active member of the Honeynet Project. He enjoys learning by blowing up systems in his home lab. Before this, he was an Tanker in the Rapid Deployment Force, where he blew up things of a different nature. You can reach him at .

Wednesday, February 01, 2006

Nmap 4.00 With Fyodor

After more than eight years since its first release in Phrack magazine,
Fyodor has announced Nmap 4.00. Curious as usual, Federico Biancuzzi
interviewed Fyodor on behalf of SecurityFocus to discuss the new port
scanning engine, version detection improvements, and the new stack
fingerprinting algorithm under work by the community.

Could you introduce yourself?

Fyodor: I'm a long-time network security enthusiast with a particular
interest in full disclosure and the offensive side of security. I have
gained a lot from the security community over the years, and try to
contribute back by releasing free tools such as my Nmap Security
Scanner and publishing useful content on my websites, Insecure.Org and
Seclists.Org. I am also an active member of the Honeynet Project.
Writing has been a major recent focus of mine. Last year I co-authored
a technical security novel named Stealing the Network: How to Own a
Continent, and I'm almost finished with a network scanning book. This
is all on top of my active and varied social life. OK, I'm just kidding
about that last part. smile.gif

You just released Nmap 4.00 after two years of work since 3.50. What
are the most exciting changes?

Fyodor: Well, the Changelog shows more than 230 improvements since that
release, so it is hard to choose just a few favorites. But some really
do stand out. The port scanning engine has been rewritten to be much
faster and (after the "diet Nmap" project) more memory efficient. The
low-level packet sending subsystem has changed dramatically as well.
Nmap can now send and route raw Ethernet frames rather than rely on the
host's raw sockets implementation. This is critical for Windows, since
Microsoft disabled raw sockets as of Windows XP SP2. And all platforms
benefit from the new ARP scanning and MAC address spoofing
functionality that this change allows.

Nmap 4.0 has new, better organized and more comprehensive
documentation, including a rewritten man page available in seven
languages. Huge improvements have also been made in version detection,
which offers many new features and saw its signature database triple in

Many Nmap users pick runtime interaction as their favorite new feature.
If you find yourself staring at the screen wondering when Nmap will
finish, just press [enter] for an estimate. If you forgot to enable
verbose mode, press 'v' to enable it. Or press 'V' to turn it off.
Packet tracing and debugging can be enabled or disabled on a whim as

for the rest of the interview, head over to ::

Re: This Is Amazing

Well its not legal now but it may be once the FCC approves it. As of
now only federal agencies can spy on you legally:P

Re: This Is Amazing

Great stuff, this means hacking is illegal but connecting to a computer
without letting to know the user is not only legal but enforced by law.
What a strange world...

Writing "hacker" Tools And Exploits Could Be Illegal In The Uk

"Proposed changes to the Police and Justice bill would make it an
offense to make, adapt, supply, or offer to supply any article which is
designed or adapted to impair the operation of a computer, prevent or
hinder access to a computer, or impair the operation of any program or
access to any data."

Hell, you don't even have to write anything. If you know what it
is/does, you could be found guilty!

"knowing that it is designed or adapted for use in the course of or in
connection with an offence under section 1 or 3"

Spooky stuff there kids.