Darknet - The Darkside

Don`t Learn to HACK - Hack to LEARN. That`s our motto and we stick to it, we are all about Ethical Hacking, Penetration Testing & Computer Security. We share and comment on interesting infosec related news, tools and more. Follow us on Twitter, Facebook or RSS for the latest updates.

12 March 2006 | 186,037 views

JTR (Password Cracking) – John the Ripper 1.7 Released – FINALLY

Check Your Web Security with Acunetix

The new “features” this time are primarily performance improvements possible due to the use of better algorithms (bringing more inherent parallelism of trying multiple candidate passwords down to processor instruction level), better optimized code, and new hardware capabilities (such as AltiVec available on PowerPC G4 and G5 processors).

In particular, John the Ripper 1.7 is a lot faster at Windows LM hashes than version 1.6 used to be. (Since JtR is primarily a Unix password cracker, optimizing the Windows LM hash support was not a priority and hence it was not done in time for the 1.6 release.) John’s “raw” performance at LM hashes is now similar to or slightly better than that of commercial Windows password crackers such as LC5 – and that’s despite John trying candidate passwords in a more sophisticated order based on statistical information (resulting in typical passwords getting cracked earlier).

John the Ripper 1.7 also improves on the use of MMX on x86 and starts to use AltiVec on PowerPC processors when cracking DES-based hashes (that is, both Unix crypt(3) and Windows LM hashes). To my knowledge, John 1.7 (or rather, one of the development snapshots leading to this release) is the first program to cross the 1 million Unix crypts per second (c/s) boundary on a general-purpose CPU. Currently, John 1.7 achieves up to 1.6M c/s raw performance (that is, with no matching salts) on a PowerPC G5 at 2.7 GHz (or 1.1M c/s on a 1.8 GHz) and touches 1M c/s on the fastest AMD CPUs currently available. Intel P4s reach up to 800k c/s. (A non-public development version making use of SSE also reaches 1M c/s on an Intel P4 at 3.4 and 3.6 GHz. I intend to include that code into a post-1.7 version.)

Additionally, John 1.7 makes an attempt at generic vectorization support for bitslice DES (would anyone try to set DES_BS_VECTOR high and compile this on a real vector computer, with compiler vectorizations enabled?), will do two MD5 hashes at a time on RISC architectures (with mixed instructions, allowing more instructions to be issued each cycle), and includes some Blowfish x86 assembly code optimizations for older x86 processors (the Pentium Pro family, up to and including Pentium 3) with no impact on newer ones due to runtime CPU type detection.

Speaking of the actual features, John 1.7 adds an event logging framework (John will now log how it proceeds through stages of each of its cracking modes – word mangling rules being tried, etc.), better idle priority emulation with POSIX scheduling calls (once enabled, this almost eliminates any impact John has on performance of other applications on the system), system-wide installation support for use by *BSD ports and Linux distributions, and support for AIX, DU/Tru64 C2, and HP-UX tcb files in the “unshadow” utility.

Finally, there are plenty of added pre-configured make targets with optimal settings, including ones for popular platforms such as Linux/x86-64, Linux/PowerPC (including ppc64 and AltiVec), Mac OS X (PowerPC and x86), Solaris/sparc64, OpenBSD on almost anything 32-bit and 64-bit, and more.

Of course, all platforms supported by John 1.6 (including plain x86 running most Unix-like systems, Win32, or DOS) are still supported. Similarly, pre-compiled binary distributions of John 1.7 for Win32 and DOS are made available.

Source: Security Focus



11 March 2006 | 4,132 views

UK Could be Going TOO Far With Digital Laws

Types of activities that will become illegal under the proposed laws include making or supplying “hacking tools”- computer programmes or code that can help crack passwords or bypass security systems – and will be punishable by up to two years in prison.

Isn’t this legitimate action for any security enthusiast, hobbiest or professional involved in penetration testing or vulnerability assessment?

The law will also be clarified to make it illegal to hamper the operation of a computer, closing a loophole that has made it difficult to prosecute hackers for so-called “denial of service” attacks in which hackers bombard a computer system with hundreds of thousands of requests for information over the internet, so the servers are overloaded and cannot function.

I mean laws are all well and good, but the politicians have to wary and make sure they aren’t hurting people in the wrong places.

A major problem with the UK law at present (which called for this revamp) is under UK law DoS attacks (Denial of Service) are not illegal.

