As a penetration testers, we rarely have to find ‘zero day’ vulnerabilities or perform ‘bug hunting’ in order to compromise Windows Active Directory Domains. However, in one of these rare cases while performing an internal penetration test for a client, we had to do so. Lansweeper is an inventory software that scans your network in order to gather system information such as patch level, network interfaces, resources status, etc. We were fairly surprised during this test when we were able to access Lansweeper 5’s dashboard with a regular user account. Our customer was actually shocked and swore that he had configured only Domain Admin access on this Web interface. According to him, a recent update must have reset the login permission on the dashboard. At first, we were doubtful that explanation would hold up to scrutiny. Our curiosity increased when we realized that Domain Admin accounts, SSH keys, Linux root passwords and all the “juicy stuff” one normally finds in a password vault is stored on a Lansweeper server. The result of our experimentation: Three vulnerabilities were identified that led to the full compromise of our customer’s network infrastructure. Later that week, our client sent us a copy of an email exchange with Lansweeper (formerly Hemoco) confirming the issues reported and that everything should be fixed by version 6.
Responsible Disclosure Attempt
We contacted Lansweeper and tried to engage in a responsible disclosure agreement with them. We couldn’t reach a formal agreement in a timely fashion but in order to protect the public we decided to publish all the details in this blog post. Because Lansweeper seemed convinced their new version would address existing security issues, since version 6 has been released, we believe the potential for harm in release these vulnerabilities to be much lower than the benefits to users of the product.
Vulnerabilities discovered
Lansweeper 5 was installed on a Windows Server machine and was using an MSSQL database. With the objective of recovering the credentials from the Lansweeper database, the following exploitable vulnerabilities were discovered from the dashboard Web access;
- Default Database credentials
- Leakage of sensitive information from MSSQL Error Messages
- Broken encryption for credential storage
Note that other vulnerabilities may exist in the application, testing was performed and aligned with our customer’s needs and was not an extensive application security assessment.
Those three vulnerabilities could lead to the compromise of your stored credentials from two different vectors: the Web interface and the exposed MSSQL database. All captures from the following analysis originates from my lab and reflects our customer’s installation.
Analysis
Default Database credentials
Default installation of Lansweeper 5 using an MSSQL Server as a back-end uses default, static credentials to store and query data from its database. The connection string can be recovered from the web.config file in the web folder of the application. There are no easily accessible means to change these database credentials other than updating the web.config flat file.
User ID=lansweeperuser; Password=Mysecretpassword0*If an attacker has access to port TCP 1433 of the MSSQL Server hosting the lansweeperdb database, he can simply put these credentials in order to gain full access to the lansweeperdb database.
The table where credentials are stored is: tsysCredentials. The capture below shows generic example of the table schema and content.
These stored credentials are not salted cryptographic hashes, they are using a “reversible” encryption scheme that will be discussed later. Although accessing MSSQL database directly from the network is really convenient for the attacker, it would be much harder to access if the database socket is bound locally to localhost. This is in fact the scenario we had to deal with in this particular customer mandate and we will show you an alternative way of retrieving these passwords from the Web user interface.
Leakage of sensitive information from MSSQL Error Messages
The application offers a rich reporting mechanism with SQL scripting capabilities. Developers did take special care to avoid any request that would output the content of the tsysCredentials table into a report or query results. However, the SQL scripting feature (Configuration->Database scripts) displays verbose error messages which can be abused in the same way you would for an Error-Based MSSQL injection. An example is shown in the following screenshot:
Usernames and passwords can be retrieved just by querying the database with the proper values. A simple division by 0 does the trick to display the content of the SELECT statement. In order to access the SQL Scripts feature you need to authenticate to the dashboard and specific roles need to be enabled for your account. However, in the case of our customer, the Lansweeper access control settings have been cleared out by a recent update so default credentials with default roles allowed us to extract the passwords. It should be noted that we were not able to confirm with the vendor if Lansweeper’s management access control settings are usually cleared on update. The advice here is that you should review and test your Lansweeper access control settings after every Lansweeper update. Now that we have extracted the encrypted passwords from the database lets try to recover them.
Broken encryption for credential storage
When storing credentials with a use case like Lansweeper’s – the remote management of computers and servers – passwords need to be reversible by design. However, special care should be taken when storing those passwords and, in the case of Lansweeper, that might have been overlooked. We always recommend dealing with a qualified security expert when designing, implementing and testing a cryptographic solution.
The main problem here is the key location. From the capture of the tsysCredentials table scheme and the above content, no keys were extracted or so it seemed. Neither in the web.config file. Since the application is compiled with the .NET framework, it did not take long to find out that part of the encryption key is stored with the ciphertext. The remaining part of the key is hard-coded and obfuscated in the code itself. This turns out to be a bad key handling solution because it is tied to the software itself and not the specific installation or the specific password entry. Furthermore both the key and the ciphertext can be extracted via the aforementioned SQL injection. A better design would have required both the Web management interface and the server host to be compromised in order to steal these credentials. In plain terms the impact is that any encrypted password from any Lansweeper 5 instance can be decrypted without any other requirement.
Here is a capture of our C# proof of concept tool that was used to recover the password in our lab as well as our customer’s passwords:
> LPR.exe MVRtXmhzQXNpUzeu6JplTkcEqKyZ6K0vOdp/dakDvBT4YFC0vm52fr8YwiRnNZNxY7p2sk6IvM4mh6VCetFIpErgc2pzjvGxCg==
[*] Decrypting Lansweeper Password: MVRtXmhzQXNpUzeu6JplTkcEqKyZ6K0vOdp/dakDvBT4YFC0vm52fr8YwiRnNZNxY7p2sk6IvM4mh6VCetFIpErgc2pzjvGxCg==
[*] Note that this operation will NOT take a while...
[-] Recovered: privateLansweeper Password Recovery Tool
That’s about it! In a nutshell, if you are using Lansweeper 5, remember that password recovery is possible to anyone having direct access to the database (via default hidden credentials) or the Web user interface (via SQL injection). It would have been much better if keys were stored on the Windows system using native cryptographic APIs.
This issue has been fixed in version 6 of Lansweeper. There is a changelog entry that states: More secure password encryption thanks to an on-server encryption key.
EDIT: The following link was brought to our attention which we missed during our (too) quick look on the web: https://www.rapid7.com/db/modules/auxiliary/gather/lansweeper_collector. Good job at Rapid7 guys for providing the public with the best security tool set!
Recommendations
As stated by Lansweeper, Lansweeper 6 should include new security design and security fixes. We will take a look at the solution now that it is released. Meanwhile, here are some guidelines to protect your credentials:
- Review your access control settings on your Web user interface now! Especially if you upgraded. Make sure only authorized people have access to the web interface and force TLS usage.
- Do not use the default database credentials. You can change the password for a strong one, and update your web.config file in your Lansweeper installation folder. You should contact support if help is required.
- Do not expose your database connection on the network without any access control.
Of course, the same recommendations would apply to any other software vendor where critical assets such as high privilege credentials are digitally stored.
