Home page logo
/

pen-test logo Penetration Testing mailing list archives

Re: DCOM Security.
From: "bryan allott" <homegrown () bryanallott net>
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
-------------------------------------------------------------------------------


  By Date           By Thread  

Current thread:
[ Nmap | Sec Tools | Mailing Lists | Site News | About/Contact | Advertising | Privacy ]
AlienVault