- 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
Finally a comment that makes sens
Thinks Celina Nunes & Machtyn
Admin
Sql injection and XSS, for example, are very common and if they exist, have a high level of damage potential. This vulnerability in particular gives an attacker elevated privileged access to command-line on the server.
As far as your "list" of things to check for, OWASP has already thought of this and provides tutorials, libraries, etc. for developers to not create poorly written, insecure code. This kind of stuff is really inexcusable in this day and age given the awareness and help out there for developers; they just have to care a little bit and look for it.
Admin
It is funny how (nearly) everyone focus on the chmod part and try to chmod the entire system. That will in many systems render the OS useless. It is much more interesting to inject random code using the standard *nix shell command separator (";"), as some have indicated...
Admin
Crack a few passwords, see if those users have the same passwords elsewhere (email, network drives, etc.), maybe steal some confidential files or other company secrets. Why ruin somebody's day when you can destroy their company entirely?
Admin
Not only is there the classic WTF with chmod (which I now have a headache from banging my head against the wall) but there is also a WTF that there was a person like Armid who was knowledgable and had power to stop such horrid code before it went into production.
Admin
OK, useful information coming....
This is why at many places, and not just on *NIX machines, world write except to some very well know things that must be this way, (like /tmp, and /var/tmp) is considered a major security issue.
Routinely you scan the whole file system for any files that have world write and track down the program/person doing this and smack them hard.
Of course we had one group of idiot devs lead by an idiot that would keep setting all files for their application to 777. It seems if they had any problem with the app their first debugging task was to set everything to 777 because those damn sysadmins must have changed something.
Of course the admins never made a change to the app, and the protection change never fixed the problem and they would have to actual read logs and do real support.
A few weeks later a standard "look over the system" by HQ mandated security scripts would find the world write files. Nasty emails would be sent, files changed back to something sensible and the app would continue to run just fine.
Later - Rinse - Repeat.
One day I brought this pattern up to the idiot leader of the group of devs. His answer was
"God created 777 for a reason"
To all you devs out there. Stop requiring a log file or some other thing to be world write because you don't understand how protections work. In your install packages, RPMs, software depots, etc., stop delivering files with world write on them for no reason.
(I'm looking at you IBM. Why do the software license agreement text files have to be world write?)
The TRWTF is that the sys admins haven't been jumping up and down at an app creating or setting files to world write. It would have been traced back to this code which is a disaster waiting to happen.
Second RWTF, why does someone feel the need to make a system call to chmod. Let's see how well that works on non-*NIX systems.
Admin
Admin
Everyone knows the Deadly Cookie is Matt Cooke
Admin
Told you C is dead
Admin
Or, you could install TamperData for FireFox... and edit your cookies on the fly.
Admin
OK, so explain how a web server running in a chroot jail as a non-root user has any problem coping with this.
Any web server not running in a chroot jail as a non-root user is the real WTF.
Admin
OMFG this has at least a dozen code smells and they are all nauseating.
If you call yourself a web developer and you didn't see even one thing wrong in the first two seconds of looking at that abomination, please please for the sake of all who have to share your planet, take your mouse and go give it to someone responsible. Yes, right now!
You can keep your keyboard. After two years of using that exclusively you may have learned enough to get back into web development. If not, there's no hope. Go wash cars or something.
Admin
Admin
I suppose the Armid would have only read one line. The full code snippet might be something like this.
if (( is_file($_COOKIE["$sessionid"] ) && ( strcmp(dirname($_COOKIE["$sessionid"]), "/tmp/session_ids") == 0) ) { ... ... ... system("chmod 777 " . $_COOKIE["$sessionid"]); ... ... } else { // handle the invalid sessionid here }
So stop read single line of code and try to understand the big picture.
And seriously what is a tester doing looking up at the source code? Is he a tester or a code reviewer / auditor?
Admin
I think every developer should have their mouse taken away for two years as standard practice so they can learn how to use the shortcuts built into $IDE, which saves a lot of time, really.
Admin
Nope, still a WTF. There is no valid situation for setting 777 on a public facing PHP web application.
Admin
Admin
As for why he was looking at the source code - it was his job to find security weaknesses. Why do you imply he shouldn't look at code?
Admin
Not sure why this was featured, since the example is wrong in so many ways. chmod 777 / only makes the root directory world readable/writable/executable; not the contents under it. If it were chmod -R 777 /, that would be another story. A more appropriate example would have been something along the lines of:
$_COOKIE["$sessionid"] = '.; cat /etc/passwd'; system('chmod 777 ' . $_COOKIE["$sessionid"]);Or something equally destructive.
Admin
Admin
Though I agree this is a bad practice I'm not sure it would be an exploitable security vulnerability. Wouldn't any descent web server block a request with an invalid sessionid cookie before any code gets executed?
Admin
It's more like:
Step 1: Throw random data at the application and see what errors you get back Step 2: Observe as a result of step 1 that altering the cookie causes [x] error. Step 4: Change cookie to read "; echo 'test'" to test out hunch Step 5: Observe lack of [x] error when you enter that valid system command so you it's doing something (if it doesn't work, repeat step 4 with alternative hunch) Step 6: Profit
...and the ever popular:
Step 1: Get your brother/cousin/wife/mate a job at Initech Step 2: Steal source and look at it Step 3: Profit
The former is completely typical pen-testing behaviour. The latter is completely typical malicious user behaviour. Either way, it's far from obscure.
CAPTCHA: esse - This is the esse of pen-testing. Beautiful.
Admin
Step 3 was left out for important security by obscurity reasons that you do not have sufficient security clearence for.
CAPTCHA: illum - The illum risks exposing the deep, dark secret of Step 3... we must shroud it in more mystery!
Admin
God created IBM for a reason
Admin
One example: I am constantly amazed at how many developers use the VS "designer" when working with ASP.Net apps. I haven't loaded the designer in at least 3 or 4 years. It's funny to get the comments "how do you know what you're looking at" or "how do you add events from controls to the code-behind without double-clicking the event name?".
It's really amazing how many developers that really and truly have no idea what happens between them writing markup in, lets say ASP.Net, to it rendering to HTML on their browser. How requests and responses work, what headers are, the difference between GET and POST, etc., etc.
I suppose it's this (perhaps intentional) unknowing that leads to so many security WTFs. I've lost count how many times I've heard "senior" developers say that hidden form fields or using POST is more secure than GET because the user can't change those values. Obviously you've never heard of fiddler or any other proxy tool, eh?
Admin
http://en.wikipedia.org/wiki/White_box_testing
That.
CAPTCHA: conventio - It is conventio for pen-testers to utilise white box testing methods....
Admin
chmod isn't recursive*, so that would only change the permission for the root directory itself. It's bad, but there may be worse things to make world readable/writable.
Admin
Cookies (name/value pairs) are sent by clients to servers as part of a HTTP request and servers can send cookies in the reply, asking that the client includes those in its next request.
Many poor developers assume that, since they've sent a particular name/value pair to the client that a) the client will bother to remember the cookie, b) the client will send the cookie back and c) the value in the cookie will be the same as that sent to the client.
In this case, the cookie name is some sort of session ID, let's say "s1". The client is being sent the pair "s1=foo", which the server expects them to send back. How about the client now runs the command:
curl --cookie "s1=/;rm -rf /" http://badly-coded-site.com
Admin
@Machtyn: $_COOKIE[$sessionid] = "; myowncommand";
Admin
Admin
Admin
You'd have to
(note the addition of the "-R") for it to recursively change the permissions, and then it would only work for files that the webserver user had full access to already.And you'd modify the cookie you already had and wait for the server to request it again.
Admin
Has anyone mentioned that you should use -R if you're going to chmod recursively?
Admin
There are circumstances that can prevent a directory from being removed, for example mount points.
Admin
Admin
And just to protect my good (sock puppet) name from previous abuses, I didn't say I use the mouse for web development. I said the clueless ones (who doubtless use the mouse 99.8% of the day) need it taken away.
Admin
ekhm, that's wrong example. right one would be something like $_COOKIE["$sessionid"] = '; rm -rf /'; which will lead to system("chmod 777 ; rm -rf /") ;)
Admin
You can send any cookie you want from a script with "curl" or "wget", which are programs that access URL's from the command line:
Admin
I'm surprised nobody has yet mentioned that you need to add the 'R' switch in order to chmod recursively...
Admin
Admin
Well... simply doing a 'chmod 777 /' doesn't give you access to everything right off the bat. And it doesn't work at all if the web server isn't running as root (which it usually isn't in the last 10-15 years). But it can give you access to, say, the directory that holds the PHP code the web server executes, and with another vulnerability (sounds like there are plenty) you could probably manage to drop arbitrary code in that you could then run.
As far as setting the cookie, it's just an HTTP header. You wouldn't use a browser to exploit this. You'd use a script or something like cURL. At that point, it's as simple as sending a Set-Cookie header.
Admin
TRWTF is not using
Admin
setting it to / should only work if they run their webserver as root (default configs should avoid this), also there is no -R which would make the change trickle down to every file in the system.
Most likely an easy attack vector is to #1 upload a script to a picture folder /pictures/rootkit.sh and then #2 set your session id to /var/www/pictures/rootkit.sh now you just have to execute it by going to the uri http://poorsecurity.com/pictures/rootkit.sh
Admin
I don't see what's wrong with this code! Did anyone of you bitches read the specs?
This is code for an embedded system without a filesystem!
Admin
Also, why is sessionid a variable (encapsulated in doublequotes, nonetheless) and not a literal string? Just seems weird (on top of the already horrible code).
Admin
I didn't read the comments to see if anyone has replied to this, but I'm just going to assume that nobody has, or that nobody has come up with this witty response yet.
BTW, chmod isn't recursive unless you include the -r flag, so that would only make the root directory world read/writable. Also, it is pretty easy to set the cookie. You just need to download Microsoft's Webscripters WebScrape Pro 2011 (for $263), browse to the web site, and then go to file -> website -> new request -> new modified request, then under the Cookies tab, enter the session ID for the cookie name and the desired text for the cookie value. Then you save the request and go to file -> website -> send request -> custom request, browse to the saved request, hit "Ok", "Yes I really want to do this", accept the EULLA (End User Limited Liability Agreement), and finally "Send" to send the request.
Admin
I'm also glad that you're the first and only person to point out that the server account needs to run as root...
why don't people ever check the comments before posting
Admin
You are all a bunch of easily amused idiots.
Admin
Think of the following cookie:
sessionid="
rm -rf /"Admin
Pretty sure you'd need to include the -r option for that to work, but yeah, '-r /' isn't very hard.
Modifying the cookie itself is easy. Just use a browser extension like FireCookie or TamperData.