Forum Discussion

azia1's avatar
azia1
4 years ago
Solved

Adding/Modifying Device System and Auto Properties via API

When I was checking the api documentation, there was nothing there indicating how to add/modify System Properties for example "system.sysinfo". Is this even possible? I bring up as it w...
  • mnagel's avatar
    mnagel
    4 years ago
    1 hour ago, azia said:

    When I was checking the api documentation, there was nothing there indicating how to add/modify System Properties for example "system.sysinfo".

    Is this even possible?

    I bring up as it would be useful for reporting/dashboard purposes, as sometimes we DONT have a means to fully monitor a machine aside from pinging it and or engaging it via an API, but say in a quick report we want to see how many windows/CentOS servers we have and the connection trends, we can sort/filter by system.sysinfo or other system properties that are usually there. 

     

    Well.... yes.  But it reveals a pretty scary part of the API and IMO one that LM should be quite concerned with given the recent SolarWinds hack.  Basically, you can execute the debugger from the API, which allows you to set those variables.  This also allows you to (among other things) post a Powershell script and run it.  With an API key.  From anywhere.  Without MFA.  I am not going to post the specifics of how to do this here, but if you watch debugger access in a web browser trace, you will see how it is called.  

    FWIW, I learned about this during a ticket we had where NetFlow would not pair with a device because the source interface was not in the system.ips, so we had to use this to manually set that property. That script runs regularly to this day as it is the only option we have to keep NetFlow associated with that device.

mnagel's avatar
mnagel
Icon for Professor rankProfessor
4 years ago

Sure, but it ultimately relies on an admin-enabled API token.  Those should always be protected very carefully, but I also don't know if folks are aware the debugger can be accessed that way. It is a useful tool, but very sharp.  IMO debugger access should have an additional layer of protection at minimum (e.g., an allow list).  That might be appropriate for other endpoints, but definitely the debugger.  I know it is undocumented, but that does not remove the risk.  I do know there is an IP Whitelist option in the Portal Settings -- does that apply to all access including API access?  If so, it would be preferable to have one ACL for UI access and one for API access since the former is more likely for clients to want general access (and in an MSP portal, that means if one wants that, all have to have it).