Recently in security Category

According to The Register, the UK police have increased the exercise of the power that allows them to compel the revealing of crypto keys. That fancy duress key you put on your truecrypt volume is only good for earning you jail time. I've mentioned this before, but crypto is vulnerable at the end-points. If the Government can point a loaded law at you to force you to reveal your keys, the strength of your convictions, not your crypto, is what is being tested. Perhaps that 2-5 year prison term is worth it. Or maybe not.

I take heart that a majority of those served with the demand notice have refused. But we still don't quite know what'll happen to them.

This is harder to pull off in the US thanks to the 5th amendment, but there is nothing stopping this kind of thing off our shores. Or heck, at our borders.

Today I'm spending most of it sheepdogging a vendor installing an application. This vendor is VPNing in, and such access is a key part of the product's support contract.

This is something I've noticed recently. Several of the server-based off the shelf apps I've installed lately have had a requirement that the vendor have access to the server in some way. Some of it is so they can do the install. Some of it is so they can update it so we don't have to. Some of it is just in case we ever call for support and need their help.

I have a theory for why this is. I have a sneaking suspicion that its because that's how these vendors support installs in environments where the sysadmin is a desktop person who got handed a server and was asked, "make it work." This kind of vendor-based hand-holding makes the ongoing maintenance of applications lower on the client side of the equation, which can lead to more sales. But, I'm not sure if that's it or not.

This is causing some grumbling in the ranks, since it means untrusted parties have to be allowed to log in to servers in the domain. Before this recent spate of applications, vendors demanding such access had their apps relegated to servers not in the domain at all. This doesn't work when the app requires domain access. Console access to servers is a sensitive thing for us, so we don't like to hand it out on demand to vendors.

Especially when we weren't involved in the purchase process to begin with. Many a time we've been told:

Client: We spent umpty thousand dollars on this ap. Install it.
Us: *reads install document, cringes* They need Administrator access to the whole box and a tunnel into the inner Banner fortress. I don't want to.
Client: What part of umpty thousand dollars don't you understand? Make it work.
Us to Management: Insecure! Violates best practices!
Management to Us: It's too late to get a refund, and upper management was involved in the decision. Make it work.
Us: Wilco.

Or words to that effect.

Ahem.

How are y'all handling this kind of thing, presuming you're also seeing it and it isn't just me getting lucky.

This question came up, and it got a long response out of me.

Question:

Taking in mind that being a a deterministic machine a today computer is incapable of producing random sequences and all computer-generated "random" sequences are pseudo-random actually, aren't computer-generated random passwords insecure? Isn't it more secure to just press keys randomly to create a random password than to use a digital generation algorithm?

The idea behind this question is sound, since deterministic processes return consistent results, password generators do not return random passwords and are therefore not good (or in the words of this poster, insecure). Unfortunately, it shows a lack of awareness of just what constitutes a good password.

Good passwords come in many flavors. Passwords that humans never have to type (such as those attached to batch processes) can be much more complex and long than the kind humans have to memorize. Also, if you're dealing with a character limit on passwords, a good password on such systems will look different than good passwords on other systems that lack a limit on size.

Over the years we've learned what a good password looks like:

• Long enough to make randomized guessing non-viable.
• Have enough entropy to make each character significantly non-dependent on other characters in the password.
• Able to be memorized.

There are also system-specific variables for what constitutes a good password.

• For systems with 8-character limits on passwords (old crypt-based *nix password systems), high entropy is required.
• For systems with well known methods of attacking passwords below a certain length (LanMan, NTLM, but not NTLMv2) high length is required.

In basic, length increases the number of possible passwords that have to be brute-force checked, and entropy increases the number of passwords that have to be checked at a certain length. Perfect entropy (i.e. completely random) of course maximizes the number of passwords that have to be brute forced at any given length. Unfortunately, perfect entropy always fails the memorization test of 'good password' for password lengths much above 7.

Which is a long way of saying that perfect entropy is not required to have a good password. In fact, if your password needs to be used on a system with known attacks for short passwords (Windows) length is more important since most normal humans can't memorize 16+ character passwords of four-character-set random characters. Especially if password rotation is in force so they have to do it a couple times a year.

