Count Upon Security

It was 10 years ago that the Internet Engineering Task Force (IETF) released the Request For Comments (RFC) 3514 “The Security Flag in the IPv4 Header” authored by Steve Bellovin.

This RFC brought to the Internet community what  could have been the security silver bullet. What do you mean? Well, due to the fact that security devices like firewalls, intrusion detection systems, proxies and others have a hard time trying to determine if a packet has malicious intent or is rather normal. Steve Bellovin came up with the idea of creating the Evil bit, taking advantage of the unused high-order bit of the IP Flags field.

Very simple mechanism! Consider this: benign packets should have the Evil Bit set to 0 and those that have malicious intent will have the Evil Bit set to 1.

How does it work? When using offensive tools or crafting packets with malicious intent. The software or the attacker must set the Evil bit. For example fragments that are dangerous must have the Evil bit set. When executing a port scanning if the intent is malicious the Evil bit should be set. When sending an exploit via Metasploit the Evil bit should be set and the list goes on. On the other hand if the packets don’t have malicious intent the bit should not be set.

How should the security systems process such packets?

When processing packets, devices such as firewall should check the Evil Bit. If it is set they must drop all packets. If the Evil bit if off the packets must not be dropped.

Wonderful idea, but for those who don’t know the RFC was released on the April Fools’ Day. The Evil bit RFC was published on 1^st April of 2003. Like many others, this has been another humorous RFC. Humorous Request for Comments have been around for quite some time and is a good read if you have time and want to laugh.
Apart of the Evil bit one that is really hilarious is the RFC 5841 which proposes a TCP option to denote packet mood. For example happy packets which are happy because they received their ACK return packet within less than 10ms. Or the Sad Packets which are sad because they faced retransmission rates greater than 20% of all packets sent in a session. If you want to read more the Wikipedia as its complete list here or the book “The Complete April Fools’ Day RFC“.

Humor apart and for the sake of curiosity you could try to determine if any system process or reply to such packets. I used Scapy which is a powerful packet crafting and manipulation tool. It is written in python and let’s see how could we generate a TCP Syn packet with the Evil Bit set.

Before creating the packet lets just refresh our knowledge about the IP Flags field. In the IP header there 3 bits used for flags and according to the RFC 791:

Bit 0: reserved, must be zero
Bit 1: (DF) 0 = May Fragment, 1 = Don’t Fragment.
Bit 2: (MF) 0 = Last Fragment, 1 = More Fragments.

The normal combinations used with Fragmentation flags are shown in the following table:

In our case we want to generate a packet that has the highest order bit of the FlaView Postgs field set i.e. Evil Bit.

Which according to the RFC is reserved and must be set zero. However, we will use Scapy to craft a packet that has the Evil bit set with a fragment offset of zero and send it trough the wire and capture it using tcpdump.

#cat myevilpacket.py
#!/usr/bin/python
from scapy.all import *

ip=IP(src="192.168.1.121", dst="192.168.1.2", flags=4, frag=0)
tcpsyn=TCP(sport=1500, dport=80, flags="S", seq=4096)
send(ip/tcpsyn)

# python myevilpacket.py

I will leave the Scapy explanation for another post but would like to briefly mention the usage of flags=4. As you could see in the IPv4 header image the IP Flags field uses 3 bits.  These 3 bits are the highest bits in the 6th byte of the IP Header.  To set the Evil bit we need to set the value to 100 in binary or 4 in hex/integer.

The following picture illustrates the packet that was captured using tcpdump when the myevilpacket.py script was invoked  You could see the Evil bit on.