With fwknop now re-written in C for the 2.0 release,
I thought it would be a good idea to take a look at how close encrypted SPA packet data comes to having
high levels of entropy - as understood to be a measure of randomness - from one packet to the next. If
fwknop is properly using encryption, and the ciphers themselves are also well-implemented (fwknop can
use either Rijndael or GPG), then we would expect there to be no obvious relationship between SPA packets
even for repeated access requests to the same service. If there are any such relationships in the
encrypted data across multiple SPA packets, then an adversary might be able to infer things about
the underlying plaintext - precisely what strong encryption is supposed to make difficult. This blog
post covers SPA packet entropy for AES (Rijndael) CBC and ECB encryption modes, and leaves GPG to another
post.
Although this post has some similarities with an older blog entry
"Visualizing SPA Packet Randomness",
a more rigorous and automated way of measuring cross-packet SPA entropy will be presented. In addition,
we'll take a look at what happens when (normally) random
salt
values for AES encrypted SPA packets are artificially forced to be constant. This helps to highlight
some real differences in AES electronic codebook (ECB) and cipher block chaining (CBC) encryption
modes.
First, the next release of fwknop will most likely offer the ability to select different AES encryption
modes (such as cipher feedback (CBF) mode and output feedback (OFB) mode), and a dedicated
"crypto_update"
branch has been created for this work. The default AES encryption mode used by fwknop is cipher block chaining
(CBC) mode as defined
here.
Within the crypto_update branch there is a new script
"spa-entropy.pl"
that is designed to execute the fwknop client multiple times, collect the encrypted SPA packet data, use the
ent program to measure the entropy in slices for each byte
position across the SPA data set, and then plot the results with gnuplot. What does this accomplish? It
allows us to easily see for any given byte position within a collection of SPA packets whether there is a
relation from one to the next. If there is such a relation, then the cipher used to encrypt the
data was not very good at achieving high levels of entropy in the ciphertext across multiple packets.
As a motivating
example from Wikipedia, AES in
ECB mode encrypts identical plaintext blocks into identical ciphertext blocks, and this results in patterns
in plaintext data being preserved to some extent in the ciphertext. So, an adversary can make good guesses
about the underlying plaintext just by looking at the ciphertext! Wikipedia does a nice job of illustrating
this with the following two images of the Linux kernel mascot "Tux" - before and after AES encryption in
ECB mode:
 |
