Microsoft has released a Knowledge Base article, 870669, that describes how to implement a change manually that will disable the browser’s capability to leverage the ADODB.Stream object.
This could be a painful fix for many organizations as you may be using that object for certain file based Intranet applications. Best thing to do is test the fix and see if anything you care about breaks. Then you can roll it out. There are steps at the bottom of the article that describe undoing the change, but this is a nasty exploit (manages to steal passwords and the like) so I wouldn’t wait long before paying some attention to it.
I have recently been asked by a deeply knowledgable friend of mine, Malek Kemmou, about the latest in Intrusion Detection software. I realized that if he was curious, then this might be a topic worthy of a few words…
The bad news is that there is not much out there really that can serve as a silver bullet. Alot like the Anti-spam software when it first started coming out, there were alot of players, but they all used the same basic technique. In the case of detection software we are in much the same place. Hackers leave footprints if you are logging (both on the OS itself and on the web server). If the logs are not configured or configured incorrectly then it is like having video cameras without film, they won’t help you solve the crime.
A further problem is that more elite hackers tend to alter the logs after they are done (wiping the gun clean so to speak). Step 3 (step 1 is to turn on logging, step 2 is to configure it appropriately) is to secure the logs from being altered (or dumped) by an intruder.
Products like GFI LanGuard will publish white papers (see the link) on why they are the best, but mostly they are the same. You could interpret most logs yourself until they get beyond a certain size.
You can even just submit your logs to DShield.org (been around since Nov 2000) and they will analyze them for you. Some interesting statistics come out of looking at the data from so many firewalls and web servers. If you go there note that they are currently reporting Survival Times of 22 minutes (The “Survival Time” is the average time between attacks for our average submitter. An unpatched PC will survive about that long before it will be infected with the worm of the day).
Here is a nice little article from the guys at Foundstone, http://secinf.net/info/misc/tricks.html, that should give you some tips on what you (and the detection software) should look for beyond the obvious “cmd.exe” in your standard IIS logs.
If you are using something you like, let me know, I expect this space to get pretty heated in the next 18 months as awareness rises and drives demand.
Jeopardy Answer: What are 3 things that don’t go together easily!
If you feel the need to host ASP.Net on a windows domain controller and can’t bring yourself to upgrade to version 1.1 then at least read this KB article. The crux of the problem is that domain controllers on IIS 5.0 servers (i.e. on Windows 2000) don’t have local accounts for the ASPNet_WP.exe process to run under. You have to create your own weak account or assign more privileged accounts (bad idea).
I heard as recently as tonight about someone fighting this issue (it is always tough when the solutions are all security tradeoffs to some extent), but reportedly with .Net 1.1 (we are verifying). As a rule I don’t put ASP.Net apps on domain controllers, maybe that is just a rule we should all accept if we don’t like the other options presented?
Alot of sources say that you should rename your administrator account on your windows systems and windows network. While I agree with this wholeheartedly, you need to take the war to the hacker.
First, renaming the administrator account to admin or adm or something equally obvious when seen doesn’t cut it. You need to get evil. If you rename the account (and you should) then rename it to something indistinguishable from the rest of your accounts. Remember that internal threats are real and your uses can usually see the entire user list. Pick someone you went to school with that will never work for your company (at least not while you work there) and rename the administrator as if it were that person’s account according to your standard naming practices. SJones for instance for Susan Jones. Also fill out the record with a description, etc. For larger companies you want to make this impossible to discern by a typical user from someone working in a remote office or maybe a temp that never got deleted. Understand that this is easiest when you first setup the machine or network, but can be done long after if you can bring yourself to do away with using the Administrator account for services or regular network maintenance.
So now you have an administrator that no one can identify from just looking at the user list. The SID for the administrator account is still the same and we can’t do much about that, but we take what we can get.
Next move is to create a new account named Administrator. Give it a nightmare password (14 or more characters with mixed case and symbols everywhere) and then turn on auditing for failed logins at a minimum. Now you have setup a scenario where no one has any business using the administrator account for anything except hacking.
If you follow this tactic for all privileged accounts so that Exchange runs under MKelly and SQL Server runs as PRobinson then you have just taken a lesson from Sun Tzu and applied it to your system security. Machiavelli would be proud!
More than a year ago, I spent a day or two wading through WSE 1.0 (hence the title) to prepare a nice demo for a talk on GXA that Andrew Brust and I did at CeBit held in NYC. In my travels, I reviewed Tim Ewald’s white paper called “Programming with Web Services Enhancements 1.0” and soon thereafter I found a wonderful resource courtesy of Dan Wahlin at http://www.xmlforasp.net/codeSection.aspx?csID=81. Dan has put together a streaming demo that I classify as the moral equivelent of a WSE Hello World (I mean that in a good way in case you miss my meaning). I consider Don Box’s “Understanding GXA” the primer that the above resources really compliment if you want to know from a developer’s perspective what the deal is with WSE.
I often get asked how a developer can go about getting security savvy. Understanding the concepts of WSE is an important stop along the way.
I haven’t seen a valid link to “Understanding GXA” lately. You will have to settle for the latest found at http://msdn.microsoft.com/webservices/building/wse/default.aspx.