AJAX and Security, Revisited

In the last two days I’ve started to notice a number of articles detailing security in an AJAX application. Apparently there are a lot of people out there touting AJAX as this super-secure way of serving content on the web. And then there are those that are touting it as less secure than traditional DHTML sites. Mike Kemp of Heise Security warns that AJAX can open you up to attack while Jeremiah Grossman of Whitehat Security explains that AJAX is no less secure than traditional DHTML.

But let’s look at the reality of the situation. Regardless of the language and methodology used, security still breaks down into some fairly straightforward concepts :

    1. Never trust the client
      • In simple terms, consider the user of the application to be the enemy. Double check everything the user sends you and make sure that what they send is acceptable. Be as restrictive as possible because even the simplest mistake can be costly.
    2. Design using the Defense In Depth approach
      • Defense in depth is a security strategy in which you use multiple layers of defense to prevent attacks. This type of strategy goes beyond the web page you are trying to serve and encompasses the network as well. Simply put, you design your security to run at each layer. What this means is that instead of just checking input at the server level you instead check it at every layer the data interacts with. While this means more code, it can also mean more security. If someone was able to get through one layer, it doesn’t mean they’ll get through the next.
    3. Test Test Test
      • Before you release your application, you test it. Add security penetration testing to your test suite. Attack the application from every angle you can think of and, if possible, have others attack it as well. It’s very hard for a programmer to check his own work for security flaws because he knows what the program is designed to do and what security code has been put in place. Having someone else test your application can reveal security and application bugs that you as a developer would never find.
    4. Keep up with current technology
      • Keeping up with technology is one of the best ways to learn how to secure your applications. I highly recommend reading security related programming books, blogs, and news to find out about new techniques, reinforce old techniques, and, most importantly, to keep security at the forefront of your mind. If you’re not thinking security, then you’re likely to make simple mistakes that can cost a lot in the long run.
    5. Make sure your tools are up to date
      1. The tools you use can be the source of security bugs if you don’t keep them up to date. A great example of this are the APIs you use within your programs. If you link to old versions of the APIs then you may be susceptible to security and application bugs that were fixed in later releases. APIs are usually a black box item, so make sure you check into the API before deciding upon it’s use.

These are just a few ways to make sure you’re maximizing security in your code. There are many other lists out there, but you’ll find that they all come down to the same few basic principles. Never think that your program is 100% secure, there’s always a way to attack it. You just need to be more diligent than the attackers.

ZERT Patch for IE Vulnerability

ZERT is back at it again. They’ve released a patch for the latest Microsoft Internet Explorer vulnerability. Actually, it’s more of an automated script that disables the ActiveX controls that are vulnerable. Much easier than hand-editing the registry. Check it out if you use IE.

More IE Exploits

Another day, another Microsoft exploit. This time it’s an exploit in the WebViewFolderIcon function. So far this only seems to affect Internet Explorer, or more accurately, ActiveX. The vulnerability in this instance is an integer overflow in the COMCTL32.DLL file which means that other attacks, possibly more serious, may be on the way. COMCTL32.DLL is the “Common Controls” library used in many Windows applications. This is the same library that displays the list boxes, combo boxes, etc. in Windows. Saying this is an important DLL may be quite the understatement.

 

The Internet Storm Center has more details about this vulnerabilty and some recommendations as to how to fix it. In short, they suggest keeping your Anti-Virus up-to-date, and setting some killbits. Killbits, however, are not for the faint of heart. Unless you really know what you’re doing, my suggestion is to drop IE for the time being and switch to another browser. Firefox is my browser of choice, but you can use whichever you’d like. If you absolutely need to use IE for specific web pages that you can trust, then I suggest checking out Firefox and the IE Tab extension. With that, you can create a list of sites that will be displayed in IE while the rest are displayed using the Firefox engine.

 

Microsoft has acknowledged the vulnerability and is working on a patch for it. Again, they promise an October 10 release. Hopefully they see reason once again and can patch this as soon as possible.

IE VML Exploit Update

Kudos to Microsoft for releasing a patch for the recent VML security bug (CVE-2006-4868). The patch is available for download via the MS06-055 Security Bulletin they released earlier today.

 

I’m impressed that they thought this was a severe enough problem to warrant an earlier release than the October 10th date they stated in the original Security Advisory. They have updated the original advisory and removed most of that content, however, so you’ll just have to take my word for it. And, funnily enough, they apparently used the cut and paste approach as the current revision points this out as the “Powerpoint Mso.dll Vulnerability” and not the Vgx.dll vulnerability. Well, noone’s perfect..

 

Now get out there and patch! And while you’re at it, check those anti-virus definitions and make sure those are up to date. And if you don’t already have some sort of firewall, get one!

Internet Explorer VML Vulnerability

