cipherdyne.org

Michael Rash, Security Researcher



fwknop    [Summary View]

Next »

Hakin9 Article - Advanced SPA with fwknop

Hakin9 fwknop article In the latest issue of Hakin9 Magazine, I had an article published entitled Advanced SPA with fwknop. It was the goal of this article to introduce the port forwarding capabilities of fwknop that make it possible to reach internal services with automatically generated NAT rules, and also to show how fwknop SPA packets (prior to the 1.9.6 release) could be detected with some well-crafted Snort rules that look for certain encryption and encoding artifacts. Also, with the addition of source IP addresses to SPA digest tracking, it is possible to get a sense of routing paths that might at one time have had sniffers watching for SPA packets if a replay attack against the same fwknopd instance is detected at some later time.

The Snort rules mentioned in the article - updated to take into account the more recent 1.9.6 release - are displayed below. The first Snort rule is designed to look for UDP packets over port 62201 that end with two '=' characters - a potential marker of base64-encoded data (when the original data size was not a multiple of four). The second rule looks for the base64-encoded version of the string Salted__, which is added by the Crypt::CBC module to maintain compatibility with how the OpenSSL library encrypts data. The third rule looks for packets that begin with base64-encoded version of the string 0x8502 which is a marker for data encrypted with GnuPG, and also checks to see of the size of the payload is at least 1000 bytes (SPA packets encrypted with GnuPG tend to be larger than those encrypted with Rijndael). Here are the Snort rules: alert udp any any -> any 62201 (msg:"fwknop pre-1.9.6 SPA traffic"; dsize:>150; pcre:"/==$/"; sid:20080001; rev:1;)
alert udp any any -> any 62201 (msg:"fwknop pre-1.9.2 SPA traffic"; content:"U2FsdGVkX1"; depth:10; dsize:>150; sid:20080002; rev:1;)
alert udp any any -> any 62201 (msg:"fwknop GnuPG encrypted pre-1.9.6 SPA traffic"; content:"hQ"; depth:2; dsize:>1000; sid:20080003; rev:1;)
Any recent release of fwknop (greater than 1.9.5) strips out these identifying markers before transmitting SPA packets on the wire, so these rules are no longer effective at detecting fwknop SPA communications. Also, strong port randomization features were added in fwknop-1.9.4, both for the randomization of the SPA packet destination port as well as the port where the actual connection (say, SSH) is made, so UDP port 62201 is not effective either when these features are used.

Finally, here is an excerpt from the conclusion of the article:

   In the continual arms race that is computer security today, having a good understanding of network communications and how to customize an IDS rule set to an emerging protocol is an important skill. Finally, SPA offers a compelling addition to the tools available for effective server defense; I personally sleep more soundly knowing that arbitrary IP addresses around the Internet cannot see that I have an SSH daemon running, and yet I can access it from wherever I like.

Installing fwknop on Debian and Ubuntu

fwknop Debian packages Franck Joncourt has developed Debian packages of fwknop and fwsnort, and he has provided a set of installation instructions. I've tested this procedure on an Ubuntu-8.04 system as well and it worked quite well. Hopefully it won't be long before fwknop and fwsnort packages make it into the official Debian repository.

To get the latest packages from dthconnex repository, you can add the following lines to your /etc/apt/sources.list file: # cat >> /etc/apt/sources.list
deb http://dthrepo.podzone.org/debian/ sid main
deb-src http://dthrepo.podzone.org/debian/ sid main
Now, the following command will inform you that the public key related to the dthconnex repository (a dedicated GPG key used for signing all packages) is not available: # apt-get update To make it easy for users, a package known as debian-dthconnex-keyring is available and can be installed with the following command: # apt-get install debian-dthconnex-keyring It will add the dthconnex key to your apt keyring, and you can verify this as follows, and now you can run the apt-get update once again and the key warning message should not appear anymore: # apt-key list
[...]
pub 1024D/888B2140 2007-11-25 [expire: 2008-11-24]
uid DthConnex Repository (Unofficial Debian Repository) <debrepository@dthconnex.com>
Now, you can install fwknop (fwknop-server/fwknop-client) or fwsnort safely.

As packages distributed from the dthconnex repository are build from Debian GNU/Linux Sid for amd64/i386 architectures, if you need to backport them or build them for a different architecture, you can get their source like so: # apt-get source fwknop-server

Software Release - fwknop-1.9.7

