Ben's Blog Main Site | All Posts Twitter | RSS

I may be the only evil (bit) user on the internet

Almost every year a joke RFC is made on April 1st (these have caught on so well, that it’s now common to see more than one of these every year), or April Fool’s Day, and some of them are pretty great. Here are some of my favourites:

  • SONET to Sonnet Translation RFC1605
  • Hyper Text Coffee Pot Control Protocol (HTCPCP/1.0) RFC2324
  • UTF-9 and UTF-18 RFC4042
  • TCP Option to Denote Packet Mood RFC8541
  • The Null Packet RFC6592
  • Scenic Routing for IPv6 RFC7511

Though you can find a full list here: link

However my favourite one so far is RFC3514 or the “The Security Flag in the IPv4 Header”

One of the things that make RFC like the RFC3514 and RFC2324 (and others) great is that they are actually implementable, as in the case of the “Evil bit”. There is nothing stopping you from actually doing it.

Curious by this as of late, I wondered if anyone out there actually sets the bit. It isn’t a very well acknowledged RFC: even though it’s under the “Informational” category (as are all April Fool’s RFCs) it’s not even recognized by Wireshark and other systems

The reserved bit in wireshark is the evil bit

Some would say that Wireshark isn’t RFC3514 aware :) (Though someone tried to make it link)

It’s even harder to look for these kind of packet in tools like tcpdump, you have to resort to a rather unobvious filter of ip[6:1] & 0x80 = 0x80

In FreeBSD someone actually did the work and made it a option for your IP stack link however the patch was only in FreeBSD for around 24 hours before being reverted link

I have not been able to find any attempt at having this in the Linux kernel, so I made a patch link for it. Very rudimentary, forces you to always have the evil bit enabled on your outgoing packets (good enough for myself).

[email protected]:~$ uname -v
#110+evil SMP Sat Oct 24 19:08:01 BST 2015

Now that I have my home desktop recompiled with my new “evil” kernel, I am now sending almost all of my outbound packets with the evil bit set.

Am I alone in this?

In the RFC it mentions the following:

Devices such as firewalls MUST drop all inbound packets that have the
evil bit set.  Packets with the evil bit off MUST NOT be dropped.
Dropped packets SHOULD be noted in the appropriate MIB variable.

After spending 2 weeks browsing normally with my hacked kernel, I found only one site that I could not access only from my desktop. freedesktop.org appears to have rules set to drop evil bit packets. freedesktop.org is in the IP space of Portland University, so after even more digging I found that all of the Portland University address space drops evil bit packets!

This inspired me to go searching for sites that also had done this in the alexa 100k (at the time of writing, freedesktop ranks 35,426 on there link). After doing scans if I could connect to port 80 from a PC that had no evil bit kernel, and a normal one on the same network, I found the following list of domains that only failed on my evil bit computer, some of the interesting domains are:

Universities:

  • cf.ac.uk
  • pdx.edu
  • skku.edu
  • shmtu.edu.cn
  • tc.edu.tw
  • cardiff.ac.uk
  • upf.edu
  • uq.edu.au
  • usc.edu
  • chapman.edu
  • kctcs.edu
  • lonestar.edu
  • missouristate.edu

Banks/money handling companies:

  • citruspay.com
  • rbs.co.uk
  • rbsdigital.com
  • natwest.com

Software Sites/Companies:

  • kaspersky.co.jp
  • kaspersky.com
  • kaspersky.ru
  • teamviewer.com
  • caniuse.com
  • unicode.org

You can find the full list of top alexa 20k domains to look at here: link

I highly suspect the thing that links all of these sites together is a common appliance, since most of these sites are not under a security service, with the one exception of ddos-guard.net who seem to filter it on all inbound to their network. None of the listed sites above (other than the full list) use ddos-guard.net.

So now we know that sites target this bit to block, but the real question is why? Is it that someone didn’t see the date of the RFC, maybe sarcasm doesn’t translate very well, possibly someone in the real world actually sent the evil bit when doing evil things, and cause some products to target it?

Time for some security by obscurity

Now, it’s fairly obvious at this point that this is a bit that isn’t used that much. However lucky for you we can use that to lock down a port so it is only visible to “evil” people, meaning that most (if not all I suspect) scanners will never see this port, but people using the kernel patch can see it perfectly fine and without IP blocking.

Unfortunately iptables itself does not have a way to target the IP flags on a packet, however there is a useful u32 module for iptables link that you can use to target random bits in packets for your own use. The following IPTable chain whitelists people who use the evil bit to access a port:

iptables -N evil
iptables -I INPUT -p tcp --destination-port <port> -j evil
iptables -m u32 --u32 "3&0x80>>7=1" -A evil -j ACCEPT
iptables -A evil -j DROP

Obligatory tester

Please load javascript!

Closing

If you see a green “Evil is set” thing above ( aka this ), do let me know on either my email, [email protected] or tweeting me. Do let me know what equipment you also use.

If you happen to run one of the sites I have mentioned that drop “evil” traffic, please also let me know what firewall/router setup you use, I would love to know what drops the evil bit by default.


Like the blogging engine? Click here to see the code