poltcatering.blogg.se

1. #LANSWEEPER LOG4J REPORT UPDATE#
2. #LANSWEEPER LOG4J REPORT PATCH#
3. #LANSWEEPER LOG4J REPORT FULL#
4. #LANSWEEPER LOG4J REPORT PASSWORD#

Developers did take special care to avoid any request that would output the content of the tsysCredentials table into a report or query results. The application offers a rich reporting mechanism with SQL scripting capabilities. Leakage of sensitive information from MSSQL Error Messages 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. 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. These stored credentials are not salted cryptographic hashes, they are using a “reversible” encryption scheme that will be discussed later.

#LANSWEEPER LOG4J REPORT FULL#

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. User ID=lansweeperuser Password=Mysecretpassword0*

There are no easily accessible means to change these database credentials other than updating the web.config flat file. The connection string can be recovered from the web.config file in the web folder of the application.

All captures from the following analysis originates from my lab and reflects our customer’s installation.ĭefault installation of Lansweeper 5 using an MSSQL Server as a back-end uses default, static credentials to store and query data from its database. Those three vulnerabilities could lead to the compromise of your stored credentials from two different vectors: the Web interface and the exposed MSSQL database. 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. Broken encryption for credential storage.Leakage of sensitive information from MSSQL Error Messages.With the objective of recovering the credentials from the Lansweeper database, the following exploitable vulnerabilities were discovered from the dashboard Web access Lansweeper 5 was installed on a Windows Server machine and was using an MSSQL database. 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.

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. We contacted Lansweeper and tried to engage in a responsible disclosure agreement with them. 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. The result of our experimentation: Three vulnerabilities were identified that led to the full compromise of our customer’s network infrastructure.

#LANSWEEPER LOG4J REPORT PASSWORD#

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. At first, we were doubtful that explanation would hold up to scrutiny.

#LANSWEEPER LOG4J REPORT UPDATE#

According to him, a recent update must have reset the login permission on the dashboard. Our customer was actually shocked and swore that he had configured only Domain Admin access on this Web interface. We were fairly surprised during this test when we were able to access Lansweeper 5’s dashboard with a regular user account.

#LANSWEEPER LOG4J REPORT PATCH#

Lansweeper is an inventory software that scans your network in order to gather system information such as patch level, network interfaces, resources status, etc. However, in one of these rare cases while performing an internal penetration test for a client, we had to do so. As a penetration testers, we rarely have to find ‘zero day’ vulnerabilities or perform ‘bug hunting’ in order to compromise Windows Active Directory Domains.