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

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

blog.benjojo.co.uk

390 pointsluu61 comments

Maybe 20 years ago now, I wrote a simple email-to-sms script that I ran from procmail. To send the email out as SMS, it connected to a Verizon web site. This was before Verizon provided their own email-to-sms gateway.

I wrote and tested the script under OS X and it worked fine. I then moved it to my Linux server on the same network and it couldn't connect to Verizon's web site.

After using tcpdump to figure out what the difference was, I noticed that Linux was setting the ECN bit. Verizon had a firewall in front of their site that was apparently dropping packets with the ECN bit set. ECN was only a couple years old at that point. I think I figured out that it was due to an out-of-date Cisco PIX firewall on the Verizon end, but I'm not sure how I would have figured that out.

The solution was to disable ECN on the Linux box.

https://en.wikipedia.org/wiki/Explicit_Congestion_Notificati...

FYI, you can do email-to-SMS with various carriers just by sending to an appropriately-named email address. For Verizon, it's PHONE_NUMBER@vtext.com (text) or PHONE_NUMBER@vzwpix.com (pictures). No need for any website interaction.

Discovering this was a huge boon to my high school programming. I had a Gmail bot listening for commands like !weather which would text me an up to date weather report. This was 2005 and I was on a flip phone without a data plan working outside as a lifeguard.

How did you get the commands to the bot?

I've only seen one-way (email-to-SMS); is there a way to do the reverse, too?

Yes, the reverse just works for most carriers.

Just put an email address instead of a phone number.

Go ahead and try it out.

Verizon didn't have its own email-to-sms gateway at the time. This is not code that's still running.

Shout out to Matthew Dodd's commitment to the April Fools joke bit: https://svnweb.freebsd.org/base?view=revision&revision=11292...

My man added a sockopt, ping(8) option, documented all these changes in the manual pages, and added some fun sysctls related to the functionality.

This is the sort of thing that comes back to bite you. Websites that you think are down and ignore for now, annoyed but ok happens, only to later notice it was your own doing.

I played this on myself by setting X-Forwarded-For: '" which would trigger an sql error if someone assumes an IP address is safe to insert without escaping or parameterization. Very few sites broke, but the first one that did I remember sold TLS certificates.

I put a <script> tag that phoned home in my User-Agent header for shits and giggles when I was a reckless teenager, and went about my normal browsing. It broke a web forum's admin panel, and the owner of the site threatened to report me to the FBI. Nothing came of it, but I wonder if they would have had a case.

Forgive my ignorance, but what case could they have possibly had??

Who knows, but we live in a world where some people even consider “view source” to be hacking and attempt to prosecute them.

https://www.theregister.com/2022/02/15/missouri_html_hacking...

Computer Fraud and Abuse Act, "intentional access to a protected computer" maybe? Not a lawyer or prosecutor, but there have been some pretty ridiculous prosecutions under the Act in the past. I'm slightly nervous to even bring it up today, but I'm pretty sure the statute of limitations has run out by now.

Absolutely nothing would have happened at the time, and you have no reason to be nervous talking about it :) In my reckless teenage years I did far worse very often and nothing ever came of any of it.

Please refrain from replying with what could be construed as legal advice without the proper disclaimer. Different jurisdictions have different laws, and they can be draconian. For example, someone got into legal trouble (and wrote a blog post about the ordeal) after only a single attempt to browse to a URL from which they had accidentally deleted some text at the end.

A disclaimer should be implied for everything on the internet by default.

If someone wants to take some random anecdote from some random guy on the internet as legal advice that isn’t really my fault or problem - I’m not prefacing everything I write with an arguably useless disclaimer to account for such an absurd scenario.

Only people who would need to leave a disclaimer would be lawyers, and even they are saying it's out of an abundance of caution to ensure they are not viewed as giving a client legal advice.

https://news.ycombinator.com/item?id=36130359

Not really. I believe you are liable if the other person understands you are advising them based on your expertise in the specific field.

1. So if someone tells you they are a lawyer and then proceeds to tell you to do something illegal, they might be liable.

2. Some with engineers. If somebody tells you they make living wiring mains in houses and then proceeds to tell you to remove cover from a power supply and tweak it, they might be liable if you get shocked or your house burns down.

But I am not a lawyer.

For example, in Czech civil code there is something along the lines of:

> Section 5

> (1) Any person who publicly or in communication with another person presents themselves as a member of a certain profession or status, thereby indicating their ability to act with the knowledge and diligence associated with their profession or status, shall be held accountable if they act without the requisite professional care.

So you’re saying that you can be sued for telling a story, based on your life experience, just because someone on the internet interpreted it as advice?

So then every comment ever made that wasn’t intentional trolling and fiction then. Must be a backlogged court system with all those cases of someone being held liable for the perception of another. How does one prove they perceived something as advice? Wouldn’t it be easy to throw out short of the comment literally saying, “my advice would be”.

Parent had the evil bit enabled, maybe this tirade should have been directed to the routers and low-level apis that hid this important context.

This reminds me of the thing that used to happen on HN a lot, where a top-level comment would be someone going “I was wondering why someone wrote an article about ‘Butt-Native Functions’, but then remembered I have the Cloud-to-Butt extension running.”

Just looking at the other RFC's, it turns out the "packet mood" RFC also allows one to flag the packet as evil: https://datatracker.ietf.org/doc/html/rfc5841

> It is hard for a TCP packet to discern higher moral quandaries like the meaning of life or what exactly defines 'evil' and from whose perspective such a characterization is being made. However, developers of TCP-based applications MAY choose to see some activities as evil when viewed through their particular lens of the world. At that point, they SHOULD mark packets as evil.

Edit: Yay

1) add the check IP on the site to NFQUEUE

   iptables -A OUTPUT -p tcp -d 185.230.223.37 -j NFQUEUE --queue-num 1

2) write a little python script using [0] netfilterqueue and [1] scapy

   from scapy.all import IP, TCP
   from netfilterqueue import NetfilterQueue
   
   # Callback function for handling packets in the NFQUEUE
   def packet_callback(packet):
       pkt = IP(packet.get_payload())
       # Modify only outgoing TCP packets to the target IP
       if pkt.haslayer(TCP) and pkt[TCP].dport == 3560  and pkt[TCP].dport == 3561:
           # Set the reserved bit to 1
           # 6 ist DN und evil
           # 2 ist DN
           # 4 is evil
           pkt.flags |= 4
           del pkt[IP].chksum
           del pkt[TCP].chksum
           pkt.show2()
           pkt.show()
   
   
           # Print a message indicating packet modification
           print("Modified packet:", pkt.summary())
   
           # Update the packet payload
           packet.set_payload(bytes(pkt))
   
       # Accept the modified packet
       packet.accept()
   
   # Set up the NFQUEUE handler
   nfqueue = NetfilterQueue()
   nfqueue.bind(1, packet_callback)
   
   try:
       # Run the main loop
       nfqueue.run()
   except KeyboardInterrupt:
       # Cleanup on keyboard interrupt
       nfqueue.unbind()

3) analyze your packages with wireshark and find that your script works!

4) be sad because the response never arrives and your packages are treated as if they hadn't set the evil flag :(

EDIT: YES! I didn't see that he does 2 checks and the second uses a different port. NOW I'M EVIL!

[0] https://github.com/oremanj/python-netfilterqueue

[1] https://scapy.readthedocs.io/

Am I evil? Yes I am

Am I evil? I am man, yes I am...

https://www.youtube.com/watch?v=HMW0FtvU5iQ

Did anyone ever figure out why some domains were dropping evil packets? Were they dropping all packets with reserved bits set, or just evil ones? Did they have some infra in common?

My guess is that since the packet is officially reserved and should not be set, a common firewall or other security appliance considers said packets to be malformed and drops them as a default behavior.

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

The evil bit could be something of a self-fulfilling prophecy. Because no one uses it, that makes it a source of bugs/vulnerabilities; therefore, anyone setting it deliberately but not maliciously (such as for a joke) will want to turn it off; only those who want to exploit it maliciously will keep it turned on; hence, anything with an evil bit can be safely assumed to be, in fact, evil, and it should be filtered out automatically.

This is in line with the evil bit spec as per TFA:

> Devices such as firewalls MUST drop all inbound packets that have the evil bit set.

If you're a firewall vendor, it seems like a no-lose situation to drop packets with the evil bit. Either someone's experimenting like in this blog post, and you look cool because you implemented an April Fool's RFC, or someone is actually sending malicious packets, and you look like a competent firewall. Imagine if you didn't drop the packets with the evil bit, and a hacker thinks it's funny to add the bit to their packets while they're exploiting some unrelated vulnerability in your software. The post-mortems and exploit writeups would make you look incompetent - "this firewall vendor can't even stop packets that announce their evil intentions!"

Section 4 of the RFC says:

> Packets with the evil bit off MUST NOT be dropped.

That seems to be at odds with standard firewall operation, that may choose to drop packets because of all sorts of reasons unrelated to the "Evil bit". This would seem to constrain their operations unnecessarily, and so I would say that it is in the best interest of security vendors to ignore most of this RFC as frivolous and not binding.

No, no, that's the whole point - assuming standards-compliant users and attackers who follow this RFC, this simplifies firewall operation so that all packets with the evil bit off are not evil and can safely be forwarded, as any malicious traffic without the evil bit is simply noncompliant and should not be there, so any consequences of that are the fault of the noncompliant device (i.e. the attacker) as the firewall is operating properly according to the requirements.

I interpreted that as having an implicit “by this step of the filtering process”, not as applying to the entire firewall.

The purpose of the RFC is to simplify security on the Internet, make such decisions transparent, and to preserve clear separation of concerns between the layers. As such, the evil bit is supposed to be the only thing that a conforming device checks.

