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 ------------------------------------------------------------------------
Current thread:
- Subverting eTrust Access Control on UNIX (file execution) RexRufi (Dec 07)
- Re: Subverting eTrust Access Control on UNIX (file execution) Tim Brown (Dec 08)
- Re: Subverting eTrust Access Control on UNIX (file execution) arvind doraiswamy (Dec 10)
- Re: Subverting eTrust Access Control on UNIX (file execution) Tim Brown (Dec 10)
- Re: Subverting eTrust Access Control on UNIX (file execution) arvind doraiswamy (Dec 10)
- Re: Subverting eTrust Access Control on UNIX (file execution) Tim Brown (Dec 08)