Unable to get findings with Vega

[pomil-1969]

I am using VEGA to perform penetration testing on an Angular web application. Before performing the test, I am manually scanning the application (after successfully setting up a proxy connection between my browser and VEGA) in order to collect the app urls I need to test, which among others, are REST back end calls to a secured Spring Boot application.

The back end calls require the presence of the request header 'Authorization: Bearer xxx', where xxx corresponds to a valid token, or else the server response will be '403 Unauthorized'.

After finishing the scanning, I am starting the scanning process. The application home page and the login page are being scanned as expected and I am getting some findings, but unfortunately all the other paths (which are the secured paths) are not scanned, since I do not receive any finding. I also try manually adding the required request header to every VEGA request, by configuring an Identity with "Macro" Authentication type and selecting the entry with the Authentication request header, but without any success.

Is this a bug of the application or am I missing something? Could somebody provide any insight on this?

[anneborcherding]

Have you checked the communication between VEGA and your application for example by using wireshark? Through analyzing the messages sent and recieved you might find out if the problem is caused by VEGA or by your application.

[pomil-1969]

I ran wireshark, but going through as many entries of the captured packages as possible in the first line I could not observe a communication problem between VEGA and our web application.

[anneborcherding]

Could you check if VEGA adds the correct header to the requests? And could you maybe check if the application answers with the 403 response codes as you have mentioned?

[pomil-1969]

VEGA seems to add the correct header to the requests. The application does not answer with 403 because the required request header is available. I do not think that this is a matter of the request header since it seems to be correctly added by VEGA. What else could I check?

[anneborcherding]

Thanks for checking! Is VEGA actually calling the secured paths during the test or is it maybe ignoring these URLs?

[pomil-1969]

While it seems to be collecting them while proxy scanning it seems to ignore them when running the scanner.

[anneborcherding]

Could you enter one of those paths as base URI to check if VEGA will use it in this case? Another possible check would be to add the paths to one scope and use this scope as target scope.

[pomil-1969]

While crawling such a base URI I get repeatedly following kind of Warnings in the console (VEGA log): (crawler) Network problem while retrieving URI http://xxx/api/secured/ [Connection reset] (scanner) Exception processing request: GET http://xxx/api/secured/ HTTP/1.1 : Connection reset

and in the Scan Info panel (right side): The request is: GET /api?page=e"%20or%201%20eq%201%20or%20"a"%20=%20"a&size=10&sort=id%2Casc

and the resource content:

[anneborcherding]

VEGA is not establishing a new connection after the old one has been closed? I remember seeing some of these warnings before without having any issues with it.

I don't know of a setting in VEGA to do so (whithout changeing the source code). Depending on how you run VEGA, you might consider using a (transpartent) proxy between VEGA and your target which will change the response to some other status code. Maybe mitmproxy might be a good start.

[pomil-1969]

I do not want to change the response. HTTP Status 400 is the right response. The question is if there is a way VEGA could ignore it and continue scanning?

[anneborcherding]

If you don't mind touching the source code, I would suggest just to suppress the corresponding exceptions if it is caused by an HTTP Status 400. For this, you would need to check how you could identify such an exception and then drop it. Warning: I have not tested this.

To suppress the crawler warnings, you could try suppressing the ExecutionException thrown in get(boolean readEntity) of HttpRequestTask.java that can be found in platform/com.subgraph.vega.http.requests/src/com/subgraph/vega/internal/http/requests.

To supress the warning from the scanner you could try suppressing the exception in notfiyScanException(..) of ScanInstance.java that can be found in platform/com.subgraph.vega.model/src/com/subgraph/vega/internal/model/alerts .

Again, I have not tested this, this is just a suggestion.