Vulnerability analysis site

Discussion in 'Computer Security' started by Ken van Wyk, Jul 30, 2003.

  1. Ken van Wyk

    Ken van Wyk Guest

    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 --
    or go directly to the analyses at

    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

    Although the book isn't free, we're maintaining the web site* as a free
    "book companion" resource. No registration, subscription, etc., is

    * The web site is graciously hosted by our friends at


    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 (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

    "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?


    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,, 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.


    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.


    Mark G. Graff
    Kenneth R. van Wyk
    29 July 2003


    [1] Morris, Robert T. "A Weakness in the 4.2BSD Unix† TCP/IP
    Software". AT&T Bell Laboratories,
    [2] Dole, Bryn, Steve Lodin, and Eugene Spafford. "Misplaced Trust:
    Kerberos 4 Session Keys." Proceedings of the 1997 ISOC
    Conference. 1997. Available online at
    [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.
    Ken van Wyk, Jul 30, 2003
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.