Hacker Challenges -- Boon or Bane?

In the past year, several businesses have made resources publicly available on the Internet and challenged all comers to find bugs in them or break into them. Incentives offered to those who reported valid break-ins or bugs have ranged from T-shirts to cold cash. Recently, Gene Spafford of Purdue University decried this growing practice in a message circulated widely on the Internet. Cipher has obtained responses from some of the organizations who have sponsored challenges of one sort or another, and circulating them along with that note. We thank Prof. Spafford and the organizations who responded to our request for comments.

A Few Comments on "Hacker Challenges"

I note with dismay the increasing number of "hacker challenges" used in marketing security products. I think these are actually harmful to the profession and practice of security, rather than helpful. I believe the harm comes in two ways: (1) the challenges don't serve as any real test of the products, and it denigrates security professionals by suggesting that they should accept them as proof of security; and (2) it helps reinforce the image that there should be some form of reward for hacking through security measures. Neither of these are views we should responsibly seek to promote.

Consider the nature of showing the security of a product. Does a "challenge" meet the goal of testing, which is to increase one's confidence in the correct functioning of the artifact? It really doesn't, for a number of reasons:

• Few such "challenges" are conducted using established testing techniques. They are ad hoc, random tests. Thus, there is no way of determining final coverage. For instance, if 90% of all challenge attacks are of the same variety, what has the "test" really shown? (Consider testing a calculator. If you perform 10,000 tests, but 9000 of them are addition with zero, have you done a thorough job of testing?)
• That no problems are found does not mean that no problems exist. It may mean that the testers didn't expose them. Doing random, black-box testing remotely is not likely to really test much of the product. (Challenge testing is basically a form of black-box testing.)
• That no problems are reported does not mean that no problems exist. The "testers" might not have recognized them. (Look at how often software is released with bugs, even after careful scrutiny -- users don't always recognize anomalies.)
• That no problems are reported does not mean that no problems exist. How do you know that the "testers" will report what they find? How do you know the vendor is getting accurate data? If Jane Random Hacker found a way to penetrate the product in a manner that vendor monitoring didn't expose, it is possible she'd find more profitable uses (later) for that information than informing the vendor about it. Further, because of possible problems with the law, hackers might not want to report success and draw attention to themselves.
• Simply because the vendor does not report a successful penetration does not mean that one did not occur -- the vendor may choose not to report it because it would reflect poorly on its product, or not meet the narrow criteria for a "successful" penetration, or the vendor may not be able to detect it happened. (How can anyone outside prove otherwise?)
• Seldom do the really good experts, on either side of the fence, participate in such exercises. Thus, anything done is usually done by amateurs. (The "honor" of having won the challenge is not sufficient to lure the good ones into the fray. Good consultants command fees of several thousand $$ per day in some cases -- why should they donate their time and names for what amounts to free consulting and advertising?)

Also note that any such challenge also serves to aid potential hackers in their later pursuits:

• It gives potential miscreants some period to practice breaking the system without penalty. Any other time spent hacking at one of these might result in legal action or worse. Isn't it nice the vendor is giving free practice time to the bad guys? I hope all the potential customers are equally pleased at this.
• It gives miscreants an excuse if they are caught trying to break into the system later (e.g., "We thought the contest was still on.") This might well weaken any legal action taken later.
• The vendor contest may actually even include some publication of hacks that don't work -- thus helping reduce the effort to compromise the system later.

Furthermore, the whole process sends the wrong message -- that we should build things and then try to break them, or that there is some prestige or glory in breaking systems. That isn't what we need. Instead, we want to promote responsible behavior, using established methods. We need to establish that security is something best done by well-trained professionals, and that hacking into systems is not "job training". (I've argued this point in more detail in "Are Computer Break-Ins Ethical?", Journal of Systems and Software, Jan 1992, 17(1).)

Good security should be carefully designed in and tested using established methods. Tiger teams have a role, but using them (especially ad hoc teams) as a major means of establishing safety is negligent. Security "contests" to demonstrate a system are worse, and should be viewed negatively by potential customers. It should be generally recognized that such contests cannot establish more than cursory confidence in a product, are not a good means of testing, and actually create a climate that may encourage or enable people to try to break the product after it is in use.

