In today's article I will talk about the vulnerabilities of the 1C server in the corporate network.

As practice has shown, in installations with 1C all make the same mistakes of different degrees of seriousness. I will not touch on obvious things like installing updates, but I’ll go over the specifics of the application server running under Windows. For example, whenever possible uncontrolledly manipulate Microsoft SQL databases using 1C tools.

Historically, it’s rare that system administrators and 1C programmers work as one team. Most often, 1C specialists do not delve into the subtleties of system administration, and system administrators do not seek to grasp the nuances of 1C work.

And it turns out the infrastructure with "childish sores", obvious to the information security specialist - below I bring personal TOP of such problems.

We start the server correctly

By default, the 1C platform, during installation, creates a special account with limited rights, under which the server services are running - USR1CV8. Everything is going well, until network resources become necessary: ​​for example, for automatic uploads-downloads. The default account does not have access to domain network folders, since it is local.

In my practice, I have encountered many ways to solve this task: folders with write access for the Everyone group, 1C server under an account with domain administrator rights, explicit credentials for connecting to a network resource in the code. Even the launch of 1C server under a user session as a normal application.

We go to the server via RDP, we see such a window and we get a nervous tic.

Of course, “zahardkozhennye” passwords and network resources with anonymous write access are rare. In contrast to the operation of the server 1C from under a normal domain account. Of course, with the ability to execute arbitrary code "on the server."

As is known to any 1C-nick, but not to any system administrator, in 1C processing there are two modes of performing procedures: on the server and on the client. The procedure launched in the “server” mode will be executed under the application server service account. With all her rights.

If the server 1C works with domain administrator rights, then the potential pest can do anything with the domain. A reasonable solution would be to create a special account - based on USR1CV8 , only in the domain. In particular, she should allow access only to certain servers in the Active Directory Users and Computers snap-in.

Configure logging in to authorized servers only.

It would not be superfluous to allow access to the server only as a service, disabling the possibility of local (interactive) login. This can be done through local security policies directly on the server, or by using domain-based group policies.

Assign user rights in local security policy.

The same goes for the Microsoft SQL Server account. Gray hair can be added from bad habits:

• run SQL as a computer or even a domain administrator for easy backup;
• include the ability to run executable commands through the xp_cmdshell stored procedure to transfer backups to network resources through beautiful maintenance plans.

Connect to SQL

Regularly in practice there is a database connection to the 1C server under the user “SA” (superuser in SQL). In general, this is not as scary as it sounds, because the password from SA is cached in the 1CV8Reg.lst file on the application server. An attacker’s hash can get hypothetically - do not forget about server account rights - but decryption will be long, especially if you use brute force.

But still it will not be superfluous to set up an audit of access to this file with notification of the responsible persons.

Another thing is when 1C programmers are “delegated” DBA responsibilities. Again, from personal experience: the SQL server was the responsibility of programmers, as was the integration of an external site with 1C databases. The result was the SA password in the site scripts.

For your own reassurance, it is worthwhile to put a complex password on SA or deactivate this account altogether. On SQL, then you need to enable domain authentication for management and create a separate login for 1C with the rights to the necessary databases.

If you do not want to leave the ability to create SQL databases through the 1C interface, then the new user will have the general role public and db_owner directly in the 1C database.

This can be done through Management Studio or a simple T-SQL script:

USE <databasename> CREATE LOGIN 1c_user WITH PASSWORD = 'VeryStrongPassword' CREATE USER 1c_user FOR LOGIN 1c_user ALTER ROLE db_owner ADD MEMBER 1c_user GO 

1C users

For some reason, few people pay attention to the rights of users in 1C. But a user with the rights “Administrative functions” or “Administration” will easily unload the database into .DT through the configurator and take it home - this will bring more than one moment of an exciting happiness to your management. Therefore, it is worth catching a 1C-nick on a glass of tea and sitting together above the base to find out which users have such rights. But at the same time - what threatens the reduction of their powers.

The right to unload the base in the role of Full Rights in a typical 1C: Accounting 2.0.

The next important point is the launch of external processing. As we remember, in 1C, you can run the code with the rights of the server account. It’s good if it doesn’t have administrative rights to the system, but you still have to exclude the possibility of running such processing for users. And do not forget to ask the 1C specialist to “embed” additional reports and processing into the database. Although not all processing supports embedding - this feature depends on version 1C.

You can check which typical roles do not have rights to open external processing in the configurator.

All these actions will not only help protect against a potential "internal pest", but will also become an additional obstacle to encryption viruses masquerading as 1C treatments.

If you still need to start external processing, then a good option for control and safety will be an audit of their launch. A staff audit mechanism for 1C is not available, but the community has already come up with several workarounds . Implementing these mechanisms is paired with the 1C specialist, as well as setting up notifications about events in the database registration log.

Separately, I note the ability to configure domain user authentication instead of 1C authentication. And it will be more convenient for users - fewer passwords in their memory reduces the risk of stickers appearing on the monitor.

Cluster Administrator

So, users can no longer start processing, the server account is maximally limited. But there is one more thing: the 1C cluster administrator account, which is not created by default.

Its absence is dangerous: any person with a laptop with open access to the network ports of the server (by default it is TCP: 1540) can create its own base there, and there will be no restrictions on starting processing. And the villain will be able to get information on databases, on working users, change cluster settings and even forcefully shut down certain users.

An example of a PowerShell script that expels all users from all server databases:

 $COMConnector = New-Object -ComObject V83.COMConnector $agent = $COMConnector.ConnectAgent("servername") $cluster = $agent.GetClusters()[0] $agent.Authenticate($cluster,"", "") $sessions = $agent.GetSessions($cluster) Foreach ($session in $sessions) { $agent.TerminateSession($cluster, $session) } 

Using a similar method of working with the 1C server for good purposes has already been mentioned in a previous article .

Creating a cluster administrator is not easy, but very simple - just right-click on the “administrators” item in the 1C cluster management, create a new administrator by setting a login and password.

Creating a cluster administrator 1C.

I touched only a part of the flaws in setting up 1C: Enterprise. For self-study, I recommend reading the materials that have not lost their relevance:

• an information document on the ITS website;
• article on security 1C: Enterprise 8.0 in the community mista.ru.

Share in the comments your non-standard solutions and curiosities when working with the 1C: Enterprise system.