Otherwise, we're back to square 1, where you don't know what caused your packets to be dropped even though they are clearly and explicitly not evil!

He did specify that the listed servers only blocked on evil bits, implying they didn't block when other private bits were used

I don't see anything saying that in the blog post

> 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

This seems to be the comparison between a totally regular device and one with the evil bit set, he doesn't mention a device having any other private bits besides the evil bit set.

I am 100% sure that it was in the article that he listed the sites which only failed on the evil bit, and not on other reserved bits. I've read it 4 times again, and it is not there now. Strange.

Perhaps they were running TempleOS? :P That seems like one stack where the odds of evil-bit packets being deliberately blocked seems very high to me.

TempleOS has no networking support at all, so I suppose one interpretation is that it drops all packets with the evil bit set.

That seems crazy. When a new spec comes out and a previously reserved bit starts meaning something, you really don’t want old software to just drop packets as malformed. Reserved means ignore, not an assertion that it must be zero.

Welcome to the world of security, where experimentation and changes are frowned upon as risky.

it's the same flag position as fragment? i guess an evil packet is just being identified as one. instead of if 0x800==whatever value is marked as a fragment, some firewall just uses if 0x800!=0x0. /shrug

Some rogue employee at Google should set this for all their outgoing traffic since they dropped the "Don't be evil" bit.

Heck, from https://datatracker.ietf.org/doc/html/rfc5841

    Some organizations are prohibited from using this mood by mission
    statement.  This would also prohibit using the security flag in the
    IP header described in [RFC3514] for the same reasons.

I mean, that was obviously talking about Google

Haha reminds me of the one we made this year proposing adding barter system as a payment method to our processor: https://github.com/juspay/hyperswitch/issues/825, fun times :P

Discussed at the time:

I may be the only evil bit user on the internet - https://news.ycombinator.com/item?id=10632856 - Nov 2015 (36 comments)

(Reposts are fine after a year or so and links to past threads are just to satisfy extra curious readers!)

Somewhat of a meta question for @luu - how did you come across this post today before you resubmitted to HN?

I ask as I ended up searching for this article earlier today and thought about resubmitting (but ended up not doing so). It just seems a strange coincidence, unless there's something we both saw that made us think 'evil bit'!

It used to be like clockwork that a Wikipedia article would be submitted to HN shortly after Radiolab covered the same or a closely related topic.

I've also had similar déjà vu moments where something I had only just read about would be submitted to HN.

I think I've also seen the inverse happen, where you see a post about some phenomena on HN and only a few days later some science/IT YouTuber covers the same thing. In those instances I do wonder if that YouTuber was reading HN and thought to make a video about it, or if the HN submitter and the YouTuber had both had their brains tickled by some other source (eg. a podcast).

Sometimes you'll even see things come full circle where that YouTube video itself is then submitted to HN.

This is really great:

> it’s not even recognized by Wireshark and other systems...It’s even harder to look for these kind of packet in tools like tcpdump...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

Basically this provides a literally covert channel through which you can undetectably smuggle data between cooperating hosts. Lovely!

I wonder which version of Wireshark he was using; we've supported the evil bit since 2009.

I mean, you could set any other non-standard bit in the header and get the same "covert channel." There's nothing special about this bit aside from the fact that some middleboxes will drop packets that have it set (which makes it an unreliable channel and thus a particularly bad candidate for data exfiltration), and some monitoring tools will parse it. Whereas if you chose any other non-standard bit, you can guarantee no monitoring tools will know how to parse it, and it's unlikely any middleboxes will drop it (unless they're dropping any packet with non-standard bits in the header).

Here's a Linux loadable kernel module to make all outgoing packets "evil". (That I hope still works... haven't tested it in a while.)

https://github.com/alwilson/evil

There's a sort of beautiful irony in the fact that freedesktop.org is one of the few domains that properly implements the spec.

Knowing that the IT at Portland State is run by some very skilled old school hackers with a sense of humor, I would not be surprised at all if they managed to set this up on purpose.

The Cardiff University Network Team are funny guys

Really?

Because I heard they were just a bunch of

Cardiff University Network Team Services was the unofficial name for them when I did work experience there

Reminds me of the University of North Texas mugs.

Exercise to be left to the viewer.

Are there any domains that only accept evil packets?

Or sites that add an easter egg, give you a discount, that sort of thing. Don't need to alienate everyone-but-this-guy to have a unique thing, in case anyone is feeling like hacking something together tonight :D

brb setting up my personal site to redirect people with the evil bit set to a "jail" page, kinda like how all cheaters in Fall Guys are put into the same server by themselves [1]

[1] https://twitter.com/FallGuysGame/status/1305486780851007489

I was vaguely aware of this practice, but not the "evil bit" gag. The funniest thing I'll encounter today!

Reply on news.ycombinator.com