Wednesday, March 26, 2008

PHP IDS and Web application firewalls

| Armando Romeo |

PHPIDS is by far the best in its field. It offers the features of an IDS for php applications, it's completely open source,  free and customizable. Rules are easily added through a handy xml file.
Although it has not been yet released a mature/stable version I noticed a good interest from the community. I am not sure if it is due to webmasters laziness, or the benefits PHPIDS can  bring to the overall web application security.



The risk with such kind of tool is to think that it is going to solve all kind of security problems. Want to say it now. It is *just* another layer of security
and will never be as effective as a real source code audit or vulnerability assessment.

Web application firewalls or IDS are still far from being an ultimate solution and probably they will never reach this stage as much as network firewall do not solve all network security problems.

Moreover, I see a bit of confusion in terminology about WAFs. In networking field firewall is something working on connection basis. That is you determine a traffic pattern using wildcards and then apply some rule to it.
WAFs available now act mainly like IDS instead.


Attacks on web applications are held through HTTP, that is Application layer. We are going to filter according to user (malicious) input, not user connection to forbidden ports/ip. So the name Waf is just incorrect.

PHPIDS is just on this task. You can choose to inspect GET, POST, SESSION and COOKIE and match user input with  an xml defintion file which off-the-shelf offers a good protection level against XSS, RFI, LFI, Sql injection.

I personally don't think at it as a safety feature even if without any doubt it adds some real benefit.

I take it as a way to understand where attacks are coming from and where
they are going to: it makes it easy to trace malicious attempts, instead of plumbing logs for attacking payloads.

According to impact level you can choose wether to log it on file or have a detailed report mailed to you.
Stats on hacking attempts against hackerscenter clearly show that I would end up with a DoS against my mail box if I enable this feature ;) .
Logging to database is my favourite solution.

I'm testing PHPIDS locally on Joomla and attacking it with pen testing tools to see what's catched and what not.
Will show my results and maybe a quick guide on how to install phpids in my next blog post...


Monday, March 17, 2008

Patch management for HOME Pc: Secunia PSI

| Armando Romeo |
I find it better than Antivirus. It is well-known, my bad feelings against Antiviruses. So I can argue this tool is much more useful
than any Antiviruses. Just ask yourself how a hacker can infect you with a malware.


Most of the cases it is by exploiting a vulnerability into one of the software installed on your PC. This has been done by the most dangerous malwares in the last years.
They need a vulnerability to spread. So why not stopping vulnerabilities instead of hoping that AV updates will cure the disease while
the hole will still remain open?

I must say that I was impressed by this new tool from Secunia. And more impressed by the fact that it is free.

Secunia PSI makes it extremely easy to keep up your computer up to date with the latest patches available from secunia patches database.
It works by scanning your pc, locate old software with recognized vulnerability and apply patch. Completely automatic and with a nice interface.

It stays in the tray and warns you about available patches.

It also provides a nice score of the overall security level of your installed software,
an easy way to incentivate users to reach a higher level of protection.
The numbers shown by Secunia says it all:

Adobe Reader 8.x 172,653 61.07% of all computers affected
Apple Quicktime 7.x 133,169 47.10% of all computers affected
Sun Java 1.5.x 98,618 34.88% of all computers affected
Skype 3.x 57,496 20.34% of all computers affected

And I must admit that even my PC needed a bunch of fixes when I first tried PSI.
I recommend to disable the "Show only easy to patch programs" if you're familiar enough with your PC.

All in all, especially under windows, patches are almost always an executable that you have to double click...

Citing Secunia: "81.01% of all computers connected to the Internet needs to apply at least one security update to secure their computer, until updated, users risk falling victim of a hacker by simply: Visiting a website, opening a PDF file, viewing a movie, etc. - and this is just over a period of 24 hours"

Interesting isn't it?
I find PSI one of the best tools available for personal security. Something it should be there along with the useless AV's, that
will fail to recognize a fingerprint of a virus in which the coder has changed 1 single byte of the source code.


Tuesday, March 11, 2008

CSRF in Pills

