SQL Server sysadmins can affect the host machine

Microsoft SQL Server has an xp_cmdshell procedure that runs the a given program with arguments. It's unavailable by default, but can be enabled by server sysadmins. The account under which SQL Server runs is roughly equivalent to a standard user, but it has a couple extra privileges enabled. Most relevantly, it has SeManageVolumePrivilege, which permits the use of SetFileValidData (which is how the fsutil file setvaliddata command works). Therefore, if an attacker can gain sysadmin privileges on an SQL Server, they can exfiltrate deleted data from the disk like so: create a blank file, write a zero byte at a large address in that file, set the valid data to that point, and read the file's contents. PowerShell makes the first and last steps pretty easy.

NTFS permissions to allow users to create their own home folders

In Active Directory environments, it's common to give each user a home folder where only the owner of the folder can work with the contents. The "Active Directory Users and Computers" tool can automatically set a user up with Full Control of their assigned home folder, but it's also possible to make a folder under which newly created folders will automatically be made home-like.

First, disable inheritance on the topmost folder and do not copy inherited entries. Then add these access control entries:

• Allow SYSTEM full control over "this folder, subfolders, and files"
• Allow Administrators full control over "this folder, subfolders, and files"
• Allow Users "list folder contents", "read & execute", and "read" on "this folder only" (or "this folder, subfolders, and files" if you want everyone to have read access to each others' stuff)
• Allow CREATOR OWNER full control over "subfolders and files only"
• Allow Users "create folders / append data" on "this folder only"

The last entry is what allows users to create their own folders, while the second to last is what gives them full control over the contents.

Based on my Super User answer.

CloudFlare leaks: change your passwords

In case you have not yet heard, CloudFlare - which handles the traffic for many, many web sites - had a bug that spewed sensitive data into responses of certain requests. Fortunately, it's over now, but some users' credentials were definitely compromised.

Here is a big list of notable potentially affected sites. Note that not nearly all sites there were affected, and it's not guaranteed that all affected sites are there; it's just a useful resource. I strongly suggest you change your passwords - or, better yet, enable two-factor authentication where possible - on the CloudFlare sites you use.

Further reading:

• Q&A on Security.SE
• The vulnerability disclosure

StartCom is probably going away

StartCom is a root certification authority (CA) that has historically provided free SSL certificates. I've used them for a couple of my domains, and I've been very happy with the experience.

A while ago, though, it was discovered that StartCom's new owner WoSign had engaged in some sketchy behavior (intentionally backdating certificates). They also had severe bugs that allowed people to get valid certificates for domain's they don't own, which is a Very Bad Thing^TM. Google Chrome has started phasing out its trust of those two CA's. I believe Firefox is also doing something similar.

This is basically a death sentence for that company, as it was for DigiNotar.

PATH surprise: Adds to the DLL search order

The most desired effect of adding a folder to the PATH environment variable is that typing the name of a program in that folder can run it. There is one other, more subtle effect.

The DLL search order specifies where Windows will look for a DLL file when a program loads it only by file name. The last thing searched is the collection of folders on the PATH. Therefore, if a program attempts to load a DLL that's usually absent (e.g. it's an optional module), it might accidentally find it if you have an appropriately named file in a PATH folder. This could lead to security issues if you put a per-user folder on the system PATH.

Fortunately, loading a DLL by file name only is inadvisable, so well-written programs shouldn't do that.

Based on my Super User answer.

Disabling writes for a program with Low Integrity

Windows processes each have an "integrity level" in addition to a user token. Even if the user has sufficient access to a particular resource, no process can write to an object at a higher integrity level than itself. Most objects have Medium integrity, so processes at Low integrity can barely write anywhere.

To launch a process with Low integrity, you'll need PsExec:

psexec -l -i cmd.exe

That produces a command prompt running at low integrity, which you can see if you do a whoami /all. If you try writing to normal files/folders or Registry keys, you'll get an access-denied error.

.crypt ransomware with mention of "RZA4096"

Today I briefly looked at a small outbreak of ransomware, which fortunately didn't affect me personally. The encrypted files had .crypt appended to their names, and the ransom note had several misspellings, including a mention of RZA4096 (should be RSA). The files are indeed scrambled in some way. Kaspersky's tool to decrypt CryptXXX files does not support these. Stories I found on the Internet indicate that paying will not help, so if you're hit with this, don't pay. Instead, restore from backups, which you totally have, right?

