Don Kiely has something to say

I am listening to the Don Kiely interview on Dot Net Rocks and thought that it was worth pointing the security minded toward.  I have known Don for a while from conferences out and about, but hadn’t realized how much he has delved into the Least Priviledge issue until listening to Carl and Rory discuss it with him on the show.


Also highlighted was Ted Neward’s article on least priviledge located on theServerSide.Net which though short has spawned some comments that show the mood on the subject.


Even if you don’t take the advice at least know the issue.

AuthDiag 1.0 is available in its final form!

If you haven’t used it yet then you should get to know this tool.  If you have then you should be happy to know that the final 1.0 version of AuthDiag is now available at http://download.microsoft.com/download/6/c/9/6c96682c-8449-4112-a089-3b98c0035d0c/AuthDiag.msi


When you are using Windows Authentication for a web site it can be mind numbing to figure out what is causing access denied problems, especially if you aren’t a security expert.  While it is an unsupported tool, it usually provides enough to get you past your access control configuration issues.


This link is to the i386, 32 bit version of the application.  If you need a 64 bit version (there are different installers for AMD and Intel 64 bit chips) drop me a line and I will hunt down the URLs for you.


 

Too good to be true…

I was talking to an old friend at the recent Mobility Day held at the Microsoft Office near Boston and he brought up an incident that I have seen happen to others.  I realized though that it isn’t something talked about often so it seemed like perfect blog fodder.


He told me of working with a large bank in Boston (that doesn’t really narrow the list down) where outsourcing was literally a requirement based on the budget.  The code for the bank system was developed by a Russian firm that showed great talent.  Unfortunately they also showed great talent for deciet.  The code delivered had 3 backdoors in it that would have allowed easy access to account data and possibly to money.  After ripping out the offending code after doing a very wise line by line code review the system was deemed safe.  How often has this happened without it being caught?  The X-Files premise, “Trust No One“ is actually correct.  I don’t mean to indicate that only off-shore firms would do this, quite the contrary, but I think the odds go up based on how subject to prosecution the developers would find themselves if discovered.


This also brings up what I think is the biggest fantasy of all.  The one that asserts that open source code is inherently more secure than commercial software.  We have examples from the last 12 months where some of our selfless open source contributors were not so selfless after all.  It should be no secret based on the main subject of my entire blog that I think that security is the place where all the action will be in the next 5 years.  This translates to where all the cost will be as well.


My point is that you must truely Trust No One.  If you decide to use open source because it is cheaper then you are deluding yourself unless you include the cost of doing a complete, line by line code review before implementing it.  The advantage of using commercial / proprietary products is that if you buy it from a company and you make sure it is one that you can sue for enough money to matter if they put in a backdoor, then that is your hedge against the threat.  Always ask yourself the question of what is preventing this developer from putting in a backdoor.


 

Physical Security not a high enough priority…

We regularly do network and application reviews for customers to make sure they know where the security problems are hiding.  I kind of expect to find servers unpatched, applications accepting unvalidated user input and the raft of standard security faux pas on both the network administrator and developer sides of the house.  What get me everytime is when I see physical security ignored or given token attention.


I was once teaching a class on SQL Server when a student jumped up and ran from the room, not to be seen again for 2 days.  I asked what I had said wrong and was told that 16 of his servers had been stolen out of their datacenter.  The datacenter in question had been on the 1st floor and had windows that the theives broke and took the machines at their leisure.  This is an extreme case and it happened back when SQL Server 6.5 was still a new product, but you would be surprised how many companies are still largely ignoring physical security.


Over 50% of hacking is done from the inside.  Physical possession is the ultimate vulnerability.  Unless your system is secured far beyond what is customary using technologies like encrypted file systems, anti-tampering devices and the like, then tools like Lophtcrack will give up the goods in a relatively short period of time.


Take another look at your physical security.  You might have a really solid server room with a locked door, but if the hinged can be removed from the outside, how is that going to deter the soon to be ex-employee from liberating a server over the weekend.


In our company we send out emails at intervals to the staff reminding them of how to avoid unleashing a virus on the network.  We do this before we get nailed by the latest in exploits.  I suggest you remind yourself and your staff about physical security in the same way.  Regularly and proactively, the job you save may be your own!


If you have a physical security horror story you would like to share then please share via the comments.

TechEd style Cabana comes to New England…

