Re: DCOM Security.

["bryan allott" <homegrown () bryanallott net>]

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