Don’t panic!

I know it’s unusual for me not to post in nearly a week – however I just wanted to let you all know that I’m giving the paws a much needed rest and promoting some healing so I can jump back in the saddle before the end of the week.

I have a tendency to not let myself heal all of the way. This time I need to do it the “write” way. :-)~

Thanks for your patience. Keep the e-mails coming everyone. I read every one of them.

I’m also soliciting some ‘banana cupboard’ stories for

continue reading.....

It has been more than a year since Michael Lynn first demonstrated a reliable code execution exploit on Cisco IOS at Black Hat 2005. Although his presentation received a lot of media coverage in the security community, very little is known about the attack and the technical details surrounding the IOS check_heaps() vulnerability. This paper is a result of research carried out by IRM to analyse and understand the check_heaps() attack and its impact on similar embedded devices. Furthermore, it also helps developers understand security-specific issues in embedded environments and developing mitigation strategies for similar vulnerabilities. The paper primarily focuses on the techniques developed for bypassing the check_heaps() process, which has traditionally prevented reliable exploitation of memory-based overflows on the IOS platform. Using inbuilt IOS commands, memory dumps and open source tools IRM was able to recreate the vulnerability in a lab environment. The paper is divided in three sections, which cover the ICMPv6 source-link attack vector, IOS Operating System internals, and finally the analysis of the attack itself.

continue reading.....

Last week I released the second ModSecurity development release, 2.5.0-dev2, in preparation for the next version of ModSecurity. Some may notice that this version is now 2.5.x where as the first development release was 2.2.x. Ivan and I decided that because of the large feature sets going into this next release we would bump the version to 2.5.x to signify a halfway point to 3.0.0. This release is primarily a performance enhancement release, so I want to introduce two of the main new features in more detail.

In this release, I have introduced a phrase matching operator (@pm) to match against a list of phrases. The new operator uses the Aho-Corasick algorithm and is many times faster than the default regular expression operator (@rx) for lists of OR’d phrases. For example, if you want to accept only GET, POST and HEAD requests the following rules are equivalent, but the second is faster (even more so as the list grows):

SecRule REQUEST_METHOD "!^(?:GET|POST|HEAD)$" t:none,deny
SecRule REQUEST_METHOD "!@pm GET POST HEAD" t:none,deny

The new @pm operator should be used for static lists of phrases (black/white lists, spam keywords, etc). However, for large lists, this new operator may cause the rule to become difficult to read and maintain. If your lists are large, you can use an alternate form (@pmFromFile) that accepts a list of files and place the phrases into a file or multiple files (one per line) instead of inline. In this form, the phrase file(s) will be read on startup. To allow for easy inclusion of third party phrase lists, if the filename is given with a relative path, then ModSecurity will look for it starting in the same directory as the file that contains the rule specifying the file. For example:

SecRule REQUEST_METHOD "!@pmFromFile allowed_methods.txt" t:none,deny

### And in allowed_methods.txt in the same directory:
GET
POST
HEAD

Another performance enhancement (that is still being tuned) is transformations are now cached for each transaction. With previous versions of ModSecurity, the transformations for each rule were applied in the order specified to the original value. This was done for every variable in every rule. Starting with ModSecurity 2.5.0-dev2, transformations will only be performed once for each transaction. If more than one rule uses the same transformed value, then the cached value is used instead of reapplying the transformations.

As always, the source code is available in the download section of the ModSecurity Website. Below is an outline of the new features and changes in this release so far. Please see the documentation included in the release for full details and usage examples. Please direct any comments to the ModSecurity User Support mailing list.

Major Changes Since Version 2.1.1

2.5.0-dev2

• Added new phrase matching operators, @pm and @pmFromFile. These use an alternate set based matching engine (Aho-Corasick) to perform faster phrase type matches such as black/white lists, spam keywords, etc.
• Cache transformations per-request/phase so they are not repeated.
• Added @within string comparison operator with support for macro expansion. This was discussed as @contained on the user list, but this seemed too similar to @contains. This operator looks for a variable value within the operator value (opposite of @contains which looks for the operator value in the variable value).
• Fixed issue with requests that use internal requests. These had the potential to be intercepted incorrectly when other Apache httpd modules that used internal requests were used with mod_security.
• Fixed decoding full-width unicode in t:urlDecodeUni.
• Added matching rule filename and line number to audit log so that it is much easier to figure out which rule caused an alert to be generated.
• Enhanced PDF protection allows a choice of forced downloads (of PDF files) or use of token redirection.
• Various other bug fixes and smaller changes. See the CHANGES file and/or the ModSecurity Reference Manual in the release for more details.

