80 lines
5.1 KiB
Markdown
80 lines
5.1 KiB
Markdown
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]] |