Issues, ToDo & DoNot

I - Issues

Property Sets, Transforms & Categorization

• If a dynamic property is used as the Entity's value, its display_name in the properties list appears as Temp
• Because Maltego entities might have different sets of dynamic properties for representing Metasploit objects, the transforms that are available to these entities are not filtered adequately, which is a problem when, for example, raw groups of entities lack some properties needed by the transform to run correctly. This is due to representing Metasploit entities in the form of property sets.

API Issues, Python code bugs, etc...

• Python treats integers of value 0 as being None in a weird way: when querying the value from the dict received via API call, a 0 is printed. However, and despite this 0 is assigned to a Maltego Host as a property, the query of this property will yield a "None" response.

Persistence of Builtin Maltego Entities adjustments

• When a Maltego builtin Entity is redefined/overloaded in the Python code, AND that its display settings are modified in the Maltego client (for multiple icons management, between others), the following issue appears:
  • If doing a Factory Reset, and despite exporting the concerned builtin Entities, when importing them again, overloaded properties will remain present (they are imported with the .mtz entity file) but all advanced display settings will disappear.

This is not a huge problem if there are only 1 or 2 builtin entities that overloaded, but if this number grows it will become cumbersome...

Random bugs in Maltego client's Entity hierarchy

• Sometimes, maybe because of an inconsistent Profile or Entity file being imported, Maltego Client does not infer the right hierarchy of Entities, so that transforms are not available to all expected entities (between other problems).

II - Todo

Naming

• Almost all entity fields are just Field() classes. Wherever possible, replace them with more precise types such as EnumEntityField(), or more important, StringEntityField().

Entity Merging

• When a Metasploit workspace has the same host under several IPs, it automatically switches its services if they have been discovered for the new IP. However there is an issue when retrieving them in Maltego, because each host will be considered a different one and two Host entities will appear. When the Host Entity will retrieve the services, an error will raise that there are no services. The issue also appears when both Host Entities are merged into one, because one IP will override the other, as well as the Host ID. Therefore the remaining entity cannot retrieve the services assigned under the other IP in Metasploit

Entity Appearance

• THE BIGGEST TODO EVER would be a damn long list of Operating Systems, Services, Programs and their appropriate 48x48 icon. A clear way to integrate such a list should be devised, so this list can be leveraged as an Entity 'reservoir'.
• At the moment, there is one common base class for all hosts: MetasploitHost.
• Icon determination is not coded directly into Entities classes, in order to get more granularity in Icon choices. The OS Factory and Service Factory are the modules taking care of this.

Utilities

• Make a utility class for managing different Databases, with potentially a GUI that helps managing the Metasploit Web Service. Potentially not useful to go that far though...

MetasploitCredential

• Finish Pull/Push Credential transforms: For the Push, needs to implement the full dictionary required by the API. It is not exactly the same as one from GET requests, so it cannot be fetched-then-put this way.

To add

• Establish a manner to represent and process a Metasploit Note/Loot object in Maltego, while making it easy to reuse with other tools.

Config Files

• Currently, Effective-Couscous loads the config file local to the package (not the ~/.canari/canari.conf). It may be good to change this, or simply to add user-specific parameters in both config files, at install.

III - DO NOT

Confusing Python code Entity inheritance and Maltego code inheritance.

Python Entity definition class: Do not make an Entity class inherit from the class of an Entity higher hierarchically in Maltego, for the sake of saving a few lines of properties' code...

class MetasploitHost(Entity): _namespace = "foo.host"

  prop_one = StringEntityField("")
  prop_two = StringEntityField("")

class LinuxHost(MetasploitHost): namespace = "foo.host.MetasploitHost"

""" Using inheritance to get/set props on this Entity class """ ...And then accessing the values of LinuxHost() in transforms....

host = LinuxHost() host.name = "Foo" ... because: The way Canari looks up class properties, in this case, is ambiguous to the Maltego client (it considers the properties to be MetasploitHost's, not LinuxHost's ones) so it will mess everything up WITH HUNDREDS OF EXCEPTIONS AND A TOTALLY UNUSABLE MALTEGO CLIENT.