The SNMP protocol.

Initially, the SNMP protocol was developed to test the functioning of network routers. Subsequently, the scope of the protocol covered other network devices such as hubs, gateways, terminal servers, Windows Server machines, etc. In addition, the protocol allows for the possibility of making changes to the operation of these devices.
The main participants in the protocol operation process are agents and management systems. If we consider these two concepts in the language of "client-server", then the role of the server is performed by agents, that is, the very devices for which the protocol we are considering was developed. Accordingly, the role of clients is assigned to management systems - network applications necessary to collect information about the functioning of agents. In addition to these two subjects, two more can be distinguished in the protocol model: the control information and the data exchange protocol itself.
The protocol allows devices to be interrogated over the network, receiving information about the status of their network interfaces, load, and other data.
The SNMP protocol also has another very important feature, namely the ability to modify data on agents.
Now let's talk about what kind of information the management system can get from the depths of SNMP. All information about the objects of the agent system is contained in the so-called MIB (management information base), a database of management information, in other words, the MIB is a collection of objects available for write-read operations for each specific client, depending on the structure and purpose of the client itself. After all, it makes no sense to ask the terminal server for the number of dropped packets, since this data has nothing to do with its operation, as well as information about the administrator for the router. Therefore, the management system must know exactly what to request and from whom. There are currently four MIB databases:
1) Internet MIB is a database of objects for providing error diagnostics and configurations. It includes more than 200 objects (including MIB I objects);
2) LAN manager MIB - database of more than 100 objects – passwords, sessions, users, shared resources;
3) WINS MIB - database of objects necessary for the operation of the WINS server (WINSMIB.DLL );
4) DHCP MIB - database of objects necessary for the functioning of the DHCP server (DHCPMIB.DLL ), which serves to dynamically allocate IP addresses in the network.
All MIB names have a hierarchical structure, usually represented as a tree. There are ten root aliases:
1) System - this MIB II group contains seven objects, each of which is used to store information about the system (OS version, operating time, etc.);
2) Interfaces - contains 23 objects necessary for maintaining statistics of agents' network interfaces (number of interfaces, MTU size, transfer rate, physical addresses, etc.);
3) AT (3 objects) - responsible for address translation. It is no longer used. It was included in MIB I. An example of using AT objects is a simple ARP table (for more information about the ARP protocol, see the article "Non-standard use of the ARP protocol", which can be found on the official website in the Articles section) of matching the physical (MAC) addresses of network cards to the IP addresses of machines. In SNMP v2, this information was transferred to the MIB for the corresponding protocols.;
4) IP (42 objects) - data on passing IP packets (number of requests, responses, dropped packets);
5) ICMP (26 objects) - information about control messages (incoming/outgoing messages, errors, etc.);
6) TCP (19) - everything related to the transport protocol of the same name (algorithms, constants, connections, open ports, etc.);
7) UDP (6) - similarly, only for the UDP protocol (incoming/outgoing datagrams, ports, errors);
8) EGP (20) - External Gateway Protocol traffic data (used by routers, objects store information about received/sent/dropped frames);
9) Transmission - reserved for specific MIBs;
10) SNMP (29) - statistics on SNMP – incoming/outgoing packets, packet size limits, errors, data on processed requests and much more.
Each of them is represented as a tree growing downwards (the system resembles a DNS organization). For example, we can access the administrator's address using the following path: system.sysContact.0, system.sysUpTime.0, and system description (version, kernel, and other OS information): system.sysDescr.0. On the other hand, the same data can be set in dot notation. So, system.sysUpTime.0 corresponds to the value 1.3.0, since system has the index "1" in the MIB II groups, and sysUp-Time - 3 in the hierarchy of the system group. The zero at the end of the path indicates the scalar type of the stored data.
Symbolic names of objects are not used during operation, that is, if the manager requests the contents of the system.sysDescr. 0 parameter from the agent, the object reference in the query string will be converted to "1.1.0", and will not
be passed "as is". Next, we will look at the BULK query, and then it will become clear why this is so important. This completes the overview of the MIB II structure and goes directly to the description of the interaction between managers (management systems) and agents.
In SNMP, the client interacts with the server on a request-response basis. By itself, the agent is able to initiate only one action, called a trap, an interruption ("trap" - trap). In addition, all agent actions are limited to responding to requests sent by managers. Managers, in turn, can make four types of requests:
GetRequest is a request from the agent for information about a single variable.;
GetNextRequest - instructs the agent to provide data on the next (in the hierarchy) variable.;
GetBulkRequest is a request to get an array of data. Upon receipt, the agent checks the data types in the request for compliance with the data from its table and fills the structure with parameter values: for(repeatCount = 1; repeatCount < max_repetitions; repeatCount++). Now imagine a manager's request for a list of hundreds of variable values, sent in symbolic form, and compare the size of that with the size of a similar request in dot notation. I think it's clear what the situation would lead to if symbolic names were not transformed in the above way.;
SetRequest is an instruction to set a specific value with a variable.
SNMP is a monitoring and diagnostic protocol, and therefore it is designed for situations where the integrity of routes is compromised. In addition, in such a situation, a transport protocol that is as low in hardware requirements as possible is needed, so the choice was made towards UDP.
Suppose a manager has sent several packages to different agents, how can the management system further determine which of the incoming packages concerns the 1st and 2nd agents? To do this, each package is assigned a specific ID - a numeric value. When the agent receives a request from the manager, it generates a response and inserts the ID value it received from the request into the package (without modifying it). One of the key concepts in SNMP is the concept of a group. The manager's authorization procedure is a simple check to see if he belongs to a specific group from the agent's list. If the agent does not find the manager's groups in its list, their further interaction is impossible.
It is quite obvious that more reliable authentication tools are needed for secure authentication of this. The first version of the SNMP protocol even had a joke like this: "SNMP means Security is Not My Problem, security is not my problem."
Before that, we had encountered the first and second versions of SNMP several times. Let's pay attention to the difference between them.
First of all, we note that SNMP v2 includes support for traffic encryption, for which, depending on the implementation, DES and MD5 algorithms are used.
This leads to the fact that when transmitting data, the most important data is not available for sniffing, including information about network groups. All this led to an increase in the traffic itself and a complication of the package structure.
It seems that the protocol is designed to work in an environment of so-called "trusted hosts". Let's imagine a certain IP address, the owner of which has the intention to benefit or simply annoy the administrator by disrupting the operation of a certain network. Let's take the place of this attacker. Consideration of this issue can be reduced to two points:
a) we are outside the "hostile network". How can we do our dirty deed? First of all, we assume that we know the address of the network gateway. According to the RFC, the management system is connected to the agent via port 161 (UDP). Let's remember that successful work requires knowledge of the group. Here, the attacker is helped by the fact that administrators often leave the default group values (names), and by default there are two groups for SNMP - "private" and "public". If the administrator did not provide for such a development, the ill-wisher can cause him a lot of trouble. As you know, the SNMP protocol is part of Fingerprinting. If desired, thanks to the system MIB II group, it is possible to learn quite a lot of information about the system. At least the read-only sysDescr parameter is worth it. After all, knowing exactly the software version, there is a chance, using the tools for the appropriate OS, to gain full control over the system. I mentioned the read-only attribute of this parameter for a reason. After all, without rummaging through the snmpd sources (in the case of a UNIX-like OS), this parameter cannot be changed, that is, the agent will faithfully give the attacker all the necessary data. And do not forget that agent implementations for Windows are supplied without source codes, and knowledge of the operating system is 50% of the success of the attack. In addition, let's recall that many parameters have the rw (read-write) attribute, and among such parameters is forwarding! Imagine the consequences of setting it to "notForwarding(2)" mode. For example, in the Linux implementation of the software for SNMP called ucd-snmp, it is possible to remotely run scripts to servers by sending a corresponding request. The successful implementation of these threats can lead to extremely sad consequences.;
b) the attacker is on the local machine. In this case, the probability of the administrator's dismissal increases dramatically. After all, being in the same segment of the network makes it possible to simply sniff out the names of groups, and with them, a lot of system information. Everything mentioned in paragraph "a" also applies to this case.
Thus, when using the SNMP protocol, you need to be extremely careful. To ensure the security of devices monitored via SNMP, firewalls must be used to segment and allow only trusted hosts to interact using this protocol.
To detect devices that support SNMP, you can use the SNMP utility included in the Kali distribution.
It can be used to scan the subnet for devices that support the SNMP protocol. If detected, an attempt will be made to select the community both in search mode and by dictionary.
Oleg Petukhov, lawyer in the field of international law and personal data protection, information security specialist security, protection of information and personal data.
Telegram channel: https://t.me/protectioninformation Telegram Group: https://t.me/informationprotection1 Website: https://legascom.ru Email: online@legascom.ru #informationprotection #informationsecurity