ShmooCon 2013 Talk on fwknop
22 February, 2013
Update 03/24/2013: All presentation videos have been uploaded to shmoocon.org,
and here is the full video for the talk discussed below:
video.
This past weekend at ShmooCon 2013 I gave a talk entitled "Generalized Single Packet Authorization for Cloud Computing Environments" (slides, video demo), and in this blog post I thought it appropriate to give an introduction to the talk in blog format. The main point of the talk was to show that it is completely feasible to integrate SPA as implemented by fwknop with Cloud Computing environments that conform to the Infrastructure as a Service (IaaS) model. In particular, it was shown that SPA can be used to protect and access both SSH and RDP services running on EC2 instances within a Virtual Private Cloud (VPC) in Amazon's AWS environment. Accessing SSHD via SPA by itself is nothing new and has been a primary use case supported by fwknop for a long time, but maintaining a default-drop packet filtering stance for RDP is a different story due to the fact that fwknop does not support a Windows firewall. However, through the use of both SNAT and DNAT capabilities within iptables, the fwknop daemon is able to convert an Ubuntu EC2 instance running within Amazon's Cloud into an "SPA gateway" that is able to then allow access to any service running on any other system within the VPC network - including RDP on a separate Windows host. Further, such access is granted through a single externally routable Amazon Elastic IP that is associated with the Ubuntu system. The Windows host doesn't even need to have a default route back out to the Internet - it always just sees incoming RDP connections from the Ubuntu host even though they really originate out on the Internet from whatever system is allowed via the SPA protocol. Here is a graphic to illustrate this scenario:
If you want a video demonstration of this all in action, this demo was given during the
ShmooCon talk:
Now, for more explanation, the following systems are depicted in the graphic above:
- The SPA client system that runs the fwknop client to send SPA packets and from which SSH and RDP connections originate.
- The Amazon border firewall.
- An Ubuntu host on the VPC network where the fwknop daemon runs.
- A Windows system on the VPC network where RDP lives.
$ cat ssh_access.sh #!/bin/sh -x fwknop -A tcp/80 --server-port 40001 -R -D 107.23.221.41 sleep 2 ssh -p 80 -i ~/.ssh/cdyne-vpc-testing.pem ubuntu@107.23.221.41 exit $ cat rdp_access.sh #!/bin/sh -x fwknop -A tcp/80 --server-port 40001 -N 10.0.0.223,3389 -R -D 107.23.221.41 sleep 2 rdesktop -u Administrator 107.23.221.41:80 exitTo see all of the above in action just watch the video. Hopefully the talk itself will be posted online soon, and when it is I'll post a link. More information can also be found in the talk slides.
Finally, I'd like to thank the ShmooCon organizers for putting on a great conference as usual, and I'm looking forward to next year.
Given this graph, it is apparent that Rijndael comes pretty close to producing data that looks
quite random across every byte position and there are no significant outliers. Now, let us run
the spa-entropy.pl script in --gpg mode in order to instruct the fwknop client to generate
SPA packets that are encrypted with GnuPG:
Wow, it is immediately apparent that there is something quite different about the measured entropy
for GnuPG SPA packets. There are three areas of interest: 1) the first four bytes, 2) two
bytes or so around byte 275, and 3) four bytes around byte 525. Why does the entropy fall
off so drastically at these locations? The first region is most likely an artifact of the
usage of the same GnuPG key across all SPA packets along with the fact that the fwknop client
only strips off the first two bytes if they match the string "hQ" in the base64 encoded SPA
data. This string corresponds to the same values that the /etc/magic database
provides to the file command - it is the same across all GnuPG encrypted data regardless
of which keys are used. But, the next four bytes aren't as predictable, and must vary from
key to key so the fwknop client can't use a simple strategy of removing these bytes before an
SPA packet is placed on the wire. (The whole reason for removing the bytes in the first place
is to make it slightly more difficult to write a simplistic Snort signature for SPA packet
detection.) The next two regions can be explained by the fact that the OpenPGP protocol
(see: 
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):
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.
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.
Pentoo
Kicking off 2011 with a bang is easy this year - Max Kastanas has ported the 
