SNMP service: still opened to the public and still queried by attackers
by Manuel Humberto Santander Pelaez (Version: 1)
Simple Network Management Protocol (SNMP) is a UDP service that runs on port 161/UDP. It is used for network management purposes and should be reachable only from known locations using secure channels.
I reviewed my honeypot today for interesting connections during december 2019. Saw an increase of snmp queries with the following distribution:
This is interesting as attackers are querying for the Community-Based Simple Network Management Protocol version 2 (SNMPv2c) instead of SNMPv2. It introduced GetBulkRequest command to gather large amount of data. SNMPv2c includes SNMPv2 without the SNMPv2 security model, using instead the simple community-based security scheme of SNMPv1.
Our ISC data shows this port was also active during december with a small spike during the first week of 2020:
Shodan report shows many devices connected to the internet with open SNMP port:
And there are domains with an important number of devices with open SNMP port. Source is Shodan:
We can conclude the following:
- There are devices that still have SNMP open to the Internet and the attackers know it. They predominantly search for devices that respond under the SNMPv2c protocol.
- You should not place devices on the Internet with open SNMP services. This is a very cheap way for an attacker to gather intelligence about your network and traffic.
- Please always use secure protocols:
- SNMPv1 send passwords in clear text. SNMPv2 is prone to password hashing attacks.
- SNMPv1 and SNMPv2 are vulnerable to IP spoofing. None of them should be used.
- SNMPv3 is vulnerable to brute force and dictionary attacks. This is the current protocol version. To mitigate the vulnerabilities, you should use IPSec transport connections.
Do you have any other interesting findings to share with us? Please send them out using our contact form.
Manuel Humberto Santander Pelaez
SANS Internet Storm Center - Handler
Twitter:@manuelsantander
Web:http://manuel.santander.name
e-mail: msantand at isc dot sans dot org
Increase in Number of Sources January 3rd and 4th: spoofed
Justin C alerted me in our Slack channel that GreyNoise, a commercial system similar to DShield, noted a large increase in the number of sources scanning. We do have these "Spikes" from time to time and had one for the last two days. Artifacts are usually not lasting that long, and we also did not have a notable change in the number of submitters. So I took a quick look at the data, and here is what I found:
| Date | Sources |
|---|---|
| Jan 2nd | 271,050 |
| Jan 3rd | 500,226 |
| Jan 4th | 592,926 |
Looking at the top /8 Networks also shows an interesting anomaly (each table cell contains the /8 followed by the number of sources from that /8):
| Jan 2nd | Jan 3rd | Jan 4th |
|---|---|---|
| 103/8 (6666) | 103/8 (181969) | 103/8 (308602) |
| 36/8 (5620) | 167/8 (24761) | 187/8 (5633) |
| 187/8 (5601) | 177/8 (5857) | 177/8 (5262) |
| 177/8 (5365) | 187/8 (5847) | 14/8 (4903) |
| 14/8 (4908) | 36/8 (5783) | 189/8 (4864) |
| 189/8 (4796) | 14/8 (5539) | 190/8 (4703) |
| 113/8 (4731) | 189/8 (5382) | 36/8 (4501) |
| 190/8 (4237) | 190/8 (4846) | 113/8 (4323) |
| 200/8 (3875) | 113/8 (4805) | 185/8 (4113) |
| 185/8 (3618) | 117/8 (4057) | 5/8 (3872) |
Scans from 103/8 pretty much explain the increase in sources we had over the last few days. There was also a notable increase for 167/8 on the 3rd, but it was nowhere as significant as the increase for 103/8. Now we can "zoom" in on the reports from 103/8 and look at how they compare to the rest of our reports. I ran this data across all three days:
| 107/8 | not 107/8 |
|---|---|
| 22 (182,710) | 445 (140,056) |
| 23 (170,000) | 23 (117,595) |
| 80 (35,102) | 80 (73,071) |
| 7547 (29,649) | 8080 (69,167) |
| 443 (23492) | 22 (33,520) |
The big anomaly is port 22 and 23 here. It looks like the 103/8 network prefers to scan these two ports. Of course, these are popular ports in general.
Now, if they are scanning port 22 and 23, then we should see them in our cowrie honeypots if they are trying to log in.
Let's look at the number of source IPs from Cowrie logs:
| All Sources | 103/8 Sources | |
| Jan 2nd | 21,647 | 562 |
| Jan 3rd | 20,013 | 526 |
| Jan 4th | 12,575 | 284 |
So no increase in login attempts and 103/8 is unremarkable. Having no logins from 103/8 could indicate that the purpose of these scans is to either find open ports or the scans are spoofed. To investigate further, I plotted the 2nd Byte of the IP address for all 103/8 sources
The distribution is pretty "random" with a dip from about 150-190. The unassigned /16 in this netblock (in addition to smaller blocks) 103.128/16, still had 1,174 sources contributing to these scans. All of these scans are from January 3rd and 4th. Our sensors detected nothing from 103.128/16 on January 2nd. So this is a pretty good hint that the scans are spoofed.
What is special about 103/8? This netblock was the last /8 assigned to APNIC from IANA. It was assigned to APNIC on Feb 2011, and assignments from 103/8 have been made to ISPs all over Asia.
Why would someone run a large spoofed scan like this? Not clear. It could be an experiment, a bug, or an attempt to hide the actual scan. I will look into this in more detail tomorrow. This may be a new "Mirai" style botnet that tries to do something a bit different, but . of course, we won't get the respective malware from 103/8 if these scans are spoofed. Usually, "decoy scans" that include spoofed packets, in addition to real packets tend to be a waste of time for these simple internet-wide scans. If anything, they increase the noise and make it more likely that the scan is discovered. The scanning system is usually better off using these resources for actual scans. One of the "breakthroughs" of MIrai was its scanning speed after all. It may be notable that the scans started on 01/03, and the spoofed IPs are '103'. But not sure if this means anything.
---
Johannes B. Ullrich, Ph.D., Dean of Research, SANS Technology Institute
Twitter|
Comments