Upgrade 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 have 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 network equipment HP / H3C and Huawei. These devices allow you to access critical information with minimal rights. Exploiting a vulnerability allows an attacker to penetrate the corporate networks of commercial companies and the technological networks of telecom operators using these widely used devices.
In 2003, Huawei Technologies and 3Com founded the H3C joint venture. 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 mib define objects for “Manage configuration and Monitor running state for userlog feature”. In the new version of the OS, access to them should be allowed only with the read-write community string. However, this was not done, and you can get information from the community string with read-only rights.
These databases contain the following information:
And in order to find out all this, you only need to guess the read-only community string, which is often configured by default as “public”.
OID is responsible for this information on devices: 1.3.4.1.4.1.2011.10 and OID: 1.3.6.1.4.1.25506.
Directly for the very information about configured local users OID is responsible: 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 the query with these OIDs, we get (H) H3cUserInfoEntry, which contains the following values:
• (h) h3cUserName - The user must be unique
• (h) h3cUserPassword - The password of the local user, default is null
• (h) h3cAuthMode - The encrypting type of password:
• (h) h3cUserLevel The value of the user. default is 0.
In the example below, snmpwalk is called with the –Cc key, since it comes with dynamic indexes. If you execute the request without this key, the error “Error: OID not increasing” may occur.
Curious detail: the settings indicate that the password should be encrypted. And when viewing the configuration, the way it is:
But at the same time, via SNMP, the password is still specified in the open form (it probably depends on the specific device):
So, we were able to obtain the credentials of local users, including those with the maximum level of privileges (the user is “admin” with the level of privileges “3”). Now it only remains 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 suddenly you are not able to log in via SSH or Telnet ...
... you can always try to go through the web (the image is clickable):
Now look at another example.
In this case, we received the passwords in encrypted form. Huawei can use AES256 or DES for password encryption. In this case, the scheme with the DES algorithm uses the same encryption key on all vulnerable devices and does not use salt for encryption. As a result, the password can be easily decrypted, as Roberto Paleari and Ivan Speziale of Emaze Networks wrote in 2012.
So, you can open your favorite console and try to connect with the received data via SSH or Telnet:
Or, as we have already said, if access via these protocols is limited, you can always try to log in through another protocol:
It should be noted that the encryption scheme with AES256 also has problems: in 2014, the same guys from Emaze Networks published one more note in which they talk about how bad things are.
The search results in Shodan demonstrate how popular this vulnerability is:
Since Huawei is a Chinese company, it is not surprising that most of the available devices are located in China. But in Russia, too, not everything goes 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 threatens with. Equipment manufacturers have released patches for their devices - but, as is usually the case with network equipment, a large number of devices remain vulnerable.
Operation of this vulnerability allows an attacker to penetrate into the corporate network of a commercial company, into the technological network of a telecom operator and any other organization. Obtaining control over 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 the development of an attack on intranet automated systems.
All this once again confirms the commonplace truth: unsafe protocols carry great danger. In order to get into the corporate network, you do not need to use clever schemes with complex exploits: just one SNMP protocol with a standard community string with minimal read-only rights and another protocol for accessing devices — SSH, Telnet, or the web. Moreover, as practice has shown, if the access via Telnet or SSH on most devices is limited, then via HTTP, enter whoever wants.
And one more “nice bonus”. If the registration service is configured, an attempt to access the device via SSH, Telnet or web can be seen, for example, on a Syslog server. But there will be no similar messages for requests via SNMP, 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 needed, 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, as well as deny access to the device with read-write rights.
And of course, it is necessary to restrict access to the device using the lists of allowed addresses or access lists.
Author: Evgeny Stroyev, Positive Technologies Research Center
In 2003, Huawei Technologies and 3Com founded the H3C joint venture. 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 mib define objects for “Manage configuration and Monitor running state for userlog feature”. In the new version of the OS, access to them should be allowed only with the read-write community string. However, this was not done, and you can get information from the community string with read-only rights.
These databases contain the following information:
- local user names,
- their passwords
- Password encryption type
- level of privileges possessed by the user.
And in order to find out all this, you only need to guess the read-only community string, which is often configured by default as “public”.
OID is responsible for this information on devices: 1.3.4.1.4.1.2011.10 and OID: 1.3.6.1.4.1.25506.
Directly for the very information about configured local users OID is responsible: 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 the query with these OIDs, we get (H) H3cUserInfoEntry, which contains the following values:
• (h) h3cUserName - The user must be unique
• (h) h3cUserPassword - The password of the 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 value of the user. default is 0.
In the example below, snmpwalk is called with the –Cc key, since it comes with dynamic indexes. If you execute the request without this key, the error “Error: OID not increasing” may occur.
Curious detail: the settings indicate that the password should be encrypted. And when viewing the configuration, the way it is:
But at the same time, via SNMP, the password is still specified in the open form (it probably depends on the specific device):
So, we were able to obtain the credentials of local users, including those with the maximum level of privileges (the user is “admin” with the level of privileges “3”). Now it only remains 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 suddenly you are not able to log in via SSH or Telnet ...
... you can always try to go through the web (the image is clickable):
Now look at another example.
In this case, we received the passwords in encrypted form. Huawei can use AES256 or DES for password encryption. In this case, the scheme with the DES algorithm uses the same encryption key on all vulnerable devices and does not use salt for encryption. As a result, the password can be easily decrypted, as Roberto Paleari and Ivan Speziale of Emaze Networks wrote in 2012.
So, you can open your favorite console and try to connect with the received data via SSH or Telnet:
Or, as we have already said, if access via these protocols is limited, you can always try to log in through another protocol:
It should be noted that the encryption scheme with AES256 also has problems: in 2014, the same guys from Emaze Networks published one more note in which they talk about how bad things are.
The search results in Shodan demonstrate how popular this vulnerability is:
Since Huawei is a Chinese company, it is not surprising that most of the available devices are located in China. But in Russia, too, not everything goes 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 threatens with. Equipment manufacturers have released patches for their devices - but, as is usually the case with network equipment, a large number of devices remain vulnerable.
Operation of this vulnerability allows an attacker to penetrate into the corporate network of a commercial company, into the technological network of a telecom operator and any other organization. Obtaining control over 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 the development of an attack on intranet automated systems.
All this once again confirms the commonplace truth: unsafe protocols carry great danger. In order to get into the corporate network, you do not need to use clever schemes with complex exploits: just one SNMP protocol with a standard community string with minimal read-only rights and another protocol for accessing devices — SSH, Telnet, or the web. Moreover, as practice has shown, if the access via Telnet or SSH on most devices is limited, then via HTTP, enter whoever wants.
And one more “nice bonus”. If the registration service is configured, an attempt to access the device via SSH, Telnet or web can be seen, for example, on a Syslog server. But there will be no similar messages for requests via SNMP, and you may not even know that someone received credentials or did something else (for example, changed the device configuration).
How to defend
Simple enough. First, you need to turn off the SNMP service.
If this protocol is still needed, 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, as well as deny access to the device with read-write rights.
And of course, it is necessary to restrict access to the device using the lists of allowed addresses or access lists.
Author: Evgeny Stroyev, Positive Technologies Research Center
Source: https://habr.com/ru/post/247355/
All Articles