RE: Software vendor clueless

From: Mark Medici (markat_private)
Date: Tue Aug 19 2003 - 15:01:37 PDT

  • Next message: Kevin Patz: "Re: Increasing ICMP Echo Requests"

    > All,
    > I have a customer whose company does legal work for lots of 
    > businesses.  
    
    Legal work meaning what?  Is the client an attorney or law firm, where
    there are clear laws, regulations and codes of ethics regarding
    confidentiality?
    
    > The data housed on their network is what I would call 'financially 
    > sensitive'.  
    
    What do you mean by "financially sensitive?"  Do you mean the client's
    accounting records are stored on the server?  Or, more sensitive, are
    bank account access data or employee payroll/tax id data stored on the
    server?  Or, most sensitive, confidential customer data?
    
    Does the client share your view about the sensitivity of this
    information?  Did you discuss the matter to understand their view of the
    situation?  Have you performed a business impact analysis to determine
    the risk?  
    
    > Recently, I found their Exchange server had been 
    > turned into an open relay.  It was not that way a month ago.
    
    So you are saying that one month ago you documented the Exchange 5.5
    server configuration and that it was properly configured to deny relay.
    Subsequent to documenting the configuration, someone changed the
    settings to allow anonymous relay (Exchange 5.5's default
    configuration).  If this is indeed the case, then it indicates that
    someone has gained unauthorized, privileged access to the server.  This
    might have been done by someone with permissions to make the changes, or
    it might have been done by an intruder.  If nobody is willing to admit
    to making the changes, then you are right to assume the worse.
    
    Assuming the worse, changing the administrator account's password is,
    unfortunately, an ineffective response.  Any intruder worth his salt
    would have installed at least two backdoor methods to regain access to
    the system.  Ideally, the server should be rebuilt from bare iron on
    freshly-formatted disks, hardened before allowed to connect to a
    network, then the data restored.  The data in the Exchange stores will
    be problematic.  Depending on the size of the organization you might
    decide to manually move all the Exchange information stores content to
    .PST file, or use exmerge.exe from Microsoft.  Considerable "touching
    up" will be required.
    
    If you (or the client) decides against a complete rebuild (dangerous, in
    my view, if you know an intruder's been actively manipulating the
    system), then you need to audit every single user, computer and service
    account; change every password; run multiple anti-virus, anti-Trojan and
    anti-spyware packages; and attempt to validate every executable file on
    the system.  You should also, at least short-term, install an IDS to
    identify how the intruder broke into the system in the first place, and
    make sure that vulnerability is fixed.  Even then, I would always have a
    nagging concern that something was missed.
    
    > Once I stopped the 
    > bleeding, I told them I wanted to change the Administrator password, 
    > (NT4.0, Exch5.5.  I know, I know).  They told me they were 
    > not allowed to change the password.  "Sez WHO", I asked.  "Our
    software 
    > vendor", they 
    > replied.  Turns out the vendor in question has a niche market in this 
    > kind of legal field.  Also turns out they use the same 4-letter, (no 
    > caps, no special chars), administrator password on ALL their 
    > customers networks.  
    
    Obviously, the software vendor is not providing overall support for the
    client, otherwise they would not be paying for your expertise.  In my
    experience, any software vendor with a rule that the end user client
    cannot change the administrator password is more than willing to
    accommodate when challenged on the issue.  Particularly if you consider
    (and tell them you're considering) the probability that one of their
    employees, customers, or ex-employees/customers are likely to be
    responsible for the intrusion, and their negligence is considering
    security is a significantly contributing factor.
    
    > To make matters worse, they have PCAnyWhere ports 
    > open on all these networks, because their software is so buggy, the 
    > developers need to remote in and fix things all the time.  
    > The spokesman for the group 
    > claims that the AT&T managed firewall prevents anyone else 
    > from using the PCNoWhere ports by IP address.
    
    Properly configured, pcAnywhere can be nearly as secure as VPN access.
    pcAnywhere can be setup to require two-level user authentication and
    public key encryption of all traffic.  The pcAnywhere ports can be
    easily configured for non-standard values, and measures to protect
    against password cracking and abandoned/broken sessions are available.
    If securely configured and used in combination with a firewall that
    restricts access to predetermined, trusted external IP addresses, then
    pcAnywhere poses very little security risk.  
    
    > I'm not a great negotiator, and I'm going to face the SW 
    > spokesman next 
    > week.  He is a good spin doctor.  I'm looking for help in making him 
    > secure his stuff.  All help is appreciated.
    
    Look at it this way: If your mutual client gets hacked and confidential
    information is misused due to the software vendor's negligence in
    adequately securing their information:
    
      1.) The client may be sued, and the software vendor may be named
          as a co-defendant by all damaged third parties.
      2.) The client will likely sue the vendor directly, regardless of
          prior contracts and disclaimers.
      3.) The negative publicity regarding the vendor's gross negligence
          will, at best, force them to change their policies reactively,
          and at worst will diminish their reputation and cost them
          business.
      4.) The cost to resolve the problem reactively, during a crisis
          situation, will be more expensive and difficult than a planned,
          proactive approach to implement proper security.
      5.) At minimum, the vendor will lose one loyal customer.
    
    Between you and me, I would leave out the stuff about their software
    being full of holes and other deprecating remarks.  The fact is that all
    software is buggy, and it wasn't their software that was exploited
    (though their lax security was contributory.  Vertical-market stuff that
    must be customized per-customer according to their business needs
    frequently needs lots of support from the developer, since every client
    has their own idea of how reports should look and data should be
    categorized.  The ability to quickly accommodate your client's unique
    requirements is probably what attracted them to the vendor in the first
    place.
    
    Finally, consider the fact that the client has probably invested a
    considerable amount of money in their software, customization, ongoing
    support and, most important, data entry.  If you put yourself in an
    adversarial position versus the software vendor, you will likely find
    yourself out of a gig.
    
    ---------------------------------------------------------------------------
    Captus Networks - Integrated Intrusion Prevention and Traffic Shaping  
     - Instantly Stop DoS/DDoS Attacks, Worms & Port Scans
     - Automatically Control P2P, IM and Spam Traffic
     - Ensure Reliable Performance of Mission Critical Applications
     - Precisely Define and Implement Network Security and Performance Policies
    **FREE Vulnerability Assessment Toolkit - WhitePapers - Live Demo
    Visit us at: 
    http://www.securityfocus.com/sponsor/CaptusNetworks_incidents_030814
    ----------------------------------------------------------------------------
    



    This archive was generated by hypermail 2b30 : Tue Aug 19 2003 - 21:09:05 PDT