, special to SecurityFocus 2000-11-05
There are many reasons for a villain to crack Microsoft's network... Industrial espionage just isn't one of them.
“
Hackers trade source code like teenagers trade baseball cards.
”
Most newsworthy was the possibility that Microsoft's highly guarded source code was compromised, and possibly misappropriated. The Wall Street Journal reported that the hacker might have had access to Windows or Office 2000 source code. Microsoft denies it, and says the attacker only had access to the source code for a future product under development. Only the hacker and, quite possibly, Microsoft know the real truth.
Not surprisingly, and maybe in an attempt to save face, Microsoft now claims they were watching the hacker's every move and may have collected evidence that could lead to the culprit's real identity.
After criticism of their security practices (and widespread media attention...), Microsoft tried to "clarify" the facts. A Microsoft spokesperson revealed that an employee's home machine was infected with the Trojan, and that may have led to the hacker identifying the passwords needed to access the corporate network.
It's unclear whether the attacker had access to source code on the developer's compromised machine, or to corporate servers that store the source code trees. But one surprising tidbit of information emerged from the reports: it seems Microsoft's corporate network is accessible through the use of static passwords.
Protecting the crown jewels based only on "something you know," just doesn't make much sense. You never know when someone else knows your password. Utilizing better security practices could have prevented this problem, such as installing current anti-virus software definitions on all machines that connect to the network, and implementing stronger authentication methods, like access tokens or biometric devices. You'd think the monolithic software company would have known better.
The damage is done now, and company executives will no doubt lose sleep over this security incident. Cleaning up after an attack and verifying the integrity of the compromised systems is bad enough, but not knowing the attacker's intentions can be nerve wracking. Could it be industrial espionage? An assault on Microsoft's image? An effort to expose non-competitive coding practices? Or did the hacker hope to post the source code on the Net "because information wants to be free?"
Although it cannot be ruled out, I believe the probability of industrial espionage is slim. It's easier to get a permanent job or contractor position at Microsoft, or just bribe someone that already has access to the code, than to hack the company's network. And imagine the risks of selling or buying the source code in the marketplace. (On the other hand, extradition may not be an issue from certain countries.)
So if it wasn't industrial espionage, what was it?
Back in my hacking days, source code was the ultimate trophy--a souvenir of the accomplishment (hack). Having source code is like having blueprints to the software, enabling one to study its inner workings -- to learn how it functions, and to identify security vulnerabilities.
One fellow hacker I knew (no, not me) had the source code trees to most of the Unix-based operating systems. This fellow successfully compromised the internal networks of almost every major Unix software developer. His goal was not only to scour through the code to find security holes, but more deviously, to develop backdoors and Trojan horses for each version of the operating system.
Still other hackers trade source code like teenagers trade baseball cards; Microsoft source code would be the Honus Wagner of any collection.
Regardless of who hacked Microsoft, and why, the incident should serve as a reminder that any entity with enough resources, time, and money can compromise almost any computer system or network. Although there's no surefire way to eliminate the risk, the key is to minimize it to an acceptable level. It's crucial to develop sound security practices that are followed by everyone with access to sensitive information, such as proprietary source code.
A good security program must audit compliance with polices and procedures to verify employees are following them. Swift detection and reaction to violations of corporate policy, whether intentional or not, will reduce unnecessary exposure.
Protecting valuable information assets such as source code also requires examining the "big picture" -- physical, technical, and personnel security threats. Every security analyst knows the importance of a thorough risk assessment to identify vulnerabilities, and to implement cost-effective countermeasures. However, that is not enough. Network administrators must exercise constant vigilance, monitoring every machine on the network; otherwise expect to be the next Microsoft-style victim.
My advice is to live by this axiom: network security is as strong as the weakest link in the chain. How strong is yours?
