Differences
This shows you the differences between two versions of the page.
|
cdci:labs:5 [2020/03/20 01:02] mihai.chiroiu |
cdci:labs:5 [2025/01/21 19:24] (current) mihai.chiroiu |
||
|---|---|---|---|
| Line 1: | Line 1: | ||
| - | ====== Lab05. Practical cryptography ====== | + | ====== Lab05. Network discovery ====== |
| <note warning> | <note warning> | ||
| Line 8: | Line 8: | ||
| ===== Objectives ===== | ===== Objectives ===== | ||
| - | * Hashing data to provide integrity | + | * Network discovery using nmap |
| - | * Use openssl for symmetric and asymmetric encryption | + | * Wireshark usage for protocol dissection |
| - | * Convert to base64 an encrypted message | + | |
| ===== Topology ===== | ===== Topology ===== | ||
| - | {{ :cdci:labs:cdci_lab05-crypto-topology.png?direct&600 |}} | + | For this lab you will have to discover the topology manually. |
| + | |||
| + | https://github.com/CiscoNetAcad/SEED | ||
| ===== Tasks ===== | ===== Tasks ===== | ||
| Line 20: | Line 21: | ||
| ==== 01. [5p] Virtual machine setup ==== | ==== 01. [5p] Virtual machine setup ==== | ||
| - | First, make sure that your virtual machine is updated (run the provided update.sh script, or create one). | + | First, make sure that your virtual machine is updated, run the provided update.sh script. |
| - | <code> | + | |
| - | root@cdci:/# cat update.sh | + | |
| - | #!/bin/bash | + | |
| - | # (c) Mihai Chiroiu - CDCI | + | |
| - | + | ||
| - | git clone -b labs --single-branch https://github.com/mihai-chiroiu/cdci.git | + | |
| - | git config user.email "student@upb.ro" | + | |
| - | </code> | + | |
| Next, in one terminal start the provided Mininet topology. | Next, in one terminal start the provided Mininet topology. | ||
| <code> | <code> | ||
| - | root@cdci:/# cd cdci/lab05 | + | root@cdci:/# cd cdci/labs/lab03 |
| root@cdci:/# /usr/bin/python3 topology.py | root@cdci:/# /usr/bin/python3 topology.py | ||
| </code> | </code> | ||
| - | If there are any problems with starting the topology (if all is good you should see the Mininet prompt ">") use the given cleanup script and try to restart the topology. | + | If there are any problems with starting the topology (if all is good you should see the Mininet prompt ">") use the given cleanup script and try to restart the topology. You will require a second (even third) ssh connection to the OpenStack VM. |
| - | ==== 02. [10p] Internet connectivity ==== | + | ==== 02. [10p] Connecting to the network ==== |
| - | Before you begin, make sure that you have Internet connectivity on all two nodes. R1 should be the gateway for the all of them. Write down the IP addresses of all the nodes (including the gateway). Use the provided scripts to access the nodes. | + | The main goal of the lab is to discover the network infrastructure and protocols available. The attacker is connected directly into sw0 using attacker-eth0. First, login into the attacker's docker using the "attacker_bash.sh" script (from ~/cdci/labs/lab03). |
| - | + | ||
| - | Download the following archive and extract it both nodes (Hint: wget is installed). https://ocw.cs.pub.ro/courses/_media/cdci/labs/upb-vs-harvard.zip . Download the archive also on your local computer and inspect the images. | + | |
| - | + | ||
| - | <code> | + | |
| - | root@ip-172-30-0-165:/# ./h1.sh | + | |
| - | root@attacker:/# | + | |
| - | + | ||
| - | root@ip-172-30-0-165:/# ./h2.sh | + | |
| - | root@victim:/# | + | |
| - | </code> | + | |
| + | The network uses DHCP, so you can get an IP address. Investigate the obtained resources via the DHCP protocol (IP address, routes, etc.) and write them down. | ||
| <solution> | <solution> | ||
| <code> | <code> | ||
| - | root@h2:~# wget https://ocw.cs.pub.ro/courses/_media/cdci/labs/upb-vs-harvard.zip | + | root@attacker:/# ip a f attacker-eth0 |
| - | root@h2:~# unzip upb-vs-harvard.zip | + | root@attacker:/# dhclient attacker-eth0 |
| - | root@h2:~# pwd | + | root@attacker:/# ip r s |
| + | 10.0.0.0/8 via 10.255.255.249 dev attacker-eth0 | ||
| + | 10.255.255.0/24 dev attacker-eth0 proto kernel scope link src 10.255.255.207 | ||
| + | root@attacker:/# ip a s | ||
| + | 165: attacker-eth0@if164: | ||
| + | inet 10.255.255.207/24 brd 255.255.255.255 scope global dynamic attacker-eth0 | ||
| </code> | </code> | ||
| </solution> | </solution> | ||
| - | ==== 03. [10p] Hashing ==== | + | ==== 03. [10p] DHCP protocol inspection ==== |
| - | - Use the MD5 hashing function and compare the files from the archive extracted previously. How do the hashes differ? What about the files, are they the same? Now, use other hashing functions and compare the result. | + | <note important> |
| - | - Download the latest version of the Firefox browser for Windows and compare the hash value to the official one. | + | For tcpdump to work inside the Docker container use '-Z root' as an argument. This will force tcpdump to run as a root. |
| - | - http://releases.mozilla.org/pub/firefox/releases/65.0b9/win64/en-US/ | + | </note> |
| - | - http://releases.mozilla.org/pub/firefox/releases/65.0b9/SHA256SUMS | + | |
| - | <solution> | + | Now, that you are connected to the network re-run the DHCP protocol and save it using "tcpdump". First, make sure that you flush the IP addresses on the interface ("ip a f"). You might need to open a second terminal to the attacker's docker. Open the saved capture on your local computer using Wireshark and inspect the DHCP process. Try to answer the following questions. |
| - | <code> | + | * How can you filter the traffic to view only the DHCP packets? |
| - | root@h1:~/upb-vs-harvard# md5sum upb.bmp | + | * What is the duration of the lease? |
| - | 2cbfabbbfb2adf0fea6ff8fbbaeaabae upb.bmp | + | * Can you identify the DHCP option regarding routing information? What number is it? Which is the network and next hop information? |
| - | root@h1:~/upb-vs-harvard# md5sum harvard.bmp | + | |
| - | 2cbfabbbfb2adf0fea6ff8fbbaeaabae harvard.bmp | + | |
| - | root@h1:~/# wget http://releases.mozilla.org/pub/firefox/releases/65.0b9/win64/en-US/Firefox%20Setup%2065.0b9.exe | + | ==== 04. [15p] Basic topology discovery ==== |
| - | root@h1:~/# sha256sum Firefox\ Setup\ 65.0b9.exe | + | |
| - | </code> | + | |
| - | </solution> | + | |
| - | ==== 04. [10p] Symmetric encryption ==== | + | |
| - | The openssl tool provides different mechanisms to encrypt data using symmetric cyphers. List all the available cyphers and modes of operation. Encrypt the ‘This is a cool lab’ text using aes-256-cbc mode and the password ‘thisisasupersecretpassword’. The output of the previous command is a not human-readable and cannot be easily used, add the ‘-base64’ parameter and verify the output. | + | Now that you know what your network is, find out all available hosts within your subnet. For this job you can use the "nmap" tool and perform a very fast ping scan. You got a hint that all the networks use a /24 mask and that the default gateway uses .1 as its IP address. Optimize the nmap scanning time, search in the nmap manual for timing and performance options (in the virtual environment the RTT is typically less than 5ms). |
| - | * Copy and decrypt the message on the other node. | + | |
| - | <solution> | + | <note tip> |
| - | <code> | + | To scan only for a [[https://nmap.org/book/man-target-specification.html|specific range]] of IP addresses you can use nmap range for target specification, e.g., 192.168.0-255.1. |
| - | root@h1:~# openssl list -cipher-commands | + | </note> |
| - | aes-128-cbc aes-128-ecb aes-192-cbc aes-192-ecb | + | |
| - | [...] | + | |
| - | root@h1:~# echo "This is a cool lab" | openssl aes-256-cbc -k thisisasupersecretpassword | + | |
| - | root@h1:~# echo "This is a cool lab" | openssl aes-256-cbc -k thisisasupersecretpassword -md sha512 -p -base64 -pbkdf2 | + | |
| - | salt=1F678051A7D00C6F | + | |
| - | key=C46100F8145E3C58BECD235C6F55C8CBD2CDCC15ACD9EB35C7815E70CF97330A | + | |
| - | iv =9B51ACC36B704923244B65190C3A1A0B | + | |
| - | U2FsdGVkX18fZ4BRp9AMb3QeOQYXFoR0lFCO7tXYAXiQ/tJmwAsbOM8yYjmWD6ku | + | |
| - | + | ||
| - | root@h2:~# echo "U2FsdGVkX18fZ4BRp9AMb3QeOQYXFoR0lFCO7tXYAXiQ/tJmwAsbOM8yYjmWD6ku" | openssl aes-256-cbc -k thisisasupersecretpassword -md sha512 -base64 -d -pbkdf2 | + | |
| - | This is a cool lab | + | |
| - | </code> | + | |
| - | </solution> | + | |
| - | + | ||
| - | ==== 05. [15p] ECB-mode encryption ==== | + | |
| - | + | ||
| - | In this exercise we will show how using a wrong encryption mode can break the encryption scheme. Let us try to encrypt the upb.bmp image using the AES-256-ECB mode. | + | |
| - | * Encrypt the image file using AES-256-ECB. | + | |
| - | * Recover the image-related metadata / header . This is required if we want the picture to be displayed properly. Note that the header is 54 bytes ([[http://www.onicos.com/staff/iz/formats/bmp.html|http://www.onicos.com/staff/iz/formats/bmp.html]]). You can use the "dd" tool for this purpose. | + | |
| - | * Last, transfer the encrypted image to your file (from the node to the virtual machine, and from the virtual machine to your computer). | + | |
| <note tip> | <note tip> | ||
| - | You can transfer file from the nodes (docker containers) to the host (virtual machine) using scp. | + | You should discover 5 gateways/networks in the topology. |
| - | </note> | + | </note> |
| <solution> | <solution> | ||
| <code> | <code> | ||
| - | root@h1:~/# openssl aes-256-ecb -k thisisasupersecretpassword -in upb.bmp -out upb_logo_enc.bmp -nosalt -pbkdf2 | + | nmap --min-hostgroup 256 -n -sn -T5 --max-retries 1 --min-parallelism=256 --max-rtt-timeout 5ms --min-rate 1024 10.0-255.0-255.1 |
| - | root@h1:~/# dd if=upb.bmp of=upb_logo_enc.bmp bs=6 count=9 conv=notrunc | + | |
| - | 9+0 records in | + | Nmap scan report for 10.5.140.1 |
| - | 9+0 records out | + | Host is up (0.00040s latency). |
| - | 54 bytes copied, 5.6056e-05 s, 963 kB/s | + | Nmap scan report for 10.7.6.1 |
| - | root@h1:~/# scp upb_logo_enc.bmp ubuntu@192.168.16.1:~/. | + | Host is up (0.0011s latency). |
| - | ubuntu@192.168.16.1's password: | + | Nmap scan report for 10.88.205.1 |
| - | upb_logo_enc.bmp 100% 733KB 381.8KB/s 00:01 | + | Host is up (0.0010s latency). |
| + | Nmap scan report for 10.155.20.1 | ||
| + | Host is up (0.00063s latency). | ||
| + | Nmap scan report for 10.255.255.1 | ||
| </code> | </code> | ||
| </solution> | </solution> | ||
| + | ==== 05. [15p] Routes discovery ==== | ||
| + | After finding out the IP addresses in use on the topology, let's find the routes to each subnet. Use traceroute to identify the path. | ||
| + | * What type of packets does the traceroute tool sent? Can you change it to use ICMP for discovery? | ||
| + | * What’s the TTL values in these packets? | ||
| + | * What type of ICMP packet does the host receive? | ||
| - | ==== 06. [10p] Digital signing ==== | + | ==== 06. [10p] Virtual machine setup ==== |
| - | Symmetric encryption is typically used for encrypting data, hashing is used for data integrity and asymmetric encryption is used for authentication. We can use ‘openssl dgst’ tool for signing files using DSA. | + | Send an ICMP echo request to one of the remote hosts and notice the ICMP redirect message. |
| - | * Create a DSA key pair and use it to sign the image file encrypted before. Use SHA256 for hashing the file. | + | * Who sends this message? |
| - | * Send the signed data to the other node and verify the signature. How could you distribute the public part of the DSA key? | + | * How is this message used? Can you block this message? (Hint: [[https://www.kernel.org/doc/Documentation/networking/ip-sysctl.txt|accept_redirects]]) |
| + | * Are there any (temporary) updates in the Linux routing table (use "ip route get" IP command)? | ||
| + | * Update the network topology to include the new information. | ||
| - | <note tip> | + | ==== 07. [10p] Port scanning ==== |
| - | For file transfer between the two nodes you can use scp via the virtual machine. You can also start the ssh daemon on the nodes if you want. | + | |
| - | </note> | + | Now, it is time to discover the running services for each remote network. Ignore the services on the local network for the next exercises (i.e., 10.255.255.0/24). Write down the IP addresses and the open ports. |
| <solution> | <solution> | ||
| <code> | <code> | ||
| - | root@h1:~/# openssl genpkey -genparam -algorithm DSA -pkeyopt dsa_paramgen_bits:2048 -pkeyopt dsa_paramgen_q_bits:256 -pkeyopt dsa_paramgen_md:sha256 -out dsaparams.pem | + | root@attacker:/# nmap -T4 10.5.140.0/24 |
| - | root@h1:~/# openssl genpkey -paramfile dsaparams.pem -out dsaprivkey.pem | + | Starting Nmap 7.80 ( https://nmap.org ) at 2020-03-13 17:02 UTC |
| - | root@h1:~/# openssl dsa -in dsaprivkey.pem -pubout > dsapubkey.pem | + | Nmap scan report for 10.5.140.1 |
| - | root@h1:~/# openssl dgst -sha256 -sign dsaprivkey.pem upb_logo_enc.bmp > upb.sig | + | Host is up (0.000020s latency). |
| - | root@h1:~/# scp upb_logo_enc.bmp upb.sig dsapubkey.pem ubuntu@192.168.16.1:~/. | + | All 1000 scanned ports on 10.5.140.1 are closed |
| - | root@h2:~# scp ubuntu@192.168.16.1:~/upb.sig ubuntu@192.168.16.1:~/upb_logo_enc.bmp ubuntu@192.168.16.1:~/dsapubkey.pem . | + | Nmap done: 256 IP addresses (1 host up) scanned in 26.00 seconds |
| - | root@h2:~# ls | + | |
| - | dsapubkey.pem upb.sig upb_logo_enc.bmp | + | |
| - | root@h2:~# openssl dgst -sha256 -verify dsapubkey.pem -signature upb.sig upb_logo_enc.bmp | + | |
| - | Verified OK | + | |
| </code> | </code> | ||
| - | </solution> | + | <code> |
| + | root@attacker:/# nmap -T4 10.7.6.0/24 | ||
| + | Starting Nmap 7.80 ( https://nmap.org ) at 2020-03-13 17:04 UTC | ||
| + | Nmap scan report for 10.7.6.1 | ||
| + | Host is up (0.000019s latency). | ||
| + | All 1000 scanned ports on 10.7.6.1 are closed | ||
| - | ==== 07. [10p] Certificate Signing Request ==== | + | Nmap scan report for 10.7.6.2 |
| + | Host is up (0.000023s latency). | ||
| + | Not shown: 999 closed ports | ||
| + | PORT STATE SERVICE | ||
| + | 8080/tcp open http-proxy | ||
| - | Asymmetric encryption schemes are used in certificates to authenticate and encrypt data in transit. In this exercise we are going to create a CSR (Certificate Signing Request), which includes the public key of your server. Note that this CSR must be signed by a Certificate Authority before being used. | + | Nmap done: 256 IP addresses (2 hosts up) scanned in 24.93 seconds |
| - | * Generate a 2048 bits private-public RSA key. Note, that while in practice the private key should be protected using a symmetric key, in this lab we assume that you don’t. Display the public key part of the generated pair. How about the private one? | + | </code> |
| - | * Use the previously generated key and create a new CSR that should be saved to the ‘ServerCertificateRequest.csr’ file. | + | <code> |
| - | * Print the public key stored in the CSR certificate and compare it with the one generated in the first step. | + | root@attacker:/# nmap -T4 10.88.205.0/24 |
| + | Starting Nmap 7.80 ( https://nmap.org ) at 2020-03-13 17:02 UTC | ||
| + | Nmap scan report for 10.88.205.1 | ||
| + | Host is up (0.000017s latency). | ||
| + | All 1000 scanned ports on 10.88.205.1 are closed | ||
| - | <solution> | + | Nmap scan report for 10.88.205.2 |
| + | Host is up (0.000023s latency). | ||
| + | Not shown: 999 closed ports | ||
| + | PORT STATE SERVICE | ||
| + | 53/tcp open domain | ||
| + | |||
| + | Nmap done: 256 IP addresses (2 hosts up) scanned in 17.87 seconds | ||
| + | </code> | ||
| <code> | <code> | ||
| - | root@h1:~# openssl genrsa -out RSAKEYPAIR.pem 2048 | + | root@attacker:/# nmap -T4 10.155.20.0/24 |
| - | root@h1:~# openssl rsa -in RSAKEYPAIR.pem -pubout | + | Starting Nmap 7.80 ( https://nmap.org ) at 2020-03-13 17:04 UTC |
| - | root@h1:~# openssl rsa -in RSAKEYPAIR.pem -text | + | Nmap scan report for 10.155.20.1 |
| - | root@h1:~# openssl req -out ServerCertificateRequest.csr -new -key RSAKEYPAIR.pem | + | Host is up (0.000016s latency). |
| - | root@h1:~# openssl req -in ServerCertificateRequest.csr -pubkey | + | All 1000 scanned ports on 10.155.20.1 are closed |
| + | |||
| + | Nmap scan report for 10.155.20.2 | ||
| + | Host is up (0.000023s latency). | ||
| + | Not shown: 999 closed ports | ||
| + | PORT STATE SERVICE | ||
| + | 80/tcp open http | ||
| + | |||
| + | Nmap done: 256 IP addresses (2 hosts up) scanned in 25.98 seconds | ||
| </code> | </code> | ||
| </solution> | </solution> | ||
| + | ==== 08. [10p] Services scanning ==== | ||
| - | ==== 08. [10p] Digital signing ==== | + | As you have already noticed, there is an DNS server running in the remote network. Use it to find out what is the named of the other two servers you discovered. |
| - | + | ||
| - | In this exercise you will be required to analyze an already signed certificate from the www.google.com website. | + | |
| - | * Use the s_client suite from openssl and download the top chain certificate locally (Hint: signed by GlobalSign Root CA). Note that there might be a chain of certificates, save each one in a different file. | + | |
| - | * What is the public key of the certificate? Compare it to the one viewed in browser (use Firefox for a simplified view). | + | |
| - | * Use ‘openssl verify’ to test the correctness of the certificate. Does the verification of the certificate work? | + | |
| <solution> | <solution> | ||
| - | <code> | + | root@attacker:/# nslookup 10.7.6.2 10.88.205.2 |
| - | root@h1:/# openssl s_client -host www.google.com -port 443 -prexit -showcerts | + | 2.6.7.10.in-addr.arpa name = vulnerable.iot.dashboard. |
| - | root@h1:/# cat www.google.pem | + | </solution> |
| - | -----BEGIN CERTIFICATE----- | + | |
| - | MIIESjCCAzKgAwIBAgINAeO0mqGNiqmBJWlQuDANBgkqhkiG9w0BAQsFADBMMSAw | + | |
| - | HgYDVQQLExdHbG9iYWxTaWduIFJvb3QgQ0EgLSBSMjETMBEGA1UEChMKR2xvYmFs | + | |
| - | U2lnbjETMBEGA1UEAxMKR2xvYmFsU2lnbjAeFw0xNzA2MTUwMDAwNDJaFw0yMTEy | + | |
| - | MTUwMDAwNDJaMEIxCzAJBgNVBAYTAlVTMR4wHAYDVQQKExVHb29nbGUgVHJ1c3Qg | + | |
| - | U2VydmljZXMxEzARBgNVBAMTCkdUUyBDQSAxTzEwggEiMA0GCSqGSIb3DQEBAQUA | + | |
| - | A4IBDwAwggEKAoIBAQDQGM9F1IvN05zkQO9+tN1pIRvJzzyOTHW5DzEZhD2ePCnv | + | |
| - | UA0Qk28FgICfKqC9EksC4T2fWBYk/jCfC3R3VZMdS/dN4ZKCEPZRrAzDsiKUDzRr | + | |
| - | mBBJ5wudgzndIMYcLe/RGGFl5yODIKgjEv/SJH/UL+dEaltN11BmsK+eQmMF++Ac | + | |
| - | xGNhr59qM/9il71I2dN8FGfcddwuaej4bXhp0LcQBbjxMcI7JP0aM3T4I+DsaxmK | + | |
| - | FsbjzaTNC9uzpFlgOIg7rR25xoynUxv8vNmkq7zdPGHXkxWY7oG9j+JkRyBABk7X | + | |
| - | rJfoucBZEqFJJSPk7XA0LKW0Y3z5oz2D0c1tJKwHAgMBAAGjggEzMIIBLzAOBgNV | + | |
| - | HQ8BAf8EBAMCAYYwHQYDVR0lBBYwFAYIKwYBBQUHAwEGCCsGAQUFBwMCMBIGA1Ud | + | |
| - | EwEB/wQIMAYBAf8CAQAwHQYDVR0OBBYEFJjR+G4Q68+b7GCfGJAboOt9Cf0rMB8G | + | |
| - | A1UdIwQYMBaAFJviB1dnHB7AagbeWbSaLd/cGYYuMDUGCCsGAQUFBwEBBCkwJzAl | + | |
| - | BggrBgEFBQcwAYYZaHR0cDovL29jc3AucGtpLmdvb2cvZ3NyMjAyBgNVHR8EKzAp | + | |
| - | MCegJaAjhiFodHRwOi8vY3JsLnBraS5nb29nL2dzcjIvZ3NyMi5jcmwwPwYDVR0g | + | |
| - | BDgwNjA0BgZngQwBAgIwKjAoBggrBgEFBQcCARYcaHR0cHM6Ly9wa2kuZ29vZy9y | + | |
| - | ZXBvc2l0b3J5LzANBgkqhkiG9w0BAQsFAAOCAQEAGoA+Nnn78y6pRjd9XlQWNa7H | + | |
| - | TgiZ/r3RNGkmUmYHPQq6Scti9PEajvwRT2iWTHQr02fesqOqBY2ETUwgZQ+lltoN | + | |
| - | FvhsO9tvBCOIazpswWC9aJ9xju4tWDQH8NVU6YZZ/XteDSGU9YzJqPjY8q3MDxrz | + | |
| - | mqepBCf5o8mw/wJ4a2G6xzUr6Fb6T8McDO22PLRL6u3M4Tzs3A2M1j6bykJYi8wW | + | |
| - | IRdAvKLWZu/axBVbzYmqmwkm5zLSDW5nIAJbELCQCZwMH56t2Dvqofxs6BBcCFIZ | + | |
| - | USpxu6x6td0V7SvJCCosirSmIatj/9dSSVDQibet8q/7UK4v4ZUN80atnZz1yg== | + | |
| - | -----END CERTIFICATE----- | + | |
| - | root@h1:/# openssl x509 -in www.google.pem -pubkey | + | ==== 09. [15p] Virtual machine setup ==== |
| - | -----BEGIN PUBLIC KEY----- | + | |
| - | MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA0BjPRdSLzdOc5EDvfrTd | + | |
| - | aSEbyc88jkx1uQ8xGYQ9njwp71ANEJNvBYCAnyqgvRJLAuE9n1gWJP4wnwt0d1WT | + | |
| - | HUv3TeGSghD2UawMw7IilA80a5gQSecLnYM53SDGHC3v0RhhZecjgyCoIxL/0iR/ | + | |
| - | 1C/nRGpbTddQZrCvnkJjBfvgHMRjYa+fajP/Ype9SNnTfBRn3HXcLmno+G14adC3 | + | |
| - | EAW48THCOyT9GjN0+CPg7GsZihbG482kzQvbs6RZYDiIO60ducaMp1Mb/LzZpKu8 | + | |
| - | 3Txh15MVmO6BvY/iZEcgQAZO16yX6LnAWRKhSSUj5O1wNCyltGN8+aM9g9HNbSSs | + | |
| - | BwIDAQAB | + | |
| - | -----END PUBLIC KEY----- | + | |
| - | root@h1:/# openssl verify -verbose www.google.pem | + | Lets try and see what the webserver offers. Unfortunately, the text-only version of Kali provides only a text-based browser, lynx. Start a capture on the interface and save it for later analysis, while browsing the website and reading Instructions webpage. The username and password for the site are admin / password. |
| - | www.google.pem: OK | + | * Use Wireshark to view the passwords sent and to save the page opened. Use File->Export Objects->HTTP and change the file extension to HTML so that you can open it locally. |
| - | # if we use the first certificate | + | <note tip> |
| - | root@h1:/# openssl verify -verbose www.google.pem | + | Use 'tcpdump -Z root' to prohibit privileges dropping. |
| - | C = US, ST = California, L = Mountain View, O = Google LLC, CN = www.google.com | + | </note> |
| - | error 20 at 0 depth lookup: unable to get local issuer certificate | + | |
| - | error www.google.pem: verification failed | + | |
| + | <solution> | ||
| + | <code> | ||
| + | root@attacker:~/#tcpdump -Z root -n -i attacker-eth0 -w http.pcap | ||
| + | tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes | ||
| + | ^C55 packets captured | ||
| + | 55 packets received by filter | ||
| + | 0 packets dropped by kernel | ||
| + | root@kali:~# lynx 10.155.20.2 | ||
| </code> | </code> | ||
| </solution> | </solution> | ||
| - | |||
