Microsoft

Stories about Microsoft, Windows, Office and so on

New computers – Windows 7 – security and password aging

Today when I signed on I got a bit of a shock.  The computer warned me that my password was going to expire in 5 days, and I should probably consider changing it.

It was a shock because this is my computer, and I go along with current password aging thinking, which is that a) we can’t figure out who first figured that password aging was all that hot an idea, and b) if it ever was a good idea, in the modern computing environment, password aging is a non-starter.  Given that passwords should probably exceed 20 characters, and likely should be somewhat complex, trying to get people to choose a good one more than once every few years (when rainbow tables have been extended) is likely more security compromising than enhancing.

So, I went looking.  Having dealt with security for a number of years, it wasn’t too hard for me to figure out that I didn’t want the control panel (since I hadn’t seen anything along that line while I was modifying other settings), and that I likely wanted “Administrative Tools,” and under that “Local Security Policy.”  I had to read through all the options to determine that I probably wanted “Account Policies,” but, under that, it was obvious I wanted “Password Policy,” and, once there, “Maximum password age” stood out.  With no particular options or actions I went back to the menu bar until I found that “Action” had a “Properties” function, bringing up a dialogue box with an entry box with a number in it.  I figured that setting it to zero might turn off password aging, but I didn’t want to do anything that might require me to set a new password every time I signed on, so, when I saw that one of the tabs was “Explain,” I choose that.

(Allow me to digress for just a second here, and note that I suspect that the average home or small office user would not have found it easy to find this setting, and thus would have been stuck with the default.  And all that that implies.)

The explanation did confirm that setting the number of days to zero does mean the passwords never expire.  But it also told me that “It is a security best practice to have passwords expire every 30 to 90 days, depending on your environment. This way, an attacker has a limited amount of time in which to crack a user’s password and have access to your network resources.”

Microsoft, you’ve got to be kidding.  If an attacker has enough access to your system in order to start cracking your passwords, then they’ll almost certainly succeed within a few days.  Unless you’ve chosen a really, really good password, in which case it might be some years.  So 30 to 90 days makes very little sense.  (And, if you’re really serious about the maximum of 90 days, how come the entry box allows up to 999?)

But then, right down at the bottom, it tells me that “Default: 42.”

Oh, sorry, Microsoft.  Obviously you are kidding.  Nobody could take that seriously as a default.

(But then, why is that the default, and why is it enabled by default? …)

The issue prompted a little more thinking on my part.  Was it really 37 days (42 minus 5) since I’d installed the machine?  Ah, but then, it couldn’t be.  As previously noted, I had to take it back to the store to clear up some OS registration issue.  They, of course, didn’t ask what password I’d set, they just blew off the passwords.  So, the 37 days would start from that point, wouldn’t it?

Well, apparently not.  When I checked my journal, it was obvious that the 37 days started when I first started setting up the computer, not when the store eliminated the passwords.

Interesting version of “history” there, Microsoft …

The “Immutable Laws” revisited

Once upon a time, somebody at Microsoft wrote an article on the “10 Immutable Laws of Security.”  (I can’t recall how long ago: it’s now listed as “Archived content.”  And I like the disclaimer that “No warranty is made as to technical accuracy.”)  Now these “laws” are all true, and they are helpful reminders.  But I’m not sure they deserve the iconic status they have achieved.

In terms of significance to security, you have to remember that security depends on situation.  As it is frequently put, one (security) size does not fit all.  Therefore, these laws (which lean heavily towards malware) may not be the most important for all users (or companies).

In terms of coverage, there is little or nothing about management, risk management, classification, continuity, secure development, architecture, telecom and networking, personnel, incidents, or a whole host of other topics.

As a quick recap, the laws are:

Law #1: If a bad guy can persuade you to run his program on your computer, it’s not your computer anymore

(Avoid malware.)

Law #2: If a bad guy can alter the operating system on your computer, it’s not your computer anymore

