Re: news story and router passwords

[Mark Teicher <mark.teicher () NETWORKICE COM>]

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 passwords
>
>
> > One 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 is
> clamed
> > > >that some hacker after sniffing router password changed it and made
> > > >*something* after that they were not able to recover that password.
> Have
> > > >somebody 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 -
> no
> > >contract, 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 that
> customer
> > >will be buying next....
> > >
> > >Cheerio,
> > >Link.
> >