Hi,

Can SAML requests embedded within JSON be detected?

I could also take a stab at it but where should I begin?

Excellent tool BTW.

Thank you

Make it possible to edit SAML Requests as well

Hey, sorry for the bad title
Essentially, the strings provided by Burp's deocder (after url and Base64 decoding) and Raider are different in that the raider XML parser has attempted to "fix" the document and has added elements such as

   <?xml version="1.0" encoding="UTF-8"?>

also it has rearranged the document's elements or the attributes of the elements
That makes raider fail to produce an acceptable request if the server implements schema validation or just expects it's own version of the xml document.

Here's also a test that will fail on the latest master branch

@Test
public void testXmlLoadsCorrectly() throws IOException, SAXException, ParserConfigurationException, TransformerException {
    String msg = messageSimpleSAMLphpWithSig;
    Document document = xmlHelpers.getXMLDocumentOfSAMLMessage(msg);

    String docString = xmlHelpers.getString(document);
    assertTrue(docString.trim().replaceAll("\\s+", "").equalsIgnoreCase(msg));
}

The problem is with ipsilon and free ipa

It seems the extension tries to find the DTD items in the request but it cannot parse it. As a result, when building an XXE attack, it complains and sometimes removes the XXE payload completely.

I think it should try not to parse the DTDs or when DTD is there, it can show an error that it is not going to parse it at all and convert it back to base64 as is.

This is a known bug in the Burp API. See Issue #2.

@RouLee said:
It was implemented with commit 6578eab. There is a bug in the burp API when using Content-Type: multipart/form-data; The parameter gets added but not removed.
The bug was reported to portswigger.

This issue will be closed if the Burp API is fixed.

I am working with an implementation that does not deflate before base64 encoding. It seems SAML raider does this as default, because of this it is causing all my requests to be interpreted as malformed. Is there a way to force SAML raider to not deflate?

I cannot click on "Raw" anymore in intercept, when i selected SAMLRaider tab:

Hello, just trivial issue,
SAML response not showing colored in my burp which make it hard to understand the assertion , in adddition the search is not working , SAML raider version 1.2.3 and i tried both burp 1.7.31 and 2020.4.
regarding java version tried 11 and 13

Hi all.

In the current state of the awesome SAMLRaider, it is not possible to remove signatures from an AuthnRequest, but it is not possible to re-sign them with a cloned certificate.

It would be super cool if you could implement this.

thanks

Hi.

I have noticed there is a limitation written to the tool:
"Bypassing XML signatures in non-SAML contexts, for example SOAP endpoints using WS-Security extensions."

I have encountered a situation I need to comply with this limitation...
Can you please direct me on how to develop/fix this limitation?

Thanks in advance,
Avi.

I'm facing the issue using SAMLRaider v1.4.1 with Burp Suite Professional v2022.3.9
The plugin doesn't work with signatures. I cannot import signatures, for example.
Button "Send Certificate to SAML Raider Certificates" does nothing.
This is the Burp Extender tab error output:

java.lang.NullPointerException: Cannot invoke "application.SamlTabController.isEnabled(byte[], boolean)" because "this.samlTabController" is null
at application.SAMLHighlighter.processHttpMessage(SAMLHighlighter.java:20)
at burp.hko.run(Unknown Source)
at java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:539)
at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1136)
at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635)
at java.base/java.lang.Thread.run(Thread.java:833)

Thanks in advance!

P.S.: Windows 10 x64, JRE 8.0.3330.2 x64

Trying to resign a SAMLResponse with a self-signed certificate clone but the signing takes forever:

When importing a traditional RSA PEM key, the following error is displayed:
Error (class org.bouncycastle.asn1.pkcs.PrivateKeyInfo cannot be cast to class org.bouncycastle.openssl.PEMKeyPair (org.bouncycastle.asn1.pkcs.PrivateKeyInfo and org.bouncycastle.openssl.PEMKeyPair are in unnamed module of loader burp.eb2 @361a5085))

Add new XSW10 attack.

