cipherdyne.org

18 September, 2008

A key advantage to using Single Packet Authorization (SPA) over port knocking is the fact that it is trivially easy to harden SPA packets against replay attacks by including a significant number of random bytes within each SPA packet. Then, by tracking the SHA-256 message digest (or the digest from some other suitable cryptographic hashing algorithm) for all incoming SPA packets, the server can enforce that only unique SPA packets ever result in elevated access through a default-drop firewall policy. Any duplicate SPA packet will match a previously calculated digest, and such a packet is therefore flagged as a replay attack (subject to the usual concerns surrounding the minuscule chance of a hash collision - though for SHA-256 this is exceedingly unlikely). In the case of SPA packets generated by the fwknop client, a full 16 bytes of random data is included at the beginning of each packet before it is encrypted.

Another benefit of randomizing SPA packet data - beyond thwarting replay attacks - is that it becomes more difficult to write signatures for intrusion detection systems to detect SPA traffic. The structure of SPA packets generated by the fwknop client is designed to minimize sections that remain the same from one invocation of the client to the next - such identifying sections could be used to write Snort rules to detect fwknop SPA packets. This blog post contains examples of such Snort rules which look for the base64-encoded versions of the string "Salted__" or the hex bytes "0x8502" at the very beginning of UDP packets over port 62201 (the default port used by fwknop). There is also a rule to look for trailing '=' characters at the end of such packets in order to detect the marker used by base64 encoding when the length of the original data is not a multiple of four. These predictable bytes are artifacts of the Crypt::CBC module, GnuPG, or base64 encoding itself, but any recent release of fwknop strips these bytes out of SPA packets before sending them on the wire. The fwknopd server adds them back in if necessary before attempting to base64 decode and decrypt incoming SPA packets.

So, given that fwknop uses CBC mode for symmetric encryption and random bytes are at the very beginning of the payload data, one would expect that SPA packets from fwknop - when viewed via a sniffer - are essentially random variations of base64-encoded data, correct? And this should remain true across all SPA packets that are encrypted with the same encryption key, and even across the same access requests?

Let's see how close fwknop gets to this...

What we need to see is the distribution of byte values across each byte position in a large sampling of SPA packets. That is, for the first byte in each packet across our sample, can we find a relation to any of the other first bytes in the other packets? This process needs to be repeated across all bytes in every packet. To rigorously test for randomness properties we could also get more sophisticated and use the NIST Statistical Test Suite, but for now we'll just focus on using Gnuplot to visualize the byte distribution across two sets of 20,000 SPA packets. If Gnuplot shows any recognizable features or relationships across our sample sets, then we know that we have more work to do. For reference, if you want to duplicate the analysis in this blog post or perform your own analysis of the SPA packet data sets (20,000 packets each), you can download them.

We need two capabilities: 1) the ability to automatically generate 20,000 SPA packets with the fwknop client and store them in a file (one packet to a line), and 2) the ability to parse the file and count the number of different characters in each byte position across all 20,000 SPA packets and print this data to a file so that it can be graphed. These goals are accomplished with this patch to fwknop (which adds a new command line argument --Save-packet-append to be released in fwknop-1.9.8) and this script base64_byte_frequency.pl respectively.

