Skip to content

Conversation

mssalvatore
Copy link
Collaborator

@mssalvatore mssalvatore commented Mar 3, 2023

What does this PR do?

Fixes #3039

Add function for smarter brute force credentials generation

PR Checklist

  • Have you added an explanation of what your changes do and why you'd like to include them?
  • Is the TravisCI build passing?
  • Was the CHANGELOG.md updated to reflect the changes?
  • Was the documentation framework updated to reflect the changes?
  • Have you checked that you haven't introduced any duplicate code?

Testing Checklist

  • Added relevant unit tests?
  • Have you successfully tested your changes locally? Elaborate:

    Tested by running unit tests

  • If applicable, add screenshots or log transcripts of the feature working

@codecov
Copy link

codecov bot commented Mar 3, 2023

Codecov Report

Patch coverage has no change and project coverage change: +0.06 🎉

Comparison is base (3449dc9) 67.17% compared to head (2ad1ed2) 67.23%.

❗ Current head 2ad1ed2 differs from pull request most recent head 68507ed. Consider uploading reports for the commit 68507ed to get more accurate results

Additional details and impacted files
@@             Coverage Diff             @@
##           develop    #3048      +/-   ##
===========================================
+ Coverage    67.17%   67.23%   +0.06%     
===========================================
  Files          438      439       +1     
  Lines        12602    12627      +25     
===========================================
+ Hits          8465     8490      +25     
  Misses        4137     4137              
Impacted Files Coverage Δ
.../monkey/infection_monkey/exploit/tools/__init__.py 100.00% <0.00%> (ø)
...exploit/tools/brute_force_credentials_generator.py 100.00% <0.00%> (ø)

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

☔ View full report at Codecov.
📢 Do you have feedback about the report comment? Let us know in this issue.

Credentials(identity=IDENTITIES[2], secret=SECRETS[3]),
}

generate_and_compare_credentials(input_credentials, expected_credentials)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this could also assert the correct order as the output should be deterministic. IMO less UT code to maintain is worth it, but "test one thing only" has benefits as well, so I leave it up to you.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The interface doesn't make any promises about the order, except that complete credentials from the input are first. But, again, it does not make any promise about the order of those credentials.

identity_type = type(credentials.identity)
identities.setdefault(identity_type, set()).add(credentials.identity)
Copy link
Contributor

@VakarisZ VakarisZ Mar 6, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What's the point of putting identities/secrets into dicts by types? This is an indirect way of grouping the output by type? Why do we want it?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's fairly direct. There's a comment below. Basically, orderly output is better than disorderly, IMHO. It might be useful for debugging. If we need to dump out the result, at least there's some order to it.

So, yeah, it's analogous to an SQL GROUP BY clause. Order isn't guaranteed by the interface (other than ordering complete/known-good credentials first"

Comment on lines 36 to 37
identity_filters: Iterable[Callable[[Identity], bool]] = (),
secret_filters: Iterable[Callable[[Secret], bool]] = (),
Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What's everyone's thoughts on this? Would it be better to just allow the user to provide a single filter for each of these, instead of an iterable?

Options:

  1. Allow the user to provide a single filter for each. This is probably the most common use case. If a user wants to filter on multiple criteria they can build a single compound filter and pass it in.
  2. Leave it as is.

@VakarisZ
@shreyamalviya

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I say leave it in, assuming there's no downside to doing that.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The interface is arguably more cumbersome if you just need a simple filter, but arguably nicer for those cases with more complex filtering criteria.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's already implemented and it's not something whose logic will change often.

With our end goal being an easy-to-use plugin system, I like the idea of leaving this in.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

After some discussion on webex, we decided to go with a single filter, as this will support the vast majority of cases.

@mssalvatore mssalvatore force-pushed the 3039-smarter-brute-force-credentials-generator branch from de428f6 to 1c568ae Compare March 6, 2023 14:00
@mssalvatore mssalvatore force-pushed the 3039-smarter-brute-force-credentials-generator branch from 1c568ae to 2ad1ed2 Compare March 6, 2023 14:21
mssalvatore and others added 4 commits March 6, 2023 10:05
The vast majority of uses for this function will require filtering
certain types of secrets. Only one filter is required to this. Accepting
an iterable of filters for identities and secrets unnecessarily
complicates the code and interface.
@mssalvatore mssalvatore force-pushed the 3039-smarter-brute-force-credentials-generator branch from 2ad1ed2 to 68507ed Compare March 6, 2023 15:05
@mssalvatore mssalvatore merged commit 7f89663 into develop Mar 6, 2023
@mssalvatore mssalvatore deleted the 3039-smarter-brute-force-credentials-generator branch March 6, 2023 15:11
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.

Smarter brute forcing
3 participants