skip to main |
skip to sidebar
Ever want to prevent a user from attaching a USB drive? Well, you could turn off USB in the system BIOS, but that prevents attachment of all USB devices, not just drives. That could be disastrous if you don't have a PS/2 Keyboard and Mouse attached.
There's a simple registry hack that manages how Windows XP SP2 and later and Vista manage attached drives (including external hard drives as well as flash) but not prevent the use of HID devices and other non-drive devices. There's a very good write-up on the How-To Geek. The hack can be summed up in this simple line:
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\StorageDevicePolicies]
"WriteProtect"=dword:00000001
For more security, you can look at physical protection. Unfortunately the USB physical standard doesn't allow any realistic way to permanently lock the drives, but you can block them. Lindy makes USB port blockers that will at least deter casual attempts to plug in USB and at least slightly slow determined users. They can be removed with a carefully bent paper clip, but once in, you can't easily remove with bare hands. Different colors use different keys to remove. Of course, you can buy them in colors other than pink...
I'm going to step aside from my normal patching discussions and talk about what happens when you do get attacked with malware that exploits a vulnerability. When a nasty program exploits an unpatched vulnerability, there are always mitigating factors that can help limit the impact. One of the big ones is that the exploit usually runs in the security context of the account which it attacks/is run against. Security vendor BeyondTrust looked at the 154 Microsoft vulnerabilities published in 2008. They found that 92% of all vulnerabilities had their impact mitigated or were rendered completely harmless when the user was running with no elevated privilege (normal user rights). Obviously this is a report from a security vendor selling software that helps manage user rights... but the breakdown for 2008 is striking, indicating that running as non-administrator at least mitigates:
- 94% of Microsoft Office vulnerabilities reported in 2008
- 89% of Internet Explorer vulnerabilities reported in 2008
- 53% of Microsoft Windows vulnerabilities reported in 2008
That makes sense when you realize that the first two categories are just applications. They're very specialized, widespread and extensible applications, hence the risk. Ultimately, however, they're running at the user's privilege level. Even though the OS itself is somewhat less protected-- many of the juicier exploits will run at the System context or elevate privileges-- 53% mitigation is still pretty good.
Here's my beef with Microsoft in this regard. We all know that running in the least level of privilege is the safest and these numbers add good ammunition to that argument. While Microsoft has made great strides in allowing the user to elevate their privilege on some actions in the "XP era" and later, getting the ability to universally change security context on the fly eludes them. *nix with sudo and the standard GUI security elevation method of OS X both have serious problems, but they're a lot closer to right. Windows 7 will certainly continue the slow progress in this area, but at some point Microsoft ought to do better.
And this time, it's bringing a worm. At this point, the estimate of infected systems is at around 8 million according to F-Prot. I've not seen an infection yet myself, knock on wood, but considering:
A.) That there was more than enough warning with Microsoft flailing their arms over a serious out-of-band patch on 10/23/2008, plus at least one, probably two Patch Tuesdays since the patch was released.
B.) This worm only spreads over corporate and local networks -- networks that are supposed to be managed by professionals.
The numbers are disheartening to say the least.
--
Edit: Microsoft has a helpful portal for this worm. Ars Technica also has a great article, quoting an infection rate of around 1.1 million PCs for the last 24 hours.
This is going to be short as it's already covered well elsewhere and this is late... Microsoft has another out-of-band patch as of 12/17, MS08-078 affecting all versions of IE on all supported OSes except Server 2008 for IA-32/x64. Zero-day exploits are already going on. Get this one patched ASAP.
I'd normally say "use Firefox" or some other browser whenever possible, but Firefox and Opera are also currently suffering vulnerabilities. Firefox 3.0.5 resolves the issues. While not quite as sever as the zero-day exploit on IE, these are noteworthy as cross-platform.
It appears that at least two credible variants of worms based on the MS08-067 exploit have gone live.
I'm fully (and I do mean fully patched) and your organization should be too.
I don't normally beat the dead horse with Windows patch news, but this one is bad. Microsoft released an out-of-band patch this morning with MS08-067.This vulnerability affects all current shipping Windows versions, with worm-style propagation being a very real likelihood. Versions of Windows 2000 and XP Pre SP2 are highly vulnerable, with some XP SP2+ and Windows Server 2003 systems being exploitable under certain common/popular firewall conditions.
Vista and Server 2008 appear to be exploitable, but only in terms of a DDoS type attack. Remote Code Execution has not yet been shown on a Vista system.
As of 12:30 PM Pacific Time, Microsoft reports attacks in the wild. This could be the next Blaster/Sasser type attack, so get patching!
We looked at passwords and password strength in the context of a random password generator. That's a great tool and a wonderful ideal, but sometimes random strings can be a squeency bit hard to memorize and type.
Here are some tactics I've found for creating easily memorized passwords (with the understanding that you still need strong passwords and great security.)
I want to make one point, though, before I start: I've both been taught and seen that when you give people an example password, they will think that the example is itself a great password, and then use the example. Don't do that.
Acronyms: Take a phrase or sentence, using the first letters of each word. For example, "This password is for the backup administrator account" might become Tpiftbaa. That's not great (sufficiently random, but only 2 classes of character), but moving in the right direction.
Passcodes: Systems that will take a longer password can take a phrase or sentence in the form of a passcode. With the previous example, "This password is for the backup administrator account." could itself be the password. That's much stronger-- much longer and it adds the period as a third class of character, but remembering the little fiddly words can get tricky with these.
Patterns: Sometimes thinking outside the box is the key to a good password. Look at your keyboard and find a nice pattern. I'll use the keys on the left of a standard qwerty keyboard. Note that the keys make a cool "V" pattern-- hey, that's kinda random! "1qazse4" isnt' just a pattern on the keyboard, it's a decent password. The problem here is that somebody shoulder-surfing is much more likely to be able to pick up on your password because it makes an obvious pattern.
Transposing Characters: I hesitate to mention this one, because it's so easy to be lazy. Think you're 1337? Well, 'leet boy, you can use a "1" for an "i" or a "#" for an "H". This is a good tactic, but easy to abuse. "P@ssw0rd" is a very, very bad password- easily guessable. Use this tactic, but in conjunction with passwords that are good to begin with.
Mnemonics: Like anything memorized, attach them to other concepts or items-- or make up your own secret special meaning for your password. Pronounce it out loud in your mind-- just don't use things that are easily memorized but also guessable things about you.
Naughty Passwords: Since other mnemonics are often insecure, one trick you can use to make passwords more memorable is to use elements that are at least slightly naughty. Let's say your boss has a serious problem with rearward-facing pants bulge. Myb#aBFA would be a pretty good password! Breaking that down:
My
b(oss)
#(leet-h for has)
a
Big
Fat
Ass
Bet you won't forget that one so easily!
It's probably worth a few minutes to talk about what constitutes a bad password.
Anything guessable is bad. Anything that's easily compromised through brute force is bad.
OK phew, that was hard! Now, on to the specifics. Users often don't really have a clue about passwords in general and see them as at best a necessary evil and at worst a horrible pain in the ass. Users will go to heroic lengths to "beat the system." Getting around these problems often involves management, but at least be vigilant for what happens.
Using really poor passwords: People use the names of their kids, their pets, their address, their kids' birthdays, their pets' birthdays, etc. These are all very easily guessable, bad passwords. The ultimate cliche is a password of "password." BAD USER! NO COOKIE! You'll see other common passwords like favorite sports teams, TV/movie characters, cities, states, brand names, etc. used. Your defense against this is setting up a password system that requires complexity and tests for dictionary words and other likely bad passwords.
Practicing Poor Password Security: Taping your password to your monitor, the underside of your keyboard, or scribbling it on the bottom of the tissue box all happen, often. No matter how complex your passwords are, writing it down in a public space removes all security. Anybody who can get to their desk can get in with their passwords. All you can do is have a policy set up such that when this is caught, the user gets their proverbial hand spanked, changes their password immediately and is informed not to do it again.
Using the Same Password in too many Places: This is another easy one, but hard if not impossible to test for. At least encourage your users to use different passwords for work than for any other use and if you have a more secure network or if they act with higher privilege than normal, ask them to use a 2nd password for that task so that a single compromise won't compromise every system.
Re-using the same passwords excessively: So if you have a password policy that the user has to change the password monthly, and can't use the same one doesn't preclude the user from just having two passwords and rotating them monthly. You can set policy such that they can't re-use more than X number of passwords (3-6 is common.) That's actually pretty reasonable. If users rotate a larger number of passwords less frequenty, it's not so terrible. The danger comes in when users combat this annoyance by just changing one character or identifier in the same base password. If "Password1" just becomes "Password2", the whole point of rotating passwords has just been invalidated. If you can, ensure that when a user changes a password that it's >1 character different from the old one.
But sometimes, admins fail as well. I've seen a production database system that contained credit card data at a major company that was just secured by a password-- not a username/password pair. Understanding that people are lazy, a co-worker sat down one slow afternoon and tried strings. About one in four turned out to be a valid password. These weren't exotic strings either-- mostly sports teams, common dictionary words, etc. Thankfully the admins realized this was a huge security hole and fixed it in short order.
If you can, ensure that passwords are as complex as possible and be vigilant for users trying to undermine your best efforts.
There's not much to say about this one that's not common sense, but more common sense is better.
Passwords should be "strong" -- that is, not easily guessable or hacked via brute-force. The longer it is, the better. Combining different types of characters (upper-case letters, lower-case letters, numerals and 'special characters' like punctuation) is even better. Your birthday, the name of your dog, etc. are all very, very bad passwords. They're not as good as two-factor authentication, but often they're all you get to work with.
Sometimes you have to crank out password after password (or one Really Good password) and that's a job best left to a random password generator. If you just need some passwords, I like the PCTools Random Password Generator web page.
Security through obsurity frankly sucks. Sometimes you can't get around using it, so it's worth understanding what it is so you can avoid it whenever you can. Simply put, making something appear to be something else, or hiding an insecure service rather than securing it is poor security.
For example, having a file out on an unsecured network share called passwords.txt that contains, say, passwords is just stupid. That's less than no security; it's a tempting target for any prying eyes.
Renaming that file to csfr4pw.txt seems like it might deter casual onlookers, but anybody interested in your data can trivially grep or search through file contents and notice that it contains sensitive passwords. Likewise, other automated tools like nmap can help attackers easily determine what services are running where.
Find a better way to secure the data. Put it behind a protected share, encrypt it, or even just alter the contents to say "the passwords are stored in a tamper-evident envelope in a locked cabinet." Though technically part of "defense in depth," this is one tactic you should avoid if at all possible.
Defense in Depth isn't just a military tactic anymore. This is another basic building block of IT security. In short, don't rely on one specific type of security for your valuable data and expect attacks to come from every vector possible.
Defense in depth starts with securing your systems physically. Anything that's really sensitive should be behind locked doors. Firewalls, separate sensitive networks, OS-level security, anti-virus, anti-malware, intrusion detection systems, and many other tactics can help ensure that what needs to be secure actually is.
Typically you'll want to combine multiple levels of security for additional assurance.
A key pair of linked concepts, Authentication and Authorization are so fundamentally important to networked computing, yet often ignored as "assumed knowledge." The fact is that most networked operating systems handle Authentication and Authorization pretty well if configured properly, but I want to cover the basics in case there are any problems. Pay attention, there will be a quiz later!
Authentication is a process by which you prove that you are who you say you are. The most common form of authentication is a user password. In this case, you provide some piece of information only you and the computer know. If you have that info, you are (as far as the computer is concerned) who you say you are.
You have probably also seen biometric authentication systems like fingerprint scanners, and some of you may have seen Handheld Authenticators like the RSA/SecurID system. In the first example of biometric data, something you know is replaced by something you have-- and in the case of your finger, something hopefully you and only you have.
Two-factor authentication builds on the previous two concepts. You need something you have plus something you know. You the basic form at an ATM machine. To make it give you money, you need your PIN code and your card. A thief would need both rather than an either-or to get access to your account. From an administrative standpoint, you may need to consider something like a SmartCard system or an RSA/SecurID system. For SecurID, you have a physical token/device (key fob usually) that generates one use-codes. You combine these one-use codes from the authentication device with a PIN number only you know. Instead of a password, you now have not only a two-factor password, but a one-time two-factor password!
The most common way for this to break down would be to share passwords or use shared accounts (accounts that aren't meant to be tied to a specific person and more than one person has the password.) For authentication to be reliable and secure, you must not have any situations where one person knows another person's password! If you just can't resolve this, realize that it's an insecure situation and work to mitigate the risk.
Authorization is the other half of this coin. Once a system can reliably tell that you are who you say that you are, now the system can give you permission to do what you should be able to do-- this is often revered to as user privilege or privs in admin-speak.
As an admin, you'll typically work within the specifics of your networked OS/system to grant and modify user privilege as required by your organization. Users should operate under the concept of least privilege. That is to say, that they should have the rights to do what they need to do, and not more than that. Granting them extra permissions is a risk that the users may engage in dangerous activities (installing spyware, snooping through HR payroll databases, etc.)
Your risk here is threefold:
- You need a strong authentication system to ensure that you know who is logging in to your systems.
- You need to be vigilant in that the IT group is setting up permissions properly, without any loopholes and obeying the principle of least privilege.
- You need to guard against outside threats which will use exploits in the system to elevate their privilege beyond what they should have.
As you can see, these two concepts are tightly linked and important building blocks for all security concepts.
Posts
