Vault7: CIA Hacking Tools Revealed
Navigation: » Latest version
Owner: User #71494
Caterpillar ICE Command-Line Parser Notes, Plans, Etc.
Task Description
The ICEIn-memory Code Execution spec outlines the ability to pass command line arguments into the tool being kicked off by ICE. Caterpillar uses a config file burned in at deployment time via Builderpillar.py. The Operators would like the ability to use the command line arguments specified in the Builderpillar documentation to override portions of the burned-in configuration.
Commands That Need to Be Implemented:
- chunksize
- collect
- id
- ip
- kill
- mtu
- max
- port
- rate
- redundancy
- state
New Commands To Be Created:
- uncollect - give the operators the opportunity to remove a GLOB specified in the config from collection
My Questions:
- Are Caterpillar ID numbers stored programmatically somewhere or is there a magic spreadsheet with the operators somewhere? Implementation of the "ID" command allows the reassignment of the ID at runtime. A poor selection could mean two broken deployments. Should we consider a small base-end tool to track what ID's go with which deployment of Caterpillar and provide new, generated, ID's from that tool for the operators?
- Do we disallow ID to be overridden at run-time, and force ID to be selected pre-deployment?
- Is Caterpillar always invoked by ICEIn-memory Code Execution or can it restart autonomously? I see that it keeps a state file to resume exfiltration if it is interrupted during execution, but does it restart itself or is it dependent on ICEIn-memory Code Execution to start it back up? I need to know if I can count on the command line options to always be there for config-overriding reasons or if I will need to store the overrides off somewhere persistent and call them back up when Caterpillar starts back up.
Implementation Plans:
Three major components will need to be created to make this effort function:
- A command line option parser and validation function
- I'm thinking this will be a user-input specific class added to CatLib, the main part of Caterpillar. The validation/parsing method will need to be invoked by both CatICE (required) and CatEXE (to make my testing life easier). The parsing method will create structure to hold the new configuration information, and allow the entry points to return failure codes to the callers if the user inputs malformed or out of bounds command line options
- A function to take the command line options and change the burned in config
- Also added into CatLib. Probably an extension to CaterpillarConfig to take the structure defined by the input parser and update the config that's been burned in.