From: bryan allott (homegrown@bryanallott.net)
Date: Wed Sep 28 2005 - 14:05:15 EDT
>>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 -------------------------------------------------------------------------------
This archive was generated by hypermail 2.1.7 : Sat Apr 12 2008 - 10:55:00 EDT