(no title)
ShabbyDoo | 5 years ago
1. Was this GIF-fetching endpoint likely exposed publicly by most customers' SolarWinds deployments?
2. Public or not, was there any auth in front of this endpoint when deployed?
My presumption is that some (most?) customers deployed the SolarWinds admin console publicly (with its own auth in front) and that this particular GIF-fetcher endpoint, being deemed trivial, was not protected by the console's auth scheme. Thus, those who knew about the trojan just had to scan the known IP ranges of SolarWinds customers until they found the exposed admin console, and then remote code execution was easy from there.
If this endpoint was protected by the same auth scheme as the admin console, then this trojan becomes more of a privilege escalation attack. Its existence would increase the value of obtaining the creds of a SolrWinds user, but (presuming SSO integration) those creds would get the attackers lots of other access given the sorts of IT people who use SolarWinds.
If the endpoint was not fronted by any auth scheme but the admin console was not exposed externally, then the benefit would be that attackers who gained access to a SolarWinds customer's employee-facing network (what's the name for the network segments accessible to anyone who plugs in a laptop in a cubicle?) could "ride" this trojan to gain access to a more privileged part of the network.
I'm not an infosec guy. Do these arguments make sense?
No comments yet.