Even though the aim of the project is to help NRENs and ISPs companies, feedback from them is crucial, since the main attacks committed through their networks. Using NoAH system can help detect, monitor and report suspect activities in real-time.

NoAH system main features:

• Provide source of data for security analysis.
• Produce attacks signatures for further use (integration with IDS, firewalls and other network protection tools).
• It has few false positives, low cost and low risk.
• It does not capture legitimate users traffic (No sensitive data).
• Help the security teams understand the threats they face and how to defend against them.
• Raw data available for the administrators.
• Easy to adapt new honeypots on the company’s network.
• Open-source software.
• Contribute to a large network of Honeypots.

The opening presentation by Spiros Antonatos (FORTH) focused on honey@home, an application developed by the NoAH project that can be installed on a Windows or Linux PC. The application allocates an unused IP address in order to collect information about potential cyberattacks; forwarding it to a remote NoAH honeypot for further analysis. As a result, the geographical coverage of the NoAH infrastructure is greatly extended.

The second presentation by Stefano Zanero (Politecnico di Milano) examined the usefulness of intrusion detection systems (IDS) compared with honeypots. Whereas a honeypot actually needs to be comprised in order to be useful, an IDS is able to detect security violations on any system. This in principle allows better collection of attack data, and this can be taken a step further to develop anomaly detection systems, which learn by contrast with normality.

The third presentation by Pascal Gamper (ETHZ) focused on improved methods for signatures for generating zero-day attacks. Time is critical when dealing with such attacks, which means fast automated methods are necessary if they are to be useful in IDSs.

There then followed an talk by Melanie Rieback (VU) on the issues related to RFID (Radio Frequency Identity) technology. This provided an interesting historical overview about the development of the technology, but also the security issues and concerns that it currently presented.

It was then back to more NoAH developments, with a presentation from Asia Slowinska (VU) on the Argos secure system emulator that provides a secure containment environment for running a honeypot system. Whenever potential malicious use is detected, the unsafe data is saved for off-line processing and the emulator terminates its execution. The aim is to prevent the honeypot systems from themselves being compromised, and to ensure that early-warning information can be forwarded to other systems.

The final presentation was given by Marc Dacier (Symantec) on the Leurré.com distributed honeynet. This is a network of low interaction honeypots based on the honeyd software. Currently there are around 50 platforms deployed in 30 countries around the globe. The software can be installed on a low-specification PC from a CD available from Eurecom, and also provides access to the entire SQL database of collected traffic traces. In fact, the success of the system in collecting useful data, encouraged the establishment of the three-year EC-funded WOMBAT project to establish a worldwide observatory of malicious behaviours and attack threats.

The feedback received about the workshop was very positive, and the speakers were highly rated by those attendees completing feedback forms. The presentations from the workshop are available online from the NoAH website.

• The attacker connected from 80.60.158.116 to our win2k server honeypot.
• Aim was to exploit a vulnerability in the WINS service at port 42.
• Date was 2nd June 2008 18:45 GMT +0200.
• The attack was not detected by the snort IDS.
• Argos raised an alert of type “RET”.
• The EBP contained the value 0×90909090 which results obviously from a stack buffer overflow. Thus, a false positive can be excluded.

Analysis of the attack

First step in my analysis was to find all known vulnerabilities/advisories affecting this service. The search results in the Microsoft advisory MS04-045. A more detailed explanation has been published by immunitysec.com. This seems to be the only severe vulnerability in this service. In addition, multiple exploits exist targeting at this vulnerability.

The first look at the packet dump of the attack using wireshark reveals that according to the MS advisory the WINS replication service was attacked. The first three 4-Byte words in the tcpstream of the attack correspond to the “packet” as referenced by immunitysec: “size of packet” “XX XX FF XX”, and “real address pointer”. The vulnerability exists because the “real address pointer” can be manipulated by the attacker and user data is subsequently written to this location. In our Argos CSI data it points at a memory location which is marked as tainted. Thus, the behavior of the exploit is consistent with the description of the vulnerability.

Attack verification

To verify that the vulnerability attacked is the one found by immunitysec.com I tested the corresponding exploit in the metasploit suite against our honeypot and compared both results. The comparison with the traces of the real attack was surprising. First, the payload size of the attack was much smaller than the size of the metasploit attack. Moreover, the three bytes that are characteristic for the exploitation of the vulnerability are different.  They start at the memory location 0000002d: packet lenght: 0×208, “00 00 78 00″, “05 37 1e 90″. Thus, the critical Byte “FF” in the second word is missing as seen in the metasploit attack. Moreover, the bytes at the address 0×05371e90 do not seem to be tainted which is in contrast to the metasploit attack. Thus, I am confident that this vulnerability is definitely not the one published by immunitysec. Further analysis of this attack will follow.

Screenshots

Packet dump of the attack

TCP stream data of the attack payload

TCP stream data of the metasploit attack data

The application is available from the Honey@home website. Continue reading for more details on the new features.

