Active Directory Domain Controller Hacked Through Remote DNS Management?

This is my initial reaction to Microsoft's Security Advisory 935964, and should be correct to the extent the advisory is complete and correct.

Through a buffer overflow attack on the RPC port of a Windows server an anonymous user can execute code in the DNS. Since the Windows DNS Service is integrated with Active Directory and often run on a domain controller, this means the attack has the opportunity to compromise a Windows domain controller, which is a great start towards

• Compromising other domain controllers (DCs)
• Compromising computers in the forest, attacking non-forest computers in the zone of trust accessible to the DC
• Escalating any kind of privilege that is controlled by groups, accounts or other objects in the Active Directory
• Intelligence gathering
• Doing mischief with DNS against anything that uses the DNS

No information has been released yet on how Microsoft found out about this targeted, undercover exploit and what was compromised – maybe they saw the vulnerability for sale out in hacker land, but there could be some very unhappy security departments out there that aren’t talking about this publicly!

And the auditors should be asking questions – how does your organization know this couldn’t have happened to you, that it didn’t happen, that it didn’t compromise regulated environments.

I find this to be a very significant advisory because it demonstrates some important concepts my colleagues and I have been writing about

• Risk aggregation in Active Directory forests (first written about by us circa 2000) – don’t integrate sensitive environments with a single forest that contains lower surety elements
• Targeted attacks and undercover exploits – this doesn’t look like a worm put out for show, this is going after the money
• The need for a perimeter layer of security (network IDS and firewall traffic control) to serve as a preventive or detective control for vulnerable hosts that perform critical functions
  

No patch yet. The workaround is to lock down the RPC port on the host (so it can’t be managed remotely) and/or through firewalls (so the RPC port is blocked). The trouble is, organizations actually need to be able remotely manage DNS and other things on the DC. They can shut remote management down temporarily while waiting for the patch, but the longer they have to wait, the more painful this get for network and security support.

Organizations that have implemented what we call a “control zone” – where domain controllers and other sensitive infrastructure are firewall protected so the ports used for remote management are either blocked (if unneeded) or restricted to authorized IP addresses or IPSec authenticated hosts. Microsoft has provided some documentation on how to run domains and forests within firewalls by tunneling DC to DC traffic through IPSec http://www.microsoft.com/downloads/thankyou.aspx?familyId=c2ef3846-43f0-4caf-9767-a9166368434e&displayLang=en but I haven’t reviewed this in depth yet. There is also some good information in the blog entry http://blogs.zdnet.com/Ou/?p=469.

Finally, I want to say that these kinds of exploits can happen to any operating system. Microsoft is to be commended for its responsible disclosure of the problem so that organizations can undertake workarounds. Microsoft also warned about risk aggregation years ago when identified that the domain is not a security boundary when included in a forest. But many customers still persist in creating large forests, not protecting their control zone and may be including things in the forest that they shouldn't.

Appalacian Identity Management at Myspace

What do you think about when you hear the word Appalachia? Beautiful mountains and trails? Poor, inbred communities? Its all there. And weirdly, it all relates to this blog entry. Sort of.

This post is actually about poor (shall we say, inbred?) identity management on Myspace.com. But it starts on the Appalachian trail.

My cousin's son Mason is taking the summer off to hike the Appalachian trail. As I write, he and his friend "Swamp Yankee" are somewhere in Tennessee. They are posting accounts of their travels whenever they reach a suitably high peak or civilized valley boasting cell phone signal. The trail is beautiful, but what they find most interesting about the hike is the community of people out there. (Isn't it great how everything always comes back to people, to identity?)

Mason's posts are on myspace.com/skhikers - another strange community. To send Mason a message, my wife (Ginny) had to join myspace too. But when she typed in her email address, myspace said somebody already had it! Her proprietary instincts aroused, Ginny clicked on "forgot password" and sure enough myspace sent the password. Ginny used it to login and found she had become "Amanda" - a Pennsylvania girl with a lot of rapper talk in her profile.


Amanda's gone now. Ginny took control of the account keyed on her email address. Fortunately, the account had hardly been used and there was only one friend named "Tom" (who seems to be everyone's friend.) Most likely Amanda forgot her password and could never get it back because she had (accidentally?) misappropriated Ginny's email address and could not successfully invoke "forgot password." But it could have been much worse. There could have been a lot of information there, and ethical vagueness about who owns the account and what should happen to it.

