Re: DCOM Security.

From: bryan allott (homegrown_at_bryanallott.net)
Date: 09/28/05

  • Next message: Steve McLaughlin: "RE: Topology discover" 
    To: "Chris Fahey" <cfahey@ceservices.com>, <njfanelli@hotmail.com>
Date: Wed, 28 Sep 2005 20:05:15 +0200

    >>How concerned should I be with the possibility of the code
    >>being decompiled? Additionally the programmer has domain credentials
    >>hard coded into the application in order to perform an upload of
    >>information that is created.

    code can be decompiled *relatively* easily but also depends how the
    information is stored [i'm assuming c++ here] global char*, or local
    std::string maybe or easier yet, a resource file [i wont claim to know about
    the relative degrees of complexity here, suffice to say there seems to be
    enough academic material [with working tools] to decompile binaries and
    recover "constants" embedded in the code]
    but in order to get it decompiled, another question has to be raised: how
    did the "decompiler" get hold of a copy of the binary in the first place? in
    which case, anything can happen [decompile, reverse engineer, plug in own
    code to, say, sniff usage, and redeploy, act as nothing has happened-
    perhaps even more frightening]. it also means [having the password in the
    code] that you trust yr development team :) u shouldnt really. a disgruntled
    tech-savvy programmer can be bad news. and u also need to protect the
    programmer from suspicion in case there is a compromise!

    i guess tis why the practice of embedding any type of credential in
    applications has been avoided.
    [ besides the logistical problems of credentials changing over time,
    security policies or in case they do get compromised :) which would require
    a recompilation of the code- not ideal ]
    so another question to ask is, in the event of a compromise, credentials
    embedded or not, what's the strategy for changing credentials and moving on
    without disabling the service?

    >>suggestions?
    u could store the credentials offline in a secure repository, only
    accessible by using a trusted cert, assymteric key [and a dozen more] pick a
    strategy. then of course, u spend time securing the repository of
    credentials, but at least the code can be flexible enough to pick up an
    artifact by means of a public/common name, and verify the artifact using a
    trusted source [risky if implemented badly] before accessing the password.
    so i guess that's my main point: however u store credentials in/out of code,
    also ensure there's some mitigation strategy in place in case of compromise.
    chances are there could be. but layers of defense are key [no pun intended]
    here, as always- dont think there's a single silver bullet. at least the
    risk of decompiled code getting out [ security wise, but def not business
    wise :) ] will be lowered somewhat.

    u could use the SSL or PKI protocols as models for an app to get a password.
    depends on the risk and what it i$ worth. and where the app is sitting. if
    the machine where the app is sitting is compromised, u can focus on other
    things. but ideally, yr application should never know the password. its
    better if it knows, by easy configuration, where to get the right password
    by presenting a trusted piece of evidence [also configurable].

    ----- Original Message -----
    From: "Chris Fahey" <cfahey@ceservices.com>
    To: <njfanelli@hotmail.com>
    Cc: <pen-test@securityfocus.com>
    Sent: Tuesday, September 27, 2005 11:27 PM
    Subject: RE: DCOM Security.

    Sounds like a fairly old custom app. Back then it was common practice to
    have usernames/passwords embedded in the code. What I would be concerned
    about is if it is using ipsec, how secure is it? If the key can be
    compromised then it wouldn't be hard to sniff the usernames/passwords
    off the network.

    -----Original Message-----
    From: njfanelli@hotmail.com [mailto:njfanelli@hotmail.com]
    Sent: Monday, September 26, 2005 12:54 PM
    To: pen-test@securityfocus.com
    Subject: DCOM Security.

    I'm unfamiliar with Microsofts component services.
    A client of mine has a local workgroup application that creates a
    connection (ipsec) to a domain server, the application calls a server
    component (dcom) via anonymous access. The developer has a password
    embedded with in the local app to authenticate the anonymous account.
    >From this point the component forwards over a request to another server
    for a Foxpro database (without any additional security). Is there a way
    to exploit the anonymous account if the workgroup client were to get
    compromised? How concerned should I be with the possibility of the code
    being decompiled? Additionally the programmer has domain credentials
    hard coded into the application in order to perform an upload of
    information that is created. Suggestions? Thank you in advance

    Nicholas Fanelli

    ------------------------------------------------------------------------
    ------
    Audit your website security with Acunetix Web Vulnerability Scanner:

    Hackers are concentrating their efforts on attacking applications on
    your
    website. Up to 75% of cyber attacks are launched on shopping carts,
    forms,
    login pages, dynamic content etc. Firewalls, SSL and locked-down servers
    are
    futile against web application hacking. Check your website for
    vulnerabilities
    to SQL injection, Cross site scripting and other web attacks before
    hackers do!
    Download Trial at:

    http://www.securityfocus.com/sponsor/pen-test_050831
    ------------------------------------------------------------------------
    -------

    This message (including attachments) contains confidential information from
    Competitive Edge Services, Ltd. intended for a specific individual and
    purpose. The contents of this message are protected by law and are only for
    the viewing or use of the intended recipient. If you are not the intended
    recipient, you should return this message to Competitive Edge Services, Ltd.
    and then delete the message. Disclosing, copying, distributing, or acting
    upon the contents of this message is strictly prohibited.

    ------------------------------------------------------------------------------
    Audit your website security with Acunetix Web Vulnerability Scanner:

    Hackers are concentrating their efforts on attacking applications on your
    website. Up to 75% of cyber attacks are launched on shopping carts, forms,
    login pages, dynamic content etc. Firewalls, SSL and locked-down servers are
    futile against web application hacking. Check your website for
    vulnerabilities
    to SQL injection, Cross site scripting and other web attacks before hackers
    do!
    Download Trial at:

    http://www.securityfocus.com/sponsor/pen-test_050831
    ------------------------------------------------------------------------------- 

    -- 
No virus found in this incoming message.
Checked by AVG Anti-Virus.
Version: 7.0.344 / Virus Database: 267.11.8/113 - Release Date: 27-Sep-05
------------------------------------------------------------------------------
Audit your website security with Acunetix Web Vulnerability Scanner: 
Hackers are concentrating their efforts on attacking applications on your 
website. Up to 75% of cyber attacks are launched on shopping carts, forms, 
login pages, dynamic content etc. Firewalls, SSL and locked-down servers are 
futile against web application hacking. Check your website for vulnerabilities 
to SQL injection, Cross site scripting and other web attacks before hackers do! 
Download Trial at:
http://www.securityfocus.com/sponsor/pen-test_050831
-------------------------------------------------------------------------------
  • Next message: Steve McLaughlin: "RE: Topology discover"
    • Quantcast