cipherdyne.org

23 August, 2008

Scott Beatty recently prepared a talk about fwknop at the 2008 BARcamp gathering in Chicago. It is nice to see fwknop getting some additional publicity, and Scott emphasizes Single Packet Authorization (SPA) mode communications over the legacy port knocking mode (which often seem to be confused as the same thing). Scott's talk is entitled Protect Your SSH Port (and Others) With fwknop, and has a lot of excellent supporting graphics - including screenshots of both the Nmap cross-platform frontend Zenmap and the fwknop Windows UI in action - to help illustrate authentication concepts and fwknop usage.

From the BARcamp Chicago website: A BARcamp is an ad-hoc gathering born from the desire for people to share and learn in an open environment. It is an intense event with discussions, demos and interaction from participants. The name BARcamp was inspired as a complement to FOOcamp, a private tech gathering run by Tim O'Reilly.

23 July, 2008

This past weekend at the Last HOPE conference in NYC I gave a talk entitled "Port Knocking and Single Packet Authorization: Practical Deployments" (slides). The talk was fairly well attended - I estimate about 100 people or so - and there were several good questions from the audience. Some of the questions deserved a more thorough answer than I was able to provide during the talk, so this blog post fleshes out some of my original answers. If you attended the talk and would like to see more discussion of one of these questions, or if you just have a question about fwknop in general, please email me.

