How SNMP is exploited

• Discover how SNMP can make your network vulnerable to attack

SNMP provides an easy way for administrators to get topology information about their networks and even provides some management of remote devices and servers. However, you have to be very careful that you correctly block SNMP traffic at your firewall; otherwise, hackers can also use it to gather that valuable network information and exploit vulnerabilities.

How SNMP is exploited
The SNMP agent for Windows NT can disclose lots of useful data to a hacker, especially if the server is also running WINS and/or DHCP. If these services are running on the NT Server, SNMP can disclose the same data you get from NBTSTAT or remote procedure calls, including a network map and an IP address to MAC address mappings. SNMP management software can even change WINS and DHCP databases remotely if the read-write password is known. However, SNMP is a cross-platform protocol, so its vulnerabilities are definitely not limited to Windows networks.

Since management information databases (MIBs), an SNMP component, often include a TCP connection table listing all passive open ports and active TCP connections, this information can be accessed remotely. Some vendors, such as Cisco, automatically hide some of the SNMP information, but even Cisco software doesn’t hide all of the TCP table data—and many vendors’ implementations of SNMP don’t conceal any of it.



Bottom line
SNMP can be exploited by hackers who are trying to attack a network, making it a major potential security risk. As we’ve discussed, you need to set up your firewall to block UDP ports 161 and 162 to the outside world, or at the very least, closely monitor all traffic on these ports. It’s also a good idea to change the default SNMP community names so that they are not an easy target for hackers.
Are you blocking SNMP traffic at your firewall and/or monitoring SNMP traffic?

https://www.techrepublic.com/article/lock-it-down-dont-allow-snmp-to-compromise-network-security/

• Standard SNMP uses two types of community strings: read-only and read-write. The read-only community string allows administrators to query the device and only read values, while the read-write community string allows administrators not only to read values but also to change those values. However, the community string names are transmitted in clear text, and a cracker who is packet sniffing the network can determine the community name from passing traffic. Once this community name is known, the attacker can then read the values of the managed device, make configuration changes, and even shut down or reboot the system.

In many cases, attackers do not even need to sniff the network traffic to obtain a community name, because they can guess them relatively easily. In the past, many network administrators used easy-to-guess or well-known community names, such as "public," "admin," or "private," and sometimes did not even use a password.

Attackers also can exploit the characteristics of the User Data Protocol (UDP), which SNMP uses. As a connectionless transport protocol, UDP allows the delay, replay, and reordering of packets. Consequently, attackers also can delay, replay, and change packets and also may be able to influence the managed device's behavior.

Securing SNMP
Disable the SNMP service. Administrators should disable any unnecessary services or functions, including SNMP. However, when disabling SNMP, administrators also should implement filtering practices for additional security.

Employ ingress and egress filtering at the network perimeter. As a temporary solution, administrators can block access to SNMP services at the network perimeter. This action may help limit the scope of security vulnerabilities.

Ingress filtering controls incoming traffic as it enters the network. Normally, the only devices that must accept inbound traffic from the public Internet are servers. External hosts do not often initiate inbound traffic to servers that do not provide public services. Therefore, administrators can perform ingress filtering at the network perimeter to help prevent unauthorized services from receiving externally initiated inbound traffic.

Administrators can employ ingress filtering on the following ports to protect those devices in the local network that are not authorized to provide public SNMP services:

snmp 161/udp # Simple Network Management Protocol (SNMP)
snmp 162/udp # SNMP system management messages
In addition, administrators may use ingress filtering for the less common services shown in Figure 3 . Blocking certain services may affect other services, and administrators should carefully consider these ramifications.

snmp 161/tcp # Simple Network Management Protocol (SNMP)
snmp 162/tcp # SNMP system management messages
smux 199/tcp # SNMP Unix Multiplexer
smux 199/udp # SNMP Unix Multiplexer
synoptics-relay 391/tcp # SynOptics SNMP Relay Port
synoptics-relay 391/udp # SynOptics SNMP Relay Port
agentx 705/tcp # AgentX
snmp-tcp-port 1993/tcp # cisco SNMP TCP port
snmp-tcp-port 1993/udp # cisco SNMP TCP port
Figure 3. Less common SNMP services that may benefit from ingress filtering
Egress filtering controls outgoing network traffic. Devices providing public services usually do not need to initiate outbound traffic to the Internet. By employing egress filtering at the network perimeter, administrators can help prevent attackers from using the network to attack other sites.

