LogicMonitor Portal Security

Some additional information on how to keep your LogicMonitor portals secure, including the 2FA authentication enablement. LogicMonitor Security Best Practices,  2FA FAQ’s & User Reports.

@David Bond @Stuart Weenig thank you for sharing this level of detail! Much appreciated!

For those frantically enabling 2FA everywhere, I can recommend the Authy app, which is low-support, even if you are an MSP with a lot of users.

Users will need to add the Authy app to their Android / iPhone first, after which the “Verify using OneTouch Verification (Authy app)” option is quick and painless:

Authy is good stuff

Thanks @A11ey - we really appreciate you providing the “official” word 🙂.  Marked as Best Answer.

For those frantically enabling 2FA everywhere, I can recommend the Authy app, which is low-support, even if you are an MSP with a lot of users.

Users will need to add the Authy app to their Android / iPhone first, after which the “Verify using OneTouch Verification (Authy app)” option is quick and painless:

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.

UPDATE: I have had confirmation this morning from LM Support that:

1. a security incident is being investigated
2. the news articles referenced are “factually incorrect”
   • no details given, which is good practice at this stage until mitigations have been enacted
3. a “small number” of customers are affected
   • those customers have been contacted and preventative measures are being taken
   • This is important - if you have not been contacted, you can assume that you are not affected
4. all customers should take time to secure their accounts
   • for example as per my list above
   • Two-Factor Authentication Setup Guide

I would discourage any speculation until LogicMonitor have made a statement.  However do not delay in securing your accounts, with my list above a good starting point.

Again, I’m willing to update the advice, but am awaiting LogicMonitor’s public statement before doing so.