8000 0.74.3 sync2 by scudette · Pull Request #4249 · Velocidex/velociraptor · GitHub
[go: up one dir, main page]
More Web Proxy on the site http://driver.im/
Skip to content

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 22 commits into from
May 20, 2025
Merged

0.74.3 sync2 #4249

merged 22 commits into from
May 20, 2025

Conversation

scudette
Copy link
Contributor

No description provided.

scudette and others added 22 commits May 20, 2025 22:02
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>
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>
@scudette scudette merged commit 1266ea2 into v0.74-release May 20, 2025
3 checks passed
@scudette scudette deleted the 0.74.3-sync2 branch May 20, 2025 12:18
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants
0