Potential False Pos

General support questions for the Secutor Prime product.
jfvanmeter
Contributor
Posts: 5
Joined: Fri May 11, 2007 3:14 am

Potential False Pos

Postby jfvanmeter » Fri May 11, 2007 4:50 am

Hello every, I have a problem were the file permission are failing a scan. Below is the information I have and any feedback will help.

Secutor Prime version: 1.1.0

SCAP content version and target OS SCAP-Win2003-MS-XCCDF-Beta-v2.xml - Windows 2003 R2 x64 Enterprise edition Service Pack 2

Platform being run on Windows 2003 R2 x64 Enterprise edition Service Pack 2

which test(s) has the problem
NIST SP 800-53 Controls - Applicable 800-53 Access Control Checks
Access Enforcement - All of the File Permissions Checks

Example Telnet.exe ACL is Administrators - Full and System - Full


What each reports and what it should report
For a example
(red X) Telnet.exe Permissions failed
Details - Failure to properly configure ACL file and directory permissions, allows the possibility of unauthorized and anonymous modification
to the operating system and installed applications.

Findings - Empty

Reference
CCE,CCE-Winv2.0-122
NSA na
DISA Gold Disk ID 1130
oval:gov.nist.2:def:157
PDI 2.006
CCE-Winv2.0-122
800-68 Section 6.6 - Table A-9.30
DISA STIG Section 5.4.10.1 - Table A.1 Row 31

OVAL Notes
==================================================================================

oval:gov.nist.2:def:157 (compliance)
Administrators and System User Have Full Access to the SYSTEMROOT/system32/telnet.exe file
Product: Windows Server 2003, SP2, 32 bit
Risk: 0.0


---> Result: fail <---

*** BEGIN **************************************************************************

oval:gov.nist.2:tst:6 [true] (the installed operating system is part of the Microsoft Windows family)
*** AND ***
oval:gov.nist.2:tst:7 [true] (Windows Server 2003 is installed)
--> [true]

---> TRUE <---
*** AND **************************************************************************

oval:gov.nist.2:tst:281 [false] (The Administrators group is granted full access to the file telnet.exe)
*** AND ***
oval:gov.nist.2:tst:282 [false] (The System user is granted full access to the file telnet.exe)
*** AND ***
oval:gov.nist.2:tst:283 [true] (There are no access privileges to file telnet.exe by users not part of the Administrators group or the System user)
--> [false]

---> FALSE <---
*** END **************************************************************************
oval:gov.nist.2:tst:6 -- the installed operating system is part of the Microsoft Windows family
Windows is windows
--> Result: TRUE


oval:gov.nist.2:tst:7 -- Windows Server 2003is installed
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\CurrentVersion
5.2 equals 5.2


oval:gov.nist.2:tst:281 -- The Administrators group is granted full access to the file telnet.exe
C$\WINNT\\system32::equals::telnet.exe::equals::Administrators: File does not exist.
--> Result: FALSE


oval:gov.nist.2:tst:282 -- The System user is granted full access to the file telnet.exe
C$\WINNT\\system32::equals::telnet.exe::equals::SYSTEM: File does not exist.


oval:gov.nist.2:tst:283 -- There are no access privileges to file telnet.exe by users not part of the Administrators group or the System user
C$\WINNT\\system32\equals -- File does not exist.


==================================================================================


Also in the In the OVAL Notes the Product: Windows Server 2003, SP2, 32 bit report, the server that was scanned is 64 bit

Thank You in advanced
Take Care and Have Fun --John

jfvanmeter
Contributor
Posts: 5
Joined: Fri May 11, 2007 3:14 am

Re: Potential False Pos

Postby jfvanmeter » Fri May 11, 2007 8:21 am

I have a update that I would like to add.... the server I scanned is in a workgroup, and a security policy is applied via secedit and various inf files.

If you look at the line from the template you can see that it only contains the default administrators group and system
"%SystemRoot%\system32\telnet.exe",2,"D:PAR(A;OICI;FA;;;BA)(A;OICI;FA;;;SY)"
If you look at the ACL on the file, you see System = Full but for the administrators group you see mycomputername\administrators.

My thought is that threatguards is looking for administrators, and but recieves mycomputername\administrators and fails the check because there not the same.

Does threatguard check for the sid SID: S-1-5-32-544 to id a user name or group? or does it look for the display name?

http://support.microsoft.com/kb/243330

[quote="jfvanmeter"]Hello every, I have a problem were the file permission are failing a scan. Below is the information I have and any feedback will help.

Secutor Prime version: 1.1.0

