Saturday, 18. October 2014Week 41

Show Shellshock the door

Lately the requests trying to exploit the Shellshock vulnerability are getting annoying. Of course my hosts are patched — even before the first such request arrived — and they are using Dash as /bin/sh anyway.
But this does not stop attackers from sending those requests. Some even seem to have programmed a loop which sends request after request even though their exploit is not working.

Since most of the requests are for valid URLs, the webserver just replies with a 200 status code and serves the content. As this gives no indication to the attacker whether his exploit worked or not, he has no reason to remove the host from his target-list and thus continues to send requests.

To break this pattern and signal that the host is not vulnerable to Shellshock, I came up with the nginx config snippet below. It recognizes Shellshock patterns in a request and replies with a '403 Forbidden' status code, thus indicating to an attacker that his request was blocked.

if ( $http_referer ~ ^\s*\(\s*\)\s*\{ ) { 
        return 403 "Blocked by Shellshock protection (https://blog.x-way.org/Show-Shellshock-the-door).";
}
if ( $http_user_agent ~ ^\s*\(\s*\)\s*\{ ) { 
        return 403 "Blocked by Shellshock protection (https://blog.x-way.org/Show-Shellshock-the-door).";
}
if ( $http_cookie ~ ^\s*\(\s*\)\s*\{ ) { 
        return 403 "Blocked by Shellshock protection (https://blog.x-way.org/Show-Shellshock-the-door).";
}
if ( $http_host ~ ^\s*\(\s*\)\s*\{ ) { 
        return 403 "Blocked by Shellshock protection (https://blog.x-way.org/Show-Shellshock-the-door).";
}
if ( $args ~ ^\s*\(\s*\)\s*\{ ) { 
        return 403 "Blocked by Shellshock protection (https://blog.x-way.org/Show-Shellshock-the-door).";
}
if ( $content_type ~ ^\s*\(\s*\)\s*\{ ) { 
        return 403 "Blocked by Shellshock protection (https://blog.x-way.org/Show-Shellshock-the-door).";
}
if ( $remote_user ~ ^\s*\(\s*\)\s*\{ ) { 
        return 403 "Blocked by Shellshock protection (https://blog.x-way.org/Show-Shellshock-the-door).";
}
if ( $request ~ ^\s*\(\s*\)\s*\{ ) { 
        return 403 "Blocked by Shellshock protection (https://blog.x-way.org/Show-Shellshock-the-door).";
}
if ( $request_body ~ ^\s*\(\s*\)\s*\{ ) { 
        return 403 "Blocked by Shellshock protection (https://blog.x-way.org/Show-Shellshock-the-door).";
}
Friday, 17. October 2014Week 41

Inspect CSR with OpenSSL

Before sending a CSR off to your CA, it is worth checking that all parameters are correct.
Especially you should make sure that the requested signature algorithm is SHA256 and not the deprecated SHA1.

This can be done with the following OpenSSL command:

openssl req -noout -text -in <your_CSR_file>
Monday, 13. October 2014Week 41
Sunday, 5. October 2014Week 39

How to enable SNMP on a Cisco SLM2008 Smart Switch

The Cisco SMB SLM2008 Smart Switch does normally not support SNMP and there is also no setting in the configuration interface which would enable SNMP.

But nevertheless the firmware does actually contain a SNMP daemon. Thus it is not surprising that a smart guy on to the Cisco support forum found out how to manipulate the proprietary config file such that it enables the SNMP daemon:

  1. Configure your switch with everything you need
  2. Download enable_snmp.pl
  3. Run # perl enable_snmp.pl <IP of your switch>
  4. Enjoy the SNMP export from the SLM2008 :-)

As this is a non-official hack, there are some limitations:

  • The embedded SNMP daemon only supports read accces and no SNMP Traps.
  • Changing a setting on the 'System' configuration tab disables the SNMP daemon again (thus the script will need to be run again).
Wednesday, 1. October 2014Week 39