Now, let's collect the first set of 20,000 SPA packets. Each packet is encrypted in this case with the Rijndael cipher, and we use the --Include-salted and --Include-equals command line arguments to produce SPA packets that are compatible with older fwknopd servers: [spaclient]$ for ((i=1;i<=20000;i+=1)); do fwknop -A tcp/22 -a 127.0.0.1 -D 127.0.0.1 --Save-packet --Save-packet-file spa_artifacts.pkts --Save-packet-append --get-key spa.pw --Include-salted --Include-equals > /dev/null; echo $i; done
1
2
3
...
19998
19999
20000
[spaclient]$ head -n 2 spa_artifacts.pkts
U2FsdGVkX1/s7OmvQtYk9UnQuGg8htJ+19pru9NdhflmGhS9d/9fFET7jnPKWsk3/lnd CbGprkkUBkEYXNORP8RU8ZhkCS+pexZ2J+FbQzmwiuD7/9nA1DAmBGnUQi7mLyZYtOGm iCa8yL9IaP43DVhMflAEf+tQGaPw5xUd2/0=
U2FsdGVkX18NuTMq50ef6hjD0t16ZUnKrVYjirVW81UIRNDfclS812vZAWTdcio8t3GC QVxZz/uwrJsjkzevD0OhxJhba+CQVeKuJpfUOhskDQMtYDcH2hkGeDRK9Oc6AfLjO5Fd JXxBJuf8pmxfLC2iWkfAfooCJpjkOm+afH4= All of the SPA packets generated by the command above are written to the file spa_artifacts.pkts, and now let's execute the base64_byte_frequency.pl script against it. This script will create two new files spa_artifacts.pkts.2d and spa_artifacts.pkts.3d for graphing in two and three dimensions. The 2D file contains a simple count of each base64 encoded character, and the 3D file contains a count of each character at each position in the collection of SPA packets. We'll use Gnuplot to graph this data as follows: [spaclient]$ ./base64_byte_frequency.pl spa_artifacts.pkts
[+] Parsing SPA packets from: spa_artifacts.pkts...
[+] Writing 2D results to: spa_artifacts.pkts.2d...
[+] Writing 3D results to: spa_artifacts.pkts.3d...
[spaclient]$ cat > spa_artifacts_2d.gnu
reset
set title "2D SPA packet randomness (artifacts included)"
set terminal png transparent nocrop enhanced
set output "spa_artifacts_2d.png"
set xlabel "char"
set ylabel "frequency"
plot 'spa_artifacts.pkts.2d' using 1:2 with lines title '(char,freq)'
[spaclient]$ cat > spa_artifacts_3d.gnu
reset
set title "3D SPA packet randomness (artifacts included)"
set terminal png transparent nocrop enhanced
set output "spa_artifacts_3d.png"
set xlabel "position"
set ylabel "char"
set zlabel "frequency"
set view 72,9
splot 'spa_artifacts.pkts.3d' using 1:2:3 with points title '(pos,char,freq)'
[spaclient]$ gnuplot spa_artifacts_3d.gnu
[spaclient]$ gnuplot spa_artifacts_2d.gnu
[spaclient]$ ls -atlr *png
-rw-r--r-- 1 mbr mbr 5977 2008-09-14 09:31 spa_artifacts_2d.png
-rw-r--r-- 1 mbr mbr 4194 2008-09-14 09:31 spa_artifacts_3d.png The last two lines above indicate that Gnuplot has created two graphics files spa_artifacts_2d.png and spa_artifacts_3d.png for plotting the data in two and three dimensions. Because we're graphing base64 characters as integer data, the base64_byte_frequency.pl script maps each base64 character to numerically ordered values beginning at zero. We could have just graphed the hex value of each character directly, but this would result in gaps. For reference, the base64 alphabet is described by the following characters (in order): +, /, 0-9, A-Z, a-z. There is also the equals "=" character, but it is only used as a closing marker. So, the base64_byte_frequency.pl script maps "+" to 0, "/" to 1, "0-9" to 1-11, "A-Z" to 12-37, "a-z" to 38-63, and "=" to 64.

Here is the 2-dimensional graph that Gnuplot has produced: You can see in the graph above that there are several spikes for a few character values. These spikes correspond with the characters U2FsdGVkX1, which is the base64 encoded version of the string "Salted__". Every SPA packet in the spa_artifacts.pkts file begins with this string, and so one would expect more of these characters on average than the others. There is also a sharp dip to 20,000 on the right-hand portion of the graph for the value 64, which corresponds to the = character. This is because there is only one equals character at the end of each SPA packet in the spa_artifacts.pkts file.

