Microsoft Windows

When a Patch is Not a Fix - We Have the Downadup Worm

If you haven’t heard by now, the “downadup” worm (renamed various other things by competing vendors) is propagating itself like crazy across the Internet. Various software vendors have added some artificial hype about how fast it is spreading, but I didn’t get sweaty palms until I read that US_CERT is now saying that the patch/Technote Microsoft released to address the issue doesn’t work.

Here’s how it’s going so far - the worm installs itself via the “autorun” feature that is enabled whenever removable device is connected to a computer. This includes, but is not limited to, inserting a CD or DVD, connecting a USB or FireWire device, or mapping a network drive. This connection can result in code execution without any additional user interaction.

So Microsoft issued an out-of-cycle patch that wasn’t really a patch or a fix - just a workaround. The patch/fix/workaround involves disabling the autorun function inside the Windows registry. The instructions in the Technet article 91525 were incorrect, and did not disable autorun.

So if you’ve done this on your network, and think you are safe…..you’re not.

A newer Microsoft Technet article is available here.

At first I was confused, because the article provides instructions for a way to disable autorun as a “workaround” against the worm propagating itself. The information does not address the vulnerability the worm is actually designed to exploit.

After some more digging, the actual vulnerability we should be concerned about is that the worm employs an attack against the “server” service listed as a Bulletin in October 2008. The exact details from the Security Bulletin MS08-067 are as follows:

“This is a remote code execution vulnerability. An attacker who successfully exploited this vulnerability could take complete control of an affected system remotely. On Microsoft Windows 2000-based, Windows XP-based, and Windows Server 2003-based systems, an attacker could exploit this vulnerability over RPC without authentication and could run arbitrary code. If an exploit attempt fails, this could also lead to a crash in Svchost.exe. If the crash in Svchost.exe occurs, the Server service will be affected. The Server service provides file, print, and named pipe sharing over the network. The vulnerability is caused by the Server service, which does not correctly handle specially crafted RPC requests.”

It seems the only “solution” we are offered from Microsoft for users of anything other than Server 2008 is a manual fix to try and stop propagation.

Where’s the real fix? Not the workaround (which didn’t work). Am I missing something? “Where’s the beef?”

Don’t Be Seduced Just Yet

I had a co-worker ask me yesterday what my opinion on “cloud computing” is, and whether it should be something they could recommend to clients. He had seen announcements about cloud computing from Microsoft

According to a 2008 paper published by IEEE Internet Computing “Cloud Computing is a paradigm in which information is permanently stored in servers on the Internet and cached temporarily on clients that include desktops, entertainment centers, table computers, notebooks, wall computers, handhelds, sensors, monitors, etc.” Another criteria is that it be massively scalable.

“Cloud Computing” is almost the same as “SaaS” (software as a service), the difference being, according to Gartner, scalability.

What I found the most interesting was the statement from Microsoft: Windows Azure provides developers with on-demand compute and storage to host, scale, and manage Web applications on the Internet through Microsoft® data centers. (the bold emphasis is mine.)

So, a business runs all it’s core applications and stores all it’s data on Microsoft’s servers. Windows is actually developing Azure as a separate platform from Windows server and desktop apps. It’s all accessible anywhere from the Internet. I guess Microsoft has decided to get into the Data Center business arena along with IBM and HP.

This is probably a silly question, but what do you have if there is no Internet access? There seems to be a massive assumption that all business functions can be run over the Internet.

The ONE statement about security on their opening page was: Security supported by flexible Code Access Security policies and The built-in management services give monitoring and tracing capabilities.

That’s IT???? I admit it is a page pitched to software development, but shouldn’t secure software development and the security of data centers be in there anywhere? The FAQ offered up nothing on that topic, as well. It did, however, offer up pricing.

So, I’m going to be terribly cynical and say that this might be Microsoft’s approach to controlling the rampant software piracy of their products going on all over the world. How about promoting it as a “more secure platform?”

Other than being a marketing ploy, “cloud computing” sounds like “thin client” writ large. There may be some significant financial savings, if you have the right kind of business to use this platform. AND you want to turn your data security over to Microsoft.

Microsoft’s only mention of “risk” - Windows Azure provides you, the developer, with a scalable platform and a rich development environment that allows you to focus on the business logic of your application without worrying about operational constraints or lock-in,” didn’t get me to “wow.” How often has security lagged far behind software development and what is Microsoft doing to change that? From this announcement, nothing.

Host vs. Network IDS

I’ve noticed a definite tendency for organizations to move to monitoring network traffic with their Intrusion Detection Systems. It’s a lot easier than trying to update a host IDS service/agent and keeps the increased CPU at the monitor, where it belongs. Also, host agents are limited by what the operating system is willing to log.

Windows, for instance, will give you hundreds of logging messages that actually have no useful information for an IT Admin or Auditor to review. The setup of their Event Log auditing mechanism is still klugy, outdated and difficult to interpret. (Micro$oft, are you listening?). I can’t say I get to wow about UNIX either, and FORGET anything like logging with Novell.