And a final point about the determinism of generated passwords. A deterministic process can't introduce more entropy that it received as an input, this is true. When generating a 40 character password, a password generator can use a smaller amount of truly random bits (thank you /dev/random) to generate a password. The amount of entropy in this password will never exceed the number of bits that were pulled from the random source so long as an attacker knows what algorithm generated the password. If an attacker doesn't know what algorithm was used to generate a password, then the dependency of one character on another is unknown so the password will have high apparent randomness. This is called pseudo-randomness, and is how /dev/urandom and most hashing algorithms work.

Since perfect entropy is not required to generate a good password, deterministic password generators can produce perfectly fine passwords. So long as they have a good source of entropy to seed their processes with.

Over half a year ago I mentioned that I was going to write up a script that sucks down Windows security log info and deposits the summarized data into a database. That script has been pretty much done for several months now, and the data is finally getting some attention on campus. And with attention comes...

...feature requests.

It's good to have them, but tricky to deal with. There is a quirk in how these logs are gathered and how Microsoft records the data.

• Login events record the User and the IP address the request came from. The machine they're logging into is the Domain Controller in this case.
  
• Account Lockout events record the machine that performed the lockout. This would be things like their workstation, or the Outlook Web Access servers.

Since we use DHCP on campus, the Machine : IP association is not static. Our desktop support users like having machine name wherever possible, with machine name AND IP being preferred. This will prove tricky to provide. What doesn't help is that a lot of login events come from IPs that trace to our hardware load-balancers, which generally means a login via LDAP by way of our single-sign-on product (CAS). That's not a domained machine, obviously.

There are a couple of ways to solve this problem, but none of them are terribly good.

• During event-parse, use WMI to query the IP address to find out what it thinks it is. Should work fast for domained machines, but will be horribly slow for undomained machines.
• Use a reverse IP lookup. Except for the fact that we use BIND for our reverse-DNS records so we'll get a lot of useless dhcp134-bh.bh.wwu.edu style addresses that won't correspond to the 'machine login' events I'm already tracking.
  
• Do DB queries to find out which machine logged in with that IP address most recently and use that. But all those lookups will HORRIBLY slow down parsing, even if I keep a lookup table during the parsing run.
  

Slowing down parsing is not a good thing, since we chew between 70K-300K events every 15 minutes during busy periods. Even small efficiency dings can be horribly magnified in such an environment.

Nope, looks like the best solution here is to make the IP address a clickable link that leads to another query that'll populate with the most recent machines to hold that IP address. If any show up at all.

I wonder what they'll ask for next?

One of the more annoying problems with password and account-lockout policies in Active Directory has been that they apply to every account universally. I you want to force your users to change passwords every 90 days, with account lockout after a certain number of bad login attempts, then the same policies apply to your 'Administrator' user. Account lock-out was a really great way to DoS yourself in really critical ways.

In a way, that's what account-lockout is all about. It's to keep bad people from coming in, but its also a way for bad people from preventing legitimate people from using their own accounts. You need to take the good with the bad.

Since we were a NetWare shot for y-e-a-r-s we're very used to Intruder Lockout (ILO), and losing it during the move to Windows was seen as a loss of a key security feature. We had accounts that had to be exempted from lockout, which was dead easy in eDirectory but very difficult in AD.

Happily, Server 2008 introduces a way to do this. It's called "Fine-Grained Password Policy", and is NOT group-policy based. This was somewhat surprising. Getting this requires raising the domain and forest functional levels to the 2008 level. What it allows is setting password policy based on group memberships, with conflict resolution handled by a priority setting on the policy itself. Interestingly, the actual policies are created through ASDI Edit, so they're not beginner-friendly.

For instance, we can set a 'lock out after 6 tries in 30 minutes' setting to the Domain Users group at a Priority of 30, and a second 'never lock out ever' policy to the Domain Admins group at a Priority of 20. That way 'Administrator' will have the never-lock policy apply to it, but Joe User will have the lock-after-6-in-30 policy apply. This works best if the password policy specifies that Domain Admins need to have very complex and long passwords, which makes a brute-force cracking attempt take unreasonably long amounts of time.

We put this in place a few weeks ago, and it is working as we expected. SO GLAD to have this.

My thoughts on this quote:

