There is an active attack in the wild for the newly announced Adobe Acrobat and Adobe Reader vulnerability. While the attack isn't widespread, there is always the possibility of copycat attacks. One of the recommended suggestions is really easy to do, so I'm posting it here, and that's to disable JavaScript from within the Adobe application. For instance, with Adobe Reader 9, if you select Edit | Preferences, you'll bring up a dialog menu, one of the options of which is JavaScript. If you click on it,you'll have the option of disabling JavaScript within Adobe Reader. To do so, uncheck the box as show here:
Right now there's not a patch out, but this is one way to minimize your exposure which shouldn't drastically affect productivity. Adobe has said they'll have a patch for the version 9 builds of these applications by March 11, 2009, with patches for versions 8 and 7 to follow afterwards.
Andy Warren points to a TechNet article about Security by Obscurity and wanted me to post some notes. Let's start with the example they used.
Rename the Administrator account:
I agree with Roger's take. We intentionally rename the administrator account because it does stop the malware and scripts. We intentionally rename the administrator account because it allows us to alert easier. We see a hit against administrator, and we know 99% of the time it's not legitimate. That allows our reaction to be quicker.
This doesn't mitigate the need for strong passwords. They still must be there. And the argument that a GPO applies the same administrator rename is only partially true. If you segment your systems in different OUs or you use WMI filtering or you security groups to determine which computers can apply a GPO, you can have multiple GPOs with multiple renames.
What Security By Obscurity Gets You:
Security by obscurity gets you an advantage against automated scripts. Security by obscurity gets you a time delay against an attacker intending to break in. Depending on how the system is obscured (for instance, if you move the HTTP port, the attacker must do a port scan first... which, depending ont he environment, may be detectable). Security by obscurity can get you early notice. For instance, if you don't use administrator anywhere and you start getting audit failures against administrator, you know one of three possibilities is true:
Any of those three you want to know about.
Why It Isn't Where We Should Stop:
But security by obscurity doesn't absolve you of responsibility for taking all appropriate security measures. For instance, if you rename the administrator account but you still have a weak password, the account is still weak from anyone who can browse the system. Therefore, you still secure the password.
Let's apply this to SQL Server.
A script or the worms we've seen will not be able to get to your SQL Server. But assume you have a blank sa password (a complete reliance on security by obscurity). You've stopped the easy stuff. But then you've got that one internal guy who knows the sa password is blank. Even if he doesn't know the port on SQL Server, if he can access the server, he can try a port scan, such as with Nmap. Most of these tools (Nmap falls into this list) allow a very slow rate of fire, meaning they won't get picked up on alerting. Once he finds the port, he can get in. And if this server contains data that's worth some money, he can afford to wait until he finds the port. And then the guy gets in, gets the data, and likely you have no audit trail. Not good.
Therefore, certainly hide your systems; make 'em harder to find. But don't neglect the other aspects of security.
I have a CTP of SSRS 2008 deployed to one of my servers. Today I built a couple of reports and from one of my systems, they all tested fine. However, this system, because it is a testing server, doesn't receive the Group Policy Object (GPO) controlling IE security settings that our standard systems do. Now the IE GPO contains what's necessary to do Windows integrated authentication against our Intranet-based web servers, to include Kerberos delegation. But for whatever reason, the systems which receive the GPO kept prompting users to log in.
One of the issues with troubleshooting is the fact that SSRS 2008 is no longer a web application under IIS. As a result, the places to look for logs, for security settings, and the like are all different. One thing that isn't is that since Windows authentication is involved, the audit failures should still be logged on against the Security event log for the OS. They were. I didn't see any Kerberos pre-authentication errors. The only errors I saw was when the domain/realm picked up the name of the server instead of the name of the Active Directory name. However, there weren't anywhere near the # of audit failures as people were getting prompted. It almost seemed like every time SSRS retrieved a new file (such as an image file) it forced a re-authentication.
Since I needed the reports out for others to use, I rebuilt the reports for SQL Server 2005. This, not surprisingly, meant I had to drop back to Business Intelligence Development Studio (BIDS) for SQL Server 2005. The Data Source was able to publish, but not the reports themselves. The reports were simple queries displayed in tabular form, so it took just minutes to rebuild them, but that wasn't something interesting to see... if BIDS for SQL Server 2008 could publish to a SSRS 2005 server just by switching the Reporting Services target. It wasn't. There may be a way to force it... but I'll wait until next week to look at that in more detail. I'll also troubleshoot what IE settings broke the authentication in SSRS 2008 but which don't break SSRS 2005.
The recent slate of attacks on IIS servers don't seem to be an attack directly against IIS or against SQL Server itself. In other words, they aren't going after vulnerabilities in the server product (either one). Rather, the attacks are targeting weaknesses in the web application which permit SQL Injection attacks. More here:
The reason we're seeing infections on such a large scale is the attackers have been able to automate the attack. This isn't altogether surprising considering the techniques to detect whether SQL injection is successful are rather well known and can be coded for. As to what the injections are doing... basically they are inserting JavaScript which causes the download and execution of a particular file. That file tries a number of exploits against the local computer to attempt to compromise it.
The moral of the story is make sure your web application has solid input validation. If the input was properly handed, the SQL injection attacks would fail. If you're using software that either a large community uses or that you purchased, don't assume it's safe. For instance, a few months ago I took a look at an application a business associate of mine had purchased. Within a couple of pages it was obvious the author had done some input validation to trap whether or not a value coming in was an integer, for those fields which should have been integers, but did absolutely no checking when it came to string values.
