Happy April 1st! This post is part of April Cools Club: an April 1st effort to publish genuine essays on unexpected topics. Please enjoy these true stories, and rest assured that the tech content will be back soon!

The mouse started moving. Not the one on the desk, the pointer on the screen! First to the left, then down to the bottom corner.

*Click!* The Windows Start menu came up.

"cmd" wrote a silent hand on an invisible keyboard. It downloaded a file from a random-looking URL, then executed it.

*Pop* went both the computer and the illusion of security.

A cartoonish computer sitting on a desk, with a desktop view displayed on the screen. A shady hand breaks the fourth wall, reaching directly into the computer screen to grab and control the mouse pointer.

Backing up a bit: I was in college in the early 2010s, taking a class on computer security. My team was presenting our final project: a security audit of Swiss cheese popular "PC remote control" mobile apps. We chose this app category on purpose: it's easy to make a working app, and very hard to make a safe working app there. While one or two well-established companies had offerings in this market, price pressure was doing its thing and the most-downloaded apps were free or freemium from "not a household name" publishers. More on that in a bit.

We set the tone with a demo. We fired up a Windows VM and installed an app's PC-side agent.

We made a great big show of setting a 💪 strong 💪 password on the agent: 20 characters long, freshly generated by random.org. Pfft, nobody is breaking in now! Right?!

Not even two seconds later — you heard the story. Our shellcode pwned the computer. Oops!

This post isn't nearly long enough for the entire comedy of errors we found in those apps. I'll describe only the three most amusing ones:

Aside: "Amusing" vs Security Vulnerabilities

"Amusing" isn't a word I'd normally use to describe a security vulnerability. Usually, a team of engineers worked hard and did their best to build a robust system, and yet a flaw slipped by unnoticed and users may have gotten harmed as a result. That's tragic, not funny.

The situation here is the exact opposite from that usual case. Here, it's "free mobile app with no ads and no clear business model wants you to install some software on your PC so the app can work properly." Can you guess the general business model now? Of course, not all free apps are like this. But to paraphrase Patrick McKenzie, crime has a business model. Successful business models have more money to spend on marketing, design, and app polish, so it's very likely that the top contenders in each app store category have some kind of business model behind them. Exceptions exist, but we call them "exceptions" for a reason.

That's right — the PC-side agent software for most of these apps came with surprise bonus DLC packs that your OS security suite might object to. One such app directly bundled off-the-shelf malware in the installer; another spun up a file server featuring your system's photos directory, put it on an open port, and then said "hi, here's my public IP and also my behind-the-NAT IP address" to another server on the internet — just to make sure your photos are extra easy to find. The photo server functionality was never mentioned in either the PC agent or the mobile app. It was not a component of any user-facing feature in either of them. It was not even hinted at in any documentation, release notes, or settings that we could find. Any explanation that doesn't include the words "purposefully malicious" would be a stretch so big that we'd need the Voyager space probes to find its other end.

These apps were out to pwn their users. These were not apps trying hard to be secure — they were trying hard to look secure, and failing hard. Many cryptographic schemes can support covert backdoors, and you won't find any of them here. We can laugh at the poor attempt at (in)security.

Okay, back to the story!

Protecting Only Half the Bits

Most of the apps we surveyed encrypted the data sent between the mobile app and the PC-side agent.

Yes. Most of them. That was the bar here — it was set to "trip hazard."

What encryption? Oh, you know, "XOR each byte with 57" for example 🤦‍♂️

Why 57, though? We didn't find a definitive answer. The app authors didn't leave any helpful code comments like "chosen by fair dice roll." But we had a hunch based on our knowledge of cryptography.

You see, properly-encrypted data should just look like a bunch of random bits. Curiously, the byte value "57" happens to have four "1" and four "0" bits (00111001) so "XOR 57 each byte" flips exactly half the bits in the message.

Then clearly each bit in the message has a 50% chance of being flipped, making it properly random! (Lol, no! That's not how math works 😆) But that was our theory for why the authors chose 57.

"Ah! They should have XOR-ed with 255, so all the bits could get protected," quipped our professor in response to our theory.

The Challenge-Irresponsible Protocol

Bad encryption doesn't explain how we broke in, though. There was still a password check to get past.

That particular app also implemented a home-grown challenge-response protocol for user authentication: Natural, really, given the existing investment in custom cryptography!

But wait ... where's the password here?

The password is in the challenge string, duh! The server's challenge is the unsalted SHA-256 of the password!

Yes: not only was the password not required to log in, but the server kindly leaked the password hash as part of every login attempt. Over an "XOR 57"-encrypted connection, of course. Of course! 🤦‍♂️

Enough about this poor app. Let's switch gears to a competing app in the space.

The "Kindness Opens All Doors" Protocol

Choosing the right authentication scheme can be a hard, multi-dimensional problem.

We want attackers kept out at minimum expense, and legitimate users let in with minimum hassle. Checking passwords can be expensive, CPU and memory-intensive work! If you're doing it right, at least. Not much of that energy in this story though! Without Fail2Ban-style safeguards that ban users after a sequence of incorrect password guesses, servers that check passwords can be subjected to a variety of attacks: dictionary attacks, credential stuffing attacks, or even plain old denial-of-service attacks that just aim to waste server resources.

"Aha," said one of the apps we looked at, "we can fix this!" Be worried. Be very worried!

How did the app fix it? An exotic scheme like Simultaneous Authentication of Equals? Something common like SSH keys? Boring old HTTP authentication sent over HTTPS?

I wish.

It checked the password only on the mobile app 🤦‍♂️

This poses two interesting questions!

First: if the PC agent program doesn't check the entered password, how does the communication protocol between mobile app and PC agent actually work? For example, what happens if you skip past the authentication portion of the protocol, and just start sending PC control commands like "move the mouse" or "type in text"?

What happens? What happens is this: the mouse moves, and the text gets entered!

Authentication is optional from the PC agent's point of view! In practice, legitimate users will use the app and attackers will use shellcode instead of the app. So in practice, this system annoys legitimate users by requiring a password and lets attackers in at minimum expense — completely backwards!

This brings us to the second question. Recall from our demo that users set the password on the PC agent, but the password check happens on the mobile app. How does the mobile app learn the password to check against?

It very kindly asks the PC agent to send over the current password — in plain text, of course!

Kindness opens all doors indeed — especially when users reuse passwords!

Hope you enjoyed this true story! April Cools is about surprising our readers with fun posts on topics outside our usual beat. Check out the other April Cools posts on our website, and consider making your own blog part of April Cools Club next year!

If you liked this post, consider subscribing or following me on social media.