It can cost online companies millions of pounds in lost business when their websites are unavailable, but laws are not clear on whether simply stopping a computer from working is illegal.

Jeremy Beale, head of e-business at the CBI employers’ group, said: “There have been very few prosecutions under the Computer Misuse Act to date, but the new laws could give security a wider currency with businesses.”

I agree we need to protect legitimate business, but please, be reasonable with the laws and don’t punish us who are trying to educate and secure the world.

Source: Financial Times


10 March 2006 | 13,736 views

Post-Mortem Data Destruction

1. Introduction

This article describes and partly implements a method to delete or re-locate, potentially sensitive and / or incriminating information from your UNIX flavoured machine, after the sad event of your death.

An older version of this article has been published before, yet it has since disappeared from the Internet and the Google cache; hence this re-post.

Initially, the intent of the whole idea of Post-Mortem Data Destruction (PMDD), or Post-Life Data Destruction, was humorous. Thus, this document should be taken lightly.

Incidentally it can be of use to interested people as this article does contain some useful tips / pointers if one decides to build such a system. For some of you that lack common sense: any damage you might cause to your machine after reading this document is entirely your own fault.

Note that this article, obviously, assumes that the machine that the data is on, is under your own control. We will continue to look at various motivations for PMDD, below. Note that this whole theory does not apply when you are using remote storage systems (i.e. virtual drives) as the information is then stored on a remote location and we cannot be sure that the remote system really deletes your data. Their EULA might state that they do but the truly paranoid wouldn’t make the assumption that they really delete it. I sincerely wonder why one would actually ever use such a remote virtual drive — by definition these are un-trusted. But I slightly digress..

2. Motivation

You can have various motivations for wanting your data destroyed after your death:

  • You don’t want years of valuable research to fall into the wrong hands,
  • You don’t want your girlfriend or room-mates to find your collection of granny pr0n,
  • You are paranoid, or just uncomfortable with the idea somebody else will read your stuff after you have died.

Motivations for moving, i.e. sending out certain data upon the event of your death could be:

  • You are the maintainer of an important piece of software and you want the other people working on the project to have access to the latest modification you have made,
  • You suspect your elimination because of messing around with the wrong people, and want certain data (i.e. copies of emails) to be sent to, for instance, a newspaper.

After you have died, it’s too late: it will be virtually impossible to log in to your machine and delete data. Note that haunting is only reserved to a few (hurt) souls and such a state can not be guaranteed. Fat chance you’re able to sit behind a terminal in the after-life, too.

One could opt for encryption, making it hard for a person to recover the data — but that doesn’t really guarantee anything. In the event of your death, the partitions would be available to anyone that can get their hands on it. If the encrypted partitions are gone, they can never…

Let us continue by making a technical analysis of the problem at hand.

[...]


10 March 2006 | 22,776 views

SSL VPNs and OpenVPN – Part IV

4. Brief How-to …. Creating Multiple clients to Single site tunnels.

Example of using PKI to create a client-to-site VPN:

For a road warrior or roaming/multiple user scenario, static keys based VPNs don’t scale well. You will need to implement a PKI if you have Hub and Spoke architecture of VPN.

From the OpenVPN.net website:

Static Key advantages

  • Simple Setup
  • No X509 PKI (Public Key Infrastructure) to maintain

Static Key disadvantages

  • Limited scalability — one client, one server
  • Lack of perfect forward secrecy — key compromise results in total disclosure of previous sessions
  • Secret key must exist in plaintext form on each VPN peer
  • Secret key must be exchanged using a pre-existing secure channel

The following describes implementing PKI from OpenVPN.net’s OpenVPN 2.x How-to. For far more description and settings, please consult this howto.

If you want to use OpenVPN in a multiple client’s setup, then it’s recommended that you setup PKI first. A PKI will have;

- A certificate (Public key) and a private key for the server and each client

- A certificate authority (CA) certificate and key for signing server and client certificates.

Both server and client will authenticate the other by first verifying that the presented certificate was signed by the master certificate authority (CA), and then by testing information in the now-authenticated certificate header, such as the certificate common name or certificate type (client or server).

Generating the master Certificate Authority (CA) certificate and key:

For PKI management, we will use a set of scripts bundled with OpenVPN.

