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

File Observables with no Hash Create their own Hash #1069

Closed
securitiz opened this issue Feb 9, 2021 · 0 comments
Closed

File Observables with no Hash Create their own Hash #1069

securitiz opened this issue Feb 9, 2021 · 0 comments
Labels
feature use for describing a new feature to develop solved use to identify issue that has been solved (must be linked to the solving PR)
Milestone

Comments

@securitiz
Copy link

Description

When creating a file observable with no hashes (for example, with only the file name property filled in), OpenCTI hashes the filename itself and displays it as the hash of the file. This is a mistake, as the hash could be misconstrued to be the hash of the actual file.

Environment

  1. OS (where OpenCTI server runs): Ubuntu 20.04
  2. OpenCTI version: 4.1.1
  3. OpenCTI client: frontend
  4. Other environment details:

Reproducible Steps

Steps to create the smallest reproducible scenario:

  1. Create new File observable
  2. Set the observable's value to be "test.txt"
  3. Leave the hash values as empty
  4. Create object

Expected Output

A file observable is created, with empty hash values, and the object's name is "test.txt"

Actual Output

A file observable is created, with the MD5 hash value set to "dd18bf3a8e0a2a3e53e2661c7fb53534". This is the hash of the string "test.txt".

Additional information

@securitiz securitiz changed the title File Observables with no Hash File Observables with no Hash Create their own Hash Feb 9, 2021
@SamuelHassine SamuelHassine added bug use for describing something not working as expected feature use for describing a new feature to develop solved use to identify issue that has been solved (must be linked to the solving PR) and removed bug use for describing something not working as expected labels Feb 10, 2021
@SamuelHassine SamuelHassine added this to the Release 4.2.0 milestone Feb 10, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feature use for describing a new feature to develop 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

2 participants