8000 Create Linux.Detection.BruteForce.yaml by RCarras · Pull Request #861 · Velocidex/velociraptor-docs · GitHub
[go: up one dir, main page]
More Web Proxy on the site http://driver.im/
Skip to content

Create Linux.Detection.BruteForce.yaml #861

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.

Sign up for GitHub

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

Jump to bottom
Merged
merged 12 commits into from
Jun 25, 2024
Merged

Create Linux.Detection.BruteForce.yaml #861

merged 12 commits into from
Jun 25, 2024

Conversation

RCarras
Copy link
Contributor
@RCarras RCarras commented Jun 14, 2024 •
edited
Loading

This module search for brute force attacks, basing its analysis on BTMP and WTMP logs.

Requirements: It's necessary to use velociraptor client with high privileges because of utmpdump command use.

@RCarras
Copy link
Contributor Author
RCarras commented Jun 19, 2024

Hello @scudette should I do anything more to approve the module? Sorry for any inconvenience.

@scudette
Copy link
Collaborator

Couple of comments:

  1. Use a temp directory so we dont leave files on the client
  2. Lock the release down by hash

But mainly the issue is with the shell script - this type of analysis is easy to do with VQL so what does the shell script add? It also looks to be quite vulnerable (bash scripts are difficult to write securely) so I am not sure we really want to go that way?

@RCarras
Copy link
Contributor Author
RCarras commented Jun 20, 2024

Hi @scudette, firstly, thanks for your support and contribution to improve the artifact. Replying to your suggestions and questions:

  1. Use a temp directory so we dont leave files on the client. ✅
  2. Lock the release down by hash. ✅
  3. The script was firstly done by shell script that's why we present It as follows, It could be adapted (but could be a tedious process because of script length), anyway we saw other Shell scripts used by VQL artifacts (as CatScale for example that aren't adapted to VQL either) so we thought it could be fine.
  4. Talking about possible vulnerabilities, we tested It many times to improve it and we did some bash scripts vulnerabilities tests (Example: shellcheck), so we think it's secure, anyway if you detect any issue we'll appreciate it and change the vulnerable part of the code.

@scudette
Copy link
Collaborator
scudette commented Jun 21, 2024 •
edited
Loading

I didnt take a closer look at the shell script to be honest but some things immediately stood out to me.

  1. The script uses hard coded paths that leave files behind on the system as well as making it easy to do symlink attacks.
  2. Using sudo is not needed in a script already running as root - will fill up the auth logs and may interfere with other evidence.
  3. not using absolute paths to shell commands like date utmpparser etc opens the script up to path injection attacks.
  4. I am not sure if there is shell injection in the awk parameters - at first I thought so but I think that might be ok actually due to non expansion single quotes.

It is also very hard for me to actually see what the script is doing without reading it very closely. A better comments or description would help. What constitutes a detection? Is 5 failed logins within 1 hour a detection? Is it doing more than that? Is it similar logic to https://docs.velociraptor.app/artifact_references/pages/windows.events.failedlogbeforesuccess/ ?

It is usually very difficult to write secure shell scripts so I am always a bit reluctant to include those. You are right that some other artifacts include shell scripts too (like for example UAC is also a shell script). It is a bit about risk mitigation.

We have on our road map an attempt to split the exchange into different categories of artifacts - particularly to put artifacts that use external tools and scripts in their own category because they do pose higher risk i think.

@RCarras
Copy link
Contributor Author
RCarras commented Jun 21, 2024 •
edited
Loading

Hello @scudette, thanks again for all your feedback and great ideas to improve the shell script. I've just update the shell script (repository) and VQL artifact locked hash.

Updates:

  1. The script uses hard coded paths that leave files behind on the system as well as making it easy to do symlink attacks: Now it uses mktemp to create the dir ✅
  2. Using sudo is not needed in a script already running as root - will fill up the auth logs and may interfere with other evidence: Now it doesn't use sudo inside the script ✅
  3. not using absolute paths to shell commands like date utmpparser etc opens the script up to path injection attacks: Now commands are set with full path, that is searched with WHICH full path command ✅
  4. Every script logic line is commented, except logs extracting one (utmpdump + rsync), to improve understanding of the script. ✅
  5. BruteForce Detection: by default, after testing it a lot (by simulating with hydra brute force attacks) and taking into consideration previous incidents experience, it's set as: Time_Interval between attempts ~ no more than 45 secs, and Attempts to be considered as brute force ~ 80 attempts. Anyway it's a malleable variable, so depending on Incident Responder experience it could be change as it is a parameter in VQL artifact. ✅

I'd also want to add that the script has 3 flows to detect different type of brute forces:

  • Basic Brute Force Attack: multiple consecutive attempts from an IP.
  • Password Spraying: multiple consecutive attempts from different users with the same password.
  • Dynamic IP Attack: multiple consecutive attempts from different IPs.

Kind regards,
RCarras

@scudette
Copy link
Collaborator

Just FYI , point 3 does not fix the issue - which still searches the path for the command which is still vulnerable to path injection. Scripts need to specify the absolute path to all sub commands.

@RCarras
Copy link
Contributor Author
RCarras commented Jun 25, 2024

Just FYI , point 3 does not fix the issue - which still searches the path for the command which is still vulnerable to path injection. Scripts need to specify the absolute path to all sub commands.

@scudette Solved. If it's necessary anything more to merge artifact with the exchange let me now.
Thanks!!

@scudette scudette merged commit 6af3a9e into Velocidex:master Jun 25, 2024
3 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers
No reviews
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.
2 participants
@RCarras @scudette
0