11 ms·
I may be the only evil (bit) user on the internet (2015)
- dang 3y agoDiscussed at the time: I may be the only evil bit user on the internet - https://news.ycombinator.com/item?id=10632856 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!)
- jefftk 3y agoDid 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?
- korethr 3y agoMy 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.
- TZubiri 3y agoHe did specify that the listed servers only blocked on evil bits, implying they didn't block when other private bits were used
- deleted 3y ago[deleted]
- Terr_ 3y agoPerhaps 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.
- eindiran 3y agoTempleOS has no networking support at all, so I suppose one interpretation is that it drops all packets with the evil bit set.
- jackbondpreston 3y agoI don't see anything saying that in the blog post
- philately 3y ago> 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
- DaSHacka 3y agoThis 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.
- bmacho 3y agoI 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.
- wwalexander 3y agoThis 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.
- TechBro8615 3y agoIf 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!"
- NoZebra120vClip 3y agoSection 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.
- gbear605 3y agoI interpreted that as having an implicit “by this step of the filtering process”, not as applying to the entire firewall.
- tsimionescu 3y agoThe 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!
- gwern 3y ago> 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.
- NotYourLawyer 3y agoThat 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.
- tsimionescu 3y agoWelcome to the world of security, where experimentation and changes are frowned upon as risky.
- alwifjlskdfj 3y agoit'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
- loeg 3y agoShout out to Matthew Dodd's commitment to the April Fools joke bit: https://svnweb.freebsd.org/base?view=revision&revision=112929 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.
- robinduckett 3y agoThe Cardiff University Network Team are funny guys
- BLKNSLVR 3y agoReally? Because I heard they were just a bunch of
- robinduckett 3y agoCardiff University Network Team Services was the unofficial name for them when I did work experience there
- BLKNSLVR 3y agoReminds me of the University of North Texas mugs. Exercise to be left to the viewer.
- NavyG 3y agoHaha 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 https://github.com/juspay/hyperswitch/issues/825, fun times :P
- doctor_radium 3y agoI was vaguely aware of this practice, but not the "evil bit" gag. The funniest thing I'll encounter today!
- BlackLotus89 3y agoEdit: 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 https://github.com/oremanj/python-netfilterqueue [1] https://scapy.readthedocs.io/ https://scapy.readthedocs.io/
- mindcrime 3y agoAm I evil? Yes I am Am I evil? I am man, yes I am... https://www.youtube.com/watch?v=HMW0FtvU5iQ https://www.youtube.com/watch?v=HMW0FtvU5iQ
- LordDragonfang 3y agoThere's a sort of beautiful irony in the fact that freedesktop.org is one of the few domains that properly implements the spec.
- xwdv 3y agoAre there any domains that only accept evil packets?
- lucb1e 3y agoOr 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
- datenyan 3y agobrb 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 https://twitter.com/FallGuysGame/status/1305486780851007489
- lucb1e 3y agoThis 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.
- greyface- 3y agoI 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.
- hext 3y agoForgive my ignorance, but what case could they have possibly had??
- greyface- 3y agoComputer 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.
- js2 3y agoMaybe 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_Notification https://en.wikipedia.org/wiki/Explicit_Congestion_Notificati...
- interroboink 3y agoFYI, 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.
- js2 3y agoVerizon didn't have its own email-to-sms gateway at the time. This is not code that's still running.
- 8organicbits 3y agoDiscovering 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.
- interroboink 3y agoHow 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?
- bearbin 3y agoSomewhat 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'!
- 22c 3y agoIt 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.
- blunaxela 3y agoHere'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 https://github.com/alwilson/evil
- gumby 3y agoThis 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!
- geraldcombs 3y agoI wonder which version of Wireshark he was using; we've supported the evil bit since 2009.
- TechBro8615 3y agoI 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).
- kerblang 3y agoJust 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 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.
- _yb2s 3y agoKnowing 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.
- pcthrowaway 3y agoSome 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 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