2.2.0-dev1

• Experimental support for content injection. You can use @prepend value and @append value to inject content into the output.
• PDF XSS protection added.
• Geographical lookups by IP address/hostname were added. With this you can access the country, city, postal code, etc. — within a new GEO collection — from any existing ModSecurity variable by using the new @geoLookup operator.
• String comparison operators — @streq, @beginsWith and @endsWith — to allow an easier-to-use non-regular expression operator. Values will have macros interpreted prior to a match, so that you can do "@streq %{REMOTE_ADDR}", etc.
• A length transformation — t:length — transforms a value into a numeric character length.
• Whitespace trimming transformations are now available. Use t:trimLeft, t:trimRight or t:trim to trim whitespace from the left, right or both, respectively.
• Experimental variables — RESPONSE_CONTENT_LENGTH, RESPONSE_CONTENT_TYPE, and RESPONSE_CONTENT_ENCODING — were added.
• Added the filename and line number of the rule to the debug log on its execution. I will add it to the audit log in the next development release.
• Removed support for CGI style HTTP_HEADER_NAME variables for request headers. The 2.x REQUEST_HEADERS:Header-Name should now be used.
• Removed support for %0 - %9 TX variables that expanded to numbered captures. Use %{TX.0} - %{TX.9} instead.
• Various other bug fixes and smaller changes. See the CHANGES file in the release for more details.

continue reading.....

A very interesting research paper titled “Apache Prefork MPM Vulnerabilities” was released a few days ago, as you can see in the corresponding Bugtraq post. The paper describes, in detail, the dangers of allowing third-parties to run code under the same account as the Apache web server. This normally happens when dynamic content is produced using Apache modules (e.g. PHP) or when CGI scripts are configured to run without suEXEC. This topic itself is not new. You will find several articles on runtime process infection following this Google search link. I warn about this problem throughout my book and especially in Chapter 6, which is dedicated to those situations when more than one party is using the one Apache installation. However, it is one thing to know that something is possible and another to demonstrate, step by step, how it is done. Another interesting finding resulting from this paper is that it is possible to send a SIGUSR1 signal, as root, to any process on the system instead of just to Apache children processes. This is an issue that will have to be fixed in one of the future versions of Apache.

This problem with running code as the same identity as the web server is well understood (and has been for years) among the advanced Apache users. The solution is to always execute CGI scripts through suEXEC and to never allow third parties access to any of the modules. The real problem is that, as with any other product, there are few people who understand Apache inside out (and they can protect themselves) but there also those who are using the technology but do not have the luxury of learning everything there is about it (and there are many legitimate reasons for that).

The solution is obvious. Apache must be safe out of the box! We should dispense with the idea of running things in the same process. Process isolation facilities (either suEXEC or something else) should be installed and running by default on all installations. We can and should make provisions for those who know what they are doing to shoot themselves in the foot, of course. But the only reason to attempt to run things in the same process is performance and I suspect, in this day and age, virtually all users will be happy with the performance of their web server doing things in a secure manner.

continue reading.....

CAREFUL! This diary contains links to malicious code!
A number of MySpace profiles include drive by …(more)…

continue reading.....

Several of our readers reported an email that lead to a fake Microsoft patch being spammed on the n …(more)…

continue reading.....

On June 26th 2007, Microsoft re-released the MS07-022 update for Windows 2000 SP4. …(more)…

continue reading.....

One suggestion from Chris in the UK.
SPF is a red herring here – you surely know what IP address(s) …(more)…

continue reading.....

Nick submitted a nice piece of malware we are currently looking at. The malware itself includes a ni …(more)…

continue reading.....

Today, Robert reported that he is seeing a higher then normal spam volume. We do get notes like this …(more)…

continue reading.....

Philipp K from Vienna, Austria submitted this story, which I found very enlightening. In it …(more)…

continue reading.....

On Thursday Apple releases a patch which addresses a cross-site scripting vulnerability. These …(more)…

continue reading.....

Simple Invoices Index.PHP SQL Injection Vulnerability

