cipherdyne.org

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.

04 January, 2008

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.

20 December, 2007

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.