HTTPs/TLS Attacks  

Public Key Infrastructure

TLS utilizes both symmetric and asymmetric cryptography. Asymmetric cryptography typically relies on public key infrastructure. To fully understand how TLS works, we must therefore get a basic understanding of certain terminologies such as public key infrastructure, certificates, and certificate authorities.


Public Key Infrastructure

A public key infrastructure (PKI) comprises roles and processes responsible for the management of digital certificates. This includes the distribution, creation, and revocation of certificates. Without a proper PKI, public key cryptography would be impractical.

In public key cryptography, the encryption key is different from the decryption key, which is why it is also called asymmetric encryption. Each participant owns a key pair consisting of a public key that is used for encryption, and a private key or secret key that is used for decryption. As its name suggests, the public key is public knowledge, thus everyone can use it to encrypt messages for the owner of the corresponding private key. Since messages encrypted with a public key can only be decrypted with the corresponding private key, only the intended receiver can decrypt the message. This inherently protects the messages from unauthorized actors. Here is an overview of commonly used encryption algorithms and their type:

Algorithm Type
RSA asymmetric
DSA asymmetric
AES symmetric
DES symmetric
3DES symmetric
Blowfish symmetric

However, there is a conceptual problem that comes from the acquisition of other actors' public keys since it is impossible to verify their validity. For instance, consider an example where the user Alice wants to communicate with hackthebox.com privately. To do so, she obtains the public key of hackthebox.com, encrypts her message with it, and sends it to the target. Since only hackthebox.com knows the corresponding private key for decryption, the message cannot be decrypted by unauthorized actors. But how can Alice know that the public key actually belongs to hackthebox.com and not an attacker that wants to steal Alice's HackTheBox credentials? Assume an attacker intercepts Alice's request to obtain HackTheBox's public key and instead sends Alice his own public key while spoofing the origin to make Alice think it's actually HackTheBox's public key. She would then encrypt her message with the attacker's public key thinking it was HackTheBox's public key, enabling the attacker to decrypt and access the message. Certificates exist precisely to solve this problem.

image

Certificates

The purpose of certificates is to bind public keys to an identity. This proves the identity of the public key owner and thus solves the previously discussed problem.

When accessing a website, we can check the certificate of the web server. In Firefox we can do this by clicking on the lock next to the URL bar, and then Connection Secure > More Information > View Certificate.

Let's have a look at the contents of the certificate for hackthebox.com:

image

The certificate contains information about the subject. Most importantly the Common Name, which is the domain name the public key belongs to. Additionally, each certificate has an expiry date and needs to be renewed before it expires to remain valid.

Note: Additional domain names can be specified in the Subject Alt Names section.

If we scroll down a bit, we can see that the certificate also contains the public key:

image

This certificate ensures that when we encrypt a message with the public key shown in the screenshot, only HackTheBox will be able to decrypt it.

So certificates are used to tie an identity to a public key. But who can issue certificates? And what prevents an attacker from just creating a certificate with his own public key and the domain hackthebox.com, thus impersonating HackTheBox with a forged certificate? That is where Certificate Authorities come into play.

Certificate Authorities

Certificate authorities (CAs) are entities that are explicitly allowed to issue certificates. They do this by cryptographically signing a certificate. The identity of the CA is proven by a CA Certificate. Just like any other certificate, CA certificates are signed by another CA. This continues until a root CA is reached. The chain from the root CA to the end-user's certificate is called the certificate chain. When we look again at HackTheBox's certificate, we can see the certificate chain consisting of three total certificates at the top:

image

When accessing a website, the browser validates the whole certificate chain. If any of the certificates contained in the chain are invalid or insecure, the browser displays a warning to the user. The root CA's identity is checked against a hardcoded set of trusted CAs in the so-called certificate store to prevent forgery of root CA certificates.


OpenSSL

OpenSSL is a project that implements cryptographic algorithms for secure communication. Many Linux distributions rely on OpenSSL, making it essential for encrypted communication on the internet. Security vulnerabilities and bugs in OpenSSL lead to millions of affected web servers. We can use the OpenSSL client which is preinstalled on many Linux distributions to generate our own keys and certificates, convert them to different formats, and perform encryption.

Key Generation & Certificate Conversion

We can generate a new RSA key-pair with 2048 bit length and store it in a file using the following command:

[!bash!]$ openssl genrsa -out key.pem 2048
Generating RSA private key, 2048 bit long modulus (2 primes)
..+++++
...............................................................+++++
e is 65537 (0x010001)

When we cat the file, it shows us the private key:

[!bash!]$ cat key.pem 
-----BEGIN RSA PRIVATE KEY-----
MIIEowIBAAKCAQEAzCBnKqY7/6joFncQwuMfn9jRJmA4KX3rvAeN9/Zo4ItLWZ6q
<SNIP>
rfrwXh8ZgFAuDx75kxnuzKzzHg+uV2YiS2RMuid03qlW2iKHWUV8
-----END RSA PRIVATE KEY-----

We can use openssl to print out the public key as well:

