(this reply was originally posted on vulndev) You can do that with any docsis modem.. All of them use the snmp community 'public' for read/write access.. There really isn't any physically identifiying information in a snmp walk of a modem (or by using docsdiag.jar to do it)... Signal levels, interface statistics, etc.. You can tell if they're using usb or ether and you can probably pull the client ip's (CPE's) from the walk.. The docsis_light_avalos is odd, but I think that it may be the config file the modem is using or another configuration variable (possibly specific to the rca?).. It would be pretty crazy if your mso was snmp writing physically identifying information in every modem! At any rate that's a problem with your isp, not rca. Any snmp values that are written are reset when you unplug the modem for an extended period (15min+) or reset it using a software tool(motorola) or the physical reset button(toshiba).. The 10.x.x.x side of the modem is kind of wide open, but it's also fairly safe because unless you get someone to tell you their modem ip (or you get it directly from their modem (physically) you don't have any way to find it out other than guessing (which btw only works if your both on the same modem network).. It would be fairly simple to develop a tool to find active 10.x.x.x ranges and then snmp poll every ip in those ranges and compile a list of internet ip's behind modems.. That might not tell you much as far as physical location but you could use the information to determine what a persons modem ip was if you had their real ip and they were on your modem network.. Another thing with the snmp side is the recent protos snmp test suite.. _A LOT_ of the modems lockup when you use this tool on the 192.x.x.x or the 10.x.x.x interface.. It probably wouldn't be hard to make a mass denial of service attack that would hit all/selected ranges of 10.x.x.x addresses with the snmp exploit.. This would effectively lock up any vulnerable modem and would require the user to powercycle to restore service.. The main thing to keep in mind is that the 10.x.x.x addy's aren't public and people outside of your modem network can't communicate with them.. If anyone turns the above concepts into an exploit I'd appreciate a copy ;) Rob Koliha HSDT Charter Communications Gabriel A. Maggiotti wrote: > >------------------------------------------------------------------------ > >------------------------------------------------------------------------------ >Web: http://qb0x.net Author: Gabriel A. Maggiotti >Date: March 26, 2002 E-mail: gmaggiot@ciudad.com.ar >------------------------------------------------------------------------------ > > > > >General Info >------------ >Problem Type : deny of service, misconfiguration and leak of information >Vendor : www.rca.com >Product : RCA cablemodems >Model : DCM225 (perhaps others) >Scope : Remote >Risk : High > > >Summary: >------- > >The RCA Digital Cable Modem serves as a two-way high-speed bridge between your >personal computer and >a cable Internet Service Provider (ISP). i It converts >information that originates from the Internet or your computer into electronic >messages that can be transported over the same wires your cable company uses to > transport video signals. > > >Problem: >------- > >1- Deny of Service: > > The RCA cable modem has two devices, the one for local connection is 192 >.168.100.1 . This device is used for information request about the status of >the cable. The other device is 10.x.x.x and gives the same information. > If you connect to the second device (10.x.x.x) on port 80, RCA cable >modem reset the user connection with inet. I proved it with my own wan ip 10.1.1 >.x and with other cablemodem users IP's in the same wan. All of them reset > when I remotly connect to port 80 of the cablemodems. > > > >2- Leak of Information: > I can connect to the wan IP 10.x.x.x of any cablemodem user in my node,< >br>and take a look at the users cablemodem status information such as: > > USB: Inactive > Ethernet: 100 > BaseT > MAC Address: 00 10 95 0a 05 62 > User: Active > Signal Acquired at 573 MHz > SNR: 36.0 dB > Received Signal Strength: -4.0 dBmV > Micro-Reflections: 20 dBc > Connection: Acquired > Frequency: 37 MHz > Power Level: 44.0 dBmV > Channel ID: 4 > Number of user conected: 1 > > > >I can dump user cablemodem MIB's too. > > I can search in MIB table looking for my node server. I know that the >node IP start with 10.x.x.x and I started to search in the MIB Ops, a found >it! > >69.1.4.2.0 = IpAddress: 10.20.250.1 >69.1.4.3.0 = IpAddress: 10.20.250.1 >69.1.4.4.0 = IpAddress: 10.20.250.1 >69.1.4.5.0 = "docsis_light_avalos" > > And then I recognize the word "avalos" becouse is the name of the street >w >here the node fisicaly is. > > >3- Misconfiguration cause you can write my own MIB table. Take a look: > ><quote> >[gabi@pluto gabi]$ snmpwalk 192.168.100.1 public > >system.sysDescr.0 = RCA DCM225 Cable Modem serial no. 65731049496572, >HW_Version 025 (03.1), SW_Version ST05.14.00, Bootloader_Ver 11.1, OS: PSOS >2.5.0 >system.sysObjectID.0 = OID: enterprises.2863.225.25.5.20.0 >system.sysUpTime.0 = Timeticks: (141857) 0:23:38.57 >system.sysContact.0 = unassigned sysContact >system.sysName.0 = >system.sysLocation.0 = >system.sysServices.0 = 79 > >[gabi@pluto gabi]$ snmpset 192.168.100.1 public system.sysName.0 s lame >system.sysName.0 = lame > >[gabi@pluto gabi]$ snmpset 192.168.100.1 public system.sysLocation.0 s >lame_cyty >system.sysName.0 = lame_city > > >[gabi@pluto gabi]$ snmpwalk 192.168.100.1 public > >system.sysDescr.0 = RCA DCM225 Cable Modem serial no. 65731049496572, >HW_Version 025 (03.1), SW_Versio >n ST05.14.00, Bootloader_Ver 11.1, OS: PSOS >2.5.0 >system.sysObjectID.0 = OID: enterprises.2863.225.25.5.20.0 >system.sysUpTime.0 = Timeticks: (161396) 0:26:53.96 >system.sysContact.0 = unassigned sysContact >system.sysName.0 = lame >system.sysLocation.0 = lame_city >system.sysServices.0 = 79 ></quote> > > >------------------------------------------------------------------------------ >research-list@qb0x.net is dedicated to interactively researching vulnerab- >ilities, report potential or undeveloped holes in any kind of computer system. >To subscribe to research-list@qb0x.ne t send a blank email to >research-list-subscribe@qb0x.net. More help available sending an email >to research-list-help@qb0x.net. >Note: the list doesn't allow html, it will be stripped from messages. >------------------------------------------------------------------------------ >