+ About++ Cryptography is key area of security and is used to keep secrets secret. When implemented badly these secrets can be leaked or the crypto manipulated to bypass protections. + ++ This module will look at three weaknesses, using encoding instead of encryption, using algorithms with known weaknesses, and padding oracle attacks. + + ++ + Objective+Each level has its own objective but the general idea is to exploit weak cryptographic implementations. + ++ + Low Level+The thing to notice is the mention of encoding rather than encryption, that should give you a hint about the vulnerability here. ++ + +
+
+
+ Start by encoding a few messages and looking at the output, if you have spent any time around encoding standards you should be able to tell that it is in Base64. Could it be that simple? Try Base64 decoding some test strings to find out: ++That failed, but what you might notice is that the number of output characters matches the number of input characters. Another common encoding method that is sometimes mistaken for encryption is XOR, this takes the clear text input and XORs each character with a key which is repeated or truncated to be the same length as the input. ++XOR is associative, this means that if you XOR the clear text with the key you get the cipher text and if you XOR the cipher text with the key you get the clear text, what it also means is if you XOR the clear text with the cipher text, you get the key. Let's try this with our examples: + ++This looks promising, let's try the second example: + ++There is no repetition in the key yet so let's try with a longer string. + + ++It looks like we have found our key "wachtwoord". Let's give it a try on our challenge string: + + ++And there we have it, the message we are looking for and the password we need to login. + + +Another lesson here, do not assume that the messages or the underlying system you are working with is in English. The key "wachtwoord" is Dutch for password. +Medium Level+The tokens are encrypted using an Electronic Code Book based algorithm (aes-128-ecb). In this mode, the clear text is broken down into fixed sized blocks and each block is encrypted independently of the rest. This results in a cipher text that is made up from a number of individual blocks with no way to tie them together. Worse than this, any two blocks, from any two clear text inputs, are interchangeable as long as they have been encrypted with the same key. In our example, this means you can take blocks from the three different tokens to make your own token. ++ + +
+
+
+ + How do you know the block size? This is given in the algorithm name. aes-128-ebc is a 128 bit block cipher. 128 bits is 16 bytes, but to make things human readable, the bytes are represented as hex characters meaning each byte is two characters. This gives you a block size of 32 characters. Sooty's token is 192 characters long, 192 / 32 = 6 and so Sooty's token has six code blocks. + + ++Let's start by breaking the tokens down into blocks. +Sooty: +Sweep: +Soo: ++ Each token has broken down nicely into blocks so we are on the right track. + ++ If you look carefully at the blocks you will see that there are some that repeat over the different tokens, this means that the same clear text has been encrypted to create the block. If we look at the description we can try to map these to the JSON object. + ++ Taking Sooty as an example: + +Sooty: ++ Assuming we are right with our mappings, if you compare the blocks that match you can see that Sooty and Sweep both have the same expiry block (b85bb230876912bf3c66e50758b222d0) and both Sweep and Soo have the same level block (83f2d277d9e5fb9a951e74bee57c77a3). This matches with what we know about the tokens as both Sooty and Sweep have expired tokens and both Sweep and Soo are users, not admins. + ++ Knowing all this, we can now create our forged session token. We need to take the username block from Sweep, the expiry block from Soo and the level block from Sooty. We can then finish the token off with the remaining blocks from any of the tokens. This gives us: + ++ Which gives us... + ++ + ++ This is a very contrived setup with the tokens tweaked to force blocks to map to the JSON object so manipulation is easier to do, in the real world it is unlikely to be this easy however as data is often formed from fixed sized blocks overlaps can happen in a way that mixing blocks up results in valid data. Sometimes just being able to pass invalid data is enough so all that is needed is to swap blocks in a way that they can be decrypted and then passed on to the rest of the system where they will cause errors. + ++ If you want to play with this some more, there is a script called ecb_attack.php in the sources directory which shows how the tokens were generated and lets you combine them in different ways to create custom tokens. + +High Level+The system is using AES-128-CBC which means it is vulnerable to a padding oracle attack. + ++ + + +
+
+
+ Rather than try to explain this here, go read this excelent write up on the attack by Eli Sohl. +Cryptopals: Exploiting CBC Padding Oracles ++ If you want to play with this some more, there is a script called oracle_attack.php in the sources directory which runs through the full attack with debug. You can run this either against the DVWA site or it will run locally against its own pretend web server. + +Impossible Level+You can never say impossible in crypto as something that would take years today could take minutes in the future when a new attack is found or when processing power takes a giant leam forward. ++ The current recommended alternative to AES-CBC is AES-GCM and so the system uses that here. 256 bit blocks rather than 128 bit blocks are used, and a unique IV used for every message. This may be secure today but who knows what tomorrow brings? + + |
+
+ You have managed to steal the following token from a user of the Prognostication application. +
++ +
++ You can use the form below to provide the token to access the system. You have two challenges, first, decrypt the token to find out the secret it contains, and then create a new token to access the system as a other users. See if you can make yourself an administrator. +
++ You have managed to steal the following token from a user of the Impervious application. +
++ +
++ This being the impossible level, you should not be able to mess with the token in any useful way but feel free to try below. +
++ This super secure system will allow you to exchange messages with your friends without anyone else being able to read them. Use the box below to encode and decode messages. +
+ +"; + +if (!is_null ($encoded)) { + $html .= " ++
"; +} + +$html .= " ++ You have intercepted the following message, decode it and log in below. +
++ +
+"; + +if ($errors != "") { + $html .= '+ You have managed to get hold of three session tokens for an application you think is using poor cryptography to protect its secrets: +
++ Sooty (admin), session expired +
++ +
++ Sweep (user), session expired +
++ +
++ Soo (user), session valid +
++ +
++ Based on the documentation, you know the format of the token is: +
+{
+ \"user\": \"example\",
+ \"ex\": 1723620372,
+ \"level\": \"user\",
+ \"bio\": \"blah\"
+}+You also spot this comment in the docs: +
++To ensure your security, we use aes-128-ecb throughout our application. ++ +
+ Manipulate the session tokens you have captured to log in as Sweep with admin privileges. +"; + +if ($errors != "") { + $html .= '