Been having an interesting convo with the security team of a fairly high-profile open source web application community (Name withheld for the time-being because of the numbers involved) WRT the below scenario...

Given an example URL thus:

www.example.com/products

... the application - on every single high profile site I've tested that uses this platform - allows me to navigate to that same page (in most cases), by simply dropping another word into the path like thus:

www.example.com/any-word/products

or, to step-up the game a little:

www.example.com/any-word/any-word/any-word/any-word/any-word/products

... will also result - in the overwhelming majority of cases - in the same page being returned (sometimes different, but still un-intended).

OK, just to re-emphasise, when I said (above) high-profile sites, I absolutely mean, in some cases, household brand-names reknowned the world-over = big bucks. Clearly though, most of the applications are run by all strata's of interest-groups too; from the non-profit church, up to the aforementioned dinosaurs.

The point being however: big money.

So to tie this up, if we know the footprint to look for (simple, thanks to Google), it is a trivial matter for - whoever, for whatever commercial or grudging reason - to perform some guestbook/blog-spamming with our new link in order to hurt our target's rankings.

That is basically the gist of it, but let's now compound that by further throwing into the mix the fact that the application tends to spit-out relative links in its navigation, and you begin to see the scale that such an attack makes possible.

Simple to execute, high probability of success, not illegal, big bucks at stake... security vulnerability?

Is not "security risk" predicated upon the value of the assets being appraised?

As you may have surmised, I am having a little problem with persuading those concerned to broaden the (introverted?) culture of what I believe to be a significant security risk.

I am merely an interested follower of this seedy world for educational and "self-awareness" purposes but with the stakes becomming so increasingly high these days for SERPs, is it fair to say that the web application industry still need to be persuaded that security risks exist outside of the server in the form of traffic and revenue, as well as maintaining control of the server and the data within?

... or am I just being a drama-queen?!

It's not your job to broaden their culture (well, unless they pay you to ;)). If you want to be a nice guy and inform the rest of the world that there is a problem and certain sites have issues, sure go for it.

In the end the market will decide. Whether it be SOX audits they will get fined for, lost business over lost customer trust or direct losses from fraud, to most companies, security is only as important as how much money it can save them.

So it may or may not be worth it to the company, if implementing the security measures to counteract threat X costs more than doing nothing, the company will do nothing. Either way not your problem (unless they pay for it to be...).

-id

id actually makes a good point... while I think it may be your responsibility to raise the awareness of the risk I think every website out there is vulnerable to google bowling or other search engine optimization evils (this site included). If someone really wanted to mess with us there is nothing to stop them other than someone at at the search engine in question seeing what is going on and somehow interviening.

That said, what you are saying is a real risk and should definitely be communicated, but I think that as there isn't a lot of search engine DoS activity going on at the moment it's unlikely that it will garner much respect amongst your executive management. It may be that you are simply ahead of your time, but at the moment this is really more of a theoretical risk than an actual commonly used one - except in the off case where someone is trying to out you for black hat SEO techniques that your company may employ.

The short of is is I think you're safe for the time being and it's probably better for your career to state it as a theoretical attack only and focus on the more here and now type risks. If you want to talk more about any of the particulars hit me up in PM. High dollar accounts always have specific issues that don't fit into broad stroke type comments like the ones id and I are making so without knowing more details we might be making generalities that don't make sense with your situation.

- RSnake
Gotta love it. http://ha.ckers.org

I AM a drama-queen then... OMG! ;¬)

I take both your points, ID and RSnake, and yes, it is, for the moment at least, a theoretical attack.

But then, I see patches being commonly released to fix scenario's which have, IMO, a low probability of even being dreamt-up by an attacker, are complicated to enact, and in some cases, with unknown or unpredictable "rewards" (opportunistic).

That's not to down-play the importance of fixing things, but sometimes I wonder if someone just likes to sit there and dream-up scenario's purely for the game of thinking them up (particularly in the open-source community).

A (loose) example of a recent (CSRF) fix for the web-app I'm referring-to :

Visiting a specially crafted page, anywhere on the web, may allow that page to post forms to the specific web application under discussion, within the context of the visitor's session. If that session has top administration privilidges, blah blah...

