Now there is an even more dangerous exploit for jpg files. Details can be found here.
I have seen an example of this exploit in action. In the demo I got from our security team, displaying the custom crafted jpg image caused the workstation to reboot.
If you didn’t take the last reminder to patch seriously, I urge you to get it now.
Now I have heard it all! Terrorists, Hurricanes and now JPEGs can be used to attack your computer!
To see what I am ranting about check out the article.
I just finished reading an upcoming article from Forbes Magazine (unfortunately you will have to register to read it before the September 20th pub date) about the belief that terrorists are turning to hacking as their next major vehicle to do damage.
In the article they point out things like, “The FBI says the cyberterrorism threat to the U.S. is “rapidly expanding.” “Terrorist groups have shown a clear interest in developing basic hacking tools, and the FBI predicts that terrorist groups will either develop or hire hackers,” Keith Lourdeau, an FBI deputy assistant director, told the U.S. Senate earlier this year.”
The article also mentions a company that I have had dealings with in my consultant travels. Invensys makes valves and regulators and such. Exactly the kind of equipment that a bad guy would want to manipulate.
Scary, but maybe I’m not too old to get back in the service after all…
The Software Development Life Cycle (SDLC) is a well established and well thought out concept. There are books and experts and cool slides galore that talk about it and how security should fit into it. The problem that I see is that the process as most people think about it isn’t cyclical enough.
Most of the treatment of the subject shows the process ends on acceptance of the product. This means that it is in general use, the major bugs that will be fixed have been and the users are active with the application. This status remains until the application is either revised or retired. You can’t live that way anymore. If you have an application that is waiting for a revision in the future or making its way to retirement, I would be willing to bet that it has already outlived any security analysis done during its construction. How many new threats exist today that weren’t around when existing applications were being developed. How many measures were taken as fully adequate just a year ago that we now see still leave us in the lurch against a determined attack?
If you have an application in production that hasn’t been revised for security in some time you may want to at least take a mental inventory. The C levels in your company won’t understand that your application was secure when you released it. They will only see that it was not secure when it was attacked.
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.
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.
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.
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.
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:
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.
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.