Bypassing the rules of access control in the means of protection from unauthorized access

In the Russian information security market, there is a whole class of products designed to meet the requirements of regulators (FSTEC, FSB, Roskomnadzor and others). These products are called “SZI from unauthorized access”, which means - means of protecting information from unauthorized access. The main functions of such products are implementation, regardless of the operating system, user authentication, rules for delimiting access to files and directories (discretionarily, as in operating systems, and mandatory for state secrets, where there are different levels of information), integrity monitoring, device connection management, and any other functions. There is a short article about similar products on Habré, although it’s already more than five years old, but in general, little has changed. All these products, for the most part, are needed for the compliance in a pure form, but, nevertheless, with the help of these means most security policies are implemented in state bodies, state-owned companies, defense, etc.



It is logical to assume that these products are safe and properly perform their functions, but I found out that this is not the case. In this article, we will consider only DSS from unauthorized access control for the Windows operating system, since, despite the import substitution trend, most state-owned computers still work under it. In Windows, there are many features and subtleties that can play a cruel joke with the developers of remedies. We are not going to talk about all the nuances right now; let’s analyze only one that allows you to bypass the policy of delimiting access to files.



It's no secret that the main file system used in Windows is NTFS. In NTFS there is such a thing as attributes, access to which can be obtained by adding a double colon after the file name. There are many attributes of files, but one of us is interested in $ DATA, it contains the contents of the file. Appeal to file.txt and file.txt :: $ DATA is identical, but the mechanism of operation within the operating system is different. I decided to see if GIS developers know about this feature. The practical part is simple - the test.txt file was created with the contents of “Hello, world!”, In the GIS interface, access rights were set that prohibit reading of the file for all users, then the file was read by its name and $ DATA attribute, under an unprivileged user.



I wanted to look at the maximum possible number of SZI, but it turned out that only demo version is available for two products - Dallas Lock and Secret Net. There is open access to Aura, but it has not been updated since 2011, and it is unlikely that anyone else is using it. All the rest (Sentinel, Blokhost, Diamond) could not be obtained in the demo - they are not publicly available, the manufacturer either does not respond to requests, either requires warranty letters, or instead of the demo version they offer to listen to the webinar.

')

Dallas lock

Set permissions:







Checking:







And here it is - any user can read the contents of any file, completely ignoring all configured access restriction rules.



Vulnerable version:

Secret net

Set permissions:







Checking:







In Secret Net, this focus does not work, it seems that their developers understand NTFS (although they do not really understand the security of drivers ).



Checked on this version, perhaps the earlier ones are still vulnerable:







I will be glad if you test the GIS available to you and post the result in the comments. And be careful with "certified security tools", do not blindly trust certificates and licenses.