Seriously, make backups now. You never know when some kind of exploit will result in your data getting destroyed.

Less-known way for sites to identify you: Canvas fingerprinting

It's moderately well-known that web browsers include some information about themselves and the system in requests, and that such information can be used to identify ("fingerprint") the user. There are also several less-known pieces of data that can be harvested, including one particularly interesting one.

New-ish browsers support the <canvas> tag, which is a way for web sites to render images and shapes from JavaScript. Different video hardware/software configurations result in ever-so-small differences when instructed to draw some simple shapes. Sites can ask your browser to render things on a canvas and then read the pixel data back to use as part of your fingerprint.

Tor Browser has an option to return blank data when a site tries to read the canvas, thus blocking this potential avenue to anonymity compromise.

SQL string concatenation + unchecked user input = SQL injection

SQL injection is a way for attackers to compromise your database by sending input that causes your query to run SQL code rather than just transferring data.

If you're developing a program that you think might be vulnerable to SQL injection, you can look for two things that together signal a vulnerability:

1. String concatenation - the dynamic construction of SQL commands. The S stands for Structured, which means you shouldn't treat the commands as normal text; they have special structure. There may be a better way to accomplish what you're after without operating on text. For example, parameterization is a solid way to pass any data into a query safely.
2. Unchecked, untrusted user input to the function that builds the SQL query. If you're sure that a procedure will only be called on trusted data (like from other procedures you create that don't take user input), it doesn't really matter whether your own application can do bad things to itself. Functions that do accept possibly-hostile input should either paramaterize queries or implement some really solid escaping (which is harder than you'd think).

If you only have stored procedures, a good key phrase to check for (at least on SQL Anywhere) is EXECUTE IMMEDIATE.

Encryption doesn't help very much if everyone has the key

Let's say you want your app to communicate securely to its server. So you decide to encrypt the data. That's great! But how do you determine the key?

If you hardcode an encryption key into your client and server, you've given it to everybody, including bad guys who want to intercept your traffic. It doesn't matter how much you obfuscate it; the key will get found. Anybody who has the key can decrypt the traffic, and so encrypting your traffic doesn't help at all if you distribute that key freely.

If you have the server send the client the key to use each session, a bad guy listening on the network can grab the key too and use it to decrypt the data. Again, you're then just handing everyone the secret.

The right way to do encryption over an untrusted network with untrusted clients is with public-key infrastructure and key exchange. If you distribute your public key with the client, it can check whether the server is legit (i.e. not spoofed by an attacker). Have the client encrypt a random symmetric key with the public key, then the server will be able to unlock it with the private key, which only the server keeps. Once the symmetric key is securely transferred, you can open a normal session encrypted with it.

Reversing the Sybase SQL Anywhere "SET HIDDEN" action

Yes, it's possible, and not very hard.

Sybase's SQL Anywhere product has a feature that allows the contents of functions, views, stored procedures, and triggers to be obfuscated in an allegedly one-way fashion. When an object is hidden with the SET HIDDEN clause, its contents are transformed into a mash of symbols. Even DBAs can't see the original text, and all the Sybase documentation says the plaintext is unrecoverable.

There is an undocumented feature in Sybase ASE that provides a command in diagnostic mode that can reverse the process. The problem is that SQL Anywhere does not have diagnostic mode or the dbcc command.

At first, I thought that the obfuscation process compiled the SQL into something lower-level, but no. The server program can reverse it, and does so when the object is called for.

