search

RUB-NDS / BurpSSOExtension

An extension for BurpSuite that highlights SSO messages in Burp's proxy window..
Other
117 stars 43 forks source link

Help with understanding attack wrapper interface #2

Closed garthoid closed 6 years ago

garthoid commented 8 years ago

I am trying to get my head around the intent of the attacker interface. I have read Tim Guenther's Thesis. Specifically the choosing of an attack vector for signature wrapping: is the intent to attempt an attack for each vector? This seems awkward as there could be hundreds. Also, I notice that the oracle increments the attack could after each attempt even though I have not modified the payload, perhaps this is because the payload is now permanently modified.

Tim-Conrad commented 8 years ago

The intent of the attacker interface was to semi-automate the signature wrapping attacks.

Each attack vector is meant to be tested on its own (or in combination) against the target. There is no option (maybe you would like to fork it and automate this process) to automatically apply all vectors at once or in a row.

I can understand that, this is not the best solution (especially the GUI). But the interface was design to speed up manual testing, with allot of knowledge of the available attack vectors.

CheariX commented 8 years ago

Unfortunetely, it is not easy to improve this workflow. On a quick peek, for example, it sound reasonable to add XSW functionality to the repeater tab. This will result in false-positives, if the SP checks the "inResponseTo" attribute. For real SAML tests, you have to simulate a full login flow (e.g. with Selenium). It would be really nice to have this in ESpReSSO, but up to now, there are no plans :(

garthoid commented 8 years ago

In our case a post request with a SAML body will result in a 500 internal server HTTP error code in a negative situation. The point of an Intruder like interface leaves it up to the human to decide of the response is negative or positive. As per one of your diagrams I am simply looking for the response once the IDP has been issued to the content provider. Each iteration in the interface would modify the original request, sort automatically generating each request in the slider bar. However I am sure this will perhaps not work for all use cases.

On 22 December 2015 at 03:30, CheariX notifications@github.com wrote:

Unfortunetely, it is not easy to improve this workflow. On a quick peek, for example, it sound reasonable to add XSW functionality to the repeater tab. This will result in false-positives, if the SP checks the "inResponseTo" attribute. For real SAML tests, you have to simulate a full login flow (e.g. with Selenium). It would be really nice to have this in ESpReSSO, but up to now, there are no plans :(

— Reply to this email directly or view it on GitHub https://github.com/RUB-NDS/BurpSSOExtension/issues/2#issuecomment-166552650 .

garthoid commented 8 years ago

Another interface question. The oracle does not generate any vectors until content in the "Configure Payload:" window has been modified. This is not the impression I got from page 14 of the thesis. Is what I am seeing correct and if so why is modification required by the oracle?

On 22 December 2015 at 10:39, garthoid garthoid@gmail.com wrote:

In our case a post request with a SAML body will result in a 500 internal server HTTP error code in a negative situation. The point of an Intruder like interface leaves it up to the human to decide of the response is negative or positive. As per one of your diagrams I am simply looking for the response once the IDP has been issued to the content provider. Each iteration in the interface would modify the original request, sort automatically generating each request in the slider bar. However I am sure this will perhaps not work for all use cases.

On 22 December 2015 at 03:30, CheariX notifications@github.com wrote:

Unfortunetely, it is not easy to improve this workflow. On a quick peek, for example, it sound reasonable to add XSW functionality to the repeater tab. This will result in false-positives, if the SP checks the "inResponseTo" attribute. For real SAML tests, you have to simulate a full login flow (e.g. with Selenium). It would be really nice to have this in ESpReSSO, but up to now, there are no plans :(

— Reply to this email directly or view it on GitHub https://github.com/RUB-NDS/BurpSSOExtension/issues/2#issuecomment-166552650 .

CheariX commented 8 years ago

This is a legacy behavior of the underlying XSW library. If no payload is configured, Signature Wrapping does not make much sense - you simply need a modification.