Recently in security Category

I've wondered why IPSec VPNs do that for a while, but hadn't taken the time to figure out why that is. I recently took the time.

The major reason comes down to one very big problem: NAT traversal.

When IPSec VPNs came out originally, I remember there being many problems with the NAT gateways most houses (and hotels) had. It eventually cleared up but I didn't pay attention; it wasn't a problem that was in my area of responsibility, so I didn't do any troubleshooting for it.

There are three problems IPSec VPNs encounter with NAT gateways. One is intrinsic to NAT, the other two are specific to some implementations of NAT.

1. IPv4 IPSec traffic uses IP Protocol 50, which is neither TCP (proto 6) or UDP (proto 17), and protocol 50 uses no ports on the packet. Therefore, a VPN concentrator can only support a single VPN client behind a specific NAT gateway. This can be a problem if four people from the same company are staying in the same hotel for a conference.
2. IPv4 IPSec traffic uses IP Protocol 50, which is neither TCP or UDP. Some NAT gateways drop anything that isn't TCP or UDP, which will be a problem for IPSec VPNs.
   
3. NAT gateways rewrite certain headers and play games with packet checksums, which IPSec doesn't like. So if IPSec is going to tunnel via TCP or UDP, there will be issues.

These are some of the reasons SSL VPNs became popular.

This is where RFC 3751 comes in. It's titled, "IPsec-Network Address Translation (NAT) Compatibility Requirements" oddly enough. It turns out that packet checksums are not required for IPv4 UDP packets, which makes them a natural choice to tunnel an IPSec VPN through a stupid NAT gateway. The VPN concentrator pulls the IPSec packet out of the UDP packet, and thanks to the cryptographic nature of IPSec it already has ways to detect packet corruption and will handle that (and any required retransmits) at the IPSec layer.

Like many olde tyme sysadmins, I look at 'cloud' and shake my head. It's just virtualization the way we've always been doing it, but with yet another abstraction layer on top to automate deploying certain kinds of instances really fast.

However... it's still new to a lot of entities. The concept of an outsourced virtualization plant is very new. For entities that use compliance audits for certain kinds of vendors it is most definitely causing something of a quandary. How much data-assurance do you mandate for such suppliers? What kind of 3rd party audits do you mandate they pass? Lots of questions.

Over on 3 Geeks and a Law Blog, they recently covered this dynamic in a post titled The Inevitable Cloud as it relates to the legal field. In many ways, the Law field shares information handling requirements similar to the Health-Care field, though we don't have HIPPA. We handle highly sensitive information, and who had access to what, when, and what they did with it can be extremely relevant details (it's called spoliation). Because of this, certain firms are very reluctant to go for cloud solutions.

Some of their concerns:

• Who at the outsourcer has access to the data?
  
• What controls exist to document what such people did with the data?
• What guarantees are in place to ensure that any modification is both detectable and auditable?

For an entity like Amazon AWS (a.k.a. Faceless Megacorp) the answer to the first may not be answerable without lots of NDAs being signed. The answers to the second may not even be given by Amazon unless the contract is really big. The answers to the third? How about this nice third-party audit report we have...

The pet disaster for such compliance officers is a user with elevated access deciding to get curious and exploiting a maintenance-only access method to directly access data files or network streams. The ability of an entity to respond to such fears to satisfaction means they can win some big contracts.

However, the costs of such systems are rather high; and as the 3 Geeks point out, not all revenue is profit-making. Firms that insist on end-to-end transport-mode IPSec and universally encrypted local storage all with end-user-only key storage are going to find fewer and fewer entities willing to play ball. A compromise will be made.

---

However, at the other end of the spectrum you have the 3 person law offices of the world and there are a lot more of them out there. These are offices who don't have enough people to bother with a Compliance Officer. They may very well be using dropbox to share files with each other (though possibly TrueCrypted), and are practically guaranteed to be using outsourced email of some kind. These are the firms that are going into the cloud first, pretty much by default. The rest of the market will follow along, though at a remove of some years.

Exciting times.

Microsoft is releasing an out-of-band patch to invalidate two of their Intermediate Certificate Authorities.

http://technet.microsoft.com/en-us/security/advisory/2718704
http://isc.sans.edu/diary/Microsoft+Emergency+Bulletin+Unauthorized+Certificate+used+in+Flame+/13366

In essence, the Flame malware appears to have code signed by a valid MS certificate authority. As this particular malware is suspected to have been written by a "state actor" (a.k.a. cyber-warfare unit for a government), chances are good that this CA is not circulating in the general unseemly underbelly of the Internet. However, it does present a compromise of those certificates, so Microsoft is issuing revocation certificates for them.

