I’ve written about security in web applications before. Common Intrusion Detection (and prevention) products fail to properly defend web applications from attacks such as XSS, SQL Injection etc. It don’t see them getting better at it either. Web application firewalls, aka WAFs, do a much better job, much due to it’s reverse proxy architecture that allows it to properly decode the application flow.

Another way would of course to implement the IDS functionallity in the web application itself, and this is what PHPIDS does:

PHPIDS (PHP-Intrusion Detection System) is a simple to use, well structured, fast and state-of-the-art security layer for your PHP based web application.

Currently the PHPIDS detects all sorts of XSS, SQL Injection, header injection, directory traversal, RFE/LFI, DoS and LDAP attacks. Through special conversion algorithms the PHPIDS is even able to detect heavily obfuscated attacks - this covers several charsets, entities of all forms, comment obfuscation, obfuscation through concatenation, shell code and many other variants. Furthermore the PHPIDS is able to detect yet unknown attack patterns with the PHPIDS Centrifuge component.

The security of applications are hardly ever though of in this way. If we are looking at the source, why not patch the vulnerability instead of implementing code to detect attacks at them? Well, we might not discover all vulnerabilities, and this kind of security implementation allows for detecting intent.

What many people seem to forget when thinking about IDS and especially IPS-systems is the important tie they have to performing network forensics. Not all attacks will be blocked, and the ones that are detected by other means needs to be investigated. What equipment is better suited for that than a device that sits inline, at the perimiter or core, monitors all sessions entering and leaving the premises, and that at least tries to identify possibly malicious elements of the monitored traffic. That’s right, none. The true value of a modern monitoring system is that they are a tool for investigating security incidents - not just blocking them.

Having this in mind, this puts new requirements on the IDS/IPS. Not only should they have a good detection rate and low false positive rate, they should also have the necessary information available to actually investigate the indications that alerts truly are, but also investigate traffic that isn’t tied to an alert. Further more, which is one of the crucial elements of performing forensics, is to avoid informing the potential attacker about your knowledge of an attack. This is lesson 1A in incident handling - never try to contact the source of the alerts; never visit the website that the attack is coming from etc. All these actions might inform the attacker of your knowledge of the compromise, and as such will cripple your ability to investigate it.

Related to this is the fact that most IDS/IPS systems, and some firewalls aswell for that matter, does lookups of source and target IPs in the alerts. This feature, which is intended to make the alerts more easily readable, might in fact inform the attacker that some system has processed the traffic from him. When an alert fires the system will automatically try to do a reverse lookup on the IP, the host will contact the root server and follow it’s trail down to the DNS server that has information about the IP in question. This DNS-server could very likely be run by the attacker who now sees someone doing lookups on his IP. See how the solution itself contributes to the problem?

A possible solution to this, which doesn’t involve turning of name resolution entirely, is to be able to configure the system to use 3:rd party dns-servers or dns-proxies for external IP:s. I learnt of a tool that has implemented the support for this, namely the excellent network security monitoring console Sguil.

A couple of days ago I learnt from IDG about the disclosure of 100 e-mail accounts from parlaments and other high profile targets world-wide. The incident is also covered in international zines like the Register and Vnunet.

Whats interesting about this is the decision made by the consultant to disclose the information, and his reasoning,

“Here is a list with working passwords to exactly 100 email-accounts to Embassies and Governments around the world. Yes it’s the real deal and still working when we are posting this. So why in the world would anyone publish this kind of information? Because seriously, I’m not going to call the president of Iran and tell him that I got access to all their embassies.

Leaving the ethical and moral discussion aside, which in fact is to obvious to warrant discussion, and instead focusing on the difficulty of disclosing this kind of information. Lets identify the difficulties of informing 100+ victims having their e-mail accounts compromised:

1. Who do we inform of the compromised accounts? We can try the accounts themselves, but we can’t be sure that someone using the credentials removes the e-mail. Does all parlaments have a website? Do they have a technical contact? Just searching for a e-mail adress to target the information with might be very time consuming.
2. Who would understand what we were saying? Even though saying “I have login credentials to your e-mail and can read your e-mail” would likely catch anyones attention, few would understand the extent and seriousness of this. Just getting the attention might be time consuming.
3. Who would believe what you were saying? Prove it, they would say. Yeah, on 100+ accounts.

So what should you do?

• Contact and inform your national incident response team of the situation. Hand them the information and let them own the case. The have the time and resources, and will likely be very keen to help , especially in this case since it is of national interest. I, for instance, would contact SITIC.
• Another possibility is to work with a security partner who have contacts, experience and resources to notify the customers.

This is an example of why we need the security industry.