Filter SNMP traffic from unauthorized internal hosts. Only a few network management systems need to initiate SNMP request messages. Thus, administrators can configure SNMP agent systems to prohibit request messages from unauthorized systems. This action can help reduce—although not completely eliminate—the threat of internal attacks.

Change default community strings. Products enabled with SNMP usually feature default community strings: "public" denotes read-only access and "private" denotes read-write access. Because these default access-control mechanisms are commonly known, network administrators should change community strings to make them more difficult to guess. Nonetheless, community strings—regardless of whether they have been changed from the default setting—are passed in plain text and thus vulnerable to packet-sniffing attacks.

When configuring SNMP community strings, administrators should follow these guidelines:

Do not use the default "public" or "private" string.
Do not use a string that would be easy to guess, such as the company's name or phone number.
Do not use a text-only string; use an alphanumeric string (both text and numerals).
Use both uppercase and lowercase letters (community strings are case-sensitive).
Use a community string that is at least six characters long.

Segregate SNMP traffic onto separate management networks. In some environments, blocking or disabling SNMP is not possible. Administrators can limit SNMP security threats in these environments by confining SNMP access to isolated, privately accessible management networks.

Ideally, this segregation would require physically separate networks, but that type of infrastructure is usually impractical. Instead, administrators can use techniques such as virtual LANs (VLANs) to help segregate network traffic. VLANs may not completely prevent attackers from exploiting SNMP vulnerabilities, but they can hinder an attacker's ability to initiate an attack.

In addition, administrators can implement virtual private networks (VPNs) to segregate SNMP traffic. VPNs use cryptography to provide strong authentication. However, administrators should be aware that implementing solutions such as VLANs and VPNs may require substantial alteration of the network architecture.

https://www.dell.com/content/topics/global.aspx/power/en/ps2q03_maahs?c=us&l=en&cs=04

• The security deficiencies of all SNMP versions can be mitigated by IPsec authentication and confidentiality mechanisms. The implementation of SNMP over Datagram Transport Layer Security (DTLS) is also available

If you do plan to use SNMP to control and monitor network devices that don't support SNMPv3, then it's easy to use IPSec to secure that traffic.
For remote networks that you'll be managing and monitoring with SNMP, I suggest creating an IPSec tunnel to the first network device (which is usually a router or firewall) that you physically maintain. This tunnel secures your network traffic across the public portion of your network (i.e., your Internet transport). In addition, it will simplify the addition of monitoring devices on the other end of your network as well as reduce the complexity of your overall architecture.

https://www.techrepublic.com/article/lock-down-snmp-traffic-using-ipsec/

• TLS is the successor to Secure Sockets Layer (SSL). The Transport Security Model addition to the SNMPv3 framework along with (D)TLS specifications allow organizations to bring SNMP users, applications, and devices under the umbrella of an X.509 public key infrastructure.

Datagram Transport Layer Security (DTLS) is TLS implemented on top of datagram protocols such as UDP. DTLS provides the same security for datagram protocols that TLS provides for stream protocols. (D)TLS is a term that collectively refers to TLS and/or DTLS.

With TLS and DTLS, SNMP messages can be exchanged over secure communication channels. While the security provided is the same, messages are exchanged and handled differently

• http://www.snmp.com/products/techinfo/secmodels.shtml

• Scanning NetBIOS

 

 During a penetration testing engagement we might come across with the NetBIOS service.In the past the NetBIOS protocol was enabled in almost every network that was running Windows.In nowadays system administrators are disabling this service due to the fact that plenty of information can be unveiled regarding shares,users and domain controllers.However NetBIOS can still be found on default configurations of Windows Server 2008 and Windows Vista so in a penetration testing this protocol can be abused if we discover it.

Generally the NetBIOS provides the following three services:

Name Service: UDP/137

Datagram Service: UDP/138

Session Service: TCP/139

 The two basic tools are nbtstat and nbtscan.The nbtstat is a command line utility that is integrated in windows systems and it can unveil information about the netbios names and the remote machine name table or local but only for one host.From the other hand the nbtscan is a netbios nameserver scanner which has the same functions as nbtstat but it operates on a range of addresses instead of one.

 

https://pentestlab.blog/2012/08/19/scanning-netbios/