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.
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.
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.
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.
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”.
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.”
> 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.
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!
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.
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!"
> 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.
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!
> 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.
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.
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 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.
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.
> 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 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).
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.
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]
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...