Category: Security

Windows .ANI Vulnerability

Another day, another vulnerability… This time it’s animated cursors. You know, those crazy animated cursors Microsoft included in one of their Plus! packs back in the day?

Well, it seems that there’s a stack overflow exploit in the way they’re handled by the OS. In a nutshell, when it copies the data into memory, it doesn’t properly check the size of the memory being copied. The result is that memory is overwritten and the stack overflows.

The Zero-day Emergency Response Team has a pretty good writeup on their site about the exploit as well as a patch to resolve the problem. This is a pretty big security issue, so I recommend at least checking out the info on their site.

This vulnerability affects Windows 98, 2000, XP, Server 2003, and Vista. The Internet Storm Center also warns that other unsupported versions of Windows, probably Windows 95 and ME, are also likely affected. Neither ZERT nor Microsoft are likely to release a patch for Windows 95 or ME. Additionally, they have a nice matrix that explains which mail clients are vulnerable to this as well.

Microsoft has released an out-of-cycle patch for this vulnerability. You can find the relevent files on their advisory page, bulletin MS07-017. Patches for Windows 2000, XP, Server 2003, and Vista are available. If you still use Windows 98, the ZERT patch is your only option.

Update : eEye had released a patch back on March 30th for this vulnerability. However, this patch only ensures that .ANI files are loaded from the SystemRoot and not anywhere else. While this helps prevent most exploits, if an attacker can somehow gain access to the SystemRoot, the system is still vulnerable.

Please take special note : This is being actively exploited in the wild. This is a serious remote access vulnerability which can lead to your computer being compromised. Please make sure you have an anti-virus program installed and up-to-date. And remember, your first line of defense is you. Be responsible, know the risks, install the patches, and keep yourself safe.

Book Review : 19 Deadly Sins of Software Security

Security is a pretty hot topic these days. Problems range from zombie computers acquired through viral attacks, to targeted intrusion of high-visibility targets. In many cases, insecure software is to blame for the security breach. With the increasing complexity of today’s software and the increased presence of criminals online, security is of the utmost importance.

19 Deadly Sins of Software Security was written by a trio of security researchers and software developers. The original list of 19 sins was developed by John Viega at the behest of Amit Yoran who was the Director of the Department of Homeland Security’s National Cyber Security Division. The list details 19 of the most common security flaws that exist in computer software.

The book details each flaw and the potential security risks posed when the flaw exists in your code. Examples of flawed software are presented to provide an insight into the seriousness of these flaws. The authors also detail ways to find these flaws in your code, and steps to prevent the problem in the future.

Overall the book covers most of the commonly known security flaws. These include SQL Injection, Cross Site Scripting, and Buffer Overruns. There are also a few lesser known flaws such as Integer Overflows and Format String problems.

The authors recognize that software flaws can also consist of conceptual and usability errors. For instance, one of the sins covered is the failure to protect network traffic. While the book goes into greater detail, this flaw generally means that the designer did not take into account the open network and failed to encrypt important data.

The last chapter covers usability. The authors detail how many applications leave too many options open for the user while making dialogs cryptic in nature. Default settings are either set too loose for proper security, or the fallback mechanisms used in the event of a failure cause more harm than good. As the Microsoft Security Response Center put it, “Security only works if the secure way also happens to be the easy way.”

This book is great for both novice and seasoned developers. As with most security books, it covers much of the same material, but is presented in new ways. Continual reminders about security can only help developers produce more secure code.

[Other References]

10 Immutable Laws of Security Administration

10 Immutable Laws of Security

Michael Howard’s Weblog

John Viega’s HomePage

the squirrels are nice here…

I ran across an article over at Slashdot about a recent incident involving a Republican aide, and members of attrition.org. For those that don’t know, attrition.org is a computer security oriented website that attempts to expose industry fraud and misinformation. This particular story finally made it to the “traditional” media yesterday.

So, on to the story. Apparently a Republican aide, Todd Shriber, decided that he wanted to have his college grades modified slightly because he didn’t do to well. So Mr. Shriber contacts attrition.org, having read some of the postings on the site and thinking that they were hackers. His initial email was sent on August 9, 2006.

Jericho and Lyger from attrition.org quickly begin leading the aide on and gathering the “information” that they will need in order to pull off the job. The information included the usual stuff like name, student id, date of birth, pigeon and squirrel pictures… Wait, pigeon and squirrel pictures? Yes, you read that correctly.. Jericho asked Mr. Shriber to forward him “A picture of a squirrel or pigeon on your campus”.

This request for pictures should have thrown up red flags all over the place, but apparently not for savvy Mr. Shriber. Instead, he continues on his quest, providing all of the necessary information with what appears to be eagerness. The pictures and initial information needed to access his grades was provided in exactly one week. This included a message to Lyger, the “hacker”, with a special code phrase in the subject to let Lyger know who he was.

Over the following 11 days Lyger continued to lead Mr. Shriber on providing technical details about his activities. From 768-bit encrypted databases to shutting down systems with smurfs, Lyger explained that he was now ready to “hole-shot this once the hashes match.”

But then disaster struck. “todd… no more.. omfg we are SO busted..” Lyger explained that the noc had run reverse udp traceroutes and caught him. They had everything, the logs, the rot-26 stuff, and everything pointed back to Mr. Shriber’s login. Ah well, so much for that.. Lyger even told him to stay away from attrition.org since they were checking web logs.. And so the charade was over. After less than a month, Mr. Shriber’s chances for good grades were shot.

Mr. Shriber, however, was relieved. In a follow-up message to Lyger he explained that he was getting cold feet anyway and was ready to abort. Oh, and by the way, “As a gesture of good faith, I was hoping you guys would remove our correspondence from your web site. Isn’t that risky for all of us to have it up there?”

Duh…

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.