SNMPv3/USM, unfortunately, does suffer from some elements of man-in-the-middle attacks. But these are poorly understood and certainly not well documented (if at all). This document attempts to describe the weakness inherent in the SNMPv3/USM protocol.

Background and Conventions

Although this document coves some of the necessary background, it’s still expected that the reader already understands how SNMPv3 with its User Based Security Model (USM) works. The details of the SNMPv3 protocol and the USM-subprotocol aren’t discussed in this write-up.

It’s also expected that the reader is familiar with the USM concept of “discovery”, which can be summarized at a high level as this: a manager is allowed to send a “probe” message to an agent and the agent should return a “report” message that says “I’m using securityEngineID 1234”. An important element of this discovery request and response process is that it’s fundamentally unauthenticated. There is no proof that the agent responding actually is the right agent. The belief is that because future requests and responses are authenticated and use a key only known to the agent the manager wants to communicate with that the unauthenticated discovery request isn’t a big deal. But, in fact, it is and it does open the door for certain types of man-in-the-middle attacks.

USM contains a key-localization process provides the ability for the administrator to provide only a master password or a master key and the management software can transform that key through a series of one-way hashes into a key which is unique to each agent that the packets are destined for. Though this does prevent keys stolen from one agent from being used to break into another, it doesn’t help in the problem described below as will be shown. It won’t matter if the key localization process is used or not; they could have been randomly generated for each remote agent.

For documentation simplicity I’m only showing the use of one key in this document. But in SNMPv3/USM there are actually two: one for authentication and one for encryption. For purposes of the discussion, however, we can treat the keys as a “pair” and any time one is affected then so is the other.

SNMPv3 also has the notion of a contextEngineID, which is not discussed in this document as it is not relevant. Only USM’s specific securityEngineID is relevant to this discussion.

Typical Real-World SNMPv3/USM Start-Up Sequence

Pictures are always easier to understand, so let’s pretend we have the following network setup. Agent B will be colored red in these pictures since in the examples below we’ll consider it to be a machine which has been taken over by an attacker.

Typically a management station starts talking to an agent for the first time over SNMPv3/USM it will send an an securityEngineID request. And, of course, the agent sends back a response with its own securityEngineID:

At this point, the management station can start sending authenticated and encrypted traffic to the agent by using the authentication and encryption key assigned to the given securityName for the remote agent. Each agent has its own unique key pair that the manager uses to communicate with it and internally the manager has a table (the usmUserTable) of all the users and keys for the agent it wants to talk to.

The Attack

The problem with this situation is that the manager uses two values in order to look up the key for a given communication.

1. It uses the securityName value it was given by some dialog box or command line option. In these diagrams this value is “userJoe”.
2. The securityEngineID that it potentially learned from the discovery process.

But Discovery Results Aren’t Authenticated

Assume in the diagrams that Agent B has been compromised and it’s keys are now known to the attacker. Normally traffic sent from the manager to Agent A should be authenticated and encrypted with Agent A’s keys. This means that Agent B shouldn’t be able to see or respond to requests sent to Agent A because it doesn’t know the right keys.

But, if an attacker has compromised a device that is able to see traffic destined for more than just itself (e.g. when connect to a hub or truly in the middle of the path) then there is a problem if it can also spoof traffic. All it has to do is spoof responses to other addresses with its own securityEngineID for any securityEngineID probe that comes it can see. It will have to do this faster, of course, than the real agent can respond (but that can frequently be easily helped by launching DOS attacks). The end result is that the manager will get back a packet in response to it’s securityEngineID probe with a packet that looks like it was from Agent A but internally has a securityEngineID for Agent B.

Now, the manager thinks it has the right securityEngineID for Agent A, but in fact has the wrong securityEngineID for it (i.e. it has “engineIDB”). It uses this securityEngineID (“engineIDB”) in combination with the operator-provided securityName (“userJoe”) as indexes into it’s user/key table to figure out which key to use for protecting traffic. This look-up succeeds in finding a key, but has in fact found the wrong key for the agent it wants to talk to (Agent A). Instead, it finds Agent B’s key and starts its communications using KeyB.

Agent A will actually drop any requests that fail authentication (possibly sending a notification; but more on that later). But Agent B no longer even has to beat Agent A’s response back to the manager so there won’t be a race any longer and Agent B has successfully captured the entire communication stream until the manager looses its knowledge of Agent A’s securityEngineID again.

What Power Does This Leave Agent B With?

This only buys Agent B two things:

1. The power to receive and decrypt traffic that was intended for Agent A. Typically GET and GETNEXT requests from a manager shouldn’t have anything but OIDs in them (though from an analysis point of view it might contain information about what functionality Agent A is supposed to have). SET requests, however, might have more interesting information encoded into the values that might be worth “stealing”.
2. The power to spoof Agent A and return fictitious data from it. Agent B can now adequately pretend to be Agent A and thus can return bogus data as well as pretend to have acted as if SET requests had really been processed. This lets untold number of bad things happen, including convincing a management station that a device is fine when it really isn’t, under-reporting bandwidth usage, etc…