continue reading.....

The Symantec folks identified a website exploiting a bug from this months Microsoft patches, specifi …(more)…

continue reading.....

Yesterday we published a diary about blocking active code in banner ads. Adrian wrote to us to …(more)…

continue reading.....

Many folks have asked if I’ll be speaking at DEFCON and Blackhat this year in Vegas. I’m honored to have been invited to both. I can’t wait to meet as many of you as possible. Also, I was happy to read this month’s issue of Vanity Fair (http://www.vanityfair.com/politics/africa), co-edited by Bono, and entirely dedicated to Africa. I was also thrilled to learn about “beads for life” (www.beadsforlife.com (http://www.beadsforlife.com/) and www.beadsforlife.org (http://www.beadsforlife.org)) which is selling Jewelry and necklaces to benefit the vulnerable in Uganda! This is almost exactly what we’re trying to do to help out the women in the Bugembe district of Uganda (http://johnny.ihackstuff.com/uganda) on behalf of AOET (http://www.aoet.org). Cool stuff, and it comes close to hitting the mark: empowerment, not charity. Thanks for your support!

continue reading.....

Well, it was bound to happen. The research chat rooms and mailing lists are all bu …(more)…

continue reading.....

One of our readers, Walter, wrote to us today with a request to owners of websites: please blo …(more)…

continue reading.....

This is not the first time that PayPal is vulnerable to cross-site scripting… 142TeeTH has discovered and submitted to us the two XSS vulnerabilities affecting PayPal.com. According to him, PayPal’s technical staff are already aware of the issues.

continue reading.....

Susam Pal and Vipul Agarwal published today an interesting advisory about some vulnerabilities affecting Orkut – the famous social networking website, owned by Google. They state two things… Updated: July, 2nd 2007

continue reading.....

EKG Multiple Remote Denial of Service Vulnerabilities

continue reading.....

In a previous Blog entry, I outlined a number of steps that you could take to increase performance of the ModSecurity open source Console. While these tuning steps will certainly help to increase performance, there is still one big issue that will bring the open source Console to its knees – too many open/active alerts in the Alert Management interface (where the URL is – http://ip_of_your_console:8886/viewAlerts). Having too many open alerts will chew up the available memory for the MUI and it will become unresponsive.

If you are in the scenario where you already have too many active alerts and the MUI is totally non-responsive, you may have to try and bypass the MUI and instead use the Java Derby DB client to interact directly with the DB listener and close the active alerts.

Removing Too Many Existing Alerts from the MUI

Here are the steps:

1. Stop the currently running console with –

   # ./modsecurity-console stop

   You should then check the “ps” output to ensure that the Java process is not hanging. If it is, you may need to either re-execute that command or issue a kill command to that specific process number.

2. Enable remote access to the database by editing console.conf and changing the startNetworkServer setting to "true". You will need to use the same username/password when connecting later with the Derby client.

   <Service derby com.thinkingstone.juggler.components.DerbyServer>
       Property password "XXXXX"
       Property startNetworkServer "true"
       Property host "0.0.0.0"
       Property username "XXXXX"
       Property port "1527"
   </Service>
   

3. Restart the console with -

   # ./modsecurity-console start

4. Verify that the DB listener is up and running on port 1527 with -

   # netstat -nlp | grep 1527

5. CD into the modsecurity-console/lib/ directory and then start the
   java commandline utility like this -

   java -classpath derbyclient.jar:derbytools.jar -Dij.driver='org.apache.derby.jdbc.ClientDriver' org.apache.derby.tools.ij

6. Connect to the Derby DB like this (make sure to substitute your Host:port and username/password info) -

   connect 'jdbc:derby://HOST:PORT/consoleDb;username=USER;password=PASS';

7. To close all open active alerts -

   UPDATE alerts SET alert_status = 'CLOSED' WHERE alert_status = 'OPEN';

8. Then restart the modsecurity-console -

   # ./modsecurity-console start

9. Attempt to access the MUI
   

Is There A Better Way To Manage Alerts?

If you are becoming frustrated with the performance of the open source Console and/or if you have more then 3 ModSecurity sensors to manage, you may want to consider taking a look at Breach’s commercial ModSecurity Management Appliance that was just recently made available. It has many significant performance increases and is an enterprise class solution (it can manage up to 50 ModSecurity Sensors).

continue reading.....