This can e.g. be used to exploit CVE-2021-28091 (https://git.entrouvert.org/lasso.git/tree/NEWS?id=v2.7.0):

2.7.0 - June 1st 2021
----------------------
36 commits, 45 files changed, 1945 insertions, 177 deletions

* CVE-2021-28091: Fix signature checking on unsigned response with multiple assertions

  https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-28091

  When AuthnResponse messages are not signed (which is
  permitted by the specifiation), all assertion's signatures should be
  checked, but currently after the first signed assertion is checked all
  following assertions are accepted without checking their signature, and
  the last one is considered the main assertion.

  This patch :
  * check signatures from all assertions if the message is not signed,
  * refuse messages with assertion from different issuers than the one on
    the message, to prevent assertion bundling event if they are signed.

TODO:

• Add new XSW10 Attack (like XSW3 but evil assertion after the valid one; just switch the assertions).
• Create description and image
• Mention CVE number in description as an example

Would be useful to have ability to set customer parameter name to look for SAML ticket instead of defaults SAMLResponse/SAMLRequest.

Currently running Burp 2.0.19beta w/ openjdk on Ubuntu 16.10

SAML Raider seems to load fine and decode messages in the Proxy view. However the edit messages window doesn't allow entry of text. I can highlight text with my pointer and right click to "delete" and "copy/cut" but it doesn't actually edit the message before forwarding it on, or repeating the request in the repeater window. I have no errors in the extender tab.

I'm testing an instance of a nodejs app w/ passport-saml. Nothing crazy.

The main problem seems to be:

java.lang.RuntimeException: java.lang.NoSuchMethodError: com.sun.org.apache.xml.internal.serialize.OutputFormat.(Lorg/w3c/dom/Document;)V

Which renders SAMLRaider useless when using a newer JDK/JRE.

Some information:
http://openjdk.java.net/projects/jigsaw/talks/prepare-for-jdk9-j1-2016.pdf

Installed the SAML raider extension from BApp store, able to view only the SAML raider certificates tab...but unable to get a tab under proxy and repeater. Any specific configuration required?
SAML raider version 1.2.1
Burp suite version: 1.7.32

What if my target application is sending the SAML assertions base64 encoded?

The SAML Raider tab is not appearing, so I'm not able to modify any SAML assertion.

Any idea on how to solve this problem?

Thanks!

It's not possible to clone the certificate if the serial number of the certificate is negative.

First of all, thank you very much for this very useful extension!

I noticed a problem in the display of the assertion in the "SAML Raider" tab in the proxy when switching between requests with and without assertion info.
Here are the reproduction steps:

1. Select a request with SAML info, but without assertion info. Empty assertion panel, but that's expected.
   

2. Select a second request with SAML info, and with assertion info. We can see the info in the assertion panel and that's expected.
   

3. Go back to the first request (without assertion info). The assertion info from the request previously selected remains, which is problematic since there aren't supposed to be there. Expected: nothing displayed.
   

Do not hesitate to ask if you need more info!

The SAMLRaider request editor had the string "" when intercepting some WSS SAML requests. The stack trace was a RuntimeException: "com.sun.org.apache.xerces.internal.dom.DeferredTextImpl cannot be cast to org.w3c.dom.Element". I narrowed this down to:

XMHelpers.java - getSAMLResponseOfSOAP():

Element SAMLresponseOld = (Element) body.getFirstChild();

Note: For what it's worth maybe it'd be better to use a Node here instead of element, and then check to see if the Node is of the type you are expecting?

In this case though, the first element of the body is not a SAML element, because this is WSSE everything SAML related is in the SOAP header element. Working backward and reviewing SamlTabController.java leads to the isWSSMessage boolean which is only set to true in isSAMLMessage() and only if helpers.getRequestParameter(content, "wresult") is non-null. Searching around for where the wresult parameter is set leads to getMessage():

if (isWSSMessage) {
    parameterToUpdate = "wresult";
}

Unless I've missed something, it seems isWSSMessage is only set when the wresult parameter is set, and wresult is only set when isWSSMessage is set, a circular dependency.

Per the SAML specification, any exchanged SAML payload should be in a parameter named SAMLRequest or SAMLResponse. However, developers occasionally don't follow spec, and use a differently-named parameter. This makes attempting SAML attacks with SAMLRaider difficult.

It would be desirable to have a feature where the target parameter (or a list thereof) could be customized. That way, if an application is out-of-spec, the list of potential parameters could be modified accordingly.

When I intercept a SAML response, I can alter the XML in the "SAML Attacks" tab, but not the "SAML Message Info" tab's "Parsed & Prettified" XML.

In previous versions, I believe the XML was always prettified, and modifiable... that was much easier.

• Support for XXE testing
• "RAW" Mode (only Base64 encoding and decoding)
• Support for testing AuthRequests --> Testing the IdP
• create stand alone certificate cloner. --> keystore creator

Hi,

Love this extension! So here's the scenario: I've got a SAMLResponse that's being forwarded to target server, and I want to resign this response using my cloned certificate to see if the server actually validates the response. I use SAMLRaider to clone the certificate and that works well.

When using the "(Re-)Sign Message" the signature and certificate is removed from the request instead of replacing the existing signature, leaving me with a SAML response that has neither a certificate nor a signature. Running burp 1.7.23 on windows 10 x64, using the extension from bapp store.

See illustrations:

Before using the "(Re-)Sign Message" functionality:

After using it (sensitive fields in SAMLResponse grayed out):

In real-world cases, the SAMLResponse is often only valid for 10 seconds or similar. It would be nice to have a way to use the XSW attacks in an automated way. How do you test with short NotOnOrAfter times?

The full automation of a login and receiving the SAMLResponse is now easy due to the Stepper Burp extension. With Hackvertor we also have options to encode things dynamically. What would be really cool is if SAMLRaider would also support some kind of dynamic marker. I propose something similar to Hackvertor: If the SAMLRaider extension sees some tag (via looking at the traffic in the processHttpMessage Burp API) such as <_@_SAMLRaider_XSW1>PD94bWwgdmVyc2lvbj0iMS4w....Pg%3D%3D<_@/_SAMLRaider_XSW1>, it would take the passed base64 and apply the XSW1 transformation.

However, that's just an idea, I'm open to any suggestions how you test the XSW attacks with very short NotOnOrAfter times.

Hi!
I just noticed that your extension appends HTML encoded 'carriage return' (
) to each line of the SignatureValue and X509Certificate on resigning the SAML message.

<ds:SignatureValue>bG5rLy5HIxfdW/N1FxpbsGEnUB/grnl3+C4VbQr5VzhouRV5tbzHlcYfCB/IBe4OANtfDZNAKswi&#xd; Uphytc5Tzr4cj7H30Wqf/ZG5QaUqj7RHZQaXWPgTYmv4IgfyxkzBBeT44RlTO4lJYujPXpp5PMxQ&#xd; [...]</ds:SignatureValue>

I'm on Ubuntu 20.04 and use Burp Professional 2021.2 with OpenJDK (build 14.0.2+12-Ubuntu-120.04).
The same problem exists with OpenJDK 11.

Is anybody else having this issue?

I intercepted a SAML response and sent the certificate to the SAML Raider Certs, where I "Save and Self-Sign"-ed the cert.

Back on the SAML Raider tab, the self-signed cert was pre-selected. I clicked "(Re-)Sign Message", and get the message "Signing..." but it never actually re-signs the message. It's like the extension displays the message, but doesn't actually do anything.

BurpSuite isn't "hung" or anything; I can forward the request, but the request is not re-signed.

Implement https://github.com/pwntester/DupeKeyInjector in SAMLRaider, so only one tool is needed for testing SAML.

Recently, I have encountered a couple of SAML implementations where the service provider does not accept the output generated by SAMLRaider. I have tested this by making a change in the SAML Raider edit box, undoing that change, and submitting the request, which is rejected by the server. Resubmitting the original code works fine.

Closer inspection shows that this is caused by linebreaks that are inserted by SAMLRaider. It seems the first couple of linebreaks are accepted by the server, but in my case inserting a linebreak (manually, without using SAMLRaider) between ds:SignedInfo and <ds:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/> triggers an error at the server. This might well be a bug in the SAML implementation rather than in SAMLRaider, but nevertheless something that prevents testing with SAMLRaider.

One implementation that seems to suffer from this is Saml2-js.

Would it be possible to find a solution for this? If it is not possible to find the root cause, would it be possible to add a setting that disables adding the linebreaks?

Maybe something useful to implement?
https://duo.com/blog/duo-finds-saml-vulnerabilities-affecting-multiple-implementations

I think the format of certificate is right.When I selected the certificate and clicked Send Certificate to SAML Raider Certificates, error appeared

Hi

I was really keen to explore SAMLRaider but I got a bit nervy about using it because it appeared to be making changes beyond what I would have expected. I would intercept the HTTP request carrying the SAML response, delete a character, replace it and then send it on its way – thus I've made no overall change - but it would be rejected. When looking at the edited response the plugin had:

• stripped all the newlines out completely. As far as I understand it, canonicalization retains CRLFs (but ensures they are always 0x0a) so I assume therefore that any 0a byte is part of the input that’s digested.
• taken out the attribute xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion" from all elements that contained it (saml:Issuer, saml:Subject, saml:Condition, saml:AuthnStatement and saml:AttributeStatement). This presumably would change the digest of the assertion, assuming canonicalization retains the namespace attribute.

So in both cases the digest was being changed, thus invalidating the signature, hence the response . was rejected. Grateful for any comments.

Jerome

Further information:
https://en.wikipedia.org/wiki/WS-Security

I want to test all possible SAML attacks on a site. For this, i assumed the following workflow:

1. Send SAMLResponse login request to SAMLRaider
2. ???
3. Profit

Or, to be more exact:

1. Send SAMLResponse login request to SAMLRaider

2. Copy XML Signature
   2.1) Send cert to saml raider certs
   2.2) Clone cert / chain

