CS88 Lab 4: Network Security: Public Key Infrastructure & Internet of Things

Complete Task 1: Setting up an Enterprise Public Key Infrastructure

Complete Task 2: Launching a DNS Rebinding IoT Attack

We will first need a configuration file for OpenSSL to use to generate certificates, and to find relevant information.

Let’s create a self-signed certificate for our root swatCA in rootCA.sh. In this file you should see an example for creating a certificate for modelCA. You want to instead create a root certificate for swatCA. Once you are done, you can run this bash script and see the following output:

PKI$ chmod +x *.sh
PKI$ ./rootCA.sh
Generating a RSA private key
............................................................................................................................................................................................................................................................................................................++++
..............................................++++
writing new private key to 'swatCA.key'
PKI$ ls  #shows swatCA.crt and swatCA.key
docker-compose.yml  image_www  rootCA-solution.sh  swatCA  swatCA.crt  swatCA.key  swatCA_openssl.cnf  volumes
-----

The output of the command above is stored in two files: swatCA.key and swatCA.crt.

We can now use the following commands to look at the decoded content of the X509 certificate and the RSA key. Run the command below to look at the certificates created.

First, a Public Key Algorithm that is used together with the private key, to authenticate the endpoint (i.e., Alice has a public key that can be used with the private key to decrypt messages from Bob).

Second, a Signature Algorithm to verify that the end user is really who they say they are, i.e., (in our analogy above this is the equivalent of Trent verifying that the public key does indeed belong to Alice).

A Certificate Signing Request (CSR), includes the organization’s public key and identity information.

The CSR will be sent to the rootCA, who will verify the identity information in the request, and then generate a certificate.

The command to generate a CSR is quite similar to the one we used in creating the self-signed certificate for the CA. The only difference is the -x509 option.

Modify the contents of cs88_cert_req.sh and run it to see the following output:

PKI$ chmod +x *.sh
PKI$ ./cs88_cert_req.sh
Generating a RSA private key
...............................................+++++
................................................................................................................................................................+++++
writing new private key to 'cs88_key.pem'
PKI$ ls  #shows the following *new files*
cs88_key.pem
cs88.csr
-----

We can use the following command to look at the decoded content of the CSR and private key files:

Due to the hostname matching policy enforced by browsers, the common name (CN) in a certificate must match with the server’s hostname, or browsers will refuse to communicate with the server.

To allow a certificate to have multiple names, the X.509 specification defines extensions to be attached to a certificate.

Let’s add alternate names that www.cs88.com can correspond to in cs88_cert_req_altname.sh with the following extension fields.

-addext "subjectAltName = DNS:www.cs88.com, \
DNS:www.cs88A.com, \
DNS:www.cs88B.com"

If we now run cs88_cert_req_altname.sh, we should now see the following:

PKI$ ./cs88_cert_req_altname_solution.sh
Generating a RSA private key
...............................+++++
......................+++++
writing new private key to 'cs88_key.pem'
-----

In the real world, the CSR files are usually sent to a trusted CA for their signature (and usually $$). In this task, we will use our own trusted root CA to generate certificates.

The commands in rootCA_sign_cert.sh converts the certificate signing request into an X509 certificate using the rootCA’s certificate and the key file. Update and run rootCA_sign_cert.sh to see the following output:

PKI$./rootCA_sign_cert.sh
Using configuration from <your_config.cnf>
Check that the request matches the signature
Signature ok
Certificate Details:
        Serial Number: 4096 (0x1000)
        Validity
            Not Before: Oct 26 15:59:54 2022 GMT
            Not After : Oct 23 15:59:54 2032 GMT
        Subject:
            countryName               = US
            stateOrProvinceName       = Swarthmore
            organizationName          = Swarthmore .
            commonName                = www.cs88.com
        X509v3 extensions:
            X509v3 Basic Constraints:
                CA:FALSE
            Netscape Comment:
                OpenSSL Generated Certificate
            X509v3 Subject Key Identifier:
                5E:0E:DD:58:98:2B:53:DA:FB:F6:8C:9C:3B:89:25:F8:7E:C0:54:9B
            X509v3 Authority Key Identifier:
                keyid:5A:22:15:E8:A6:8C:A2:8E:93:C9:A2:B4:98:87:CA:59:B6:EA:83:B5

Certificate is to be certified until Oct 23 15:59:54 2032 GMT (3650 days)