fwknop-1.9.7 release The 1.9.7 release of fwknop is available for download. This release changes several areas of fwknop related to packaging and packet decoding. First, in order to better support the work of Franck Joncourt to package the cipherdyne.org projects for Debian, all perl module dependencies have been moved into the deps/ directory. Second, it is looking like fwknop will eventually be integrated with Fedora thanks to the work of Mirek Trmac who contributed significant patches (including the removal of the NetPacket dependency). Also, as mentioned in the latest releases of fwsnort and psad, every project release is now signed with a new GnuPG key that is dedicated just for this purpose, and this key can be downloaded here.

The complete ChangeLog for fwknop-1.9.7 appears below:

  • Mirek Trmac from Red Hat contributed several patches so that fwknop can be bundled within the Fedora Linux distribution. These patches implemented the following changes:
    • Updates to fwknopd to remove the NetPacket module as a dependency (this is a particularly important update since it assists with getting fwknop bundled with Debian as well). The patch manually decodes the network and transport layer headers.
    • A patch to make the fwknop init script not start fwknopd by default on Red Hat systems. This patch also supports Fedora init script conventions better (i.e. fwknop instead of the fwknopd name for the lock file in /var/lock/subsys).
    • Updated the fwknop Makefile to respect the OPTS variable which is used in the RPM spec file.
    • Bugfix in fwknop_serv to support the variable expansion code from fwknopd. This was important for the TCPSERV_PID_FILE file which is defined as $FWKNOP_RUN_DIR/fwknop_serv.pid.
    • Updated fwknopd to use the Net::Pcap API valid in Net::Pcap-0.14 for the datalink() function (used to detect the datalink layer type).
  • Updated fwknop, fwknopd, and knoptm to import perl modules out of the /usr/lib/fwknop/ directory if it exists. This allows the perl module path to be manipulated via the --Lib-dir command line argument and 'require' statements instead of the old 'use module' strategy.
  • Added module version output for each non-core perl module used by fwknop and fwknopd in --debug mode. This is mostly useful for the test suite to see which versions of the modules are being used.
  • Added the ability to ignore any local GnuPG 'options' file with a new command line argument --gpg-no-options (for the fwknop client) and a new access.conf config variable GPG_NO_OPTIONS (for the fwknopd daemon). This fixes a problem reported by Mike Holzmann where the 'encrypt-to' option in the default options file was causing SPA packets to exceed 1500 bytes when encrypted with a 2048-bit GnuPG key. Also added the MAX_SNIFF_BYTES to the fwknop.conf file and --Max-packet-size to the fwknop command line to alter the default of 1500 bytes if needed (but this shouldn't really be necessary).
  • Bugfix for 'Premature end of base64 data' and 'Premature padding of base64 data' warning messages from MIME::Base64 errors. Now fwknopd applies more rigorous checks for base64 encoded characters, and either of these two messages above will result in the packet data being discarded before it is sent through any decryption function. Mike Holzmann reported this issue.
  • (Test suite) Added --test-system-fwknop to allow any installed version of fwknop to be installed instead of the scripts bundled within the local source distribution.

fwknop Presentation at BARcamp Chicago

fwknop at BARcamp Chicago 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.

The Last HOPE Conference, Port Knocking and SPA Talk Wrap-up

SPA talk slides from the Last HOPE conference 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.

SPA Talk at the Last HOPE Computer Security Conference

SPA talk at the Last HOPE conference Next month in NYC the final Hackers On Planet Earth (HOPE) conference will take place from July 18th through the 20th. I will be giving a talk there entitled "Port Knocking and Single Packet Authorization: Practical Deployments", and here is the abstract:

   Port Knocking and its big brother, Single Packet Authorization (SPA), can provide a robust additional layer of protection for services such as SSH, but there are many competing Port Knocking and SPA implementations. This talk will present practical usages of fwknop in Port Knocking and SPA modes, and discuss what works and what doesn't from a protocol perspective. Integration points for both iptables and ipfw firewalls on Linux and FreeBSD systems will be highlighted, and client-side support on Windows will be demonstrated. Finally, advanced functionality such as inbound NAT support for authenticated connections, sending SPA packets over the Tor anonymity network, and covert channel usages will be discussed. With SPA deployed, anyone scanning for a service with Nmap cannot even tell that it is listening; let alone target it with an exploit (zero-day or not).

A goal for the talk will be to start with the most basic port knocking deployment (a shared sequence of only one port) and build from there into encrypted port knocking sequences, and then move into the SPA realm with SPA packets encrypted with Rijndael and finally with GnuPG. Along the way security tradeoffs will be discussed. For example, a shared sequence of a single port allows an extremely simplistic port knocking implementation (so there is less risk of a vulnerability in the port knocking software itself), but then any casual port scan or stray packet that hits the shared port also qualifies as a valid port knock sequence. At the high end, SPA packets encrypted with GnuPG solve all sorts of difficulties with simple port knocking from a protocol perspective, but there is the slight expense of a more complicated implementation (although it is still a lot harder to target an SPA implementation with an exploit than a complicated TCP-based service that advertises its existence to the world under any basic port scan).

At the talk I will also release the next version (1.9.6) of fwknop.

If you are going to be at the HOPE conference, please stop by and say 'hello'. No Starch Press will also be at the conference so I'm sure I will hang out at their booth much of the time as well.

The Security Properties of Port Knocking and SPA

There has been a recent thread on the Security Focus Security Basics mailing list entitled Port Knocking Vulnerabilities. It seems that a common concern in this thread is to concentrate on whether a service that is protected by a default-drop packet filter and associated port knocking or Single Packet Authorization system can be detected remotely by an attacker. That is, people seem to associate the security of port knocking and SPA with whether or not a service protected by such a mechanism can be detected. Some in the thread make a case that protected services can be detected through timing attacks whereby packet latencies with surrounding systems are monitored for variances which indicate the existence of a particular service or services behind the packet filter. To this I responded:

   Timing attacks can come up with some really interesting information, I agree. However, I'm not aware of an application of timing attacks against default drop packet filters to answer the question "is service XYZ really running behind the filter". Sure, as an attacker, you can collect timing differences between round trip times to all sorts of devices that the target system may be communicating with, but I doubt if there is a reliable way to infer that a _particular_ service is listening as result. After all, the steady state of such as service may be that there are no sessions at all; only the occasional administrative session to run a couple of commands and then it exits. Note that I'm not questioning whether it is possible to determine if a _system_ exists; I'm questioning whether it is possible to determine if a particular service running on a system exists. To do so, such a timing attack would have to differentiate between "tcp port 22" communicating vs. "tcp port 23", etc. I'm skeptical, and if people think it is possible, I would like to see relevant papers that make this clear.

I find it interesting that people concentrate on whether a service protected by a default-drop packet filter and a port knocking or SPA system is detectable. Let's assume for a moment that such a timing attack is able to give an attacker a high probability that SSH is really running behind a port knocking or SPA system. Now, what would the attacker be able to do to exploit a vulnerability (zero day or otherwise) in the SSH daemon? It is easier to subvert the port knocking protocol (I wrote a paper on this here if anyone is interested: http://www.cipherdyne.org/fwknop/docs/SPA.html), but how about SPA?


Perhaps this discussion could be extended on Sebastien Jeanquier's online Single Packet Authorization forum.

2007 LinuxQuestions.org Members Choice Awards

2007 LinuxQuestions.org Members Choice Awards Drew Bentley, a long time user of psad, emailed me to mention that he had voted for psad to be included within the 2007 LinuxQuestions.org Members Choice Awards in the category of Network Security Application of the Year. Although there are many security projects out there that outstrip the Cipherdyne projects, my personal hope would be that eventually fwknop might be included in the Members Choice Awards someday. The rise of service authorization via passive means embodied by Single Packet Authorization allows the security model employed by VPN services and software such as SSH to be strengthened with a default-drop packet filter. This reduces the number of functions - any one of which has a non-zero probability of containing a security vulnerability - that an attacker can tweak from arbitrary source IP addresses.
     I personally sleep better at night knowing that my SSH daemon can only be reached after a would-be client is passively authenticated and authorized to communicate through the iptables policy by sending a properly encrypted and non-replayed SPA packet. Anyone scanning for my SSH daemon with nmap cannot even see that it is listening.

EnGarde Secure Linux Bundles fwknop and psad

EnGarde Secure Linux Bundles fwknop and psad The EnGarde Linux distribution, which focuses on security, has announced that they now bundle both fwknop and psad within their latest release (3.0.18). Here is a quote from their press release:

   Guardian Digital is happy to announce the release of EnGarde Secure Community 3.0.18 (Version 3.0, Release 18). This release includes many updated packages and bug fixes, some feature enhancements to Guardian Digital WebTool and the SELinux policy, and a few new features.

In distribution since 2001, EnGarde Secure Community was one of the very first security platforms developed entirely from open source, and has been engineered from the ground-up to provide users and organizations with complete, secure Web functionality, DNS, database, e-mail security and even e-commerce.


Coupled with the EnGarde annoucement, linuxsecurity.com has published an article about how to configure fwknop on EnGarde systems to add a strong default-drop stance for SSHD:

   This article will walk the reader through an EnGarde Secure Linux implementation of fwknop, from the initial iptables rules setup to the deployment of fwknop on both the server and client side. By the end of the article, the user will be able to explicitly shutdown all access to the EnGarde Secure Linux SSH daemon to only those with fwknop credentials.
Next »