For those interested, my co-author (Mark Graff) and I have been posting and
 maintaining a free repository of analyses of some recent/topical
 vulnerabilities on our book's web page, at http://www.securecoding.org --
 you can alternatively go directly to the analyses at
 http://www.securecoding.org/companion/analysis/.
 
 In these periodic "columns", we analyze the root causes (no pun intended) of
 some recent vulnerabilities and discuss ways of preventing similar mistakes
 in the future.  We also look at where in the development process (e.g.,
 architecture, design, implementation, operations) the flaws were likely to
 have been introduced.  I've attached our most recent write-up below as an
 example.
 
 Although the book isn't free, we're maintaining the web site* as a free
 "book companion" resource.  No registration, subscription, purchase, 
 etc., is necessary.
 
 * The web site is graciously hosted by our friends at http://www.nidhog.com.
 
 Cheers,
 
 Ken van Wyk
 Mark Graff
 Co-authors of "Secure Coding: Principles and Practices" (O'Reilly, 2003)
 
 =====
 
 Copyright (C) 2003, Mark G. Graff and Kenneth R. van Wyk. Permission granted
 to reproduce and distribute in entirety with credit to authors.
 
 29 July 2003
 
 We figure our readers must know as much about new gadgets as any group
 in the world. So we are going to ask you to keep an eye out for one
 (we'll describe it later) that we think might prevent vulnerabilities
 like the one under the microscope today.
 
 The flaw was first reported by security firm ThreeZee. The full text
 of their advisory is available at
 http://www.threezee.com/sections/security/tzt001.txt.  (As always, we
 encourage you to read the original advisory in full. There's always
 more to the story than we cover here.)
 
 ThreeZee points out a problem with a particular mobile phone service
 provider's messaging software.  It turns out that any visitor to the
 provider's web site can predict the ID numbers associated with text
 messages, also known as Short Message Service (SMS) messages. That
 simple ability opens up a gaping security hole. You could (but please
 don't) obtain for yourself the delivery reports intended for message
 senders. You could get the email addresses of the recipients, too.
 
 What's the big deal about that?  Well, by combining that information
 with a couple of other flaws, an attacker could eavesdrop on new text
 messages sent to the cell phones. Potentially, one could gain at least
 partial control of a cell phone account.  It's a classic example of
 step-by-step system compromise, where each new plateau reached yields
 information making further compromise possible. If we were the
 each-new-dawn-a-miracle type, we would call it beautiful.
 
 But the bug itself is quite a curiosity, too. The principal flaw:
 message ID's are coined in a predictable sequence. Once you know one,
 you can deduce a practically unlimited number of them; and knowing
 those message ID's unlocks all that information you're not supposed to
 be able to get to. Here's how the advisory explains the prediction
 method.
 
         "While the Tracking, or message ID may look foreign in ways,
         it's quite simple.
  
         Think of the way an odometer turns on a car. That is the basic
         idea of the ID.
  
         Example 1: MsgID4_A54GKVHD 
  
         Example 2: MsgID4_3M5GKVHD
 
         Starting after the '_', the message ID will progress in the
         order of A - Z, and 0 – 9. There seems to be no association
         with the time sent, or who it was sent to. Like the odometer,
         when a character/digit of the ID reaches the end (9), it will
         restart at A, and the preceding character will increase by 1."
 
 Does this seem familiar? Where have we seen this before?
 
 Well, for starters, Robert Tappan Morris described a similar
 vulnerability in his 1985 paper [1] at AT&T Bell Labs. The problem he
 unearthed there had to do with predicting sequence numbers used in the
 TCP protocol. In Chapter 4 of Secure Coding, we cite a conceptually
 similar problem [2] in version 4 of MIT's Kerberos system. In that
 case, the designers really tried to make the initial sequence numbers
 "random" (hence, unpredictable) but still came up short.
 
 Now those design errors were made in the 70's and '80s, the bad old
 days. How could such a problem get introduced into a web site "in this
 day and age"?  Well, it's easy, really. Let's ask instead: how could
 it have been avoided?
 
 
 WHAT CAN GO WRONG?
 
 In some of the better Software Engineering curricula we are familiar
 with, the value and power of a process known as "domain analysis" is
 taught. It's basically a fancy way to learn from the mistakes of
 others.  The point is to locate, study and analyze during the design
 process similar problems that cropped up in earlier projects. We
 recommend the practice. (In fact, as we write this, one of us is
 undertaking just such a study for an important design we are
 participating in.)
 
 There's not always time for domain analysis. Even if there were, our
 profession is so new--and the world we deal with still so
 abstract--that we don't have the great body of disasters other
 engineers do to draw upon for inspiration. (To get a start, you might
 try Perrow [3], Neumann [4], and Reason [5] for stories, respectively,
 of catastrophic engineering errors; computer-related disasters; and
 common human errors in risk evaluation. In addition to Peter Neumann's
 above book, his superb on-line RISKS Digest,
 http://catless.ncl.ac.uk/Risks/, is a great forum to study and learn.) 
 So what is the best way for a programmer operating under real-world
 constraints to identify lurking design-level errors?
 
 Train yourself to ask the question, "What can go wrong?"  When
 designing a piece of software, the design team should be considering
 the ramifications of their design choices from exactly that
 perspective.  What would happen if someone were able to guess the
 value of any arbitrary message ID on the text-messaging portal?  What
 could an attacker do with that information?  It's our experience that
 once you start down that road, you'll often find yourself rooting out
 one potential design weakness after another. In this case, maybe it
 would have sufficed to pass onto the implementer a note that message
 ID's should be reasonably unpredictable.
 
 
 A MIRACLE OF A RARE DEVICE
 
 We opened this analysis with a mention of a device we had an idea for
 that could help prevent vulnerabilities like this.
 
 We would like this gizmo to hover above our shoulder all of the
 time. (Or you could build it into, let's say, the kind of pith helmet
 worn by jungle explorers. That would be OK.) Our main requirement is
 that it must sound a loud gong whenever we need to ask the question,
 "What can go wrong?" Once a project should be enough. Hey, by the way,
 solar power would be a neat add-on feature.
 
 Until we have one, we'll try to remember to ask the question
 ourselves--or, better yet, use a checklist to help remind us to ask
 the questions.
 
 Cheers,
 
 Mark G. Graff
 Kenneth R. van Wyk
 29 July 2003
 
 
 REFERENCES
 
 [1] Morris, Robert T. "A Weakness in the 4.2BSD Unix† TCP/IP
 Software". AT&T Bell Laboratories,
 1985. http://www.pdos.lcs.mit.edu/~rtm/papers/117.pdf
 [2] Dole, Bryn, Steve Lodin, and Eugene Spafford. "Misplaced Trust:
 Kerberos 4 Session Keys." Proceedings of the 1997 ISOC
 Conference. 1997. Available online at
 http://www.isoc.org/isoc/conferences/ndss/97/dole_sl.pdf.
 [3] Perrow, Charles. Normal Accidents. New York, NY: Princeton
 University Press, 1999. ISBN 0691004129.
 [4] Neumann, Peter. Computer-Related Risks, New York:
 Addison-Wesley/ACM Press, 1995. ISBN 0-201-55805-X.
 [5] Reason, James. Human Error. New York: Cambridge University Press,
 1990. ISBN 052131494.

-- 
KRvW Associates, LLC
IT Security Consulting and Training
http://www.KRvW.com
+1 703 981 7746