| Armando Romeo |
I decided to put down few frequently asked questions about CSRF vulnerabilities after my recent efforts into securing joomla from this kind of attack. There is still a big part of the web app field who still has no idea about how csrf work, and even if they try to fix it, they do not understand it fully failing to cover all the mount points of such fascinating
attacking vector.


I'm not going much into details on what CSRF is since there are many good resources online where read about it and opefully understand it.

So why writing a FAQ? Well because I have seen too many pen testers failing to understand the real power of it not giving to it the right importance and weight CSRF should have into their vulnerability assessment reports.

Let's start :

How does CSRF differ from XSS?
In the end they are both Cross-site!
Well, no. There are more differences than what the name says.
I never liked acronyms. I would call XSS a script injection attack since this is just how it works.

With CSRF there's no script injection, at least for a basic and standard attack. Moreover CSRF doesn't require scripting or HTML to be successful.
A link is enough in a simple scenario.
Another difference is in the final goal a hacker wants to achieve. XSS in most of the cases is used to steal cookies or deface. CSRF is much more powerful. Basically it enables a hacker into performing a privileged
action on behalf of the victim. With the same privilege level of the victim. This leads me to the next question.

How is CSRF dangerous?
Dangerous. In my opinion more dangerous than XSS in most of the cases.
With the worst kind of XSS a hacker can manage to steal a session cookie getting into the victim's account.
CSRF doesn't steal cookies (once again in a basic scenario in which only CSRF is involved) but still lets a hacker perform a privileged action.
The privilege level is the same of victim's.

In the CSRF I have found in Joomla (and other web applications) a hacker was able to create a NEW super admin account.
This means complete portal compromise, this time not limited to session cookie lifetime.
Moreover a CSRF in the file management page let a hacker upload any kind of file on server. Shell says nothing to you? Server compromise, yes.

So basically, think of what a privileged user (being it a standard member or an admin) can do on a site and you get the danger level.

How stealth is CSRF compared to other attacks?
Well probably it is the hardest to track.
Sometimes it can get nearly impossible since there's no injection and it leaves
no traces into any logs.
Let's take the Joomla sample that fits well in our discussion.
To get a superadmin account a hacker would require to have a superadmin (Bob) visits a forged link or visits a malicious web page, or in general triggers
an url in whatever elite and evil way you can think of.
Bob, after triggering the forged url, won't notice any suspicious activity going on under his nose.
However, the forged url added a new superadmin using Bob's open session (if it is actually open) on his own portal. This means that on Bob's server log, the action will be recorded as taken by Bob himself of course.
Stealthness level can be increased using more sophisticated techniques but in general CSRF is not an attack held directly towards the
victim website.

The image below can clarify this furthermore.


How can I prevent CSRF?
This is the most frequently asked question that a security response team makes when you report such a vulnerability.
Before I give any explanation I usually forward them to the literature available. Since successfully fixing a bug is not a task you can do without understanding its nature.

The most obvious and common answer you find in literature is to use tokens.
I personally wouldn't look at tokens as the ultimate csrf solution since a token can be stolen (I'm working on this, and I should come up soon with some proof of concept).

So basically tokens are random strings (usually obtained by hashing some random number) that are generated for every form in a web application and inserted into a hidden form field. The token value is also stored into the user session variables set and the two are compared upon data retrieval when the form is submitted. If they match, pass. Else block the user from
performing the action.

This works well of course. And works well (actually it is the only solution I'm aware of) for those actions performed through HTTP GET method (the token is passed in the querystring).  So it's a decent solution for most of the cases
if token stealing code is not took in place (Which is something that requires a much more complicated attacking model and sometimes
hardly successful).

A solution I always propose is the use of captchas. Those nice images, invented to keep spammers away can come in handy to ensure that the request is valid and performed by the intended privileged user.
Even here a "good" captcha
should be used since there is a good research in this field and spammers are getting smarter and smarter with OCR techniques

So it's enough for this introductory discussion about CSRF. My research on CSRF will not end here and I will decide to write more on the topic according to audience attention and interest.

Free Security Magazines