Author: paranoidmike

A Product Manager sharing experiences on & of the job.

Encrypting files on the server – WTF???

Published on by paranoidmike1 Comment

I can’t tell you how irritated I get when I read yet another recommendation from some well-meaning security expert that says you should use EFS to encrypt files on a Windows SERVER. I have little or no problem with EFS on a Windows CLIENT (though if you’re not using domain accounts, or you don’t use SYSKEY [shudder], you’re only keeping your files safe from grandma, not your kids), but I have to wonder how many people understand how decryption keys are protected (and by what) when they recommend using EFS on a server.

SQL Database (mdf) encryption example
Let’s take a simple case: you want to protect your SQL database files from remote attackers, so naturally you think “I’ll encrypt the data using EFS – cheap, free and easy – and then remote attackers won’t be able to access the data.” Yes, in one sense that is quite true – if a remote attacker were to try to copy the files on disk – e.g. from a buffer overflow exploit that gave them remote LocalSystem access – then NTFS would return an Access Denied error.

  • when you encrypt a file that is to be accessible to a Service (such as the “MS SQL Server” service that mounts the SQL database files), you are in reality required to encrypt the file in the context of the Service account in which the service runs.
  • In this example, you’d have to encrypt in the MSSQLServer service’s account context – and if you’ve been reading your SQL Server security guidance, you’ll already have created a service account and downgraded MSSQLServer from the default LocalSystem service account context.
  • This means that only the service account (e.g. you’ve created a local account named SERVER\SQLServiceAcct) can decrypt the files.
  • What happens when the service starts? The service “logs on” with the SQLServiceAcct (actually the Service Control Manager calls CreateProcessAsUser() or similar API and runs the new process in the context of the user account specified as the Service Account in the service’s configuration).
  • How does the Service Control Manager “authenticate” the service? The service account name is stored in cleartext in the Registry, and the service account password is stored as an LSA Secret elsewhere in the Registry.
  • LSA Secrets are ACL’d so they are not readable by any user except the LocalSystem, and they are further encrypted with the System Key (aka SYSKEY), so that only the LSA process (which has the ability to use the SYSKEY decryption key) could access the LSA Secrets.
  • [AFAIK] The Service Control Manager requests that the LSA decrypt the service account password and pass it to the Service Control Manager for use in the CreateProcessAsUser() API call.
  • Once the MSSQLServer service is running in the correct user context, then the EFS driver in NTFS will decrypt the encrypted database files for the MSSQLServer process, and SQL Server will be able to mount the now-decrypted database files.
  • Any process running in any other user context will not be able to supply the correct RSA private key for EFS to be able to decrypt the files. In our example, if the attacker could remotely run a script in the LocalSystem context that tried to copy the database files,NTFS will return an Access Denied message to the script process that tried to access the encrypted database files.

However, if that same remote attacker were really interested in getting access to that encrypted file, they could quite easily grant themselves access:

  • Anyone with LocalSystem access (or local Administrators membership as well) could grant themselves the SeDebugPrivilege, and then run any number of “hacker” tools that could dump the LSA Secrets from memory into cleartext form.
  • e.g. the family of lsadump*.exe tools attach to the LSASS.EXE process (via the Debug privilege) and dump out all the decrypted LSA Secrets.
  • Once you have the decrypted LSA Secrets, you can quickly find the SQLServiceAcct password, which then gives you the ability to logon as that user account.
  • Once you can authenticate as the SQLServiceAcct user account, you’ll have access to all the RSA decryption keys stored in that user’s profile. Then any attempts to read/copy files encrypted by that user will be automatically decrypted by EFS.

This is an unavoidable consequence of the scenario. Services must be able to start automatically (at least, on all Windows servers for which I’ve had to recommend security measures), which means that the Service Control Manager must be able to read the password from LSA Secrets without user intervention.