3. Remove signatures
   3.1) Check if login still works

4. Re-Sign assertion
   4.1) Check if login still works

5. Re-sign message
   5.1) Check if login still works

6. XSW[1-8] attack
   6.0) Select XSW attack, click apply
   6.1) Check if login still works
   6.2) Reset message?

So my questions are:

• Does SAMLRaider work in Repeater, or do I have to intercept the SAMLResponse every time?
• Do i need to click "Reset message"? If yes, when? What does it do?
• Do the XSW attacks use the original SAML Assertion? If i have modified it (e.g. re-signed message, assertion etc.), do i have to reset the message? Is it taking the original message? The modified one? Which one makes more sense?
• Some XSW attacks are not working after I press "Apply XSW", e.g. "This XML Message is not suitable for this particular XSW attack". Is it possible to check the preconditions beforehand, and indicate in the XSW selection view which one's will work, and which one will not? (so i dont have to click through all of them)

Hello,

I'm trying to use your extension on Burp, however I am encountering some problems.. In particular, if I try to click on the "(Re-)Sign Assertion" button to generate a new signature for a SAML response, it does not work and the message info continues to say "Signing..." (see the attached screenshot). I've already tried to uninstall and reinstall the extension, but nothing changes.. Can you help me? Thanks.

image

When the SAMLResponse parameter for example is invalid (e.g. SAMLResponse=x), clicking on the SAML Raider tab freezes Burp and I need to close it and re-open it.

