Vega Scanner
When you start Vega for the first time, you will be in the scanner perspective. Vega has two perspectives: The scanner, and the proxy. We'll start the introduction with the scanner. The Vega scanner is an automated security testing tool that crawls a website, analyzing page content to find links and form parameters. Vega finds injection points, referred to as path state nodes, and runs modules written in Javascript to analyze them. Vega also runs Javascript modules on all responses sent back from the server during the scan.
The screenshot above shows the complete Vega scanner perspective. The parts that comprise it, such as "Website View", "Scan Info", etc., are moveable. To restore to the original layout, click on the "Window" menu item and select "Reset Perspective". This will reassemble the UI parts into this arrangement. This does not affect the data or operation of any current scan.
Vega stores information about the current and past scans in a "workspace". Clearing the workspace will remove all scan data, including alerts and saved requests/responses. To do so, select the "File" menu item and click on "Reset Current Workspace".
Vega scans websites recursively, building an internal representation of the site in a tree-like data structure comprised of entities known as "path state nodes". Path state nodes can be directories, files, or files with POST or GET parameters. Complex websites can result in long scans and large path state data structures, so Vega offers configurable parameters that limit the scan scope in the scanner preferences. To access these parameters, click on the Window menu item and choose "Preferences". There are two sets of preferences associated with the scanner: Scanner preferences and Scanner debugging. Select Scanner debugging.
The scan limits are set in the scanner preferences. These include the following parameters:
-
Total number of path descendants
This is the total children of a node + all its children. Children of a path state node could be its subdirectories, or its parameters, with one node for each in a set of parameters.
-
Total number of child paths for a single node
Limits on the number of children per node (subdirectories + files + parameters).
-
Maximum path depth
The limit on the heirarchy of path state nodes (e.g. /level1/level2/level3/level4..)
-
Maximum number of duplicate path elements The maximum number of permitted duplicate, adjacent path nodes. For example: /images/images/images.
-
Maximum length of strings to display in alert reports
The alerts can include text from the module, such as the response body. The level of permitted module verbosity can be configured here by the user.
-
Maximum number of requests to send per second
This setting regulates the speed at which Vega scans.
The scanner debugging preferences contain settings intended for use during module development or debugging.
-
Log all scanner requests
By default, Vega only saves the requests and responses that generate alerts within its database. Enabling this will result in all requests and responses being saved. They will be accessible from the message viewer.
-
Display debug output in console Enabling this will cause Vega to output verbose logging to the console.
To start a scan, click the new scan icon at the top left corner. Alternatively, you can select the "Scan" menu bar item and click on "Start new Scan".
This will cause the New Scan wizard to open.
The user can either supply a base URI As the target, or edit a target scope. Target scopes allow multiple base URIs and exclusions that will not be scanned by Vega. Another way to add or remove resources from a target path is via the web view.
For this tutorial, we will just enter a base URI. Clicking next will advance to the next wizard page.
Modules are units of extended functionality written in Javascript (the Vega engine is written in Java, but includes the Rhino JS interpreter). Vega supports two kinds of modules:
Basic Modules
These run on path state nodes and perform active fuzzing, including:
URIs that are known to be files or directories
URIs with parameters, with each parameter being a distinct path state node
Response Processing Modules
These run on all responses that are returned from the server. They can be considered "grep" modules.
Both types of modules can store information in the shared knowledge base and generate XML-based alerts.
Remember: experiment with Vega on servers that belong to you and are not in production use.
Vega supports the configuration of credentials for performing automated scans while authenticated to the application or server. These credentials include:
- Basic HTTP
- Digest HTTP
- NTLM
- Macro (form based authentication)
Credentials must be configured using Identities. The Vega Identities feature has its own Wiki page. There is also a short video tutorial here: http://www.youtube.com/watch?v=Yw2UbKivkgQ.
Vega also permits the configuration of cookies that will be sent with all scanner requests. These can be added individually through the Wizard UI.
Vega will start crawling the target web application. Vega sends many requests. This is because in addition to analyzing the page content, the crawling engine does several tests on each potential path, trying to determine if it is a file or a directory. Vega also compares pages to each other, and tries to figure out what the 404 page looks like. Vega modules also send their own requests.
The scan progress will be indicated with a progress bar. Note that the total number of links to crawl will grow as Vega discovers new ones and generates variations to perform the above described tests, so the finish time will be a moving target. The preferences described at the start of this tutorial control the parameters that limit scope of the scan.
To stop an active scan, click the red icon with an "x" next to the new scan button.
Vega will build a list in the top right corner of the paths crawled and seen. The greyed-out paths are those that that have not been accessed. Vega will not crawl links on other websites.
As the scan progresses, instances of alerts will appear in the summary box shown in the previous screenshot. The alerts that correspond to each instance can be found in the box to the lower right.
Opening up the scan results will reveal a tree of alerts, with severity at the highest level, followed by type, and then path instance. Both current and previous scan results for the workspace are listed. The target icon representing the current scan will be blinking until it is finished.
Clicking on an alert will open it in the central pane. To return to the scan summary, click on the top-level item in the alerts tree in the Scan Alerts view, in the bottom right corner.
The alert incorporates both dynamic content from the module and static content from a corresponding XML file. One great feature about alerts is the link to the saved request and response. To slide open a fastview with the message editor, click on the request link towards the bottom of the alert.
Clicking a request link like the one shown above will pop open the message viewer, with the associated request and response already selected:
Here the details of the request and response can be viewed. The request can also be replayed by right clicking it in the request list just above the message content boxes. Doing this will open up the request editor, which is documented more extensively in the proxy tutorial.
Another way to get to the request viewer is to click on the icon in the status bar, in the bottom left corner. This will open up the fast view in a manner similar to when the request link is clicked on in an alert. There is also a fastview link to the console, which blinks when there is error output that has not been seen.
Continue to the next user guide: Using the Vega Proxy (pt. 2 of 4)
Have feedback on Vega? Our documentation? Please tell us.