Use cases
The framework supports some options for configuring the scope against which the chosen siddhi will run. Below are the main options.
Before that, a note: Vimana is not a portscanner, so the best option, especially when the number of targets is very large, is always to scan with nmap by exporting the result to XML, which will be passed as an argument for Vimana via the --nmap-xml <nmap_results.xml> option:
python3 vimana.py run --module dmt --nmap-xml scan_result.xml
An example of nmap's XML scope configuration is shown below, in the item Multi-Target(--nmap-xml option)
One-Shot-Target (--target option)
Well, imagine that you are conducting an intrusion test and in the midst of all the uproar you end up finding a target in which no vulnerabilities were pointed out, but even so, as a good sniper, it left you a little smell[ing?] a rat.
Suppose it is an internal analysis and the IP is 192.168.0.102 and that, in addition to the known service ports, port 8000 active on that IP has also been identified. In the case of the internal testing context, the pentester will already have some information regarding the technologies used by the developers and this will allow you to infer which siddhis can be used against the target.
So we already know the IP in advance and also that the port we want to evaluate is active, we can then run Vimana as follows:
python3 vimana.py run --module dmt --target 192.168.0.102 --port 8000 --verbose --debug
If there is nothing that can be done by the siddhi, an informational message about it will be displayed. If any, the initial panel will be presented with some information about the target, as below:
Multi-Target (--target-list option)
In another scenario, you have some IPs and ports to check:
python3 vimana.py run --module dmt --target-list 192.168.0.1,172.18.0.1,192.168.1.119 --port-list 8000,9999,9001
Multi-Target (--nmap-xml option)
Now imagine a scenario where you have entire ranges to analyze and you don't know the hosts ups or the open ports in each one beforehand. In this case, the best approach is to perform a scan with nmap and pass only the result in XML to Vimana. This point is important, because as already mentioned in the repository, it is important to know where each tool comes in and Vimana does not intend to be a port or vulnerability scanner, so whenever the scope is undefined and there are integer ranges for sweeping, this is always the best option:
python3 vimana.py run --module dmt --nmap-xml nmap_results.xml
Other scoping options
In addition to the above options, vimana also supports other options for scoping:
Before demonstrating a use case focused on Django applications, it is necessary to be very clear from which perspective this tool was developed and what its possibilities are.
From a developer's perspective, an exception, a warning, any error is an obstacle to be overcome in order for your application to rise and run with stability. However, from an attacker's perspective, a rupture event, with or without error messages (as in the case of a SQLi Error Based and a Blind, XXE, SSTI, and so on) is always something to be investigated better. This is because over time it is learned that many Hanging Fruits arise from the investigation of these scenarios, which can often allow the target to be completely compromised.
One of the first steps of an intrusion test is the fingerprint of the active infrastructure, application, technologies, services and ports. Thus, the discovery stage is crucial, especially in a blackbox approach.
One of the tests performed in this step is the enumeration of directories, endpoints and URLs of the application. A characteristic of this type of test is the high number of requests that the tools need to send to the server in order to analyze the response for each attempt in order to identify or at least infer whether a particular directory / URL exists.
In the present context, in a Django application with DEBUG true, a plugin such as DMT (Django Misconfiguration Tracker) identifies with a single request which are the root URL Patterns of the application:
And from there it performs the mapping through NoReverseMatch and
"expanding" these initial patterns to identify new URLs and data input endpoints under user control.
In this step, if the vimana module was executed with the debug option, some extra information is presented during the analysis, as in the case below where djmimic tries to reproduce the urls.py file for each identified application:
After this mapping, the DMT then invokes the application fuzzer, DJunch scoping the URLs initially identified. From this, the fuzzer will create a new scope with data of random types performing random tests alternating data types, directories, files and headers to identify exceptions:
Example of an exception identified by DJunch:
In addition, the code snippets for each module involved in the traceback are reassembled for further analysis with identification of the triggers of each module and the objects and local variables, in some cases. Once these sections are loaded in the tool, manual and SAST code review can be performed (in future releases), in addition to the identification of vulnerable modules and libraries and mapping of the application logic:
The last section of the presentation of a real-time exception is the Django application environment, the collections made in these fields and in the source code, can contain a lot of important information such as hardcoded passwords in the code, plain text passwords in environment variables, tokens , api keys, usernames, IPs, emails, URL hooks and so on. This information will later be analyzed and correlated by the abduct command (still under development), which will be responsible for crossing the information of an analysis and providing a scenario with possible attack vectors:
Exceptions already identified with the same triggers are only counted in the occurrences of the item in question, as below:
In addition, configuration issues [that are not dependent on DEBUG true] are also identified:
There are still situations where the server's response, even without exception, can allow us to infer that there was an internal error:
List of traceback objects:
In the future this can serve to guide attacks where it is necessary to have a sense of where a particular object of a triggered exception was allocated on the server.
If the analysis was carried out successfully, Vimana will enter the issues consolidation screen (if the identified exceptions are listed in this Python exceptions hierarchical tree, they will be highlighted in red, in the present case there is no highlight because only their own exceptions were identified of Django):
Once the result collected by the chosen siddhi and the siddhis invoked by during the analysis has been successfully executed, they will be consolidated in a report for presentation via terminal. The sections of this report can be used interactively at the final prompt. Here is an example of what an analysis report looks like in this version:
Environment variables separated by category and overview of issues identified from the siddhi analysis and the version of the Framework:
Exceptions identified detailing the number of environment variables, local variables, lines, number of occurrences, issues references and associated vulnerabilities:
Configuration issues:
As has been said, from the fuzzer identification of Django's version (DJunch invoked by DMT), other siddhis are called to look for security tickets:
And also by CVEs:
The next step is to interact with the issues identified by the plugins during the analysis: Interaction with issues