Protecting Yourself From The Attack

There are only a few choices when considering what to do about this attack:

1. Understand the weakness and be OK with it. Just don’t be ignorant of it.
• Understand that:
  • Management data sent from the management station can be stolen.
  • An agent can be “spoofed”. A management application may think it’s talking to agent A which has possibly:
  • Accepted and acted upon SET data.
  • Has returned real and true values that you can trust to be from that agent.
• Protect yourself as best as possible:
  • Leaving your management applications long-running so they memorize securityEngineIDs can be helpful (though if the attacker succeeds at any point, you’ll believe he’s the right agent for a longer period of time so it’s still a trade off).
  • Doing a “leap of faith” type approach and believing the first securityEngineID and expecting it “from then on” (even if the management station is shut down; though I don’t know of software that stores securityEngineIDs in persistent storage.).
2. Don’t use the securityEngineID discovery process and pre-populate the management database with the real expected securityEngineIDs extracted from their consoles. Unfortunately, this doesn’t scale well. And thus I don’t know of a single person who actually manages their network this way.
3. Use different securityNames on every agent. Unfortunately, this doesn’t scale well either. I don’t know of a single person that manages their network this way either.
4. Use another form of SNMPv3 security, such as SNMP/SSH transport or the upcoming SNMP/(D)TLS transport. These forms of SNMPv3 don’t suffer from this weakness but have only recently been defined by the IETF and aren’t widely implemented and deployed.
5. Only run management commands over a protected physically separate and entirely switched network. Fortunately, this is frequently common practice. Though it doesn’t necessarily eliminate the threat depending on which network components have been broken into, it should help reduce the threat significantly.

Questions and Answers

Does This Attack Work If Not Man-In-The-Middle?

The short answer is “no”.

The longer answer is that if the attacker can’t see the traffic, then they’d have to be able to guess the manager’s messageID and time the securityEngineID response appropriately.

But even if they could do that, it doesn’t help much unless they can see the traffic since they won’t see what they can now decrypt and respond to. The attacker can’t easily respond to what they can’t see (without an unreasonable amount of guessing of packet contents and timing).

The best an attacker can hope to accomplish would be a denial of service attacker because the manager would fail to communicate with Agent A while the securityEngineID mismatched.

What About Authentication Failed Notifications?

If all the agents are configured to send out SNMPv2-MIB::authenticationFailure notifications then in theory the manager would receive a notification every time agent A received a packet that wasn’t authenticated with the proper key (keyA).

This is true and maybe helpful if authentication-failure notifications have been turned on. But the evil Agent B entity may find it possible to spoof securityEngineID query responses from the management’s notification receiver to stop INFORM notifications from being encrypted with the right authentication key thus causing the notification receiver to drop the notifications. TRAP notifications are sent using the local (correct) engineID so this attack won’t work on them.

I recently posted my both funny and depressing text message conversation with AT&T as a result of their spamming me (which, by the way, I still haven’t managed to turn off mostly because I gave up).

A friend of mine (WY0X) gave me permission to post his recap of his on-the-phone conversations with AT&T about a similar, but even worse, problem:

I love the fact I have intelligent friends. I hate the fact I have less-than-intelligent companies.

Recently my wife and I went to Stockholm, Sweden. We were there, accidentally, for 2 weeks in total. For the first 2 days we wandered around and tried to battle jet-lag through a healthy regiment of walking in the sunlight with frequent stops to consume cappuccinos. Following that, I had a week long convention while Dawn did whatever suited her at the time.

Our first major outing was to the island of Gamla Stan, which is one of the oldest parts of Stockholm. It’s narrow streets are filled with stores, restaurants and brightly colored walls. It’s an extremely relaxing area of the city to walk around that is devoid of cars and full of things to feed your eyes. There are, especially in the summer, a huge number of tourists so the streets are crowded but it’s worth it. The Stockholm guidebooks we looked at mentioned pick pockets but we felt much safer in Stockholm than many other large European cities.

During my working-week we did get to spend an evening at the wonderful Vasa museum. This museum is dedicated to a huge wooden war ship which sank in 1628 and was recovered in 1961. It’s a wonderfully done museum dedicated to a ship that is stunning to walk around. Though it does feel odd to visit a museum entirely dedicated to a ship that failed so dramatically: it sunk only a few minutes into its maiden voyage. The museum is on the “must see” list if you ever plan to visit Stockholm.

After these first few wonderful days of touring the city we were emailed by our currently preferred credit card company (thank goodness for conference internet access!) that we needed to contact their fraud department ASAP and they had deactivated our card. After calling, we learned that they suspected something was wrong. They asked us if we had purchased plane tickets recently. Certainly, we assured them, we had. Also, did we purchase anything from overstock.com on July 24th. Well it so happens that was the day we were travelling (and travelling and travelling), so we certainly hadn’t. They immediately cancelled our cards and promised to send new ones to our hotel and they “should hopefully get there by Saturday”. This was a good thing as we were set to check out on Sunday.