If I was a potential customer of any security product, which of the following, somewhat exaggerated approaches would be more likely to convince me that a company had its act together? Which one is the company more likely to be seeking to sell based on smoke and mirrors?

• Approach A: Our product was coded by a bunch of really talented hackers and former system crackers who learned everything they know on the IRC. We put our product up on the Internet for 6 months, and offered a nifty backpack and some money to anyone who could break in. No one claimed the prize. Obviously, ours is a superior product.
• Approach B: Our company is certified as an ISO 9000 company. We used formal software engineering approaches to design and build our product, ending in full functional testing, D-U path testing, and statement coverage to 98%. We also hired well-known independent security experts A, B, and C under non-disclosure to examine the code and identify weaknesses, and then conduct field trials. Company X and University Y have also had the opportunity to examine and test our product, and none of them have found flaws.

Approach "B" is clearly the one we want to encourage. Approach "A" encourages cycles of "penetrate and patch" and that is what is wrong with most mass-market software available today. However, vendors claim that Approach "A" is what sells more product than Approach "B," in part because it seems to inspire more confidence, and in part because it is cheaper to produce software if they don't use an approach like "B".

If we, as a community and a profession, want better quality and more trustworthy products, we must begin to demonstrate it. The best way is in the marketplace, by showing a willingness to buy based on substance, and not flash. Saying "no" to attempts to sell us products based on "hacker challenges" is one way to do that.

Replies:

Most of Gene's points are very valid, and I agree with them. His points are aimed at challenges promoted by a company in order to show that a product is secure. On the other hand, the Community ConneXion challenges are promoted in order to show that a product is *insecure*.

It's easy to prove insecurity, but hard to prove security. The vendor-supported challenges are trying to prove security, which is rather misguided. In proving insecurity though, our challenges are rather simple, as they only require one counter-example to be proven that a system is insecure.

We received a very similar letter from Mr. Spafford when we first began our contest and posted an extensive reply on our site while it was in operation. I will summarize the main points for Cipher readers:

1) Mr. Spafford says that these challenges are a poor way of testing software.
That is true, however it was never our purpose to test the software by running a challenge. The testing has been completed or we would not have been confident enough to place $10,000 on the line. The main purpose of our security challenge was to promote awareness of the existence of security options for Macintosh servers. It was never intended as proof of the security of the system or to replace rigorous testing.

2) Mr. Spafford says that these contests promote hacking.
We disagree with that entirely. By his argument, the Daytona 500 is responsible for people driving too fast on highways. I think there are people who drive as if they are on a race track (one passed me this morning on my way to work) but it is clear that rules on the highway are different from rules on the race track and no court in the land would let a person get away with arguing differently. We clearly stated on our site the limitations of the contest including a warning that we were not condoning similar attacks on systems other than the one provided for the contest.

3) Mr. Spafford says that these contests make it easier to break other systems.
Mr. Spafford is looking in the wrong place. Bulletin boards, newsletters, Web sites and more all exist with information on how to hack into systems. Books have been written on the subject, movies made, and special investigative reports offered on television all on the subject. Writing about what failed on our site will not help hackers significantly. Our site also did not provide free practice to hackers because *none of the attempts worked*. Practice is useless if you do not at some point succeed.

4) Mr. Spafford says that it is wrong to test things by trying to break them.
I don't think he thought about what he was saying there. What is beta testing but an attempt to find where software will break? Stress testing for metal structures? Crash testing cars? It is a fact of life that part of testing a product is to find where it will fail, which means trying actively to break the product in a variety of ways.

In summary, it is our opinion that Mr. Spafford's letter has no bearing on the challenge that we had online. He probably would have been better served by investigating our site more thoroughly before writing the letter.

My quick reaction is that the Netscape Bugs Bounty is not a "hacker challenge". It is a way to reward users for helping to find bugs that get past us. I don't think that we make any claims such as "our product must be secure because no one claimed our hacker prize". We also don't view the bug bounty as a replacement for our own QA efforts, but a supplement to it.