If you are using Linux, BSD, or a unix-like OS, open a shell and cd to the easy-rsa subdirectory of the OpenVPN distribution. If you installed OpenVPN from an RPM file, the easy-rsa directory can usually be found in /usr/share/doc/packages/openvpn or /usr/share/doc/openvpn-2.0 (it’s best to copy this directory to another location such as /etc/openvpn, before any edits, so that future OpenVPN package upgrades won’t overwrite your modifications). If you installed from a .tar.gz file, the easy-rsa directory will be in the top level directory of the expanded source tree.

If you are using Windows, open up a Command Prompt window and cd to \Program Files\OpenVPN\easy-rsa. Run the following batch file to copy configuration files into place (this will overwrite any preexisting vars.bat and openssl.cnf files):

init-config

Now edit the vars file (called vars.bat on Windows) and set the KEY_COUNTRY, KEY_PROVINCE, KEY_CITY, KEY_ORG, and KEY_EMAIL parameters. Don’t leave any of these parameters blank.

Next, initialize the PKI. On Linux/BSD/Unix:

. ./vars

./clean-all

./build-ca

On Windows:

vars

clean-all

build-ca

The final command (build-ca) will build the certificate authority (CA) certificate and key by invoking the interactive openssl command:

ai:easy-rsa # ./build-ca

Generating a 1024 bit RSA private key

............++++++

...........++++++

writing new private key to 'ca.key'

-----

You are about to be asked to enter information that will be incorporated

into your certificate request.

What you are about to enter is what is called a Distinguished Name or a DN.

There are quite a few fields but you can leave some blank

For some fields there will be a default value,

If you enter '.', the field will be left blank.

-----

Country Name (2 letter code) [KG]:

State or Province Name (full name) [NA]:

Locality Name (eg, city) [BISHKEK]:

Organization Name (eg, company) [OpenVPN-TEST]:

Organizational Unit Name (eg, section) []:

Common Name (eg, your name or your server's hostname) []:OpenVPN-CA

Email Address [me@myhost.mydomain]:

Note that in the above sequence, most queried parameters were defaulted to the values set in the vars or vars.bat files. The only parameter which must be explicitly entered is the Common Name. In the example above, I used “OpenVPN-CA”.

Generate certificate & key for server

Next, we will generate a certificate and private key for the server. On Linux/BSD/Unix:

./build-key-server server

On Windows:

build-key-server server

As in the previous step, most parameters can be defaulted. When the Common Name is queried, enter “server”. Two other queries require positive responses, “Sign the certificate? [y/n]” and “1 out of 1 certificate requests certified, commit? [y/n]“.

Generate certificates & keys for 3 clients

Generating client certificates is very similar to the previous step. On Linux/BSD/Unix:

./build-key client1

./build-key client2

./build-key client3

On Windows:

build-key client1

build-key client2

build-key client3

If you would like to password-protect your client keys, substitute the build-key-pass script.

Remember that for each client, make sure to type the appropriate Common Name when prompted, i.e. "client1", "client2", or "client3". Always use a unique common name for each client.

Generate Diffie Hellman parameters

Diffie Hellman parameters must be generated for the OpenVPN server. On Linux/BSD/Unix:

./build-dh

On Windows:

build-dh

Output:

ai:easy-rsa # ./build-dh

Generating DH parameters, 1024 bit long safe prime, generator 2

This is going to take a long time

.................+...........................................

...................+.............+.................+.........

......................................

The final step in the key generation process is to copy all files to the machines which need them, taking care to copy secret files over a secure channel.

You can also generate the certificates and keys in their respective machines to bypass copying them over some secure channel.

Although your default installation will have sample client and server ovpn files, you can also find an excellent sample Client and Server configuration files here.

The sample files are pretty easy to understand and are common for Linux and Windows except for the part where config files look for "key" and "crt" files. On Windows, you will have to use double backslashes to quote a path. For example; "C:\\Program Files\\OpenVPN\\config\\foo.key" .

After configuring the files according to your network, you can put those "ovpn" files in the config directory of your installed path and start OpenVPN using these files.

That's it! Following these steps correctly will most probably have your VPN tunnel up and running. This translates into a VPN that's easy to implement, easy to maintain and dirt cheap. The choice doesn't get any easier than this.

4. OpenVPN in a Nutshell

OpenVPN is a free, open source GPL'ed software. Implementing it across your tunnel requirements not only is cheaper, but also easy to implement and maintain. It takes away the complexity of IPSec, and it introduces the security of SSL in VPN domain.

If you do face any problems; the OpenVPN.net mailing list and Mathias Sundman's website http://openvpn.de should get you all the help you require.

All the best SSL VPN'ing!!

Some excellent articles:

1. Meet OpenVPN By Hans-Cees Speel

2. Introduction to OpenVPN By David Bogen

3. OpenVPN GUI for Windows By Mathias Sundman

4. OpenVPN 2.0 TAP mini-HOWTO By cchee on forums.gentoo.org

5. To setup a VPN using OpenVPN on UIC.edu

Previously:

1. SSL VPNs and Using OpenVPN : What is an SSL VPN
2 .SSL VPNs and OpenVPN - Part II : Why OpenVPN?
3. SSL VPNs and OpenVPN - Part III : Brief How-to - OpenVPN and Site-to-Site Tunnels.


09 March 2006 | 17,648 views

Windows Rootkits

Windows Rootkits are a big rarity in this modern web hacking tehnology…
I won’t speak exactly about rootkits, because it’s impropriate to call them that way… why? Well rootkits are programs that aid you in getting access to root level users…

So in the case we are using Windows rootkits we should call them admkits (admin kits [©copyrighted to me of course])…. So let’s cut the **** and get down to serious business.

Note: the following admkits are from www.packetstormsecurity.org, there also could be others available on the net… not just the following 4

_ROOT_040

Windows NT Rootkit v0.04 alpha – Hides processes, files, directories, has k-mode shell using TCP/IP – you can telnet into rootkit from remote. Hides registry keys – (keyboard patch disabled in this build.) Includes execution redirection.

Fake Netstat

Fake Netstat is a windows copy of netstat which can hide certain network connections. Requires renaming the original netstat.

NT BindShell

Ntbindshell is a lightweight (24k compiled) cmd.exe backdoor for Windows. Full C source included. Provides two modes of operation – standard (listening mode) or reverse-connect mode. Includes the ability to install itself as a system service, providing a shell with LocalSystem privileges.

reverseTelnet

Reverse telnet redirector / port redirector and front end console for Windows. Perfect for firewall bypassing from inside out. Can be used for bouncing connections, piping or relaying data, or as a quick MIM chat server. Windows executable form only.

More information of course can be found in the readme files from the archive…


09 March 2006 | 21,409 views

SSL VPNs and OpenVPN – Part III

3. Brief How-to ….. OpenVPN and Site-to-Site Tunnels.

OpenVPN can be implemented either Site-to-site or client-server model. I will take example configurations of both models.

If you want to implement site-to-site configuration, the best way is to use static-keys instead of PKI. Using static keys, you can have your VPN tunnel up and running in a jiffy.

First, decide which Operating systems will be used for implementing VPN endpoints on your network. According to OS, download the OpenVPN software from these locations;

Linux: http://openvpn.net/download.html

I would recommend using Mathias Sundman’s “OpenVPN GUI for windows” for its sheer simplicity.

Windows: http://openvpn.se/download.html

Example of using static keys to create a site-to-site VPN:

In this example, a VPN tunnel will be created with a server endpoint of 10.33.66.1 and a client (peer) endpoint of 10.33.66.2. Encrypted communication between peers will occur over UDP port 1194, the default OpenVPN port.

First generate a static key using this command;

openvpn --genkey --secret static.key

Copy the static key to both peers over some secure channel. Heck, use a pen drive if you are paranoid and have access to both peers physically.

Copy the static key file in “config” directory of OpenVPN installation.

Create a configuration file named “server.ovpn” in the config directory of OpenVPN, and type this in the file;

dev tun

ifconfig 10.33.66.1 10.33.66.2

secret static.key

Now create a “client.ovpn” file in config directory of second peer which will effectively become a client for the server you created just now. Put the following in the client file;

remote remoteserverip

dev tun

ifconfig 10.33.66.2 10.33.66.1

secret static.key

The IP address of remote server will come in place of “remoteserverip” in the remote directive of client.ovpn.

Now start OpenVPN executables using these ovpn files that we created. If you get “Initialization Sequence Completed” in the window, most of your work is done. Now ping the other end of tunnel. If ping succeeds, you are done!

Always make sure that you have UDP port 1194 (or any port/transport protocol over which you plan to create a tunnel) open through the network. This may require manually opening the ports at the firewalls/routers at both ends.
If you want to access the networks behind the endpoint servers, there are two options. Either you use routing (TUN) mode or bridging (TAP) mode on your OpenVPN machines. For some obscure reasons if you want to allow non-routable protocols to be tunneled (like NetBIOS) then you will have to use OpenVPN in TAP mode. Bridging ensures that your VPN endpoints make a long reach Ethernet over your WAN.

If you decide that you want to use a routed (TUN) mode, then you must enable IP forwarding on the OpenVPN machine. The virtual interface can be made external interface and local area connection can be designated internal. It will basically become a router and you can do everything with this box that you could with Linux/windows based router.

Next: Creating OpenVPN tunnels for Clients-to-site scenario….

Read on in Part IV

Previously:

1. SSL VPNs and Using OpenVPN : What is an SSL VPN
2. SSL VPNs and OpenVPN – Part II : Why OpenVPN?


08 March 2006 | 16,441 views

SSL VPNs and OpenVPN – Part II

2. Why OpenVPN

Here, in this article, I will lay down the emphasis on one important Open-Source SSL VPN software written by James Yonan and contributed by several others, which proposes security without the inherent complexity of IPsec AND using a trusted design of client component and VPN server.

Usually VPNs require end points which are trusted. The server and client are machines with elevated levels of trust as VPN components are installed on known machines which participate in corporate network according to security policy. Additionally, it is made sure that authentication credentials are pre-installed (in a secure way) on both of these devices so that each endpoint could authenticate each other.

SSL Remote Access connections nee. SSL Gateway clients, allow users to connect to VPN servers irrespective of the machine. The client can be any machine in cybercafe or public terminal. This brings us to two severe security issues. One, we break the trust model. The server and client no longer share the authentication credentials using secure channel.

Two, users connect from machines that are not subject to corporate security policies. Even if the user manages to start SSL session with SSL gateways, they are doing all their input and output on an unknown insecure machines that might as well be worm clearinghouses.

The propensity of a public machine loaded with keystroke loggers and remote management tools that allow the attacker to sniff passwords and collect session data is very high. Untrusted Clientless VPNs on an arbitrary machine is the weakest link in a security chain.
OpenVPN adheres to secure computing practices with a software component installed on the endpoints.

From the OpenVPN website:

“OpenVPN is a full-featured SSL VPN which implements OSI layer 2 or 3 secure network extension using the industry standard SSL/TLS protocol, supports flexible client authentication methods based on certificates, smart cards, and/or username/password credentials, and allows user or group-specific access control policies using firewall rules applied to the VPN virtual interface.
OpenVPN is not a web application proxy and does not operate through a web browser.”

Another reason: OpenVPN is FREE. And works on Linux like OS’s AND Windows.

Next: we will learn how to implement a VPN Tunnel using OpenVPN.

Read on in Part III

Previously:
1. SSL VPNs and Using OpenVPN : What is an SSL VPN


07 March 2006 | 27,230 views

SSL VPNs and Using OpenVPN

Requirement: To connect to a VPN server in a different country.

Situation: A country which has proxies at every gateway.

Issues: VPN based on IPSec is fussy when it comes across networks which are NAT’ted/ proxied. The Security Parameters Indexes don’t match and clients do not get connected.

Objective: To connect VPN server in a corporate network using some flexible VPN which I can run on any port/transport protocol so as to bypass the port/protocols/applications restriction.

Using these factors I came to conclusion that I needed SSL VPN solution. The following article explains the SSL VPN nuances and advantages of using them in certain situations.

Contents:

  1. What is an SSL VPN
  2. Why OpenVPN
  3. brief How-to (site-to-site and client to site)
  4. Nutshell

1. What is an SSL VPN

For a very long time, people in information security have thought IPSec is THE VPN and SSL is for secure online banking. While SSL has traditionally been used for Web site security purposes, SSL’s applications reach wider than just web proxying and application security.

Traditional SSL VPN started off with products that were more like SSL gateways instead of true VPNs. These products cannot be really termed as VPN but more like “Secure Remote Application Access”.

They thrive on a management facade called “Clientless VPN”. A VPN that can be established with any web browser without installing a software component sure promise less pain for users and administrators alike, but it comes with certain caveats that we will talk about later.

In the past, IPSec has been used as THE technology to create a VPN Site-to-site or site-to-client tunnel. IPSec has since long enjoyed widespread implementation because of its monopoly on function, although it has received its fair share of criticism for being too complex, and tightly coupled with Operating System.

IPSec came out in November 1988 with a series of RFC’s defining the protocols necessary to create VPNs. This RFC (2401-2412) represented a backbone of IPSec technologies. While IPSec does provide for a framework to establish a secure tunnel, it comes with a lot of complexity. Since complexity and security is inversely proportional, there are so many things with IPsec that may go wrong with wrong implementation. Thoroughly understanding everything and grappling with issues like Nat-T is something not everyone would be comfortable with.

Apart from that, IPSec being coupled tightly with Operating System doesn’t induce a sense of security. Any program integrated with kernel is against secure computing architecture. A wrong implementation or a security breach could take down the whole system.

Understanding the fact that IPSec is complex, industry started moving towards SSL based Remote Access solutions which may not be as secured as we want them to be. It’s because of the fact that a lot of these solutions push web browser as the client which can be used at any machine. The issue of ANY machine connecting to central site may not be very desirable as machines in cybercafes or public terminals do not form a part of control domain. Its desirable to run your upper layer protocols over SSL because it’s widely implemented and allowed in majority of packet filters.

Yeah…..but WHY OpenVPN??

Read on in Part II


06 March 2006 | 4,461 views

Latest RIAA Bullshit – Fair Use Policy – Can’t Use YOUR CDs on YOUR iPod

Amazing, now ripping YOUR OWN CD’s to use on YOUR iPod is not fair use according to the new DMCA rulings currently being created.

As part of the on-going DMCA rule-making proceedings, the RIAA and other copyright industry associations submitted a filing that included this gem as part of their argument that space-shifting and format-shifting do not count as noninfringing uses, even when you are talking about making copies of your own CDs:

“Nor does the fact that permission to make a copy in particular circumstances is often or even routinely granted, necessarily establish that the copying is a fair use when the copyright owner withholds that authorization. In this regard, the statement attributed to counsel for copyright owners in the MGM v. Grokster case is simply a statement about authorization, not about fair use.”

For those who may not remember, here’s what Don Verrilli said to the Supreme Court last year:

“The record companies, my clients, have said, for some time now, and it’s been on their website for some time now, that it’s perfectly lawful to take a CD that you’ve purchased, upload it onto your computer, put it onto your iPod.”

If I understand what the RIAA is saying, “perfectly lawful” means “lawful until we change our mind.” So your ability to continue to make copies of your own CDs on your own iPod is entirely a matter of their sufferance. What about all the indie label CDs? Do you have to ask each of them for permission before ripping your CDs? And what about all the major label artists who control their own copyrights? Do we all need to ask them, as well?

I wish they would just make their collective minds up, or lack of minds or whatever you want to call it.

Digital Restrictions Management indeed.

Source: EFF


06 March 2006 | 7,289 views

Anti-Spyware Software Wars – Can’t they get along?!

Last year, we noted how some security products could cause conflicts that would cause computers to lock up — but there’s another (less troublesome) trend that’s happening as well: security products declaring competing products as malware and removing them.

Just a little over a week ago, the latest version of Microsoft’s anti-spyware offering declared Symantec’s anti-virus offering as malware. However, it looks like Kaspersky Labs has Symantec’s back on this one. Its latest anti-spyware offering flagged some Microsoft anti-virus software as being malware. Of course, this was bound to happen, since many security products often have to do things that look quite like malware.

This is only likely going to get worse — and many of these standalone companies might want to start thinking about proactively trying to deal with the issue. In the meantime, it seems like the security suite providers should be using this as an opportunity to hype up how their combined offering does everything in one package (even if that’s not quite true), so you never need additional, conflicting software.

According to several different support threads over at Microsoft’s user groups forum, the latest definitions file from Microsoft “(version 5805, 5807) detects Symantec Antivirus files as PWS.Bancos.A (Password Stealer).”

When Microsoft Anti-Spyware users remove the flagged Norton file as prompted, Symantec’s product gets corrupted and no longer protects the user’s machine. The Norton user then has to go through the Windows registry and delete multiple entries (registry editing is always a dicey affair that can quickly hose a system if the user doesn’t know what he or she is doing) so that the program can be completely removed and re-installed.

I put in calls to Microsoft and to Symantec on this issue, but am still waiting to hear back from both companies.

Source: Washington Post

I have had similar problems in the past with things detecting HijackThis! or Spybot as Malware..or playing with having two level 7 firewalls installed.