myNetWatchman   KnowledgeBase

Pooling knowledge to
secure the internet.

Linksys SNMP vulnerability used for DDoS

Created: 15-Mar-2002
Author: Lawrence Baldwin, myNetWatchman.com

The following documents how certain models of the popular Linksys cable modem/DSL routers can be used to launch a distributed denial-of-service (DDoS) attack. This possibility was fore-shadowed by Matthew S. Hallacy more than three months ago he first identified this SNMP vulnerability Bugtrac

13-Mar-2002 through 14-Mar-2002: Eight independent myNetWatchman sensors picked up udp/161 (SNMP - Simple Network Management Protocol) probes from a source IP address of: 63.105.X.X

14-Mar-2002 15:00 UTC - I contacted the owner of the source IP (John Burgess), he indicated he had outbound udp/161 filters in place so it was impossible for his host to be generating this traffic. Futhermore, he indicated that he was receiving high volumes udp/162 (SNMP Trap) packets sourced from hosts in the 12.x.x.x range. A sample packet is shown here:

Frame 32 (163 on wire, 163 captured)
    Arrival Time: Mar 15, 2002 13:09:48.696761000
    Time delta from previous packet: 0.472954000 seconds
    Time relative to first packet: 10.163996000 seconds
    Frame Number: 32
    Packet Length: 163 bytes
    Capture Length: 163 bytes
Ethernet II
    Destination: 00:50:54:ff:82:97 (CISCO_ff:82:97)
    Source: 00:07:eb:7c:8b:20 (Cisco_7c:8b:20)
    Type: IP (0x0800)
Internet Protocol, Src Addr: x.x.snfccafj.dsl.att.net (12.98.x.x), Dst Addr: x.x.com (63.105.x.x)
    Version: 4
    Header length: 20 bytes
    Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)
        0000 00.. = Differentiated Services Codepoint: Default (0x00)
        .... ..0. = ECN-Capable Transport (ECT): 0
        .... ...0 = ECN-CE: 0
    Total Length: 149
    Identification: 0x0000
    Flags: 0x00
        .0.. = Don't fragment: Not set
        ..0. = More fragments: Not set
    Fragment offset: 0
    Time to live: 49
    Protocol: UDP (0x11)
    Header checksum: 0x2935 (correct)
    Source: x.x.snfccafj.dsl.att.net (12.98.x.x)
    Destination:x.x.com (63.105.x.x)
User Datagram Protocol, Src Port: 2264 (2264), Dst Port: snmptrap (162)
    Source port: 2264 (2264)
    Destination port: snmptrap (162)
    Length: 129
    Checksum: 0xad0f (correct)
Simple Network Management Protocol
    Version: 1
    Community: public
    PDU type: TRAP-V1
    Enterprise: 1.3.6.1.4.1.3955.1.1
    Agent address: 12.98.x.x
    Trap type: ENTERPRISE SPECIFIC
    Specific trap type: 1 (0x1)
    Timestamp: 5452519
    Object identifier 1: 1.3.6.1.4.1.3955.1.1.0
    Value: OCTET STRING: @out 192.168.1.104 1287 www.mynetwatchman.com 80

Note: The payload conforms to the standard Linksys access log format, indicating that the source is a Linksys router of some kind:

@out 192.168.1.104 1287 www.mynetwatchman.com 80

I picked the above packet amount hundreds of others, as it ironically showed that the owner of this Linksys had been accessing my own web site (www.mynetwatchman.com)! After looking up the source IP of this packet in my registration system I was able to identify that this person was indeed a participant in my distributed IDS network--I have since notified him that his Linksys appears to have been compromised.

Here is a graphical representation of this attack.

Normal state: Assume of random distribution of vulnerable Linksys routers and myNetWatchman sensors in the 12.x.x.x netblock. By default, Linksys routers configured to send SNMP Traps to local network:

Attack: Attacker sends SNMP exploit to all hosts in 12.x.x.x netblock. Source IP is spoofed so that it is the victim's IP. Upon receiving this packet, vulnerable Linksys routers are reconfigured to now send all logging data to victim's IP via SNMP Traps:

User's Internet connection now clogged with SNMP Trap data causing a denial-of-service.

I contacted Linksys and their representative indicated they were not aware of this exploit, so unfortunately I'm not sure if there is a patch to resolve this. They indicated they would research it and get back to me on Monday (17-Mar-2002). Ken Claussen made a good suggestion that a work-around might be to have Linksys users change their community string to something other than 'public'. Not sure if this will even block the exploit.

Credits:

Many thanks to the myNetWatchman agents whose data made detection of this activity possible.

John Burgess who provided the packet captures that were essential in verifying this activity as sourced from Linksys equipment

Matthew S. Hallacy for orginally discovering and documenting this vulnerability: Bugtrac

secKB Index

myNetWatchman Home