cipherdyne.org

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.

At the same time, the Ubuntu VPC host is also running a webserver. This is to illustrate that everyone out on the Internet can scan the externally routable Elastic IP (107.23.221.41 in this case) associated with the Ubuntu host and see that Apache is listening on port 80. (Note that this IP is not currently associated with my Amazon account.) But, no other services are visible to a scanner on the Ubuntu system because iptables is deployed in a default-drop stance for everything except for port 80. Even so, fwknop is able to create access through the iptables policy for SSH and RDP through the Ubuntu system over port 80 (i.e. SPA "ghost services"). These two scripts that are shown in the demo video illustrate gaining access to SSH and RDP:

$ 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
exit

To 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.

24 July, 2012

About a week ago at the HOPE Number Nine conference in NYC I gave a talk entitled "Recent Advances in Single Packet Authorization" (slides). In some respects this talk was a follow up to my talk on SPA and fwknop from the Last HOPE conference in 2008. Back then, the work on the all-C implementation of fwknop had just begun and this work was designed to address some of the questions that were brought up such as "have you audited all of the code in the perl module dependencies?" and "does the fwknop client run on the iPhone?". With the fwknop-2.0 release, the client does run on the iPhone and many other devices besides, and auditing huge code bases from dependent perl modules is no longer necessary.

Beyond this, fwknop strives to make sophisticated usage of NAT for authenticated connections, and this is realized with a use case whereby fwknop is used to protect against the recent Windows RDP vulnerability (CVE-2012-0002) within Amazon Virtual Private Cloud (VPC) networks. Of course, at this point the vulnerability has been patched, but for a time it wasn't and this is where SPA comes in. One challenge for this is the fact that fwknopd does not directly support a Windows firewall. The solution is to deploy a virtual Linux instance on the VPC network and then use either the normal SNAT/DNAT capabilities in fwknopd, or use the new FORCE_NAT mode. Either way, RDP connections can be made to internal Windows systems through the Linux "jump host" after a proper SPA packet is sent. Further, only one Amazon Elastic IP is required in order for this to work - the IP is bound to the Linux host and no externally routable IP is given to the Windows host. The Windows system only ever sees what appears to be a connection from the Linux host even though it has really been NAT'd through from the external Internet. Below is a network diagram that illustrates this, and more detail can be found in the slides. .

24 Nov, 2009

At the upcoming SANS Incident Detection Summit on December 9th and 10th I will be participating in two panel discussions. The first is entitled "Enterprise Network Detection Tools and Tactics" and is described by Richard Bejtlich (who has organized the whole conference) as a venue where "speakers with large-scale experience will share their tools and tactics for identifying suspicious and malicious activity". The second, "Detection Using Logs", focuses on the usage of platform, operating system, and application logs to detect intrusions, and Security Information Management and log aggregation and search systems will be discussed.

If you are going to be at the conference, please say hello!

10 Sep, 2009

UDPATE: The talk slides can be downloaded here and a video of the talk is available too.

On Friday November 6th I will be giving a talk on Single Packet Authorization with fwknop at the upcoming DojoCon conference at Capitol College in Laurel, MD. This talk will focus on some recent developments in the world of fwknop development and the resulting enhancements to SPA capabilities. Topics to be emphasized include:

• The new libfko C implementation and what it means for SPA deployments.
• Interface monitoring for administrative control changes and increasing packet counts. This adds an extra dimension of reliability for fwknopd server operations.
• HTTP proxy support, as well as the development of an SSL web gateway for sending SPA packets on behalf of client systems that cannot construct SPA packets themselves.
• Development efforts for future fwknop features (such as additional client integration, and deployments on embedded Linux distributions).

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.