Write out database with 1 new entries
Data Base Updated

Notice that we use the policy policy_anything defined in the configuration file. This is not the default policy; the default policy is more restrictive, requiring that the subject information in the request match that of the CA’s certificate. The policy used in the command, as indicated by its name, does not enforce any matching rule. Not to be used in real-world deployments!

We also see a "Database Updated" statement at the end of the certificate signing. Let’s take a look at our database, and see what updates it has received. You should see something like the following:

Since we are setting up an enterprise or private chain-of-trust, we want to enable all the extensions or alternate names of cs88.com (i.e., cs88a.com, cs88b.com, etc) are also certified by the rootCA.

To enable this feature, open your copy of the configuration file in your favorite text editor, and uncomment the following line:

After signing the certificate, use the following command to print out the decoded content of the certificate, and check whether the alternative names are included. Run rootCA_sign_cert.sh to generate new output.

Configure the private key and public certificate: We first need to configure the Apache server, so it knows where to get the private key and certificates.

Build and Start your Docker container: Let’s now get our docker container up and running:

PKI$ dcbuild
....
Successfully built 860997d47d7d
Successfully tagged seed-image-www-pki:latest
PKI$ dcup
Starting www-10.9.0.80 ... done
Attaching to www-10.9.0.80

# Once you are done working on the lab.
PKI$ dcdown
Removing www-10.9.0.80 ... done
Removing network net-10.9.0.0

Setting up the Apache Server: Now that we have our docker container up and running, lets ssh into the Apache server:

PKI$ dockps
4ddfc0f2e744  www-10.9.0.80
# --> YOUR DCBuild will generate a unique number associated with the webserver
# --> USE your number don't copy paste :)
PKI$ docksh 4dd
root@4ddfc0f2e744:/#

Now if we run ls, we should see the volumes folder with the certificates we copied in. Let’s copy these certificates to the certs folder.

Once you’ve done the previous step you should be able to see the following contents in your certs folder:

root@4ddfc0f2e744:/# ls certs
bank32.crt  bank32.key  cs88.crt  cs88.key

