Kuro5hin.org: technology and culture, from the trenches
create account | help/FAQ | contact | links | search | IRC | site news
[ Everything | Diaries | Technology | Science | Culture | Politics | Media | News | Internet | Op-Ed | Fiction | Meta | MLP ]
We need your support: buy an ad | premium membership

[P]
Attack of the Web Trojans

By rusty in News
Tue May 09, 2000 at 10:53:51 PM EST
Tags: Security (all tags)
Security

Zope.org has identified several new trojan-type attacks that affect Zope and nearly all other web-managed dynamic content systems. They come in both server-side and client-side flavors, and will likely be very tricky to patch or fix, technologically. See the links above for extensive descriptions of the problems. My summary of the issues follows.

Thanks to Jonathan Corbet of Linux Weekly News for bringing this to my attention. See his description of the problem on LWN.


The server-side issue appears to be pretty Zope-specific. From the description on Zope.org:
Under the current Zope security model, a DTMLMethod author can create a method containing code that attempts to perform actions above the author's level of privilege. If the author attempts to run this method, he will get an error because he is not sufficiently privileged to perform the actions. However, if the author can arrange for a more privileged user to view his content, the code will run, possibly performing actions without the higher-privileged user even knowing about it. This hole results from the fact that DTMLMethods execute with the privileges of the user executing the method.
They state that the issue will be fixed in Zope 2.2, by creating an ownership scheme for server-side objects.

The client-side issue is much more far-reaching and potentially damaging. At the risk of making myself look dumb, I'll give an example of the problem using Scoop itself.

Imagine that there is a form button to delete a story, and when an administrator presses it, the resultant URL, expressed as a GET, looks like:

http://www.kuro5hin.org/?op=deletestory&sid=12/34/27/2000/12345
(not the actual form string, but something like that). Now, whether or not I have permission to perform that action is determined by my local session cookie. If my browser provides a session cookie, and that session is found to contain, in the database, a UID, and that UID is granted a certain level of privilege, then the action goes through without further prompting.

"So what's the problem?" you ask, "Surely an admin wouldn't click on such a link without knowing what he was going to do!"

But that's not the end. Now imagine that someone creates a page consisting of the following HTML:

<HTML>
<HEAD>
<META HTTP-EQUIV="Refresh" 
    CONTENT="0;
    URL=http://www.kuro5hin.org/?op=deletestory&sid=12/34/27/2000/12345">
</HEAD>
<BODY>
</BODY>
</HTML>
and emails me the link to this page, with a description such as "Please consider this article for posting to kuro5hin.org". I click the link to see the page. Uh-oh.

As we've seen, I have the admin cookie stored on locally, so they have just tricked me into sending the destructive URL to my server, along with full admin privileges. There won't be any warning that I'm about to do this, and I won't know until it's too late.

The example covers Scoop, but the problem extends to almost all web-administered applications. Very few have any kind of checks in place to prevent this kind of problem. Ways to fix it, as listed on the Zope site, include curtailing logged-in time, providing "Undo" capabilities, or performing referrer checks before performing certain actions. Developers of web-administered applications, and admins of such applications need to take note of this problem immediately, and be very careful what they do while logged in as an admin. Fixes will likely be slightly slower in coming than for most problems, due to the subtle nature of the issue. Until then, admins, stay logged out until you have to do something administrative!

Sponsors

Voxel dot net
o Managed Hosting
o VoxCAST Content Delivery
o Raw Infrastructure

Login

Related Links
o Scoop
o Kuro5hin
o Zope.org
o trojan-typ e attacks
o server-sid e
o client-sid e
o Jonathan Corbet
o Linux Weekly News
o his description
o descriptio n
o Scoop [2]
o Also by rusty


Display: Sort:
Attack of the Web Trojans | 32 comments (32 topical, editorial, 0 hidden)
What about checking the http-referr... (3.00 / 1) (#6)
by Bradley on Tue May 09, 2000 at 06:53:28 PM EST

Bradley voted 1 on this story.

What about checking the http-referrer field? Only do admin-type actions if you've clicked on a link from kuro5hin.org.

I suppose someone could still do something nasty involving links in a comment - does kuro5hin strip the onFoo javascript stuff from within tags?

Re: What about checking the http-referr... (none / 0) (#14)
by Marcin on Tue May 09, 2000 at 11:11:19 PM EST

Your javascript is broken :) I get an "Unterminated string constant" error when I load this page (IE5). :)

And it doesn't change the window status text either.
M.
[ Parent ]

