649 stories
·
43 followers

Leaving "gifts" behind on dedicated server hosts

1 Comment and 2 Shares

I used to work in a place that had a bunch of machines that other people would pay to use. You might call it "dedicated" or "managed" or even "enterprise" hosting. A lot of it was just "whitebox" machines sitting on bread racks, but some of it was actually in proper racks (or "cabinets") with machines which were actually built for it.

Regardless of the hardware used, the model was about the same: you'd pay the company some amount of money for the right to do whatever you wanted with the machine, more or less. Obviously, if you screwed it up too badly, or installed some unsupported OS, you might not get much support beyond hardware replacement or reimaging it with a supported system, but it worked for most people.

I also became a customer of this world way back then, and have been ever since. This page is coming to you from the latest incarnation of this kind of server, for instance: just a box hanging in a rack somewhere in Dallas.

Recently, my mind turned to nefarious ideas. It was probably after writing that post about bad hardware getting into loops a couple of weeks back. That post was about hard drives being used by multiple distinct customers, but what about the rest of the machine? Are there parts that don't get "wiped"? Could you leave behind a little "gift" for the next customer?

This is where I put the "evil hat" on. So, I have root on the box, right? I also have out-of-band access to it so I can mess around with the console and/or "BIOS" settings. Basically, I can do all kinds of stuff on here. Reflashing it probably wouldn't be terribly difficult if I really wanted to.

That brings up a whole new bag of hurt: what are the odds that the hardware is going to enforce some kind of signed integrity check on that firmware? Maybe the main board itself will, but what about things like the NIC? Is it all that paranoid? What if it isn't? Could I put my own code on there? How about the BMC? There's a lot of goofiness out there, so I bet there's at least one hole on a lot of popular hardware.

Let's say I do that. Then I "return" the machine. It goes back into the pool, and then some other customer gets a hold of it. Meanwhile, my evil firmware is still on the box, right? Who actually checks that kind of stuff before they reuse hardware for another customer? I'm guessing the number is effectively zero.

Once the machine goes back online with a new customer, then I exploit the hole I left behind, and boom, it's mine again. Maybe I get lucky and find something particularly tasty and interesting. Maybe not.

I don't have an easy solution for this one. Building your own box and doing the co-lo thing is just far too annoying for a lot of people.

Read the whole story
afita
159 days ago
reply
Cluj-Napoca, România
Share this story
Delete
1 public comment
acdha
159 days ago
reply
This is a big problem: the answer is a trusted boot process like iOS uses but that has, not without reason, been resisted for also making things like perfect DRM possible and preventing users from installing open source operating systems. Limited demand means most vendors do a terrible job on the implementation, testing, and documentation and that means fewer people use it.
Washington, DC
chrishiestand
157 days ago
The big cloud providers are also getting pretty good at this: https://cloud.google.com/security/infrastructure/design/

Subprocesses are generally bad news

1 Share

Yesterday, I wrote about a confluence of well-meaning features which can create a serious disaster. It's what happens when you have a flag library, a means to change those flags by way of unauthenticated networks, and programs that run subprocesses. I glossed over a bunch of possible tangents in order to focus on that particular hat trick.

Today, however, is about the specific case of running subprocesses. In short, if you can make your system work without them, then do so! "Shelling out" to something else is a fantastic way to open incredibly bad holes in your system and potentially give the entire game away to whoever happens to find it first.

There are too many ways this can go wrong. I will attempt to describe a few of them.

First off, system(). This is a C library call which looks mighty tempting. It lets you run processes just by constructing a string. They run by way of a shell, and so respect PATH. This means you don't even need to worry about exactly where the binary lives. You can just system("git commit -m update") and it'll work well enough to make you think it's safe and good to leave like that forever.

The biggest problem here is that yes, it runs via a shell. Shells love to take all kinds of flexible input and do marvelous things with them. With that in mind, what if I can get you to put certain magic characters into the command? Going based on our git example from above, maybe instead of saying "update" as the commit reason, I can get you to say something I define. What if I tell you the commit reason is this?

foo ; touch /tmp/0wned;

What's going to happen? It's going to call out to this, isn't it?

/bin/sh -c git commit -m foo ; touch /tmp/0wned;

Congratulations, you just ran my payload.

"I'll just escape it" is a typical and yet unacceptable response to this. Odds are good that this will get screwed up, and someone will find yet another clever way to inject some command that would benefit them.

Maybe you use popen() instead. Assuming we're talking about the C library version here, guess what? You are also going through a shell, and are just as vulnerable. If you build up a command line and allow me to send you arguments, I can probably make you run my payload.

