PhxBUG - Phoenix BSD User Group

Insufficient validation in vga(4) may allow an attacker to gain root privileges if the kernel is compiled with option PCIAGP and the actual device is not an AGP device. The PCIAGP option is present by default on i386 kernels only.

This is also OpenBSD 3.9 Errata #17

Introduction

What is a honeypot?

In information security, any closely-monitored device or application designed with the purpose of drawing attacks. They typically have no production value; a honeypot that is successfully attacked and compromised results in no loss of critical services, and should disclose no important information to an attacker.

What is the purpose of a honeypot?

Honeypots have a number of uses:

• Distract attackers from truly valuable systems or applications on the network.
• Provide insight into attacker methodologies. In other words, a honeypot can serve to answer the question, "How can we defend against an enemy, when we don’ t even know who the enemy is?"
• Assist in development of IDS signatures and collection of malware, exploits, tools, etc.

Honeypot Flavors

The community breaks honeypots down into 2 main kinds.

• Low-interaction - Emulates services, applications, and operating system interfaces, presenting the illusion of a target system to an attacker while only exposing a pseudo service to them. Tend to be low risk, easy to deploy/maintain, but capture limited information. A honeypot software application such as honeyd is an example of a low-interaction honeypot.
• High-interaction (research) - Usually consist of real services, applications, and operating system installations. Designed to capture extensive information, but higher risk and high maintenance. A full-fledged Windows XP installation on a physical or virtual machine is an example of a high-interaction honeypot.

Honeynets

Information has different value to different organizations. Some organizations want to deploy honeypots to identify infected or compromised systems on their internal network. Others want to identify snooping employees, looking for data they shouldn't. Others, such as ISPs, want to identify both nefarious customer activity and see what threats target them from the Internet. The ability to gather information is critical, and a honeypot that doesn't help you get valuable information to suit your purposes is just a sacrificial box.

Another flavor of honeypot (or concept related to honeypots) are the high-interaction honeypot collections designed to capture in-depth information, referred to as honeynets. A honeynet is a honeypot architecture you populate with live systems, not a product or software. Any traffic entering or leaving the honeynet architecture is destined to one or more honeypots, never to legitimate systems, and is therefore always suspect.

As noted, the key value to a honeynet is in being an architecture, not a product. There are several aspects of the honeynet architecture that lend value to the framework and analysis capabilities it provides.

• Control - better grasp on controlling our ins and our outs (packet filtering, scrubbing, and traffic policies.)
• Transparency - utilize bridging for isolation, rather than routing; honeypots can blend in with other legitimate systems, utilizing contiguous address space.
• Analysis - information gathering is enhanced through formalized structures for logging, alerting, and analysis consoles.
• Flexibility - One strength of the honeynet architecture is that honeypots are up to the implementor. They can be high- or low-interaction, any quantity, any flavor, any patchlevel, any operating system, and present any services to attackers.

The Honeynet Project CDROM

http://www.honeynet.org/tools/cdrom/

The Honeynet Project produces a free Linux distribution for the purpose of creating honeynet architectures. Their CDROM is currently based off of Fedora Core 3 and provides the role of a honeywall in the architecture. The honeywall has (at least) 3 network interfaces; 2 interfaces configured in a bridge, giving an inlet and outlet into the honeynet architecture, and a third interface to function as a management interface (the only one that has IP connectivity for remote administration.)

The distribution neatly integrates several components to form the core network flow controls at the honeywall:

• iptables firewall to apply filtering policies
• snort_inline to provide IDS/IPS capabilities

The honeywall serves as the core analysis system in the honeynet, as well. The core analysis utility on the system is Walleye, a web-based analysis console.

In Walleye, you can:

• View and analyze IDS events
• Review network flow data
• View captured packet data

Since any network traffic seen on the honeynet is illegitimate, it is important to be able to account for the traffic and analyze it. Walleye makes it easy to do this.

