|
|
martes, 5 de mayo de 2020
October 2019 Connector
$$$ Bug Bounty $$$
What is Bug Bounty ?
A bug bounty program, also called a vulnerability rewards program (VRP), is a crowdsourcing initiative that rewards individuals for discovering and reporting software bugs. Bug bounty programs are often initiated to supplement internal code audits and penetration tests as part of an organization's vulnerability management strategy.
Many software vendors and websites run bug bounty programs, paying out cash rewards to software security researchers and white hat hackers who report software vulnerabilities that have the potential to be exploited. Bug reports must document enough information for for the organization offering the bounty to be able to reproduce the vulnerability. Typically, payment amounts are commensurate with the size of the organization, the difficulty in hacking the system and how much impact on users a bug might have.
Mozilla paid out a $3,000 flat rate bounty for bugs that fit its criteria, while Facebook has given out as much as $20,000 for a single bug report. Google paid Chrome operating system bug reporters a combined $700,000 in 2012 and Microsoft paid UK researcher James Forshaw $100,000 for an attack vulnerability in Windows 8.1. In 2016, Apple announced rewards that max out at $200,000 for a flaw in the iOS secure boot firmware components and up to $50,000 for execution of arbitrary code with kernel privileges or unauthorized iCloud access.
While the use of ethical hackers to find bugs can be very effective, such programs can also be controversial. To limit potential risk, some organizations are offering closed bug bounty programs that require an invitation. Apple, for example, has limited bug bounty participation to few dozen researchers.
A bug bounty program, also called a vulnerability rewards program (VRP), is a crowdsourcing initiative that rewards individuals for discovering and reporting software bugs. Bug bounty programs are often initiated to supplement internal code audits and penetration tests as part of an organization's vulnerability management strategy.
Many software vendors and websites run bug bounty programs, paying out cash rewards to software security researchers and white hat hackers who report software vulnerabilities that have the potential to be exploited. Bug reports must document enough information for for the organization offering the bounty to be able to reproduce the vulnerability. Typically, payment amounts are commensurate with the size of the organization, the difficulty in hacking the system and how much impact on users a bug might have.
Mozilla paid out a $3,000 flat rate bounty for bugs that fit its criteria, while Facebook has given out as much as $20,000 for a single bug report. Google paid Chrome operating system bug reporters a combined $700,000 in 2012 and Microsoft paid UK researcher James Forshaw $100,000 for an attack vulnerability in Windows 8.1. In 2016, Apple announced rewards that max out at $200,000 for a flaw in the iOS secure boot firmware components and up to $50,000 for execution of arbitrary code with kernel privileges or unauthorized iCloud access.
While the use of ethical hackers to find bugs can be very effective, such programs can also be controversial. To limit potential risk, some organizations are offering closed bug bounty programs that require an invitation. Apple, for example, has limited bug bounty participation to few dozen researchers.
Related word
viernes, 1 de mayo de 2020
Ten Ideas From Reiner Knizia About Playtesting
Reiner Knizia is one of the biggest names in game design around the world. The German game designer is a mathematician and has his name associated to more than 700 games launched in many different countries. I had the honor to talk personally to Knizia in 2011, at DIGRA's conference in Hilversun (Netherlands) and I watched a great keynote about the game designing process in the same event.
On that occasion, I gave Knizia my board game, YN, and had the opportunity to talk a little bit with him (a great achievement for my game designer career).
I follow Knizia in social media and I'm always taking notes about the knowledge on game design he shares on those platforms. In this post, I will reproduce 10 ideas Knizia showed recently on Twitter about playtesting (one of the most fundamental topics in the game designing process). Below, I listed the 10 points. Follow him by clicking here.
Playtesting 1. Those who do not play do not live. Those who do not playtest do not design.
Playtesting 2. Designs always work perfectly in your mind. The first playtest is the (often cruel) moment of truth.
Playtesting 3. Regardless of how much experience you have, you cannot develop a game on the drawing board – only at the playing table.
Playtesting 4. Game design is a classic iterative process of playing and improving – nowadays popularised as "design thinking".
Playtesting 5. When your playtesters do not like your design, (usually) your design is to blame – not your playtesters.
Playtesting 6. I recognise good playtesters by my (frequent) urge to strangle them.
Playtesting 7. For your design to appeal to one group, test with one group. For your design to have broad appeal, test with many groups.
Playtesting 8. You can make (most) designs interesting through your play-talk - but when published, your design needs to speak for itself.
Playtesting 9. Blind playtesting, without you taking part, is as useful as other people going on a rollercoaster and reporting their experience.
Playtesting 10. When you have playtested your design to perfection, let it rest some time, then play again. – Expect to be surprised!
#GoGamers
On that occasion, I gave Knizia my board game, YN, and had the opportunity to talk a little bit with him (a great achievement for my game designer career).
I follow Knizia in social media and I'm always taking notes about the knowledge on game design he shares on those platforms. In this post, I will reproduce 10 ideas Knizia showed recently on Twitter about playtesting (one of the most fundamental topics in the game designing process). Below, I listed the 10 points. Follow him by clicking here.
Playtesting 1. Those who do not play do not live. Those who do not playtest do not design.
Playtesting 2. Designs always work perfectly in your mind. The first playtest is the (often cruel) moment of truth.
Playtesting 3. Regardless of how much experience you have, you cannot develop a game on the drawing board – only at the playing table.
Playtesting 4. Game design is a classic iterative process of playing and improving – nowadays popularised as "design thinking".
Playtesting 5. When your playtesters do not like your design, (usually) your design is to blame – not your playtesters.
Playtesting 6. I recognise good playtesters by my (frequent) urge to strangle them.
Playtesting 7. For your design to appeal to one group, test with one group. For your design to have broad appeal, test with many groups.
Playtesting 8. You can make (most) designs interesting through your play-talk - but when published, your design needs to speak for itself.
Playtesting 9. Blind playtesting, without you taking part, is as useful as other people going on a rollercoaster and reporting their experience.
Playtesting 10. When you have playtested your design to perfection, let it rest some time, then play again. – Expect to be surprised!
#GoGamers
Curved Region Rendering
Around a month ago I had an idea in my head: a voronoi grid modified to have rounded cells that change in size. I made an attempt here for single cells changing size. The next step was to merge cells together, as I had done on this project. I decided that the way to demo this would be to simulate some kind of belief/cultural systems that spread over time across a map. I tried this here.
It didn't go well.
What happened? I think the problem was that I had three unknown elements in this project:
- Simulation with the simplest rendering code I could get away with. Figure out what simulation rules are interesting and cool.
- Rendering isolines on a triangle mesh.
- Rendering curved isolines on a triangle mesh, using Bezier curves.
In trying to figure out all three at once, I didn't do a good job on them. I should have instead focused on one at a time. I ended up succeeding with #2 when I learned about and implemented the Meandering Triangles algorithm, and also built a little interactive visualization that helped me understand how the algorithm works. I failed with #1, having tried several algorithms but not finding one that I liked. I realized towards the end of the week that #1 was a red herring; I didn't need a simulation at all, as I really just wanted curved regions. I also failed at #3, having tried some experiments but never finding what I wanted, and also rejecting Chaikin Curves for reasons I can't remember. Since I really wanted the curved variable sized regions, I should have spent more time on #3 and less on #1. I ran out of time on this project so I'll leave #1 and #3 for another day.
You can see the animation I ended up with.
What do I mean "I ran out of time"? That's the next blog post!
domingo, 26 de abril de 2020
Probing For XML Encryption Weaknesses In SAML With EsPReSSO
Security Assertion Markup Language (SAML) is an XML-based standard commonly used in Web Single Sign-On (SSO) [1]. In SAML, the confidentiality of transferred authentication statements against intermediaries can be provided using XML Encryption [2]. However, implementing XML Encryption in a secure way can be tricky and several attacks on XML Encryption have been identified in the past [3] [4]. Therefore, when auditing a SAML endpoint, one should always consider testing for vulnerabilities in the XML Encryption implementation.
This blog post introduces our latest addition to the SAML Attacker of our BurpSuite extension EsPReSSO: the Encryption Attack tab. The new tab allows for easy manipulation of the encrypted parts within intercepted SAML responses and can, therefore, be used to quickly assess whether the SAML endpoint is vulnerable against certain XML Encryption attacks.
Once a SAML response which contains an EncryptedAssertion has been intercepted, open the SAML tab, select the Attacks pane, and choose Encryption from the dropdown menu. This works in Burp's Proxy, as well as in the Repeater tool, and is depicted below.
The payload in the text area labeled XML data can now be entered. Any update in the XML data field will also be reflected in the hexadecimal representation of the payload (found on right of the XML data field). Note that this is automatically padded to the blocklength required by the symmetric algorithm selected below. However, the payload and the padding can be manually adjusted in the hex editor field.
Eventually, click the Encrypt content button to generate the encrypted payload. This will apply the changes to the intercepted SAML message, and the manipulated message using Burp's Forward or Go button can now be forwarded, as usual.
To determine whether or not a SAML endpoint is vulnerable to Bleichenbacher's Attack, we simply need to check if we can distinguish those responses received when submitting ciphertexts that are decrypted into invalidly formatted PKCS1 v1.5 plaintexts, from the responses we receive when sending ciphertexts that are decrypted into validly formatted plaintexts.
Recall that PKCS1 v1.5 mandates a certain format of the encrypted plaintext, namely a concatenation of a BlockType 00 02, a randomized PaddingString (PS) that includes no 00 bytes, a 00 (NULL-byte) as delimiter, and the actual plaintext message. The whole sequence should be equal in size to the modulus of the RSA key used. That is, given the byte length k of the RSA modulus and the message length |m|, PS has the length |PS| = k - 3 - |m|. Furthermore, PKCS1 v1.5 demands that |PS| to be at least eight bytes long [5].
In SAML, the recipient's public key is usually known because it is published in the metadata, or even included in the EncryptedAssertion. For this reason, we do not need to fiddle around with manipulated ciphertexts. Instead, we simply submit a validly formatted RSA-PKCS1 v1.5 encrypted message and an encrypted message which deciphers into an invalidly formatted plaintext. As an example, assume an RSA public key of 2048 bits which we want to use to encrypt a 16 byte session key `01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 10` (hexadecimal representation). |PS|$ is $2048/8 - 3 - 16 = 237, so a valid PKCS1 v1.5 plaintext, ready to be encrypted using `AA` for all 237 padding bytes, could look like the listing shown below.
00 02 AA AA AA AA AA AA AA AA AA AA AA AA AA AA
AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA
AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA
AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA
AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA
AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA
AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA
AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA
AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA
AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA
AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA
AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA
AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA
AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA
AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA 00
01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 10
Next, repeat the steps outlined above, but this time submit an invalid PKCS1 v1.5 message. For example, consider using an invalid BlockType of `12 34` instead of `00 02`, or replace the `00` delimiter so that the decryptor is unable to determine the actual message after decrypting the ciphertext. If you are able to determine from the recieved responses whether or not the submitted ciphertext decrypted into a valid PKCS1 v1.5 formatted plaintext, chances are high that the decryptor can be used as a Bleichenbacher oracle. Don't forget to take into account the actual XML data, i.e., the assertion encrypted with the new session key; by submitting valid or invalid XML, or by removing signatures from the SAML message or the assertion you may increase your chances of detecting differences in the returned responses.
In order to determine if a particular SAML service provider is vulnerable to this attack, we can avoid the cumbersome ciphertext manipulation, if we are in possession of the decryptor's public key:
In the Encryption Attacker tab of EsPReSSO, add the public key certificate to the Certificate field (if necessary) and insert a symmetric key of your own devising into the Symmetric Key text field. Select an appropriate RSA encryption method and click the Encrypt button to apply the new EncryptedKey element to the original SAML message.
An XML message can now be inserted into the XML data text field. Select a CBC mode encryption algorithm and click Encrypt to apply the changes. As in the example above, press Burp's Go or Forward button to send the message and carefully inspect the response. Try sending invalid XML, e.g., by not closing a tag or using the `&` character without a valid entity and keep an eye open for differences in the returned responses. To manipulate the padding, the text field on the right side shows the hexadecimal representation of the plaintext, including the CBC padding. If you send a single block and set the last byte, which indicates the padding length to the blocksize, i.e. 16 or 0x10 for AES, the ciphertext should decrypt into an empty string and is generally considered "valid" XML.
Please refer to the original paper for more details, tips, and tricks for performing the actual attack [3].
In case you wonder how XML Encryption can be used in a secure fashion, here are some considerations [6]:
This blog post introduces our latest addition to the SAML Attacker of our BurpSuite extension EsPReSSO: the Encryption Attack tab. The new tab allows for easy manipulation of the encrypted parts within intercepted SAML responses and can, therefore, be used to quickly assess whether the SAML endpoint is vulnerable against certain XML Encryption attacks.
Weaknesses of XML Encryption
Implementations of XML Encryption can be vulnerable to adaptive chosen ciphertext attacks. This is a class of attacks in which the attacker sends a sequence of manipulated ciphertexts to a decryption oracle as a way to gain information about the plaintext content.
Falsely implemented XML Encryption can be broken using:
- an attack against the CBC-mode decryption (quite similar to a padding oracle attack) [3] or
- a Bleichenbacher attack against the RSA-PKCS#1 encryption of the session key [4].
SAML makes use of XML Encryption and its implementations could, therefore, also be vulnerable to these attacks.
XML Encryption in SAML
To support confidential transmission of sensitive data within the SAML Assertion, assertions can be encrypted using XML Encryption. An EncryptedAssertion is shown in the abridged example below.
<EncryptedAssertion>
<EncryptedData>
<EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#aes128-cbc"/>
<KeyInfo>
<EncryptedKey>
<EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#rsa-1_5"/>
<CipherData>
<CipherValue>
[...]
</CipherValue>
</CipherData>
</EncryptedKey>
</KeyInfo>
<CipherData>
<CipherValue>
[...]
</CipherValue>
</CipherData>
</EncryptedData>
</EncryptedAssertion>
<EncryptedData>
<EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#aes128-cbc"/>
<KeyInfo>
<EncryptedKey>
<EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#rsa-1_5"/>
<CipherData>
<CipherValue>
[...]
</CipherValue>
</CipherData>
</EncryptedKey>
</KeyInfo>
<CipherData>
<CipherValue>
[...]
</CipherValue>
</CipherData>
</EncryptedData>
</EncryptedAssertion>
The EncryptedAssertion contains an EncryptedData element, which in turn is the parent of the EncryptionMethod, KeyInfo, and CipherData elements. SAML makes use of what is referred to as a hybrid encryption scheme. This is done using a session key which symmetrically encrypts the payload data (the example uses AES-128 in CBC mode), resulting in the ciphertext contained in the EncryptedAssertion/EncryptedData/CipherData/CipherValue child element. The session key itself is encrypted using an asymmetric encryption scheme. In our example, RSA-PKCS#1.5 encryption is used with the public key of the recipient, allowing the contents of the the EncryptedKey child element to be derived from the KeyInfo element.
Encryption Attacker
Our BurpSuite extension EsPReSSO can help detect vulnerable implementations with the newly integrated Encryption Attacker within EsPReSSO's SAML module.
Once a SAML response which contains an EncryptedAssertion has been intercepted, open the SAML tab, select the Attacks pane, and choose Encryption from the dropdown menu. This works in Burp's Proxy, as well as in the Repeater tool, and is depicted below.
As sketched out above, the symmetric session key is encrypted using the recipient's public key. Since the key is public, anybody can use it to encrypt a selected symmetric key and submit a valid encryption of arbitrary messages to the recipient. This is incredibly helpful because it allows us to produce ciphertexts that decrypt the chosen plaintexts. To accomplish this, one can purposefully send invalidly padded messages, or messages containing invalid XML, as a method to trigger and analyze the different reactions of the decryption endpoint (i.e, turning the endpoint into a decryption oracle). To facilitate these investigations, the new Encryption Attacker makes this process dead simple.
The screenshot above shows the essential interface of the new encryption tab:
At the top, the certificate used to encrypt the symmetric session key can be pasted into the text field. This field will be pre-filled automatically if the intercepted SAML message includes a certificate in the KeyInfo child element of the EncryptedData element. The Update Certificate checkboxes above the text area can be used to include the certificate in the manipulated SAML message.
In the Symmetric Key text field, the hexadecimal value of the symmetric session key can be set. Choose the asymmetric algorithm from the dropdown menu and click Encrypt key -- this will update the corresponding KeyInfo elements of the intercepted SAML message.
At the top, the certificate used to encrypt the symmetric session key can be pasted into the text field. This field will be pre-filled automatically if the intercepted SAML message includes a certificate in the KeyInfo child element of the EncryptedData element. The Update Certificate checkboxes above the text area can be used to include the certificate in the manipulated SAML message.
In the Symmetric Key text field, the hexadecimal value of the symmetric session key can be set. Choose the asymmetric algorithm from the dropdown menu and click Encrypt key -- this will update the corresponding KeyInfo elements of the intercepted SAML message.
The payload in the text area labeled XML data can now be entered. Any update in the XML data field will also be reflected in the hexadecimal representation of the payload (found on right of the XML data field). Note that this is automatically padded to the blocklength required by the symmetric algorithm selected below. However, the payload and the padding can be manually adjusted in the hex editor field.
Eventually, click the Encrypt content button to generate the encrypted payload. This will apply the changes to the intercepted SAML message, and the manipulated message using Burp's Forward or Go button can now be forwarded, as usual.
Probing for Bleichenbacher Oracles
Bleichenbacher's attack against RSA-PKCS1 v1.5 encryption abuses the malleability of RSA to draw conclusions about the plaintext by multiplying the ciphertext with adaptively chosen values, and observing differences in the received responses. If the (error-) responses differ for valid and invalid PKCS1 v1.5 ciphertexts, Bleichenbachers' algorithm can be used to decrypt the ciphertext without knowing the private key [6].
To determine whether or not a SAML endpoint is vulnerable to Bleichenbacher's Attack, we simply need to check if we can distinguish those responses received when submitting ciphertexts that are decrypted into invalidly formatted PKCS1 v1.5 plaintexts, from the responses we receive when sending ciphertexts that are decrypted into validly formatted plaintexts.
Recall that PKCS1 v1.5 mandates a certain format of the encrypted plaintext, namely a concatenation of a BlockType 00 02, a randomized PaddingString (PS) that includes no 00 bytes, a 00 (NULL-byte) as delimiter, and the actual plaintext message. The whole sequence should be equal in size to the modulus of the RSA key used. That is, given the byte length k of the RSA modulus and the message length |m|, PS has the length |PS| = k - 3 - |m|. Furthermore, PKCS1 v1.5 demands that |PS| to be at least eight bytes long [5].
In SAML, the recipient's public key is usually known because it is published in the metadata, or even included in the EncryptedAssertion. For this reason, we do not need to fiddle around with manipulated ciphertexts. Instead, we simply submit a validly formatted RSA-PKCS1 v1.5 encrypted message and an encrypted message which deciphers into an invalidly formatted plaintext. As an example, assume an RSA public key of 2048 bits which we want to use to encrypt a 16 byte session key `01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 10` (hexadecimal representation). |PS|$ is $2048/8 - 3 - 16 = 237, so a valid PKCS1 v1.5 plaintext, ready to be encrypted using `AA` for all 237 padding bytes, could look like the listing shown below.
00 02 AA AA AA AA AA AA AA AA AA AA AA AA AA AA
AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA
AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA
AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA
AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA
AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA
AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA
AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA
AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA
AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA
AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA
AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA
AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA
AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA
AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA 00
01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 10
In the Encryption attack pane of EsPReSSO, ensure that the correct public key certificate has been added to the Certificate field. Insert a valid plaintext, such as the one above, into the Symmetric Key field and select Plain RSA encryption from the Algorithm drop down menu. Click the Encrypt button to compute the RSA transformation and apply the new EncryptedKey element to the intercepted SAML message. Now, submit the message by clicking Burp's Go or Forward button and carefully inspect the response.
Next, repeat the steps outlined above, but this time submit an invalid PKCS1 v1.5 message. For example, consider using an invalid BlockType of `12 34` instead of `00 02`, or replace the `00` delimiter so that the decryptor is unable to determine the actual message after decrypting the ciphertext. If you are able to determine from the recieved responses whether or not the submitted ciphertext decrypted into a valid PKCS1 v1.5 formatted plaintext, chances are high that the decryptor can be used as a Bleichenbacher oracle. Don't forget to take into account the actual XML data, i.e., the assertion encrypted with the new session key; by submitting valid or invalid XML, or by removing signatures from the SAML message or the assertion you may increase your chances of detecting differences in the returned responses.
Probing for Oracles in CBC-Mode Decryption
Another known attack on XML Encryption is aimed at the Cipher Block Chaining (CBC) mode, which can be used with the block ciphers AES or 3DES [2]. The attack is described in detail in this referenced paper [3] and is quite similar to Padding-Oracle attacks on CBC mode; the malleability of CBC mode encryption enables the attacker to perform a bytewise, adaptive manipulation of the ciphertext blocks which are subsequently sent to the decryptor. In most cases, the manipulated ciphertext will not decrypt to valid XML and an error will be returned. Sometimes, however, the plaintext will be parsed as valid XML, in which cases an error is thrown later on at the application layer. The attacker observes the differences in the responses in order to turn the decryptor into a ciphertext validity oracle which can be used to break the encryption. Due to some particularities of the XML format, this attack can be very efficient, enabling decryption with about 14 requests per byte, and it is even possible to fully automate the process [7].
In order to determine if a particular SAML service provider is vulnerable to this attack, we can avoid the cumbersome ciphertext manipulation, if we are in possession of the decryptor's public key:
In the Encryption Attacker tab of EsPReSSO, add the public key certificate to the Certificate field (if necessary) and insert a symmetric key of your own devising into the Symmetric Key text field. Select an appropriate RSA encryption method and click the Encrypt button to apply the new EncryptedKey element to the original SAML message.
An XML message can now be inserted into the XML data text field. Select a CBC mode encryption algorithm and click Encrypt to apply the changes. As in the example above, press Burp's Go or Forward button to send the message and carefully inspect the response. Try sending invalid XML, e.g., by not closing a tag or using the `&` character without a valid entity and keep an eye open for differences in the returned responses. To manipulate the padding, the text field on the right side shows the hexadecimal representation of the plaintext, including the CBC padding. If you send a single block and set the last byte, which indicates the padding length to the blocksize, i.e. 16 or 0x10 for AES, the ciphertext should decrypt into an empty string and is generally considered "valid" XML.
Please refer to the original paper for more details, tips, and tricks for performing the actual attack [3].
Summary
The new XML Encryption attacker included in EsPReSSO can help security auditors to quickly assess if a SAML endpoint is vulnerable to known attacks against XML Encryption. To this end, the decryptor's public key is used in order to send suitable test vectors that can be provided in plaintext. Ciphertext manipulation is, therefore, not required. The actual process of decrypting an intercepted SAML message is, however, considered out of scope and not implemented in EsPReSSO.
In case you wonder how XML Encryption can be used in a secure fashion, here are some considerations [6]:
- Always use an authenticated encryption mode such as AES-GCM instead of the CBC-mode encryption.
- Using RSA-PKCS1 v1.5 within XML Encryption is particularly difficult to do in a secure manner, and it is recommended to use RSA with Optimal Asymmetric Encryption Padding (OAEP) instead [2].
- Apply a digital signature over the whole SAML response, and ensure it is properly validated before attempting to decrypt the assertion. This should thwart the attack as a manipulated response can be recognized as such and should be rejected.
----------
[1] https://www.oasis-open.org/standards#samlv2.0
[2] https://www.w3.org/TR/xmlenc-core/
[3] https://www.nds.ruhr-uni-bochum.de/research/publications/breaking-XML-Encryption/
[4] https://www.nds.ruhr-uni-bochum.de/research/publications/breaking-XML-Encryption-pkcs15/
[5] https://link.springer.com/chapter/10.1007%2FBFb0055716
[6] http://www.w3.org/2008/xmlsec/papers/xmlEncCountermeasuresW3C.pdf
[7] https://web-in-security.blogspot.com/2015/05/how-to-attack-xml-encryption-in-ibm.html
[2] https://www.w3.org/TR/xmlenc-core/
[3] https://www.nds.ruhr-uni-bochum.de/research/publications/breaking-XML-Encryption/
[4] https://www.nds.ruhr-uni-bochum.de/research/publications/breaking-XML-Encryption-pkcs15/
[5] https://link.springer.com/chapter/10.1007%2FBFb0055716
[6] http://www.w3.org/2008/xmlsec/papers/xmlEncCountermeasuresW3C.pdf
[7] https://web-in-security.blogspot.com/2015/05/how-to-attack-xml-encryption-in-ibm.html
Related word
Suscribirse a:
Entradas (Atom)