Theoretical risks and real risks are generally the same thing when you're talking about IT security.

In large part, this is correct. Especially when getting audited. We have regular audits here, both internal and external. We have servers that handle credit-card data, so we have to deal with PCI compliance as well. So yeah, we know about this. We're also familiar with the debate.

In order to get our PCI stuff certified we have to have security scans performed against our credit-card processing servers. In order to do this, we grant a specified IP address full and unrestricted access to an internal IP list. The third party then scans that from wherever they are, and sends us the report full of red Xes.

The internal debate goes like this. I'm not naming names for obvious reasons. I like my job.

Tech: Why do we have to let them in to scan? That's, like, completely bypassing the security provided by our firewall. Both firewalls. It's not like a regular hacker has that kind of access. These servers can not normally be reached from the internet at all! They should be scanning THAT!

Manager: Because that's what the PCI standard says they have to do.

Tech:  It makes no sense!

The reason for this is because they're testing how vulnerable we are if our other servers get hacked and they have enhanced access to that subnet. That's also very unlikely in our case (see also: two firewalls), but the fact remains that it still has to be checked. Because we've never been attacked that way (that we know of), that kind of attack is seen as theoretical rather than real.

All it takes is one attacker, or a group of attackers, to REALLY WANT SOMETHING for theoretical attacks to become real. The concerted attacker, as opposed to the casual attacker, is the one that'll employ novel methods of getting what they want. Door-rattlers looking for phat pipes for their warez repos are looking for any fat pipes they can find and the resources they expend per target are pretty small. Someone looking to break in for a specific reason is targeting us specifically, and the resources they'll expend to get it is a LOT higher.

It is the concerted attacker that'll spend the time to worm their way from internet-facing systems, to intranet-facing systems, to get to secure-net facing systems. It is this kind of attacker that'll do targeted phishing against user most likely to have inner-firewall access of some kind and then attempt to create VPN sessions with those credentials to do scanning from a far more advantageous network position. It is the concerted attacker that'll do targeted DNS hijacks in order to get better information. These are not the kinds of things that Joe Warezer or Ben BotHerder are going to bother with.

It is also true that the concerted attacker can be vastly more damaging than their younger cousin who is just looking to leech resources or reputation. So yeah, it's a very low likelihood of running into that kind of threat, but the risks of not doing something about it are pretty high. That's what makes the theoretical real. 

This past weekend I got into a pretty long discussion about privacy, governmental, corporate, and criminal tracking of everything you do (Big/Little/Silent brother), and such related topics. It was good debate. One of 'em was an actual lawyer versed in these issues who works for a library-related non-profit. How cool is that? Working as I do for a liberal institution of higher ed we do value our individuality and right to express same.

Big Brother. We know this one, Orwell told us all about it in his book 1984. Governmental tracking of people for their own safety.

LIttle Brother. A more recent development, but private-sector tracking of people for reasons relating to profit. Your browsing habits are being tracked by the ad agencies. That kind of thing.

Silent Brother. A term I came up with, but it's obvious enough I wouldn't be surprised to learn someone else came up with it too. Criminal tracking of everything you do for reasons of illicit profit. Russian crime gangs specializing in identity theft.

Now thats out of the way, some nitty gritty. Under the fold.

Worst-case thinking is something that Sysadmins are kind of prone to. We all know what level of disaster would cause us to lose everything, and it's not a good feeling. At my last job I was asked once what my worst-case scenario was. And it was a truck-bomb in the wrong spot that would cause our datacenter to suddenly drop a few floors, as well as do serious damage to most of our offices (and note, this was asked AFTER 9/11).

Fixing that was easy, don't allow traffic on that road. But that wasn't an option for us. So we just lived with it.

Having been around enough people worrying about this, the thinking goes that if we mitigate the worst-case we also mitigate the bad-cases too. Let's take a look at this, shall we?

If we HAD been able to stop traffic on that road, it would have done nothing for certain other just as costly incidents. A direct hit by a tornado would render the building structurally uncertain for a week or two as the engineers assessed its soundness, and that would cost us quite a lot thank you. A sprinkler release on the floor above the datacenter could cause water to fall into the datacenter, which would be bad. A fire on the same floor as the DC would cause a sprinkler release in the datacenter (no FM-200 system there!) and short a bunch of stuff out. None of this would have been mitigated by stopping traffic on that one road.

