chown.htm: Who owns your files?

	Who owns your files? Security thorough obscurity	Fravia's Anonymity Academy
21 Jul 1999	by [blue]
	Courtesy of Fravia's page of reverse engineering
fra_00xx 982207 [blue] 0100 CO PC	NAME chown - change owner SYNOPSIS /usr/ucb/chown [ -fR ] owner[.group] filename ... DESCRIPTION chown changes the owner of the filenames to owner. The owner may be either a decimal user ID (UID ) or a login name found in the password file. An optional group may also be specified. The group may be either a decimal group ID (GID ) or a group name found in the GID file. Only the super-user can change owner, in order to simplify accounting procedures. OPTIONS -f Do not report errors. -R Recursively descend into directories setting the ownership of all files in each directory encountered. When symbolic links are encountered, their ownership is changed, but they are not traversed. So far so good... now read this beautiful essay by [blue] and then download this file chown.zip... and up you go, you superuser you... :-)
	There is a crack, a crack in everything That's how the light gets in
Rating	( )Beginner (x)Intermediate ( )Advanced ( )Expert

Yet another example of Micro$oft dirty tricks: security thorough obscurity.

Who owns your files?
Security thorough obscurity
Written by [blue]

Introduction

The trick: made them think they are secure. Keep repeating this.

Tools required

None really. Win32 development tools if you want to implement ideas from this essay.

You should know about Windows NT administration, Windows NT security model, ACL, ACE, Win32 programming (sorry... no assembly required :-)

A good book on NT administration is Windows NT 4 Server Unleashed by Jason Garms (you can find it on the Web).

Target's URL/FTP

www.microsoft.com/ntserver

Program History

Too long to put here...

Essay

Since the first multi-user operating system arise the necessity for controlling the access to resources. This leads to another problem: the system administrator needs a lot of rights to perform his daily duties (for example to do backups), but how we can protect some files from being accessed by sysadm? A company can have a lot of sensitive information: payroll lists, customers lists, etc. How can we protect this kind of files from being accessed by sysadm without anyone noticing?

In UNIX it's just not possible. The root account is omnipotent. When NT appears it claims it solved this problem. Please read the following statements carefully.

An owner cannot change the ownership of a resource they own. The owner can only give another user or group permission to take ownership of a resource. Security of resource is thus maintained by preventing users from creating or editing files and then making them look as if they belonged to someone else.

For example, if a user assign the No access permission to a file, a member of the Administrators group can still take ownership of the file and make changes to it. The user, by checking the ownership of the file, would see that the administrator owned the file, and had disregarded the No Access permission on the file.

Microsoft Education and Certification - Administering Microsoft Windows NT 4.0, page 133

Good, very good.

If an administrator wants to access a file that he or she is not granted access to, the administrator must first take ownership of that file. Once ownership is taken, the administrator will have full access to the file. It is important to note that administrator cannot give ownership back to the original owner. If this were so, the administrator could take ownership of a file, examine it, and then assign it back to the original owner without that owner's knowledge.

NOTE: Because administrators have backup privileges, an administrator could back up a file (or entire volume) and restore it onto another system. The administrator could then take ownership of a file on this new system, examine it, and then restore from backup with original permissions, without the owner's knowledge. Please keep this in mind when thinking about file security.

Knowledge Base Article Q102099 - Administrator Access to Files

Friendly warning.

The key distinction between C-level and B-level security is in the notion of access control. In a C2 (DAC) system, owners have absolute discretion about whether or not others have access to their objects.

Knowledge Base Article Q93362 - C2 Evaluation and Certification for Windows NT

Looks ok. The owner of a file should deny sysadm any access to file and that's it. The only thing sysadm can do it's to take ownership of the file and then give himself necessary rights, but this cannot go unnoticed: user can see the change of the file owner. Many people believe in those statements, and they give a feeling of security that administrators cannot view users' files if the permissions are set properly. However, it is simply not correct.