The core problem here is that this CA is trusted by all Windows installs by default, and could be used to sign patches or other software. This has obvious problems in the form of valid-seeming software installs, but less obvious ones in that somewhere a state-actor has the ability to perform man-in-the-middle attacks for SSL using valid certificates.

The PKI system was designed around the idea that certificate authorities would occasionally get compromised and does contain mechanisms for handling that. However, those mechanisms are not frequently exercised so the process of issuing such a revocation is, shall we say, not as smooth as it really should be.

You really should apply this patch as soon as it arrives.

This rant is a familiar one to a lot of desktop-facing IT professionals.

Today the person who handles our bank stuff came to me with a problem. The check-scanner wasn't working. I poked around but couldn't make it work, and advised her to talk to the bank since they provided the scanner, the scanner driver, the IE-plugins it worked with, and Windows didn't recognize it as a scanner.

So she did.

Their advice?

You need to turn off Windows Update. Every time it runs it changes things in IE and you have to go through and do a bunch of things to make it work

I gave her the look. Then I remembered myself and redirected the look to a harmless corner until I could speak again. Even getting a piece of that baleful stare caused her to cringe. Oops.

Like all right-thinking Windows admins, I'm a believer in leaving Windows Updates turned on if I'm not doing something else to manage that particular risk. Our fleet of Windows machines is not big enough for me to bother with WSUS (we have a LOT of Mac users), and we most definitely do not do anything like blocking browsing at the border. So, I want those updates thanks.

So I pulled a laptop out of the dead pile. That laptop will now be a dedicated machine for talking to the bank and nothing else. All because our freaking bank can't run secureable software. Makes you question your trust in them, it does.

The other day a Colorado court ordered a defendant to produce the unencrypted contents of their own laptop. This is what I called "rubber hose cryptography", and previously we've heard of efforts in the UK to compel decryption. It has now happened here, and not at the US border. Unlike the UK, this decryption demand in Colorado is not based on a law that specifically says that courts can demand this.

Wired article

The counter-argument is quite clearly the 5th amendment right guaranteeing the ability to not self-incriminate. If that decryption key only exists in your head, and disclosing it would incriminate you, then you don't have to yield the key.

This judge disagreed. I'm not a lawyer, so I can't tell what legal hairs were split to come to this decision. But the fact remains that this judgment stands. The only concession he appears to have made for the defendant is to preclude the prosecution from using the act of disclosure as a 'confession', but the data yielded by the disclosure is still admissible.

Today I had an incident with biometrics that further convinces me that they are not the end-all be-all of security.

Today I had to head up to our datacenter to do some nebulous "things". Like you do. Since we colo at a large facility that has all of those security certifications, getting into it is something of a trial but a familiar one. Hand scans, double-layered man-trap, the whole deal.

Only, the hand-scanner on the cage our racks are in wouldn't read my hand today. It took 19 tries before it decided I was me. To get this far I had to pass four other hand-scaners and only had to re-enter three times along the way. When I went back to the security station to see WTF, they had me re-scan my hand. Leaning over I saw that I had managed to fill their live-log of entry/exit events with red events, and they didn't seem phased in the least.

I've had some trouble with this particular hand-scanner before, enough that I dread leaving the cage. For what ever reason, this particular scanner is far enough out of spec that the fuzzy results it returns are fuzzier than their system will accept. Since it's on a rack cage rather than the higher trafficked man-trap scanners, it hasn't been caught out and re-tuned (or something). But still, I hate that thing.

Five years ago I published the following article:

Strong passwords in a multiple authentication environment.

The key thing I was driving at in that article, a strong password on one system is not a strong one on another system and this can significantly compromise password security if multiple authentication systems are in use, is still very much true.

That article was full of Solaris 8 and NDS. Here in 2011 those are now really old. What has changed since then?

• Old Samba versions that don't support NTLMv2 are now very rare.
• Most modern Samba now includes Kerberos support.
• LM/NTLM requiring Windows installs are now very few and far between.
  
• Linux can now leverage both LDAP and AD for back-end authentication, and such hooks are common and pretty well documented.
• Web-authentication systems (OpenID) are now much more common.
• Application-level auth is much more common and the data it protects much more significant.
  

Because of all of these, password length is beginning to trump password complexity as the surest bet for an uncrackable password. Those 8-character limits of yore are now blessedly rare.

However, some things still haven't changed:

• Older software with embedded authentication still can require older password protocols.
• Some IDM systems force passwords to be command-line safe, which restricts the allowable special-characters that may be used.
• Embedded devices, especially very expensive embedded devices, can require old password protocols long after they've been superseded. 
• The cost of paying off the IT Debt built into some IDM systems can prevent newer authentication systems from being implemented due to simple resource costs, keeping older protocols around longer than is safe.
• Arbitrarily short field-limits in databases that store passwords (16 characters should be good enough for everyone, obviously).
• Developers who decide to write their own authentication systems from scratch rather than hook into something else that's been battle-tested.

So, even now, today, in 2011, the bad decisions of ten years ago, or the hard-to-update technology of ten years ago, can significantly hamper a unified password policy for a multi-authentication system. That hasn't changed. It's all well and good that Linux (which replaced your Solaris installs three years ago) can support 200 character passwords, but that doesn't matter if the custom-built ERP application has 10-character passwords baked into its core.

However, another trend has continued since 2006: web-apps have continued to eat client/server apps for lunch.

With web-apps the option of leveraging different authentication system, or at least providing an abstraction layer to hide the old cruft from view, is possible. Perhaps there is now a web-app in front of the custom-built ERP system, put there so everyone could stop maintaining all of those terminal programs and ease the VPN/home-computer problem (everyone has a browser). That web-app could very well use an alternate authentication source, such as LDAP, and use the LDAP database itself to store the (highly entropic and automatically rotated frequently) authentication tokens needed for the old system.

With a system like that, such an old system can still be protected by an enterprising user who has selected this:

valence NIMBOSE sequestrate absolution [953]

As their passphrase. Four dictionary words, no funny spellings, four character-sets.

Is that a good password? Consider this: The Oxford English Dictionary has over 600,000 words in it. A four-word uncased pass-phrase using random words requires 1.296x10^23 guesses to brute-force, since each position has 600K possibilities. An 8 character mixed case password requires 5.346x10^13 guesses, add in numbers and you rise to 2.815x10^14.

With GPU-based password crackers available now, even salted 8-character passwords are not that good even with fully randomized passwords. This is the march of technology. As has been pointed out, adding ever more random ASCII to a password doesn't scale. Pass phrases? Good things!

But if you restrict the word-set only to words in common usage and exclude words only used in technical settings, the word-set drops precipitously to 20K or less. Even so, a four word uncased password gives an password requiring 1.6x10^17 guesses. Throw in some irregular casing and the total guesses goes up markedly.

Which reminds me, I need to spend some time going over our own developed software for password handling safety. You should to!

"Unless a password generator is just taking raw output from /dev/random, it's using programming logic to determine the password. Programming is deterministic, so password generators are deterministic, and so are the passwords they generate.

Therefore, password generators do not produce good passwords. Q.E.D."

I saw a statement much like that one a while back. The questioner was concerned that programatic password generators were not yielding good passwords, since they were designed with deterministic logic and only took a restricted set of inputs to generate that password.

This is true to a point, but there are limits.

If you have perfect knowledge of how a password generation program works and what it uses for inputs, it is possible to derive correct passwords much faster than true random guessing would suggest. The only entropy in the system is introduced by the inputs. If that input size is (for example) only 8 bits regardless of how large a password is generated, the final password will have no more than 8 bits of entropy. You can create a table of all possible passwords this program can generate.

However, if you don't have perfect knowledge of how the password generation program works, the effective entropy can be much higher for an attacker. The effective entropy will be somewhere between the supplied entropy and the entropy implied by the password length.

So, turn this on it's head.

Take password stores. They take a user-supplied password which can have very bad entropy, perform a generally well known computation on it to get a string (frequently called a hash) that is actually stored. This is seen as effective security, so long as the computation is sufficiently robust and non-reversible. But, robustness is a moving target. MD5 is broken, WEP hashes are so broken as to be nearly cleartext these days, Windows LanMan hashes are very broken, SHA-1 is showing some weaknesses but is still pretty strong.

Password-derivation attacks focusing on automatically generated passwords are perhaps most effective when used against systems known to use generated passwords that users will actually keep. Unless they have something like OnePassword end-users will immediately change passwords that are 16 characters of random typeable-ASCII, but may keep something like, "shoes376emotional". The techniques for defending against password-guessing attacks are well known:

• Limit the rate the system will accept login attempts for user accounts (increase the time required to guess the password)
  
• Limit the number of times a login can fail before locking the account from further login attempts (increase the time required to guess the password)
  
• Force periodic password changes (move the target faster than password-guessing could find the password)
• Prevent stations with lots of bad login attempts from further access to the login process (force the attackers to use multiple stations)

No matter how you slice it, even with perfect knowledge of the password-generator an attacker is still going to have to grind through a lot of passwords to find the one that works. They'll be able to find it faster than the char-sets used in the password would suggest, but still need to plow through thousands of attempts. Most of the above methods have been baked into things like Active Directory for a very long time. The same can't be said for bespoke website authentication services.

