Tuesday, January 05, 2010

Single Packet Authorization: The Ghost in the Machine

The first toolsmith of 2010 discusses one of my favorite concepts: single packet authorization (SPA).
In Single Packet Authorization: The Ghost in the Machine you'll discover the advantages of Michael Rash's (Cipherdyne) SPA with fwknop over Port Knocking:
1. SPA requires only a single encrypted packet in order to communicate various pieces of information, including desired access through a firewall policy and/or complete commands to execute on the target system.
2. fwknop keeps iptables in a "default drop" stance, thus protecting services such as OpenSSH with an additional layer of security, making exploitation of vulnerabilities (both 0-day and unpatched code) much more difficult.
3. With fwknop deployed, port scanners looking for sshd won’t find it; it makes no difference if a 0-day vulnerability exists or not.
4. The authorization server passively monitors authorization packets via libcap; there is no "server" connection in the traditional sense.
5. Access to a protected service is only granted after a valid encrypted and non-replayed packet is received from an fwknop client.
6. SPA can utilize asymmetric ciphers for encryption.
7. SPA packets are non-replayable.
8. SPA cannot be broken by trivial sequence busting attacks.
9. SPA only sends a single packet over the network; IDS will not interpret it as a port scan.
10. SPA is much faster because it only sends a single packet.

For this toolsmith I took Michael's concept of an SPA ghost service up a notch to show just how low and slow we can fly:
Imagine you’re part of a highly secretive pen testing team working on site with a major corporate client. The client is surprisingly secure, monitors well, and locks outbound traffic to http and pop3. They proxy and content monitor http traffic as part of data leak prevention, so anything you do over port 80 is likely to be noticed. Further, they block the vast majority of web addresses, limiting access to just a few approved sites. All said and done, you’ll get nowhere over port 80. However, traffic bound for port 110 is surprisingly not monitored due to an oversight. Helpful, but you still need to be very stealthy.
You’ve managed to sneak into their datacenter and deploy your workstation, but to further your foothold you need a customized Python script that didn’t make it in your toolkit when you deployed to the client site. Your handler back at your office can present the file to you via a one-shot NetCat connection like this:

( cat PSKpredict.py; ) | nc -q 1 -l -p 6543

Your handler set the NetCat listener to an uncommon port (6543) and has left the firewall closed. Remember, you’re a highly paranoid and hopefully stealthy organization. He has, however, allowed fwknop to open that port via access.conf (PERMIT_CLIENT_PORTS: Y;) when properly authenticated to.
Now you can bind fwknop to port 110 to sneak out of the client network and grab the file we need on the server back in the Batcave.

SPA with fwknop has unlimited potential as far as I'm concerned, and Michael's pending code revisions will likely only improve it further.

Read the whole article here, and be sure to visit cipherdyne.org.


del.icio.us | digg | Submit to Slashdot

Please support the Open Security Foundation (OSVDB)


Anonymous said...

Does it make sense to add an OTP (one time password) access layer after the ssh port is opened up by SPA ?

Russ McRee said...

With SPA via fwknop you're only "authenticating" to iptables in essence. Once the firewall opens the given port for you and forwards the traffic to the appropriate service, normal authentication requirements still apply. Thus if you use SPA for SSH, you'll still need to authenticate to the service in addition to you SPA password.
The one-time connection I describe is for use via NetCat, not SSH.
Once the single connection is made, the listener is no more.

Anonymous said...

Don't be silly, with modern wireless tech the pen team doesn't need to use the client's network to retrieve their script from their office. Unless they're inside a faraday cage or something.

Moving blog to HolisticInfoSec.io

toolsmith and HolisticInfoSec have moved. I've decided to consolidate all content on one platform, namely an R markdown blogdown sit...