Full Disclosure: I am not an LogicMonitor employee, but was in the past.
One more to add:
- Review your API tokens and suspend any that you did not create.
When I started at LM over 4 years ago, the default at that time was a temporary password that was already not what is mentioned in those articles. Also, that temporary password was only usable once as it required you to change the password as soon as you used it. Reading several articles last night and this morning, most of them are wildly and factually incorrect. LM does not create user accounts for you, that’s up to you as the LM admin. It’s possible you contracted LM Pro Services to do this setup, in which case, it’s possible one single person in Pro Services was still creating user accounts with the old (pre 2019 at least) style of default password. However, my experience with the engineers in that group leads me to believe that none of them would be that careless.
Take statements in those articles like “until recently” and “they define all user accounts for your org” with a VW bug sized grain of salt. Remember, “news” outlets like that are not interested in peddling the truth, they are interested in getting view counts. If you ever think that a news article is there to provide you with useful information, you have been duped; you are the product.
Some questions I’ve been getting last night and today:
“Just confirming we change default passwords on the collectors?” - This is not actually the password that the articles claim was compromised and is not a credential set or created by LM. The Collector is installed on either a Windows or Linux password provided by the customer. The Collector runs as a service using either an account created on the OS for the purpose of running the Collector or it runs as LOCALSYSTEM (an option on Windows). LOCALSYSTEM obviously runs as the system itself so it doesn’t have credentials associated with it. If desired, you can create an account, either local to the system or in a domain, that the Collector runs as. In the case of Linux, the Collector installer has for some time prompted you for the name of an account to use or create, defaulting to creating the “logicmonitor” user, which is created and given the proper permissions to run the Collector daemon.
“What about the password for the logicmonitor user created during Linux Collector installation?” - That’s a good question, but an easy one to answer. When running sudo passwd --status logicmonitor
, you should see an output that looks like this:
logicmonitor L 01/26/2023 0 99999 7 -1
The second field of this output should read “L”, meaning this is a locked password. From the passwd man page:
-l, --lock
Lock the password of the named account. This option disables a password by changing it to a value which matches no possible encrypted value (it adds a ´!´ at the beginning of the password).
This means that the account is created without a password option available, essentially cutting off that option as an attack surface.
“Are we impacted?” - Most likely not, this was reportedly a small subset of customers and in no way a “large hacking operation”. We are not impacted because we force SSO for the employees here at this MSP and we define random default passwords for all customer user accounts, with 2FA enforced and requiring the reset of the password on first login.
“What about the lmsupport account?” - This account is used by engineers in LM support to log into your portal and assist you when you contact them for assistance. The method for an LM employee to use this account is RBAC controlled within LogicMonitor (not any LM employee can use it) and requires two factor authentication by the LM engineer (unless it has changed, which is unlikely). Under normal circumstances, we have this account restricted to a read only account, to minimize that attack angle as well. When a support case is opened, if the engineer needs admin access to do something, they can request that we temporarily change the role of that account to a higher level role so they can do what they need to do to help us.