(Avoid malware, same as #1.)

Law #3: If a bad guy has unrestricted physical access to your computer, it’s not your computer anymore

(Quite true, and often ignored.  As I tell my students, I don’t care what technical protections you put on your systems, if I have physical access, I’ve got you.)

Law #4: If you allow a bad guy to upload programs to your website, it’s not your website any more

(Sort of a mix of access control and avoiding malware, same as #1.)

Law #5: Weak passwords trump strong security

(You’d think this relates to access control, like #4, but the more important point is that you need to view security holistically.  Security is like a bridge, not a road.  A road halfway is still partly useful.  A bridge half-built is a joke.  In security, any shortcoming can void the whole system.)

Law #6: A computer is only as secure as the administrator is trustworthy

(OK, there’s a little bit about people.  But it’s not just administrators.  Security is a people problem: never forget that.)

Law #7: Encrypted data is only as secure as the decryption key

(This is known as “Kerckhoffs’ Law.”  It’s been known for 130 years.  More significantly, it is a special case of the fact that security-by-obscurity [SBO] does not work.)

Law #8: An out of date virus scanner is only marginally better than no virus scanner at all

(I’m not sure that I’d even go along with “marginally.”  As a malware expert, I frequently run without a virus scanner: a lot of scanners [including MSE] impede my work.  But, if I were worried, I’d never rely on an out-of-date scanner, or one that I considered questionable in terms of accuracy [and there are lots of those around].)

Law #9: Absolute anonymity isn’t practical, in real life or on the Web

(True.  But risk management is a little more complex than that.)

Law #10: Technology is not a panacea

(Or, as (ISC)2 says, security transcends technology.  And, as #5 implies, management is the basic foundation of security, not any specific technology.)

New computers – Windows 7 – security and permissions (2)

Had an interesting experience.

There is a file I keep with some reference material.  For a number of years I’ve had this in the root directory of the drive on most of my machines.  I tried to update it the other day.

I couldn’t.

Windows 7 apparently would not let me modify anything in the top-level directory, even though properties showed that I had full control.  I tried a variety of different ways to make these permissions effective.  No dice.

Eventually I found myself somewhere that offered to let me blow off permissions for the root directory.  Permanently.

I thought it over, and eventually decided not to.  Generally, I’d agree that having the ability to write to the root directory might possibly be dangerous, in a somewhat bizarre set of circumstances.  But I decided that moving the file wasn’t that much of an issue.  So I let the permissions lie.

But I’m left with some questions.  My first reaction, once I got to the screen that would let me change the permissions, was to blow them away.  I was so frustrated by the roadblocks and lack of information provided by Windows 7 that I probably wasn’t thinking completely clearly.  And I’d suspect I’m not alone in this.

The other question is: why on earth did Windows 7 allow me to put the files there in the first place, but not allow me to modify them?  Isn’t the ability to put a file there in the first place even more of a security risk?

New computers – Windows 7 – compatibility (4) – oddities

A few interesting … “undocumented features” of Windows 7 observed in the last couple of days.

One is that Windows 7 seems to have a great deal of difficulty remembering the window settings (placement, size, full screen, etc.) for non-Microsoft software.  Not terribly important, perhaps, but greatly annoying, and new to Windows 7.  (XP had some faults in that regard, but nothing like Win7.)

I plugged in one of my cameras this morning.  Normally this would just be plug and play.  However, I couldn’t find any entry for it in Windows Explorer, even though the computer had said that the new device was found, and the driver successfully installed.  Unplugged and plugged again, and it still wouldn’t play.  Finally went looking for devices and printers, and, under removeable storage it simply did not appear.

However, I noticed that one of the other devices had an oddly familiar name.  When I clicked on that, I noticed that one of my mapped network drives was no longer that network drive, but the camera.  Very odd.

(I must say that, once I found out [via Google, not Microsoft Help] how to access it, I very much appreciated the fact that you no longer have to go through contortions to get yourself a command prompt function via Windows Explorer.  A “Shift-context menu” seems a bit arcane, though …)

New computers – Windows 7 – compatibility (3) – Epson (and hardware in general?)

Having gotten some of the software and XP Mode problems out of the way, I now need to install some of the old (and some new) hardware to the new desktop.

The HP LaserJet P1005 installed just fine as soon as it was plugged in.

I suspected that the Epson Stylus CX6400 wasn’t going to be quite so simple, since I recalled having to run the install software before I connected it the last time.  And, yes, sure enough, the installation software (once I found the old CD and instructions) didn’t run under Windows 7.

So, off to Epson.  I checked under Drivers and Support, specified my “All-in-One” (it’s get a printer, a scanner, and some memory card readers), and asked for Windows 64-bit drivers.

Now out of Epson EasyPrint v3.10, ICM Color Profile Module Update v1.20, TWAIN Driver and EPSON Scan Utility v3.04A, TWAIN Driver and EPSON Scan Utility v2.68A, and Printer Driver v5.5aAs which would you pick?  Yeah, I didn’t know either, and the descriptions weren’t an awful lot of help.  But I knew (from the dim and distant past) that TWAIN (we used to say that it stood for “Technology Without An Interesting Name) had something to do with scanners, and the v2.68A was listed for 64-bit only, so I chose that.

It ran.  After a while I got the scanner part of the Windows Fax and Scan program.  It didn’t have many options.  Epson Scan had been installed, but it insisted that it couldn’t run, and Epson Scan Settings insisted the scanner wasn’t installed.  I used the troubleshooter (seemingly provided by Epson) but it was no help.  I rebooted the computer: that was no help.  I tried help and searching on the Epson site: you guessed it, no help.

I did some Google searching.  Found a mention of device drivers, and having to uninstall the Microsoft brand, and install the proper Epson driver.

Well, thought I, I installed this with installation and setup stuff from Epson: surely Microsoft wouldn’t have messed it up in that short time.  But I had a look at Device Manager anyway.

And, lo and behold, the driver that was installed was signed by Microsoft.  Uninstalled that, searched the disk for related drivers, found two.  One was for CX6300/CX6400, and one just for the CX6400, so I installed the latter, on the theory that the more specific was more likely to be from Epson.

And now Epson Scan is happy to run.

(I also installed the original XP software from the CD within XP Mode.  That didn’t work …)

New computers – Windows 7 – XP Mode fixes

I think I may finally be getting the hang of this XP Mode thing.  (I may also be fooling myself …)

As previously noted, XP Mode doesn’t access the “real” drive, but a virtual drive which is contained in one large file.  (Actually, seemingly a minimum of three, but only one appears to contain the drive “contents.”)  XP Mode does provide you with links to the real drives on the computer, but, while accessible from most Windows programs, since they are not mapped to drive letters, you cannot do anything with DOS programs, even though such programs run under XP Mode.

I figured I would have to create the directories, with files I wanted to work on, within the “virtual” drive, and, each time I made any modifications, remember to copy the new versions back to the “real” disk so they could be used under Win7.  Not only is this a nuisance, but it wastes disk space.  XP Mode takes up enough space as it is: starting at about 1.5 gig, by the time you get it up to speed with Windows updates, it has ballooned to 6 or 7 gig.  Any programs or file space you want come on top of that.  (And, since I no longer trust XP Mode to stay stable, I have been making backup copies as I have been doing the updating and adjusting of the virtual machine, wasting even more disk space.)  An annoyance, to say the least.

I can’t remember where I found it, but somehow I noted a reference to the actual description, within XP Mode, of the links to the real drives.  It looks just like a network reference to a shared resource.  So I tried mapping that format and creating a DOS “lettered” drive mapping (from within XP Mode).  So far it seems to work fine.

For those who’d like to try, the “network” name of the real computer seems to be TSCLIENT.  So, in order to create a link to the C: drive on the real computer, map to \\TSCLIENT\C .  (It does not seem to matter what your real machine’s name is, that name does not seem to be used in the reference.)

The MSRC – now and then

It’s amazing to compare how the Microsoft Security Response Center handles vulnerability disclosures versus how things were just 10 or 12 short years ago.

Here’s a typical disclosure process 10 years ago (based on a very true story):

Us: (sending an email to secure@microsoft.com) we’ve discovered a vulnerability in an office product. Here are the technical details. Can you confirm the issue and let us know when it’s patched?
Microsoft: Thanks for reporting, bla bla, we’ll get back to you soon

[about a week passes]

Us: Hi MSRC, any news about our office vulnerability?
[no reply]
[Sending a personal email to an MSRC friend to speed things up]
Microsoft: Oh, thanks for reminding us. We’ll check with the office team

[another few days pass]

Us: Hello? Anybody there?
Microsoft: Oh, yes. That vulnerability thing. Here’s what we decided: (a) It’s not a vulnerability. (b) it’s not a problem with the office product but with the world (or the RFC) (c) The office team can’t recreate it (d) even if the vulnerability was real, it wouldn’t be exploited in real world scenarios
Us: are you kidding us? Did you actually look at the sample code we gave you?
[a few days pass. We are pondering if to go complete full disclosure or give them time to digest]

Microsoft: Ok, this time we actually read your advisory and yes, it seems to work. But it’s just a denial of service. Nobody will ever exploit it because of … [something that heap spraying/DEP bypass/code mutation made look ridiculous about a year later]
Us: [starting the get mad] look guys. We sent you PoC code. You actually want us to write an exploit code for you?
Microsoft: yes, that would help convince our developers

[Us, spending time writing code so that Microsoft is convinced to fix their own products based on free information while wasting our precious time]

Us: here it is
Microsoft: oh, wow, it really does run code. Ok, we’ll fix it in the next release cycle which should be right after the democratic primaries of 2012.

Us: Ok, forget it. We’re going full disclosure

Microsoft: no, wait wait wait. We found your name on the world wide web and now realize you’re legit. Ok, we’ll fix it. Happy now? We might even mention your name in our advisory if/when that happens.

If it sounds familiar, that means you were disclosing vulnerabilities to vendors in the early 2000’s or late 1990’s. If you think I’m exaggerating, it’s only because you didn’t.

But here’s the amazing thing. Just a few years later, some radical changes started to happen. The big dysfunctional dinosaur that was MSRC became an efficient, friendly and if I didn’t know it, I would think it’s a different company altogether. Here’s a real recent discussion:

Us: Hello MSRC, here’s information about an office vulnerability
Microsoft: Hi, thanks for reporting. I checked the information, went over the sample code and have some technical questions [some intelligent questions here, basically they are doubting the findings but being really careful to check all the angles first]

[technical discussion continues for a couple of days with questions and answers going back and forth]

Microsoft: Ok, we get the picture now. Thanks for reporting. Here’s the guy that is going to be responsible for your case.
[a few days pass]
Microsoft: Ok, we now know it’s a […] vulnerability and not a […] one. We’ll pass it to the relevant team, just wanted to keep you posted
[further proactive updates and niceties continue until disclosure time. Credits, the end.]

What could have possibly caused this radical change that made MSRC focus on the technical side instead of the PR, not to mention being so research-friendly? New team? New procedures? Full disclosure forced them to see the truth? Too many beers at defcon finally showed them the light? Whatever they are taking, I wish they could spread some around. Most of the other vendors could use that. Yes, I’m looking at you Google.

New computers and old network problems

Well, I don’t know if this is a continuation in the “new computers” series, or just rehashing an old problem.

I’ve noted before the problem of the complexity of trying to establish an ad-hoc network under Windows.  And, I’m trying various things with the new Mac.  So, in a situation, right now, where I have one network cable, and two computers downstairs, I decided to see what an ad hoc network was like with a Mac.

I remembered to do the bridging thing on Windows, and I’ve set up an ad hoc network with a pre-shared key.  (At least, I think I have.  That seemed to be the way it worked, and the Mac connected with a password, but, on the Windows machine, when I go back and look at it, it says it’s open.)  The Mac wouldn’t show the network when I looked at the list, but, when I gave it the name and password it seemed to connect just fine.

I got a Web site correctly on the Mac.  Then I went to connect to the Windows machines as servers, and that worked out fine.  Then I went to do some work on the Web, and … nothing.  The Mac wasn’t able to get onto the Internet.  I was still connected to the Windows servers, but couldn’t get a Web page.

And, then, suddenly, I could, again.  And then I couldn’t.  (At the moment, I can’t.)  (Sorry, started working again just before I finished this entry.)
I’ll have to give it a shot with the Mac connected to the cable, and see if I can set up an ad hoc wireless connection that the Windows netbook can use, but, at the moment, Mac networking is not working any better than Windows in the ad hoc environment.

Roll on PopulistNet.