WWU is the kind of enterprise where physical presence is required for most of our business. The kind of disaster that would limit our ability to teach while not also affecting our classrooms themselves limits the kind of disaster to plan for. As it happens, cutting two fiber runs would stop most network-based instruction, so that's the disaster we plan for. This building sinking into the bog it was built on is... a dark fantasy, and only likely in the kind of earthquake that'd also do serious damage to campus itself.

So yes. Good risk-management involves looking at the probable risks, not the worst-case risks and hoping good overall coverage inherits from that.

I've been reading up on Active Directory read-only domain controllers (RODC), new in Server 2008. When I first glanced at them, they looked an awful lot like NDS read-only replicas which have been around since the advent of NetWare 4.0 too many years ago. Novell put r/o replicas into NDS in large part for complete X.500 compliance. However, their real use case was never made clear. The only case I could ever come up with is a kind of disaster-recovery site, where that R/O replica could be promoted to a R/W replica in an emergency. So why was Microsoft finally putting the last X.500 piece in now?

Turns out, it wasn't X.500, it was to solve a somewhat intractable problem with Active Directory domains; the satellite office problem. The Small Business Development Center is a part of the College of Business Education, and actually offices in downtown Bellingham. Before they got a reliable WAN connection to campus, they needed to be able to work when their internet connection was down. What we did was put all of those users into a single OU, made that OU a partition in eDirectory, and gave their NetWare server a copy of that replica. That way, only those security principles were ever at threat, and they could still log in and use resources local to them when their WAN link was down.

The same problem with AD is much trickier to solve, since you can't partition the AD database that way. You really had three options:

1. Tell the users to live with the outage.
2. Put a Domain Controller down there.
3. Declare the site a new Domain in the forest and put Domain Controllers down there.
   

Putting a DC down there meant that the site would have a full copy of your entire authentication database, which can represent a major security vulnerability if the site lacks any way to truly secure the DC's physical existence. AD Sites allow for more efficient use of WAN resources, but that doesn't change the fact that a full and complete copy of the domain was hosted there.

A Read-Only Domain Controller is NOT a full copy of the domain; it does not contain any passwords by default. Unlike a R/O NDS replica, users can actually authenticate against it; the server proxies the authentication against a normal DC if it can find one. You can set a password-caching policy to tell it which passwords to keep local copies of, so branch-local users can still log in when the WAN is down. That's... not useless You're still having to keep the entire AD database down there complete with GPO SYSVOL goodness and all those groups, but at least if thieves run off with the RODC they'll only fully compromise local users.

It still isn't as robust as how eDirectory handles it, but at least it's a lot better than it used to be. Especially if politics prevent you from being able to declare a new domain.

ArsTechnica had a nice write-up regarding a recently uncovered hardware device that facilitated man-in-the-middle attacks for SSL. The fact that this is possible is nothing new. The fact that it now exist in hardware seemingly is.

While the article focuses on the government spying angle, this exact same thing applies to corporate spying. For the sake of example, presume I'm working in an identical role in EvilCorp. EvilCorp does what quite a lot of corporate America does and restricts employee access to the internet. They take it to the extra step of attempting to stop 'information leaks' of proprietary documents. While systems to do this for SMTP-based email are commonly available, blocking webmail access is another issue. One option is to subscribe to a webmail block-list that update your filtering appliance with sites to block users from. Another option is to allow them to access it, but be sure they're not selling you out to MoreEvilCorp.

To do this, you need a mandatory HTTP proxy. Dead easy to implement in the modern network. Second, you need access to a Certificate Authority trusted by your peons. If you're running Active Directory (and really, what self-respecting EvilCorp wouldn't?) then you have a trusted CA built into your infrastructure. Third, you need a software package (or maybe a, say, hardware appliance) that'll generate a certificate signed by your own CA to gmail.com, talk SSL to the client, and then create an SSL session with the real gmail.com, allowing you to sniff their personal email free of that dreadful encryption.

This appliance sounds like an all-in-one hardware appliance designed to do exactly what a lot of Companies would really like to start doing. And what's good for Corporate spying is good for the spooks (for whom it is more likely to be illegal).