-
Notifications
You must be signed in to change notification settings - Fork 524
0.74.3 sync2 #4249
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Merged
Merged
0.74.3 sync2 #4249
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Previously API clients had to have the MACHINE_STATE permissions (i.e. had to be admins) to write events over the API. However, the user only needed the PublishQueues permission in the VQL send_event() function. This PR brings the code into more consistency: 1. Deprecate the old WriteEvent() API in favor of the PushEvent() 2. Allow permission checks against the PublishQueues field in the user's policy. This allows a user to push events with any permissions (e.g. they dont event need "reader"). This is useful for setting up scripts with very low permissions who are still able to push events to Velociraptor.
Commit 786e656 introduced a background job for updating client flow indices after deleting flows. This background job always constructed indices from scratch, leading to slow I/O in a master/minion setup backed by Amazon EFS. This PR allows individual flow IDs to be passed to the background job so it can simply filter them out from the index files, similar to the path taken when `delete_flow( … , sync = true )` is called. --------- Co-authored-by: Mike Cohen <mike@velocidex.com>
This allows profiles to see the status of recent flows that have completed. It also addresses the issue of the in flight checks checking the flow status after it has completed. The client will keep records of past flows and simply return the exit status of those flows when asked.
Prevously the flow state was set to error as soon as a log was issued at level ERROR however the query continued running until the end. This caused the GUI to disable the cancel button so it was impossible to cancel the flow. This PR Keeps the flow at the IN_PROGRESS state until completion while tagging the error message in the flow. This allows the flow to be cancelled after the error by the GUI. After completion the flow will be switched to the ERROR state. Also: 1. Fix Registry accessor parsing of MULTI_SZ fields. 2. Fix Generic.Client.Profile artifact 3. Refactor tests to use the global mock clock
…#4204) # Background The default folder for Darwin installers is `/usr/local/sbin` as per https://github.com/Velocidex/velociraptor/blob/a5abaee504234366a0ebe2eb114d0e02019f38d5/docs/references/server.config.yaml#L278. This folder does not exist by default on MacOS. Currently the installer will create it with if it is not present upon installation, with 0700 permissions (=only root can read, write and traverse; everyone else can't do anything). As per [best practices](https://refspecs.linuxfoundation.org/FHS_3.0/fhs/ch03s16.html): > Locally-installed system administration programs should be placed into `/usr/local/sbin`. > (...) > We recommend that users have read and execute permission for everything in `/sbin` except, perhaps, certain setuid and setgid programs. > The division between `/bin` and `/sbin` was not created for security reasons or to prevent users from seeing the operating system, but to provide a good partition between binaries that everyone uses and ones that are primarily used for administration tasks. > There is no inherent security advantage in making `/sbin` off-limits for users. # Proposed solution Change the permissions to 0755, which preserves the current rights for root, but allows other users to traverse and read without obstruction. This is in line with best practices and ensures it doesn't interfere with other tools interacting with this folder.
Hi, i updated the security key, since the old gpg key was expired. The information was taken from https://www.rapid7.com/.well-known/security.txt - [x] formatted security info - [x] updated encryption fingerprint Best regards, c-f #### Sidenote The security.txt of rapid7 contains more information. I was not sure, if i should submit the complete security.txt or not (seen below). Link: https://www.rapid7.com/.well-known/security.txt ``` Contact Security Team: security@rapid7.com Abuse Contact: abuse@rapid7.com Encryption key: https://keys.openpgp.org/search?q=396F6DCA9B60EB1AF2D1621FA885DF1431A0A489 Preferred Languages: en Canonical: https://www.rapid7.com/.well-known/security.txt Vulnerability Disclosure Policy: https://www.rapid7.com/security/vulnerability-disclosure-policy/ Report a Vulnerability in a Rapid7 Product or Service: https://rapid7.freshdesk.com/support/tickets/new?ticket_form=vulnerability_disclosure Careers: https://careers.rapid7.com/careers-home Blog: https://www.rapid7.com/blog/ ```
…4221) Windows refuses to load the driver from a directory with spaces in it. This change allows the driver to load from the more usual location. --------- Signed-off-by: dependabot[bot] <support@github.com> Co-authored-by: snyk-bot <snyk-bot@snyk.io> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
Also added Flat support to VMDK
This finds VHDX files and calls the linux file finder on them.
…4227) The artifact contained a hardcoded PID equal to 9604 that prevented the artifact from working correctly. The following error can be seen in the Log when attempting to run the artifact: - vad: OpenProcess for pid 9604 : The parameter is incorrect. Modifying the harcoded PID of 9604 to Pid addresses the issue.
Also make Linux process tracker fields the same as Windows when using the dummy tracker. Fixes: #4233 --------- Co-authored-by: snyk-bot <snyk-bot@snyk.io>
There was no condition check if a file was ending a .lnk extension. This led to the Artifact.Windows.Forensics.Lnk attempting to parse other files such as executables.
…4239) Previously the rule reported was the triggering rule of the correlation which makes no sense.
…4241) Previously the details and enrichment field were filled from the matching rule. The PR also tags each matching event in the correlator with the rule that actually matched it. This makes it easier to see why the rule was selected into the correlator.
extended with OpenSUSE build recommendations
This accomodates complex routing configurations which allow base path to depend on arbitrary things (like org name). Also: * fixed copy notebook cell bug * revert gorilla csrf to unbroken version * remove unused pst artifacts * Added audit log on jwt exchange
Client side artifacts run on the endpoint without ACL enforcement. This is usually what we want but sometimes the extra permissions can give the user extra permissions on the end point. The artifact writer can specify required permissions which will be enforced by the server prior to collecting the artifact. However, sometimes the artifact can use plugins with high priviledge safely - in that case we do not want to restrict the users that may collect it. For example say the artifact collects autoruns by shelling to the autoruns.exe tool. Even though it is using the execve() plugin this call is safe because the args are fixed and can not be influenced by the user. However if the artifact passed user input into the execve() plugin, the user requires the EXECVE permission. Previously, the artifact could declare EXECVE as a required permission, for artifact uses where user input was directly allowed in execve() calls. This enforces additional checks on the launching user to ensure they have the EXECVE permission. This PR modifies the artifact verifier to track plugin permissions used in the artifact. This allows us to see if the artifact inadvertantly gives the user permissions they do not have. This PR introduces another field to the artifact definition called `implied_permissions` where the artifact writer can declare permissions which the artifact will give but the user does not require those. This helps the verifier identify additional permissions that are accidentally given to users on the client. This PR adds a test to ensure built in artifacts have all necessary permissions declared either in `required_permissions` or `implied_permissions` --------- Co-authored-by: snyk-bot <snyk-bot@snyk.io>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
No description provided.