Re: What about checking the http-referr... (none / 0) (#15)
by Bradley on Tue May 09, 2000 at 11:16:45 PM EST

Yes, I know :)

I don't know javascript, so I cut and pasted from another site and it apparently doesn't like spaces in the string. But the javascript stuff isn't trimmed by k5, so its still a problem.

I mailed rusty with a more malicious example, and I tested a fixed example on the preview stuff, and it worked.

I want a preview option for voting :)

[ Parent ]
A more simplisitc solution to the s... (2.00 / 1) (#2)
by fvw on Tue May 09, 2000 at 06:54:21 PM EST

fvw voted 1 on this story.

A more simplisitc solution to the second problem would be only allowing post (not get) for the admin scripts.

Re: A more simplisitc solution to the s... (none / 0) (#17)
by bobsquatch on Wed May 10, 2000 at 05:33:23 AM EST

Too bad javascript can be used to automatically submit via POST... For your fix to work, you'll also have to get everybody with admin access to disable javascript.

MiniRant: Not that I'm against disabling javascript, per se. Not that I'm against making the javascript designers the first against the wall when the revolution comes, either. Weren't we just talking about a stupid Microsoft program that executes arbitrary foreign code without the casual user's knowledge (much less consent)? Weren't we proud that Linux users would never use something that silly on their boxes?



[ Parent ]

Re: A more simplisitc solution to the s... (none / 0) (#27)
by Anonymous Hero on Thu May 11, 2000 at 05:38:14 AM EST

Also, the problem with that is that you can still just disguise a submit button. Use a gif that says "click here to enter my site!" for instance, and make it just say "http://www.blah.com/index2.html" when you mouseover it, and really, who is going to notice until they've clicked it? You SHOULD block and GET requests if you don't need them, because you know, why have them work anyway, that's sloppy and dumb, but don't rely on that.

[ Parent ]
"and emails me the link to this pag... (4.00 / 2) (#1)
by Inoshiro on Tue May 09, 2000 at 07:09:44 PM EST

Inoshiro voted 1 on this story.

"and emails me the link to this page, with a description such as "Please consider this article for posting to kuro5hin.org". I click the link to see the page. Uh-oh."

Well, this is just another reason for not allowing any automatic actions in HTML (specifically HTML email, but also real-world HTML). I disable all scripting languages and redirect support on my browsers. If people want to redirect me, they can stick a "we've moved!" link... As you said, the chances of abuse are too great

Referrer checking won't help if their browser drops it, though. I know that I block it (it's interesting what you see on the server side logs from them ;))



--
[ イノシロ ]
Re: (none / 0) (#12)
by rusty on Tue May 09, 2000 at 11:06:51 PM EST

But, referrer helping will work if the default is "don't do the action". That is, if you want to administer the site, make sure your referrer confirms that you came *from* the site. The key is that referrer field is in control of the admin, and can't (as far as I know) be faked by accident, without your (the admin's) knowlege.

____
Not the real rusty
[ Parent ]
Re: (none / 0) (#13)
by rusty on Tue May 09, 2000 at 11:08:36 PM EST

But, referrer helping will work...

Hey, now, where'd that come from? I swear I'm getting neurological damage from too much email. Anyway, that's supposed to say referrer filtering will work...

____
Not the real rusty
[ Parent ]

not exactly a bug, but a "not good"... (none / 0) (#3)
by davidu on Tue May 09, 2000 at 07:20:31 PM EST

davidu voted 1 on this story.

not exactly a bug, but a "not good" feature. IMHO.

On a related note, see this story o... (5.00 / 1) (#4)
by analog on Tue May 09, 2000 at 07:31:53 PM EST

analog voted 1 on this story.

On a related note, see this story on CNet. What was that my mom used to say.... you can't be too careful!

I think that again you're looking at trading security for convenience. It may turn out to be true that administering certain types of content (or maybe even any kind of content) through a web interface just isn't workable if security is a concern.

Re: On a related note, see this story o... (none / 0) (#19)
by bobsquatch on Wed May 10, 2000 at 05:53:59 AM EST

That's an old social-engineering crack! I saw that one for the first time in early 1997, when I was running a web-based chat service that (for a while) allowed people to post unfiltered HTML messages. The scam would go something like this:

Lameass'sOfficialSoundingUserName: Sorry to interrupt, guys, but we just found a hacker in the room. We'll need all of you to enter your site password here in order to figure out who the bad guy is. [form action="mailto:lameass@hotmail.com"][input type=password][/form]

Lameass's2ndAccount: w0w, sorry bout the hack man. ppl pitch in!

Believe it or not, this worked well. To see the old tricks still working... it brings a nostalgic smile to my lips. For a few seconds.



[ Parent ]

There always has to be someone out ... (none / 0) (#8)
by Marcin on Tue May 09, 2000 at 07:57:45 PM EST

Marcin voted 1 on this story.

There always has to be someone out there that spoils it for everyone else :)

Why can't people just play nice on the Internet? I'm going to start my own Internet, with hookers and blackjack. (Futurama reference there for those that aren't aware) :)

Really though, there's nothing clever about this kind of destruction, it's basically script kiddie behaviour. That TCP stuff that was mentioned earlier though, that's damn cool :)
M.

Hmm.... (1.00 / 1) (#9)
by deimos on Tue May 09, 2000 at 08:08:58 PM EST

deimos voted 1 on this story.

Hmm.
irc.kuro5hin.org: Good Monkeys, Great Typewriters.

Rusty admitting to - if not quite r... (none / 0) (#5)
by your_desired_username on Tue May 09, 2000 at 08:19:02 PM EST

your_desired_username voted 1 on this story.

Rusty admitting to - if not quite revealing - the vulnerabilities of his own site.

#if defined(JOKING)
Now, how do we get the URL for story deletion? packet sniffers ....
#endif /* defined(JOKING) */


Re: Rusty admitting to - if not quite r... (none / 0) (#11)
by rusty on Tue May 09, 2000 at 10:57:29 PM EST

Download Scoop. It'll be pretty obvious how to construct a "Delete this story" url.

Security through obscurity is worse than no security at all.

____
Not the real rusty
[ Parent ]

Re: Rusty admitting to - if not quite r... (none / 0) (#29)
by tzanger on Thu May 11, 2000 at 09:23:14 AM EST

Security through obscurity is worse than no security at all.

I disagree. Security through obscurity on its own is worse than no security at all, as it gives the person using it a false sense of, well security.

Security through obscurity, in addition to other strong security, perhaps intermixed at various stages, I feel adds to overall security. Pretty much the same as a metal door frame is security, yes, but you can still kick the door in. A metal door frame with a metal door is better than a metal door alone, since you can not kick in the door and have the door frame give.



[ Parent ]
Re: Rusty admitting to - if not quite r... (none / 0) (#31)
by SolidGold on Thu May 11, 2000 at 06:14:31 PM EST

You are through laziness relying on security through obscurity, by not posting the url to delete a comment.

Life is impossible without security through obscurity. If a thief knew exactly when you wouldn't be home and where your valuables are kept, you'd be much more likely to be robbed.

All locks rely on security through obscurity. You rely on the fact that a relatively small segment of the population knows how to pick locks. However, for the segment of the population that does know how to pick locks, your lock is not much of a barrier.

[ Parent ]
Good, however, is this bugtraq? No... (1.00 / 1) (#7)
by tidepool on Tue May 09, 2000 at 09:40:50 PM EST

tidepool voted -1 on this story.

Good, however, is this bugtraq? No

Definately a potential problem, esp... (none / 0) (#10)
by genehack on Tue May 09, 2000 at 10:14:55 PM EST

genehack voted 1 on this story.

Definately a potential problem, especially as CMSs seem to be proliferating more quickly these days. Hopefully a work-around will come from the discussion?



Two remarks (none / 0) (#16)
by adamsc on Wed May 10, 2000 at 12:02:00 AM EST

  • A simple confirm step takes care of this. Just have some sort of confirm={random session id} parameter to prevent spoofing.
  • A decent logout system & a fine-grained permission can help reduce the damage, similar to not always working as root. (e.g. they have to make something be seen by someone who a) has not logged out and b) has access to the area). Still a band-aid at best, though.


.htaccess attack (none / 0) (#18)
by rafael on Wed May 10, 2000 at 05:44:31 AM EST

Hey, this technique does not only apply to sessio cookies, but it can also be used to access .htaccess-protected scripts. You only have to hope that the recipient of the malicious mail has already authenticated itself into an .htaccess-protected zone of the server...

Re: .htaccess attack (none / 0) (#20)
by tidepool on Wed May 10, 2000 at 09:25:55 AM EST

Hey, this technique does not only apply to sessio cookies, but it can also be used to access .htaccess-protected scripts. You only have to hope that the recipient of the malicious mail has already authenticated itself into an .htaccess-protected zone of the server...

Interesting idea, however, I have a feeling that this would rarely work 'in the real world'. Cookies are meant to be a passive sort of (not authentication, hrmm) identification for website visitors. True, many sites have cookies providing authorization features, which I feel the is numbest idea - however, it seems to work for the mostpart.

.htaccess (and .htpasswd) files are meant to be a secure authentication means - they are a 'in your face' kind of authentication - pop, here's the dialog box asking me to login - type in username / password, and you're either a: Allowed Access B: You get a 403 access denied.

Going to the assumption that the 'target' for the exploit has already logged into a secure (via .htaccess) site is a huge risk. If they havn't, it will pop that good ole' dialog box up, and they will start getting suspicious.

Just my take on things - Ben

[ Parent ]
Re: Attack of the Web Trojans (none / 0) (#21)
by RobotSlave on Wed May 10, 2000 at 02:55:52 PM EST

With regard to "client-side" trojans:

Er, why not simply disable your fancy web-based admin tools?

This is essentially how I used to address the Netscape Enterprise Server issue mentioned in the article-- I did most of the administration with a text editor, and on the odd occaision when I couldn't remember where to put some option or another, I'd fire up the admin server (not on the default port, mind you), and kill it as soon as I was done with the administrative task at hand.

Of course, this doesn't help users of applications that only have web interfaces (such as HotMail)-- userland security is still left in the hands of the user. Sytems security, however, gains a boost if you just say no to web-based admin tools.

Re: Attack of the Web Trojans (none / 0) (#26)
by rusty on Wed May 10, 2000 at 09:57:58 PM EST

In the case of Scoop, if I disabled or didn't use web admin tools, I'd be stuck screwing around directly in the database all the time. For running a website, web based admin is a godsend, if you can avoid security issues. You idea is kind of like saying "BIND has a hole. Why not stop running your fancy DNS? Just use IP numbers." Sure, you could, kind of, but why not fix the hole? :-)

____
Not the real rusty
[ Parent ]
Re: Attack of the Web Trojans (none / 0) (#28)
by tzanger on Thu May 11, 2000 at 09:19:27 AM EST

The fix is not to eliminate web-based admin, it is (as mentioned already here) to make your authorization "smart"

ferinstance -- the admin tools I write for the ISP I work at require authorzation. This can work as a cookie, or, barring a cookie, a login. The cookies (and the passwords) are good only for a single day and for a single user. If there is a referrer, it must be from somwhere on our network. If any of these checks fail, they're logged and the user is presented a login screen. Cookies from computers outside the immediate network are refused (or are on a 15min expire, can't remember atm)

I have a number of servers which need to be given commands via some kind of web interface. i.e. We have a mail server, a radius server, a FTP/web server and a billing server. I dont' want to hit all of these seperately to add a user. So my main page allows me to enter an authorizing user/password, tick off which services they desire, enter the relevant info and click "submit". Then the script calls up http://mailserver.myisp.net/services/addemail.cgi?u=blah&pw=blah&au=blah&ap=blah&at=hash which adds the email, calls up http://webserver.myisp.net/services/addftp.cgi?u=blah... to add on the FTP account and enable a home page for them, calls up a perl module which adds the contact and billing info, etc.

Is it secure? Yes. None of those actual parameters are sent in cleartext and the whole thing must match a one-way hash which includes such info as the server it's coming from, date, authenticating info, etc. The called server logs the call, performs the work (if the hash works out and the authenticating user has the rights) and returns. Eventually I want it to go over SSL to provide another layer of protection and so I can handle problems from my home, from my parent's home, or from the shores of Cuba. :-)



[ Parent ]
Re: Attack of the Web Trojans (4.00 / 1) (#22)
by Alhazred on Wed May 10, 2000 at 05:32:03 PM EST

I've been thinking about this issue a lot for several months because I've been building a large scale publicly accessible web site construction system that would easily fall prey.

I came up with a partial solution to what the Zope folks call the "client-side trojan" problem.

As I understand it the problem is that I could for instance redirect you to a page that requires authorization and which you have already logged into and have your browser do some sort of "bad thing".

Our system uses cookie based authentication. One simple approach is to rewrite the cookie every time the user hits one of our pages. The new cookie will contain the REFERRER that was passed in the last request by the client. If when I read the cookie again I see a different referrer in the cookie than what I seperately record in my session database, then you are booted. In other words if Rusty logs into K5 and then goes to "evilhacker.org" in the same session, and "evilhacker.org" redirects him back to a k5 admin page with some javascript and submits a request to delete all our articles, under this scheme k5 would say "patooey" because the referrer would be evilhacker.org and his cookie would be telling k5 he'd last been on some URL withing k5. The 2 don't match, ergo he's been a bad boy and off browsing somewhere else while logged into k5!

Simple, eh?

Of course it does fall prey to the objection brought up by the Zope guy about proxies and referrer information, but it does neatly solve some of the problems they brought up.

I have also implemented my cookie auth system with several safeguards of other types, like hashing the time of the last page interaction into the cookie along with the session id, so that it is hard for someone that manages to get hold of the cookie info to "replay" the cookie (ie, use it to gain access at a later time). A lot of these tricks I came up with after reading about how Kerberos does tickets. (not that any of the stuff I do is a lot like what they do, but still it was a good source of ideas about auth systems in general).

Anyway, this was a very interesting article to me at least!
That is not dead which may eternal lie And with strange aeons death itself may die.
Re: Attack of the Web Trojans (none / 0) (#23)
by mattdm on Wed May 10, 2000 at 05:49:08 PM EST

The problem with that is: it's really easy to spoof your referrer.

[ Parent ]
Re: Attack of the Web Trojans (none / 0) (#25)
by rusty on Wed May 10, 2000 at 09:55:22 PM EST

But, it's not easy (as far as I know) for someone *else* to spoof your referrer, without you knowing (is it?). The key is that yes, you can spoof your own referrer, but since you are the one doing the administration, why would you? If you had your proxy set to always report your referrer as a valid one for admin stuff, and you got tricked into this, well, that's really your own dumbass fault, isn't it. :-)

____
Not the real rusty
[ Parent ]
Re: Attack of the Web Trojans (4.00 / 1) (#24)
by numb on Wed May 10, 2000 at 07:14:24 PM EST

I wrote a short PHP script that demos how this works. It will post a message on Slashdot using your name (or AC if you're not logged in.) It only took a couple minutes to write:

Click here to try it

or

Click here to see the source

I have it set to post to a hidden sid rather than one of the articles. It took me about 20 minutes to write including the time I spent examing Slashdot's submit page source. It wouldn't be hard to do something more insidious with this. Instead of a plug for my website in a hidden sid, it could have been an embarassing story sent to a public forum on Slashdot. The sid I have the messages going to is numb.

BTW, I'm new to kuro5hin. Wanted to say it's a cool site.

numb

Follow-up (none / 0) (#32)
by numb on Thu May 11, 2000 at 06:26:21 PM EST

Well, I posted about this on Slashdot and now there's about 500 posts in the sid that I created--and it's still growing. My sid is catching up with the MS Letter article as far as posts go. It was probably a bad day to do it considering all the traffic they were already getting today--on the other hand their new webserver probably had the best workout they could have asked for.

I've definately got some work to do on my software to protect it from this stuff. I'm really glad kuro5hin brought this to my attention. I'm surprised that there hasn't been much discussion about this problem before. Raising awareness will definately help prevent this from allowing more serious exploits of this type. numb

[ Parent ]

Re: Attack of the Web Trojans (none / 0) (#30)
by Alhazred on Thu May 11, 2000 at 09:36:33 AM EST

Not that I know of. I spent a couple hours trying to think of an approach to doing that, and all I came up with were various DNS based attacks, which if you made them would let you do a lot nastier things anyway.

I think people are going to have to face the fact though that web and secure are words that simply can't be used together in the same sentence...

The really nasty thing is that this 'sploit is well within the reach of, and comprehension of, the majority of people with a reasonable amount of real web development experience. Unlike the subtle sorts of cracks like what befell apache.org the other week where the hacker had to be pretty knowledgeable on a number of subsystems (and even that one was pretty straightforward). More and more the tools and knowledge to crack become more accessible to masses of people who in the past did not have the time or inclination or talent to learn the art for themselves.

Its the age of the script kiddie, and with millions of them out there just hammering away at systems it is pretty scary.

Try an experiment sometime. Put up some software on your home Linux box (you do have one right?) to look for port scans. My home dial-up machine gets port scanned an average of 8 to 10 times PER NIGHT! 2 days of seeing that and I armored the darn thing to the hilt.
That is not dead which may eternal lie And with strange aeons death itself may die.
Attack of the Web Trojans | 32 comments (32 topical, 0 editorial, 0 hidden)
Display: Sort:

kuro5hin.org

[XML]
All trademarks and copyrights on this page are owned by their respective companies. The Rest 2000 - Present Kuro5hin.org Inc.
See our legalese page for copyright policies. Please also read our Privacy Policy.
Kuro5hin.org is powered by Free Software, including Apache, Perl, and Linux, The Scoop Engine that runs this site is freely available, under the terms of the GPL.
Need some help? Email help@kuro5hin.org.
My heart's the long stairs.

Powered by Scoop create account | help/FAQ | mission | links | search | IRC | YOU choose the stories!