Bypass of access control rules in means of protection against unauthorized access

There is a whole class of products on the Russian information security market designed to meet the requirements of regulators (FSTEC, FSB, Roskomnadzor and others). These products are called "SZI from NSD", which means - means of protecting information from unauthorized access. The main functions of such products are the implementation, regardless of the operating system, of user authentication, rules for restricting access to files and directories (discretionarily - as in operating systems, and mandated - for state secrets where there are different levels of information), integrity control, device connection management and all sorts of other functions. About similar products on Habré there is a short articleTrue, she is already more than five years old, but on the whole little has changed. All these products, for the most part, are needed for compliance in its purest form, but, nevertheless, with the help of these tools, most security policies are implemented in government agencies, state-owned companies, the defense industry, etc.

It is logical to assume that these products are safe and correctly perform their functions, but I found out that this is not so. In this article, we will consider only the SZI from NSD for the Windows operating system, since despite the trend of import substitution, most state computers still work under it. Windows has many features and subtleties that can play a trick on security developers. We will not talk about all the nuances now, we will analyze only one that allows you to bypass the policy of restricting access to files.

It's no secret that the main file system used on Windows is NTFS. NTFS has such a thing as attributes, which can be accessed by adding a double colon after the file name. Files have many attributes, but we are interested in one - $ DATA, it contains the contents of the file. The appeal to file.txt and file.txt :: $ DATA is identical, but the mechanism of work inside the operating system is different. I decided to see if the developers of SZI are aware of this feature. The practical part is simple - a test.txt file was created with the content “Hello, world!”, Permissions were forbidden to read the file for all users in the SZI interface, then the file was read by the name and attribute $ DATA, under an unprivileged user.

I wanted to look at the maximum possible number of SZI, but it turned out that you can only get a demo version for two products - Dallas Lock and Secret Net. There is still Aura in the public domain, but it has not been updated since 2011 and it is unlikely that anyone else is using it. It was not possible to get all the others (Sentinel, Blockhost, Diamond) in the demo - they are not in the public domain, the manufacturer either does not respond to requests, either requires letters of guarantee, or instead of the demo version they offer to listen to the webinar.

Dallas lock


Set permissions:



Check:



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

Vulnerable version:



Secret net


Set permissions:



Check:



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

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



I will be glad if you test the available SZI and publish the result in the comments. And be careful with “certified security features”; don’t blindly trust certificates and licenses.

Also popular now: