In this desktop management app, they are allowing access to view event viewer of remote windows machine even for guest privileged users of that app. But other features like RDP, command execution, etc are restricted which is expected as per design. Viewing event logs isn't treated in the same way. I am wondering if there is any way this feature can be exploitable. Powershell logs are there.
3 Answers
Exactly what's in the event logs will depend on the software you have installed - many third party applications write even log entries, and there's no guarantees about what kind of data they may include in them.
The built in Security log shouldn't directly contain passwords - but it can often end up having them if users accidentally type their password in the username field.
It is unlikely to be directly exploitable on it’s own. However, it can simplify other methods of exploitation.
The big risk here is of course things like passwords or PII. But that type of thing is rare unless you’re running very poorly written software.
The more realistic risk is two other types of information:
- Information that allows you to infer the system configuration.
- Information that allows you to infer the effects of other attempts at exploiting the system.
As an easy example of the first case, on the ASUS laptop I’m typing this on, a quick look at the event logs is enough to immediately identify that:
- At least some of the ‘standard’ ASUS services are installed and enabled.
- There is at least one sound card using a Realtek chipset
- It’s probably not a virtual machine
- Secure boot is disabled
- Network time synchronization is enabled
- Windows Update is enabled
- Hyper-V is enabled
- There’s probably only one non-service user
And that’s just the stuff that’s easy to see and I’m willing to share. You can parse the event logs to figure out what updates are installed on a system. You can infer most of the services and features that are actually in use on the system. You can figure out a nontrivial amount of the hardware configuration. And being able to see error messages resulting from an attack attempt on the system? That’s priceless for an attacker, because it means they potentially have detailed feedback on whether or not their attack is working. Better yet, a sophisticated attack could even use the event logs for data exfiltration if they’re remotely viewable.
In short, it’s the same type of reason that you shouldn’t expose a performance monitoring tool like Netdata or Prometheus on an untrusted network. It probably won’t be used directly as an attack vector, but it can definitely be used to collect information to plan an attack or as a way to exfiltrate data during an attack.
-
1I agree with this. In my opinion, exposing any management plane information to unauthenticated parties (presumably what "Guest" as in this case is) in a security risk, as it rules out possibility of authorization and auditing.– DL444Commented Jul 23 at 14:40
Much more rarely passwords (see Gh0stFish's answer, it can certainly happen).
However, since you mentioned "other such sensitive info" - both in the event viewer to a limited extent and in memory dumps to a greater extent, consider that information a program is working with when it crashes or has logging turned up to 'debug' or 'trace' will often find its way into the logs/dump.
The sort of information you can find here can expose anything from configuration information to software vulnerabilities to Personal Identifiable Information, aka PII (e.g., if the program processes HR data).
This is going to be greater in extent (though generally much less available) than the sort of information that can find its way into user-facing error messages, such as on websites, which are often replaced with generic error pages to prevent leaking configuration data or PII.
So, for the same reason caution often prevails over detailed user-facing error reporting in client applications, you should be very cautious who has access to both events logs and memory dumps.