There are two possibilities to change the owner of a file using Micro$oft tools.

Services for Macintosh:

Changing ownership changes the ACL. When you use the MacFile permission option to change the owner of a file, the old owner will be removed from the folder's access control list (ACL)-and likewise from all files within the folder. For example, if JGARMS is the owner and I change the owner to JSMITH, not only will the NTFS owner change to JSMITH, but JGARMS will be completely removed from the NTFS ACL.
The AFP permissions keep placeholder entries for the primary group and Everyone. If you use the MacFile Permissions option to remove all three AFP permissions from the primary group or the Everyone group, they still retain placeholder access control entries (ACEs) in the NTFS access control list.
For instance, if you remove all the AFP permissions from the owner, the primary group, and Everyone, the resulting NTFS permissions on the folder will list the owner with special access (PO), and will list the primary group and Everyone with special access (), which is essentially no specified access.
You can set the owner of the folder to a group-it does not have to be an individual user's account. This is in sharp contrast to the normal operations of Windows NT, where the Administrators group is normally the only group that can own files.
Windows NT 4 Server Unleashed, Chapter 10, Jason Garms

I take a look in Services for Macintosh documentation (including Microsoft Official Curriculum materials): there is no mention of first side effect: changing Macintosh owner also changes NTFS owner. Of course you can figure it out but after all that noise about "no possibility to SET owner" they don't give even a fine print warning. As you can see you have to dig, to search books to find what beast did you installed on your server.

POSIX Chown utility from Resource kit.

This is a different beast: it does not run in Win32 subsystem. POSIX subsystem like Services for Macintosh has it's own rules.

How about writing normal Win32 program to change the owner of a file? It's also possible (I'll give you a hint shortly). With administrative privileges (Backup, Restore and Take Ownership) it is always possible to change the owner of a file (without destroying the Access Control List!), even if administrators have explicit No Access to the file.

Win32 Security API

The key function is SetFileSecurity:

The SetFileSecurity function sets the security of a file or directory object.

BOOL SetFileSecurity(
  LPCTSTR lpFileName, // address of string for filename
  SECURITY_INFORMATION SecurityInformation, // type of information to set
  PSECURITY_DESCRIPTOR pSecurityDescriptor // address of security descriptor
);

Parameters

lpFileName: Points to a null-terminated string specifying the file or directory for which security is set.
SecurityInformation: Specifies a SECURITY_INFORMATION structure identifying the contents of the security descriptor pointed to by the pSecurityDescriptor parameter.
pSecurityDescriptor: Points to a SECURITY_DESCRIPTOR structure.

Return Value

If the function succeeds, the return value is TRUE.

If the function fails, the return value is FALSE. To get extended error information, call GetLastError.

Remarks

The SetFileSecurity function is successful only if the following conditions are met:

If the object's owner is being set, the calling process must have either WRITE_OWNER permission or be the object's owner.
If the object's discretionary access-control list (ACL) is being set, the calling process must have either WRITE_DAC permission or be the object's owner.
If the object's system ACL is being set, the SE_SECURITY_NAME privilege must be enabled for the calling process.

Things are clear now: we have to construct a valid security descriptor and apply it to file we want to modify.

The details are left to the reader :-).

Few starting points:

The SIDCLEAN example
The Web: there are at least two programs available with source code

Final Notes

Giving this we should question every Micro$oft affirmation. If they say we can't probably we can.

Ob Duh

I wont even bother explaining you that you should BUY this target program if you intend to use it for a longer period than the allowed one. Should you want to STEAL this software instead, you don't need to crack its protection scheme at all: you'll find it on most Warez sites, complete and already regged, farewell, don't come back.

You are deep inside Fravia's page of reverse engineering, choose your way out:

Back to corporate survival

red

links

+ORC

bots wars

tools

mail_Fravia

Is reverse engineering illegal?