Idea: Sending a sample to another viper instance

[jaegeral]

Idea: Similar to the cuckoo module sending a sample to another viper instance providing the same tags.

Mockup: def usage(): print("usage: viper_remote [-H=host] [-p=port] -tags=tag1,tag2,tag3") def help(): usage() print("") print("Options:") print("\t--help (-h)\tShow this help message") print("\t--host (-H)\tSpecify an host (default: localhost)") print("\t--port (-p)\tSpecify a port (default: 8080") print("\t--tags (-t)\tSpecify tags (default: keep tags") print("")

example: viper_remote -H 1.2.3.4 -p 8080

What do you guys think about it?

[botherder]

Well, using the REST API server a curl command will be sufficient to do this.

[jaegeral]

yes and no, I end up in havong several Viper instances 1) central repo to store all samples, clean taging etc 2) shared viper instance with "friends" 3) working viper with only the current relevant samples (e.g. using Viper in Remnux)

So I could think about several usecases 1) push sample from viper to viper 2) pull sample from remote viper to local

It is not a big thing to implement so I can give it a shot...

[botherder]

Any update on this?

[jaegeral]

I have started with a mockup but I guess this is more for 1.3

[morallo]

Hi! I am also interested in a collaborative/team shared version of viper. In my team we use git+github a lot for collaboration, and the workflow described by @deralexxx sounds a lot like a distributed VCS, except for the type of data shared.

After some research, I think a backend based on text files (JSON, YAML, even CSV) would be a good option for using git or other DCVS as a sync method. The git operations could be done externally by the user (like it's done now when copying whole folders), or maybe eventually integrated into viper (wrapping git remotes into "viper remotes").

Do you see any big downsides of changing SQLite for text-based files?

The part I have less clear is the syncing of malware samples. I think you could use git itself, maybe with a submodule for the binary files. Since the binaries shouldn't be changed often, git's difficulties with binary files should be irrelevant (diffing, merging, space penalty). However, a solution like https://git-annex.branchable.com/ could be considered.

What do you think? Does it make sense?

[botherder]

I guess it does. I like the idea of integrating git, but there are complications on how to handle projects for example.

Replacing SQLite with text files is also something that should be evaluated before doing any serious restructuring.

[morallo]

I don't really know viper internals, but for handling different projects, maybe just use a directory tree to organize different YAML files for different projects and samples?

[botherder]

We should probably fork this issue into a different one.

[frennkie]

Currently the Databases use basic auto increment integer as IDs. If we have multiple Databases (e.g. local and remote) having information about the same things (Malware, Tags...) Then switching the IDs to UUIDs might be a good idea so that a tag could have the same id over all places it's used.

The general Idee here could be implemented with not too effort as a pull from a remote Rest API. So there would be two tasks:

• [ ] Make sure API provides access to all required data
• [ ] Implement pull command in database.py and add command to console.

The most basic Identifier for the pull to start off with would be Project + SHA256, right?

[Rafiot]

Soo, I have a question there: if we want to start sharing samples between viper instances, why not using MISP and not reimplementing all that very complex part in viper?

The sharing bit is very complex and I'm not sure we want to go that way.

FYI, we are about to have objects in MISP (it is the next big functionality, within a month now), so it will be possible to represent everything viper has stored internally directly on MISP without requiring any heavy changes in the backed of viper.

[frennkie]

Yes, I already thought about concern too. Although MISP "only" shares the Meta Information and not the files/binaries/samples themselves, right?

I'm completely fine if this issues is closed because it's not in scope of what Viper is intended to do.

[cvandeplas]

You can upload/download samples using the misp upload and misp download commands,

viper > misp download -h
usage: misp download [-h] [-e EVENT | -l [LIST [LIST ...]] | --hash HASH]

optional arguments:
  -h, --help            show this help message and exit
  -e EVENT, --event EVENT
                        Download all the samples related to this event ID.
  -l [LIST [LIST ...]], --list [LIST [LIST ...]]
                        Download all the samples related to a list of events.
                        Empty list to download all the samples of all the
                        events stored in the current project.
  --hash HASH           Download the sample related to this hash (only MD5).

[frennkie]

Sorry, I hadn't looked into the MISP module until now.. IMHO this is really a good solution for this scenario. What do you think @deralexxx ?

Btw: This issue/idea is older than the addition of the MISP module to Viper...

[Rafiot]

Absolutely, and it may make sense to have a way to share samples between viper instances, I just want to make clear it is a complex issue :)