Looks like there’s yet *another* IE vulnerability on the loose. This particular vulnerability uses a bug in VML (Vector Markup Language) to cause a buffer overflow and allow the attacker to gain access to the system. I’m a little late to the scene, but this was initially reported on September 18th. But FEAR NOT! Microsoft has happily released a security advisory in which they explain that they know about the vulnerability, and that they’ll release a patch on October 10th.

 

.

.

.

Umm.. October 10th? That’s almost a month *AFTER* the report was made public.. This happens to be a really nasty bug that can cause your computer to be completely compromised and they admit to knowing about code in the wild exploiting this bug!

The person who reported this was not being irresponsible and revealing a “potential” security issue the the hacker community. Quite the opposite, in fact, they were reporting a known in-the-wild exploit with the intention of informing the masses so they could act accordingly. For Microsoft to not release a patch quicker, or even publish some viable mitigation strategy is incredibly irresponsible. At the very least they could explain how to unregister the VGX.DLL file that is the source of the expoit. Luckily, Sunbelt has instructions on how to do this.

If you’re interested in a better solution, ZERT (Zeroday Emergency Response Team) has created a patch to fix the problem. Be aware that this is not sanctioned by Microsoft and is supplied As-Is. However, if you rely on IE and want a reasonable sense of security, this may be your only choice until the behemoth from Redmond decides to release an “official” patch.

My recommendation? Switch to something else. There’s Firefox (my personal choice), Opera, and others. IE just has too many problems.

 

If you’d like to read more about this vulnerability, check out these links :

 

SunbeltBLOG – These are the guys that first reported the problem

TaoSecurity – A report about ZERT and how they’re proving that the closed source security model is broken

eWeek – A report about the vulnerability and the patch that ZERT created

 

I also want to point out that I’m not necessarily anti-Microsoft. I believe they’ve helped out the computer industry in many ways. However, I dislike many of their practices, and this is definitely one of them. It’s important for any software developer to release security patches when necessary. It is of utmost importance for a closed-source developer to release security patches as fast as possible because they’re the only ones who can truly patch the hole. Open source allows anyone, with the necessary skills, to patch the hole. I’m not saying Microsoft should open-source Windows, but maybe they should work a little harder to put together patches with more speed.

The Patchwork OS

Twelve patches, Twenty Three vulnerabilities.

Tuesday was Microsoft Patch day. Of the twelve patches, nine were for the Windows OS, two for Office, and one for Internet Explorer. A breakdown of the severity of each patch can be found on the ISC Website.

 

I mention this because of the severity of these flaws. There is already an exploit in the wild taking advantage of MS06-040, a flaw in the Server service. This is yet another flaw in the RPC functionality of Windows. Ports 139/tcp and 445/tcp are again the attack vector used to exploit this. For those that remember the past few years, these ports are notorious for being used as vectors to exploit the RPC service. Most commonly associated with Netbios, these are probably the most blocked ports on the Internet.

In addition to the above gem, there are also vulnerabilities in DNS resolution, the Windows Management Console, and more. You can find more information on all of these exploits at the link mentioned above. I highly recommend patching your system ASAP since exploits are in the wild and this could easily turn into another Blaster style attack. Even the Department of Homeland Security is recommending that you patch immediately. According to some reports, Microsoft is already bracing for an attack.

 

I find the frequency and number of exploitable bugs in the Windows OS to be disturbing. Linux and OSX have bugs, but nothing as frequent as Windows seems to have. A lot of the reports that compare the various operating systems seems to miss the fact that Windows as an OS (minus any Office or IE patches) has a higher number of critical exploits as compared to Linux or OSX. Often the exploits of other packages such as apache, ftp, etc are lumped in with the Linux count and assumed to be part of the OS. While most Linux distros ship with much more than the Linux Kernel itself, it’s unfair to count those exploits as part of the whole. Other reports seem to realize these facts and produce results much closer to the truth.

I think, however, that Microsoft has helped the computer industry. They helped popularize the personal computer and provided much of the software for the initial PC boom. They have invested billions of dollars into creating their products and bringing them to market. But, I think it’s high time for them to make some major changes. I would like to see them embrace the Open Source community and learn how to build and market open source products. If they embraced the Linux OS and helped extend it instead of fighting against it, I think the computer industry could take another giant leap forward. They can certainly continue to create and sell the various applications they currently have, and even produce new ones. The very act of running their apps on a Linux system may help to enhance security across the entire industry. Linux itself has proven to be very resilient to attack.

One of the biggest myths about Linux seems to be the belief that all software running on a Linux system has to be open source. Nothing could be further from the truth, however. It is certainly acceptable to run closed source products on an open source OS provided that you play within the rules. I’m not 100% clear on all of the ramifications of the GPL license, but as I understand it, you are permitted to modify any OSS product out there provided you make the source available. But, I believe you are permitted to build closed source apps using OSS libraries and not distribute the source *if* you use unaltered versions of the libraries. I may be wrong here, so please correct me if I am. Regardless, the ability to write closed source programs that run on an OSS platform definitely exists.