I have a daughter who is studying abroad, which is driving me to spend time thinking about how to aide her towards patterns that are healthy.
The Inspiration
I ran into a diagram about human emotions during a video about music theory. The video was describing the properties of various chord progressions and the feelings they tend to generate.
In this diagram, there are six fundamental emotions represented:
Fear
Anger
Disgust
Surprise
Sad
Happy
In this model, only 1/6 of the fundamental classes of emotion we experience are about flourishing. 5/6 of our fundamental emotions are about fight or flight instincts. That’s a lot of opportunity to feel anything but Happy. During my weekly call with my daughter, I ask how she spends time cultivating feelings of hope, playfulness and inspiration.
These are not naturally easy discussions. Anyone with a teenager knows you must go where the conversation goes. Structure helps remind me to stay positive and consistently nudge her towards positive outcomes.
This has lead me to think about what it means to invest time into building team happiness. It’s affecting my perspective about what kind of team I want to build. I think it’s helpful- which is why I’m sharing this with you today.
When I get feedback from peers and partners, this chart helps me do a check to discover if trends are developing that require a change. Security teams get better engagement when partners trust you. People using language associated with emotions of fear, anger, disgust and surprise give you a signal about your impact.
I look at the language my partners and peers use and explore where they align against this wheel.
Ask yourself if the feedback you receive is aligning with the emotions you’re hoping to cultivate in your teams. If you’re ending up in emotions you didn’t anticipate, you may need to explore how you can rebuild trust.
The larger video isn’t great, but I liked the chart. If you’re more interested in the music theory discussion, you can check it out here:
Happy teams require intention. What are you doing to cultivate confidence, courage, provocative inspiration, confidence and respect in your teams?
1995: SHA-0 was published by the National Institute of Standards and Technology (NIST) as a cryptographic hash function.
1996: SHA-0 was found to have serious flaws by cryptographers, leading NIST to revise the design and release SHA-1 as a replacement.
2005: A group of cryptographers discovered a theoretical attack on SHA-1 that would allow for collisions to be found in about 2^69 operations, making it vulnerable to a “collision attack”.
2006: A team of researchers from Shandong University in China presented a practical collision attack on SHA-1, allowing them to generate two different messages with the same hash value.
2008: The first verifiably successful attack on SHA-1 was announced by a team of researchers from the French National Institute for Research in Computer Science and Control (INRIA) and the École Polytechnique Fédérale de Lausanne (EPFL), which could produce collisions in just 2^52 operations.
2010: A team of researchers from the Netherlands and Germany presented an attack that could break SHA-1 by finding a collision in 2^51 operations.
2015: Google researchers announced that they had successfully created two PDF files with different content but the same SHA-1 hash, marking the first time that a practical attack on the algorithm had been demonstrated in the wild.
2017: Researchers from the CWI Amsterdam and Google announced a “collision attack” on SHA-1 that could generate two different PDF files with the same SHA-1 hash in about 2^63 operations, demonstrating the algorithm’s vulnerability to attacks in practice.
2020: SHA-1 is no longer considered secure for any use and is officially deprecated by NIST. It is recommended to switch to more secure hash functions such as SHA-256 or SHA-3.
Practical collision attack on SHA-1 presented in 2006: Xiaoyun Wang, Yiqun Lisa Yin, and Hongbo Yu. “Collisions for Hash Functions MD4, MD5, HAVAL-128 and RIPEMD.” EUROCRYPT 2005. Springer, Berlin, Heidelberg, 2005. https://link.springer.com/chapter/10.1007/11426639_17 Verifiably successful attack on SHA-1 in 2008: Marc Stevens, Arjen K. Lenstra, and Benne de Weger. “The first collision for full SHA-1.” CRYPTO 2017. Springer, Cham, 2017. https://link.springer.com/chapter/10.1007/978-3-319-63715-0_17
SHA-1 presented in 2010: Thomas Peyrin and Pierre Karpman. “Predicting and Distinguishing Attacks on SHA-0 and SHA-1.” EUROCRYPT 2010. Springer, Berlin, Heidelberg, 2010. https://link.springer.com/chapter/10.1007/978-3-642-13190-5_22
SHA-1 demonstrated by Google in 2015: Marc Stevens, Elie Bursztein, Pierre Karpman, Ange Albertini, and Yarik Markov. “The first SHA-1 collision.” Google Security Blog, February 23, 2017. https://security.googleblog.com/2017/02/announcing-first-sha1-collision.html
Collision attack on SHA-1 demonstrated by researchers from CWI Amsterdam and Google in 2017: Marc Stevens, Elie Bursztein, Pierre Karpman, Ange Albertini, Yarik Markov, and A. J. Bernstein. “The SHAttered Cryptographic Hash Function Collision Attack.” EUROCRYPT 2017. Springer, Cham, 2017. https://link.springer.com/chapter/10.1007/978-3-319-56617-7_24
official deprecation of SHA-1 by NIST in 2020: National Institute of Standards and Technology. “SHA-1 Deprecation Notice.” Federal Register, May 7,
History of discoveries of weakness in SHA-1:
1995: SHA-0 was published by the National Institute of Standards and Technology (NIST) as a cryptographic hash function.
1996: SHA-0 was found to have serious flaws by cryptographers, leading NIST to revise the design and release SHA-1 as a replacement.
2005: A group of cryptographers discovered a theoretical attack on SHA-1 that would allow for collisions to be found in about 2^69 operations, making it vulnerable to a “collision attack”.
2006: A team of researchers from Shandong University in China presented a practical collision attack on SHA-1, allowing them to generate two different messages with the same hash value.
2008: The first verifiably successful attack on SHA-1 was announced by a team of researchers from the French National Institute for Research in Computer Science and Control (INRIA) and the École Polytechnique Fédérale de Lausanne (EPFL), which could produce collisions in just 2^52 operations.
2010: A team of researchers from the Netherlands and Germany presented an attack that could break SHA-1 by finding a collision in 2^51 operations.
2015: Google researchers announced that they had successfully created two PDF files with different content but the same SHA-1 hash, marking the first time that a practical attack on the algorithm had been demonstrated in the wild.
2017: Researchers from the CWI Amsterdam and Google announced a “collision attack” on SHA-1 that could generate two different PDF files with the same SHA-1 hash in about 2^63 operations, demonstrating the algorithm’s vulnerability to attacks in practice.
2020: SHA-1 is no longer considered secure for any use and is officially deprecated by NIST. It is recommended to switch to more secure hash functions such as SHA-256 or SHA-3.
Practical collision attack on SHA-1 presented in 2006: Xiaoyun Wang, Yiqun Lisa Yin, and Hongbo Yu. “Collisions for Hash Functions MD4, MD5, HAVAL-128 and RIPEMD.” EUROCRYPT 2005. Springer, Berlin, Heidelberg, 2005. https://link.springer.com/chapter/10.1007/11426639_17 Verifiably successful attack on SHA-1 in 2008: Marc Stevens, Arjen K. Lenstra, and Benne de Weger. “The first collision for full SHA-1.” CRYPTO 2017. Springer, Cham, 2017. https://link.springer.com/chapter/10.1007/978-3-319-63715-0_17
SHA-1 presented in 2010: Thomas Peyrin and Pierre Karpman. “Predicting and Distinguishing Attacks on SHA-0 and SHA-1.” EUROCRYPT 2010. Springer, Berlin, Heidelberg, 2010. https://link.springer.com/chapter/10.1007/978-3-642-13190-5_22
SHA-1 demonstrated by Google in 2015: Marc Stevens, Elie Bursztein, Pierre Karpman, Ange Albertini, and Yarik Markov. “The first SHA-1 collision.” Google Security Blog, February 23, 2017. https://security.googleblog.com/2017/02/announcing-first-sha1-collision.html
Collision attack on SHA-1 demonstrated by researchers from CWI Amsterdam and Google in 2017: Marc Stevens, Elie Bursztein, Pierre Karpman, Ange Albertini, Yarik Markov, and A. J. Bernstein. “The SHAttered Cryptographic Hash Function Collision Attack.” EUROCRYPT 2017. Springer, Cham, 2017. https://link.springer.com/chapter/10.1007/978-3-319-56617-7_24
official deprecation of SHA-1 by NIST in 2020: National Institute of Standards and Technology. “SHA-1 Deprecation Notice.” Federal Register, May 7,
I built the “FirmwareBuilder” to make it easy for people to build raspberry pi images using Ansible. Not everyone has two Raspberry pi’s unfortunately. 😥
I built docker containers that can help you make reproducible single board computer projects. Now you can get by with only one raspberry pi!
This overview video explains how everything works!
Want to try it out? Check out instructions here to get started! Let me know how it works for you!
I needed a way to collaborate on raspberry pi development. I wanted to make it possible for others to reproduce my builds without demanding that they manually execute command after command to reproduce my project. I also wanted a solution that saves time by caching redundant downloads. So I built the “Builderhotspot“
There is a disadvantage to using the builderhotspot- not everyone has at least 2 raspberry pi’s.
I needed a solution that works if you have only one pi, so I turned to docker. I’ve created a docker-compose file that will spin up an ansible container & an apt-cacher-ng container which can be used to push firmware images to any devices on your network with the hostname of “ansibledest.local”
This tutorial assumes you have docker installed on a host system- and that somewhere on your network is a raspberry pi attached under the hostname of “ansibledest.local”
Step 1: Clone the FirmwareBuilderContainers project into your directory of choice.
On your host operating system, cd into a directory where you want to host your Firmware Builder Containers. I use ~/Development/containers.
Step 2: Modify the Docker-compose script to reflect the details of your host system
There are 3 modifications you’ll need to make to the docker-compose file you just cloned:
DOCKER_HOST
The docker-compose file’s DOCKER_HOST variable tunes the recipient device to use your local apt-cache-ng container. This reduces redundant apt-get install downloads. It sets the server hostname values in the /etc/apt/sources.list and /etc/apt/sources.list.d/raspi.list files on the recipient device so that it pulls downloads from the caching server. My firmware recipes use this value as control logic.
The value will be “builderhotspot.local” if you use the builderhotspot to push recipes to devices. Since we’re going to use containers- we need to set the value to reflect your host os’s hostname. To get the hostname of a system, you can use different commands on Windows, macOS, and Linux. Here are the commands for each operating system:
Windows
Command Prompt:
hostname
PowerShell:
hostname
or
$env:COMPUTERNAME
Mac & Linux
hostname
Alternatively, you can also use the uname -n command to retrieve the hostname on a linux system. Open the docker-compose.yml file and browse to the section for the ansible container. Note the “environment:” section. Change the DOCKER_HOST value to reflect your host system’s hostname.
VOLUMES
We need to expose two directories from the host system to the ansible container. This is done by specifying a volume & indicating where in the container it should be accessible.
The first volume is our playbooks directory. This is where we will story playbooks for all the projects we want to push to devices. You can git clone playbooks for other projects into this directory from the Host operating system. They will be exposed in the /home/pi/Playbooks directory on your ansible container.
Change the first volume’s value to reflect the correct directory on your host system. Be sure to retain
:/home/pi/Playbooks
at the end of the first line. This is how we specify the location. My playbooks are designed to run on both the builderhotspot as well as via containers- but if you modify this second value, the playbooks won’t work without modifications.
The second volume is for enabling mdns resolution. In our playbooks we want to use hostnames to specify the recipient device. This makes pushing a playbook to a target device easy. You don’t have to discover the recipient device’s IP address. You only need to know it’s hostname. This keeps life simple. If you’re on linux, the best way to do this is to share the avahi-daemon socket on the host system as a volume. If you skip this step, name resolution won’t work within the ansible container. I don’t think you need to change this value on a mac- it seems to work on my system. I still need to test this on a Windows machine to confirm mdns works. works.
Step 3: Build & launch the containers
cd ~/Development/containers/FirmwareBuilderContainers
Build the containers & run them detached.
docker-compose up --build -d
Step 4: Attach to the ansible container & test connectivity:
docker exec -it ansible bash
If you have an ansibledest system running on your network, you should be able to ping it:
root@docker-desktop:/# ping ansibledest.local
PING ansibledest.local (192.168.6.247) 56(84) bytes of data.
64 bytes from 192.168.6.247 (192.168.6.247): icmp_seq=1 ttl=63 time=0.898 ms
64 bytes from 192.168.6.247 (192.168.6.247): icmp_seq=2 ttl=63 time=1.12 ms
Step 5: Detach from your containers & deactivate the containers:
From within the ansible container, type “exit” to leave the container. Then use the docker-compose command to deactivate the containers:
docker-compose down
Step 6 (From this point forward, the only commands you’ll really need when building):
From now on, we skip the build commands. Run the docker-compose command from within the container directory on your host system:
docker-compose up
docker-exec -it ansible bash
Step 7: Building a firmware example
You now should be good to go to use Docker Containers for pushing my firmware recipes to your devices. To try out the “hack this wifi” firmware, Go to your Host OS’s terminal and cd into the playbook directory ( I use /Users/Patrick/Development/Playbooks/DockerVolume). Run the following command:
If you run ls, you should see the “Learn_Linux_Networking_And_Hacking” directory. cd into it:
cd /home/pi/Playbooks/Learn_Linux_Networking_And_Hacking
If your ansibledest system is online, you can copy the container’s ssh key to the destination system, which enables you to use ansible to install software on the recipient device:
ssh-copy-id pi@ansibledest.local
And now you can deploy the firmware:
ansible-playbook run.yml
If for some reason you forgot to set your hosts file, you can fix this in ansible for your container’s session with the “export DOCKER_HOST=hostname.local” command- where hostname.local is your host system’s hostname.
Security leaders working on security sustainment programs should set three goals for their team:
Implement controls that make it easy for development teams to consistently deliver high-quality outputs.
Implement controls that test for the existence of known negative outcomes.
Implement controls that prevent known negative outcomes.
VULNERABILITY MANAGEMENT programs are crucial for maintaining the security of your company. These programs involve various methods to track and address vulnerabilities associated with outdated and misconfigured systems. In less mature organizations, vulnerability management can be challenging. Some perceive patching as insignificant work, while others rely too heavily on automated vulnerability scanners, leading to complacency. However, obtaining funding for a vulnerability management program is just the beginning. Executing vulnerability management effectively is crucial to protecting customer data and maintaining trust, as regulatory fines can deplete resources.
To emphasize the importance of vulnerability management, it is essential to present a use case that demonstrates the consequences of neglecting vulnerabilities. You have to arm your audience with examples of failures that are relevant to your audience. The use case should also highlight the implications of an inadequate vulnerability management program. Although it may not be an exciting issue to address, it is necessary to help people understand the dangers of complacency. This is not a fun problem to tackle, Sisyphus. Vulnerability Management is never finished. You must help people understand the danger of complacency.
Why do we need vulnerability management?
Think of Vulnerability Management as regular car maintenance. Similar to checking the car’s oil, inspecting the brakes, and replacing worn-out tires to ensure optimal performance and safety, continuously measuring vulnerabilities in your enterprise environment is essential. You must also measure the mean time to resolution and aim to keep it within acceptable limits.
Software vulnerabilities exist, even before they are assigned CVE numbers and become widely known. Humans make mistakes that can be exploited. A simple way to view software vulnerabilities is as indicators of software quality. If you want to increase the chances of delivering high-quality work, you need to test for the existence of defects. Skilled tradespeople know where mistakes are likely to occur in projects and test for their presence.
How can you pitch a vulnerability management program?
Part of the challenge of launching a vulnerability management program is you need anecdotes that persuade funding sources of the importance of this boring & tedious activity. It is common for developers and managers to underestimate security impacts. You need a realistic use case that helps shortcut bad-faith discussions from parties whose execution demands improvement. So here is an example to build your argument for your quantifiable vulnerability management reporting program.
Don’t be like Equifax: Why you need a measurable, sustaining Vulnerability Management program with monthly reporting
The Federal Trade Commission Act (FTCA): The Federal Trade Commission (FTC) has the authority to bring enforcement actions against companies that engage in “unfair or deceptive acts or practices.” This authority has been used in the past to penalize companies that fail to adequately protect consumer data.
In 2017, https://en.wikipedia.org/wiki/2017_Equifax_data_breach. “Private records of 147.9 million Americans along with 15.2 million British citizens and about 19,000 Canadian citizens were compromised in the breach, making it one of the largest cyber crimes related to identity theft.”
“The total cost of the settlement included $300 million to a fund for victim compensation, $175 million to the states and territories in the agreement, and $100 million to the CFPB in fines”
March 8, 2017, (“US-CERT”) alerted Equifax to a new critical security vulnerability (referred to as 2017-CVE-5638) found in Apache Struts
Security team received the US-CERT alert and, on or about March 9, 2017, disseminated the alert internally by a mass email to more than 400 employees. The mass email directed employees, “if [they were] responsible for an Apache Struts installation,” to patch the vulnerability within 48 hours
The ACIS Dispute Portal contained a vulnerable version of Apache Struts. However, Equifax failed to apply the patch to the ACIS Dispute Portal for months. Although Equifax’s security team issued an order to patch all vulnerable systems within 48 hours, Equifax failed to send the email ordering a patch to the employee responsible for maintaining the ACIS Dispute Portal.
On or about March 15, 2017, Equifax performed an automated vulnerability scan intended to search for vulnerable instances of Apache Struts that remained on Equifax’s network. But Equifax used a scanner that was not configured to correctly search all of Equifax’s potentially vulnerable assets. As a result, the automated scanner did not identify any systems vulnerable to 2017-CVE- 5638 and the ACIS Dispute Portal remained unpatched.
On or about July 29, 2017, Equifax’s security team identified some suspicious traffic on the ACIS Dispute Portal after replacing expired security certificates.
Equifax retained a forensic consultant who ultimately determined that between May 13, 2017 and July 30, 2017, multiple attackers were each able to separately exploit the 2017-CVE-5638 vulnerability in the ACIS Dispute Portal to gain unauthorized access to Equifax’s network. Once inside, the attackers were able to crawl through dozens of unrelated databases containing information that went well beyond the ACIS Dispute Portal, in part because of a lack of network segmentation. The attackers also accessed an unsecured file share (or common storage space) connected to the ACIS databases where they discovered numerous administrative credentials, stored in plain text, that they used to obtain further access to Equifax’s network.
According to Equifax’s forensic analysis, the attackers were able to steal approximately 147 million names and dates of birth, 145.5 million SSNs, 99 million physical addresses, 20.3 million telephone numbers, 17.6 million email addresses and 209,000 payment card numbers and expiration dates, among other things.
Social Engineering your Corporate Colleagues to Embrace Vulnerability Management
When pitching the vulnerability management program, make it clear that it aims to protect the reputation of the person opposing your pitch. By avoiding predictable and repeatable situations like the Equifax breach, you help these individuals build sustainable and successful careers. Encourage a collaborative approach rather than adversarial thinking. You want to ensure that their name and reputation is not associated with unforgiving headlines like this:
Seriously, Equifax? This Is a Breach No One Should Get Away With
We all know people who worked at these companies during times of strife. Their network will wonder if they were the person responsible. It is in their best interest to avoid a predictable, repeatable situation where they are associated with this level of headline news coverage.
Deliver vulnerability reports based on leaders and encourage healthy competition among them. Ensure that every leader sees their peers’ summary vulnerability reports, enabling them to assess their position within the organization. Are they in the top or bottom half in terms of performance? At the end of the year, provide team awards for the teams with the shortest mean time to detection and resolution, and highlight teams with the lowest total count of critical vulnerabilities as exemplary.
Tips for pitching your Vuln Management Program
Implement tests to discover when a system is no longer getting scanned.
Implement tests to discover new systems that have never been scanned.
Implement tests to discover scanner misconfigurations that positively fail to discover relevant & new vulnerabilities.
Implement tests to discover a scanner that’s stopped firing.
Vuln Management programs should be assumed to be failing. Test for failures. Report on them. Implement mechanisms to systematically eliminate failures.
Loudly & clearly communicate that following concept: The existence of a vulnerability management does not mean your business is secure. Vuln Management is a cost of a sustainable, long term business. Complacent companies get burned. If you fail to maintain a high quality Vulnerability Management program, your business’s “Check Engine” light will go off at the worst possible moment.
Watching firewall logs is a good intention. You are not going to be the next equifax. You implement mechanisms for discovering vulnerability management non-compliance. You test your mechanisms for discovery gaps.
You can have 100% of your vulnerabilities patched within your SLAs and still experience catastrophic breaches & ransomware events.
Your Vulnerability Management Program should measure KPIs
Here are some example KPI’s to consider (from https://www.cisoplatform.com/profiles/blogs/top-10-metrics-for-your-vulnerability-management-program):
Mean Time to Detect
Mean Time to Resolve
Average Window of Exposure
Scanner Coverage
Scan Frequency by Asset Group
Number of Open Critical / High Vulnerabilities
Average Risk by BU / Asset Group etc.
Number of Exceptions Granted
Vulnerability Reopen Rate
% of Systems with no open High / Critical Vulnerability
Additionally- note that NIST has some recommendations around vulnerability management reporting: https://nvlpubs.nist.gov/nistpubs/legacy/sp/nistspecialpublication800-55r1.pdf
What’s your take? What else should be being measured & reported?
Unfortunately the installation scripts are stale & depend on deprecated cert-bot software from eff. I have to hack together an update for making this thing work.
The script accepts input from the user and then tunes various configuration files for the image board & nginx. For example, you can specify the domain of a page. This is useful because we’ll have to set a hostname for the captive portal.
The script fails first because it expects to install ssl certificates using certbot.
Certbot is deprecated. If you run this script, you get 404’d.
So the first thing I need to do is create my own self signed certificates.
Then I need to hack the nginx.conf and sites-available/default pages.
I put a lot of effort into figuring out how to carve out a page to host static pdfs and MP3s. I tried very hard to document the edits. If you decide to do any work with nginx and creating static content, you might find this material helpful.
Cgd is a daemon that can serve a CGI script over HTTP or FastCGI.
Useful to run CGI scripts that serve a whole domain (like werc) without need for a “real” HTTP server, or to wrap CGI scripts so they can be served by fcgi-only web servers like nginx.
//TODO: implement a startup script for launching the cgd daemon on boot in the final ansible playbook.
Piratebox was a fun project that got orphaned, which is sad.
I’m constructing a new one of sorts using my ansible automation.
The firmware will turn a Raspberry Pi into a wifi access point that will broadcast a network labeled “JoinMe.”
Users who connect to the network are forwarded to a captive portal hosted on the device. The captive portal app is a local communicty image board.
The board supports anonymous image posting & is based off the code from https://tokumei.co/. The design is an implementation of some interesting plan-9 inspired tooling called Werc. The licensing is public. It has a more inviting design than the 4chan futaba image boards.
When neighbors are attached to the network, they don’t get access to the Internet. They do get private access to whatever local community resources you insert.
In my implementation, I modified the entry tokumei page to include a link to a static directory of files. You can now host a private library of mp3 files, pdfs, zines and other culture for sharing with your neighbors.
Run an offgrid wifi community network that hosts a bulletin board and a shared library.
Create local community without logging off completely. It’s off the Internet and only accessible if you stop and connect to it when you’re in range. No Internet Trolls- only your local neighbors. No advertisers. No centralized control. I hope it will help you connect with people in your proximity.
I have posted a new firmware update for turning a raspberry pi into a cybersecurity Wi-Fi practice lab. I ran a lab about a month ago and discovered several opportunities for improvement. I’ve also gotten a few inquisitive questions from some thoughtful security weirdos. Thanks for lots of feedback. Now I’ve made some improvements.
Some of you may have struggled to get past the first challenge of cracking a Wi-Fi network credential on the network. You might have realized that there are no active clients, so you can’t sniff a handshake and crack a key. The published scripts should help you find a path forward. Of course- some kids may chose to binwalk the firmware and find the cred used by HostAPD. Perhaps there are other methods for getting the credential?
I’ve made the following changes that required the creation of a new firmware image:
Wifi network SSID is now HackThisWifi. Emojis in the SSID were too challenging for kids to type
Numerous Build process changes to work using a BuilderHotspot and Containers.
I think security is fun because I like Irony and unexpected outcomes.
I’m excited about TCP/IP networking, because it makes communication possible that has never been possible in human history.
I also think I’m a bit weird- but I know that there are other weirdos out there like me. I want to make this career probable for other weirdos like myself. I create cybersecurity labs with the hope that it will help others like me find a successful, inspiring & meaningful career.
On Saturday, we launched our first Wi-Fi hacking cybersecurity lab and the results were pretty ok.
Our session saw the participation of eight eager learners—seven 12-year-old boys and one 14-year-old girl—guided by myself and Emily, a former colleague from Amazon who is super awesome. The lab revolved around using a Raspberry Pi to create a vulnerable Wi-Fi access point, allowing participants to practice hacking in a controlled environment.
Although we had planned to cover an extensive list of topics within the three-hour session, we found that we could only manage the following:
What is Wi-Fi
Finding Wi-Fi networks
Wi-Fi network security via passwords
Password complexity
Bruteforcing Wi-Fi credentials
Networking basics: IP, DNS, default gateways
Scanning for daemons
Despite the challenges we faced, the experience provided valuable insights to improve future sessions:
Time management: Limit sessions to a maximum of three hours to maintain focus and engagement, especially for younger participants.
Simplify SSIDs: Avoid using emojis in SSIDs to minimize confusion and technical issues. Network name should be something easy to copy and paste. e.g. “HackThisNetwork”
Enhance bruteforcing script: Improve the script to make it more user-friendly and informative about successful password attempts. The attempted password should be shown first- and the field with the IP address (which indicates successful attachment to the network) should be highlighted in advance of the cracking attempts.
Optimize Nmap scans: Test and fine-tune scans to ensure compatibility across different operating systems. Make sure the scans report hostnames, IP addresses, Mac addresses & discovered services.
Pre-session preparation: Communicate with parents about necessary software installations before the session to save time. Specifically: homebrew requires Xcode command line tools are installed, which are approximately a gig in size and a long wait for downloads.
Windows instructions: Develop a comprehensive command line guide for Windows users, emphasizing the use of PowerShell over Command Prompt.
Default gateway on PC: Get-NetIPConfiguration | Foreach IPvADefaultGateWay
Kid-friendly password list: Create a dedicated file server Wi-Fi access point hosting an appropriate password list for participants.
Clear instructions: Provide better guidance for saving password files locally after they’re attached to the setup Wifi network.
Validate Nmap scans: Aim for an ideal output that includes IP address, MAC address, hostname, and any listening daemons of target systems.
Overall, I thought it was a positive first run. The kids expressed interest in a follow up lab. I want to make major corrections of this first run 1st- mainly make it cleaner and better for windows kids, but the nmap scans failing is also inexcusable. I think I can make this better in a couple of weeks. Next we can work on brute forcing SSH and providing some basic Linux Introductions.
Safely learning Security is hard. We all need realistic environments to learn security fundamentals. Over the the last 10 years, I supported a program that gave kids access to realistic hacking learning environments. r00tz asylum was a kids-oriented ethical hacking educational village at Defcon. We helped kids learn about network enumeration with labs that taught them about scanning & vulnerability discovery. We showed basic vulnerability exploitation by teaching them how to exploit the Shellshock vulnerability. We taught them basic linux commands to move around systems in order to deface websites. We helped kids learn about election security with contrived sql injection demos.
Every year, people asked if we could share the labs. But the labs were too complex and the files were too large for easy sharing. Many of the labs were partly run in the cloud.
The labs were not designed to be resilient to a loss of connectivity. It was volunteer work that produced the labs. People did what they could in the time they could make. But the labs were brittle. This has annoyed me for years.
In retrospect, it’s miraculous that r00tz came out a success. We had hundreds of kids flying to an event where, if the Internet failed there was no plan b. Those kids would be bored. The parents would be pissed. And I would have been annoyed! This would have been an avoidable catastrophe. Well it never happened. But it could have!
So I built a lab that doesn’t require connectivity. It has the added benefit of being easy to run without experts present. Here is a firmware image for the Raspberry Pi:
It configures your pi to run as a wifi access point. You can use it to practice wifi hacking & learn basic linux hacking. My daughter described it as kind of a hacking “escape room.” There’s a web page hosted on the Access Points that gives students some tips once they’ve gotten past the first challenge. You should start with three simple goals:
Discover the Wifi password.
Identify a potential point of entry for getting shell access on the access point.
Gain shell access to the Access point.
From there- you can pivot to more advanced topics. You could use this firmware to learn Linux by making changes to the software on the device. You could use it to test IoT devices for security vulnerabilities. You could use it as a local web server and host some pictures. These devices are almost like gaming consoles that can be transformed into new experiences with the right knowledge.
I’m making my way through my security challenges with my daughters. As they ask questions, I’m taking notes and I’ll post them here. But you don’t have to wait for me. The software is all ready to go! I used the same open source software that commercial Access Points use (Hostapd & DNSMasq).
With this lab, you can go from simple password breaking and move on to more advanced topics. You can use this lab to get practical experience in Linux, Internet Protocol, Authentication, Network Reconnaissance, Web development, embedded wifi access points and Security Defense.
Here is a gif that gives you a feel for how to extract & rip the firmware. Note that you need administrator privileges on your account to write to the sd card.
Extracting & Ripping the firmware
Ripping takes about 15 minutes depending on the size of your SD card.
That’s all there is. Plug the sdcard into your pi, power up. You don’t need to plug in a monitor or keyboard. You don’t need to connect it to the Internet. It’s ready to go. Try to find the wifi network you’ve created. Start hacking it.
Here are your challenges:
Challenge 1: What is the Wifi password?
Challenge 2: How did you gain remote access to the running access point?
Challenge 3: How could you modify the default web application?
Challenge 4: What could you do to secure the access point?
Challenge 5: What do you need to do to make it a secure, working wifi access point?
