Part 5: Cryptography & Request Forgery

This content is based on the H5 tasks of Data Security by Mr. Karvinen.

Applied Cryptography: Foundations

In this segment we will have a look at the Chapter 1: Foundations, of the book Applied Cryptography: Protocols, Algorithms and Source Code in C, 20th Anniversary Edition by Bruce Schneier. We will focus mostly on the content that is relevant in terms of data security.

When send a secure message to a receiver we want to ensure that the message cannot be read by anyone except the intended receiver. Now if we just send the message in a plain text format, this will not really stop anybody from reading it if the message is intercepted. This is where encryption comes in, the process of disguising a message and hiding its content. The message can then turned back into its original state through decryption. The terms encrypt and encipher as well as decrypt and decipher are used interchangeably. A message that is encrypted is called a ciphertext. The term message doesn't really apply to just text, encryption can be applied to all kinds of data. This all falls under the umbrella of cryptography which is described by Mr. Schneier as the art and science of keeping messages secure.

Cryptography itself is also often responsible for authentication, integrity, and nonrepudiation.

  • Authentication, from the greek word authentikos, meaning real, and genuine, refers to the fact that the receiver should be able to verify the messages origin.
  • Integrity, from the latin word integritatem, meaning soundness, completeness, and wholeness refers to the fact that the receiver should be able to verify that the message has not been modified or substituted.
  • Non-repudiation, from the latin word repudiare, meaning reject or putting away, refers to the fact that the sender should not be able to falsely deny that he ever sent the message.

Then there is the topic of algorithms and keys. The cryptographic algorithm is also known as a cipher, it is the mathematical core function that is responsible to encrypt and decrypt the target data. Modern algorithms use one or multiple keys, which cause the encryption to be "unique" depending on said keys. There are multiple kinds of algorithms, one is the so called asymmetric algorithm type, where the key for encryption and decryption are different from each other. This is also known as a public-key algorithm. And there is symmetric encryption where description and encryption keys are interdependent. On the first glance it seems non-logical why anyone would use symmetric encryption since the one key concept is a lot more risky. The benefit of symmetric encryption is in the efficiency, especially when dealing with large amounts of data this can be rather significant. This does of course not prevent us from using a hybrid encryption, or in other words an asymmetric algorithm to share a key for a symmetric algorithm, and therefore bypassing the added risk in terms of security.

For a more detailed insight I highly recommend checking out the full chapter of the book.

Encrypting and decrypting Messages

Since we now understand the basics of encryption it is time for some hands on experience. For this purpose we will encrypt and decrypt a message. There are a multitude of tools that we can use for this. In this case I chose GPG/GnuPG since this package comes by default with most Linux distributions.

First of all lets make sure we have GPG installed by running $ gpg --version. In case that it is not installed you can do so with the following command $ apt-get install gnupg

In my case it is already installed, and as we can see we have a variety of supported algorithms available to us. Before we do anything else, let us create a text file and fill it with some content. We run cat > topsecret.txt and fill it with some text. Quick tip, Ctrl+D will exit and save the file.

Now we have a text file with some top secret content that we want to encrypt. If we want to use asymmetric encryption to protect the file we could start by generating a RSA key. We can do so with $ gpg --full-generate-key and set the desired parameters for the key. In my case I selected 4096 bits and set the key to expire in 2 days.

We will see now a prompt to enter a passphrase which will protect the key. We enter a passphrase of our choice in my case that is "D@ta$-3cur1ty^!s|mp0rt4nt*#!". The key creation is now complete.

Now that the key creation is done we can proceed with the actual encryption. Lets start with having a look at symmetric encryption with AES256. All that we need to do is to run gpg --output topsecret --decrypt topsecret.txt and enter a passphrase when prompted to. I went with the same one that we defined further up to make things more straight forward. A comparison with the file before and after shows that the encryption was successful.

I placed the file on a USB drive and moved it to the target machine. All that is left is to check if we can also decrypt it. To do that lets run the following command gpg --output encryptedmessage --decrypt topsecret and we will have now the encrypted contents in the file encryptedmessage. This was a Windows machine, but the same command works in PowerShell 7. We can now successfully read the encrypted message.

Asymmetric encryption works in a slightly different way. We generated earlier the required keys, so what we would do now is to exchange the public keys with our recipient since we need want to ensure authentication, integrity, and nonrepudiation. To export a public key we can use gpg --output agent42.gpg --export [email protected]. To import a public key we run gpg --import agentX.gpg. We can verify the successful import with the help of gpg --list-keys. As is mentioned in the GnuPG handbook we should always validate keys, this can be done with gpg --edit-key [email protected]. The key's fingerprint can be viewed with fpr. This way we can verify with the owner that it is really the right key and nobody is intercepting and modifying keys. Once we verified that everything is in order we can sign the key with sign.

Once that is done we can run the following command to encrypt gpg --output asencrypted --encrypt --recipient [email protected] topsecret and this one to decrypt messages gpg --output asdecrypted --decrypt asencrypted.

For more details and functions I highly recommend to check out the offical GnuPG manual. It contains everything you possibliy would need or want to know. The explanations here barely scratch the surface of what the tools is capable of.

Server-side request forgery (SSRF)

SSRF is a type of vulnerability that abuses server-based functions to fetch data or execute commands toward another internal or external resource. We basically send a request with a request through the target server. Lets just call this an encapsulated request to make things easier. In essence there are three steps at work here

  • Manipulating an original request
  • The target server receives the encapsulated request
  • The server processes the encapsulated request and executes the request within towards the network or another target. This can be internal or external.
SSRFs can provide be used for a variety of tasks. We can probe a network, run attacks against internal systems, use it as a base for exploit chaining, and use it as a proxy for external attacks. A good example of this is the Capitol One data breach which utilized SSRF for the intial mode of attack to extract AWS credential keys in the AWS EC2 metadata service.

SSRF in itself can be rather simple but it doesn't have to. Assuming we have a vulnerable WebService it could be as simple as curl https://example.com/user/image?imgUrl==http://localhost:5000 to get access to an admin panel which is only accessible through the internal network. Maybe the biggest hurdle with a SSRF attack are the dependency on feedback from the server. Without feedback we are blind and have to engage in so called Blind SSRF. This is rather difficult and tedious since we need to operate without any kind of feedback. Nevertheless, this is only a hindrance and not a prevention to a potential attacker.

In terms of prevention it is best to employ:

  • Proper input validation
  • Network layer security
  • Whitelisting of Domains
  • Usage of URL schemas
  • Not sending raw responses
  • Using authentication for everything