So, why bother? I still think that a host IDS has a place, because there are things it can watch for that you will only see on the server. For instance, if someone is doing brute-force against the administrator account. If someone has made Active Directory changes who should not be in there.

How would you tell if someone added themselves to the Server Operator group? (where I’d go to look around and maybe get my hands on a SAM database). If you’ve got an Event Log monitoring function, you could pick it up that way, but wouldn’t it be nice if the IDS would pick it up? If you just installed a host IDS on certain critical servers? There’s lots of options if you step out of the all-or-nothing approach.

Speaking of which, monitoring development and test servers really does have to be included. As much as we’d like to forget that they’re there, that’s the first place hackers look. As a penetration tester, I can attest to that, as well. Patch ‘em, monitor ‘em, they’re on YOUR network.

Auditing MS SQL - Roles, and Why They Matter

SQL “Server” runs on top of MS Windows, and it has groups inside of it that are not seen on the Windows server or even the Windows Domain. That’s why we have to check and make sure that inappropriate users don’t have complete access to everything inside the database. Not everyone should be looking at those payroll files!

So, to confuse us a little more, instead of calling them groups (like Users, Administrators, Power Users, etc) SQL calls them “roles.” There are roles based on SQL as a whole (the SQL “Server”) and roles based on individual databases. Kind of like Domain Admins vs Local Admins.

SQL Server roles are equal to Domain Admins inside SQL Server. They give rights to many different core functions of SQL, and the sysadmins role has rights to everything inside SQL. By default, sa is here, but you should look very carefully at any other user in this group. DBAs like to give themselves a “backdoor” into the server this way, but that should be removed. Best practices recommend always having the DBA use their Domain ID for insertion into this role. This way you can log and monitor their access, and when they leave the company and their ID is disabled, they won’t be able to access the SQL databases. It also let’s them know that you are watching, and people tend to behave better that way.

I have found that software developers LOVE to put their names in this group, and not their Domain IDs, either. If it’s a production database, they have no business having anything other than SELECT rights anywhere. Kick ‘em out!

Here’s the SQL Server roles default permissions:

Fixed Server Roles
Sysadmin – can perform any activity (and Builtin\Administrators are part of this group by default)
Serveradmin – can set SQL-server config options and shut down SQL Server.
Securityadmin – manage logins and CREATE DATABASE permissions, read error logs and change passwords (within SQL, not Windows)
Setupadmin - manages linked servers and startup procedures
Processadmin – can manage processes running in SQL server
Dbcreator- can create alter and drop databases
Diskadmin - can manage disk files
Bulkadmin - can execute BULK INSERT statements

How do you find out who is in these roles? Use the results of a stored procedure: sp_helpsrvrolemember with the results taken from the Master database.

For individual databases, there are database roles. People in these roles can be all powerful, but only within that individual database, not all of SQL. How do you know how many databases are inside one SQL Server installation? Again, a stored procedure: sp_helpdb

You’d be surprised how DBAs like to create their own little mini databases (on production boxes!) just to “do things.” They may be great “things,” but those databases need to go somewhere else.

In order to see the members of all the database roles, run another stored procedure: sp_helprolemember run from each production database in SQL Server. It’s a little tedious, but you will get the information you need.

I commonly monitor the membership in the db_owner role (equivalent to a local server Administrator). By default, the dbo, or db_owner is the only one in this role. If the DBAs are already sysadmins, they don’t need to be in this role, unless you want to be very granular in your controls (NOT a bad idea). Developers shouldn’t be in this role, or just as bad, the application ID of an application accessing data.

This is where a lot of software development falls off the security bandwagon. If the application ID is db_owner, it means that the ID has access to everything in that database. If I can acquire the application ID’s password, (and some of them don’t have one) I can get into all the data. I wouldn’t use the application, just connect directly via ODBC or even Excel.

It’s easier to write applications using the application ID as db_owner, but unless you are using middleware to vet everyone’s login via the Windows Domain, you take the risk of losing all that confidential data out the back door.

If you can acquire this information on a quarterly basis, you will go a long way towards having an easy audit and a better night’s sleep!

FREE Tools for Auditing MS SQL Server

There’s a lot of really nice application tools to audit SQL databases out there. They have lots of bells and whistles and write out a really nice report with professional formatting. If you’ve got one of those, LUCKY YOU. But most of us Admins and Auditors have to scrounge for what we can find with the budget we’ve got (read $0).

So I always like to start out with SQLPing A nice tool from SQLSecurity.com that scans the network both actively and passively, testing SQL’s default listening port 1433 and it reports on what it finds (nothing fancy, just text). This includes those desktop versions of SQL Server: MSDE, that are often configured with SA-no password. This tool will tell you what version SQL is running, and will even do a test for SA-no password. Since SA cannot be locked out, you won’t damage the server with one attempt.

NOTE: Check with your network administrator before running this test. It’s also a great test of your intrusion detection system, because, if the IDS is configured properly, it should catch it and alert for it. Make sure management knows you are using this, if that’s what you’re going to use it for. No IDS? No worries.

