-
Notifications
You must be signed in to change notification settings - Fork 5
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.