[!bash!]$ openssl rsa -in key.pem -pubout
writing RSA key
-----BEGIN PUBLIC KEY-----
MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAzCBnKqY7/6joFncQwuMf
n9jRJmA4KX3rvAeN9/Zo4ItLWZ6qnax1RXmAM986GVcTqIlBp7vzzYY3VulcYM/k
78QwQr//nU3zKlPoMOhhhoeuq98tj76dmUYWl9gfyHyg3FIk0yWZuvVSOor5D0Rm
r5PhCu5B7+EpbnbXcfRuyoPJqq78Bs9HOfg0HO++R7Ilpcr6t6WD/ftkr1zEXaWO
cYhYCPdkpouCTsBe8QbRAy6B/E9kbENeRFdTkkX0cM5BSy4MKj9VezygK6kynzE6
KKY1I8pGYChyfWjskbXbaJF9ocBnPAvzM2RzMrw1RhiAT8ErubuMqPYdRQS4RtHV
GQIDAQAB
-----END PUBLIC KEY----

Furthermore, we can download the certificate of any web server:

[!bash!]$ openssl s_client -connect hackthebox.com:443 | openssl x509 > hackthebox.pem

This stores the certificate in the PEM format. However, there are other formats such as DER and PKCS#7. We can convert from PEM to these formats using openssl:

# PEM to DER
[!bash!]$ openssl x509 -outform der -in hackthebox.pem -out hackthebox.der

# PEM to PKCS#7
[!bash!]$ openssl crl2pkcs7 -nocrl -certfile hackthebox.pem -out hackthebox.p7

Creating a Self-Signed Certificate

Finally, we can create our own certificate and sign it ourselves. This means that the signature of a CA is not required. We can specify the type of key that is created, as well as the algorithm and expiry date of the certificate. We are also asked to enter a passphrase to protect the private key file and provide subject information for the certificate. We can provide any information we want, including impersonating HackTheBox by copying the information from their certificate:

[!bash!]$ openssl req -x509 -newkey rsa:4096 -keyout key.pem -out selfsigned.pem -sha256 -days 365
Generating a RSA private key
..++++
.............................................................................................................++++
writing new private key to 'key.pem'
Enter PEM pass phrase:
Verifying - Enter PEM pass phrase:
-----
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [AU]:US
State or Province Name (full name) [Some-State]:California
Locality Name (eg, city) []:San Francisco
Organization Name (eg, company) [Internet Widgits Pty Ltd]:Cloudflare, Inc.
Organizational Unit Name (eg, section) []:
Common Name (e.g. server FQDN or YOUR name) []:hackthebox.com
Email Address []:

Does this mean we hacked the system and are now able to impersonate HackTheBox? No, because the certificate is self-signed, the web browser does not trust it and displays a warning:

image

However, if we ever got our hands on the private key of a CA, we could use it to sign certificates with an arbitrary subject. This would allow us to effectively impersonate anyone. Therefore, private keys of CAs are one of the most protected resources when it comes to secure online communication.

Performing Encryption

Finally, we can also use openssl to perform encryption. For that, we first create a new key-pair and extract the public key to a separate file:

# create new keypair
[!bash!]$ openssl genrsa -out rsa.pem 2048
Generating RSA private key, 2048 bit long modulus (2 primes)
..+++++
.............................+++++
e is 65537 (0x010001)

# extract public key
[!bash!]$ openssl rsa -in rsa.pem -pubout > rsa_pub.pem
writing RSA key

We can then use the extracted public key to encrypt a file. Inspecting the encrypted file reveals the binary ciphertext:

[!bash!]$ openssl pkeyutl -encrypt -inkey rsa_pub.pem -pubin -in msg.txt -out msg.enc

[!bash!]$ cat msg.enc | xxd | head
00000000: 0550 eea0 8b79 ba5e a933 0539 6175 4834  .P...y.^.3.9auH4
00000010: 26dd a435 d4c1 bc18 f1c2 075f 8d51 2d2d  &..5......._.Q--
00000020: 5e13 fa33 d65f 4d59 fb87 26e2 6a29 a8e9  ^..3._MY..&.j)..
00000030: 017c 39d4 f43c 210b fbb5 921e 2763 4512  .|9..<!.....'cE.
00000040: b68e 3b41 c77d 948e c720 eb35 f104 a428  ..;A.}... .5...(
00000050: 2191 e2bd 2638 f6da ce87 93fa 80ca e32c  !...&8.........,
00000060: 3b2b 3c89 61cf 366f ff8b 933d 5dda 1299  ;+<.a.6o...=]...
00000070: 5760 3849 bad3 891d d3cb 0c94 c299 2de4  W`8I..........-.
00000080: 5c13 5a6a 25ea b645 c891 2894 995d ed7a  \.Zj%..E..(..].z
00000090: ad41 a5fc 79c3 6beb 7670 5f00 3d30 052d  .A..y.k.vp_.=0.-

Lastly, we can decrypt the encrypted file using the corresponding private key:

[!bash!]$ openssl pkeyutl -decrypt -inkey rsa.pem -in msg.enc > decrypted.txt

[!bash!]$ cat decrypted.txt 
Hello.World

/ 1 spawns left

Waiting to start...

Questions

Answer the question(s) below to complete this Section and earn cubes!

+10 Streak pts

Previous

+10 Streak pts

Next
Go to Questions
My Workstation

OFFLINE

/ 1 spawns left