Forum Discussion

Cole_McDonald's avatar
Cole_McDonald
Icon for Professor rankProfessor
6 years ago

!!! Collector Debug Console Security !!!

In doing some of the troubleshooting with LM, I realized that the debug console opens !POSH sessions as admin without asking or verifying.  Anyone that can log into the console and gain access to the collector to run a debug has default admin access into our environment.  The debug console can run Powershell commands on the collector server as if you had opened a powershell console as administrator locally.  From there, I can easily push an elevated command anywhere using CredSSP delegation as a second hop credential option leveraging the credentials given to the collector.
  • mnagel's avatar
    mnagel
    Icon for Professor rankProfessor
    6 years ago

    Oh it gets better :).  We had an issue awhile back (still do) that could only be resolved via an internal debug command (update system.ips property) normally run in the collector debug context.  This is entirely doable via the API.  No MFA required, no IP restriction possible.  Chew on that one for a bit...

  • Matthew_Dunham's avatar
    Matthew_Dunham
    Former Employee
    6 years ago

    Hi @Cole McDonald -

     

    The LogicMonitor Collector runs jobs using the permissions it has inherited from the Collector. Where the Collector is run as a privileged user so will the jobs that it's launched.

    Regardless of which Collector permissions model you adopt, as a best practice we recommend using our role-based access controls to limit "Manage" access to your Collectors. You can do so by assigning individuals that don't need Collector Debug functionality the "manager" role rather than the "administrator" role. This allows you to effectively limit the scope of your end-users based on the principle of least privilege.

  • Cole_McDonald's avatar
    Cole_McDonald
    Icon for Professor rankProfessor
    6 years ago

    Which we do... but from the collector itself, I'm required to explicitly run an elevated powershell session, even as a local admin with permissions to do so.  Asking for an elevated shell should be reserved for specific cases of administration and should be easily auditable / alertable when they are done so.  I live life wearing a tin-foil hat due to my jobs I've held in the past and the one I'm doing now.  I don't control your servers, so I implicitly don't trust them (nothing against LM, just a security posture).  As you're reaching into your customers' enterprise environments with the software, adding an escalation mechanism that would leverage the domain credentials and associated permissions to escalate sessions would be a welcome addition.  That would then trigger events on the DC that are auditable and alertable for better security alerting.

  • Cole_McDonald's avatar
    Cole_McDonald
    Icon for Professor rankProfessor
    6 years ago

    yikes!  Sounds like there's a few holes that need to be plugged.  Big product, there's bound to be some.  Hopefully, these types of issues get pushed ahead of functionality since it's an attack vector into a customer's enviornment.