Re: Subverting eTrust Access Control on UNIX (file execution)

["arvind doraiswamy" <arvind.doraiswamy () gmail com>]

Well .. Not totally related this. Alll the same you'd need to gain
access to the system someway (vuln, open share, webdav, default
password, ftp whatever) before you'd think of uploading binaries.
Unless you already gained access to those folders. And if you've got
as much access as that .. you would probably just be able to turn
things off itself or drop a rootkit in there as a POC. Just another
way of thinking - You might not need to bypass at all.

Cheers
Arvind

On Mon, Dec 8, 2008 at 5:22 PM, Tim Brown <tmb () 65535 com> wrote:
> On Sunday 07 December 2008 23:42:03 RexRufi wrote:
> > One of my clients is using CA Access Control (formerly eTrust Access
> > Control) to restrict execution of certain binaries to specifically
> > authorized users. Does anyone know how eTrust determines matches for
> > purposes of restricting access, i.e. is it simply path/file name or is
> > there a hash used?
> >
> > As an authorized unprivileged user, I picture subverting this by
> > simply uploading my own version of these binaries, if needed.  If
> > eTrust is using a hash, I'll need to modify these so that they no
> > longer match.
>
> Have a look at
> http://publib.boulder.ibm.com/tividd/td/security/GC32-0707-00/en_US/HTML/tacf02.htm#ToC.
> AC is rather similar to TACF (I believe they were originally one and the
> same?).
>
> In answer to your question, it can use a multitude of methods (depending on
> precisely what policy rules are applied).
>
> The AC policy language has the concept of trusted binaries and if it is
> detected by AC that a listed binary has different metadata from that listed
> in the policy, then the meta data in the local policy is updated to flag it
> as untrusted.  Depending on the setup and your access you may be able to
> reset this flag in the local policy using selang.
>
> The trust stuff is documented at:
> http://publib.boulder.ibm.com/tividd/td/security/GC32-0707-00/en_US/HTML/tacf32.htm#Header_48.
>
> > Flags(flagName)
> > Flags that define the way in which the resource is to be trusted and how it
> > should be trusted and how it should be checked for trusted status.
> > Available flags include Ctime, Mtime, Mode, Size, Device, Inode, Crc,
> > Owner, Group, All, None.
>
> Maybe have a look at the audit logs or policy to determine on what grounds you
> are being rejected?
>
> Cheers,
> Tim
> --
> Tim Brown
> <mailto:tmb () 65535 com>
>
> ------------------------------------------------------------------------
> This list is sponsored by: Cenzic
>
> Security Trends Report from Cenzic
> Stay Ahead of the Hacker Curve!
> Get the latest Q2 2008 Trends Report now
>
> www.cenzic.com/landing/trends-report
> ------------------------------------------------------------------------

------------------------------------------------------------------------
This list is sponsored by: Cenzic

Security Trends Report from Cenzic
Stay Ahead of the Hacker Curve!
Get the latest Q2 2008 Trends Report now

www.cenzic.com/landing/trends-report
------------------------------------------------------------------------