I mean, to my mind, that would have to be one well-targetted phishing, or other social engineering trick to work. Otherwise, relying on a random website to receive visitors that just-so-happen to still be "in-session" with the "right" privilidges from another specific build of (vulnerable) website; and without knowing which exact site that is and the treasures it might behold... well, it seems to me that the probabilities of someone going to such trouble are statistically so low as to be negligible... IMO.

Of course, one will say these types of attacks occur, or that someone will do it, eventually... but isn't that the point anyway?

Do I sound bitter that my report was both hushed-up and brushed-aside? Nah... I did wonder if it would be taken seriously before I submitted it TBH. Only because it didn't concern any theft of passwords or other unauthorised site-access. I had an interesting discussion with their security guy - It was clear this was "left-side" and he was keen to hear/learn more.

My motivation isn't career-related - this is an open-source app don't forget - I'm working on a personal project using the platform and there is an underlying problem with the menu-creation-system spitting out different paths, in certain situations, to the same page(s) = dupe content issues. More and more users are reporting that Google are penalising. Robots.txt is the current solution. Whilst I was debugging my own path issue however, up popped this little "crack".

There is an expanding "cottage" industry springing-up around this web-app, building/customising it for some major global brand clients etal. I've emailed one such agency with live example links from one of their (BIG) client sites to both warn, and work with them to fix it (including sharing costs) and then submitting it back to the community for the benefit of all... seems they have gone all quiet too now!

Anyway...

Quote

Visiting a specially crafted page, anywhere on the web, may allow that page to post forms to the specific web application under discussion, within the context of the visitor's session. If that session has top administration privilidges, blah blah...

I mean, to my mind, that would have to be one well-targetted phishing, or other social engineering trick to work. Otherwise, relying on a random website to receive visitors that just-so-happen to still be "in-session" with the "right" privilidges from another specific build of (vulnerable) website; and without knowing which exact site that is and the treasures it might behold... well, it seems to me that the probabilities of someone going to such trouble are statistically so low as to be negligible... IMO.

Uhh, this is how most every CSRF attack works. If it's a GET request, you can send them the direct link, but that's usually a bad idea. If the link looks something like http//webapp.com/settings.php?changepass=owned&verify=owned .. well that changepass just looks suspicious. So how do you get them to go somewhere less obvious? or what about for POST only requests?

Answer:
There's a dozen ways atleast, be creative. You send the target an email, or IM, or a private message using the web apps messaging system, or you post a comment/article/whathaveyou on the web app that other users will read and click the link on, or use persistent XSS to autoexecute it from that comment/article/etc., or pwn their box and force them to do it, or kidnap their first born child and leave a ransom note for them to go there, and so on. People are very predictable.. it's not hard to social engineer them into following you like drones. And admins are no tougher. Try this: send a private message to the admin saying, 'Someone claims to have hacked your server using an Apache exploit. They also posted the first four letters of your password as proof here: http//somesite.com/wordpress/20061021/Apache-vulnerable-to-TRACE-requests/'

Any admin in their right mind is going to rush to the link to see if they indeed got hacked. If you send it as a PM, you're gauranteed that they're logged in. And as soon as some fake page loads with random BS and a random four letter pass, the script in the background just launched the CSRF attack. That's really quite typical, and quite simple to pull off..

If you're under the impression that SEing is difficult or unpractical.. you're probably thinking too hard.

-maluc