Since i am new on web app pentesting. Can you please explain in detail how i can edit an original SAML assertion captured by SAMLRaider on burp?
For example to check if I can login as another user with the edited assertion

On a presentation of yours I saw the example to manipulate the certificates etc but on the assertion editing part the details were missing.

Can you please explain, step by step, how can i edit the original assertion and then send it via burp?

I am trying XSW1 but the signature is turning out to be invalid after the transformation.

Turns out the SAML Raider is losing whitespace, and so the canonicalized output is different. Initial SignedInfo (generated by Shibboleth - notice that there is no indent, but newline after every element)

<ds:SignedInfo xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
<ds:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"></ds:CanonicalizationMethod>
<ds:SignatureMethod Algorithm="http://www.w3.org/2001/04/xmldsig-more#rsa-sha256"></ds:SignatureMethod>
<ds:Reference URI="#_a544335059b58b98d30e75524e09627c">
<ds:Transforms>
<ds:Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"></ds:Transform>
<ds:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"></ds:Transform>
</ds:Transforms>
<ds:DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256"></ds:DigestMethod>
<ds:DigestValue>t9htoNyes3QdccTS57Dp1QOO6oTz8MxON+QYqqgIF3I=</ds:DigestValue>
</ds:Reference>
</ds:SignedInfo>

