Symantec Gets Pwn3d: The Fallout

Friday, January 06, 2012

Kevin McAleavey


Yesterday, I spent some time with Infosec Island's Michael Menefee going over the potential impact of the Symantec "leak" - and as someone who worked in the industry, I don't see a tremendous security risk to the source code release itself.

For those who have been following me here on the Island, you're probably aware of my lengthy series of articles wherein I glossed over the history of antivirus, in order to "peddle our stuff" as one blogger put it back last summer.

I truly wish that I had more time to have been more complete in those lengthy tomes, but I also have a "day" job and giving it the proper amount of detail would have caused our Infosec Island to tip over, much as was threatened for Guam by an errant politician a year or two ago. In this case though, it would have been quite real.  :)

For those who haven't been following the breaking news, in a nutshell, a group of "crackers" in India discovered, and threatened to release source code for Symantec's flagship antivirus software and Michael and Anthony M. Freed were both in contact with "YamaTough" who provided compelling evidence that he did indeed have the "secret sauce" and planned to release it in order to embarrass Symantec over Indian government policies towards eavesdropping on cell phone and other communications. Certainly a bold attack on an unsecured, unidentified server which contained the "kernel's secret recipe."

The good news though is that the chicken is so far past code date, it won't be served.

One of the released samples was source code for the HomePageProtection application for Windows which I was able to examine. The source code was compiled in Visual Studio 7.10 with files primarily dated up to September 7, 2005 and was apparently unpacked at its destination almost one year later on October 15, 2006.

It is not uncommon for Visual Studio to do a "build all" and thus it's safe to assume that any other source code components of the remainder of Symantec Antivirus not yet released is also of the same vintage. The build information indicates that it was their r12.0.6 product of 2006 vintage.

While this will be disconcerting to customers, shareholders and others, I for one don't see much concern to this particular source code "floating" around and I'll explain why in this article.

First off, those who know me also probably know that I'm one of the last people on this earth who would defend Symantec or attempt to minimize the damage (unless they want to hire me of course) but let's deal with the realities of the situation despite my continuing mistrust of the antivirus industry as a whole. After I explain why I don't see this a concern, I'll then do my best to raise speculation and perhaps a dash of hyperbole just to make this worth reading.

Back in 2005, and even in 2006 when this "package" arrived at whatever location it was looted from, at the time of the development of this code, Windows Vista was still known as "project longhorn" and the changes within the underlying kernel and userland were extreme.

Code that worked on XP would not function properly with the release of Vista owing to numerous changes in the kernel space, as well as userland. I remember the pure hell on earth I had to go through with my old BOClean product and all the changes I had to make to make it work with Vista and still be compatible with older versions of Windows. Almost none of my original code made it across the river Styx intact.

The Symantec code which has been released here is absolutely PRE-Vista. LUA alone would have rendered most of the code released inoperable, but the biggest changes as of Vista and Windows 7 were the result of separate consoles with the system running in its own console and userland running in others. I'm deliberately avoiding the technical complexities of what that all means for the sake of simplicity in this article.

In addition, the code in the Symantec release is NOT 64 bit compatible nor are the newer "safe functions" used. There is simply no way that Symantec would have moved any sensitive parts of this code into newer versions, and though I have not seen any of the kernel driver code, given that antiviruses REQUIRE the use of system hooks and driver shims, as well as IAT and other kernel table tricks, it's absolutely safe to believe that none of the key kernel code by which current versions of Symantec antivirus could be hacked or compromised from this code would still be in use at all.

So yes, we have genuine Symantec source code from an ancient version of their antivirus, but it can only be looked upon by us antimalware coders as a museum exhibit, not an actual threat. Nor do I see anything in the code so far released that would offer much of a hint as to how to disable Symantec's code unless the "booty" contains any kernel code that's more recent than Vista's last service pack changes in it or the special hooks that Microsoft created for AV vendors and nobody else. Until we see anything along those lines, move along, return to your homes, nothing to see here. Seriously.

Now Michael also raised a valid point while we were going back and forth over this last night, that in many parts of the world, XP is still king and his point was that in order to protect those old machines, people might still be using old versions (possibly THIS one) of Symantec and my point to him was that Symantec puts users through hoops to upgrade and when things change, they force change components even for old versions as long as the subscription is maintained.

And of course, many of us who've gone to the store and brought home a shiny new toy also know that the antivirus has already "expired" before you even open the box. In this case, I maintain that you don't have an antivirus at all if it's not up to date and maintained, so possibly he's right there. But then that'd be no different from running an expired antivirus in the first place.

So what's the REAL story here then?

Once again, a vendor hasn't properly secured its "family jewels" and they got kicked in them. Again. This reminds me of the COMODO certificate game. And they got hacked AGAIN. And then the same guy got Diginotar. One would think that "security" companies could do a better job of securing their OWN facilities and property like we do here. Nah.

One has to guess that sharing this source code was some part of a sales agreement with India perhaps, given that the stolen files were obviously part of an archive with the same date stamp on the extracted data in 2006. One would expect that any such disclosure would at least require that the file not be placed in some place where it would be available to outsiders, deep inside a security perimeter.

But then as we've learned over the past year even with SCADA systems, that's obviously not the case. Unless this file was somehow an "inside job" since Symantec has labs in India... COMODO did as well and I know some of the people who've worked over there. India is not known for the quality of security in many areas of technology or in their government. To me, the real issue is the breach, not the source code but then again I'm familiar with all this stuff and am not the least bit surprised that this has happened.

Protecting the family jewels is the most important task, especially when you claim to be a "security" company. Hasn't ANYBODY learned anything yet?

About the Author: Kevin McAleavey is the architect of the KNOS secure operating system ( ) in Albany, NY and has been in antimalware research and security product development since 1996.

Possibly Related Articles:
Information Security
Antivirus Infosec Island Symantec Hacker Norton breach Source Code pwn3d India YamaTough Kevin McAleavey
Post Rating I Like this!
The views expressed in this post are the opinions of the Infosec Island member that posted this content. Infosec Island is not responsible for the content or messaging of this post.

Unauthorized reproduction of this article (in part or in whole) is prohibited without the express written permission of Infosec Island and the Infosec Island member that posted this content--this includes using our RSS feed for any purpose other than personal use.