Q: Does fwknop run on the iPhone?
A: Given that the iPhone runs Mac OS X as well as perl, it should be feasible to run fwknop on the iPhone at least as a client. If ipfw is also available for the iPhone and AT&T does not filter inbound connections to servers that are running on an iPhone (I don't personally have one so I have not verified this), then it should also be possible to run the fwknopd daemon to sniff SPA packets.

Q: Why not build a covert channel over bits in the TCP header? Wouldn't this provide a way to implement a more simplistic userspace daemon for parsing inbound traffic?
A: There are certainly a decent number of bits available within the TCP header (and IP header too) that could be used to encode information within a covert channel, but my concern would be that not enough bits would be available to accomplish everything necessary to provide good security. Making such packets non-replayable while offering an encrypted payload at the same time I think would be difficult. That said however, one could envision a hybrid approach where bits are used first within packet headers to "get to the next stage", and this would allow the first stage to be implemented by a simplistic piece of code (such as parsing a firewall log). (This was suggested to me by Jacob Appelbaum at the end of the talk.) Still, there would be a permissions problem on the client side because tweaking bits at this level would mean that one cannot just open a socket and send data - a raw socket would be required.

Q: Have you audited the perl parser code or associated perl modules for security vulnerabilities?
A: Yow, this one was a zinger, and gets to the heart of the code complexity problem. I certainly cannot claim that all of the code used by fwknop is completely secure (no one ever can really for any piece of code), but at least attacking the fwknopd daemon is not as easy as just scanning for some vulnerable piece of software that advertises itself via a TCP socket. I'm working on re-writing fwknop in C though to make it much more lightweight and less complex, and this should help to address concerns about the complexity of perl modules while also allowing fwknopd to run on embedded distributions such as OpenWRT.

Jacob Appelbaum attended the talk, and he asked the later two questions above (which were excellent and thought provoking). Later on Sunday, I spoke briefly with Jacob and during that conversation he suggested sending SPA packets over DNS queries in order to once again return to a log parsing model for SPA instead of requiring a sniffer, and using DNS would also imply compatibility with Tor because it already handles DNS queries. I think this is a great idea, and I have added it to the fwknop TODO list - it will definitely be implemented as an option for fwknop communications.

On another note, Jacob gave a panel discussion on Saturday of the recent Debian OpenSSL vulnerability along with Dino Dai Zovi and Karsten Nohl. Hopefully the video of this talk will be posted online - it was quite excellent and provides perspective on just how damaging a seemingly innocuous and helpful "fix" can have far-reaching implications for computer (in)security. In this case, a Debian developer noticed that valgrind detected the usage of uninitialized memory by the OpenSSL library, and interpreted this as a programming bug that needed to be fixed. It turns out that OpenSSL actually uses uninitialized memory as a way to gather additional entropy during the key generation process, and removing this code had the effect of reducing the security of all keys generated by any application on Debian that used OpenSSL, which is a huge list of applications. We are going to feel the effects of this bug for a long time to come even if every vulnerable system has already been patched because there are a lot of weak keys still in use.

17 March, 2008

At the SOURCE Boston conference in Boston last week I gave talk entitled "Advanced Linux Firewalls" (slides). The conference attendance was good considering that this is the first year the conference was offered, and I look forward to next year. I managed to see a few talks, and two that stood out from the crowd were Roger Dingledine's talk "How To Make Tor Play Well With The Rest Of The Internet", and Andrew Jaquith's talk "Not Dead But Twitching: Anti-Virus Succumbs to the Scourge of Modern Malware". Roger highlighted several technology research and development areas for the Tor project, including the ability to use UDP instead of TCP for Tor virtual circuits. This is of particular interest to me, since it would mean that SPA packets could be routed over the Tor network without having to resort to the establishment of full TCP connections (which breaks the "single packet" part of "SPA"). Andrew gave some interesting perspectives on malware trends, including the fact that malware over time is becoming more targeted while at the same time exhibiting high variability. The end result is that malware authors are able to attack the weakest link in the creation of signatures for malware detection - the people that reverse engineer malware. Because human resources are scarce and slow when it comes to reverse engineering (there is no fully automated mechanism for this yet), malware authors are able to essentially perpetrate a DoS against vendors that offer malware detection.

12 March, 2008

Today at the SOURCE Boston computer security conference I will give a talk entitled "Advanced Linux Firewalls" in which I will present many of the themes I discuss in my book published late last year by No Starch Press. This talk will also launch the 1.9.2 release of fwknop, and present several new features such as client-derived access timeouts, the ability to select any of several digest algorithms (SHA-256, SHA-1, or MD5) for replay attack detection, the removal of the Salted__ prefix in SPA packets encrypted with Rijndael, and blacklist IP exclusions for incoming SPA packets. Many of these features were implemented by the SPAPICT team as well as several other contributors, and I wish to thank all who participated in the fwknop development process.

      You can download fwknop-1.9.2 here, and for those interested in the changes in the fwknop-1.9.2 release, here is the complete ChangeLog:

• Crypt::CBC adds the string "Salted__" to the beginning of the encrypted text (at least for how fwknop interfaces with Crypt::CBC), so the fwknop client was updated to delete the encoded version of this string "U2FsdGVkX1" before sending a Rijndael-encrypted SPA packet on the wire. The fwknopd server will add this string back in before decrypting. This makes it harder to write an IDS signature that looks for fwknop traffic; e.g. look for the default prefix string "U2FsdGVkX1" over UDP port 62201, which would work for fwknop clients < 1.9.2 (as long as the port number is not changed with --Server-port).
• Added more granular source IP and allowed IP tests so that access to particular internal IP addresses can be excluded in --Forward-access mode. A new keyword "INTERNAL_NET_ACCESS" is now parsed from the access.conf file in order to implemented these restrictions.
• (SPAPICT Group) Added BLACKLIST functionality to allow source IP addresses to easily be excluded from the authentication process.
• (Grant Ferley) Submitted patch to handle SIGCHLD in IPTables::ChainMgr.
• (Grant Ferley) Submitted patch to handle Linux "cooked" interfaces for packet capture (e.g. PPPoE interfaces).
• (SPAPICT Group) Applied modified version of the client-defined access timeout patches submitted by the PICT SPA Group. There are two new message types to facilitate client timeouts; one for normal access mode, and the other for the FORWARD access mode. In the access.conf file, there is also a new variable "PERMIT_CLIENT_TIMEOUT" to allow each SOURCE stanza to allow client-defined timeouts or not.
• (SPAPICT Group) Submitted patches to include support for the SHA1 digest algorithm for SPA packet replay attack detection. I modified these patches for maximum configurability (see the --digest-alg argument on the fwknop command line), and the ability to use the SHA256 algorithm as well. The default path to the /var/log/fwknop/md5sums file has been changed to /var/log/fwknop/digest.cache, and the default digest algorithm is now SHA256 (but this is tunable via the DIGEST_TYPE variable in the fwknop.conf file).
• Added the Digest::SHA perl module in support of the SHA1 and SHA256 digest algorithms for replay attack detection and SPA message integrity.
• Added full packet hex dumps (including packet headers) to fwknopd in --debug --verbose mode. This is to help diagnose packet sniffing issues over the loopback interface on Mac OS X (first reported by Sebastien Jeanquier).
• (Test suite) Bugfix to ensure that the FWKNOP_DIR variable is set to the local output/ directory in several of the test config files in the test/conf/ directory.
• (Test suite) Added several tests for configurable digest algorithms in support for the SHA256, SHA1, and MD5 digest changes made by the SPAPICT Group.
• Updated the fwknop client to always call encode_base64() with the string to encode along with a second null-string argument to force all encoded data to not include line breaks.
• Bugfix in install.pl to not test for the iptable command on non-Linux systems, and to not test for the ipfw command on systems that are Linux.
• (Test suite) Updated to include the /proc/config.gz file so that the kernel config can be reviewed (not all Netfilter hooks are necessarily compiled in).

27 July, 2007

Yesterday I gave a talk at the O'Reilly Open Source Convention (OSCON) entitled Iptables Attack Visualization. Slides can be downloaded here.

This talk concentrated on the new Gnuplot interface available in psad-2.0.8, and example visualizations of data provided by the Honeynet Project were presented. Both two and three dimensional points graphs can be generated with psad-2.0.8, and these are useful for graphing large data sets; the Scan34 challenge from the Honeynet Project includes over 170,000 lines of iptables log data. Also, link graphs produced with the psad interface to AfterGlow were presented. These graphs are great at expressing relationships between IP addresses and activity such as outbound connections from the Honeynet.

Here is a sample graph of Slammer worm traffic (404-byte packets to UDP port 1434) in the Scan34 challenge data set (seeing the spike in worm traffic is extremely easy with a graph):



Other activities are visualized in my talk (including port scans, port sweeps, and Nachi worm traffic), but some of the most interesting log messages show outbound connections from the Honeynet over SSH and IRC, and these are clear indicators of a compromised system. Here is a link graph visualization of such activity with the AfterGlow project:



With psad-2.0.8 released, you can graph all of that iptables log data you have laying around on your system, and sometimes some interesting outliers can show up that indicate malicious activity.

09 June, 2007

The Techno Security 2007 conference is over, and I gave a talk entitled "Zero-day Attack Prevention via Single Packet Authorization". The major emphasis of this talk was to demonstrate some of the new capabilities offered by the 1.8 release of fwknop, including the ability to run the fwknop client on a Windows 2000 system under Cygwin and authenticate to a Linux system running the fwknopd server. This demonstration was accomplished from a single Ubuntu Linux system with a Windows 2000 instance under Vmware to execute the fwknop client. New capabilities in fwknop that I did not have time to demonstrate are the ability to run the fwknopd server on systems that use the ipfw firewall (such as FreeBSD and Mac OS X), and the usage of gpg-agent (part of the GnuPG project) to acquire passwords associated with GnuPG keys. At some point it might be interesting to devote more time to giving a lengthy demonstration of various fwknop authentication modes and features. One additional note is that I have released fwknop-1.8.1 after the conference talk to address an issue with the usage of the ipfw "keep-state" option when fwknopd creates new rules to accept connections from valid fwknop client systems; here is the ChangeLog.

You can download a PDF of my presentation slides here.

15 April, 2007

At the O'Reilly Open Source Convention of 2007 (July 23-27, Portland, Oregon) I will give a talk about visualizing iptables log data. Here is the talk abstract:

The iptables logging format provided by the Netfilter project contains a wealth of detailed information about network traffic. Nearly every interesting field in the network and transport layer headers is logged by iptables. By combining the graphing capabilities of AfterGlow with the attack detection capabilities of psad it is possible to render eye-catching graphical visualizations of network attacks. These visualizations can expose important relationships between attackers and their targets that are difficult to acquire in via non-graphical means. This talk will analyze iptables log data from two sources: the Honeynet Project, and from an Internet-facing Linux system. This data contains instances of the Nachi and Slammer worms, and suspicious outbound SSH and IRC connections from compromised systems. In addition, material from the book "Linux Firewalls: Attack Detection and Response" will be presented to show you how to deploy psad on a live firewall. As more people run Linux, mountains of iptables log data are piling up. It is time to maximize the effectiveness of this data and mine it for suspicious traffic and network-based attacks. This talk will show you how.

31 March, 2007

At the Techno Security 2007 conference (June 3-6, Myrtle Beach, South Carolina) I will be giving a talk entitled "Zero-day Attack Prevention via Single Packet Authorization". My intention for this talk is to illustrate practical usages of fwknop with an emphasis on live demonstrations of the technology. There have also been some interesting developments in the Single Packet Authorization world since I last gave a talk on the topic at ShmooCon, 2006. In particular, Sebastien Jeanquier wrote a Master's Thesis on SPA entitled "An Analysis of Port Knocking and Single Packet Authorization" at the Information Security Group (ISG) at Royal Holloway College, University of London. His thesis is an excellent evaluation of the port knocking and SPA concepts, and is a must-read for anyone who would like to explore an authoritative treatment of the two security mechanisms. Sebastien uses a quote from Bruce Schneier's Applied Cryptography to help explain away the perception that some people have that SPA suffers from security through obscurity (which it thoroughly does not):

"...If I take a letter, lock it in a safe, hide the safe somewhere in New York, then tell you to read the letter, that's not security. That's obscurity. On the other hand, if I take a letter and lock it in a safe, and then give you the safe along with the design specifications of the safe and a hundred identical safes with their combinations so that you and the worlds best safecrackers can study the locking mechanism - and you still can't open the safe and read the letter - that's security..."

Also, additional SPA projects have sprung up, such as an in-kernel implementation that is built entirely within the Netfilter framework. I will discuss these implementations, and make the case that SPA is maturing as a valuable protective mechanism against unknown zero-day exploits in server software.

26 March, 2007

Yesterday at ShmooCon I gave a talk (slides) about my vision for endowing iptables firewalls with true intrusion detection capabilities and how it can be used as a supplement to existing IDS infrastructure. This hinges upon using the iptables string match extension to inspect application layer data for malicious characteristics that are pointed out by the Snort signature set. The process of translating Snort signatures into equivalent iptables commands is automated by fwsnort.

(Update: 12/09/2007): A video of my talk is available here.

One thing I tried to emphasize in this talk is that there are real cases for automatically responding to network attacks - for example, consider the following scenario:

• A remotely exploitable vulnerability is found within some server software X that you have deployed in your network. Suppose this server is a critical corporate application, and taking it down so that it can be upgraded or patched requires an scheduling outage window.
• Some blackhat writes a worm that exploits this new vulnerability, and the worm begins spreading.
• The Snort community develops a signature for the worm and suppose this signature does not require fancy Snort rule options such as pcre or asn1, and so this signature can be translated by fwsnort.
• Because the server software cannot just be taken down to be fixed immediately, there is a window of time in which the worm may successfully compromise systems that are running this server software.

In the above scenario, the best way to protect the vulnerable server application from attack would be to deploy a piece of inline code that has the capability of intercepting and stopping the malicious data before it can reach the application. In some cases, fwsnort along with iptables can provide this functionality.

01 March, 2007

I will be giving a talk at ShmooCon entitled Attack Detection and Response with Linux Firewalls. Here is the talk description:

Most people think of iptables as a packet filtering and mangling firewall within the Linux kernel. Although this characterization is true, iptables also provides such a powerful set of features that it can assist in the detection and visualization of network-based attacks. Through the use of the Netfilter string match extension, packet application layer data can be examined and acted upon by iptables. The end result is that a significant percentage of Snort rules can be run directly within the Linux kernel via iptables, and a program called "fwsnort' automates the translation process from Snort rules to equivalent iptables rules. In addition, by combining the "psad" and "AfterGlow" projects, some stunning graphical representations of attacks can be generated due to the completeness of the Netfilter logging format. This talk will present advanced usages of fwsnort and psad, and new versions will be released at ShmooCon.

(Update: 12/09/2007): A video of my talk is available here, and slides can be downloaded as well.

If you are planning on attending ShmooCon, please stop by for a chat; the schedule is available here.