SignedInfo after XSW1. (notice that all the newlines are gone)

<ds:SignedInfo xmlns:ds="http://www.w3.org/2000/09/xmldsig#"><ds:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"></ds:CanonicalizationMethod><ds:SignatureMethod Algorithm="http://www.w3.org/2001/04/xmldsig-more#rsa-sha256"></ds:SignatureMethod><ds:Reference URI="#_a544335059b58b98d30e75524e09627c"><ds:Transforms><ds:Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"></ds:Transform><ds:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"></ds:Transform></ds:Transforms><ds:DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256"></ds:DigestMethod><ds:DigestValue>t9htoNyes3QdccTS57Dp1QOO6oTz8MxON+QYqqgIF3I=</ds:DigestValue></ds:Reference></ds:SignedInfo>

Is there some option to preserve the whitespace?

I haven't found a pattern yet, but the "Parsed & Prettified" XML section of the "SAML Message Info" tab will be blank.

It doesn't appear to be anything wrong with the XML itself, and it seems random... I can click on the request and the Prettify will be blank. I click on some other request, and then come back to the first request and now the Prettify will be populated just fine. In other words, a given request will Prettify fine one time and not the next, or vice versa.

I think it would be a good idea to collect various SAML assertions in a central directory. These can be useful for testing our Burp Extension.

I propose a new folder examples on the top level. The files are named after the IdP.

For example the one from the Issue #1 could be stored as examples/salesforce.

What do you @RouLee think?

:)

Grz

Implement support for the Burp Intruder.

Running BurpSuite 2.0.16beta and just started getting "failureInInitialization" in the SAML Raider tab in the HTTP History > Request section.

The Extender > Extensions > Errors is spitting out:

java.lang.RuntimeException: java.lang.NoSuchMethodError: com.sun.org.apache.xml.internal.serialize.OutputFormat.(Lorg/w3c/dom/Document;)V

I've tried re-installing the Extension.

FWIW, running java -version on the BurpSuite Pro JRE gives me:
openjdk version "11.0.2" 2019-01-15

I just cloned the repo and tried to use the script:

me@arch{~/pen/tools/SAMLRaider/scripts/samltest}:./samltest 
[*] Listening for SAML Response on port 23523...
[*] Sending SAML Response...
-:1: parser error : Document is empty

^
-:1: parser error : Start tag expected, '<' not found

^

I also tried from Kali and got the same output + "this is not an option" on the awk line.
After that I gave up and used only curl instead:
curl -s --proxy 127.0.0.1:8080 --data saml_response "http://localhost:23523/"

The thing is I cannot do anything. I've tried this test script because I have this issue with all SAML response. It will switch to the SAML Raider tab when I get a SAMLResponse but I can't do anything:

Check if match/replace is applied globally

Since i added SAMLRaider to Burp 1.6 i get a Yo output on the console every other hour or so.
I couldn't find the string in the project itself, so i may be mistaken.
Screenshot related.

The popular SAML library SimpleSAMLphp had an auth bypass vuln in Nov 2019 here. This is a novel XSW attack that could be added into SAMLRaider functionality. I was able to manually replicate and exploit the vulnerability in a few vulnerable applications and can walkthrough the specifics. I don't know Java very well though - I'm a python developer. Maybe I can hack up some code and submit a PR to do this myself over Christmas break this year...