Honeynets and BSD

If the Honeynet CDROM is Linux-based, what does any of this have to do with BSD?

Although the core component of the honeynet (the honeywall) is Linux-based, you can still play off of the strengths that BSD has in any environment.

• Highly secure
• Stable
• Infrequently targeted by common attack vectors

So this means that you can integrate one or more BSD systems into your honeynet architecture as honeypots which perform specialized tasks:

1. Make it a honeypot and a target for attackers.
2. Use it in an analysis role.

In the first point, you can approach using BSD as a honeypot in a number of ways. BSD can be used to host several of the low-interaction honeypots (such as honeyd), which means it fits neatly into the architecture.

As for the second point, there are many ways you can do this. One is to establish a system of network-based syslog services within the honeynet. All honeypot systems should have some native event or system logging function which logs to the local system. A common attempt to cover an attacker's tracks on a compromised system is to erase or alter the logs on the system. Although an attacker can cover their tracks locally on a compromised honeypot system, it can be made more difficult if those logs are also sent to a remote system too. Configure the honeypots to send syslog data to a hardened and well-maintained BSD syslog server.

Another function that your BSD boxes can perform in a honeypot analysis role is that of centralized host integrity checking. Using Osiris or similar host integrity checkers on the honeypots, we can monitor for unapproved changes to our honeypots; file additions, deletions and modifications; user and group modifications, changes in listening network ports and so on. Using a hardened BSD host to run the centralized osirismd console means that this information is communicated to and stored on a system where it can be preserved, even if the compromised system is destroyed.

Yet another capability of a BSD system in the honeynet is that of a central event processing and alerting function. Using a utility such as SEC or swatch to parse out syslog events received by the system and respond to them in an automated manner lends a sense of automation to the analysis process. Coupled with some custom scripts to handle things like sending email to the honeynet analyst and restoring system configurations to defaults can help provide useful capabilities to the honeynet architecture.

It should be noted that you will probably want to give this box a separate management interface from which to deliver SMTP alerts and perform other alerting. While network activity on the interface that connects to the honeynet architecture will be visible to an attacker who has a presence on that segment, using a different network interface on the BSD systems will allow you to perform network transactions unbeknownst to the attacker.

Finally, the uses of the BSD system in the honeynet architecture will in theory make it an attractive target to attackers on the honeynet. While they may be able to disable local logging, alerting, and security functions on the honeypot systems themselves, they will also likely notice that logs are sent to the BSD system and that Osiris scan results are sent to it. This fact alone may be enough to deter unskilled attackers from continuing their activities as there is obviously an audit trail that they won't be able to disrupt. On the other hand, it is likely that this will present a new challenge for more skilled attackers to take on:

• They can't wipe tracks without breaking into this box.
• They can't disrupt messaging/alerting without taking this box down.

The possibility then is that more talented attackers will now target the BSD system in an attempt to fully cover their tracks. At this point, you might be able to acquire some useful information about the attacker. If an attacker has a remote repository of tools and connects out to it through the firewall, you may be able to gather IP addresses, user names and passwords for the attacker's repositories. You may find information about 0-day exploits or tools you didn't know about. If you set the honeynet up in such a way that the BSD box is inaccessible from the Internet (via filtering policies on the honeywall), attackers will be forced to launch their attacks from a system on the inside of the honeywall, meaning you won't see the attacks happening at the honeywall but you are likely to see communications between the honeypot and the Internet. Let the attackers pound away at the system in futility; running an updated OpenBSD host in a hardened configuration should present a challenging target to even highly skilled attackers.

Sample scripts

The following list of files are examples of configurations and scripts that can be used for analysis and alerting on the BSD system.

SEC configuration

The following SEC configuration file can be used to monitor for file alteration events in the default IIS document root directory. This configuration is run against the syslog log file where messages from osirismd are stored.