Because base64 encoding uses an alphabet of 64 characters, and given that our sample size is 20,000 packets of 171 bytes each (less the ending = marker), we would expect the average number of times each character is represented to be 171 / 64 * 20000 = 53,000 (approximately). That is, we can expect this value if the SPA packets are perfectly random across the sample set. The spikes in the 2D graph throw this expected value off a bit.

Now let's take a look at the 3-dimensional plot of the same data: This graph shows us where the predictable bytes are. We know that each SPA packet begins with U2FsdGVkX1 and ends with =, and the outliers (on the left-hand side and one point on the right-hand side - all with Z-axis values of about 20,000) in the above graph illustrate this. The X-axis represents the byte positions of each packet, the Y-axis are the numeric character codes, and the Z-axis is the number of times a character is counted.

So, given that any recent release of fwknop removes the "Salted__" prefix and any trailing "=" characters, are the graphs of such SPA packets now highly randomized?

The answer is "almost".

Let's produce the same two graphs, but this time for SPA packets produced by any recent version of fwknop (without using the --Include-salted or --Include-equals command line arguments). [spaclient]$ for ((i=1;i<=20000;i+=1)); do fwknop -A tcp/22 -a 127.0.0.1 -D 127.0.0.1 --Save-packet --Save-packet-file spa_no_artifacts.pkts --Save-packet-append --get-key spa.pw > /dev/null; echo $i; done
1
2
3
...
19998
19999
20000
[spaclient]$ head -n 2 spa_no_artifacts.pkts
/ZlXox6SyQsyMpKVj+cxHlmSpMWOaAyxmou5LgThZ58yXlxFrR7BGtqSRJJTELrUgJ2/ RiX9If+NLXEANJSu9nogO8ZG2R6cllQlhT1vM6YiLsktujuV3a7r81I1JSCwC4YZdNQC Y2xwcRGLMEEhykGhp0RKEYlSo
8jX5NECzw4NGVg3LIEhu30ph0uvBa4ijW9/S7IQEQvdj/IPHle8KRoeyHvskj1fd0XU7 beUIb5zCKsFq7NTTUsnwaccULAKQHZz4Qm0ZTVC8st0doDfhU5Bl46LbDXPCejRbSQEd cVgwDwaU8XqEKr8kYjXZ3ZNGA The 2-dimensional graph looks pretty good: Now that the invariant sections have been removed, the length of each packet is 161 characters, so if the randomness were perfect, we would expect the average instance of each character to be 161 / 64 * 20000 = 50,300 (approximately), and this is quite close to the value displayed by the graph. There are still two minor spikes corresponding to the numeric values around 0 and 1, and then again around 10 and 11 on the X-axis. These bytes correspond to the characters +, /, 8, and 9 respectively.

Let's look at the 3-dimensional graph to see if we can get a sense of where these spikes are in terms of byte positions within the SPA packets: So, at the scale shown above, the 3D graph looks decently random - at least there are far fewer outliers than for the first data set of 20,000 packets, and there aren't any other obviously regular structures in the graph. However, if you look to the left-hand portion of the graph, you will see there are small outliers at position 0 on the X-axis - the very first byte of each SPA packet. Looking through the spa_no_artifacts.pkts file, the graph is indeed correct - every SPA packet begins with one of the bytes +, /, 8, or 9.

Why?

The reason is that the current fwknop client code strips the string U2FsdGVkX1 from each SPA packet after the raw encrypted data is base64 encoded, and the encoding itself uses +, /, 8, or 9 after the last "_" in the string "Salted__". Although this is not huge problem, it does mean that it is possible to write a Snort rule that uses a PCRE to look for one of these bytes at the very beginning of UDP payload data. This will be fixed in a future release of fwknop.

