Parse Linux group IDs, names and memberships #3038
Conversation
The tests are in linux_passwd.in.yaml, and test files in the new directory testdata/files/linux.
misje
force-pushed
the
add-linux-sys-groups
branch
from
b9bb815 to
2bb2063
Compare
|
I added a test, both for this artifact and Users. I suppose it would make sense for these two to be pretty similar. Should I rename "GID" to "Gid"? Use string instead of int for GID? I take it we don't modify Users in order to ensure backwards compatibility. |
|
This test is failing because the files on windows have |
|
Which files end up with \r\n? I just checked passwd and group in git, and they're still \n. The Windows test also failed before I added tests. I force-pushed today after rebasing to latest master before adding the tests. |
|
When you git clone on windows it changes the files line ending. This causes the test to fail - you can see it in the test log output. If you are sure these files will never have windows endings in the wild you can set these files to binary here or create a .gitattribute file further down the tree |
|
I see what you mean now. These files would never have CR in Linux systems as far as I know, but it makes sense to support it nevertheless. For instance if the passwd/group file parameter is pointing to a file copied off a computer, possibly getting converted along the way. |
…er (#716) Note that this artifact depends on Velocidex/velociraptor#3038. Here is a verbatim copy of the artifact description: This artifacts checks a number of files and directories to verify whether they have the expected owner, group owner and mode. A file with an incorrect owner may allow attackers to modify important system files. Similarly, incorrect mode, like word-writable configuration or passwd/shadow files may also be signs of serious misconfiguration or signs of malicious activity. The parameter FilesToInspect contains lines of globs to search for. Each line may specify expected user, expected group, expected file mode and expected directory mode. It is very important that the order of the lines is in order of increasted specificity. For example: ```csv /etc/*,root,root,644,755 /etc/?shadow*,,shadow,640, ``` Here, every file in the directory /etc is expected to be owned by root:root and have file permissions set to 644, and group permissions set to 755. The files under /etc matching "?shadow*" are still expected to be owned by root, since the override for user is empty, but the group is no longer expected to be "root", but "shadow". File permissions should be "640" instead of "644". Note that this is an example and will most likely return hits, since a number of files in /etc have different owners and modes. "User" may either be an integer (UID) or a string (username). "Group" may be either an integer (GID) or a string (group name). The names for all UIDs and GIDs are looked up and displayed along with their IDs in the result. Modes may be specified in either octal numbers or strings. Modes specified in octal numbers, e.g. 755, 640, 1777, are matched using a regular expression, so that both "0640", "640" and "100640" matches "100640". An implicit anchor, '$', is used to match against the end of the octal mode string. When using mode strings (NumericMode unchecked), modes take the format "-rwx-r-x-r-x". Regex comparison is used, and an implicit '$' anchor is inserted at the end of the string. String modes allows for verifying only certain bits of permissions, like ensuring that only the owner has write access, no one has permission to execute, but read access is not important: "r.-.--.--". Or ensuring that SUID/GUID is not set. For finding files specifically with SUID set, look at Linux.Sys.SUID. Mixing both formats is not supported and will result in unexpected results. This artifact can also be used to look for all files owned by root with world-writable permissions, for instance. Uncheck NumericMode, add a glob, select "root" as owner and enter any invalid permission string in UserMode. This will return every file owned by root. In the notebook, add something like "WHERE Mode=~'w.$'" to the query. The User field may also be empty, essentially returning every file in the glob as long as the UserMode field contains an invalid value. This turns this artifact into a file finder-like tool with metadata like username and group names for further processing. The following columns are returned: - OSPath - IsDir - UID - User - EUser (expected user from FilesToInspect) - GID - Group - EGroup (expected group from FilesToInspect) - Mode (file/directory mode/permissions) - EMode (expected file/directory mode from FilesToInspect) - Mismatch (a comma-separated string of one or several of "uid", "gid" and "mode") - Mtime - Ctime - Atime Note that the artifacts used to look up usernames and group names use the files /etc/passwd and /etc/group. You will have to modify this artifact to use `getent passwd`/`getent group` to use NSS and get users and groups from Active Directory etc. The provided default values in FilesToInspect is an example only.
I've had the need to look up group names from GIDs, as well as finding group memberships. This simple artifact does that. It is very much like Linux.Sys.Users, except that GID is an int. I felt that this made more sense, since gid in stat() is an int.