Vulnerability Development mailing list archives
Re: news story and router passwords
From: Talisker <Talisker () NETWORKINTRUSION CO UK>
Date: Sat, 14 Oct 2000 18:35:16 +0100
Mark Firstly I apologise if my reply seemed at all condescending, I thought you meant it when you said you didn't know much about SNMP, I thought Americans hadn't discovered sarcasm yet ;o) (tongue in cheek) It has been my experience that your average sys admin has a tendancy to ignore the possible vulnerabilities introduced by SNMP v2 (same applies to databases, routers and webservers) Therefore I would err on the side of caution when using it for security Andy http://www.networkintrusion.co.uk Talisker's comprehensive IDS & Scanner List ''' (0 0) ----oOO----(_)---------- | The geek shall | | Inherit the earth | -----------------oOO---- |__|__| || || ooO Ooo The opinions contained within this transmission are entirely my own, and do not necessarily reflect those of my employer. ----- Original Message ----- From: <mark.teicher () networkice com> To: "Talisker" <Talisker () networkintrusion co uk>; <VULN-DEV () SECURITYFOCUS COM> Sent: Saturday, October 14, 2000 5:50 PM Subject: Re: news story and router passwords
Andy, Tongue in cheek :) In order for a network resource, such as a component or application, to be manageable, the managed objects must be described in a portion of the Management Information Base (MIB). The MIB defines the management-related characteristics of managed objects. An agent is able to respond to the manager's request because both use the same data definitions in the management base and a consistent set of APIs for manipulating the managed object. The contents of the /usr/local/lib/dnpap/mibhome/mibs file should contain at least the following: # Basic RFCs "rfc/rfc1902", "rfc/rfc1903", "rfc/rfc1904", "rfc/rfc1906", "rfc/rfc1907", # Old v1 RFCs "rfc/rfc1513", # TOKEN-RING-RMON-MIB :: REQUIRED BY
RMON2MIB
"rfc/rfc1757", # RMON :: REQUIRED BY RMON2MIB "rfc/rfc2011", # IP-MIB "rfc/rfc2012", # TCP-MIB "rfc/rfc2013", # UDP-MIB "rfc/rfc2021", # RMON2-MIB :: REQUIRES RMON-MIB "rfc/rfc2096", # IP-FORWARD-MIB # "rfc/rfc2108", # SNMP-REPEATER-MIB (HUB MIB WG) "rfc/rfc2206", # RSVP-MIB "rfc/rfc2213", # Integrated Services MIB "rfc/rfc2214", # Integrated Services Guaranteed MIB "rfc/rfc2233", # Interface MIB # "rfc/rfc2239", # MUA Mib (HUB MIB WG) "rfc/rfc2261", # SNMPv3 Framework MIB "rfc/rfc2262", # SNMPv3 Message Processing and
Dispatching
"rfc/rfc2265", # SNMPv3 View Based ACM MIB root.def rfc1213.def rfc1271.def btng.def mib83.def cisco.def Since SNMP communication is UDP-based, there is no guarantee that if the connection has is succeeded or not since it is a UDP socket. After the connection, a check for the system up time should be made. If a network access device SNMP sysUp time of a router is 0 or minimal, it means the communication wasis brocken. Otherwise it should be non-zero. # open/close/set a SNMP connection ######################################### sub openSNMP { my($initHost, $comm) = @_; postMessages("openSNMP($initHost, $comm)", $LOGDBG); # die use STDERR unless (&snmp_open($COMMPORT)) { postMessages("error: snmp_open($COMMPORT)",$LOGINF); return "SNMP open error"; } &snmp_host($COMMPORT,$initHost); &snmp_medium($COMMPORT,"udp"); unless (&snmp_connect($COMMPORT)) { postMessages("error: snmp_connect($COMMPORT)", $LOGINF); return "SNMP connect error"; } &snmp_community($COMMPORT,$comm); # use sysUpTime to test if the snmp connection is okay unless (&snmp_get($COMMPORT,"sysUpTime")) { postMessages("$initHost: snmp connection failed", $LOGINF); return "SNMP bad :("; } postMessages("openSNMP okay", $LOGDBG); return 0; } sub closeSNMP { postMessages("closeSNMP($COMMPORT)", $LOGDBG); &snmp_disconnect($COMMPORT); &snmp_close($COMMPORT); ################################### # open/close a openCommunications # ################################### sub openSockets { $ret = 0; if ($LogFileName) { close(STDOUT); close(STDERR); $fo = $LogFileName; $fe = $LogFileName . ".err"; renameFile($fo); renameFile($fe); if (!open(STDOUT, ">>" . $fo) || !open(STDERR, ">>" . $fe)) { postMessages("can't open $fo or $fe", $LOGERR); $ret = -1; } else { postMessages("openSockets: STDOUT->$fo, STDERR->$fe", $LOGDBG); } } return $ret; } sub closeSockets { postMessages("closeSockets(STDOUT, STDERR)", $LOGDBG); close(STDOUT); close(STDERR); } ######################## # snmpSet routine # ######################## sub snmpSet { my($comm, $v) = @_; &snmp_set($comm, $v); $results = &get_snmp_err(); return $results; } The SNMP_set command loads the MIB definitions contained in file. The built-in parser reads the file. Parsing errors are written to stderr. There are five passes involved when processing a Set request: 1. Each variable in the variable binding list of the received PDU is checked to guarantee that each object is accessible and/or creatable, and writable. 2. The test method for each object is called to verify the object's instance, size/range, and value. 3. The variable binding list is parsed to construct a list of simultaneous Set operations for groups of objects. 4. This pass verifies that all required objects within a group have specified or default values. 5. It also insures that all required values meet the relational constraints specified in the MIB. 6. Sets are then performed on all of the individual objects that can be reversed in case something goes wrong. There is are limitations on what the values for 'pathName' would be. This is the only required command line argument by the User. The 'pathName' is a file name with directory path. For instance, if the file contains passwords, the read and write actions are will act as the file to update the passwords for the routers. Likewise, if the file contains ACLs, the router will update itself for security enforcement. Both read and write functions can be toggled separately. A system administrato can do read only, write only, or combined actions. As I stated before, I don't know much about SNMP.. :) At 09:34 PM 10/13/00 +0100, Talisker wrote:Mark SNMP < v3 IMHO should not be used for security tools, too many networks don't move away from the default community name and once again getting changed community names is easy. Brief history v1 had trivial security v2 had better security, however it didn't catch on v2c was as per v2 except with v1 security !!!!! v3 has better security again (but will it catch on - if not wait for v3c) What's the word on the street is it catching on ???? I can recommend the 4 day LTI SNMP course it's pretty good though a
little
padded to fill the time Andy http://www.networkintrusion.co.uk Talisker's comprehensive IDS & Scanner List ''' (0 0) ----oOO----(_)---------- | The geek shall | | Inherit the earth | -----------------oOO---- |__|__| || || ooO Ooo The opinions contained within this transmission are entirely my own, and
do
not necessarily reflect those of my employer. ----- Original Message ----- From: "Mark Teicher" <mark.teicher () NETWORKICE COM> To: <VULN-DEV () SECURITYFOCUS COM> Sent: Friday, October 13, 2000 4:17 AM Subject: Re: news story and router passwordsOne can also utilize SNMP to grab pertinent information. "ipAdEntAddr[\$NODEIP]", "sysName", "ipAdEntNetMask[\$NODEIP]", "ipForwarding", "sysObjectID", "sysUpTime", "sysLocation", "sysDescr", and re-configure routers without the password if SNMP is not setup correctly. But I don't know anything about SNMP.. :) At 01:30 AM 10/13/00 +0800, Lincoln Yeoh wrote:At 04:35 PM 10/12/00 +0200, Vitaly Osipov wrote:Hello all, I think everybody knows that media reporting on hackers and their
tools
is,ehm, very improper :) I've read one article recently http://www.denverpost.com/business/biz1012d.htm ) in which it isclamedthat some hacker after sniffing router password changed it and made *something* after that they were not able to recover that password.Havesomebody heard of such problems (it looks like they were using
cisco,
One possible scenario: The hacker could have reflashed the router or its modules with a
custom
firmware, or just zapped the firmware. This can make password
recovery
impossible. Custom firmware would be much harder but more scary -
because
if the hacker does it right, you won't even notice till really bad
things
happen. Getting and changing the router firmware usually isn't that difficult, understanding it enough to make interesting changes
without
totally breaking stuff is a bit harder. The way to fix this would be
to
reflash the affected components with a decent release. If it's really a Cisco and they have a contract they could just
contact
Cisco TAC to fix things for them, instead of being held to ransom by
the
hacker. When a customer sent us a faulty obsolete Cisco access
server -
nocontract, no nothing, and they bought it from someone else(!), Cisco actually sent a replacement for _free_[1] within a few days! Customer happy, we happy, TAC people happy, and no bets on what router thatcustomerwill be buying next.... Cheerio, Link.
Current thread:
- Re: Netscape crashes, sec. bug?, (continued)
- Re: Netscape crashes, sec. bug? Erik Tayler (Oct 10)
- Cisco 678 exploit George (Oct 11)
- news story and router passwords Vitaly Osipov (Oct 12)
- Re: news story and router passwords Talisker (Oct 12)
- Re: news story and router passwords Mathias Wegner (Oct 13)
- Re: news story and router passwords Ralph Moonen (Oct 12)
- Re: news story and router passwords Lincoln Yeoh (Oct 12)
- Re: news story and router passwords Mark Teicher (Oct 13)
- Re: news story and router passwords Talisker (Oct 13)
- Re: news story and router passwords Mark Teicher (Oct 14)
- Re: news story and router passwords Talisker (Oct 14)
- Re: news story and router passwords Mark Teicher (Oct 14)
- Cisco 678 exploit George (Oct 11)
- Re: Netscape crashes, sec. bug? Erik Tayler (Oct 10)
- Re: news story and router passwords Jim Duncan (Oct 13)
- Re: Cisco 678 exploit Damir Rajnovic (Oct 12)
- Re: Cisco 678 exploit Joe (Oct 12)
- Re: Cisco 678 exploit Damir Rajnovic (Oct 12)