Source Code:
peludo-cachicamo-v1.0.0.tar.gz
SHA1: 819f70a7f026119b792db3ca29782feafb172a0c

Binary Package for Linux/x86 host:
peludo-cachicamo-v1.0.0-bin-linux-x86.tbz
SHA1: da33da3898800855101f20f87471719377e4a49d

To install just enter:
$ sudo tar jxf peludo-cachicamo-v1.0.0-bin-linux-x86.tbz -C /

Binary Package for FreeBSD/amd64 host:
peludo-cachicamo-v1.0.0-bin-freebsd-amd64.tbz
SHA1: 80f700f8e38d05270273c6f69eee6635db5ae634

To install just enter:
$ sudo tar jxf peludo-cachicamo-v1.0.0-bin-freebsd-amd64.tbz -C /

Running it:
Every time you want to use the Peludo toolchain you should set the environment:
$ . /usr/local/peludo/setenv

Do not forget to check the examples, in particular the injectable extensible shell server:
$ cd /usr/local/peludo/examples/esh

Download and try it!

The source code is fully documented and the package includes sample code and a detailed description of the system.

The two main things we’re going to demonstrate are geographical visualization and the netifera probe which is a deployable software agent that makes it possible to run all netifera platform tools remotely as easily as running them locally.

We’re going to install the probe on the netifera.com webserver, and we’ll deploy it like shellcode by injecting it directly into memory over the network, using an exploit.

http://netifera.com/doc/netifera_tutorial_sniffing_module_part1/

If you have the first beta installed, you must delete the entire directory (or move it out of the way) before installing this version.

Change log

• Improved the output of several tools
• Web spider: fixed a number of important bugs, improved detection of several web applications.
• TCP connect scanner: better handling of the case of the server response arriving in two fragments separated by a small delay, don’t miss the last piece of data
• Improved detection of FTP, SMTP, and other services. Fixed some service miss-detections
• UDP scanner: added a delay between sending packets, improved to better use the asynchronous socket engine
• Removed some actions from targets that don’t make sense, such as “geo-localize” for private addresses.
• Better handling of host names with multiple addresses and addresses with multiple names.
• Added an “architecture” attribute to host entities, in addition to the “os” attribute.
• Improved service detection to set the architecture when it can be known, and also to detect Linux distributions
• Distinguish multiple clients of the same service in a single host, for example represent Firefox and apt-get as two different HTTP clients that can simultaneously exist in a single host
• Open all perspectives at startup, so that both sniffing and tools perspectives are easily switched with buttons that appear in the toolbar
• Improved the sniffing API and documentation of the API
• Added the memory monitor to the status bar to help debugging memory leaks
• Added system information (os, architecture, etc) to services and clients, show OS icon decoration in services and clients too

We deliberately chose that name to draw attention to the fact that if you install this feature correctly you will be creating a security vulnerability on your system: Anybody who can execute the backdoor binary will be able to capture and send raw network packets.  We think this risk is minor and acceptable considering that it makes netifera much simpler to launch and use, but it’s disabled by default and should not be enabled without understanding the implications.

We’ll explain all the details of why it exists and how it works, and how large of a security hole it creates so you can decide for yourself if you want to use it or not.

Why do we need it?

Netifera includes functionality which captures network traffic and parses it for interesting information.  On the platforms we currently support (Linux and Mac OS X), special privileges are required to open a network interface and capture packets.

On Linux to capture packets you need to open a special type of socket with the socket system call.  A regular user process cannot access these sockets without elevated privileges:

‘Only processes with effective UID 0 or the CAP_NET_RAW capability may open packet sockets.’

Mac OS X provides the standard BSD interface for capturing packets through a set of devices in the /dev directory:

$ ls -l /dev/bpf*
crw-------  1 root  wheel   23,   0 Nov 23 10:45 /dev/bpf0
crw-------  1 root  wheel   23,   1 Nov 23 11:14 /dev/bpf1
crw-------  1 root  wheel   23,   2 Nov 21 16:52 /dev/bpf2
crw-------  1 root  wheel   23,   3 Nov 21 16:52 /dev/bpf3

Access to these devices is controlled with filesystem permissions and in a typical configuration only the superuser will have permission to open BPF devices.

On both Linux and OS X the problem is the same: We need to access a privileged operating system resource from a regular user process.

How does it work?

Our pcap implementation

When we started implementing sniffing in netifera we didn’t find a useful java library for capturing packets.  We decided to write our own by implementing libpcap in java.  Our version is somewhere between a port of libpcap into java, and a new implementation.  We copied the exact logic for opening capture devices because libpcap covers a lot of special cases and subtleties.  Since java does not directly provide access to the necessary system calls, we use a small (about 300 lines of C code) Java Native Interface library to invoke the raw system calls needed to implement the pcap library.

Backdoor

When netifera attempts to open a network interface for capture, it will fail unless netifera is running as root.  If the attempt fails because of a permission error, netifera will attempt to us the backdoor executable if it is available and installed as setuid root.

The native library executes and communicates with the backdoor binary.

1. The JNI library (libsystem.so) creates a pair of Unix domain sockets with socketpair() and executes the backdoor binary with one side of the socket pair bound to file descriptor 0.
2. The backdoor binary opens an instance of the privileged resource and obtains a file descriptor.
3. The backdoor passes the file descriptor to netifera using a Unix feature for passing file descriptors between processes over a local socket, and then exits.

What are the alternatives?

Always run netifera as root

If netifera is executed as root, then there is no problem to solve since the root user can always open the sockets or devices needed for capturing packets.  We don’t think it’s reasonable to require our users to always run netifera as root, especially considering that we are expecting our users to be very security conscious.

If you prefer to not install the backdoor binary, this is an option that can be used to access sniffing functionality in netifera.

Doesn’t the desktop environment already provide a solution to this problem?

Linux has various graphical wrappers for the sudo and su utilities and Mac OS X has something called Authorization Services.  On both operating systems this can be used to launch an application with root privileges after prompting the user for a password.  So, this would be an easy way to have netifera always launched as the root user.  We are not going to install netifera this way and we don’t recommend that you do it either.  Typing your root password into an arbitrary UI dialog just because it popped up and asked for it makes us a little bit uncomfortable.

An idea for the future

Recently we’ve been discussing a new possible solution to authenticate requests to the backdoor binary.  The way it would work is that the user would choose a password when upon installation which would be hashed and stored in a file owned and readable only by root.  The netifera user interface would prompt the user for this password and send it in requests over the socket it shares with the backdoor utility.  The backdoor executable would use the setuid root privileges to read the password from the file and authenticate the request.

Conclusion

If you install the backdoor binary with setuid privileges you will be able to sniff packets in netifera without needing to run the entire application as root.  The downside is that anybody else who can execute the backdoor binary can also use it to open network devices for sniffing.

Please let us know if you have some idea for solving this problem that we have not thought of, and if it makes sense we’ll implement it.

We’ve received good feedback from the attendees, encouragement and cool ideas. We are really enjoying our stay, thanks a lot to the organizers for their hard work!

Ok, bye, we’re going to karaoke.