The real fault lies with Myspace's inbred identity management, and this could have turned out worse. Myspace has failed to fully protect the identity and privacy of their customers.
I know because I also created an account with Myspace. While I did get email from myspace, they do not verify that had access to the email address I claimed.

Myspace has already been ravaged by the Samy worm, and judging by the quality of its identity management, there are more problems ahead before that community gets out of the woods.

Haiti, Urns, and Non-Quantifiable Risks

I've been too busy to post lately because I went on a mission trip with our church to Haiti. They was a fantastic experience, so I started another blog about it at http://global-mission-trips.blogspot.com. Please check it out and let me know what you think!



There are definite lessons from the security perspective, though. It is no secret to professionals in the field that we tend to over-estimate the risks of what is unfamiliar and novel, and under-estimate other risks.

Concerning Haiti, much has been sensationalized in the press about gang kidnappings. However, our mission group drove all over and almost everyone was friendly and there were no gangs in sight. In fact, the UN and the police have been cracking down on the gangs, with some success. We definitely worried about the risk way too much.

At the same time, I kept emphasizing to our group that we should not get complacent. Everyone was starting to relax as we kept going places and nothing happened. For example, one day we got lost and were driving through unnamed alleys and streets, rocky dirt roads, the driver didn't speak English, was lost, we had no interpreter and though this wasn't a bad area, it wasn't far from one. I took our team leader to task, insisting that we must always take "reasonable and prudent measures."


I told the group Bob Blakley's story about the Fallacy of Induction, that he wrote about in his Burton Group report "Managing Non-Quantifiable Risks." Imagine that you have an urn and are told it is full of red marbles and blue marbles. You can draw one marble at a time out of the urn; blue marbles are good but red marbles are very, very bad. And you can't see into the urn, so you don't know if it is full of one color marble, or mixed and what the proportions are and if they random or how they are distributed.

So, you could draw a long string of blue marbles and go on without a care in the world, let your guard down, and then draw a red marble. Oops! So let's not let familiarity make us complacent.
There could even be an evil child sitting above the urn, watching someone draw blue marbles, and waiting for the perfect time to drop a red marble on you. Kidnap risk, insider IT risk, and even some external hacker risks could be like that enigmatic urn.

Well, I didn't talk about security the whole time on the mission trip. We did a lot of good work, putting solar panels and water pumps into a combined church, clinic and school. And it was great trip. I'm still writing all about it at global-mission-trips.blogspot.com.

Peace,
Dan

Honey, can I have your SSN?

Interesting article today in the Washington Post by Sara Kehaulani Goo called "Dinner, Movie -- and a Background Check -- for Online Daters."

I'm one of the 31% of Americans that the article says personally know someone who is using online dating services, and for the single guy I know, one of these services has worked very well for years. If I were in his situation I'd use such sites. Still, there's a downside to online dating if you get hooked up with certain kinds of criminals or fall in love with a supposedly single person whose actually married.

In Sara's article we can see a microcosm of identity and privacy issues - authentication, background checks, reputation services, privacy and more. In particular, some of the sites are starting to offer

- criminal background checks
- verification of marital status
- double blind phone numbers for talking with a person anonymously

Third party sites of course also offer these and other services. For example, while I haven't heard of an online dating site that offers a reputation service yet, there is one called dontdatehimgirl.com where "girls" can report serial cheating and other misdeeds of the miscreant, or why not just assassinate someone's character?

This is not a reputation service in the sense of ebay or amazon, of course. Probably wouldn't want to date someone with the reputation "99.6 satisfied - feedback from 964,551 users..."

Then I suppose SSN is not enough - gold diggers could pay extra to get someone's credit score.

Anyway, it was an interesting article. Check it out at http://www.washingtonpost.com/wp-dyn/content/article/2007/01/27/AR2007012701210.html

During International Information Integrity Institute (I4’s) most recent meeting last year, Donn Parker gave his perspective on the organization’s history and why it was founded.