Python has variants on this. The usual popen-alike you find on Python doesn't usually run through a shell, but it can totally be done if you explicitly enable it. This means it might be vulnerable to this kind of injection if someone switched that feature on.

This is the point where you start grepping through your code base for calls to system() and popen() and whatever flag(s) Python uses to send it through a shell. Maybe you'll find something and can close the holes before someone else drives a truck through it. Maybe they already have.

Something like execve() is somewhat better, since you get to specify the target executable separate from all of the arguments, and there's no shell involved. It actually replaces your process with the new thing, so you have to figure out all of the stdin/out/err business, potentially closing outstanding fds, not running afoul of "things to not run after fork and before exec", and all of that fun stuff. It also means you control the environment of the new process, and can exclude a bunch of nasty stuff that might otherwise be provided by an attacker.

Still, if you can swing it, the only way to win this game might be to not play at all. If a program is just calling into a library, maybe you can do that yourself. Besides avoiding the possibility for command injection, and having to deal with forking and execing and doing that correctly, you can just call into it and call it done.

Obviously, this isn't always an option. It's not like you can call into some magic library that'll do what a call to gcc or g++ would otherwise do. There are many more examples of programs which don't exist in terms of user-facing libraries and will only deal with you through their human-facing CLI tools. In those realms, all you can do is wrap the programs and hope for the best.

One thing to consider is the possibility of explicit separation of responsibilities. Maybe you're stuck having to run some other program for some reason. You have no choice in the matter. Well, nothing says you necessarily have to do it inside the same process, right?

To abuse the earlier mention of gcc, one really bizarre approach would be to have something sitting there waiting for the call over loopback (or a Unix domain socket), which would then accept a few well-specified parameterized requests and would then run gcc in a really sparse environment (chroot, "container", that sort of thing) and kick back the results. It could run as a totally different account, too, so if something truly bad happened, it wouldn't have access to much else.

A cheeky name for it might be "RCE as a service".

Of course, now you have a dispatch problem, and a bunch of lurking processes waiting to be discovered and mistreated, and the matter of authenticating/authorizing requests to those dispatchers, and so on. You might wind up trading one set of problems for another.

In any case, take a few things away from this.

First, subprocesses are a code smell. Avoid them whenever possible.

Second, popen() and system() are really hard to use safely.

Third, if you don't need to allow modifying the environment and/or arguments handed to a subprocess, don't let it anywhere near user-supplied data! Make those things run from hard-coded constant strings or something to that effect. Don't substitute, concatenate or otherwise "taint" the future program's argv[] with data from a potential attacker.

Finally, if you can, wall this stuff off in some sort of jail.

Read the whole story
afita
161 days ago
reply
Cluj-Napoca, România
Share this story
Delete

Manual Work is a Bug

1 Share
Every IT team should have a culture of constant improvement - or movement along the path toward the goal of automating whatever the team feels confident in automating, in ways that are easy to change as conditions change. As the needle moves to the right, the team learns from each other's experiences, and the system becomes easier to create and safer to operate. A good team has a structure in place that makes the process frictionless and collaborative
Read the whole story
afita
166 days ago
reply
Cluj-Napoca, România
Share this story
Delete

Care-i schema cu media?

1 Share
Intrate în penurie de finanţări, hoiturile deontologice de presă încep să capoteze rând pe rând. Realitatea TV - o televiziune fără audienţă, dar cu propagandişti isteroizi - îşi vede sfârşitul previzibil odată cu penalizarea şi înlocuirea judecătoarei care-a reuşit să întindă un faliment dincolo de limitele bunului simţ. România Liberă, la presiunea lui Alexander Adamescu, a aruncat peste
Read the whole story
afita
190 days ago
reply
Cluj-Napoca, România
Share this story
Delete

Linux nm Command Tutorial for Beginners (10 Examples)

1 Share

HowToForge: If you are a Linux user who is also into system level software development, you may find yourself in situations where-in you need information related to symbols in an object file.

Read the whole story
afita
190 days ago
reply
Cluj-Napoca, România
Share this story
Delete

Despre finante personale

1 Share
Am fost profund impresionat de articolul de ieri al lui Cristi Dogaru(Alături de creditori până la moarte şi dincolo de ea). Cred că este unul dintre articolele pe care ar trebui să le citească oricine pentru a şti cum şi ce să nu faci cu banii. Într-adevăr, vremurile în care trăim aduc după sine multe iluzii pe care, dacă le urmezi, rişti să-ţi ratezi întreaga viaţă.  Cu ceva vreme v-am
Read the whole story
afita
191 days ago
reply
Cluj-Napoca, România
Share this story
Delete
Next Page of Stories