Posted by Adam Ruth on Wed, Jun 23, 2010
In a recent post entitled Security Administration - Tradeoffs I discussed the dangers of making things worse in an attempt to make them better. All changes have a downside, however small, and if you can't see a downside it means you haven't analyzed the change sufficiently.
This was brought into stark contract when I read this post on Eric Raymond's blog. The essentials are that some people are agitating to make AIS ship information encrypted and secure (AIS is information that ships broadcast about their position to other ships and shore receivers for collision avoidance.) The idea is that this information can be exploited by pirates and terrorists. While this is technically true, it doesn't take a very deep analysis to see what the downsides of this would be.
The biggest hole that I can see, and Eric points it out clearly, is that any system would need to have a way so that ships could still read the transmissions of surrounding transponders. What is to prevent this technology getting into the hands of pirates? A technology that by necessity must be installed on thousands of vessels, and access given to any number of individuals of varying degrees of trustworthiness? It doesn't seem like a huge problem for pirates to pose as normal ship operators who need the equipment, or failing that, to take control of a small vessel and torture the captain for his encryption keys. This change might thwart the casual, weekend pirating teens but not professionals.
It's a case seeing a problem (pirates using AIS information to track down targets) and posing a solution (prevent pirates from getting AIS information with encryption) without fully considering the real world weaknesses of encryption technology or the costs, not just in implementing the solution but in the fragility this would introduce to collision avoidance. I'm reminded of password complexity requirements which see a problem (easy to break passwords) and posing a solution (require really complex passwords) without fully considering how those complexity requirements will just cause people to store unmemorable passwords on paper or in files on computers.
Consider the following two passwords I just made up off the top of my head 7sne02mnw6slie$a and .@Flyingfoxes001. Both have the same length and one is very obviously easier to remember without much strain. The second password wouldn't fly in a lot of places, and may even drive a security officer to an early grave. In fact, I'm almost certain that even the first password isn't complex enough for a couple of places that I've worked. So which password is more secure? Let's see what my computer thinks.
Hmmmm, okay. Maybe my computer is stupid. Let me see what GMail has to say.
(first)
(second)
I know which password I'd rather use, and which I'd rather have my users go with (the password reset cost savings alone would be huge.) Still, some people's guts will tell them that the first password is clearly superior.
Another example. I recently got a new phone and I had to select a 4 digit PIN for customer service. As we should all know, 4 digits provide for 10,000 possible PINs. However there was a requirement that no two digits next to each other could be identical or consecutive, so 1274 is not a valid PIN. That simple requirement actually reduces the number of possible PINs by nearly two-thirds to 3,430. This may still be sufficient, but I'd be willing to bet that whomever created the requirement didn't consider this consequence.
No security system is ever fool-proof, particularly when the fool is the one designing the system.
Posted by Adam Ruth on Mon, Apr 26, 2010
Photo by Fristle
A fascinating blog post by Keyboard Cowboy details his efforts to expose a flaw in the granting of SSL certificates. The summary of the story is that many CAs (Certificate Authorities) grant SSL certificates to domains by sending an e-mail to an administrator's e-mail account on that domain such as "administrator" or "postmaster." Some companies include "ssladmin" in the list of authoritative addresses and many free web mail services allow that particular address to be registered by anyone, making it possible to get yourself a certificate for the web mail domain.
This particular exploit strikes me as being almost social engineering. It's not, technically, because it doesn't involve interaction with a person but the hole exists because of a lack of communication between the web mail providers and the CAs. Imagine if CAs decided to add another address to the list of usable ones, such as "securityadmin?" Unless all web mail providers were informed, this would just re-open the hole.
It brings to mind the idea that all security systems are tradeoffs. Every system that increases security in one way reduces it in another. SSL certificates are certainly a boon to online security, they make web commerce possible. But the realities of issuing certificates makes it so that not all SSL certificates can be trusted. So that even if you are diligent in looking for the https: and a valid certificate, your trust may be misplaced and you'll be less secure than if you didn't trust any site.
It's important to keep this in mind when designing security solutions and policies. Always try to identify how this new policy will reduce security. Complex password requirements are more secure, but also more likely to be written down. Time consuming door entry procedures increase the likelihood of tail-gaters. Police radios help police to coordinate activities, but scanners let the criminals keep an eye on them. I would submit that if you are looking at a new security policy and haven't been able to identify the ways in which it harms security, then you haven't thought it through enough to implement.
Follow me on Twitter @AdamRuth
Posted by The Admin Arsenal Team on Mon, Feb 08, 2010
Author: Adam Ruth
DCOM, or Distributed Component Object Model, is a technology in Windows allowing remote communication between programs. WMI, in particular, uses it to communicate. A lot of business oriented server applications use it, as well, to communicate between layers. If you've ever spent any time with DCOM you probably have come to understand just how fragile it can be. When it works, it's like magic, but when it doesn't it can be a serious hair pulling experience.
One of the more fragile bits of DCOM is its security. There are are four different areas of DCOM each with their own ACLs (Access Control Lists) and a problem in any one of the four can lead to hard to track down problems. To make matters worse, many applications that use DCOM will alter the security settings, potentially breaking DCOM access for other programs on the same computer. Sometimes it's necessary to just reset DCOM security to its default state, just as it was when Windows was installed.
Last week I found a quick way to do this, but it does require editing the registry so the standard warnings and "do not try this at home" apply. However, if you're stuck fixing a problem down in the guts of DCOM security, editing the registry is the least of your worries.
You can view the DCOM ACLs by running dcomcnfg.exe and navigating to Component Services > Computers > My Computer > Right-click > Properties > COM Security tab.
The ACLs are stored in the registry under the key HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Ole, in the following binary values:
- DefaultAccessPermission
- DefaultLaunchPermission
- MachineAccessRestriction
- MachineLaunchRestriction
To reset them, all you need to do is to delete these values. If DCOM doesn't find any ACLs here, then it will use its defaults. Any changes you make will then re-create the values. Of course, you'll want to back them up before you delete them, or you could just rename them to be safe.
Posted by The Admin Arsenal Team on Wed, Jan 27, 2010
Generally I despise information security measures that are so strict the computer users basically have to resort to using old Selectric typewriters to any work done.
Password enforcement is one area where I roll my eyes a lot. A good, reasonable, password strength policy is appropriate, no question. However, the stricter the policy the greater the probability that the respective computer users will end up writing their hard-to-remember passwords on a sticky note stored under their keyboard and then, of course, the security is worse than allowing certain patterns or longer modified words.
Then I read this article posted on ZDNet.
http://blogs.zdnet.com/security/?p=5325&tag=wrapper;col1
From the article:
Key findings include:
- In just 110 attempts, a hacker will typically gain access to one new account on every second or a mere 17 minutes to break into 1000 accounts
- About 30% of users chose passwords whose length is equal or below six characters
- Moreover, almost 60% of users chose their passwords from a limited set of alpha-numeric characters
- Nearly 50% of users used names, slang words, dictionary words or trivial passwords (consecutive digits, adjacent keyboard keys, and so on). The most common password among Rockyou.com account owners is “123456”.
One thing I definitely recommend is forcing passwords to be longer than 8 characters. Even HomerSimpson changed to H0m3&s!mP$i is a great password and one that a user who prefers typing HomerSimpson can more easily remember.
If you or someone you know creates password policies so strict I would consider taking a stroll through your users' offices and cubicles and looking under keyboards. I'd also consider easing up on your password policies if you find passwords written down.
Of course I'm not telling you anything you don't already know.
Posted by The Admin Arsenal Team on Mon, Jan 11, 2010
Photo by Brad & Ying
Author: Adam Ruth
Our goal at Admin Arsenal is about helping administrators work remotely by getting them to unplug their sneakernets. System security can sometimes make it difficult to achieve this goal. It would be great to live in a world without the need for security, not least because of its delicious gumdrop houses, use of sparkling rainbow wishes for currency, and ruler Princess Yum-yum-tum-tum of the Rose Scented Flatus. Unfortunately, we don't live in that world (which is a shame because the dollar to rainbow wish exchange rate is at its highest ever.)
Like most things in life there is a trade-off between the security of assets and their availability for use (or administration, as the case may be.) We've found that security issues tend to be the biggest roadblocks in achieving remote administration nirvana. So in that vein, I present the 5 biggest security roadblocks that we encounter regularly.
Firewall
This one should be obvious. If a computer doesn't allow inbound connections to its remote administration facilities, then it's not going to work. With the advent of the Firewall in Windows XP more and more people are seeing their remote administration break. It's been a while since the Windows Firewall entered the scene so this problem, and its cure, are quite well known now. The simplest fix (short of disabling the firewall) is to enable the
remote administration firewall exception, the file sharing exception (for remote access to the file system) and the ICMP echo exception (for ping.)
DCOM Security
WMI (Windows Management Instrumentation) is one of the primary methods of remotely administering computers. It uses DCOM (Distributed Component Object Model) as its method of communication. If the rights for DCOM aren't properly set, then WMI isn't going to work correctly, if at all. WMI, for all its power, seems to be quite fragile or brittle. One of the reasons behind this is its reliance on DCOM which seems to be the target of well meaning but misguided security experts and tools. We see this problem so often that we created a tool called DCOMAcls which allows for the remote setting of DCOM security settings.
System Time
Windows security has trouble coping with computers with clocks that are out of sync. This is actually for a good reason, since security tokens use timestamps and expirations to prevent their misuse. Depending on the settings of your authentication scheme (such as Active Directory's implementation of Kerberos) a clock that is out of sync by only a few minutes can cause connectivity problems. Usually, though, it takes clocks off by a few hours (such as reversing AM/PM or being on the wrong day.) Troubleshooting this problem can be difficult because the connectivity issues don't usually indicate that it's a time sync problem.
DNS/DHCP
WMI's authentication validates the host name being used to access the computer (unless a raw IP address is used.) If there are DNS or DHCP problems causing the wrong computer name to be used for connection, WMI will quite often fail. Windows DNS is notorious for stale records and it takes some effort and planning to ensure that a good DHCP setup prevents the same addresses being reused often. Then throw NetBIOS into the mix and once your name resolution is compromised then all bets are off.
The Double-Hop Problem
This problem only affects a certain type of remote administration, so while it's not generally encountered by most administrators, those who use this type of administration will almost always run into it. The
double-hop problem is, to put it simply, the inability for a security token to hop twice between machines. If you connect from computer A to computer B to execute a task (such as start a remote software install) and that task needs files on computer C then the security token can't hop again from B to C and access to those files will be denied. There are three solutions to this problem, the first is to configure a level of trust called "delegation" between computers, but this requires some high-level settings in Active Directory and is usually discouraged. The second solution is to send a user name and password from computer A to computer B so that a new token can be created to hop between B and C, but this is also problematic because it involves sending a password over the wire (possibly encrypted, but out in the open) and there aren't any native Windows tools that work that way. The third solution is to figure out a way to not need files on computer C, but this may not always be possible. So, while you may never run into this problem, when you do it can be a bear to deal with.
Hopefully this list will help any of you having security problems in your remote administration daily lives. Personally, I've filled out the immigration paperwork for the the land of gumdrop houses...