An Apache server can simultaneously host multiple websites. It needs to know the directory where a website’s files are stored. This is done via its VirtualHost file, located in the `/etc/apache2/sites-available directory. For the bank32 site, we have the following configuration bank32_apache_ssl.conf, that you can find here:

root@4ddfc0f2e744:/# cd /etc/apache2/sites-available
root@4ddfc0f2e744:/etc/apache2/sites-available# ls
000-default.conf  bank32_apache_ssl.conf  default-ssl.conf

Our container is already setup to run an HTTPS site for bank32.com. You can view the configuration bank32_apache_ssl.conf and follow this example to set up your own HTTPS site.

root@4ddfc0f2e744:/etc/apache2/sites-available# cat bank32_apache_ssl.conf

Once you’ve completed the previous step, to get our webpage up and running, we need to enable Apache’s ssl module and then enable this site as shown below. You would need to do the same but for the webpage www.cs88.com.

# a2enmod ssl // Enable the SSL module
# a2ensite bank32_apache_ssl // Enable the sites described in this .conf file

To start the server we can run the following commands

// Start the server
# service apache2 start
// Once you are done: Stop the server
# service apache2 stop
// To restart in case you need to:
# service apache2 restart

When Apache starts, it needs to load the private key for each HTTPS site. Our private key is encrypted, so Apache will ask us to type the password for decryption.

Inside the container, the password used for bank32 is dees. Look at your own certificate scripts to figure out what password you used. Once everything is set up, we can browse our webpage www.cs88.com, and all the traffic between the browser and the server will be encrypted!

To do the steps listed above, we need to modify the DNS or the Domain Name Lookup service on the VM.

We will use the dig utility that maps domain names to IP addresses, to modify the victim’s mappings as shown below:

seed@VM:~$ dig www.example.com

; <<>> DiG 9.16.1-Ubuntu <<>> www.example.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 35476
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 65494
;; QUESTION SECTION:
;www.example.com.		IN	A

;; ANSWER SECTION:
www.example.com.	17559	IN	A	93.184.216.34

;; Query time: 16 msec
;; SERVER: 127.0.0.53#53(127.0.0.53)
;; WHEN: Sat Oct 29 15:07:04 EDT 2022
;; MSG SIZE  rcvd: 60

seed@VM:~$ dig google.com

; <<>> DiG 9.16.1-Ubuntu <<>> google.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 45816
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 65494
;; QUESTION SECTION:
;google.com.			IN	A

;; ANSWER SECTION:
google.com.		274	IN	A	142.251.40.206

;; Query time: 16 msec
;; SERVER: 127.0.0.53#53(127.0.0.53)
;; WHEN: Sat Oct 29 15:08:08 EDT 2022
;; MSG SIZE  rcvd: 55

Seeing the response returned above what address do you think www.google.com maps to?

What we are now going to do is get our VM to overwrite the mapping between www.google.com and its IP address, and instead, point www.google.com to 93.184.216.34, which is www.example.com address.

We will provide this over-ride of DNS to IP mappings in the etc/hosts/ file.

Open /etc/hosts file in your favorite editor and add the following line:

Now, let’s launch Firefox, first clear history as shown in the previous task, and then try to visit https://www.google.com.

In this task, we assume that the Swat Root CA created in Task 1 is compromised by an attacker, and its private key is stolen. Therefore, the attacker can generate any arbitrary certificate using this CA’s private key.

Design an experiment to show that the attacker can successfully launch MITM attack by getting the root CA to validate www.example.com. You will need to execute the same steps as we did for www.cs88.com. Except that instead of your firefox directing you to the real www.example.com, you should be visiting the fake www.example.com that you have created with the "stolen" private key from the root Swat CA.

First, let’s split the hostname into individual parts seperated by the period . operator. So, now we have ., edu, swarthmore, cs and allspice.

We will see from the figures above, that resolving each section of the hostname is the responsibility of the corresponding tier in our DNS Hierarchy. The DNS has a similar structure to the Chain-of-Trust we used to establish our Public Key Infrastructure (in fact PKI’s model is inspired by the DNS Hierarchy).

Every server in the picture above maps to a set of IP addresses

Since the IoT device is behind the firewall, machines outside of the IoT’s subnet cannot interact with the IoT device, and will therefore not be able to control the thermostat. To defeat the firewall protection, the attacking code must get unto the internal network first.

Now run dcup you should see the following:

DNS$ dcup
Creating attacker-www-10.9.0.180    ... done
Creating iot-192.168.60.80          ... done
Creating router                     ... done
Creating attacker-ns-10.9.0.153     ... done
Creating local-dns-server-10.9.0.53 ... done
Attaching to local-dns-server-10.9.0.53, iot-192.168.60.80, attacker-ns-10.9.0.153, attacker-www-10.9.0.180, router
local-dns-server-10.9.0.53 |  * Starting domain name service... named    [ OK ]
attacker-ns-10.9.0.153 |  * Starting domain name service... named        [ OK ]
iot-192.168.60.80   |  * Serving Flask app "/app/rebind_iot"
iot-192.168.60.80   |  * Environment: production
iot-192.168.60.80   |    WARNING: This is a development server. Do not use it in a production deployment.
iot-192.168.60.80   |    Use a production WSGI server instead.
iot-192.168.60.80   |  * Debug mode: off
iot-192.168.60.80   |  * Running on http://0.0.0.0:80/ (Press CTRL+C to quit)
attacker-www-10.9.0.180 |  * Serving Flask app "/app/rebind_server"
attacker-www-10.9.0.180 |  * Environment: production
attacker-www-10.9.0.180 |    WARNING: This is a development server. Do not use it in a production deployment.
attacker-www-10.9.0.180 |    Use a production WSGI server instead.
attacker-www-10.9.0.180 |  * Debug mode: off
attacker-www-10.9.0.180 |  * Running on http://0.0.0.0:80/ (Press CTRL+C to quit)

We can now test the IoT server. Point the browser to www.seedIoT32.com on the User VM. If everything is set up correctly, we should be able to see a thermostat. We can also change the temperature setting by dragging the sliding bar.

After making the change, lets run the following command for the change to take effect:

$ sudo resolvconf -u

First run dockps and docksh into the attacker’s server:

seed@VM:~/.../DNS$ dockps
3163dd7f9610  attacker-ns-10.9.0.153
43171fb012c6  router
646a9c53d55c  local-dns-server-10.9.0.53
7be85d4a29c3  iot-192.168.60.80
c6ffc7e134bc  attacker-www-10.9.0.180

seed@VM:~/.../DNS$ docksh c6

After you are done making the changes above, then exit, and restart the docker container

seed@VM:~/.../DNS$ docker container restart c6ff