Passive Discovery of User Accounts

The Passive Vulnerability Scanner's plugin rule base was recently updated with new logic to recognize a variety of client-side account information for services such as AIM, MySpace and many others. This blog entry discusses the new rules and how they can be used for auditing a network.

Current User ID Rules

The following decodes are currently available in the live plugin update feeds for the Passive Vulnerability Scanner:

• 1329 return email addr
• 2341 POP3 User
• 2600 MSN Messenger UserID
• 2609 PGP Sender email
• 3018 HTTP Base64 encoded credentials
• 3954 IDA Pro UserID
• 4082 AOL Instant Messenger user enumeration
• 4098 IMAP UserID enumeration
• 9000 Myspace UserID
• 9001 Facebook UserID
• 9003 Xanga UserID
• 9005 gmail userID
• 9006 XM Radio UserID

These plugins identify a variety of specific user names and accounts that are active on any given host in a monitored network. For example, below is a screen shot of a PVS detect of a Tenable email account as
viewed under the Security Center:

Uses of This Information

If using any of these services is against your corporate policy, then obtaining the actual user name of the account and the IP address from which it originates is very useful. If this data is combined with active data from Nessus scans, such as the NetBIOS or DNS name of the source computer, this can also be useful for identifying which network users are associated with which types of external accounts.

When performing incident response and starting out with nothing more than a list of potentially compromised IP addresses, or IP addresses that are behaving oddly, being able to obtain a list of external resources and user names used on those systems is also useful. Knowing that a potentially compromised system may have been used by certain users can help incident responders prepare for what they might encounter or give clues to access vectors that a system was compromised with.

Lastly, another use of this data is to associate users to IP addresses. Being able to associate an account that "lives" on the network with a specific IP address can also track when a user gets a new IP address. In networks where centralized domain and DHCP logs aren't centralized, this can be a very useful audit trail for tracking when certain users have obtained an IP addresses or a new IP address.

Limitations

There are three limitations to this approach.

First, all email and chat user accounts are logged, regardless if they are associated with your network or not. This means you may see personal user IDs like "kungfun1nga", "rjg1969" and so on. You may also see real user names like "rongula". Mapping these accounts back to real users on your network is not a trivial task, but the data is very useful if you are responding to an incident or tracking the same private user moving around your local network.

Second, if the PVS is deployed outside of a NAT or VPN device, it won't differentiate specific IPs behind that device. For example, if you had 100 students deployed behind a NAT firewall, the PVS will only log the first email address it sees and associate it with the IP address of the NAT device.

And lastly, the PVS can detect encrypted client and server sections, but it does not decrypt them. If your users are checking mail with secure POP, secure IMAP or through a VPN, the PVS will likely be able to identify this sort of client-side activity, but won't be able to discern user names.

Using these on Your Network

A majority of these decodes are already available in the PVS updates. If you've manually synchronized your plugins lately or have your PVS managed by the Security Center, you will have these latest decodes.

Plugins 9000 through 9006 are available as a manual download under the Corporate Policy Plugins. These rules are available in the policy.prm library. If you are running the PVS in standalone mode, download the policy.prm file and place it in your /opt/pvs/var/pvs/plugins on RedHat. If your PVS is being managed by the Security Center, place the policy.prm file in the /opt/sc3/proxy/outbound directory and it will be pushed out automatically.

Disabling This Type of Collection

If gathering these user IDs is against your corporate policy, they can be disabled. On the Unix versions of the PVS, inside the /opt/pvs/etc/pvs.conf configuration file, there is a line (disabled by default) which identifies the file containing a list of plugin IDs to be disabled. The section of the pvs.conf file looks like this:

    #disabled-plugins "/opt/pvs/var/pvs/disabled-plugins.txt";
    plugins-directory "/opt/pvs/var/pvs/plugins";
    fingerprints "/opt/pvs/var/pvs/osfingerprints.txt";

Uncomment the line, create the /opt/pvs/var/pvs/disabled-plugins.txt file and place the IDs you don't want the PVS to use one to each line like this:

1329
2341
2600
2609
3018

The PVS process must be manually restarted for these settings to take effect.

For More Information

If you'd like more information about the Passive Vulnerability Scanner, please consider the following demonstration video and previous blog entries:

• (video) PVS and the Security Center are used to monitor a network of more than 10,000 nodes
• (blog) Proxy and Firewall Detection with the PVS
• (blog) Using the PVS to detect Corporate Policy Violations and Data Leakage
• (blog) Finding Interactive and Encrypted Sessions on your network