Suppose you have a hidden procedure (or an encrypted stored procedure, as I've heard some call it) called SECRETPROC. To make the server load it into memory, you'll need to call it. Some installations of SQL Anywhere come with a tool labeled dbisql.exe that you can use as an interactive SQL environment. Invoke the procedure - it doesn't have to run; I would suggest calling it with a bogus number of arguments so that you don't accidentally run something bad. Then quickly open Task Manager, find the server process (called dbsrv11.exe for me because I'm using SQL Anywhere 11), right-click it, and choose Create dump file.

Once that finishes, open the resulting file in a hex editor (though Notepad might work too). I like XVI32 for such things. Search for the name of the procedure - e.g. SECRETPROC - with correct capitalization. There will be a few mentions of it (and the obfuscated version of it too), keep going until you see one that starts with create function and has a bunch of SQL code after it. Everything from that keyphrase to the next null byte is the stored procedures code.

If you're using XVI32, click on the beginning of the interesting part in the right pane and hold Shift while using the arrow keys to go to the end of the part you want. The text will turn red. You can then use Ctrl+C to copy the data, Ctrl+N to create a new file, Ctrl+V to paste the data, and File → Save to write it out to a new file.

I suppose SET HIDDEN isn't a security feature anymore.

SSL certificate acquisition security and Outlook Online groups

Many organizations that issue basic SSL certificates use e-mail to verify ownership of the domain. Such processes involve sending a verification code to hostmaster or postmaster or webmaster at the domain in question (or its parent, in the case of subdomains).

I know of some enterprise and academic organizations that use Office 365 and Outlook Online for their e-mail. One feature of Office 365 is groups, which can function as faux-addresses that forward all e-mails to the group members. Depending on the settings, users can form and disband groups as they please without administrative approval.

What do those two facts have to do with each other? Well, imagine what would happen if somebody could create a group called hostmaster. Sure enough, that's possible, and it will indeed produce the group address of hostmaster@domain.tld. If the Outlook addresses are at the root domain, anybody who can form groups can effectively pretend to be the hostmaster and create SSL certificates for the domain. A free issuing entity that uses e-mail verification is StartSSL.

What can be done about that? Some things:

• Reserve sensitive group names by creating private groups (so users can't join)
• Don't give normal users addresses at your root domain (do something like ourmail.example.com)
• Disable the group features if you don't need them

Microsoft might want to consider making sensitive names not allowable as group IDs.

If you can install arbitrary software, you're an administrator

Today I interacted with someone who wanted to allow a certain non-administrator user account to bypass UAC and access controls for the purpose of installing software. I explained that there's no way sufficient permissions for installing arbitrary programs can be granted without effectively making that user an administrator.

The first problem is that it's not possible to perfectly differentiate between setup programs and utilities that whack important things. Being able to write to admin-only locations (Program Files, Windows, HKLM, HKCR) also allows one to modify existing programs. An attacker would swap a legitimate, frequently-run program out with a malicious program, then wait for a full admin to run it; then bad things happen and the system is compromised. A user that can create or modify Windows services can execute arbitrary code at the highest level of privilege.

Many think the Power Users group is some sort of magic compromise that allows non-admins to install software, but it's only a small step from membership in Power Users to being a full administrator. This is what Microsoft support has to say about that issue:

"Do not use the Power Users group."

Why can't monitor-mode sniffers be detected?

I answered this Super User question today. It asked about network sniffers that are in monitor mode, i.e. just listening to the Wi-Fi radio signals. Such sniffers are particularly insidious because it's not possible to see that they're listening. See, they're just hearing the same radio signals as legitimate clients, and to do that, they don't have to send anything. With nothing being sent, there's nothing for security tools to look for, and no way to know that bad things are in play.

A similar attack on wired connections would involve a physical splitter. Since that device would operate at the physical layer - the world of electrical signals on the literal wire - no network appliance would see anything different.

Data Recovery Agents and EFS

The Encrypting File System in Windows/NTFS is very nice, protecting user files with a key derived from the user's password. That means that if the user's password is forcibly reset (as opposed to changed), the user will lose access to EFS-encrypted files. That could be a problem.

Fortunately, Windows allows the registration of Data Recovery Agents for EFS. DRA certificates are also derived from a user's password. When an EFS file is created or touched, Windows encrypts the file's symmetric key with each DRA's public key in addition to that of the user. Therefore, even if access to one key is lost, a DRA can recover the file.

Note that EFS does not necessarily prevent malicious programs running as a user from accessing encrypted data. Malware could simply wait for the target file to be opened; it could also register a DRA certificate for a new user, wait for the user to touch some files, and read them with the DRA's account.

Application-Authenticated Databases

I discovered today that Sybase SQL Anywhere has a feature that attempts to authenticate applications. It appears that "OEM Authenticated Edition" is designed to be shipped as a component of other products. If you're only reading from the database (as I was for a long time), you won't notice anything special. 

The "authenticated" part comes into play when clients attempt to write to the database. Writes fail with an "authentication violation" unless a connection variable has been set that identifies the client program. The command to authenticate looks like this:

set temporary option connection_authentication='Company=companyname;

Application=applicationname;

Signature=hexstring'

Once the right authentication string is sent, writes are enabled. Interestingly enough, writes are always allowed in the first 30 seconds of the connection, a kind of grace period. Since I didn't know about this initially, I was very confused as to why some writes would work and then the rest would fail.

Now, you might think that this is a security feature, but it's basically completely pointless in that role. No connection can be established to the database without a username and password, and in most cases read access is plenty. The authentication string is constant for each application and can't be easily changed, so once it's extracted from a client program (or from the network), other applications can just send the right string and be on their merry way. I believe this feature is actually designed to combat piracy, making it a little more difficult to use a database that came as part of a certain application as a generic database server.

Windows 8 Surprise: Domain Membership Disables PIN Login

If you join a Windows 8 machine to a domain, you'll notice that you lose the ability to sign in with a four-digit PIN. If you want to re-enable PIN login, you'll need to enable a Group Policy setting:

Computer Configuration\Administrative Templates\System\Logon\Turn on PIN sign-in

There is a good reason, however, for not allowing PINs. Even if you log in with a PIN, the domain controller needs your full password to let you touch domain services. So, the machine on which you configured the PIN has to store your password and give it to the domain controller when you log in with a PIN.

Since the local system needs access to the password (because you don't enter it), it has to keep it unhashed, using reversible encryption. An attacker with physical access to the machine could find the encrypted password and decrypt it with the machine's key, which also has to be stored somewhere. There are only ten thousand possible PINs, so offline cracking of the password would not be hard. It is generally considered A Bad Thing for access to a single workstation granting access to a domain secret.

You might not want to allow PIN sign-in for your domain.

If there are secrets in your client, you're toast

Programs that communicate over a network to a central server tend to have some type of authentication and access control. That's great, but I've seen several implementations that have no real security, only the appearance of it. Such software usually fits into one of two categories:

1. Client-side security. Programs with this problem rely entirely on the client to check access controls. The absence of checks on the server side means that anybody can bypass the authentication or authorization by throwing together their own client that talks to the server directly, issuing whatever commands the user feels like. Moving the security into the server will probably be a large undertaking for the developers, but it's absolutely essential.
2. Client-held secrets. By "client-held" I mean "burned into the client program." This is a distinct issue from problem #1, though programs with the first often have the second too. Some developers think that obfuscation (to make, say, a string not visibly appear in the EXE) will sufficiently protect any sensitive configuration/information. It won't. A sufficiently determined user can get access to any data that flows through a program running under their own local security context. (Try creating a dump file of a running program and then inspecting that.) This issue also covers "encryption" algorithms that rely on the secrecy of the algorithm to be secure. To remedy this, I suggest using asymmetric-key cryptography and well-known algorithms.

Preempting CryptoWall with Group Policy Software Restriction Policies

The famous ransomware trojan known as CryptoWall does its work by downloading a malicious EXE to the user's temp directory and then running it from there. It doesn't make sense for any legitimate program to be executing from the Temp directory, so we might as well remove that option outright.

That can be accomplished with Group Policy, Software Restriction Policies specifically. Those are under Security Settings, which is accessible in MMC at secpol.msc. You might need to use the "Add Software Restriction Policies" entry on the context menu before the folder can be expanded. When that's done, create a New Path Rule under Additional Rules. Enter %TEMP% as the path and set the security level to Disallowed.

Danger: it's possible to cause great inconvenience with these policies. I am not responsible for anything you mess up. Be careful.

Simple, Effective Copy Protection with Asymmetric-Key Cryptography

Copy protection can be a hard problem, and in the end there's really no way for copyright holders to win. Then again, locks are for honest people, so there is a benefit to licensing checks as long as they are simple to implement and don't cause pain for legitimate users.

Asymmetric-key cryptography can be used to build a simple yet reasonably strong method of licensing enforcement. It can't do much if your users are willing and able to whack the executable to remove the checks, but not many manageable systems can. What it can do very well is make sure that a license key is present and produced by a trusted agent. This is how it works:

• An asymmetric key pair is generated. The public half is burned into the distributed application, and the private half is kept secret with the licensing agents.
• When a copy is bought, some identifying information about the legal owner is recorded, hashed, and signed with the private key. The resulting file is the license key, and is sent to the owner.
• When the application starts, it gathers all that identifying information, hashes it, and checks it by decrypting the signed version in the license file with the public key.

Note that this does require a persistent, unique piece of data to identify an owner, so it works better for server applications (especially ones bound to a domain) than end-user applications.