I may be the only evil bit user on the internet | Hacker News Reader

I may be the only evil bit user on the internet

blog.benjojo.co.uk

295 pointsbenjojo1236 comments

The "security by obscurity" bit is interesting. I'm now imagining a server where it checks that the initial sequence number of the SYN packet ends with your current OATH two-factor authentication code, or something, and it drops the packet if you have the wrong code. (Which elevates it quite a bit past simply "obscurity.") The traffic is indistinguishable from normal SSH traffic, and there's very little code that has to process anything from untrusted sources.

While not quite to the same level of obfuscation, your suggestion reminded me of this project: http://www.cipherdyne.org/fwknop/ Its essentially port knocking with a single encrypted packet.

Haven't tried it (yet) myself but sounds interesting.

See fwknop and the history of port knocking.

Some information on this is located in the fwknop tutorial:

http://www.cipherdyne.org/fwknop/docs/fwknop-tutorial.html

I just hope that anyone doing that only does it with private networks. I still remember that painful time I had to debut the fact that someone was blocking the heartbeat TLS extension by simply dropping traffic and I had a product that most of the time sent that extension by default ("everything else can connect, so it's clearly your fault that you cannot"). I also hope that said network actually patched Heartbleed, but I sincerely wonder about that.

While a very good story, I suspect the offending firewalls might drop traffic with any of the reserved bits set, not just the "evil" bit. Very fun exercise though!

This seems like a really bad thing to do. If any of those reserved bits get used for a legitimate purpose in the future then none of these networks will be accessible. Reserved should mean "set to 0 when you send, ignore on when you receive". It's not like these bits actually cost any additional processing. There's literally no benefit to dropping these packets, and it's shenanigans like this that mean we can't improve protocols easily in the future.

I wonder how many routers are filtering IPv4 packets with fragment offsets of 8190 and 8191?

Firewalls and other middleboxes are notorious about doing very bad things like this to the detriment of the internet as a whole. See PMTU discovery, why it was impossible to deploy TCP RED or SCTP, etc.

"Windows DNS is broken" was a meme for about five years due to Cisco ASA's blocking EDNS traffic.

This may be better than allowing the bit to desynchronise your firewall's state machine. However, if you want to be nazi like that you may actually prefer not to route your network to the Internet at the IP layer but rather provide application-level proxies (IIRC Check Point products can be configured like this).

The evil bit is the only reserved bit left in the IPv4 header, IIRC.

It looks like they're performing exactly to spec, which states packets with the evil bit set MUST be dropped.

In 1990 Bergen LUG implemented TCP over Avian Carriers. http://www.blug.linux.no/rfc1149/ The ping over that link was not good http://www.blug.linux.no/rfc1149/pinglogg/

The RFC is from 1990, the implementation from 2001.

I was in Bergen at the time, repairing concrete (ok, mostly chiseling out the old). Little did I know : )

> 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?

I think it was done just for fun. It is slightly concerning that a live equipment has such a joke enabled, but I'd say its fun-to-price ratio is relatively high.

I'm not intimately familiar with the RFC's but you could argue that since that bit is technically `reserved` when it's set the packet is 'invalid' and thus should be dropped (by some manufacturers reasoning maybe, not mine specifically)?

Also: IIRC IP packets contain CRC's/checksums of some sort. I'm not sure if the poster corrected for that or maybe the other side does(n't) and somewhere the CRC doesn't check out and thus the packet is dropped/invalid (or maybe even somewhere along the way by at a hop that chokes on such bit)?

Reading RFC 791 again, it is said that the reserved bit "must be zero".[1] I'm not sure if it is reasonable to force a "reserved" flag to be a certain value, but I guess if one is following the RFC rigorously, dropping packets with the reserved bit enabled is the correct behavior?

[1] https://tools.ietf.org/html/rfc791

If you don't force it to be a certain value, its hardly reserved. Then it's just a free bit that anybody can use for anything. Reserved means it has to be able to be used for something else in the future, and for that to be possible it has to have a known default value.

No. Imagine tomorrow a new RFC suggest to use the reserved bit for something meaningful. Any implementation that check that bit and drop the packet if the bit is 1 is broken immediately, even if it is not impacted.

True story, some years ago I had to design a protocol for remote configuration using text messages. We used a char to send the status in a compact format but in the first version we used only the first 3 bit and we specified that all the other bit should be zero (we have done so in order to have a predictable default in the future and also to increase the readability of the logs). After few months in the field we noticed that using an additional bit would be useful. Don't want to go into many details, not a problem if the bit is ignored but nice to have to simplify the operations. We updated the protocol, issued the new specs, the vendors develop the new version, we test the new version and surprise: the IOT between the new server and the old client was broken. Why? Because the designer the implementer of the client was to strict on the must be zero clause and decided that a packet with a one was a corrupt packet and should be dropped.

The result was a slow campaign of firmware upgrade and a 1 year delay of introduction of the new protocol. And it was a closed system where we had full control of clients and servers. Imagine what happens with open systems.

By the way, it is an application of this principle: https://en.wikipedia.org/wiki/Robustness_principle

He patched the IP stack, so the checksum should be correct.

Agreed, but maybe the other side (or any of the hops in between) have some weird and/or incorrect implementation on which the CRC/Checksum fails because the bit is set? I'm not sure what would happen if the bit is excluded from the CRC calculation but included in the check against/with the CRC for example. Would be a nice edge-case to test and, ofcourse, shouldn't fail. But who knows, maybe it does somewhere along the line?

Also, as barosl observes (https://news.ycombinator.com/item?id=10633361): "but I guess if one is following the RFC rigorously, dropping packets with the reserved bit enabled is the correct"

I don't know about RFC reserved bits, but I believe the linux kernel's policy is to enforce that any unused bits (in say, a bit flag field) MUST be zero, because otherwise some programmer will leave them uninitialized or something and break everything when they suddenly have meaning.

I yearn for a world in which that RFC were viable.

I love that anyone's implemented it at all though, and I really hope it's deliberate on the part of the people who drop the packet.

> I love that anyone's implemented it at all though

Similarly I have had a page online for years (may still be, can't remember the exact url... so I'd have to dig a little) that was served with HTTP status

  418 I'm a teapot

See https://tools.ietf.org/html/rfc2324#section-2.3.2 :-)

http://www.google.com/teapot :D

Visit that link on your phone and tilt it.

You can just click/tap the pot instead.

Unfortunately it isn't clear what might be considered "evil" or an "attack". Probably section 1.1 should be extended accordingly.

One of the domains that identifies and drops evil bit packets -- Kaspersky.com ... Smart, Kaspersky, smart.

Funny enough, we found a practical application for this during my time at BreakingPoint. The BPS-1000 appliance would mix a huge number of concurrent streams through a device under test; we added a feature to flag the exploit traffic as evil by setting the RFC 3514 bit: https://strikecenter.ixiacom.com/articles/permalink?month=06...

This made it easier for manufacturers of IDS/IPS/UTM/NGFW equipment to quickly isolate false negatives during fully loaded tests.

What's going on here, exactly?

Author modified his OS kernel to set the "Evil Bit" (as proposed in RFC3514) on every TCP Packet Header. Having scanned the Alexa 100K, the author found that some servers actually followed RFC3514 and dropped traffic with the Evil bit set.

excellent ELI5!

The evil bit is valuable; but with byzantine attacks who knows what to believe.

Some of the websites used probably Kaspersky software (anti virus, etc. from Eastern Europe)

Reply on news.ycombinator.com