The techniques illustrated in this blog post can be applied to SPA packets generated by other implementations as well. Some SPA implementations use a hashed payload instead of an encrypted payload which implies that multiple requests for the same access through a firewall will look quite similar in many byte positions, so it is much easier to detect such SPA packets with signatures in an intrusion detection system. By contrast, the SPA packets produced by fwknop are much harder to write reliable signatures for effective detection in any IDS - particularly when combined with the port randomization features offered in recent releases.

Finally, this blog post has only addressed the randomness characteristics of SPA packets that have been encrypted with the Rijndael cipher. An upcoming blog post will perform the same analysis for SPA packets encrypted with GnuPG.

12 September, 2008

It appears that fwknop is going to be bundled within the next release of the Fedora Linux distribution thanks to the work of Mirek Trmac and sponsored by Red Hat. One of the most significant contributions made by Mirek can be seen in this patch that removes the dependency in the fwknopd daemon on the NetPacket perl module, which seems not to be actively developed anymore. An RPM of fwknop has been built for Fedora 10, and the build and approval status can be viewed on the Fedora package page.

Although fwknop will certainly not be enabled by default on Fedora at boot time, at least the infrastructure will be there to implement Single Packet Authorization on Fedora with greater ease. Well before Fedora 10 is released, I will also have a comprehensive tutorial on the theory, implementation, and deployment of fwknop (in both port knocking and SPA modes) available on cipherdyne.org.

Given the recent problems that Debian and Red Hat have had with encryption keys and the maintenance of server security, there is always room for additional protection measures to make it more difficult to compromise systems. The features offered by fwknop make it ideally suited to combine a default-drop iptables policy with dynamic access from authenticated networks to services such as SSH.

28 August, 2008

As is well known, in the version of the OpenSSL library distributed by the Debian Linux distribution through early 2008, there was a change made that had the unintended consequence of reducing the ability of OpenSSL to gather the necessary entropy from the local system to create cryptographically strong keys. Fortunately, this problem has since been fixed, but it affected a large list of applications - including OpenSSH - that linked against the hobbled version of the OpenSSL library. Even though the vulnerability has been patched and upgrading a Debian system (or system derived from Debian such as Ubuntu) means that no new weak keys will be generated, this is only half of the story; it is still critically important to remove all weak keys from all systems. This applies even to non-Debian systems to which weak keys were copied from a vulnerable Debian system. Further, any password that was used over an SSH connection with weak keys (such as to log into a remote system or a password used to unlock a GnuPG private key) should be treated as if it were transmitted in the clear.

So, how does fwknop play into all of this?

Let's assume that a key is chosen for fwknop Single Packet Authorization (SPA) message encryption/decryption, and this key is only entered or viewed via console access (so it is never transmitted itself over a weak SSH connection). Let's also assume that SSH connections are made from a Debian system with a weak SSH key to another system, but only after authenticating with fwknop to the remote SSH server. In this case, even if an attacker can sniff all packets associated with both the SSH connection and the SPA packet, it is not a forgone conclusion that the attacker will be able to access the SSH server. If the user has to type in a password over SSH (i.e. a pre-shared key is not used), then the attacker can see it after decrypting the session, but the fwknop hurdle is still in the way. The attacker would not even be able to see that the SSH server is listening to connect to, and because the fwknop key has never been transmitted in the clear, this provides a decent defense. Building up multiple layers of security is sometimes important.

On another note, many people turn to mechanisms like fail2ban to help protect against brute force attempts to guess weak user passwords in systems that allow arbitrary IP addresses to connect to the local SSH daemon. But, in the face of something like the Debian OpenSSL vulnerability, there is no need for any attacker (who can sniff traffic) to guess passwords at all - even strong passwords are effectively transmitted in the clear. To defend against this, a stronger layer of protection is necessary such as Single Packet Authorization.

Finally, the first step in removing weak SSH keys is to find them, and this is the job of the dowkd.pl script.

25 August, 2008

In the latest issue (September/October 2008) 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.

24 August, 2008

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

24 August, 2008

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.

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.

28 June, 2008

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.

21 January, 2008

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.