[This also usually means that SYSKEY boot passphrases or boot floppies won’t be used, since the use of an “off-system SYSKEY” means the server will never boot without an administrator intervening, which makes remote management a heckuva lot harder. Unless you have some of those fancy Remote Insight boards AND a sysadmin who doesn’t mind getting paged every time the server has to reboot.]

My conclusion: EFS-encrypting files for processes that start without user intervention provides very little protection against remote attackers who can gain LocalSystem or Administrators access to your server. This means *any* Service, whether on a server or a client (e.g. the ol’ ArcServ backup agent that runs on every Windows server and client, and [at least used to] “require” a Domain Admin account as the service account. That’s another hairy security implementation for another day’s rant, lemme tell you…).

[Note: Netscape web server had this same “problem” back in the days when I still administered Netscape-on-Windows. If you had an SSL certificate configured for the site, and you didn’t want to have to stand at the keyboard every time you wanted to start the web server, you’d have to store the private key’s decryption password in a plaintext file on the server. Kinda ruled out any *real* security that you could claim for that private key, but whatever – SSL was just there to encrypt the session key anyway, and very few SSL sessions lasted long enough for the fabled “sniff the SSL session on the wire” attacks anyway.]

SQL Database dump file example
“But wait Mike – what if the MSSQLServer service was always running? Doesn’t SQL have an exclusive lock on all its database files while the service is running?” Yes, absolutely. This brings to mind a couple of different thoughts:

  • how do you make sure the service is always running – prevent it being shut down, or ensure that the server reboots as soon as the service is no longer running?
  • if the files are already exclusively locked, doesn’t that mean the remote attacker won’t be able to read or copy the files off the filesystem? Why bother encrypting if the service *never* doesn’t run?

Also note: the “exclusive lock” principle obviously won’t apply to scheduled database dump files – the files are written once, then unlocked by the scheduled dump process/thread. This should make you think twice/thrice about encrypting the database dump files on disk – the files will be unlocked, waiting on the filesystem for that same LocalSystem/Admin attacker to logon as the dump user context and copy the files at their leisure. [It would also mean that any remote process to read or copy the dump files – e.g. an enterprise backup system running on a central server – would have to be able to decrypt the files remotely. This requires “Trusted for Delegation” configuration for the server where the dump files are held, which is a security headache that warrants careful thought before implementing.]

My best advice for protecting the database dumps from remote attackers?

  • Don’t ever dump to the local filesystem of the server – stream your database backups over the network, either to a remote file share that wouldn’t be accessible to the remote attackers, or directly to a backup device that writes the files to backup media; OR,
  • Minimize the amount of time that the database dumps are stored on a locally-accessible filesystem. Have the files copied off-device as soon as possible, and if possible wipe the free space after you’ve deleted the files (if you’re concerned about the remote attackers undeleting the files).

News article: "The scramble to protect personal data"

Published on by paranoidmikeLeave a comment

The New York Times recently posted an article about a wide-ranging set of data security issues that I found interesting.

This is the kind of thing that’s recently been guiding my thinking – not just encryption because CSB 1386 [for example] says you should, but holistic means of preventing loss of Confidentiality (via Information Disclosure threats e.g. not just the always-discussed-but-rare-in-the-real-world MITM SSL attacks but lo-tech attacks like getting hired at the delivery company that picks up your backup tapes).

IE & tabbed browsing – what are the competition *really* doing to MS?

Published on by paranoidmikeLeave a comment

The amount of effort that MS has poured into tabbed browsing over the years – first denying its utility, then showing how you can do it with other IE-based browsers, and finally in actually implementing it in IE7 – makes me wonder what’s up in the minds of the competition, and all the “whiners”, who kept harping on the lack of tabs in IE [caveat: I like tabbed browsing as much as the next person]

At best, tabbed browsing is a “nice to have”, and if you *really* didn’t like that IE didn’t have it, I gotta wonder why you didn’t just go use another browser that *did* have tabs. I can see *some* legitimate reason for putting tabs in IE, but the effort that it generated on MSFT’s behalf I believe was disproportionate to the benefit of finally getting tabs in IE.

