Re: verizon wireless website gaping privacy holes

From: Mark Parry (Markat_private)
Date: Mon Sep 03 2001 - 10:10:20 PDT

  • Next message: Stuart Moore: "Re: Possible Issue with Netinfo and Mac OS X"

    I think things like this are a good thing to bring up,  maybe we can badger
    web developers into using a bit of common sense in their application design.
    
    One quick thing I would like to bring up is: people are noticing this
    problem when things like session keys or account numbers are passed in the
    URL, however, I believe that many many more sites pass this info with a
    cookie, and this is just as bad, but harder to notice.
    
    If you wonder about this problem with any web site that you use, I suggest
    grabbing Achilles.  It's a proxy server that you can just run on your own
    machine, and it shows you the full request that the browser sends to the web
    server, including any cookies.  (are you maybe passing a trivial session
    number or an account number in that http request???)  I am not affiliated
    with the authors of this program but I will say that I appreciate them
    writing it.
    
    http://www.digizen-security.com/downloads.html
    
    
    Thanks,
    Adept
    adeptat_private
    ----- Original Message -----
    From: "Marc Slemko" <marcsat_private>
    To: <bugtraqat_private>
    Sent: Saturday, September 01, 2001 7:36 PM
    Subject: verizon wireless website gaping privacy holes
    
    
    > Verizon Wireless (a fairly large US cell service provider) has a
    > website.  One feature of that website allows you to access your account
    > and do things such as view your bills and recent usage and modify your
    > service.
    >
    > Cell phone bills are often very interesting things, since they contain
    > names, addresses, and a complete record of calls placed and received,
    > along with the approximate location the user was when the call was
    > made.  I'm sure I'm not alone in expecting my provider to provide a
    > reasonable level of privacy for this data.
    >
    > A typical URL used by this "my account" service is:
    >
    >
    https://www.app.airtouch.com/jstage/plsql/ec_navigation_wrapper.nav_frame_di
    splay?p_session_id=3346178&p_host=ACTION
    >
    > Note the p_session_id parameter.  This is the only session identifier
    > used.  They are assigned sequentially to each user as they login, and are
    > valid until the user logs out or the session times out.  Obviously, this
    > makes it trivial to access the sessions of other users by guessing the
    > session ID.  Automated tools to grab this information in bulk as users
    > login over time are also trivial.
    >
    > I notified Verizon Wireless about this on August 19th, telling them that
    > if I did not receive a response within a week that at least indicates they
    > are aware of the problem and are working on it, I would do whatever I
    > could to ensure the public knows about they inexcusable ineptitude, and
    > that verizon wireless customers can take whatever steps possible to
    > protect themselves.  Verizon Wireless has not responded to me, nor have
    > they fixed the problem.
    >
    > If you are a verizon wireless customer:
    >
    > 1. Do NOT use their online "My Account" feature.  If you do not login,
    > then this vulnerability can not be used to hijack your session.
    >
    > 2. Contact them to let them know what you think of their complete lack of
    > attention to the most basic security concepts involved with designing a
    > web application.  I am evaluating other alternatives for cellular service.
    >
    >
    > Note that this application of theirs also appears to have other,
    > potentially far more serious, security flaws.  Looking at the example URL
    > given above, two alarm bells should go off; one because the session ID
    > looks very weak.  I won't name the other, but it (not particular to
    > verizon wireless) has been referenced on bugtraq before and is quite
    > obvious.  I am not discussing the other potential hole both because a user
    > can't protect themself against it (unlike the session ID bug) and because
    > I can not verify if it is actually a hole or not for certain without
    > potentially violating US laws.
    >
    > Companies need to get it through their heads that they must pay attention
    > to the security of their online offerings.  If they can't do that, then
    > they should just turn the site off and go home.  It is somewhat troubling
    > that, even if a customer does have the technical knowledge required to
    > check for basic security blunders on sites they use, they may be unable to
    > do so in most countries without breaking the law.  The verizon session id
    > bug is different in that I could test it using multiple accounts that I am
    > authorized to access, without incurring any unauthorized access to the
    > accounts of third party "innocents".
    >
    >
    



    This archive was generated by hypermail 2b30 : Mon Sep 03 2001 - 21:50:32 PDT