OSSEC rule for Shellshock CGI attacks?

[Robert Moerman]

Hello,

I've been trying to write a rule to detect CGI-based shellshock attacks via the apache log parser, but I find the signature doesn't fire (even when I see the string in the apache logs): 

Detect "() { :; };" in url string....

<rule id="100002" level="13">

    <if_sid>31100</if_sid>

    <url>() { :; };</url>

    <description>Shellshock Attempt</description>

    <group>attack,</group>

  </rule>

Detect "() { :; };" transposed in url string....

<rule id="100003" level="13">

    <if_sid>31100</if_sid>

    <url>()%20%7B%20:;%20%7D;</url>

    <description>Shellshock Attempt</description>

    <group>attack,</group>

  </rule>

Has anyone done this successfully? 

Thanks - Rob

[Jan Andrasko]

Hello Rob,

this works for us:

<rule id="120003" level="13">
    <if_sid>31100</if_sid>
    <regex>()\.+{\.+:;};</regex>

    <description>Shellshock Attempt</description>
    <group>attack,</group>
  </rule>

Brgds

Jan

--

---
You received this message because you are subscribed to the Google Groups "ossec-list" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ossec-list+...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Michael Starks]

On 2014-10-02 8:08, Robert Moerman wrote:
> Hello,
>
> I've been trying to write a rule to detect CGI-based shellshock
> attacks via the apache log parser, but I find the signature doesn't
> fire (even when I see the string in the apache logs):
>

> DETECT "() { :; };" IN URL STRING....

>
> <rule id="100002" level="13">
> <if_sid>31100</if_sid>
> <url>() { :; };</url>
> <description>Shellshock Attempt</description>
> <group>attack,</group>
> </rule>
>

> DETECT "() { :; };" TRANSPOSED IN URL STRING....

>
> <rule id="100003" level="13">
> <if_sid>31100</if_sid>
> <url>()%20%7B%20:;%20%7D;</url>
> <description>Shellshock Attempt</description>
> <group>attack,</group>
> </rule>

Are you sure the url is successfully decoded in the logs?

[Michael Starks]

On 2014-10-03 9:12, Jan Andrasko wrote:

> <rule id="120003" level="13">
>     <if_sid>31100</if_sid>
>     <regex>()\.+{\.+:;};</regex>
>     <description>Shellshock Attempt</description>
>     <group>attack,</group>
>   </rule>

Thanks for sharing this. Any specific reason for the '\.+' after the
'()'? I'm not sure you'll always see something there. Also, the ':'
before ';' is not part of the exploit, so you may want to remove that. I
am testing this version:

<rule id="100085" level="13">
<if_sid>31100</if_sid>
<regex>()\.*{\.*;};</regex>
<description>Shellshock Exploit Attempt</description>
<group>attack,</group>
</rule>

As it were, this is a very unique string so I bet something like this
would even work without too many false-positives:

<rule id="100085" level="13">
<if_sid>31100</if_sid>
<regex>()\.*{</regex>
<description>Shellshock Exploit Attempt</description>
<group>attack,</group>
</rule>

This version should account for some URL encoding:

<rule id="100085" level="13">
<if_sid>31100</if_sid>
<regex>()\.*{|%28%29+%7B|%28%29%7B</regex>
<description>Shellshock Exploit Attempt</description>
<group>attack,</group>
</rule>

[Robert Moerman]

Michael, I'm not sure of anything, which is why I posted :) 

I'm going to try Jan's suggestion using Regex.  

[Jan Andrasko]

Hello Michael,

> Thanks for sharing this. Any specific reason for the '\.+' after the '()'?

You are right, '\.*' is better. Thanks for pointing this out.

> Also, the ':' before ';' is not part of the exploit, so you may want to remove that.

You are right again, there can be anything before ';'.

Rob,

issue with your rule was that this string is not part of url. It is usually in place of user agent, which is not decoded by Ossec. Therefore you need to regex whole log message.

Brgds

Jan

--

--- You received this message because you are subscribed to the Google Groups "ossec-list" group.

To unsubscribe from this group and stop receiving emails from it, send an email to ossec-list+unsubscribe@googlegroups.com.

[Michael Starks]

On 10/04/2014 05:30 AM, Jan Andrasko wrote:
> Rob,
>
> issue with your rule was that this string is not part of url. It is
> usually in place of user agent, which is not decoded by Ossec. Therefore
> you need to regex whole log message.
>
> Brgds
> Jan

A note about this: I have seen this exploit in several of the HTTP
headers, and even in a cookie! Since OSSEC doesn't always decode fields
correctly and since there are many parts of the log where this could
appear, I would advise against using anything like URL and just stick
with the match and regex elements.

[Robert Moerman]

Thanks very much, I've added the rule.  Appreciate the assistance! 

--

---
You received this message because you are subscribed to a topic in the Google Groups "ossec-list" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/ossec-list/BRhggipaCmc/unsubscribe.
To unsubscribe from this group and all its topics, send an email to ossec-list+...@googlegroups.com.

[gr...@castraconsulting.com]

You are relying on this <if_sid>31100</if_sid>  however that doesn't exist in 2.7.1

Where would I find the Apache rules for 2.8 so I can copy that rule in?

[Michael Starks]

On 2014-10-04 5:30, Jan Andrasko wrote:
> Hello Michael,
>
>> Thanks for sharing this. Any specific reason for the '.+' after the
> '()'?
>
> You are right, '.*' is better. Thanks for pointing this out.
>
>> Also, the ':' before ';' is not part of the exploit, so you may want
> to remove that.
>
> You are right again, there can be anything before ';'.

I think there is a bug in either the OSSEC code or documentation, as I
was getting some false-positives for this. The issue seems to be with
the () characters, which, in my experience, need to be escaped. I also
removed the <if_sid> since I know this exploit will show up in some
places that OSSEC doesn't properly decode. Here is my current testing

version:

<rule id="100085" level="13">

<regex>\(\)\.*{|%28%29+%7B|%28%29%7B</regex>

[Jan Andrasko]

Michael,

if you remove <if_sid>, will it match anything? I am trying now to play with it a bit and it doesn't match. I created vulnerable cgi script. All 40x attempts are matched by 31101.

**Phase 1: Completed pre-decoding.
       full event: '111.111.111.111 - - [07/Oct/2014:12:53:51 +0000] "GET /cgi-bin/test.cgi HTTP/1.1" 404 1666 "-" "() { test;};echo \\\"Content-type: text/plain\\\"; echo; echo; /bin/cat /etc/passwd"'
       hostname: 'Ossec1'
       program_name: '(null)'
       log: '111.111.111.111 - - [07/Oct/2014:12:53:51 +0000] "GET /cgi-bin/test.cgi HTTP/1.1" 404 1666 "-" "() { test;};echo \\\"Content-type: text/plain\\\"; echo; echo; /bin/cat /etc/passwd"'

**Phase 2: Completed decoding.
       decoder: 'web-accesslog'
       srcip: '111.111.111.111'
       url: '/cgi-bin/test.cgi'
       id: '404'

**Rule debugging:
    Trying rule: 4 - Generic template for all web rules.
       *Rule 4 matched.
       *Trying child rules.
    Trying rule: 31100 - Access log messages grouped.
       *Rule 31100 matched.
       *Trying child rules.
    Trying rule: 31108 - Ignored URLs (simple queries).
    Trying rule: 31115 - URL too long. Higher than allowed on most browsers. Possible attack.
    Trying rule: 31103 - SQL injection attempt.
    Trying rule: 31104 - Common web attack.
    Trying rule: 31105 - XSS (Cross Site Scripting) attempt.
    Trying rule: 31110 - PHP CGI-bin vulnerability attempt.
    Trying rule: 31109 - MSSQL Injection attempt (/ur.php, urchin.js)
    Trying rule: 31164 - SQL injection attempt.
    Trying rule: 31165 - SQL injection attempt.
    Trying rule: 31501 - WordPress Comment Spam (coming from a fake search engine UA).
    Trying rule: 31502 - TimThumb vulnerability exploit attempt.
    Trying rule: 31503 - osCommerce login.php bypass attempt.
    Trying rule: 31504 - osCommerce file manager login.php bypass attempt.
    Trying rule: 31505 - TimThumb backdoor access attempt.
    Trying rule: 31506 - Cart.php directory transversal attempt.
    Trying rule: 31507 - MSSQL Injection attempt (ur.php, urchin.js).
    Trying rule: 31508 - Blacklisted user agent (known malicious user agent).
    Trying rule: 31511 - Blacklisted user agent (wget).
    Trying rule: 31512 - Uploadify vulnerability exploit attempt.
    Trying rule: 31513 - BBS delete.php exploit attempt.
    Trying rule: 31514 - Simple shell.php command execution.
    Trying rule: 31515 - PHPMyAdmin scans (looking for setup.php).
    Trying rule: 31516 - Suspicious URL access.
    Trying rule: 31550 - Anomaly URL query (attempting to pass null termination).
    Trying rule: 31101 - Web server 400 error code.
       *Rule 31101 matched.
       *Trying child rules.
    Trying rule: 31102 - Ignored extensions on 400 error codes.
    Trying rule: 31140 - Ignoring google/msn/yahoo bots.
    Trying rule: 31141 - Ignored 499's on nginx.
    Trying rule: 31151 - Multiple web server 400 error codes from same source ip.

**Phase 3: Completed filtering (rules).
       Rule id: '31101'
       Level: '5'
       Description: 'Web server 400 error code.'
**Alert to be generated.

There is even bigger issue. When status code is 200, rule 31108 matches and attack is ignored

**Phase 1: Completed pre-decoding.
       full event: '111.111.111.111 - - [07/Oct/2014:12:53:51 +0000] "GET /cgi-bin/test.cgi HTTP/1.1" 200 1666 "-" "() { test;};echo \\\"Content-type: text/plain\\\"; echo; echo; /bin/cat /etc/passwd"'
       hostname: 'Ossec1'
       program_name: '(null)'
       log: '111.111.111.111 - - [07/Oct/2014:12:53:51 +0000] "GET /cgi-bin/test.cgi HTTP/1.1" 200 1666 "-" "() { test;};echo \\\"Content-type: text/plain\\\"; echo; echo; /bin/cat /etc/passwd"'

**Phase 2: Completed decoding.
       decoder: 'web-accesslog'
       srcip: '111.111.111.111'
       url: '/cgi-bin/test.cgi'
       id: '200'

**Rule debugging:
    Trying rule: 4 - Generic template for all web rules.
       *Rule 4 matched.
       *Trying child rules.
    Trying rule: 31100 - Access log messages grouped.
       *Rule 31100 matched.
       *Trying child rules.
    Trying rule: 31108 - Ignored URLs (simple queries).
       *Rule 31108 matched.
       *Trying child rules.
    Trying rule: 31509 - CMS (WordPress or Joomla) login attempt.

**Phase 3: Completed filtering (rules).
       Rule id: '31108'
       Level: '0'
       Description: 'Ignored URLs (simple queries).'

Jan

[Art Mandler]

Hey folks -- Did anyone ever come up with a working solution for 2.8?  

Thanks,

Art

[Doug Burks]

Hi Art,

Have you considered using Bro for ShellShock detection? It looks for
not only attempts, but successful exploitation:
http://blog.securityonion.net/2014/10/new-securityonion-bro-scripts-and.html

> --
>
> ---
> You received this message because you are subscribed to the Google Groups
> "ossec-list" group.
> To unsubscribe from this group and stop receiving emails from it, send an

> email to ossec-list+...@googlegroups.com.

> For more options, visit https://groups.google.com/d/optout.

--
Doug Burks
Need Security Onion Training or Commercial Support?
http://securityonionsolutions.com

[Art Mandler -- Skyrunner]

Thanks.  I'll take a look at it.  I'm pretty sure I have shellshock patched, but I'm still seeing some files placed in my /tmp and /dev/shm directories (although harmlessly as I've mounted them both noexec).  I have over 100 domains with php on my server, so obviously something is compromised, but I'm not finding where.  

Best regards,

Art

--

---
You received this message because you are subscribed to a topic in the Google Groups "ossec-list" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/ossec-list/BRhggipaCmc/unsubscribe.
To unsubscribe from this group and all its topics, send an email to ossec-list+...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

Art Mandler

Vice President

Skyrunner, Inc.

5 Ravenscroft Drive

Asheville, NC  28801

828-258-8562

[Michael Starks]

On 10/25/2014 10:03 AM, Art Mandler wrote:
> Hey folks -- Did anyone ever come up with a working solution for 2.8?

Does the rule I posted not work for you?

[Art Mandler]

The

 <if_sid>31100</if_sid> 

seems to be the problem, since 31100 doesn't exist in my version of ossec. 

Removing it means the rule matches nothing.

However, with over 300,000 attempts in the past week (based on a grep of the Apache access logs), it's probably a waste of time to monitor attempts.... The only real concern are exploits that succeed.

Art

[dan (ddp)]

On Mon, Oct 27, 2014 at 10:58 AM, Art Mandler <sogg...@gmail.com> wrote:
> The
> <if_sid>31100</if_sid>
> seems to be the problem, since 31100 doesn't exist in my version of ossec.
> Removing it means the rule matches nothing.
>

What is the first rule in your web_rules.xml file?

> However, with over 300,000 attempts in the past week (based on a grep of the
> Apache access logs), it's probably a waste of time to monitor attempts....
> The only real concern are exploits that succeed.
>
> Art
>
>
> On Sunday, October 26, 2014 6:37:05 PM UTC-4, Michael Starks wrote:
>>
>> On 10/25/2014 10:03 AM, Art Mandler wrote:
>> > Hey folks -- Did anyone ever come up with a working solution for 2.8?
>>
>> Does the rule I posted not work for you?
>>

> --
>
> ---
> You received this message because you are subscribed to the Google Groups
> "ossec-list" group.
> To unsubscribe from this group and stop receiving emails from it, send an

> email to ossec-list+...@googlegroups.com.

[Michael Starks]

On 2014-10-27 9:58, Art Mandler wrote:
> The
> <if_sid>31100</if_sid>
> seems to be the problem, since 31100 doesn't exist in my version of
> ossec.
> Removing it means the rule matches nothing.

This is the version I am currently running. I have had one
false-positive where there was a '{' about 100 bytes after a '(' in a
very big debug log.

<rule id="100085" level="13">

<regex>\(\)\.*{|%28%29+%7B|%28%29%7B</regex>

<description>Shellshock Exploit Attempt</description>
<group>attack,</group>
</rule>

> However, with over 300,000 attempts in the past week (based on a grep
> of the Apache access logs), it's probably a waste of time to monitor
> attempts.... The only real concern are exploits that succeed.

Indeed. But it could also be used to fire an active response and not
alert you.