Following on the heels of applying the patch Fred Rica style (see www.infosecnews.com/opinion/2002/04/17_04.htm), the SNMP vulnerability has loomed into view as the next procrastinating administrator’s nightmare.
With an overwhelming influx of devices wanting to connect to the Internet, SNMP 1.0 was developed to standardize their management. Envisioned as a type of protocol to allow for a central management station, all devices would have a small agent on them that would listen for the requests from the manager. With agents sending their data back in the form of 'traps' to the manager, this left a two-way communication string that has evident possibilities of error and disruption.
The Oulu protocol test team in Finland set out to discover what would happen if the agent sent the manager a bad trap. Conversely, they tested the manager's communication by disrupting field lengths and viability. What they found in SNMP 1.0 was fairly shocking. The number of flaws found in any number of directions on the parameters, both on the agent and the manager sides, was much more than they could have anticipated.
Back in 1990, the Internet Engineering Task Force (IETF) knew of the version 1.0 shortcomings and set to work rather quickly on version 3.0. The newer version was released containing cryptographic authentication and safeguards. The problem, however, gets propagated by the fact that most companies are still shipping SNMP version 1.0, which provides default community strings, public and private, that unless changed allow a hacker easy access in contacting corporate agents still using the standard defaults.
I heard mention of this vulnerability in early 2002. It was shining momentarily as the next scary star in our network solar system. However glaring though, it appears to have flamed out with no reported security breaches bolstering its fearsome nature. I spoke with Darwin Ammala from the Harris Network Security STAT team, to get his opinion on the largely overlooked septic nature of the SNMP vulnerability.
"A good practice is to go and change the defaults, which is very easy to do," states Ammala. "A lot of people put devices out there and figure that it's a minor device, and they don't need to worry about it. It's one of the dangers in this vulnerability in that there are a lot of those untouched defaults out there. No one knows for sure how many and how far reaching this is."
The notion of developing more secure software came to a head in the late 1990s, giving five or six years worth of population of these version 1.0 protocol devices and default settings by organizations. Looking at these legacy devices, even considering the natural turnover within an organization and its IT department, adding to that the proliferation of even more devices, software and administrators, and it's easy to see that there are very real vulnerabilities at the most basic of levels within businesses in the U.S. and beyond.
It could be overwhelming to consider addressing the issue, but blessedly, the fix is extremely simple. According to Ammala, there are some commonsense factors to tackle first.
"What a company needs to do is understand the perimeter devices on networks they control. Identifying the boundaries is the first step and most everyone knows where those are. There is a line of demarcation where the company and its devices are on one side, and someone else's devices are on the other. You go to the perimeter devices and you can configure your routers and your firewalls to only accept traffic on the SNMP ports that are coming from an address known to be yours, whether it's from another campus or another country. You know what your own IP addresses are."
With appropriate filtering, 'ingress and egress,' an administrator can effectively limit the packets coming in by denying access to those that are not recognizable as their own. Blacklisting bad traps denies them access to the devices, denying them access to the managers.
"The quick fix is quite effective actually," Ammala stresses. "A router will plainly not allow a trap to get inside, and that will buy you time to go back in and make all of these corrective changes and software updates."
Upgrading to SNMP 3.0 would seem to be the obvious goal for all corporate administrators; however, it's questionable as to whether or not vendors will exhaustively support this version, despite the inherent and dangerous flaws exposed in 1.0, now over a decade old.
"The broad announcement of the vulnerability certainly should be a wake up call to any company that hasn't already begun addressing the issue, to do so now," says Ammala. "This community string I'm talking about has been known of since 1990. It's nothing new."
History teaches us that eventually, there will be someone that will come along to test whether or not a company has addressed the SNMP issue and essentially locked its backdoors. Like anything else that is cyclic in nature, it's a matter of time and energy.
"Somebody will, at some point down the road say, 'As an intellectual exercise, I wonder how many people took this seriously'," Ammala explains. "They'll write a script that will allow them to contact the devices and run with the privileges of the manager. They can do all sorts of interesting things with this such as looking into files, or changing configurations. It could be much more serious though, causing half of a company's network to drop off without the administrator realizing the cause. It's hard to say accurately how severe it could be, not knowing all the vendor peripherals out there to affect, but denial-of-service would certainly be something to expect."
In the ROI mind-set of corporate America, at least, it makes more sense financially to upgrade your software than manually apply the fix. In installing the newer versions, it allows a company to address vulnerabilities that they are not even aware of -vulnerabilities that have only been exposed in the development labs, spurring the onslaught of new releases. Each new version of a critical software package includes not only valuable ease-of-use upgrades, but often closes the holes that a hacker would eventually find in your system.
Seemingly, the popular opinion is that if the issue hasn't caused mountains to fall or money to go streaming out through the corporate pipeline, it isn't worth addressing. It's prudent to remember that we live in a different reality now. The impossible happens in our lifetime, and it always pays to address what we can as soon as we can in every aspect of our business culture.
Melisa LaBancz is a San Francisco Bay Area security journalist, actively addressing her own vulnerabilities
