Ben Ehrlich provides his terrible opinions about all things technical.

Some People Hate it Oldschool

If you follow me on twitter, you saw that I launched a telnet version of Underground Dungeon. UGD is written in JS, so a port to Node + telnet module was pretty simple. My expectations were, as they are for most of my games, that my mom would play it, and that would be about all the attention it would get. In this case I was incorrect, and a large amount of bots seemed to have joined my mother in my fan club.


Telnet is an ancient protocol. It’s one of, if not the first networking protocol, developed at BBN when they were creating ARPANet (don’t cite me on that, but it’s somewhere in the vicinity of accurate). What telnet allowed was remote connection between computers. Telnet essentially emulated a terminal on the host machine. Today, telnet is primarily unused, in part because there is no encryption and all network traffic is visible.

My use case for telnet required no security. The goal was just to host my game there so people could play UGD over the telnet protocol. Why? Why not. Since A. there are no passwords or private data being exchanged throughout normal gameplay and B. no actual system access is given to players (the telnet server is directly serving the game) I figured telnet was safe, fun, and retro.

Release the bots!

You know where telnet is not safe, fun or retro? Apparently, many IoT devices. You can read about the details here on ZDNet, but the summary is, a wide variety of IoT devices have open, insecure, telnet services on them and can be accessed from the world at large. Malicious people are aware of this and attempt to take advantage of it.

How much? A lot. Like, in the order of billions. So it’s no shock that my humble telnet server, within HOURS of coming online, became the target of one of such attacks.

These aren’t the servers you’re looking for.

The IoT devices in the aforementioned attack all run a flavor of Linux called BusyBox. Technically, it’s not a distro, but a series of binaries designed to run on embedded systems. I had never heard of BusyBox until I started seeing it in my logs.

I launched the telnet server at around 5PM on Friday. At around 7, I tried to log into it but my connection timed out. I SSH’d into my VPS to see what was up and saw that the telnet server had crashed. Weird, I thought, but not entirely unexpected. The telnet module was pretty janky and I had very low expectations for its performance. I relaunched the server, and again walked away. I came back before bed and saw that it had once again crashed. This time I took a look at the logs. Two attacks were happening simultaneously.

The first attack was trying to write a file that would wget (located in /bin/busybox, so there’s a clue…) a file onto the system. Then it would mark it executable, then it would run it, presumably taking over the system in some nefarious way. This attack seemed to be targeting IoT consumer devices.

The second attack was repeatedly trying different username/password combinations to gain root access to the device. I believe it was this attack. Two reasons these attacks aren’t going to work (at least for now).

1. I’m not running BusyBox. There’s no wget located at /bin/busybox, so they won’t be downloading anything onto my system as it stands.

2. The typical telnet server, the kind these attacks are looking for, offer shell access to the device. When these bots connect they try to run sh which would put them in a unix terminal session. My telnet server is running a game, and that’s all it can do—there is no functionality built in to run any unix or telnet commands. So while they enter their multitude of commands and passwords, they’re being repeatedly asked if they want to start a new game, load, or quit.

The “fix”

I added a single line of code to the server which has stopped the crashing. Whenever someone types “wget” or “busybox” (words which will never come up in gameplay unless you have a very unique play style, but words that the bots constantly enter), they get booted from the server. No fuss, no muss. Going forwards, I’ll start logging the IPs of the bots and prevent them from joining in the first place, but right now I’m content to just sit back and watch bots get the boot.

Learn cool tech stuff! Take a class at Coditum!

The Quest for Non-Icy Frozen Yogurt – Part 1

My girlfriend, Isabel, and I are big fans of frozen yogurt, in part because of the great experience of serving yourself and all the fun toppings, and in part because of the delicious tangy stuff itself. Because of the quarantine (and because there’s only one frozen yogurt place in Boston), we’ve been trying to make our own frozen yogurt–with mixed, but mostly positive results.
Continue reading “The Quest for Non-Icy Frozen Yogurt – Part 1”

Snippet of the Day 2020-03-27

I want to get in the habit of posting little bits of code that have been useful in my day to day. Here’s a little snippet for material design labels. This creates the little rising effect using pure CSS. I built this to play nice with bootstrap.

<div class = 'mat-group'>	 
    <input type = 'text' class = 'form-control' placeholder = 'anything, but must be something.'>
    <label>The placeholder text.</label>

    .mat-group label { position:absolute;margin-top:-1.25rem; pointer-events:none; transition: all .3s ease; color: rgba(0,0,0,.26);}
    .mat-group input:focus + label,.mat-group input:not(:placeholder-shown) + label { position:absolute; margin-top:-2.7rem; font-size: .75rem; color:#009688; }
    input::placeholder {color:transparent !important;}

In action:

I Wish The Troll Farm Was Bigger

I wish the fake news making farm of trolls in whatever eastern European nation was bigger than it is. And I wish it was huge. I wish there was a small state where people reported to the factory, sat at a desk, and wrote mean comments all day. I hope this because it beats the alternative of a real (real large) body of people who are just that horrible to one another.

Continue reading “I Wish The Troll Farm Was Bigger”

Oh Settings, Where Art Thou

The removal of the headphone jack was a failure. We all know it. There is no one in the world who says “I’m so glad we got rid of the headphone jack so this phone could be .1mm thinner.” There are a lot of people who say, “I don’t want to spend $100+ on headphones that will be unrepairable in a few years,” or “I can’t charge my phone and listen to music at the same time.” Apologists say, “just buy a $x adapter, you can leave it in all the time,” but I’d rather not pay extra money to make a new phone have the basic functionality that my previous phone had.

To the same note: It’s been 7 years since Windows 8 released. We’re still dealing with the UI decisions and the fragmentation it caused in the Windows user experience. We know it was bad, and we continue to suffer with it.

Rewind to 2012. Exciting things are happening. Computers are getting touch screens, we’re looking at Intel processors in phones. It’s seriously looking like there might be a complete convergence of technologies—a momentary dream: run the same software across all ecosystems. Oh how naive we were.

Continue reading “Oh Settings, Where Art Thou”

Self Destructing Wolves (My Favorite Bug Ever)

I said I’d talk about the most difficult bug I’ve ever encountered, but I want to talk about my favorite bug instead. The most difficult issues I’ve faced in programming have been working with bad legacy code, but those stories are just me bashing my head against the keyboard because someone used !important on every other line of a stylesheet.

Instead I want to talk about my favorite bug ever, which took about 30 seconds to fix, but which I’m still thinking about five years later. Here’s the story of the self destructing wolves.

Continue reading “Self Destructing Wolves (My Favorite Bug Ever)”

Fun In Horrible API Land

There’s plenty of API horror stories out there, I figured I’d share mine. This is a story of a certain API of a certain piece of software and the trials and tribulations I went through to avoid making users upload a CSV file.

Background: There’s not a lot of software in the space of the company I was working for at the time. The quality ranges from poor to less poor and my company opted for one of the less flexible more stable bad options–I will call it Athletic. This was customer facing software that had a very decent user experience if you were a customer and a very bad experience if you were actually paying for it.

So I’m building a web app to be used internally at my company which needs data from the software in Athletic. The options are: 1. Download an excel spreadsheet that you can export from Athletic, convert it into a CSV, and upload it. This works, but is a painful process for users and this will need to be repeated weekly, sometimes more often. Option 2 is to use Athletic’s API. I opt for option two. So the odyssey begins.

Continue reading “Fun In Horrible API Land”