I also recommend SQLSecurity. com for a lot of great information and scripts for DBAs. They know all about SQL Injection (Unlike a CIO I recently interviewed three years ago) and they have lots of MS SQL information well worth your visit.

The other free tools I use are found inside SQL Server. Yes, inside the SQL database, and they are called “Stored Procedures.” This is a fancy name for pre-written sequenced query language batch files. The folks at Microsoft have done us all a great favor by writing hundreds of them. Inside the Master database are the stored procedures you want to run, or have a DBA run for you and output to .csv format files. (Each database also has stored procedures, but the Master database SPs are the ones you want.) There is a table full of them, and here are the ones I use:

sp_helpdb Names and file locations on the Windows server of all SQL databases. (And you should find out who or what has access to those files)

sp_helpuser Review usernames, groups the user belongs to, and their default login database.

sp_helplogins a. Identify and review any external users and groups; b. Look for mappings of login name to UserOrAlias or as DB Owner. c. Check AUser and ARemote columns to identify who has remote access to what database.

sp_helpsrvrolemember Users and groups assigned to each server role (More on this later)

sp_helprotect Permissions in the database. Examine this list carefully for what rights are granted and denied to whom.

Get the results of these queries, results from the last post, and SQLPing. You’ll have some very interesting items to review. and remember, Google is your friend.

Dear Network Administrator - Please Change Your Password Like Everyone Else!

I have a nifty little .vbs script I wrote last year. I send it to the network administrators before I come on site, ask them to run it and send me the results. It tells me username, login ID, description, length of password, last login date, acct locked, etc. It also tells me when the last time the password was changed. I use it to check for terminated users still on the system and that password controls are indeed what they say they are.

In the last 9 out of 10 Windows Domain IT audits, what group of people hasn’t changed their password(s) in over a year (sometimes two)? You guessed it. The last network admin got a little huffy, when I inquired, and replied, “We do comply with corporate policy! We just change them manually.” She cc’d my boss and her boss. Ouch.

I guess she didn’t read the file she sent me: it’s right there in plain text - the exact date. I copied and pasted her team’s last change dates, simply replying to ALL, and referencing the attached file. I try to be polite when watching someone loudly and publicly announce how badly they want to eat their shoes. After a pregnant day of silence, she came back with a very polite response telling me they were designing a new group policy just for their group to ensure passwords were changed in compliance with corporate policy. I could tell the shoe leather wasn’t very tasty.

I’ve done it too, as an administrator; somehow we don’t think that the rules should apply to us. After all, we’re the good guys! How, a non-engineer might ask, do they circumvent the group policy? Simply go into the administrative interface and select the checkmark for “password never expires.” All done.

As an IT auditor, I represent my company’s standard for IT, and so does a network administrator. If I am not following the rules, why should anyone else? Network Administrators have the most powerful rights on the network - capturing their passwords would allow a thief into everything. And the longer you don’t change it, the more time people have to work on getting it.

Plus, it just makes us engineers look bad.

P.S., the next most common group of non-changers? CEOs.

Call me “Kernel” Patch

One of the junior members on my audit team likes to rag me about how often I harp on patching at various client sites. He started out by calling me “Captain Patch,” but I pointed out that I like “Kernel” much better. Why have just a nickname when you can make a really good pun with it too?

It’s easy to say, “Patch your servers.” Beware of the auditor that lays that one on you and walks off; it’s NOT a one step process. Patches can break things and breaking things in production, especially if you’re running custom software on those servers, can be a disaster of large proportions.

Some years ago at a bank I was working at, our outsourced network team started patching servers over the weekend. Unbeknownst to them, the patch updated a driver for the disk array on our Compaq servers with one that didn’t work. Install patch….no server. A server won’t boot if it can’t find the disk to load the software!

About 25 servers were “patched” before they realized the problem. Since they were in Texas, a whole lot of us got out of bed in Boston and headed to the Bank to try and discover the cause of massive server failure. That was a very long weekend.

You gotta have a plan! And it needs to be a fast one, because bad guys start reverse-engineering the code the minute the patch is released. And the plan has to test those patches to make sure everything works, before deploying to production.

“We don’t have test boxes.” Of course not. I used development boxes, (announcing it first), then after 24 hours, if nothing had broken, it went to the backup production boxes across the continent. If all went well, changes could go into production for highly critical patches in less than 48 hours. Use secondary Domain controllers, file servers, database test servers, etc. The most critical server gets patched last, but fast.

If you’re running a critical application with outsourced software, write it into the contract with the vendor that they will test patches quickly and update you so that your servers can be patched. If you sign a contract without this requirement, shame on you!

Decided not to apply a patch for Media Windows v.exty xx? OK, but who made the decision to bypass certain critical ones? You’ve got to document what didn’t get patched and why. Otherwise, you could be the one called on your vacation by a furious boss with a broken server. Or, God forbid, a hacked one.

No excuses. Figure out a plan, draw up a procedure, and save yourself major headaches.