Using a well known poorly designed password generation system that spits out passwords end-users are likely to continue using means that you need to move the goal-posts (force regular password changes) more often in order to prevent brute-force intrusions. Unless you're also supplying generated passwords for those changed passwords (I've never heard of such a system, but I suppose they could exist) the changed passwords are likely to be something slightly different ("shoes#&^emotional") to completely different than the ones the generator would spit out, which further reduces the likelihood of a successful password-guessing attack.

The biggest vulnerability presented by poorly designed password generation systems are for systems that:

• Don't rate-limit login attempts
• Don't lock-out accounts after a certain number of bad login attempts
• Don't force password changes
• Don't do any kind of IP-reputation lockouts after repeated bad logins

A lot of built-from-scratch web authentication systems don't do any of the above four points, instead they focus on keeping the password hashes secure and having a password-recovery option for people who forget their passwords. Putting an insufficiently entropic password generator on top of it compounds the bad idea.

Can password-generators produce good passwords?

They absolutely can produce cryptographically good ones (a simple one: draw 8 bytes from /dev/random, get the sha1 hash of those bytes, convert the first 16 bytes of the hash to UTF-8, rerun bytes that don't translate, bam! Good 16-character password). Producing good passwords that users will be able to remember is another much more complex problem.

Are bad password generators unusable?

Since bad is relative, it depends. Such poor generators could be sufficient for producing short-term temporary passwords, which limits their vulnerability window. Usable, but only intelligently.

XKCD hit this one on the head. I'm sure nearly all of you read it, but for those that don't...



Spot, freaking, on. As I said, it isn't anything I haven't mentioned before.But nice to see in graphical format.

This specific case is for a "plausible attack on a weak remote web service," which is a different case than cracking stolen password hashes, but one that's a lot easier to carry off. Find a web-login system that doesn't rate-limit or lockout, and you can keep grinding on it until you get through. Length trumps complexity.

However...

If you have intelligence that the target's password method is 3-5 common dictionary words, that problem is a lot easier to crack than "random string of lower-case alpha characters ranging from 16 to 70 characters in length". Still, it'll take a while. And for the remote attacker grinding on "admin", probably not a safe assumption.

A question was posted to ServerFault yesterday that raised ALL of our eyebrows.

Our security auditor is an idiot, how do I give him the information he wants?

The asker is not wrong. Really, go read the question. Any security auditor asking for a complete list of passwords, in plain-text, has got a few screws loose. The asker is understandably hiding their identity, though it has become clear that they are in the UK somewhere. The answers are high quality, and I recommend reading them.

Yes, this is something that System Administrators have to put up with from time to time.

• I have been told to do something against all good understanding of best practice, and may be possibly illegal.
• I have complained, and been told by higher authority to put up or shut up.
• Now what?

In the industry, if your boss is an (potentially criminal) idiot, and you can't change their mind, it is time to change the boss. Not everyone has that luxury though, especially in this economy, so sometimes you have to stick with it. That's the hard part.

The "fix" for this particular case is the same as the "fix" for being asked to troubleshoot a faulting legacy system you'd been studiously ignoring because it privately scares you. Hold your nose, get educated about the system, and start making some reasoned arguments/guesses about what may be the problem. The answers on that question provide the education and troubleshooting guidance for dealing with the, "my security auditor is defective," problem.

This person is in a very sticky situation. They are being asked to do something that is very likely illegal in their area and it seems like this is a serious request rather than a subtle test of some kind. And worse, their business management has bought in (see second comment on the question, you'll have to expand the comments to see it). If they do everything they can to convince business management that this is not only stupid, but potentially criminal, and management still presses ahead, they'll get to one of the hardest decisions to make in our line of work.

• Do I quietly go along with this, having done everything I can to dissuade them?
• Do I report this action to the authorities and be a whistle blower?
• Do I point management at this as-yet-unlinked-to-the-company tempest-in-an-Internet as last ditch supporting evidence of the flagrant stupidity of these actions?
• Do I resign my position and become employed elsewhere rather than do these actions?
  

Each of the above has their own consequences. The first point may end up with your butt on the line if the issue ever does get brought up legally. The second one will cause your company to be quite angry with you, probably involve extensive legal proceedings, and will be an unremovable mark on your record (for good or bad). The third will only work if management is of the right mindset to understand it, and may get you fired for talking about company policy in public. The fourth is perhaps the easiest to do, but will also involve a period of unemployment that could stretch several to many months.

I wish them the best of luck. It's the kind of thing that we all hope only happens a very few times in any career.