Troubleshooters.Com Presents

Troubleshooting Professional Magazine

Volume 4 Issue 10, October 2000
Introduction to Security
Copyright (C) 2000 by Steve Litt. All rights reserved. Materials from guest authors copyrighted by them and licensed for perpetual use to Troubleshooting Professional Magazine. All rights reserved to the copyright holder, except for items specifically marked otherwise (certain free software source code, GNU/GPL, etc.). All material herein provided "As-Is". User assumes all risk and responsibility for any outcome.

[ Troubleshooters.Com | Back Issues ]


CONTENTS

Editors Desk

By Steve Litt
I heard about Information Technology Security Awareness day (ITSA day) from the FLU Linux group mailing list, and decided to make the 100 mile pilgrimage. I go into details in a later article, but suffice it to say ITSA day gave me a lot of food for thought.

Computer and network security is a lot like automotive smog control in that a security malfunction doesn't necessarily manifest itself as a malfunction in the overall system. Like smog, you need specialized tools to deduce the security of your system. Like smog, you can't learn security by experimentation (unless you have a cracker buddy who repeatedly hits you with exploits).

This issue of Troubleshooting Professional Magazine scratches the surface of security. If it gives some readers a heightened awareness of security, it's done its job. From there you can follow some of the links in the URL section to get hard info on specific exploits and their defenses.

To wrap up this TPM issue, Linux Log presents some threats to your data that have more to do with lawyers, lobbiests and laws than with ping sweeps and port scans. As a Troubleshooter, sooner or later you'll likely clean up the mess from a breached security. Enjoy this issue of Troubleshooting Professional Magazine.

Steve Litt can be reached at Steve Litt's email address.

Vote for Your Favorite Troubleshooting Professional

By Steve Litt
Now is the time to vote for your favorite Troubleshooting Professional issue (by year and month) and/or article (by year, month and title). Submit your entry to
Steve Litt's email address. The results will be announced in our fourth anniversary issue, which comes out in January.
Steve Litt can be reached at Steve Litt's email address.

ITSA Day

By Steve Litt
There's nothing better than a free exposition. Except maybe a *good* free exposition. The Information Technology Security Awareness day (ITSA day), put on by the University of Florida in Gainsville, was a *great* free exposition. At 8 am fellow LEAP-CF member Brian Coyle and I piled in my Buick and headed North to Gainsville. Unfortunately, the three hour commute meant we missed all the morning talks. But the afternoon talks were more than worth the ride.

After lunch, John Kida of S3 Networks spoke on "Learning from Your Security Mistakes". It was like a Keystone Kops Komedy of security, with many pratfalls reminiscent of security blunders I often make. As I looked around the auditorium, I saw more than a few sheepish grins. Of all the talks, this one most powerfully got its message across.

