PHPIDS Released
christ1an just announced that PHPIDS has been released. This has been in development for quite a while, but the intention is to react (more like an IPS than an IDS) to potential attacks. From the site:
The IDS neither strips, sanitizes nor filters any malicious input, it simply recognizes when an attacker tries to break your site and reacts in exactly the way you want it to.
If you are running any custom PHP programs, I’d suggest taking this for a spin. As it is a first public release there will no doubt be some issues, but with the community’s help, hopefully this will turn into more of a ubiquitous tool to stop attackers from exploiting PHP applications. Please provide feedback about it’s use. I’m sure it will become a valuable resource. Nice work by .mario, crist1an and Lars.
June 11th, 2007 at 7:12 am
Robert, people will never harden PHP
Three tries, and the script killes itself (to much recoursion):
“Fatal error: Allowed memory size of 134217728 bytes exhausted (tried to allocate 67108872 bytes) in /home/phpids/demo/ids.php on line xxx”
My hint: Although christ1an is German, they should at least try our own “special chars” ä, ö and ü =P
regards, beni
June 11th, 2007 at 7:31 am
@beNi: Thanks - we already know this issue and fix is in prgress…
June 11th, 2007 at 8:53 am
Ok, we located the problem and plan to publish the 0.2.1 this evening (now+2hrs) including fresh filter rules and better UTF7 detection. thanks again for the input.
Greetings,
.mario
June 11th, 2007 at 7:07 pm
Just some fun:
http://phpids.heideri.ch/?test=%20%3Cmarquee%20scrollamount=5
June 11th, 2007 at 7:28 pm
It looks like the website is experiencing problems, as all I get is a page saying it’s scratching its feet, or something. I’m curious as to the benefit of this over a standard IPS solution. I couldn’t find a description. To me, from a 50 yard view, it seems redundant and adds additional load to a critical device (webserver).
I’m not trying to discredit your work, but I think I must be missing something?
June 11th, 2007 at 8:00 pm
I think, they have taken it off until the new release.
If you want to take a look at it, go out and visit http://phpids.heideri.ch
(don’t know the version).
Explanation of the benefit over an IDS/IPS:
http://christ1an.blogspot.com/2007/05/real-effectiveness-of-current-waf.html
June 11th, 2007 at 11:45 pm
Yes - unfortunately we had a database crash - I’ll call in when problems are solved…
June 11th, 2007 at 11:50 pm
Well the good thing about all these HTTP aware IPS, IDS, WAF is that they created a “new” class of vulnerabilities in web applications/web servers.
Nowadays you can completely stop people from using a particular web application by infecting their browsers with cookies that will trigger the IPS, IDS, WAF rules and deny the request.
Infection ways are many: vulnerability in the app or in another app in the same domain, universal xss, browser cross domain vulns, browser plugin cross domain vulns, … And for example blub.co.kr can still set cookies for *.co.kr in Firefox. One cookie is enough to “DOS” all PHP servers in korea… I call that effective…
I gave a talk about this problem at the cologne PHP user group on 1st June.
PS: This problem is exactly the reason why Suhosin drops input variables that were detected as malicious instead of blocking the whole request.
PS2: Servers using mod_snakeoil^H^H^Hsecurity can usually be dossed with a simple cookie like name=%00%xx%
June 12th, 2007 at 5:12 am
Stefan: Good point however not applying to PHPIDS and therefore calling it a new class of vulnerability makes as much sense as calling Suhosin a vulnerability of that kind.
From the very beginning the PHPIDS was never designed to block or sanitize anything by default. The only goal it tries to achieve is to detect possible attacks.
But thanks for your advice, we’ll cover that part in the documentation so developers don’t fall into that trap.
June 12th, 2007 at 6:08 am
Addendum: You have to use Firefox 2.x and have JavaScript enabled for that link above to work.
June 12th, 2007 at 7:03 am
christ1an: If I see correctly you check _REQUEST in your example for CakePHP. _REQUEST contains cookies. And what is the application supposed todo with the information that it is attacked? It will most probably refuse to work with a nice error screen.
Voila… DOS through the usage of PHPIDS.
Btw I did not call PHPIDS a “new” vulnerability but DOS through Cookie Infection. A whole bunch of web applications are vulnerable to this. Especially all those using _REQUEST all over the place.
The message is simple: when you scan cookies for attacks the only option you have is to remove those that attack you. Blocking completely is no option and letting them through is also no option. But even if you drop only those considered an attack PHPs feature to ignore whitespace in the beginning of a variable name is still breaking your neck (if you try to handle it from PHP userspace).
June 12th, 2007 at 7:44 am
Yeah your statment about DOS through cookie infection is absolutely right and I also agree that many applications will be vulnerable to this.
However I need to defend the PHPIDS on this matter. It is not the PHPIDS that makes the application vulnerable but the kind of reaction the developer implements.
So consider the CakePHP a bad example that should be imrpoved the way you proposed to prevent DOS attacks.
June 12th, 2007 at 8:07 am
“However I need to defend the PHPIDS on this matter. It is not the PHPIDS that makes the application vulnerable but the kind of reaction the developer implements.”
exactly - if you use the PHPIDS and implement a reaction like showing an error page (like we did in our still fucked up blog) you should pretty much know what you’re doing and when you do it. that’s the reason why you don’t find example logic that redirects or does worse in the examples.
For learning sake you should use the PHPIDS in silent mode first - and log or mail what’s coming in - to give you an overview on what’s happening on your domain and where.
Regards,
.mario
June 13th, 2007 at 1:24 am
Hi!
We’re back - Trac and forum are still down but you can use page and downloads again. I guess by tomorrow the whole estate should be working again.
http://php-ids.org/
Thanks for your support!
.mario