It reminds me of the times when the press are goaded into spending inordinate amounts of time reporting on trivial issues, giving the government or industry plenty of “cover” in which to execute much more controversial policies and decisions. Like implementing extreme policies while the press spends every waking moment wondering about Terry Schiavo, as one example.

Microsoft, you should watch out for what people are *really* doing while you’re not watching – while you’re being goaded into focusing all this attention on such a trivial implementation (even if some of your biggest customers are “demanding” tabbed browsing). At minimum, you’re being taunted into playing a game of catch-up with the competing browsers, and getting no more benefit from this than being able to claim “me too” on a feature that I believe is ultimately trivial. What major “big-bang” features do your competition get to deliver, while you’re playing me-too rather than implementing new features?

I know this sounds a bit paranoid, but it doesn’t mean it’s inaccurate…

InfoCard – how is this different (in function, not in form) from MS Wallet, Passport and/or any of the dozens of "form filler" applications?

Published on by paranoidmikeLeave a comment

“Microsoft to flash Windows ID cards”

I’m trying to understand what the heck “new” is being offered here…

  1. InfoCard will install a secure “store” (which can contain identity and payment info, among other things) on your PC.
  2. I presume that the whole InfoCard “store” will be password-protected (as is de rigeur for consumers, even in these heady days of security), though perhaps they’ll offer the option integrating things like the MS Fingerprint Reader, a smart card or some form of USB smart device [for those few consumers who actually care enough about security to bother with all the hassle this’d bring].
  3. Presumably you’ll be asked to input each of your credentials and your credit card information into the software.
  4. When a user then visits an online service that asks for InfoCard-compatible versions of either (a) one of the authentication credentials the user’s stored in their InfoCard “store” and/or (b) payment information, the user will be prompted for their InfoCard “master password” (hopefully every time their InfoCard store is about to give out this information), and then the InfoCard store will use whatever Web Services communications protocols to securely communicate the consumer’s information to the site.

What is so revolutionary about this, you might ask? Compare this to the typical “form filler application”:

  1. The form filler app installs a secure “store” (to contain identity and payment info) on your PC.
  2. The form filler app asks you to establish a “master password” to protect anything it adds to its “store”.
  3. You’re asked by the form filling application whether you wish to add any creds it’s just observed you type (into a web form) into its secure “store”. You can also pre-fill identity information (one or more sets) into the form filler app, to be auto-filled later into web forms.
  4. When a user then visits an online service that asks for either (a) one of the authentication credentials the user added to the app’s “store” and/or (b) payment information, the user is prompted for their “master password” [which can then be cached for a specified period of time], and the browser then submits this information to the web site using whatever communication protocols were established (usually, SSL/TLS).

So as near as I can tell, the InfoCard user experience for web surfing fundamentally boils down to the Web Services “format” for communicating this sensitive information from consumer to web site.

Colour me skeptical. Sure, in a few years, most web sites will have one or more Web Services communications & security engines built into it, and by that time, the pressure for “current” approaches to communicating this information consistently & securely will be heightened. However, I guess I’m not clear on what InfoCard buys the consumer (who presumably will have to adopt this technology in droves) *today* over and above the current “good enough” approaches for storing & communicating this information – and until there’s a clear consumer benefit, watch people not bother in droves. [I’m sure *I’ll* download it as soon as it hits the web and play around with it, but I’m still a bit “sick in the head” with my love for trying the new stuff out…]

As well, I’m not sure what will compel the web services application vendors, and their customers (the web application programmers and architects) to adopt the Microsoft “InfoCard” approach over the growing number of identity-integration technologies that are becoming available. [Or maybe under the hood, “InfoCard” is just a friendly name for an implementation of a WS-*-compliant client, and any server that speaks WS-* will be immediately capable of interpreting the output from the InfoCard client…]

You know what would be a brilliant integration? If this were wired in tightly with the MSN Toolbar, so that its form-filling feature could adapt over time to add these capabilities without requiring the MSN consumers to adopt yet *another* piece of technology, at ever-decreasing return-on-effort.