Next came Tim Ryan of CISCO Systems, with his discussion titled "Secure Network Design". This was an outstandingly technical presentation of attack strategies, and defenses against them. The slide show was outstanding, and is available at the ITSA day website (URL in URL's section of this magazine).

Jeff Powers, the Vice President of Sales for Baltimore Inc. came next with his "The State of Public Key Infrastructure Today". Jeff lucidly laid down an overview of this important topic. During ensuing discussions, remaining challenges were discussed. As we drown in an ever increasing flood of paperwork, digital signatures and secure, encrypted documents become our only salvation. Jeff provided a vital understanding of where we are, and where we need to go.

Last but not least, John Rezabek, Technical Product Manager for Internet Security Systems (ISS) presented "The Anatomy of an Attack and Risk Management". It was very similar to Tim Ryan's presentation, presenting both cracking strategies and defenses against them. The differences and similarities between the two presentations yielded enhanced subject depth.

Rounding out the festivities were a great bunch of vendors. I talked to a few of them, but they were all over my head. But I eavesdropped anyway, and heard some really interested conversations.

They say there's no free lunch. Don't say that around UFL on ITSA day. They gave us free lunch better than porterhouse steak and caviar.

Steve Litt can be reached at Steve Litt's email address.

Anatomy of an Exploit

By Steve Litt
The following is a typical attack strategy:
  1. Reconnaissance
  2. Own a computer
  3. Exploit trust relationships
  4. Own the network

Reconnaissance

The first step must be to learn as much as possible about the target network. There are technological tools and social engineering tools. Technical tools include ping sweeps and port scans, followed by DNS and whois queries on identified IP addresses. Social engineering includes perusal of the target's web and email content.

The purpose of all of this is to find computers to attack, and to evaluate which computers will be the easiest target.

Own a computer

The Reconnaissance phase has allowed you to look at a computer, and maybe even see certain of its resources. That's a far cry from exercising any control over the computer. To obtain control over a computer, the attacker must gain a high privelege access to that computer long enough to place a back door to obtain high privelege access at a later date and time.

Ideally for the attacker, this can be done in a single exploitation of a priveleged process. For instance, if a CGI script running as root could be overflowed such that it drops the attacker to a shell prompt as user root, with xterm on the attacking machine, the attacker now needs only install a Perl program that backs up /etc/passwd and /etc/shadow, then temporarily deletes the root password so the attacker can put in his own. Now he can have his way, and on the way out cover his tracks, including replacing the original root password.

One interesting method of gaining control of a machine is telling Apache to initiate a telnet session with the attacker's machine. If Apache falls for it, and if the firewall allows outgoing Apache initiated packets into the outside world, the attacker wins.

Exploit trust relationships

"Tell em Joe sent you". It's the trust model used in the underworld, the hiring of babysitters, and in computer networks. If Joe trusts you, so do I. Naturally, this trust relationship is only as effective as Joe's judgement. If Joe trusts the wrong guy, and Bill trusts Joe to make the right decision, Bill now trusts the wrong guy.

The police use this all the time. They arrest Joe for peddling dope. They offer Joe immunity of Joe sets up a meeting with Bill. Bill falls for it and takes the fall.

Black hats do it too. They crack Susie Secretary, who uses her daughter Tiffany's name as a password (that took all of 2 minutes to crack). From there they get onto the fileserver, which trusts Susie's client. Now they have their way with the network, because most others trust the file server.

Under certain circumstances, trust relationships can pierce a firewall, so care must be taken. Especially effective is port redirection, in which the cracker goes in a protected port and comes out an unprotected one right through the firewall. Trust relationships must be strict and well thought out, or breach of a single host can compromise the entire network.

Own the network

Pretty soon the black hat has either the root password or a back door on most of the network's hosts. Now he can have his way with the network. He can download all the info, or mess with your data, or place something in someone's disciplinary file, or conduct a distributed denial of service (DDOS) attack on a different network.

Defeating the cracker

Start with good administration. Shut off all unneeded services. Use up-to-date software with all security fixes in place. Implement forced password changes and prevent reuse of old passwords. Be very thorough in configuring the firewall, paying attention to what can send what to whom, and under what conditions. Be sure Apache can't initiate a conversation to the outside. Guard against port redirection scams.

Download a copy of nmap. It's a port scanner that finds lots of potential problems. According to its website on insecure.org, it has the following abilities:

The Nmap URL is in the "security URL's" section of the URL's section of this magazine.

You may wish to install tripwire. Tripwire is a utility that tracks changes in files so that you know immediately if somebody's "tweaked" something. I would have recommended Tripwire highly, except it's a commercial program which, in the future, could have its price boosted.

There are many, many security tools listed at http://www.insecure.org/tools.html.

Steve Litt can be reached at Steve Litt's email address.

Social Engineering

By Steve Litt
 
"Hi. Is Malcolm there?"

"I'm sorry sir, Mr. Jennings is out of the office today. May I take a message?"

"No, that's OK. This is Clint Cutler from Philly. Malcolm and I went to Ball State University together. He might have told you about the time we put the car on the roof of the dorm."

"Clint! Malcolm has mentioned that incident a few times. I laugh every time. Wasn't there also someone named Phil Darner with you? You sure you don't want to leave a message?".

"No. Here's the problem. I'm in town for just a couple days and I want to surprise him. Also, I've never met his wife. Remind me, what's her name again?"

"Tiffany".

"Yes, I remember now. You know I should really stay in touch. How many kids does Malcolm have now?"

"Are you sitting down? The guy you goofed around with in college has four kids now. Margo is six, Jennifer is four, Melanie is two, and little Johnny is only three weeks old".

"Wow, I should get a belated birthday card for Johnny. What is his birthday?"

"September 10".

"That's great. You know, I seem to remember that Malcolm's birthday is coming up."

"Not til November".

"November will be here in no time. Maybe I'll email him a birthday card."

"That's a great idea. His birthday is November 7."

"Great. I guess you'd better give me his email address."

"It's mjennings@ourlittlecorporation.com."

"Excellent. Now if you're going through his email and see my birthday card, please make sure he reads it."

"Of course Clint. I screen Mr. Jennings' email, so yours will be one that gets passed on through."

"You know, you've been so nice, and I don't even know your name."

"Sarah Kramer".

"Sarah, great meeting you. I wish my secretary were more like you. ... Malcolm with kids. Imagine that. You know, another friend of mine has quadruplets."

"Oh my gosh, and I thought I had trouble with one!"

"I think kids are a wonderful challenge no matter how many you have. Do you have a son or a daughter?

"Jeremy is eight years old. He plays soccer in AYSO. He runs us ragged."

"Your husband isn't Rob Kramer from Barzakon Construction, is he?".

"No, Fred Kramer. He's an attorney at Klimer & Carter."

"They're a law firm, aren't they?"

"Yes. They specialize in mergers and acquisitions."

"I may need legal representation on something that's getting a little too much SEC attention. Maybe I should talk to your husband."

"That would be great. Would you like his phone number?

"Sure!"

"It's 407-555-1234, extension 5678."

"Great Sarah, I'll give Fred a call. And please do me a small favor and don't tell Malcolm I'm in town. I want to surprise him. OK?"

"Sure thing Clint. Call back soon!"

"Absolutely Sarah. I get into town every couple years."
 

Bart Wallen switches off his tape recorder, walks away from the pay phone, and smiles. That call was better than he had hoped. With one call he got all of Malcolm Jennings' childrens' names, and one of their birthdays. Oh, and don't forget his wife's name. With any luck Malcolm's server logon ID is mjennings, and Bart can do a ping investigation to get server ip addresses, and then use whois to translate ip addresses to server names. And what do you want to bet that Sarah Kramer is either skramer or scramer, and with any luck her password will be fred, freddie, or jeremy.

And Sarah gave him more ammo for social engineering. He'll be calling Fred Kramer, on the pretense of a possible business relationship, to garner more info on Sarah. And she mentioned Phil Darner. He'll look up Phil Darner in a search engine, possibly and'ed with Ball State. And of course, maybe Malcolm's password is Clint, Cutler, or ClintCutler.

It started when the company, "Our Little Corporation", refused to honor Bart's $30.00 rebate. They had claimed the rebate had expired two years ago. When Bart complained, the service person was pleasant enough, but wouldn't give Bart his money. Right then and there Bart knew he was going to shut them down. He'd done it before.

It will be simple enough. Using the Our Little Corporation servers as masters, he will direct a denial of service attack against a very litigous mid sized company who has also treated Bart poorly. The attack will have Our Little Corporation fingerprints all over it. With any luck the two of them will be tied up in court for months.

His first step had been search engines, and he'd quickly found a braggart named Malcolm Jennings, a mid manager working for Our Little Corporation. Malcolm never tired of regailing his college escapades on various lists. One name that Malcolm threw out frequently was Clint Cutler. That was the "password" Bart needed to carry out his first social engineering in the company. Now he had two user names and several possible passwords. With any luck he could log on to the server as one of those users, and then use a buffer overflow to bust out of a high privelege process into a shell. Then he could set up his own back door, and begin spreading his influence over the system by exploiting trust relationships.

Bart smiles as he marvels how easy blabbermouths make his job.


It's called social engineering, and it's a powerful tool in the hands of a cracker. There was a time when a person could brag in relative privacy, but those days are gone. Any email can find its way to a mailing list. And most mailing lists are archived, meaning it sticks around for years. And of course, search engines spider those archives. That means that anyone who wants to get you or your company will be able to find that info in about 10 minutes.

Keep that in mind the next time you get the urge to brag about your kewl new technology. I'm not telling you never to brag. I'm just saying to try to filter out information about important live networks.

And it's not just bragging. At ITSA day in Gainsville, John Kida of S3 Networks gave a great talk entitled "Learning from Your Security Mistakes". One example he used was the human resources ad that listed every skill the candidate would need. A cracker can access that info and know immediately what technologies are on the premisis, and what projects they're used for.

As they say in the TV cop shows, "Let's be careful out there!".

Steve Litt can be reached at Steve Litt's email address.

The Boy Next Door

By Steve Litt
Remember when "the boy next door" was a character in a song? He's been promoted. Now, often as not, he's a guy hooked up to the same subnet as you, right through your DSL or cable. And being the wild and crazy 13 year old he is, his curiosity and adventuresome spirit know no bounds. Although I understand broadband providers are taking steps to limit this exposure, when you're hooked to broadband it's best to consider yourself on a party line.

In the past, party lines mean't you didn't say anything you didn't want that nosy Thelma Smith to repeat at the crowded general store. Now it means that without adequate security, Thelma's grandson Sean can see everything on your hard disk. And just maybe plant a little trojan there.

The first step is certainly to either disable sharing, or make sure it's adequately password protected (hard to do on Win9x share oriented authentication). Perhaps the best bet is to have all file sharing done by a single Samba server. You can go a long way toward discouraging casual lookylous by placing the following two lines in the [global] section of your smb.conf file:

valid users=+smartguys
browseable=no
Group smartguys includes only those people knowing enough to use strong passwords and change them often. The second line makes the server non-browseable at the top level. Because they're in the [global] section, these two act as a default for any shares not explicitly specifying valid users or browseablity.

Note that the preceding breaks the [homes] share. To reenable it, add the following line to the [homes] share:

valid users=%U
Do the measures discussed above prevent those not in group smartguys from accessing shares? Not in the slightest. Different shares can have non-default parameters explicitly specified. Those who need access to such shares can be given their addresses (\\myserver\data, for instance), or their logon scripts or autoexecs can be made to do the correct drive mapping. But the boy next store will have to work harder to attack you.

The next step is to configure a good firewall so nobody from the outside can sniff your packets, portscan or pingsweep you. That's beyond the scope of this issue of Troubleshooting Professional, but there's plenty of documentation on how to set up a firewall. Also, try to use a switch instead of a hub. With a switch, one port can't be used to sniff another, because packets go only from source to destination.

Every day, hordes of innocent web surfers leave themselves wide open to crackers on the net. Most get away with it because there are just so many targets to choose from. Like Alfred E Newman says, "what, me worry?". But one day some guy with a grudge against Alfred's buddy's employer may bust onto Alfred's box to exploit a trust relationship with Afred's more careful buddy, after which grudge-man will use the beachhead on his buddy's box to crack the employer. And just for fun, he might email some of Alfred's downloaded porn to Alfred's wife...

Steve Litt can be reached at Steve Litt's email address.

Public Key Infrastructure

By Steve Litt
I'm really anxious to have practical digital signatures, so I can tell everyone I do business with not to send me paper. I'm drowning in paper. Unfortunately, after seeing Jeff Powers' excellent presentation titled "The State of Public Key Infrastructure Today", I don't think we're quite ready. But I can tell you, it seems like when everything finally falls into place, Jeff's company, Baltimore Inc, will be ready to provide the infrastructure.

Public key technologies provide three benefits:

  1. Strong encryption
  2. Tamper detection
  3. Non-repudiation
#1 is important for privacy, so only you and the person you send the file to can see it. If you write to an employee on the other coast, detailing next year's business strategy, you certainly don't want your competitors to be able to decode it.

#2 is important to prevent someone from changing your message with a binary editor. If even one byte in the file changes, the file won't encrypt because the encryption is based on the public key, the private key, and the checksum of the file. So when you receive a file, you're guaranteed that if it decrypts you have the exact same file that the other person sent you.

#3 is important for contracts in digital form, acting as a digital signature. Because only you have your private key, if the public/private combination shows the doc belonging to you, you *must* have created it (so goes the theory).

What I understood from Jeff Powers' ITSA day presentation, #1 and #2 are pretty much ready for prime time. But #3 has some problems, in my personal opinion. Basically, your digital signature private key is your signature. It "proves" you wrote and signed the document. But if somehow somebody managed to get a copy of that private key, he could "forge" your signature. And the forgery would be absolutely perfect, down to the very last bit.

Compare that to written signatures. They vary. Even the same person's signature varies. But there are handwriting experts who can testify as to the probability of the signature being written by the purported person. Forgeries of written signatures are common, but in all but a very few cases they are eventually sorted out. Because you can't do a bit for bit copy of an original ink signature.

So the next logical question is "how likely is a digital signature forgery?". Well, we know it's possible. I don't think there's ever been an uncrackable computer technology. But forgeries exploiting weaknesses in public key infrastructure software would be rare, and would be quickly patched.

The real problem is that the private key is too long for a human to remember, so it must be kept on his computer. Of course, the private key is password protected, but then you're subject to the same problems as with any password. Will it be a birthday or relatives name? Will it be the same as the password they use on a mailing list or some password that's sent in the clear? Will it be so short as to be brute-forcible? Will it be written on his keyboard?

Even if the user has more sense than any implications of the preceding paragraph, if a cracker gains access to the user's machine, the cracker can observe the user typing the password to unlock the private key. I believe that anyone without significant security skills can end up getting his digital signature forged.

Imagine this: John Q. Public has worked 20 years to build his small business to  the point where it's worth $20 million dollars. John's a great businessman, but his computer skills are limited to Windows 98 email and surfing. John has recently gotten a digital signature. Jack Crack sniffs John's IP address and sees him type in the password. Jack crack puts together a contract in which John Q. Public sells his business to Jack Crack for $5 million. Jack uses John's encryption and signature private keys on the contract. Jack now owns the business, which he promptly sells for $10 million, for a cool $5 million profit. Not bad for a day's work. And John Q. Public? Unless he can convince the jury that the signature is forged, he's out $20 million.

There's another problem. Signature private keys are revoked from time to time. After revocation, documents with the revoked signature are no longer authenticable. This certainly presents a problem in any court case regarding a several years-old digital contract.

None of this is a show stopper in the long run. In the long run, digital signatures and Public Key Infrastructure *must* be implemented. Because todays methods of signatures, ID cards, knowledge of social security numbers and mothers' maiden names are so insecure as to render each and every one of us open to extreme economic abuse.

Steve Litt can be reached at Steve Litt's email address.

Linux Log: The Unexpected Security Hole

Linux Log is now a regular column in Troubleshooting Professional Magazine, authored by Steve Litt. Each month we'll explore a facet of Linux as it relates to that month's theme.
Not all attacks use pingsweeps, portscans, buffer overflows, social engineering, trojan horses and the like. Sometimes you need to protect against an entirely different class of attacker, whose crack tools are lawyers, unfathomable licenses, stealth licensing, soft money lobbiests, and laws like UCITA and DMCA.
 
Double check all the following information with your lawyer, because I may be wrong in some of the details or even fundamentals. As usual, all risk for use of this information is the readers, and I take no responsibility for the outcome or mistakes. Yada yada yada.

UCITA and the Denial of Data Attack

The various UCITA based attacks can be used by software vendors "headquartered" (whatever that may mean) in states that have passed UCITA legislation, which at this point are Maryland and Virginia. It's passed both the house and senate in Oklahoma, but I guess the governor hasn't signed it because it's not listed as enacted. Other states considering UCITA are Delaware, District of Columbia,Hawaii,Illinois,Louisiana,New Jersey. At this moment it appears that UCITA is effective only in Maryland, and will take effect in Virginia in July of 2001. I got my state by state UCITA  information from a web page of law firm Baker & McKenzie located at http://www.bmck.com/ecommerce/ucitacomp.htm.

It's quite possible that other states will enact UCITA and make effective before it takes effect in Virginia. Then again, it's possible that common sense will prevail and the entire UCITA concept will be dispensed with. But in the mean time, if you have any type of electronically distributed material originating from Maryland, watch out for the DOD (Denial of Data) attack.

The DOD attack exploits the fact that UCITA outlaws reverse engineering. Yep, that's my story and I'm sticking to it, even though hundreds of attorneys are likely writing me right now to explain that the text of UCITA doesn't even *mention* reverse engineering. That's true. But UCITA gives shrink wrap and click through licenses the force of law, meaning that if an anti-reverse-engineering clause is in the license, it's law, not some silly unenforceable thing. It's law. So for practical purposes, UCITA outlaws reverse engineering of software.

Let's say the Maryland software company has a word processor. The data is in a proprietary format. They provide no export utility.

The exploit begins with their giving you an excellent price on their word processor. Maybe a very economical site license with a per-year payment. You use their word processor, and as time goes by all your documents are in their proprietary format. You don't know it yet, but they own your documents. Now they quadruple the yearly payments, and you realize they've cracked you. They hold your data hostage. There's no export facility, and it's illegal for Word, Star Office, etc to provide an import utility, because the only way they could do that is reverse engineering. You now have the choice of trying to print and OCR everything you've got, or continue enduring triple digit inflation.

I want you to imagine what will happen if Washington State ever passes UCITA.

The best defense against DOD attacks is to use GPL software. Its license clearly spells out that reverse engineering is unnecessary, because transfer of the source code is manditory. Because a cold-turkey withdrawal from proprietary software is not practical, I suggest you stop upgrading proprietary software. Unless someone manages to make a state's UCITA law retroactive, the non-UCITA licesnse you have now doesn't have a force of law, so neither do their non-reverse engineering clauses (check with your lawyer to make sure).

Gradually transition to GPL software as the proper software becomes available. Try very hard not to buy software or any kind of bitwise data, content or software from states with UCITA or considering UCITA.

UCITA and the Denial of Due Process Attack

This attack, also called a DODP attack, uses a different property of UCITA, the "self help" provision, which allows the software vendor to "shut off" the software remotely if the customer is deemed to have violated the license. There is no need to get a warrant from a judge. The black hat simply shuts off the software. The customer could always sue, but meanwhile his business is down. What's the cracker's motive? Money, as usual. He can enhance his bargaining position. Especially if a customer refusing to upgrade gets his old version shut down.

DMCA and the Denial of Free Speech Attack

The UCITA based attacks aren't generally available because most black hats don't live in Maryland. But the Digital Millenium Copyright Act (DMCA) can be used by black hats anywhere in America to launch an attack on free speech. Their exploit begins when somebody, somewhere, provides instructions on how to circumvent their copy protection, encoding, etc. In pre-DMCA America, the black hat would simply sue the person providing the instructions. But now the cracker exploits a provision of the DMCA that basically says you can't even link to a site containing the circumvention information. There are some additional requirements, like a clause saying it's only a violation if the linker's intention was to help the linkee. That's pretty weak -- publicity is always beneficial.

Why is this a denial of free speech? Let's look at a pre-digital equivalent. A nasty little terrorist group is making bombs in a house on 456 Main Street. This terrorist group bombs buildings in the name of the environment. Several environmentally sensitive newspapers mention this terrorist group and give their address, saying that although their means are wrong, the environment is a problem. Free speech, right? Newspapers have been doing it since Ben Franklin's time. But if DMCA covered paper newspapers, those environmentally sensitive newspapers would arguably be in violation of DMCA. Enough so that any lawsuits brought would not instantly be thrown out of court. Enough so that no "frivolous lawsuit" countersuit would be successful. Do you think that might place a chilling effect on free speech?

I bet you don't believe me when I say they've banned linking to a location. Check out this text of the actual DMCA as signed into law by the president:
 

   Exerp from DMCA
  ``(d) Information Location Tools.--A service provider shall not be   
  liable for monetary relief, or, except as provided in subsection (j),   
  for injunctive or other equitable relief, for infringement of copyright 
  by reason of the provider referring or linking users to an online       
  location containing infringing material or infringing activity, by using
  information location tools, including a directory, index, reference,    
  pointer, or hypertext link, if the service provider--                   
       ``(1)(A) does not have actual knowledge that the material or        
   activity is infringing;                                                 
       ``(B) in the absence of such actual knowledge, is not aware of facts
   or circumstances from which infringing activity is apparent; or         

       ``(C) upon obtaining such knowledge or awareness, acts expeditiously
   to remove, or disable access to, the material;                          
       ``(2) does not receive a financial benefit directly attributable to 
   the infringing activity, in a case in which the service provider has the
   right and ability to control such activity; and                         
       ``(3) upon notification of claimed infringement as described in     
   subsection (c)(3), responds expeditiously to remove, or disable access  
   to, the material that is claimed to be infringing or to be the subject  
   of infringing activity, except that, for purposes of this paragraph, the
   information described in subsection (c)(3)(A)(iii) shall be             
   identification of the reference or link, to material or activity claimed
   to be infringing, that is to be removed or access to which is to be     
   disabled, and information reasonably sufficient to permit the service   
   provider to locate that reference or link.

Journalist, beware!

And as a contrast, here's the first amendment to the United States Constitution. Remember that the first ten amendments are called the Bill of Rights:
 

The First Amendment to the United States Constitution.
Congress shall make no law respecting an establishment of religion, or prohibiting the free exercise thereof; or abridging the freedom of speech, or of the press; or the right of the people peaceably to assemble, and to petition the government for a redress of grievances. 

Congress -- what about the preceding sentence don't you understand?

You never know about the Supreme Court, but I think the first amendment invalidates the "no links to cracks" provision of the DMCA. But until the case gets to the Supreme Court, watch your back.

Microsoft and the Denial of Free Enterprise Attack

Kevin Mitnik can't hold a candle to Microsoft. Microsoft are the true masters. And when it comes to free enterprise, Microsoft's exploits are legendary. If you've ever found yourself without software choices, you've probably been the target of a Microsoft DOFE attack.

Microsoft has so many available tools and exploits it's hard to know where to begin. But one possible attack would begin almost kindly, with Microsoft approaching a maker of software utilities and offering to make them rich by bundling the utility with Windows. It's a good deal, but most people want to at least think about such a deal. And when such a hypthetical software utility maker asks for time to think it over, it's Microsoft could remind the company that if their utility isn't packaged with Windows, their competitor's will be. Or if the competitors won't sell, Microsoft will hire 100 programmers and make an equivalent utility. Any way you look at it, the days of making a profit selling that utility directly to the public are over. So if you want a defragmenter or disk compression utility, Microsoft is pretty much the only game in town. Attacker 1, competition 0. This is called the OYCR exploit. Can you guess what it stands for?

But of course, the offer you can't refuse won't work with a vendor who has captured the marketplace. Take Netscape as an example. So Microsoft, who are worth billions, hires a few hundred programmers to make Internet Explorer (modify Spyglass Mosaic or whatever), gives it away, and starves Netscape. Netscape can no longer afford the programming talent to keep up. Meanwhile, Microsoft ties Internet Explorer intimately to the Operating System, so only Internet Explorer can possibly offer all the Windows-centric features their marketing folks have convinced people they can't live without. Bye bye Netscape. This is the BFM (Brute Force Money) exploit.

Now occasionally a company defends against Microsoft BFM attacks with a copyright. That's what happened with Sun's Java. So Microsoft launched an EEE attack. They actually embraced Java, licensing it from Sun and offering it to their customers. They then extended Java, hopelessly entangling it to the Windows operating system in such a way that it would work extremely well on Windows, and not at all on other platforms. Just as Microsoft launched the extinguish phase of their attack, Sun won a court battle and Microsoft could no longer call their software Java. At that point Microsoft began to abandon Visual J++, proving to all but the densest that their sum and total reason for Visual J++ was as a tool to launch an EEE attack.

But Microsoft has a lot more tools available in their cracker toolbox, so they've launched a vaporware attack on Java. They've chosen their C# and .Net "technologies" as the introductory step. These tools will be out "real soon now", so many software projects are choosing to wait for C# and .Net rather than code in already-ready Java.

The vaporware attack is really a subset of the FUD attack. The black hat simply places fear, uncertainty and doubt in the minds of potential buyers of their competitors' products. FUD attacks have been used for years to keep superior Borland (scuse me, Inprise) at bay. "They might make good stuff, but how do you know they'll be in business tomorrow?".

Watch out for Microsoft's EMOD (Error Message Of Death) attack. The classic example is their successful destruction of DR DOS in the early 1990's. When the user attempted to install MS Windows over DR DOS, the installation errored out. I personally believe that error message was intentional. So did Caldera, the heirs of DR DOS, according to their lawsuit against Microsoft. I quote clause 3J:
 

"(j)Creating intentional incompatibilities between Windows 3.x and non-Microsoft DOS Software, in particular DR DOS and Novell DOS."

The full text of the lawsuit can be found at http://techlawjournal.com/courts/caldera/Default.htm.

Although the DR DOS escapade is by far the best known EMOD exploit, it is suspected that other examples exist.

Microsoft's cruelest exploit is saved for its most strident enemies. It's called the TIYLC attack. This is your last chance. After years of fighting off OYCR, BFM, EEE, vaporware, FUD, and EMOD attacks, an enemy finds themselves bleeding red ink and out of cash. So they bring in a new chief executive, whose only charter is to keep the company alive. In waltzes Microsoft with a cash infusion and a "strategic partnership". You don't think Microsoft would control such a company, do you? Apple's the perfect example. After years of battling Microsoft, they were headed for the business park in the sky. They brought in that old Microsoft fighter Steve Jobs, who promptly made a deal with Microsoft. The future will tell whether that's one less competitor Microsoft has to worry about.

Microsoft executed a brilliant TIYLC attack just this week against their age old foe, Corel. Drenched in red ink, Corel's long time president, CEO and board chair Michael Cowpland "stepped down" on 8/15/2000, and Derek J. Burney was appointed interrum president and CEO. On 10/2/2000, Corel and Microsoft announced a "strategic alliance", involving Microsoft's infusion of $135 million for 24 million non-voting convertable shares. Now of course, a publicly traded company like Corel can't tell anybody not to buy their shares. But from Corel's October 2 press announcement on their website (URL in URL's section), I gather it was consensual. I quote:
 

We are pleased to announce this latest development in our relationship with Microsoft, and what we believe to be an important step forward in our strategy for long-term growth, said Corel's interim President and CEO Derek J. Burney. 

The next day Mr. Burney was appointed permanent president and CEO. This time I quote from Corel's October 3 press release on Burney's permenant appointment, and once again the URL is in the URL's section of this magazine:
 

Derek has demonstrated to the board's satisfaction that he is well-qualified to lead Corel into an exciting and successful future, said Jim Baillie, chairman of Corel's board of directors. He brings an outstanding level of enthusiasm and commitment to the job and is well-respected within Corel as its leader. The board is really impressed with Derek's accomplishments to date, especially how he negotiated our recently-announced alliance with Microsoft. The board decided there was no need to conduct a widespread search for a new president and CEO, since Derek is clearly the right person for the job. 
"especially how he negotiated our recently-announced alliance with Microsoft."
You've got to hand it to Microsoft. It was a brilliantly planned and executed TIYLC attack.

But we have a security problem. Now that Microsoft has placed a TIYLC trojan in Corel, they can use Corel as a base of attack for further OYCR, BFM, EEE, vaporware, FUD, and TIYLC attacks on formerly the formerly impervious world of Open Source. They can also use their infiltration of Corel to launch attacks against the user, such as their infamous Distributed Denial of Money attack (described later).

I therefore recommend switching away from all Corel products, including WordPerfect Office, Corel Draw, Ventura Publisher, Paradox, WordPerfect Law Office 2000, Netperfect, and other Corel products. Imagine what would happen if UCITA passed in Washington, Corel sold WordPerfect Office to Microsoft, and your documents were in proprietary Wordperfect format. Transition to competing free software products while there's still time.


Note: A few days ago I emailed Corel's press address soliciting their comments and their side of the story. I received no reply. This is really a shame, because until 10/3/2000 Troubleshooting Professional Magazine was a staunch supporter of Corel.

The Distributed Denial of Money Attack

The Distributed Denial of Money attack (DDOM) really showcases a proprietary company's prowess. The beginning gambits are subtle, and often the target doesn't know he's been had until his wallet is cleaned out.

Early stages of the DDOM usually feature a free or inexpensive piece of software (called "the bait")  in a competition deprived (via DOFE attack) environment. Often the bait is a program useful at home. Users bring the bait into the corporation. Scripts grow up around the bait. These aren't generalized scripts like batch files or Perl scripts, they're written in a proprietary scripting language not portable to other operating systems or apps. As time goes on, the bait undergoes ever tighter integration into other apps apps from the vendor providing the bait.

Slowly, almost imperceptably, the proprietary noose tightens, and as it does, the price increases, as does the price of the other software. About the time the target realizes that the software vendor owns their system and cannot back out, exhorbitant per-seat charges kick in.

This is a subtle, distributed attack. It's possible that almost no one piece of software from the vendor overpriced. But because each of the tens of components has a per-user charge, pretty soon the vendor owns your wallet.

Securing Your Network

The combination of DMCA, UCITA and greedy vendors make any piece of proprietary software a security hole. To the extent that you use proprietary software, lawyers can reach in and grab your data. You can secure your network by replacing proprietary software with Open Source software. I believe the most secure software is that licensed under the GNU GPL, or the GNU LGPL. By ensuring the continued availability of source code, these licenses guarantee the ability to interoperate with them. Because source is available, prices will never escalate beyond convenience costs. Your data will never be held hostage.

Immediately quitting proprietary software isn't practical in most cases. What is practical is to immediately cease upgrading proprietary software. Then, secure in the knowledge that you can import your data into Open Source software, slowly convert to Open Source.

Summary

Not all threats to your data's security come from lone computer geeks in a dank basement. Many common threats take the form of obfuscated licenses, stealth licensing, lawyers, and scheming software vendors. The best defense against these types of threats it the good old GNU GPL.
Steve Litt is a member of Linux Enthusiasts and Professionals of Central Florida (LEAP-CF). He can be reached at Steve Litt's email address.

Letters to the Editor

All letters become the property of the publisher (Steve Litt), and may be edited for clarity or brevity. We especially welcome additions, clarifications, corrections or flames from vendors whose products have been reviewed in this magazine. We reserve the right to not publish letters we deem in bad taste (bad language, obscenity, hate, lewd, violence, etc.).
Submit letters to the editor to Steve Litt's email address, and be sure the subject reads "Letter to the Editor". We regret that we cannot return your letter, so please make a copy of it for future reference.

How to Submit an Article

We anticipate two to five articles per issue, with issues coming out monthly. We look for articles that pertain to the Troubleshooting Process, or articles on tools, equipment or systems with a Troubleshooting slant. This can be done as an essay, with humor, with a case study, or some other literary device. A Troubleshooting poem would be nice. Submissions may mention a specific product, but must be useful without the purchase of that product. Content must greatly overpower advertising. Submissions should be between 250 and 2000 words long.

By submitting content, you give Troubleshooters.Com the non-exclusive, perpetual right to publish it on Troubleshooters.Com or any A3B3 website. Other than that, you retain the copyright and sole right to sell or give it away elsewhere. Troubleshooters.Com will acknowledge you as the author and, if you request, will display your copyright notice and/or a "reprinted by permission of author" notice. Obviously, you must be the copyright holder and must be legally able to grant us this perpetual right. We do not currently pay for articles.

Troubleshooters.Com reserves the right to edit any submission for clarity or brevity. Any published article will include a two sentence description of the author, a hypertext link to his or her email, and a phone number if desired. Upon request, we will include a hypertext link, at the end of the magazine issue, to the author's website, providing that website meets the Troubleshooters.Com criteria for links and that the author's website first links to Troubleshooters.Com. Authors: please understand we can't place hyperlinks inside articles. If we did, only the first article would be read, and we can't place every article first.

Submissions should be emailed to Steve Litt's email address, with subject line Article Submission. The first paragraph of your message should read as follows (unless other arrangements are previously made in writing):

I (your name), am submitting this article for possible publication in Troubleshooters.Com. I understand that by submitting this article I am giving the publisher, Steve Litt, perpetual license to publish this article on Troubleshooters.Com or any other A3B3 website. Other than the preceding sentence, I understand that I retain the copyright and full, complete and exclusive right to sell or give away this article. I acknowledge that Steve Litt reserves the right to edit my submission for clarity or brevity. I certify that I wrote this submission and no part of it is owned by, written by or copyrighted by others.
After that paragraph, write the title, text of the article, and a two sentence description of the author.
 

URLs Mentioned in this Issue