Ambaga created a CTF around the old island.is login that uses the Security Assertion Markup Language. SAML is an open standard for exchanging authorization and authentication information. The Web Browser SAML/SSO Profile with Redirect/POST bindings is one of the most common SSO implementation.
Ambaga provides hints on their blog , which I definitely used because a lot of times hacking is gathering intel before you start and during, but you could always try tackling it blind if you want the added challange. The CTF also gives you some initial information to work with, like user details (more on that on the challenge website). As well as source code so if you can read code you should be able to spot the vulnerability.
As a long-time software tester, I’ve often spotted potential security risks but handed them off to the security team for deeper investigation. I lacked the tools and knowledge to explore them myself. But with some guidance, courses, and challenges like this one, it’s great to finally act on my hunches. If you’re like me and learn best by doing, this CTF is right up your alley. You can find my solution in following posts as I solve them.
Tools I use
Burpsuite
Burp Suite is a powerful and popular software platform used for performing security testing of web applications. It’s essentially a toolkit that helps security professionals and penetration testers identify vulnerabilities and weaknesses in web applications.
The community edition is free and you can get it at portswigger.net
To learn how to use the tool I recommend portswigger academy where you get to practice using the tool on known vulnerabilities in a safe environment.
Python
I had problems with base64 encoding and decoding for some reason so I used python scrips I made myself and can be found on my github.
LLM
I used Gemini and ChatGPT to help me out but mostly just with syntax and such. To be clear it sometimes would want me to try other vulnerabilities but I was pretty sure which one it was so I would dig into it and I got more right then the LLM so remember LLM is a tool not a security expert. LLM is basically guessing but can be really helpful when you don’t know the programing language, technology or syntax to help to learn it but some things it says is nonsense…
Glossary
During this CTF I learned new things and documented it here. Feel free to use it to help you out.
SAML
Security Assertion Markup Language is an open standard for exchanging authentication and authorization data between parties. Basically it is a XML format that contains a signature that changes based on the content of the XML and the public key used to encrypt it that has been base64 encoded. Note though that the signature is made before hand and then added to the XML, so anything in the <signature> is not part of what is encrypted.
When a user tries to access a service, the service redirects them to an identity provider (IdP) for authentication. Upon successful authentication, the IdP issues a SAML token containing user information and permissions. This token is digitally signed to ensure its integrity and authenticity.
SAML Tokens: When a user tries to access a service, the service redirects them to an identity provider (IdP) for authentication. Upon successful authentication, the IdP issues a SAML token containing user information and permissions. This token is digitally signed to ensure its integrity and authenticity.
Reference URI: In the context of XML signatures (such as those used in SAML), a Reference URI is an attribute that identifies the specific part of the XML document being signed. It is part of the element within the section of an XML signature. The Reference URI points to the data that is included in the signature, ensuring the integrity and authenticity of that specific portion of the document. So for example the <Signature> will include a Reference URI and somewhere in the xml you will find an element with the same id So it <Response ID=”_1234″>…</Response>. Everything in response is what is encrypted using the signing.
Vulnerabilities
I have hidden the information on the vulnerabilities so not to spoil for those that want to complete the challenge as the challenge uses these vulnerabilities put they are here for your viewing pleasure should you so choose.
👀 Show me the vulnerabilities 👀
Signature Not Verified (SNV): The vulnerability arises when a service provider (SP) fails to properly verify the digital signature of the SAML token. This can allow attackers to forge or manipulate tokens, potentially gaining unauthorized access to the service. For example you might just remove the <Signature>...</Signature> from the XML and then change the XML as you see fit. While the vulnerability is most commonly associated with SAML, it can indeed affect other types of tokens as well.
Signature Wrapping (SW): Signature Wrapping is a sneaky attack where hackers mess with the structure of a digitally signed message (like a SAML token) without breaking the signature itself. This lets them change what the message means, potentially causing chaos like unauthorized access or data manipulation. It’s like forging a document but keeping the original signature – the recipient thinks it’s legit, but the content has been tampered with. For example you might move the <Signature> tag to the top of the XML instead of the bottom, as we know we often read things from top do bottom and so do computers. If we were to add something in the signature for example a username while still keeping everything else in the XML the same it will read that as the first username it sees and if it validates the <Signature> it is still valid since we didn’t change anything outside the<Signature> tag.
Self-Signed Token Vulnerability (SSTV): This vulnerability occurs when a service provider trusts a certificate that is embedded within the SAML token itself. Instead of verifying the signature with a pre-configured, trusted public key, it mistakenly uses the key provided by the potential attacker. This is like a bouncer letting someone into a club because their ID says they’re old enough, without checking if the ID itself is a real government-issued one or a convincing fake the person printed at home. For example, an attacker can generate their own signing key and a fake certificate that mimics the details of a real one. They then modify a token to make themselves an admin and sign it with their key. When the server receives the token, it extracts the attacker’s fake certificate, sees the familiar details, and uses it to validate the signature, wrongly granting the attacker admin privileges.