SCAP content version and target OS SCAP-Win2003-MS-XCCDF-Beta-v2.xml - Windows 2003 R2 x64 Enterprise edition Service Pack 2

Platform being run on Windows 2003 R2 x64 Enterprise edition Service Pack 2

which test(s) has the problem
NIST SP 800-53 Controls - Applicable 800-53 Access Control Checks
Access Enforcement - All of the File Permissions Checks

Example Telnet.exe ACL is Administrators - Full and System - Full


What each reports and what it should report
For a example
(red X) Telnet.exe Permissions failed
Details - Failure to properly configure ACL file and directory permissions, allows the possibility of unauthorized and anonymous modification
to the operating system and installed applications.

Findings - Empty

Reference
CCE,CCE-Winv2.0-122
NSA na
DISA Gold Disk ID 1130
oval:gov.nist.2:def:157
PDI 2.006
CCE-Winv2.0-122
800-68 Section 6.6 - Table A-9.30
DISA STIG Section 5.4.10.1 - Table A.1 Row 31

OVAL Notes
==================================================================================

oval:gov.nist.2:def:157 (compliance)
Administrators and System User Have Full Access to the SYSTEMROOT/system32/telnet.exe file
Product: Windows Server 2003, SP2, 32 bit
Risk: 0.0


---> Result: fail <---

*** BEGIN **************************************************************************

oval:gov.nist.2:tst:6 [true] (the installed operating system is part of the Microsoft Windows family)
*** AND ***
oval:gov.nist.2:tst:7 [true] (Windows Server 2003 is installed)
--> [true]

---> TRUE <---
*** AND **************************************************************************

oval:gov.nist.2:tst:281 [false] (The Administrators group is granted full access to the file telnet.exe)
*** AND ***
oval:gov.nist.2:tst:282 [false] (The System user is granted full access to the file telnet.exe)
*** AND ***
oval:gov.nist.2:tst:283 [true] (There are no access privileges to file telnet.exe by users not part of the Administrators group or the System user)
--> [false]

---> FALSE <---
*** END **************************************************************************
oval:gov.nist.2:tst:6 -- the installed operating system is part of the Microsoft Windows family
Windows is windows
--> Result: TRUE


oval:gov.nist.2:tst:7 -- Windows Server 2003is installed
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\CurrentVersion
5.2 equals 5.2


oval:gov.nist.2:tst:281 -- The Administrators group is granted full access to the file telnet.exe
C$\WINNT\\system32::equals::telnet.exe::equals::Administrators: File does not exist.
--> Result: FALSE


oval:gov.nist.2:tst:282 -- The System user is granted full access to the file telnet.exe
C$\WINNT\\system32::equals::telnet.exe::equals::SYSTEM: File does not exist.


oval:gov.nist.2:tst:283 -- There are no access privileges to file telnet.exe by users not part of the Administrators group or the System user
C$\WINNT\\system32\equals -- File does not exist.


==================================================================================


Also in the In the OVAL Notes the Product: Windows Server 2003, SP2, 32 bit report, the server that was scanned is 64 bit

Thank You in advanced
Take Care and Have Fun --John[/quote]

robert.hollis
SME
Posts: 24
Joined: Wed Mar 07, 2007 12:32 pm

Re: administrative accounts

Postby robert.hollis » Fri May 11, 2007 8:39 am

Hi John,

Has telnet.exe been moved or removed from the system?

-rob

jfvanmeter
Contributor
Posts: 5
Joined: Fri May 11, 2007 3:14 am

Re: administrative accounts

Postby jfvanmeter » Fri May 11, 2007 10:20 am

No the binaries for telnet.exe have never been mored or removed, the telnet service is not installed. Telnet was only one example of a failure. All of the file perm checks failed

[quote="robert.hollis"]Hi John,

Has telnet.exe been moved or removed from the system?

-rob[/quote]

robert.hollis
SME
Posts: 24
Joined: Wed Mar 07, 2007 12:32 pm

Re: telnet only an example

Postby robert.hollis » Fri May 11, 2007 11:27 am

telnet was just an example


True, but it's likely an example of a much larger issue. I will post a follow-up courtesy message to further explain the question. For now, I've poked through the content and found the following snippet that is used for every file permission check:

<local_variable id="oval:gov.nist.2:var:1"comment="Windows system32 directory">
<concat>
<object_component object_ref="oval:gov.nist.2:obj:79"/>
<literal_component>\system32</literal_component>
</concat>
</local_variable>

The thing to notice is the hardcoded reference to "system32" which is not valid on your 64-bit system. There are two possible remedies (actions for the content developer):