We had a wonderful last day in Stockholm on Saturday visiting some of the museums that we hadn’t seen yet. The Nordic and historical museums are well worth visiting in Stockholm. The historical museum in particular goes into great depth about the fascinating Viking history in wonderful detail. That evening we returned to the hotel and were told by the front desk that, sorry, but we hadn’t received a package. Oh uh, we thought. Now what. Our only choice was to stay longer and wait for it. So much for our “last day”. Fortunately, they had enough room that we could stay until Monday if we liked while we were waiting “our package” (we of course didn’t admit we were waiting for cards to pay them with). So much for our plans to see the south of Sweden.

So we spent another wonderful “last day” on Sunday visiting Skansen, which is an outdoor museum of Swedish historical architecture and culture. In a large open space on the top of a hill in an island with a beautiful view of the water around Stockholm, they brought in houses and buildings from around Sweden from various time periods and let visitors walk around and through them. It is an absolutely fascinating area that we spent over 10 hours in before giving up and realizing we couldn’t see every possible structure (but we still felt good about getting to 90% of them or so).

The next day, Monday, we slept in after our 10+ hour walk. Around 11:00 (an hour before checkout time) we checked with the front desk and they informed us “no package; yes you can stay until tomorrow”. Then we brain stormed. What now? Well, we hadn’t yet taken a boat cruise through the city, so… let’s do that. We opted, after pouring over brochures, to forget the simple cruise around the city and go all out for our “3rd last day”. We signed up for an all day boat cruise for the day after that would take us through some of the neighbouring islands. And yes, we could stay until Wednesday since the all-day Tuesday trip would ruin our chances of checking out on Tuesday. And yes, they could add the boat trip tickets to our hotel room bill. Excellent, I thought while slyly trying to glance through the kitchen doors to see how many dishes we’d be able to wash in order to pay the upcoming larger and larger bill without a credit card.

The boat cruise was fantastic. Just off the coast of Stockholm are 30,000 archipelago (small islands for those of you with a vocabulary similar to mine). The boat cruise took us around and through a gazillion of them and dropped us of for an hour on three of them. Each were different, the final including a cute village with brightly colored houses. All red. My favorite of the three islands, though, was the most remote, desolate, rocky island. I could have spent a full day on that small island walking across the barren terrain through the fog.

Upon arriving back at the hotel that evening we, of course, found no package waiting for us at the front desk. We called the bank again and they apologized profusely and explained that they couldn’t even find a tracking number for the package they had sent. They were deeply concerned about this and would look into it.

Now, I don’t want to say anything particularly negative or positive about the bank in question. It’s probably not even worth naming them. On the plus side, they were extremely courteous (of course) on the phone. But, on the down side they did fail to get us new cards within even 5 days. They’re on par for the typical banks in the U.S. of America.

We learned one important lesson during the trip: always carry two credit cards. Of course we always knew you should do this, but now we really understood why. I think this is the first trip we hadn’t taken two and naturally it was the first one where we needed two. At least we had an ATM card (which is also supposed to work as a visa but never seems to act that way consistently). Next time we’ll certainly take a back up. We’ve learned.

If there is one thing I’ve learned from travelling: you need to roll with the punches. Almost no trip goes perfectly (oh the stories I could tell about just airports!). When travelling, if you spend all your time just fighting the good fight, you’ll have a lousy vacation.

In the end the bank informed us that we could ask the front desk to charge the bill to our old credit card and it would fail. Then we could call the bank and they would authorize the next charge of that amount and it would succeed the second time. Now, when you go to the front desk of a hotel that you’ve just spent two expensive weeks at and tell them to “try this card but it’ll probably fail” you should have a camera ready to capture their expression. It’ll be priceless. But the process did work as expected and I’ll now quote the receptionist after the second charge succeeded: “Yessssss!” (while throwing a fist in the air).

All in all, Stockholm is a wonderful city to visit. There is more to see and do than you can fit into even two weeks, as it turned out. And if you have to get stuck in a city, it’s a good one to pick to be stuck in. My wife summed up Stockholm wonderfully: it isn’t Paris, but it’s definitely right underneath it as good places to visit.

So, AT&T has gotten in the recent habit of spamming you with “tips”. “tips” are really “spam” when they’re trying to get you to do things that will eventually make them money (ie, by using more of their services).

Here’s the “tip” I got today:

AT&T:
AT&T Free Tip: Get weather, movie or restaurant
tips from Google on your phone.
Text HELP to 466453 to get started.
To end Tips send no to 4436

Easy, enough, I thought.

Me:
No

And a few seconds later, I got the response back:

AT&T:
Sorry, we did not understand
your response.  Reply ONLY the
word "YES" to activate the 4
channel/$6 Mobile TV plan

HUH???

Ok, I thought. Maybe it’s because my phone auto-capitalized the word “No”

Me:
no

And a few seconds later, I got the response back:

AT&T:
Sorry, we did not understand
your response.  Reply ONLY the
word "YES" to activate the 4
channel/$6 Mobile TV plan

NOOOOOOOOOOOOOOOOO

sigh…

[UPDATE 2009/08/20: Read the follow-on story from a friend describing his conversation with AT&T]