January 9, 2015 at 14:40Upgrade SNMP on Huawei and H3C devices
You can do three things endlessly: watch the fire burn, watch the water flow, and talk about the security of unsafe protocols. We already talked about scanning corporate networks , network devices, and Cisco IOS . This time we offer you a story about the SNMP protocol, or rather, about working on this protocol with HP / H3C and Huawei network equipment. These devices allow you to access critical information with minimal rights. Exploiting the vulnerability allows an attacker to penetrate the corporate networks of commercial companies and the technological networks of telecom operators using these widespread devices.
In 2003, Huawei Technologies and 3Com founded the joint venture H3C. In 2007, 3Com bought its share from Huawei, and in 2010 it became part of HP, which automatically received H3C. Thus, the network equipment of several vendors turned out to be vulnerable - 3Com, H3C and HP , Huawei . These devices are used in thousands of companies, from small enterprises to the largest providers.
What critical information do they give out? We are talking about user data stored in the h3c-user.mib and hh3c-user.mib databases. These mibs define objects for the "Manage configuration and Monitor running state for userlog feature". In the new version of the OS, access to them should have been allowed only with read-write community string. However, this was not done, and you can get information from the community string with read-only privileges.
These databases contain the following information:
And to find out all this, you just need to guess the read-only community string, which is very often set as “public” by default.
OID: 1.3.4.1.4.1.2011.10 and OID: 1.3.6.1.4.1.25506 are responsible for this information on devices.
The OID is responsible directly for the information about the configured local users: 1.3.6.1.4.1.2011.10.2.12.1.1.1 and 1.3.6.1.4.1.25506.2.12.1.1.1.
In response to a request with these OIDs, we get (H) H3cUserInfoEntry, which contains the following values:
• (h) h3cUserName - The name of local user, it must be unique
• (h) h3cUserPassword - The password of local user, default is null
• (h) h3cAuthMode - The encrypting type of password:
• (h) h3cUserLevel The privilege of local user the value range is from 0 to 3, and 0 is minimum, 3 is maximum. default is 0.
In the example below, snmpwalk is invoked with the –Cc switch, since it works with dynamic indexes. If you execute the request without this key, the error "Error: OID not increasing" may occur.
A curious detail: in the settings it is indicated that the password should be encrypted. And when viewing the configuration, the way it is:
But at the same time, through SNMP, the password is still specified in the clear (it probably depends on the specific device):
So, we were able to get the credentials of local users, including those with the maximum privilege level (user “admin” with privilege level “3”). Now it remains only to try to connect to the device via SSH or Telnet:
We were lucky and access to the server via SSH was not denied. But if you can’t log in via SSH or Telnet ...
... you can always try logging in via the web (the picture is clickable): Now let's look at another example. In this case, we received the passwords in encrypted form. Huawei can use AES256 or DES algorithms to encrypt passwords. Moreover, in the scheme with the DES algorithm, the same encryption key is used on all vulnerable devices
and no salt is used for encryption. As a result, the password can be easily decrypted, as written Roberto Paleari and Ivan Speziale from companies Emaze Networks in 2012.
So, you can open your favorite console and try to connect with the received data via SSH or Telnet:
Or, as we already said, if access to these protocols is limited, you can always try to go through another protocol:
It should be noted that there is also encryption in the scheme with AES256 problems: in 2014, the same guys from Emaze Networks published another note in which they talk about how bad things are.
Shodan search results demonstrate how popular this vulnerability is:
Since Huawei is a Chinese company, it is not surprising that most of the available devices are in China. But in Russia, too, things are not going smoothly: I
must say that Kurt Grutzmacher was the first to write about this vulnerability back in 2012. In the same year, he spoke at the Bay Threat conference, where he described in detail the problem and what it poses. Equipment manufacturers have released patches for their devices - but, as is usually the case with network equipment, a large number of devices remain vulnerable to this day.
Exploitation of this vulnerability allows an attacker to penetrate the corporate network of a commercial company, the technological network of a telecom operator and any other organization. Gaining control of the border network equipment provides an attacker with the ability to control traffic passing through the device in any way and opens the way for an attack on intranet automated systems.
All this once again confirms the commonplace truth: insecure protocols carry a great danger. In order to get to the corporate network, you do not need to use tricky schemes with complex exploits: just one SNMP protocol with a standard community string with minimal read-only permissions and another protocol for accessing devices - SSH, Telnet or web. Moreover, as practice has shown, if access via Telnet or SSH on most devices is limited, then through HTTP - enter whoever wants to.
And one more “nice bonus”. With the registration service configured, an attempt to enter the device via SSH, Telnet or web can be seen, for example, on the Syslog server. But there will be no such messages for SNMP requests, and you may not even know that someone received credentials or did something else (for example, changed the device configuration).
Simple enough. First, you need to turn off the SNMP service. If this protocol is still necessary, then use SNMPv3. If this is not possible, avoid using the standard community string - public and private. You can exclude objects from the (H) H3cUserInfoEntry table from access using the excluded command, and also deny access to the device with read-write permissions. And of course, you need to restrict access to the device using allowed address lists or access lists. Posted by Evgeny Stroyev, Positive Technologies Research Center
In 2003, Huawei Technologies and 3Com founded the joint venture H3C. In 2007, 3Com bought its share from Huawei, and in 2010 it became part of HP, which automatically received H3C. Thus, the network equipment of several vendors turned out to be vulnerable - 3Com, H3C and HP , Huawei . These devices are used in thousands of companies, from small enterprises to the largest providers.
What critical information do they give out? We are talking about user data stored in the h3c-user.mib and hh3c-user.mib databases. These mibs define objects for the "Manage configuration and Monitor running state for userlog feature". In the new version of the OS, access to them should have been allowed only with read-write community string. However, this was not done, and you can get information from the community string with read-only privileges.
These databases contain the following information:
- local user names
- their passwords
- type of password encryption,
- user privilege level.
And to find out all this, you just need to guess the read-only community string, which is very often set as “public” by default.
OID: 1.3.4.1.4.1.2011.10 and OID: 1.3.6.1.4.1.25506 are responsible for this information on devices.
The OID is responsible directly for the information about the configured local users: 1.3.6.1.4.1.2011.10.2.12.1.1.1 and 1.3.6.1.4.1.25506.2.12.1.1.1.
In response to a request with these OIDs, we get (H) H3cUserInfoEntry, which contains the following values:
• (h) h3cUserName - The name of local user, it must be unique
• (h) h3cUserPassword - The password of local user, default is null
• (h) h3cAuthMode - The encrypting type of password:
- 0: password simple, means password is clean text.
- 7: password cipher, means password is encrypted text.
- default is 0
• (h) h3cUserLevel The privilege of local user the value range is from 0 to 3, and 0 is minimum, 3 is maximum. default is 0.
In the example below, snmpwalk is invoked with the –Cc switch, since it works with dynamic indexes. If you execute the request without this key, the error "Error: OID not increasing" may occur.
A curious detail: in the settings it is indicated that the password should be encrypted. And when viewing the configuration, the way it is:
But at the same time, through SNMP, the password is still specified in the clear (it probably depends on the specific device):
So, we were able to get the credentials of local users, including those with the maximum privilege level (user “admin” with privilege level “3”). Now it remains only to try to connect to the device via SSH or Telnet:
We were lucky and access to the server via SSH was not denied. But if you can’t log in via SSH or Telnet ...
... you can always try logging in via the web (the picture is clickable): Now let's look at another example. In this case, we received the passwords in encrypted form. Huawei can use AES256 or DES algorithms to encrypt passwords. Moreover, in the scheme with the DES algorithm, the same encryption key is used on all vulnerable devices
and no salt is used for encryption. As a result, the password can be easily decrypted, as written Roberto Paleari and Ivan Speziale from companies Emaze Networks in 2012.
So, you can open your favorite console and try to connect with the received data via SSH or Telnet:
Or, as we already said, if access to these protocols is limited, you can always try to go through another protocol:
It should be noted that there is also encryption in the scheme with AES256 problems: in 2014, the same guys from Emaze Networks published another note in which they talk about how bad things are.
Shodan search results demonstrate how popular this vulnerability is:
Since Huawei is a Chinese company, it is not surprising that most of the available devices are in China. But in Russia, too, things are not going smoothly: I
must say that Kurt Grutzmacher was the first to write about this vulnerability back in 2012. In the same year, he spoke at the Bay Threat conference, where he described in detail the problem and what it poses. Equipment manufacturers have released patches for their devices - but, as is usually the case with network equipment, a large number of devices remain vulnerable to this day.
Exploitation of this vulnerability allows an attacker to penetrate the corporate network of a commercial company, the technological network of a telecom operator and any other organization. Gaining control of the border network equipment provides an attacker with the ability to control traffic passing through the device in any way and opens the way for an attack on intranet automated systems.
All this once again confirms the commonplace truth: insecure protocols carry a great danger. In order to get to the corporate network, you do not need to use tricky schemes with complex exploits: just one SNMP protocol with a standard community string with minimal read-only permissions and another protocol for accessing devices - SSH, Telnet or web. Moreover, as practice has shown, if access via Telnet or SSH on most devices is limited, then through HTTP - enter whoever wants to.
And one more “nice bonus”. With the registration service configured, an attempt to enter the device via SSH, Telnet or web can be seen, for example, on the Syslog server. But there will be no such messages for SNMP requests, and you may not even know that someone received credentials or did something else (for example, changed the device configuration).
How to protect yourself
Simple enough. First, you need to turn off the SNMP service. If this protocol is still necessary, then use SNMPv3. If this is not possible, avoid using the standard community string - public and private. You can exclude objects from the (H) H3cUserInfoEntry table from access using the excluded command, and also deny access to the device with read-write permissions. And of course, you need to restrict access to the device using allowed address lists or access lists. Posted by Evgeny Stroyev, Positive Technologies Research Center
