\(ECB\) Electronic Code Book - symmetric encryption scheme which **replaces each block of the clear text** by the **block of ciphertext**. It is the **simplest** encryption scheme. The main idea is to **split** the clear text into **blocks of N bits** \(depends on the size of the block of input data, encryption algorithm\) and then to encrypt \(decrypt\) each block of clear text using the only key.
Imagine you login into an application several times and you **always get the same cookie**. This is because the cookie of the application is **`<username>|<password>`**.
Then, you generate to new users, both of them with the **same long password** and **almost** the **same****username**.
You find out that the **blocks of 8B** where the **info of both users** is the same are **equals**. Then, you imagine that this might be because **ECB is being used**.
This is because the **username and password of those cookies contained several times the letter "a"** \(for example\). The **blocks** that are **different** are blocks that contained **at least 1 different character** \(maybe the delimiter "\|" or some necessary difference in the username\).
Now, the attacker just need to discover if the format is `<username><delimiter><password>` or `<password><delimiter><username>`. For doing that, he can just **generate several usernames** with s**imilar and long usernames and passwords until he find the format and the length of the delimiter:**
Knowing the format of the cookie \(`<username>|<password>`\), in order to impersonate the username `admin` create a new user called `aaaaaaaaadmin` and get the cookie and decode it:
A more complicated way to bypass this is to swap data around. We can make the assumption that the application will use an SQL query to retrieve information from the user based on his `username`. For some databases, when using the type of data `VARCHAR` \(as opposed to `BINARY` for example\), the following will give the same result:
```text
SELECT * FROM users WHERE username='admin';
```
```text
SELECT * FROM users WHERE username='admin ';
```
The spaces after the value `admin` are ignored during the string comparison. We will use this to play with the encrypted blocks.
Our goal is to end up with the following encrypted data:
```text
ECB(admin [separator]password)
```
We know that our separator is only composed of one byte. We can use this information to create the perfect `username` and `password`to be able to swap the blocks and get the correct forged value.
We need to find a username and a password for which:
* the password starts with `admin` to be used as the new username.
* the encrypted password should be located at the start of a new block.
* the `username+delimiter` length should be divisible by the block size \(from previous conditions\)
By playing around, we can see that the following values work:
* a `username` composed of `password` \(8 bytes\) followed by 7 spaces \(1 byte will be used by the delimiter\).
* a `password` composed of `admin` followed by 3 spaces \(`8 - length("admin")`\).
When creating this user, use a proxy to intercept the request and make sure your browser didn't remove the space characters.
If you create correctly this user, the encrypted information will look like:
Using some Ruby \(or even with Burp decoder\), you can swap the first 8 bytes with the last 8 bytes to get the following encrypted stream:
Once you modify your cookie, and you reload the page, you should be logged in as `admin`:
