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.
Cheers.
del.icio.us | digg | Submit to Slashdot
Please support the Open Security Foundation (OSVDB)
Subscribe to:
Post Comments (Atom)
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...
-
Continuing where we left off in The HELK vs APTSimulator - Part 1 , I will focus our attention on additional, useful HELK features to ...
-
As you weigh how best to improve your organization's digital forensics and incident response (DFIR) capabilities heading into 2017, cons...
-
Ladies and gentlemen, for our main attraction, I give you...The HELK vs APTSimulator, in a Death Battle! The late, great Randy "Macho...
3 comments:
Does it make sense to add an OTP (one time password) access layer after the ssh port is opened up by SPA ?
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.
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.
Post a Comment