I want to emphasize the importance of cybersecurity by showing how a few bad practices can disclose supposedly secure information. Moreover, I want to emphasize the tools that

# This Demo is Not...
* How to hack your friend’s FaceBook
* How to become an evil hacking mastermind
* How to control the Matrix

# Materials
* Control of Wifi network and wifi's DNS, if using physical hardware, or some method of controlling routing.
* Demo computer (VM or physical)
    * For easy installation, install [[ShadowArch#How_to_Install_ShadowArch|ShadowArch]] with a graphical environment and a Holocron layout.
    * Run the following. This Makefile is viewable in [https://aninix.net/foundation/ConfigPackages the ConfigPackages git repo]. <pre>make -C /usr/local/src/ConfigPackages/WhiteHatDemo democlient</pre>
    * You will still need to sync /etc/hosts with the demo server.
    * Users can access a virtualized demo client with VNC over [[SSH]].
* Demo server with lighttpd, telnet server, ftp server, OpenSSH server, Wireshark.
    * For easy installation, install ShadowArch with the GUI option, and run the following: <pre>make -C /usr/local/src/ConfigPackages/WhiteHatDemo demoserver</pre>
    * Lighttpd should be configured with both unsecured and secured traffic.
    * Lighttpd will need one URL that is auth protected -- simple auth is sufficient.
    * There should be a remote-capable user "testuser" with a preset initial password.
    * You should also sync /etc/hosts with any demo clients.
* [https://www.kali.org/ Kali Linux] iso -- if you're using physical hardware for the demo, use a [[Holocron]] flashdrive
* A demo user with a read-write VNC view of the democlient, a pentester with physical access to the server and client, and a class with read-only VNC sessions watching the client.

# Exercises
##  Account Credentials
<!-- This should be updated to be a BurpSuite assault -->[[Category:TODO]]
* An obviously dumb password should be set in the server's /etc/lighttpd/.lighttpdpassword and disclosed to the demouser.
* The pentester "guesses" the password and discloses why it's weak.
* Talk about [http://www.businessinsider.com/how-to-create-strong-password-heartbleed-2014-4 strong passwords].
### Mobile PIN Break
* Talk about how PINs are important
* Talk about guessing pins from smudges
* Financial data, email accounts, text messages, and such are all accessible.
* Talk about [https://en.wikipedia.org/wiki/Phishing phisihing] via a captured phone with SMS
## Encrypted network traffic
The key takeaway is to encrypt all network traffic. While a [https://en.wikipedia.org/wiki/VPN VPN] and similar network encryption models help, these tools are very simple and controllable.
### Browsers
[https://en.wikipedia.org/wiki/SSL SSL] allows us to validate that we are talking to the site we expect to.
* Use wget to mirror a login page to the demo server. The Makefile defaults to facebook.com.
* Redirect the traffic to unsecured traffic
* Have the demo user connect to the site over unsecured HTTP.
* Have a user connect to the same site over HTTPS and see the warning message.
* Optionally, remove the diverted routing and have the user reconnect to the site over HTTPS without seeing the warning.
* Capture traffic on [https://www.wireshark.org/ Wireshark] and ask the demo user to confirm their password in the capture.
* Talk about SSL chain of trust.

SSL encryption also prevents capturing session information.
* Have the demo user go to the demoserver's web server over unsecured HTTP.
* The root page will have a POST HTML form.
* Use Wireshark to capture the data and show the TCP stream.
* Have the demo user repeat the process over HTTPS.
* SSL will prevent following the stream.

### Telnet/FTP
* Have the demo user reset his password on the server with telnet.
* Capture traffic with Wireshark and show the password.
* Have the demo user pull down a file over FTP, change it, and put it back up.
* Capture traffic with Wireshark and show the change.
* Explain SFTP/SSH correlation to HTTPS -- encryption matters.

## Storage bypass w/ iso
[https://wiki.archlinux.org/index.php/Disk_encryption Disk encryption] makes it harder to access data. While physical access is death, strong encryption can delay access beyond heat death of the universe, which is long enough.
* Have the demo user set the root password and add a file in /root.
* Power off the machine and have the pentester take control.
* Ask the class if the files are secure.
* Boot the machine with the iso instead and find the file.
    * Optionally, set the root password and boot the original system.
* Talk about encrypted storage and how this recovery would be harder.
### File recovery
Just because a system has files deleted from it doesn't mean that the data is lost.
* dd 0's onto small partition on demo server
* Create ext4 filesystem
* Have the demouser create a file, display its contents, and delete it.
* The pentester "steals" the hardware and boots with a Kali iso
* Run "extundelete <disk> --restore-all -o /root" to recover the file
* Talk about secure deletion with shred or similar programs and the added difficulty of disk encryption.


[[Category:Class]]
[[Category:Security]]