Skip to content
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

Bulk Search not returning all results #6522

Closed
sweet-mentat opened this issue Mar 30, 2024 · 2 comments
Closed

Bulk Search not returning all results #6522

sweet-mentat opened this issue Mar 30, 2024 · 2 comments
Assignees
Labels
bug use for describing something not working as expected solved use to identify issue that has been solved (must be linked to the solving PR)
Milestone

Comments

@sweet-mentat
Copy link

Description

The Bulk Search is not returning results for objects that match on given values. When looking in Developer Tools at the GraphQL query, I see it searches these fields for the user-provided values:
name
aliases
x_opencti_aliases
x_mitre_id
value
subject
attribute_abstract
hashes.MD5
hashes.SHA-1
hashes.SHA-256
hashes.SHA-512
x_opencti_additional_names

The GraphQL query returns matches, but are not shown in the GUI. I have looked into the opencti code, and it looks like each object gets a default value, and the user-provided values are matched with these default values. However, sometimes an object will have multiple values that a user would search, like an X509-Certificate or a file. These objects have hashes, so if a user provided a SHA-1 hash, it will show up in the results of the GraphQL query, but not in the bulk search results in the GUI, because the default value is the SHA-256 hash. So the opencti code will try to match the results of the GraphQL query to the user-provided values, and since the default value is the SHA-256 hash, it will not match against the user-provided SHA-1 hash.

Environment

  1. OS (where OpenCTI server runs): Docker image
  2. OpenCTI version: 6.0.8, 6.0.5, 5.12.21
  3. OpenCTI client: frontend
  4. Other environment details:

Reproducible Steps

Steps to create the smallest reproducible scenario:

  1. Find or create an X509-Certificate or File object that has both SHA-1 and SHA-256 hashes.
  2. In bulk search, enter the SHA-1 hash of the object
  3. The SHA-1 hash will show up as unknown

Expected Output

I would expect the user-provided values to match against all of the searched fields to find matches. For example, I would like to be able to find an X509-Certificate in the bulk search by entering a subject, SHA-1, SHA-256, MD5, or SHA-512 hash.

@sweet-mentat sweet-mentat added bug use for describing something not working as expected needs triage use to identify issue needing triage from Filigran Product team labels Mar 30, 2024
@SamuelHassine SamuelHassine added this to the Release 6.0.9 milestone Mar 30, 2024
@jborozco
Copy link
Member

jborozco commented Apr 2, 2024

Can be reproduced in testing environment with the Hash a5c122f81de51acb8f7f7943cf3102833ac36a3f

image

@jborozco jborozco removed the needs triage use to identify issue needing triage from Filigran Product team label Apr 2, 2024
@marieflorescontact marieflorescontact self-assigned this Apr 2, 2024
@sweet-mentat
Copy link
Author

Thank you for adding to the Release. While I used the X509-Certificate object as an example, there are many objects that fall into this problem. Is the plan to fix it for just the X509-Certificate object, or for all objects?

@SamuelHassine SamuelHassine modified the milestones: Release 6.0.9, Release 6.0.10 Apr 3, 2024
@SamuelHassine SamuelHassine added the solved use to identify issue that has been solved (must be linked to the solving PR) label Apr 3, 2024
@SamuelHassine SamuelHassine modified the milestones: Release 6.0.10, Release 6.0.9 Apr 3, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug use for describing something not working as expected solved use to identify issue that has been solved (must be linked to the solving PR)
Projects
None yet
Development

No branches or pull requests

4 participants