I’m also intrigued by the promised integration of X.509 creds into the InfoCard client – will this be natively interoperable (integrated) with the current CAPI store of X.509 creds already available in Windows? Will this make X.509 more accessible to consumers, without watering down the benefits of “strong authN” to the point where it’s really no better than a password or an email address? And, are they considering integration with RMS and their XrML-based identity assertions (which are the more logical entry point for Web Services, if only because an RMS “account certificate” already uses XrML to format the identity “message”)?

There’s a bit more detail (including mention of the “WinFX” dependency of the InfoCard client) here.

Bottom line: This is something to keep an eye on for your B2C projects, but I’ll continue to seek out additional authentication & identity technologies for the enterprise space until I get a stronger understanding of this…

Data security as a superior approach to perimeter, network, host or application security?

Published on by paranoidmikeLeave a comment

I’ve always believed that the network is a poor substitute for protecting a host, its apps or (ultimately) the Data made available via the n/w, server and its apps. To me, the other layers of perimeter, network, host & applications are necessary means to the end, which is to access, manipulate and sometimes even add to that Data. Similarly, security enforced at the perimeter, network, host or application layers, while necessary, is not sufficient when what you’re really trying to accomplish is to security the Data.

Disclosure: I started my IT career in the desktop arena, and I’ve grown into the server and enterpise data arena over time. It’s been a great journey, but I’m probably still biased towards the PC at heart.

Certainly your ability to protect each set of data scales much better, the further you draw it out towards the perimeter. However, in my experience, you sacrifice the ability to provide very specific protections for the data inside the perimeter, for example:

  • the firewall rule which blocks or allows 80/tcp access doesn’t provide an ability to authorize access for specific groups of users (only for IP addresses or subnets)
  • the host security that allows/denies a user to Logon to the host (e.g. “access this computer from the network”) doesn’t give you the ability to allow the user to only access one set of data on the host but not access all other sets of data on the host
  • the application protection (e.g. SQL per-user/group roles assignment, Samba per-folder ACLs, email per-server/mailstore ACLs) don’t allow you to protect individual pieces of data accessed through the application that “front-ends” the data, though often the application can also provide built-in “bulk data protection” mechanisms. However, if another application were used to access the same on-disk data, it is often possible for the application-level protections to be completely bypassed.

In my opinion, the defining characteristic of data-level protection is that it only allows access for the authorized user(s) to the authorized data (set(s)), no matter what application or OS is used to access the data.

In the extreme, this definition would only include data that has been encrypted such that only the key that is in the authorized user’s posession can unlock the data (e.g. PGP, S/MIME).

Examine for a moment what happens when you rely only on the application-level security:

  • Windows file share-level permissions could be bypassed by users who can access the admin shares, a Remote desktop or an FTP session
  • SQL roles-based access can be bypassed by anyone who can mount the .mdf file as a new database instance, or who has one of the privileged server or database roles such as sysadmin or db_owner.

In each example, the application protections that were meant to protect the data itself has not been changed, but the data could be accessed by the user (attacker) even though the application protections were configured to block the user.

The principle of “defense in depth” implies that the more layers of defense, the better the asset is protected against a failure at any one layer. However in my experience, a valued asset will “grow” new methods of access over its lifetime – e.g. a mainframe application may start out with access only from terminal emulators, then PC access is added via Communications Server & PComm, then later a Web Services interface is added to the mainframe for direct browser-based access.

The mainframe application may not have changed in the slightest throughout all this, but the “DiD” model that was suitable at first may not be appropriate to protecting from the threats that are now possible via the new interface.

Data-level protection may not require encryption to prevent access, but it’s the only significant protection I can think of, and it seems to be the protection to which most people turn. You can also add DRM (or ERM, RMS, etc.), but if it doesn’t also include encryption, to me it’s pretty much ineffective at actually protecting content you’ve given to someone else from being exploited beyond the rights you wished to assign.