Maluc is right... CSRF unfortunately is not just theoretical. I (personally) have seen about 200 various real world attacks using CSRF in the wild. Very few of them actually required much social engineering (at least not in the way you're thinking). But rather more like they HAVE a profile somewhere and someone surfing profiles finds their profile and poof... CSRF.

I have seen Google bowling in the past too (I can count the number on one hand though). Other forms of malicious SEO are more common and less difficult to track.

So while I don't think your concern is unwarrented, it's also fairly uncommon if you are talking about statistics. There _ARE_ completely theoretical attacks that I mostly roll my eyes at (this is a web app security lab so I hear it all). However, I think a lot of the more odd scenarios point to a bigger problem and are worth looking into even if the particular application in question isn't particularly note-worthy.

I don't think you are a drama queen though. I just think you are framing the potential of the attack in a way it probably doesn't deserve (yet). In the same way XSS really is only starting to take off, it could be WAY worse, theoretically. Does that mean I recommend people turn off JavaScript? No. Statistically speaking you aren't really that much at risk unless you access one of the websites that happens to be largely targeted (MySpace). So would I recommend you not use MySpace? Yes (well if you must at least turn JavaScript off). Would I recommend you password protect your entire site to protect it from Google bowling? No.

Simple reason, the risks aren't outweighed by the reward in allowing websites and search engines to see your content. At the end of the day it's about money right? What's best for your client? What actual risks are they facing and what possible risks might they face in a worst case scenario? If their appetite for the risk exists, that's not your problem. If they are worried about it, then it is. It's really that simple.

As this is a lab, I like to hear it all. I don't make judgements about risk other than percentage of users who can be affected - as I can't comment on people's actual risk without knowing the details of their organization. That would simply be foolish to do. I can say that from most people I've talked to about things like that they aren't particularlly worried about it. However, if they were engaged in a battle with a bunch of black hat SEO folks, it might be worth thinking about as you corporate fiduciary risk may warrant further research. See what I'm saying?

- RSnake
Gotta love it. http://ha.ckers.org

Quote

rsnake Wrote:
-------------------------------------------------------
See what I'm saying?

Absolutely, yes... it's the risk/reward, cost/benefit thing isn't it.

... and yeah, we are of a species that quite often, even in the glare of a speeding train's headlights, tend to only react after the worst has happened.

I've only time to address a couple of points made:

Maluc:

Quote

You send the target an email, or IM, or a private message using the web apps messaging system, or you post a comment/article/whathaveyou on the web app that other users will read and click the link on, or use persistent XSS to autoexecute it from that comment/article/etc., or pwn their box and force them to do it, or kidnap their first born child and leave a ransom note for them to go there, and so on.

I completely accept that. My point really is the work involved... basically, all the groundwork needed to first find a vulnerable web-app (it's presumably easier after a flaw is exposed because then you have a footprint - but then again, chances are there are fewer targets after, because of the inevitable patches that follow), which is also vulnerable within the sphere-of-competance of the attacker. Then there's the targetting of the right people who use that specific web-app (emails or whatever...).

But to do all that, there has to be a motivating factor, ie... the "prize": Is it worth it?

Each (and more) of those "steps", if you like, is a limiting barrier that wipes-out the overwhelming vast majority of the surfing public... even those on the fringes of "dark society", if you like... and then you have that scarce resource, time and place - A commodity that even the hardcore need.

RSnake:

Quote

I (personally) have seen about 200 various real world attacks using CSRF in the wild.

Exactly... even one, is one too many if it happens to you - 200 is certainly a lot. But here is the kicker... a lot compared to what?

... and over what time-period?

... and I wonder how many different security fixes have been issued in that same period? If that figure is higher than the total amount of different attacks, then there is a surplus inventory which must, by definition, by based on a theoretical attack model... which begs another question but I don't have time.

Again, not down-playing the seriousness of this shit, just exploring, but I think I'm still in safe territory by saying that it's a statistically negligable risk.



Edited 1 time(s). Last edit at 10/22/2006 08:49PM by rsnake.

I edited your post to make the quotes work (it needs to use a lower case "quote"). Hope you don't mind.

Anyway, 200 isn't what I'd consider "a lot" compared to how many real world PHP vulnerabilities I've seen in the wild (thousands this week alone!):

$ cat access_log |cut -f 7 -d " " |grep -c =http://
4069

So no, not a lot. However, in some cases the risks are well higher than these PHP vulnerabilities as they don't affect small homegrown websites as the PHP vulnerabilities tend to. Instead the CSRF issues affect very large applications with millions of users with brands to protect.

- RSnake
Gotta love it. http://ha.ckers.org

Thanks RSnake.

I seem to have gone off on one there, sorry about that! I had to go out halfway through writing it and I must've come back with another conversation in-mind :)

If it was really that serious Google should be aware/made aware.