Leaking names

Leaking names

  • Comments 2

A short blog tonight.

There are many pieces of information that can be useful to an attacker when they are trying to gain access to your organisation or when they are already "in" and want to do some damage. Two things that may not be immediately obvious as "sensitive" are product code names and internal machine names.

There are various reasons to keep code names secret, such as the ability to discuss things in relatively public areas (like restaurants) without anyone else knowing what you're talking about, or because the cool-sounding code name you picked for your product might actually be someone else's trademark. But from a security perspective, letting people know your code names makes it that much easier for them to launch social engineering attacks against you.

For example, someone calls you up and says:

"Hey Bob, this is Frank over in marketing. Can you refresh my memory on the release date for 'CoolBananas' again? Steve is in my office and he wants an answer ASAP. Thanks!"

In this situation, you might be inclined to answer the question without thinking twice. After all, if the caller knows what CoolBananas is, they've got to be a Pretty Important Person, right? And although you don't actually know any of those suits over in marketing, the name "Steve" sounds vaguely familiar. "Something you know" -- be it a password, a secret handshake, or your mother's maiden name -- is one of the most popular ways of authenticating people both online and off, and it works in this case too. Someone who throws around internal code names is more likely to succeed at getting even more information out of you than someone who calls up out of the blue and says "Hey, when's your next product shipping?"

Now the astute reader might (at this point in time) object that Microsoft lets lots of codenames slip out -- everyone has heard of Longhorn, or Whidbey, or Yukon, or Titanium. That's true, but I bet you don't know what the internal codename for VSTO was, or for VSA, or for any of our future products. We do need code names for big products to enable us to talk to customers and the press about "the next version of Product X" before marketing and legal have blessed it with a real name (which can take a l...o...n...g time, let me tell you!) but smaller products and individual features often have code names that you will never hear of.

Now think about server names. On the surface they don't seem that important. Who cares if people know that my old laptop was named trancebaby or that your desktop machine is called wombat? But what if they know a machine is called ACME-PDC? Perhaps that is a Windows Domain Controller, and would be very useful to attack. Or perhaps they've already gained access to your network and are looking for ways to do the most amount of damage in the least amount of time (before they get caught). If they know that there are two servers named SQL-DEV and SQL-PROD, which one will they go after? (Actually, that's an interesting question, since the DEV (development) server is likely to be more "wide open" than the PROD (production) one, so it might be easier to elevate privileges on that box, but the PROD server is more likely to contain real, juicy data that can be stolen or corrupted, and it's more likely to be "trusted" by other machines than the DEV box). It's a bit more black-and-white if they know one machine is called JillsLaptop and the other is called SrcSafeSvr.

Now if you combine these two pieces of information, you can get even better at your social engineering:

"Hey Bob, this is Frank over in marketing again. I've been poking around the HotFudge server but I can't seem to find the specs for CoolBananas. Can you IM them to me at Frank1234@hotmail.com? The darn mail server is down again, and I need to finish a business plan for Steve by tomorrow. Thanks!"

One of the problems with VSTO is that, due to the fact that documents link to code on a separate server, if you ever forward a document outside of your organisation then it might be possible for people to deduce something about your network based on the document's custom properties. Unfortunately this is a general problem with any kind of linked content (pictures, database queries, OLE links, etc) and there's no easy solution to it. IRM might help in some of these cases, but because the OLE properties used to store the assembly location aren't part of the main document stream, they're not protected. You can support stripping of the custom properties as part of the solution itself (or, if you're really clever, perhaps even on your outbound mail server) but it's not easy and it's not the default behaviour.

It would be nice if we had a better solution here in the future (such as real integration with mail gateways or IRM), but in the meantime you should assume that if you use VSTO solutions and forward your documents outside of the firewall then your code distribution server name is "public knowledge." All the more reason to take good care of the server (and to ask Frank to re-authenticate with some more substantial evidence than just the server name before handing out the crown jewels...)

  • This is all basic technique. Mitnick goes into it in depth in his book.

    http://www.amazon.com/exec/obidos/tg/detail/-/0471237124/qid=1080681514/sr=8-1/ref=pd_ka_1/102-6347957-0921766?v=glance&s=books&n=507846
  • Thanks for bringing this up! I know a lot of people that will be talking about this at work tomorrow, (that's the power of blogs and the blogs.msdn aggregator...), and I think it is important to realize (and spread the word) that authentication schemes and locked down networks doesn't do the trick all the way. After all, I know way to much about company XXX's stuff and their YYY stuff, after meeting that John Doe guy at VSLive a few years ago...
Page 1 of 1 (2 items)