1) rewrite this variable component to use SysWOW64 on 64-bit machines, or
2) alter the CPE tag in the XCCDF file to speficy 32-bit S03 only. Common Platform Enumeration (cpe) is very new to SCAP (and still a bit in a state of flux). When in full use, it will enable tools like Secutor Prime to dismiss a benchmark as not applicable before attempting an assessment.

Either way, there's a content issue here to resolve. Thank you for surfacing it. We'll let NIST and the ISAP community know.

-rob

robert.hollis
SME
Posts: 24
Joined: Wed Mar 07, 2007 12:32 pm

Why the question about the file being removed?

Postby robert.hollis » Fri May 11, 2007 11:36 am

John,


This thread has surfaced another issue that may not have been recognized by content developers. So far, all of the content I've seen for Windows file permission checks assumes the file is in it's standard location. If it has been moved or removed, the logic of the tests are triggered to fail.

I don't believe this was intentional. To stay at the top of the weeds... the content asks

does <account> have <permission> on <file>

This is like asking

does CHARLIE have MUD on his HUMMER? (yes or no)

If Charlie does not have a Hummer, the answer is no... FAIL.

So, instead we should ask "does Charlie have a Hummer, AND is there mud on it."
That's when the violation should be flagged.

This is something we will start to work with NIST to resolve in the content across the board. Again, this is not what you're running into, however figured I should provide an explanation behind the question. You've surfaced a very good issue. Thank you for your time and support!

-rob

jfvanmeter
Contributor
Posts: 5
Joined: Fri May 11, 2007 3:14 am

Re: telnet only an example

Postby jfvanmeter » Tue May 15, 2007 3:18 am

[quote="robert.hollis"][quote]telnet was just an example[/quote]

True, but it's likely an example of a much larger issue. I will post a follow-up courtesy message to further explain the question. For now, I've poked through the content and found the following snippet that is used for every file permission check:

<local_variable id="oval:gov.nist.2:var:1"comment="Windows system32 directory">
<concat>
<object_component object_ref="oval:gov.nist.2:obj:79"/>
<literal_component>\system32</literal_component>
</concat>
</local_variable>

The thing to notice is the hardcoded reference to "system32" which is not valid on your 64-bit system. There are two possible remedies (actions for the content developer):

1) rewrite this variable component to use SysWOW64 on 64-bit machines, or
2) alter the CPE tag in the XCCDF file to speficy 32-bit S03 only. [url=http://cpe.mitre.org]Common Platform Enumeration (cpe)[/url] is [b]very[/b] new to SCAP (and still a bit in a state of flux). When in full use, it will enable tools like Secutor Prime to dismiss a benchmark as not applicable before attempting an assessment.

Either way, there's a content issue here to resolve. Thank you for surfacing it. We'll let NIST and the ISAP community know.

-rob[/quote]

I just wanted to pass along that I verified that telnet.exe is located in the following path c:\winnt\system32\telnet.exe

Hope this helps --John

gunnar
Site Admin
Posts: 81
Joined: Fri Feb 23, 2007 8:08 pm
Contact:

Re: telnet only an example

Postby gunnar » Tue May 15, 2007 8:00 am

jfvanmeter wrote:
robert.hollis wrote:
telnet was just an example


True, but it's likely an example of a much larger issue. I will post a follow-up courtesy message to further explain the question. For now, I've poked through the content and found the following snippet that is used for every file permission check:

<local_variable id="oval:gov.nist.2:var:1"comment="Windows system32 directory">
<concat>
<object_component object_ref="oval:gov.nist.2:obj:79"/>
<literal_component>\system32</literal_component>
</concat>
</local_variable>

The thing to notice is the hardcoded reference to "system32" which is not valid on your 64-bit system. There are two possible remedies (actions for the content developer):

1) rewrite this variable component to use SysWOW64 on 64-bit machines, or
2) alter the CPE tag in the XCCDF file to speficy 32-bit S03 only. Common Platform Enumeration (cpe) is very new to SCAP (and still a bit in a state of flux). When in full use, it will enable tools like Secutor Prime to dismiss a benchmark as not applicable before attempting an assessment.

Either way, there's a content issue here to resolve. Thank you for surfacing it. We'll let NIST and the ISAP community know.

-rob


I just wanted to pass along that I verified that telnet.exe is located in the following path c:\winnt\system32\telnet.exe

Hope this helps --John



What you are seeing is correct when running from the console. However, Secutor Prime is a 32-bit application, so it runs inside the WOW64 emulator, which remaps the system32 directory and replaces it with the contents of the sysWOW64 directory. Therefore a 32-bit application cannot access the contents you are seeing in the system32 directory -- only a 64-bit application to do that.