List of improvements

The new version offers numerous improvements over the previous releases:

1. Installation: The Honey@home installer now uses the Microsoft Windows Installer engine. This enables the installer to update existing Honey@home installations, without the user having to uninstall and then reinstall the software.

2. Integrated update mechanism: The software is now capable of identifying when a new version comes out on the Honey@home website. The new version is downloaded as an MSI archive and the software is automatically updated.

3. Registration wizard: The user no longer has to launch a browser to register his Honey@home client. If after the installation it is identified that the software hasn’t been registered, a registration wizard is started and the user is able to register his client without switching to a different application.

4. Settings Manager: No longer has the user to manually edit the configuration files of the software. Now all required changes to the configuration are made through the Honey@home settings manager GUI.

5. Anonymous Routing: The software now includes the components required to route the traffic it captures over TOR. This enhances the overall security of the NoAH infrastructure, as well as the privacy of the user.

6. Improved Visualization: Honey@home now offers three different charts and graphs. The first one is a pie-chart breakdown of the packets received per protocol (TCP, UDP, ICMP, Other). The second is a speed graph which shows the rate at which traffic is captured and injected. The last one shows the TCP and UDP ports that received the most traffic.

7. Misc. Improvements: The new version has a reduced memory footprint. Also it provides novice users with a recommendation for which of the existing network interfaces is suitable for the software.

Screenshots

Network interface recommendation at startup

Honey@home settings manager

Breakdown chart of received traffic per protocol

Traffic rate graph

Top ports graph

Despite all of the attractive properties of Argos and the various signature generators, we are still missing some attacks: those on the client-side. Honeypots have as a disadvantage that they mostly act like servers and wait for attackers to contact them. However, client-side attacks are on the rise. In such attacks, the client visits a malicious website and is infected by the content. Honeypots never see such attacks.

Moreover, the Argos honeypot only protects the exact configuration that it is actually running on top of its emulator. If the production machines have a slightly different configuration (e.g., a different version of the OS, applications, or plugins), Argos may miss attacks. So, ideally we would like to protect the `real’ machines.

In the Eudaemon project, some of the groundwork is done for implementing techniques to bring Argos-like honeypot technology to the desktop of normal users. In other words: client-side protection. This is a major challenge as the emulator that implements all the required instrumentation to detect attacks incurs a slowdown of a factor 15-20. As a result, running a desktop PC in instrumented mode constantly is probably not acceptable.

Instead, the idea is to take over running processes and force them to continue running in honeypot mode when needed or when possible. For instance, in the former case one may run a browser in honeypot mode when we click on an unknown URL in an email message. The browser is then protected against browser attacks by malicious server content. In the latter case, one may switch all of the user’s networking applications to honeypot mode when the machine is idle. For instance, we may switch to honeypot mode as a screensaver.

The mechanism for doing this is described in the Eudaemon paper presented at EUROSYS 2008 in Glasgow. [bibtex]

The innovative concept of NoAH Router allows to detect suspicious flows that are currently not seen by the existing Honeypots. Being installed on a router installed at the heart of the Internet, it can identify and redirect flows coming from scanning bots even if the targeted machines are not under monitoring.

During the next phase, the capacity of the NoAH Router for preventing zero-day attacks will be evaluated in a live environment. Keep an eye on the blog for further updates on the NoAH router.

For more information on NoAHDB tool please visit NoAHDB homepage.

For more information on NOAHIF please visit NOAHIF homepage.

Some useful changes follow:

version 0.9.1:

• TFTP booting from host directory (Anthony Liguori, Erwan Velu)
• Tap device emulation for Solaris (Sittichai Palanisong)
• Monitor multiplexing to several I/O channels (Jason Wessel)
• CPU model selection support (J. Mayer, Paul Brook, Herve Poussineau)
• Read-only support for Parallels disk images (Alex Beregszaszi)
• SVM (x86 virtualization) support (Alexander Graf)
• Intel mainstone II board emulation (Armin Kuster)
• VMware SVGA II graphics card support (Andrzej Zaborowski)

version 0.9.0:

• Support for relative paths in backing files for disk images
• Async file I/O API
• New qcow2 disk image format
• Support of multiple VM snapshots
• Linux: specific host CDROM and floppy support
• SMM support
• Moved PCI init, MP table init and ACPI table init to Bochs BIOS
• several x86 and x86_64 emulation fixes
• Mouse relative offset VNC extension (Anthony Liguori)
• PXE boot support (Anthony Liguori)
• ‘-daemonize’ option (Anthony Liguori)

Additional changes, besides the port, include a double taintness check before executing a part of code to ensure attackers’ injected code is always detected at the moment it is first executed. The check is performed whenever a TB is scheduled to be executed, as well as within the translated code whenever EIP is modified. This is to cover TB chaining performed by QEMU to speed up emulation. In the future we might consider disabling chaining, if a single check offers a significant performance gain.

For more information on Argos visit: http://www.few.vu.nl/argos