Re: Linksys 'routers', SNMP issues

[The Cyberiad <cyberiad () nmrc org>]

I performed some testing against the BEFSR81, v2.37
firmware last fall and noted that the unit responded to SNMP
on the WAN interface. With the correct community string you could
enumerate values, determine the internal network addressing,
etc., etc and even add forwarding rules to access services on internal
hosts. When a change is made, the trick is to find the SNMP var which acts
as the switch to save the new config values and recycle with the new
vals. Some poking and some Linksys MIBS found on the Internet id'd/confirmed
the software switch as,

.1.3.6.1.4.1.3955.3.1.6.0

integer valued ... set to 1 to save new vals/recycle.

The v2.38.1 firmware release reportedly blocks the WAN SNMP
so Linksys must've found out about the external WAN SNMP access.

Cyberiad

On Mon, 7 Jan 2002, John Duksta wrote:

> Matthew:
>
> Are the Linksys devices accepting the SNMP packets on the
> external interface? Granted, this is a pretty bad problem
> in and of itself, but I would think not so bad if the Linksys
> device is only accepting SNMP on the internal interface.
>
> -john
>
> --
> John Duksta <jduksta () genuity com>
> Security Engineer  - Genuity
> ---------------------------------------------------------------------------
> "Everything should be made as simple as possible but not simpler."
> - A. Einstein
>
> On Sun, 6 Jan 2002, Matthew S. Hallacy wrote:
>
> > Howdy.
> >
> > LinkSys DSL 'routers' have some serious information leakage, and potention DDoS
> > usage. The following models have been confirmed as having this problem:
> > BEFN2PS4 (EtherFast Cable/DSL Router & Voice with 4-Port Switch)
> > BEFSR81 (EtherFast Cable/DSL Router with 8-Port Switch)
> >
> > Querying these devices with the default community of 'public' causes them to set
> > the address that queried as their snmptrap host, dumping traffic such as the
> > following to that address:
> >
> > Enterprise Specific Trap (1) Uptime: 2 days, 19:00:23.36, enterprises.3955.1.1.0 = "@out 192.168.1.200 ==> 
> > 24.254.60.13[110]."
> > Enterprise Specific Trap (1) Uptime: 2 days, 19:00:23.36, enterprises.3955.1.1.0 = "@out 192.168.1.200 ==> 
> > 216.120.8.23[5632]."
> > Enterprise Specific Trap (1) Uptime: 2 days, 19:00:23.36, enterprises.3955.1.1.0 = "@out 192.168.1.200 ==> 
> > 216.120.8.3[5632]."
> > Enterprise Specific Trap (1) Uptime: 2 days, 19:00:23.36, enterprises.3955.1.1.0 = "@out 192.168.1.200 ==> 
> > 216.120.8.4[5632]."
> > Enterprise Specific Trap (1) Uptime: 2 days, 19:00:23.36, enterprises.3955.1.1.0 = "@out 192.168.1.200 ==> 
> > 216.120.8.5[5632]."
> > Enterprise Specific Trap (1) Uptime: 2 days, 6:04:38.11, enterprises.3955.1.1.0 = "-->[U]Send OP:    ^ps_status_q 
> > 15049C0DFC9B03166D55EA30474D04FB 9218583272 a .."
> > Enterprise Specific Trap (1) Uptime: 2 days, 6:04:38.11, enterprises.3955.1.1.0 = "<--[U]Recv __:    
> > ^ps_status_r.15049C0DFC9B03166D55EA30474D04FB.\"\".0.."
> >
> > It looks like a combination of debugging information as well as traffic logging,
> > many customers never use the configuration page, let alone change the SNMP
> > communities. To make the matter worse, LinkSys refuses to distribute an MIB
> > for the device, which is not suprising considering the SNMP implementation
> > on the device is rather broken (it goes into a continious loop).
> >
> >
> > LinkSys is routing all messages regarding SNMP to /dev/null
> >
> >                     Have a nice day.
> >                     Matthew S. Hallacy