Donn B. Parker is a retired (1997) senior management consultant from SRI International in Menlo Park, California who has specialized in information security and computer crime. He has written numerous books, papers, articles, and reports in his specialty based on interviews of over 200 computer criminals and reviews of the security of many large corporations. The Information Security Magazine identified him as one of the five top Infosecurity Pioneers (1998).

Perhaps his lasting achievement was to form I-4. I-4 (http://i4online.com) is an information sharing organization whose members comprise CISOs, CSOs and other senior security managers from corporate, government and academic organizations. I-4 has been around since 1986 to keep its members aware of the most advanced information security concepts and controls.

Donn saw the need for information sharing in the security field early on. Donn does not believe in risk assessment, but recommends doing due diligence by benchmarking, which can be facilitated by information sharing in groups like I-4. While I don’t see eye to eye with Donn on risk management, I do agree on the need for information sharing, for neither risk management nor any other information security program can be conducted in a vacuum.

Information sharing requires trust. There are many things that should not be revealed in surveys or public conferences, and yet information security practitioners desperately need to hear the real score from their peers.

Close knit law enforcement and military communities have had such trust. This trust often extended (and still extends) into industrial and other corporate physical security departments, often run by retirees from the law enforcement and military communities. But information security is still a relatively new field, at least when computers are involved, and close knit networks of interpersonal trust are few and far between.

It was for these reasons that Donn Parker and kindred spirits founded I-4. After a long incubation in SRI, they eventually documented 82 controls, which ultimately fed into the UK’s BS7799 which in turn evolved into ISO 17799 and ISO 27001. I-4 went into one of its heydays and eventually capped its membership at 75 so as to keep the sense of trust and confidentially. There was even a waiting list for new members at that point.

Through the dotcom bubble and the downturn and intervening recessions I-4 has survived. Don Parker and Bruce Baker retired, and eventually John Thurlow took over, and now Jim Wade is the Executive Director for the organization. Loyal administrative assistants and members have carried I-4 through a number of transitions of the supporting company that provides conference and logistics support (these companies have had colorful names such as Atomic Tangerine, RedSiren and lately GeTronics).

Fast forward to today – the good news is there’s no waiting list for I-4 currently. I recommend it – there are great people there, excellent conferences with everything under NDA and no vendor marketing, and a relatively small investment required for participation. Security professionals can pretty much get out of I-4 what they put into it, that’s the way information sharing works. They have a meeting on February 12-15 in Monterrey. Its not too late to plan to attend, if you are interested, you can contact their web site, or myself I suppose.

At the end of the Donn’s speech, Jim Wade brought up Donn’s wife – the “power behind the bald eagle.” What a moment! We could all wish for such a rich professional legacy…

Security 2.0? No, Symantec 2.0? Maybe

Vendors will try anything to get attention, so I suppose one shouldn't be surprised that Symantec keeps pressing forward with a strange term like Security 2.0.

According to CIO Magazine, http://www.cio-today.com/story.xhtml?story_id=1230048NUQOC&nl=5, Symantec chairman and CEO John Thompson laid out his company's Security 2.0 vision, which he said is less about locking down the physical network perimeter and more about protecting digital collaboration and transactions.

Well, ok. But then Thompson went on to say that problem of worms and viruses is largely solved…That's strange – there's a huge divergence between what Symantec’s own threat reports say and what their executive marketing pitch now is. Perhaps Symantec is worried that another vendor will move to the "forefront" of the anti-malware market (this was a pun on Microsoft's upcoming anti-virus offering in mid 2007).

But its dead wrong to say malware is diminishing. In fact, its just changing. While it is true that viruses and worms have less impact than they did at their apex in the early 2000s, the breadth of spyware, Trojan horse programs, spam and web attacks (many targeted, or “low and slow”) has greatly expanded to more than fill the gap, anti-malware solutions remain inadequate, and most organizations still very worried. Also, recent attacks on MySpace and Second Life demonstrate once again that worms and viruses will resurface for each new computing environment.

It would be nice to see Symantec easing off the FUD gas pedal, if they weren’t stepping on the hype pedal with the other foot.

For if Security 2.0 is a takeoff of Web 2.0, that’s not much of a launching pad. Web 2.0 is an ill-defined term that means different things to different people. And as for security, we’ve doing it since the dawn of human civilization. The more we invent, the more things stay the same. So its not as if we should draw a line under everything heretofore and start over with Security 2.0.

Even if there is no Security 2.0, there may be a Symantec 2.0. They are fielding new products and services such as database audit software, data leakage detection, and message content filtering. They later plan archiving tools to categorize and index data from e-mail and instant messaging, and an analysis tool called Discovery Accelerator for administrators to mine archived messages for legal discovery or evidence gathering.

The substance of this is all very interesting, but Symantec might have named it better. Its not Security 2.0, but it is progress.

Is KBA a Solution or a Problem?

Is KBA (Knowledge based authentication) a solution or a problem?

Depending on how it is implemented, KBA can be either.

There follows a slightly edited transcript about knowledge based authentication (KBA) that you may find illuminating. I'll bottom line it....at the bottom!

------------ original question

"I just got off the phone with [client]. They wanted to speak about password resets for access to [database] which is protected customer [data]. They’re regulated on improper access to this data and the issue has become higher profile at the company since the HP Board of Directors pretexting scandal.

We had a good call and I was able to answer all of their questions except this one: What kinds of proofing questions are asked in audited password reset scenarios to protect valued data?

We discussed alternatives to automated reset on the site for higher assurance (such as a phone call from the registered device of record, speaking to a human, out of band via USPS, etc.) We also discussed closing the control and audit loop through notification of access/change (via phone, email, or USPS) – so this is really just a question about the questions.

Specifically how many questions is a good threshold and what kinds of questions should be used?

Suggestions were:

SSN
Mother’s Maiden Name
Street grew up
City born in
Favorite color, movie, book
Pet’s name

Do we have any information on this? Know of any good references towards research I can point them to?

Thanks!
D."

------------ First reply

I replied to this first

I don't like these questions personally or professionally.

It feels I'm being asked to give out still more personal information in order to protect my personal informationl. What's wrong with this picture?

I recommend letting the user define the questions and answers, and advising the user to put in something and completely valueless that he/she can easily remmeber, but never to user the same one twice at any site and not to put any personal information into the q/a. And then protect it as senstitive informatoin anyway.

Dan

----------- Reply 2

And then my reply was skewered by the following comment...

…and then write down all of the questions and answers so that you have some idea how to answer all of the questions….and then keep that list with your computer for easy reference…..

E.

E. is quite correct, when I use the personal whimsical stuff I usually have forgotten months later - what was I thinking! (or what was the syntax!). Anyway I do write it down...but then I sometimes lose the lists. I think I have a better system now but can say no more for reasons of personal security :-)

------------- Reply 3

More commentary follows.

"SSN and mother’s maiden name are two of my pet peeves – these in particular should never be included in the list. I’ve been suggesting using voice biometric authentication to sidestep this whole issue of self service question and answer content

G."

This may just be a good idea. If the voice matching software works, scales, and the users all have microphones everywhere they go, attacks on this might be relatively difficult...

But wait -

----------------- Reply 4

"All of which is precisely why my recommendation is that the business should use information which it already has (e.g. recent bill amount, etc...) - so that it’s not digging for more information and it’s not requiring you to make up something which will be hard to remember.

B."

----------------- Reply 5

M. agrees and provides a good bottom line to the whole issue

"Ultimately, the quantity and nature of KBA questions are like password construction rules – interesting, but maybe have little value from a security perspective. The answers may be easily guessed and administratively known. Applications requiring lower identity assurance may be well-matched with KBA, though.

For applications requiring higher identity assurance, dynamic KBA (non-administratively known questions like last deposit amount in bank account) and OOB identity proofing are better.

M."

OOB = out of band. I think M. means that at this point the password reset (or other) system would go to 3rd party to proof the user's identity. This third party could be a credit bureau or some service plugged into credit bureaus, for example. More expensive but perhaps the only option if the site is not itself a bank with lots of transaction history on the user...

Bottom line
- KBA as often implemented with mother's maiden name is a joke
- KBA that digs deeper into less obvious (but still guessable) personal information is slightly better but creates privacy problems
- KBA with voice authentication may be a good idea, but there are problems with it, and the group didn't come to consensus
- Using administratively known information like recent transactions seems to be the safest approach