Domain User to Domain Admin
Knowing the difference between user authentication and authorization when designing secure software can be extremely important to avoid common security pitfalls. Often times application software vendors subvert the overall security imposed by the operating system and domain by not properly authenticating or checking the authorization of a user within the environment. During a recent penetration test we came across BMC’s Patrol Agent software installed across the customer’s environment. This software was being used to perform remote administration tasks on system endpoints.
Being unfamiliar with the software we decided to investigate the underlying authentication mechanisms in the client software. Each node was running the Patrol Agent software which was listening on port 3181 and running as a service with SYSTEM privilege.
While reviewing the Patrol logs we noticed something that caught our eye
PatrolCli “user [username]” “connect [IP Address] 3181” “execpsl \”system(\\\”[command to run]\\\”);\””
Patrol Agent provides a handy utility called PatrolCli for performing administrative tasks through the Patrol agent client software. The log entry got my attention because it looked like the application may be authenticating prior to connecting to a remote host to run commands. If this was the case then having rights on the local computer may give you rights to run commands on any computer that is running PatrolAgent. To verify, we opened the binary up in IDA Pro.
As you can see in the picture, the application uses LogonUserA to authenticate the user with the given password. Looking at the documentation for LogonUser we see it is meant for authenticating the user to the local computer. A more detailed article goes on to describe the API and also gives a bit of a warning when using it.
Note Collecting user credentials from a User-mode application can be annoying to the users and can provide a possible security hole in the enterprise computing environment.
Now with a little more confidence behind our theory, we decided to try and login to the PatrolCli using credentials for a regular, unprivileged domain user.
After verifying that we could use patrolcli to connect to any other patrol agent client using a regular domain user, we pointed it to the domain controller and were able to successfully execute commands as SYSTEM on the DC.
Given the severity of the finding we decided to reach out to the vendor. They informed us that there is a configuration change that can be made to the pconfig variable for each Patrol Agent instance that enforces an ACL for which users can connect to the client interface. i.e.
Restricted mode. Only users from Administrators group can connect and perform operations (“/AgentSetup/accessControlList” = “:Administrators/*/CDOPSR”):
*However, the default configuration has no ACLs set.
Given the response from the vendor, and the fact that a whole feature set was created around this faulty design (ACLs), I don’t believe this issue is going to be resolved.
**Update – the vendor reached out and provided an additional mitigation that they plan to enable by default in future versions. Unfortunately, we were unable to confirm either of these mitigations as there is no available trial version of the software.
A specific PATROL Agent configuration parameter (/AgentSetup/pemCommands_policy = “U” ) can be enabled that ensures the PATROL Agent executes the command with (or using) the PATROL CLI connected user.
This issue was reported to Mitre and is being tracked as CVE-2018-20735