Computer Stuff, Issue 4on 2019-06-23 by raylu
2 issues ago, I talked about how important IE6 was to the formative years of my programming experience. Perhaps more important to me was Battle.net 1. B.net was a matchmaking service for Blizzard games (I was late to the scene, so mostly Brood War, The Frozen Throne, and Lord of Destruction).
Like any good matchmaking service, it had chat. Unlike good chat services, the chat was... ungood. For example, the way you banned someone was by typing
/ban username. This banned the CD-key that the user was using at the time. This means that if that user disconnected, created a new account, and tried to come back, they wouldn't be able to because their CD-key would still be banned.
This is reasonable, probably. But the ban was also keyed on the operator that banned them. If the operator lost their channel operator status, the ban would be lifted.
This might be reasonable elsewhere. But B.net was intended for playing games. And when you joined a game, you left your channel. And leaving your channel means you lose your operator status. So bans are lifted as soon as you go play a game. (They're also lost as soon as you disconnect.)
This, I believe, motivated the first bots. You really wanted some piece of software that wasn't the whole game client to just sit around, holding operator status, maintaining bans. And so, those who came before me needed to reverse the login protocol. This was a little trickier than expected.
The Old Login System (or OLS) is the original login system used by Battle.net. It uses a modified version of SHA1 hashing that I'm going to call Broken-SHA1 for the remainder of this post. It's identical to SHA1 with the exception of an inverted shift or two. There's been a lot of discussion on whether or not this was intentional – to throw off reverse engineers – or a simple bug.
There's an implementation of broken SHA-1 here. Once you had that down, you were good to go. There's even community-written documentation of the protocol! I mostly figured out the protocol by reading other people's implementations of it, though, since I didn't really understand what DWORDs or bitops were.
And so the first bots came into existence. But once you could connect stuff to this chat service, you suddenly could... do all sorts of stuff. Also, remember how I said you banned people's CD-keys? This also meant that if you were on the receiving end of a ban, you could just come back as the same username with a different CD-key.
There were ways to deal with that. If you typed
/squelch username, that muted that user for you. But it actually muted that IP address for you. So if you only muted users you wanted to ban and you saw someone join who was muted, they must have come back on a different CD-key with the same IP.
You also couldn't ban CD-keys directly. You had to ban people by their username via
/ban username. If there was no user online with a given CD-key at a given time, there was no way to ban that key. Do you see the "solution"? To spam a channel, you connect, join the channel, send your spam, and then disconnect before you can be banned.
I'm sure by now, you've gathered that there was a sort of arms race. We called it "warring". But, simultaneously, there was also just... a lot of fun, stupid stuff. One of the more popular bots was written in VB6 (it was 2002). It supported a scripting language so you could customize it very easily! Let me just skip to the part where I admit that I regret writing some VBScript to make the bot ask trivia questions, give hints, and track scores.
You may also be wondering how people just had a bunch of CD-keys laying around. Even if you didn't want to go flood people's channels, you still needed a second CD-key just to maintain bans. I... also wonder this. People just gave me keys because I wrote code for them. But where did they get them?
The Exim Vulnerability
OK, back to your regularly-scheduled OSS vulnerabilities. The Return of the WIZard:
To remotely exploit this vulnerability in the default configuration, an attacker must keep a connection to the vulnerable server open for 7 days (by transmitting one byte every few minutes).
Sure, but what's with that name?
"The Return of the WIZard" is a reference to Sendmail's ancient WIZ and DEBUG vulnerabilities
The what vulnerabilities?
Sendmail uses large and truly horrendous configuration files. [...] In older versions, to avoid the overhead of reading and parsing that mess each time, there was something known as a "frozen" configuration file. [...] it was implemented in a very unclean fashion. And to understand it, it's necessary for me to digress and review the structure of a executable program in UNIX.
I love it when the explanation for a config vulnerability starts with an explanation of text/data/bss.
When sendmail was running in its normal production state, it appeared that wizard mode was enabled – the flag was in the frozen section – but that there was no password. Anyone who connected to the mailer port could type "wiz" and get all sorts of privileges, notably an interactive shell.
But when the code was being developed, the password was tested – and it worked. [...] So the wizard mode password always worked in testing, but never in production.
I just realized that it's been a month and I haven't reminded people of my favorite PHP bug!
There is no bug here, 00-00-00 means 2000-00-00, which is 1999-12-00, which is 1999-11-30. No bug, perfectly normal.
Sometimes, PHP apologists say that PHP is the way it is because Rasmus was too lazy to implement a real hash function for function names for his personal home page. There is some truth to that, but PHP is also the way it is because of this.
Matrix is some kind of decentralized chat protocol that is not a protocol and some reference implementations and something something IoT something AR something VR something.
On 2019-04-11, they discovered a security breach. That alone is not interesting enough to write about. The attacker posting a series of GitHub issues, on the other hand, is. (Actually, the GitHub account was suspended, but someone screenshotted and reposted them.)
I noticed in your blog post that you were talking about doing a postmortem and steps you need to take. As someone who is intimately familiar with your entire infrastructure, I thought I could help you out.
Some of this is the usual "you should have a ridiculously locked down environment and an unreasonably sophisticated monitoring setup", but some of it is actually straightforward to implement.