Home page logo
/

pen-test logo Penetration Testing mailing list archives

Re: Subverting eTrust Access Control on UNIX (file execution)
From: "arvind doraiswamy" <arvind.doraiswamy () gmail com>
Date: Wed, 10 Dec 2008 22:00:30 +0530

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


  By Date           By Thread  

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