Thom Robbins has worked with Chris Pels (and myself as lazy consultant) to create an event that I expect to become as popular as the Code Camps!  They are called Cabanas (all the best ideas are stolen anyways) and the first will be held in the Microsoft office in Waltham (outside Boston).


To register go to here.


Hope to see you there!

Microsoft has released a tool that removes the trojan used by Download.Ject

In case you need a way to clean up after getting hit by the Download.Ject exploit…


Download.Ject malware removal tool released


Microsoft has learned of a Trojan program that is downloaded by the Download.Ject malware, also known as Scob, to client machines from infected IIS servers. When a user visits a Web site hosted on an IIS server that is infected with Download.Ject, the Web pages downloaded to the user’s system contain an additional JavaScript program that downloads another Trojan program to the user’s system. This second Trojan is called Backdoor:W32/Berbew, also known as Backdoor-AXJ, Webber, or Padodor. When this second Trojan runs on the user’s machine, it performs several actions, including:


  – Monitoring Internet access. When the user visits one of several financial or ISP Web sites, the Trojan captures sensitive information—such as log-in names, passwords, and so on—and sends it to a Web server for the Trojan’s author to retrieve.   Installing a proxy server that allows the user’s system to be used as a relay for such actions as sending spam.  Opening fake dialog boxes that prompt the user to enter confidential information such as ATM card codes, credit card numbers, and so on. This information is then sent to a Web server for the Trojan’s author to retrieve.


 Microsoft has released a tool to help you remove Backdoor:W32/Berbew Trojan variants from your computer. You can download this tool from the Microsoft Download Center and run it on your computer to remove Backdoor:W32/Berbew.A, Backdoor:W32/Berbew.B, Backdoor:W32/Berbew.C, and Backdoor:W32/Berbew.D, Backdoor:W32/Berbew.E, Backdoor:W32/Berbew.F, Backdoor:W32/Berbew.G and Backdoor:W32/Berbew.H infections.


This tool is discussed in Microsoft Knowledge Base article 873018. This KB can be found here:


http://support.microsoft.com/default.aspx?kbid=873018


Use it in good health.

RegEx as a way to better data validation

Someone recently sent me a link to an MSDN article about 10 must have tools.  While looking it over I saw The Regulator listed and started thinking about validation of client data.


Everyone has by now heard that you must validate your data from a client before you act on it, but what does that mean.  It doesn’t mean that you just put a maximum length on your input box in your HTML and call it done.  That is no security at all.  Instead you have to do server side checks against what you expected to recieve from the client.  If you then want to go the extra measure and strip out dangerous characters after that then enjoy!  You can’t catch everything with this latter approach.  Take this example.  Suppose you have a page that takes a value and uses it in the where clause of a dynamic SQL Statement (you shouldn’t of course, but people still do).  Now you want to avoid SQL Injection and for some reason have ruled out parameterized queries using ADO.Net.  Given this classic SQL Injection vulnerable scenario, suppose you are trying to defend against the string like: ‘ OR 1=1 –


Single quotes are easy to strip out and in some cases you can even look for the OR as a literal string.  Suppose further that you have a field that asks for age and uses that to execute our dynamic SQL query.  The shrewd (or maybe just lucky) hacker can put in: O’R 1=1 –


Now this won’t destroy your server, but I am trying to prove a point, not educate hackers.  If your home grown script to kill SQL Injection like characters checks for the literal OR it will find that it isn’t present.  The single quote defeats that check, but it also breaks the OR.  If your next move is to strip out single quotes then your own defenses fix the hacker’s statement.  Also since the datatype of the field isn’t text, I don’t need the single quote anyways, that was just a way to put in a character to hide my OR and that you will strip out for me.  This can be done in billions of ways depending on your order of operations.  What this proves is what Erik Olsen of Microsoft has said in the past and I agree with totally, namely, YOU CAN’T ENSURE SOMETHING ISN’T WHAT YOU WANT, ONLY THAT IT IS WHAT YOU WANT.  If I expect an zip code from inside the United States then I check that the value is 5 characters, all of them digits.  Done, I know it is what I expected and can now move on.  If you have to strip something bad out of user data then maybe you shouldn’t strip it out, but instead should reject the request completely?


If any of this sounds reasonable then you really have to get going on your RegEx skills and that brings us back to the utilities list.  Try The Regulator, find something else, write your own or just learn the RegEx syntax.

Fix available for Download.Ject attack…

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.