AES ECB encryption -> |  |
Now, let's take a look at SPA packet entropy with the spa-entropy.pl script. For reference, fwknop builds SPA packets according to the following data format before encryption:
[random data: 16 bytes]:[username]:[timestamp]:[version]:[message type]:[access request]:[digest]
So, if a user wants repeated access to the same service protected behind fwknopd on some system, then several fields above will be identical across the corresponding SPA packets before they are encrypted. The username, version, message type, and access request fields will likely be the same. If fwknop has made proper use of encryption, then the fact that these fields are the same across multiple SPA packets should not matter. After encryption, an observer should not be able to tell anything about the underlying plaintext (other than perhaps size since AES is a block cipher). Let's verify this for 1,000 SPA packets encrypted with the default CBC mode - they are all encrypted with the same key 'fwknoptest' by the spa-entropy.pl script:
$ ./spa-entropy.pl -f 1000_pkts.data -r -c 1000 --base64-decode
[+] Running fwknop client via the following command:
LD_LIBRARY_PATH=../../lib/.libs ../../client/.libs/fwknop -A tcp/22 -a 127.0.0.2 -D 127.0.0.1 --get-key local_spa.key -B 1000_pkts.data -b -v --test -M cbc
[+] Read in 1000 SPA packets...
[+] Min entropy: 7.75 at byte: 54
[+] Max entropy: 7.86 at byte: 115
[+] Creating entropy.gif gnuplot graph...
This produces the gnuplot graph below. Perfectly random data would produce 8 bits of entropy per byte, and the min/max values of 7.75 and 7.86 along with the fairly uniform distribution of similar values across all of the SPA byte positions implies that there is little relation from one SPA packet to the next - good.
As an aside, here is
what ent reports against the local /dev/urandom entropy source on my Linux system, and it is
the "Entropy =" line that spa-entropy.pl parses for each SPA byte slice:
$ dd if=/dev/urandom count=1000 |ent
1000+0 records in
1000+0 records out
512000 bytes (512 kB) copied, 0.128497 s, 4.0 MB/s
Entropy = 7.999625 bits per byte.
Optimum compression would reduce the size
of this 512000 byte file by 0 percent.
Chi square distribution for 512000 samples is 265.77, and randomly
would exceed this value 50.00 percent of the times.
Arithmetic mean value of data bytes is 127.5076 (127.5 = random).
Monte Carlo value for Pi is 3.138715386 (error 0.09 percent).
Serial correlation coefficient is -0.001293 (totally uncorrelated = 0.0).
Now, let's switch to ECB mode and see what happens (just run the spa-entropy.pl script with '-e ecb'):
Well, that still looks pretty good. Revisiting the ECB encrypted image of Tux above
for a moment - the reason that the Tux outline can be seen in the encrypted version
is that in the JPG image file there must be identical blocks in multiple locations
to represent the solid black regions. These blocks are all encrypted in the same
way by AES in ECB mode, so the outline persists. But, this is one instance of ECB
encryption against a file that has multiple identical blocks. For the encrypted SPA
packets, we're dealing with 1,000 separate instances of encrypted data (all with the
same key). Across this data set there are certainly lots of identical plaintext
blocks (all of the SPA packets request access for source IP 127.0.0.2 to destination
port tcp/22 for example), but the encrypted data still shows a high level of entropy.
This source of entropy is provided by the random salt values that are used to
generate the initialization vector and final encryption key for each encrypted SPA
packet. As proof, if we apply the following patch to force the salt to zero for all
SPA packets (of course, one would not want to use this patch in practice):
$ git diff lib/cipher_funcs.c
diff --git a/lib/cipher_funcs.c b/lib/cipher_funcs.c
index 0a0ce3b..32c8bd6 100644
--- a/lib/cipher_funcs.c
+++ b/lib/cipher_funcs.c
@@ -153,6 +153,8 @@ rij_salt_and_iv(RIJNDAEL_context *ctx, const char *pass, const unsigned char *da
get_random_data(ctx->salt, 8);
}
+memset(ctx->salt, 0x00, 8);
+
/* Now generate the key and initialization vector.
* (again it is the perl Crypt::CBC way, with a touch of
* fwknop).
Here is what spa-entropy.pl reports after recompiling fwknop with the patch above:
Now we can easily see where there are identical blocks across the SPA packet data set. The first
eight bytes contains the salt, so these are all zero (note that fwknop strips the
usual "Salted__" prefix before transmitting an SPA packet on the wire). The next
16 bytes are the random bytes that fwknop includes in every SPA packet so these bytes
have high entropy. Next up are the username and timestamp - the later changes with
each second, so there is some entropy there since it takes a few seconds to create the
1,000 SPA packet data set. Then the entropy goes back to zero with the next fields
and there isn't any decent entropy until the final message digest.
As a final contrasting case, let's leave the patch applied to force the salt to zero, but now switch back to CBC mode:
In CBC mode, the random data included by the fwknop client now results in decent entropy
even though the salt is zero. This is because every ciphertext block in CBC mode
depends on all previous plaintext blocks, so randomness in one plaintext block implies
that every subsequent encrypted block will look different from one SPA packet to the
next. This graphically shows that CBC mode is a better choice for strong security.
Now, if the pseudo random number generator on the local operating system is poorly
implemented, this will negatively impact ciphertext entropy regardless of the encryption
mode, but still CBC mode is a better alternative than ECB mode.
Although spa-entropy.pl is geared towards measuring SPA packet entropy, this technique could certainly be generalized to arbitrary collections of ciphertext. If you know of such an implementation, please email me.
In June, 2011, all of the cipherdyne.org software projects were switched over to git from svn,
and at the same time the web interface was switched to gitweb (along with hosting at github)
from trac. Given the switch, I knew there would be a change to how search engines indexed the
code/data, and one question would be whether any particular search engine would take a specific
interest in the code provided via git and/or gitweb. Note that each of the fwknop, psad,
fwsnort, and gpgdir projects have raw git repositories that can be cloned directly over HTTP
from cipherdyne.org (a nice feature of git), or viewed with any browser through
gitweb.
(Personally, I like the "links2"
text-based browser rendering of gitweb pages - nice and clean.)
Clearly, that is not a very uniform distribution from day to day. It looks like Bing has been
hitting the gitweb interface at a rate of over 17,000 hits per day for a significant portion
of late December and early January. The other search engines hardly even show up in the graph -
you know there are big spikes when everything looks better on a logarithmic scale:
With some additional work, it looks like the gitweb.cgi links that Bing is indexing are not all
unique. That is, one might expect that Bing would hit a link, grab the content, and then not return
to the same link for a while. Some gitweb.cgi links were hit more than 10 times and more than 100,000
links were hit more than once during this time period.
Given that 1) all of the information gitweb displays is derived from the underlying git repositories,
and 2) the git repositories are directly accessible via HTTP anyway, it would seem that a better way for
search engines to behave would be to just ignore gitweb altogether and pull directly from git. That
would certainly cut down on the server-side resources necessary to service search engine requests.
Perhaps though the general strategy of search engines is not to be too smart about such things - they
probably just want access to data, and when they see a link they go after it.
Either way, the kind of dedicated and repetitive indexing the Bing is doing against gitweb is a bit much,
and it certainly seems as though they could implement a less intensive crawler. I'm curious if other
server admins are seeing similar behavior.
After a long development cycle, fwknop-2.0 has
been released. This is the first production release of the
fully re-written C version of fwknop, and is the culmination of an effort to provide
Single Packet Authorization to multiple open source
firewalls, embedded systems, mobile devices, and more. On the "server" side, supported
firewalls now include iptables on Linux, ipfw on FreeBSD and Mac OS X, and pf on OpenBSD.
The fwknop client is known to run on all of these platforms, and also functions on
Windows systems running under Cygwin. There is also an Android client, and a good start
on a iPhone client as well. On a personal note, I wish to thank Damien Stuart for a
heroic effort to port most of the original perl code over to C. Also, several other
people have made significant contributions including Jonathan Bennet, Max Kastanas,
Sebastien Jeanquier, Ozmart, and others. If there are any issues, please get in touch
with me directly or send an email to the fwknop
mailing list.
The 2.0rc5 candidate release of fwknop is available for
download. There may be a few tweaks to the
code before the official 2.0 release is made, but this is pretty close as-is. Significant
development work has gone into fwknop since the 2.0rc4 release, and adds some major new
functionality as well as fixing a few bugs. Here is a summary of the changes:
The C version fwknop has now made it into the OpenWrt
Linux distribution for embedded devices. Jonathan Bennett made this possible
by contributing a Makefile
for OpenWrt, and it was picked up the OpenWrt maintainers. It is good to
see progress made towards the integration of
Single Packet Authorization into operating
systems that are designed to function as secure gateway devices between multiple
networks.
Pentoo Linux
distribution thanks to ozmart and the Pentoo maintainers.
Pentoo is a live-cd distribution that is focused on security and derived from
Gentoo. ozmart wrote a description of the
use case for fwknop on Pentoo from a pentration testing perspective:
After using subversion for several years, I've switched
to git for all cipherdyne.org projects. Subversion has
certainly served its purpose, but it is hard to look at git and not feel a compelling draw. Further,
with easy to set up web interfaces to git repositories such as
gitweb and free hosting services such
as github, providing a public git repository is trivial. Git itself
can allow repositories to be cloned directly over HTTP without needing infrastructure like WebDAV,
and here are links for the cipherdyne.org projects (github and gitweb links too):
Kicking off 2011 with a bang is easy this year - Max Kastanas has ported the fwknop
client to the Android mobile operating sytem. This brings Single
Packet Authorization to Google's smart phones, and was accomplished using Damien Stuart's
libfko implementation.
All of the Android code can be found in the Cipherdyne
Trac respository.
A couple of screenshots of using the SPA app from an Android phone appear below - after the
SPA packet is sent and verified passively by the fwknop daemon on the remote system, the
fwknop Android app automatically launches Connectbot
to access SSHD:
Recently a psad user notified me via email that the psad-2.1.7.tar.gz tarball
was flagged by ClamAV as being infected with Exploit.HTML.MHTRedir-8.
After checking a few things, it turns out that ClamAV is triggering on a Snort rule in the
Emerging Threats rule set which is bundled in both
psad and fwsnort. The following analysis shows
exactly what ClamAV is detecting and why, and also provides some guidance for how to avoid
this for any software projects that distribute Snort rules. Similar logic would apply to
other software engineering efforts - including commercial intrusion detection systems - that
are (by their nature) looking for malicious artifacts on the filesystem or within network
traffic.
Every few months it seems that there is a new variation of a password guessing botnet.
This time around, as reported by the SANS ISC
and also by malwarecity.com,
a botnet called "dd_ssh" has been built up around a vulnerability in phpMyAdmin.
(Here is the vulnerability announcement
from the Debian security list.) Once a vulnerable webserver has been compromised, the
botnet starts scanning random IP addresses for SSH servers and attempts to brute force
passwords for those systems that accept an SSH connection. Although software like
Fail2ban and DenyHosts can offer detection and mitigation by applying thresholds to
the number of failed login attempts in the SSH log and communicate offending source IP's
to a set of interested users, a fundamental problem is that the targeted SSH daemons
are reachable in the first place from arbitrary source IP's. A more powerful
solution is to hide your SSH daemon behind a default-drop firewall policy and only
grant access through Single Packet Authorization.
Any botnet that is scanning for SSH servers will not be able to guess any
passwords or even exploit a zero-day vulnerability in an SSH daemon that is protected
in this way.
I'm a big fan of the Smokeping
project developed by Tobi Oetiker, and I use it to graph ICMP, DNS, and HTTP round trip
times for my local internet connections and also for cipherdyne.org. Since the beginning
of 2010, I've switched around where cipherdyne.org was hosted from a system at a hosting
provider in Canada to a system running on my home network (serviced by a Verizon FiOS
connection). The drop in RTT's in mid-February was expected and quite large - going
from an average of around 200ms down to about 20ms. Then, in June, I switched to a
different Verizon DSL connection and moved the cipherdyne.org webserver system to a
newer Verizon FiOS connection at a different location, and the RTT's went up a bit to
about 50ms. Here is the graph:
The fwsnort project is now available directly through the
Fedora RPM repositories
(for Fedora 12 and 13) thanks to
Guillermo Gomez.
The version that is currently bundled is fwsnort-1.0.6. Once fwsnort-1.2 is
released, the implementation of large iptables rule sets that are derived from
Snort rules will become a lot faster. This is because fwsnort is going to
support the iptables-save format by integrating the complex rules built by
fwsnort with any existing iptables policy that is instantiated in the kernel.
This is made possible by interpreting the local policy and splicing in all
of the fwsnort rules in the right places - each iptables chain is built from
scratch upon an iptables-restore (including the built-in chains), so
integrating with a running policy is not as easy as just adding each fwsnort
rule into a set of custom chains. Compatibility with the iptables-save format
has largely been completed with this patch
in the fwsnort-1.2 development effort.
For the past several months, the pure-C implementation of Single Packet Authorization
with fwknop has been in development, and the first release candidate of
fwknop-2.0.0 is ready for download.
Damien Stuart is the primary developer of this code, and I wish to thank him for
all of his efforts in making this release possible. The original perl version of
fwknop will continue to receive bug fixes as they are found, but the primary
development effort is now on the lightweight and portable C code. The Trac
interface for the perl code has moved to
fwknop-perl. Any release
that is at fwknop-2.0.0 or above will be the C implementation, and any release in
the 1.9 series or before are in perl (and will remain available
here). The perl and C versions are compatible with
each other, so SPA packets created by the fwknop perl client can be properly
decrypted and decoded by the new fwknopd C server, and similarly SPA packets
built with the fwknop C client can be interpreted by the fwknopd perl server.
Russ McRee of holisticinfosec.org
has written the January Toolsmith
issue from the ISSA Journal about fwknop and the ability to create
ghost services with Single Packet Authorization. In his Toolsmith paper, Russ emphasizes
the possibility of using the ghost services concept to bypass strict outbound network
filtering rules on a local network in order to access an external service that is bound
to a port that is filtered by the local firewall. That is, the service is made accessible
by having the SPA packet created by the fwknop client request that the remote fwknopd server
create iptables DNAT rules to forward connections to a port that the local network actually
allows out to the port where the service is bound. Russ uses this concept to access a file
that is piped through a netcat listener on TCP port 6543, but do it from the heavily
filtered network over TCP port 110 (normally associated with pop3).