We will, of course, be releasing 64-bit versions of all of our software for just this reason and doing what we can to help the community create 64-bit versions of all of the security content.

jfvanmeter
Contributor
Posts: 5
Joined: Fri May 11, 2007 3:14 am

Re: telnet only an example

Postby jfvanmeter » Wed May 16, 2007 2:58 am

[quote="jfvanmeter"][quote="gunnar"][quote="jfvanmeter"][quote="robert.hollis"][quote]telnet was just an example[/quote]

True, but it's likely an example of a much larger issue. I will post a follow-up courtesy message to further explain the question. For now, I've poked through the content and found the following snippet that is used for every file permission check:

<local_variable id="oval:gov.nist.2:var:1"comment="Windows system32 directory">
<concat>
<object_component object_ref="oval:gov.nist.2:obj:79"/>
<literal_component>\system32</literal_component>
</concat>
</local_variable>

The thing to notice is the hardcoded reference to "system32" which is not valid on your 64-bit system. There are two possible remedies (actions for the content developer):

Thats right, thank you --John

1) rewrite this variable component to use SysWOW64 on 64-bit machines, or
2) alter the CPE tag in the XCCDF file to speficy 32-bit S03 only. [url=http://cpe.mitre.org]Common Platform Enumeration (cpe)[/url] is [b]very[/b] new to SCAP (and still a bit in a state of flux). When in full use, it will enable tools like Secutor Prime to dismiss a benchmark as not applicable before attempting an assessment.

Either way, there's a content issue here to resolve. Thank you for surfacing it. We'll let NIST and the ISAP community know.

-rob[/quote]

I just wanted to pass along that I verified that telnet.exe is located in the following path c:\winnt\system32\telnet.exe

Hope this helps --John[/quote]


What you are seeing is correct when running from the console. However, Secutor Prime is a 32-bit application, so it runs inside the WOW64 emulator, which remaps the system32 directory and replaces it with the contents of the sysWOW64 directory. Therefore a 32-bit application cannot access the contents you are seeing in the system32 directory -- only a 64-bit application to do that.

We will, of course, be releasing 64-bit versions of all of our software for just this reason and doing what we can to help the community create 64-bit versions of all of the security content.[/quote][/quote]

Thanks Rob,
reviewing that scan report in greater detail, the whole report seams off, and since it is not just the system32 directory that gets remapped. but whole parts of the registry and other system folders as well; I don't believe the scan is vailid. I should have know this would be a issue, Shame on me for not catching this earlier.

How do I get my 32-bit application to use the file systems folders reserved for 64-bit applications?

The file system redirection is turned on by default. The file system redirection must be turned on to redirect 32-bit system calls to C:\Windows\SysWow64. This can be accomplished by using the WoW64EnableWoW64FSRedirection() function. . When the WoW64EnableWoW64FSRedirection() function is turned off the 32-bit application will use the system files in the 64-bit file system folder, C:\Windows\System32.

Note Unless you're certain your 32-bit application will run without redirection, leave the file system redirection activated.

How do I make my 32-bit application aware of itself running on a 64-bit architecture?

When a 32-bit application executes inside WoW64, the application is unaware that it is running on 64-bit architecture. If your application requires underlying knowledge of the architecture the call to GetNativeSystemInfo() can be used to return the processor architecture.

To disable and enable registry reflection for a particular key, use the RegDisableReflectionKey andRegEnableReflectionKeyfunctions. To determine the reflection state of a key, use theRegQueryReflectionKey function.

I hope some of the above info helps

Best Regards --John

gunnar
Site Admin
Posts: 81
Joined: Fri Feb 23, 2007 8:08 pm
Contact:

RESOLUTION

Postby gunnar » Fri Feb 11, 2011 9:13 pm

For those browsing this topic looking for an answer to the same question, Secutor Prime has been re-engineered to be capable of running an assessment against either the 32-bit or 64-bit subsystems of Windows operating systems without requiring any changes to the current benchmarks and regardless of whether Prime is being run as a 32- or 64-bit application.

For this reason we now only release Prime as a 32-bit application.

At the start of an assessment, Prime will detect if the target system is just 32-bit or has both. If the latter, it will prompt at the start of the assessment which subsystem you wish to target. Most importantly, this also applies to remote systems for licensed users of Prime Pro/Auditor, regardless of whether or not the local machine running Prime is 64-bit.

As a convenience, you can also set Prime to skip this prompt and always run in one mode or the other.


Return to “Secutor Prime Support”

Who is online

Users browsing this forum: No registered users and 3 guests