## Look for modifications to files in the IIS web root on WebServer.
## If detected, send email alert to analyst.
type=Single
ptype=RegExp
pattern=osirismd\[\d+].*\[(WebServer)]\[(cmp|missing|new)].*\\\\wwwroot\\\\.*
desc=The following modification was detected on the host '$1' during a \
routine host integrity check. This suggests an unforeseen change to content \
in the IIS document root, possibly as an attempt to deface a web site.^M^M$0
action=shellcmd /root/response/mail_alert.sh ­-s "Possible defacement, WebServer \ 
honeypot" ­-t '<analyst@example.com>' ­-f '"Honeynet Alerts" \
<noreply@puffy.example.com>' ­-d "<poohbear@example.com>" ­-i %s

SMTP alert script (mail_alert.sh)

The following shell script is called by the above SEC configuration to email an alert to the configured analyst's email address.

#!/bin/sh
# Default envelope recipient
mailrcpt="<soc@example.com>"
# parse script arguments
while getopts "s:t:f:r:d:i:" optchar; do
    case $optchar in
        s)  hdr_subj="${OPTARG}" ;;
        t)  hdr_to="${OPTARG}" ;;
        f)  hdr_from="${OPTARG}" ;;
        r)  env_to="${OPTARG}" ;;
        d)  env_from="${OPTARG}" ;;
        i)  msg_input="${OPTARG}" ;;
    esac
done
shift $(($OPTIND -­ 1))

# If no envelope recipient received as argument, assume default
env_to=${env_to:­${mailrcpt}}
# parsed out information, mail it as instructed:
/usr/sbin/sendmail ­-f ${env_from} ${env_to} <<-­ EOF
    From: ${hdr_from}
    To: ${hdr_to}
    Subject: ${hdr_subj}

    Alert description:

    ${msg_input}
EOF

Honeypot security, legality, privacy issues

Beware of problems a compromised honeypot can bring. In order for the honeypot to be a believable target for attackers, you need some bait. However, don't use what you really don't want someone finding. Watch out for attacks against your organization's public image (e.g. http://www.zone-h.org/). As with any decision that has legal or liability considerations, check with your organization's legal department and applicable management before implementing honeypots. Critical departments in an organization should be aware of their installation and use as well (think IT networking and/or security.)

One of the most frequently asked legal questions is whether a honeypot violates the Wiretap Act. This question has been answered by the the United States Department of Justice, recognizing that a
honeypot can qualify under an Exception to Wiretap Act, the Provider Exception (System Protection) clause. (http://www.honeynet.org/papers/edu/).

The second legal concern frequently raised is the question of entrapment. Given that honeypots are
deployed on networks and no advertisement enticing people to scan and/or break into the honeynet, the case of entrapment has little merit.

A final administrative legal concern is the privacy of data on the network. Information such a credit card numbers, user IDs/passwords, social security numbers, and a myriad of other data could be captured by a honeypot. Proper handling of this data is very important.

Resources

The Honeynet Project

http://www.honeynet.org/

Paper: Use of a Honeynet to Detect Exploited Systems Across Large Enterprise Networks

http://www.tracking-hackers.com/papers/gatech-honeynet.pdf

SEC: Simple Event Correlator

http://www.estpak.ee/~risto/sec/

Osiris: Host Integrity Monitor

http://osiris.shmoo.com/

The third and final article by Daniel Hartmeier, entitled PF: Firewall Management, has been posted to undeadly. A must-read series!

Daniel Hartmeier won't keep you waiting for more. He's already published the second PF installment entitled PF: Testing Your Firewall.

The second chapter, in a series of three, is about troubleshooting PF. Instead of just providing the common symptoms-to-solutions table, it tries to present a systematic procedure for problem analysis. The way is the goal. ;)

Daniel Hartmeier has posted the first of three articles entitled PF: Firewall Ruleset Optimization to undeadly. These are in-depth articles by the original author of PF. Good stuff!