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.

FIPS 180: Secure Hash Standard (SHA-0) – https://nvlpubs.nist.gov/nistpubs/Legacy/FIPS/NIST.FIPS.180.pdf
FIPS 180-1: Secure Hash Standard (SHA-1) – https://csrc.nist.gov/publications/detail/fips/180/1/archive/1995-04-17
Discovery of the theoretical attack on SHA-1 in 2005:
Xiaoyun Wang, Yiqun Lisa Yin, and Hongbo Yu. “Finding Collisions in the Full SHA-1.” CRYPTO 2005. Springer, Berlin, Heidelberg, 2005. https://link.springer.com/chapter/10.1007/11535218_17

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.

official deprecation of SHA-1 by NIST in 2020:
National Institute of Standards and Technology. “SHA-1 Deprecation Notice.” Federal Register, May 7,

August 24, 2023

Overview of my repeatable IoT Build process using Ansible & Docker

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!

July 15, 2023July 16, 2023

Container-based builds of Raspberry Pi using Ansible

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.

git clone git@github.com:CaptainMcCrank/FirmwareBuilderContainers.git

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:

git clone  https://github.com/CaptainMcCrank/Learn_Linux_Networking_And_Hacking.git

Attach to your container:

docker-exec -it ansible bash

And now cd into your playbooks directory:

cd /home/pi/Playbooks/

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.

June 19, 2023June 19, 2023

Persuasion: Pitching improvements when your Vulnerability Management programs are non-existent or insufficient.

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”

Understanding the Equifax Breach

https://www.ftc.gov/legal-library/browse/cases-proceedings/172-3203-equifax-inc

https://www.ftc.gov/system/files/documents/cases/172_3203_equifax_complaint_7-22-19.pdf
- 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?

May 31, 2023

Sustainable PirateBox Part 2

Some notes:

Tokumei is the image board I’m playing with.

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.

There are instructions for installing Tokumei.co in a self hosted environment.

They call a script that can be obtained with

wget https://tokumei.co/privclear.sh.

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.

This is the sites-available default page.

The key points of this config:

Shows you how to create a self signed certificate in the comments of the script
Shows you where you put the cert and key file so that nginx can access it.
Shows you how to reduce noise in the config by using snippets pointing to self-signed.conf and ssl-params.conf
Shows you how to configure nginx to limit file uploads on the tokumei board.
Shows you how to create the /offgrid uri that vends a directory listing within the skinning of Tokumei
A minor hack to help you debug if nginx locations are not getting triggered because of aggressive / location definitions

I have a major //TODO:

If you look around here you see the reference to werc.

It references a fastcgi server running at localhost on 3333.

That cgi server is invoked with the following command:

sudo /usr/local/go/bin/cgd -f -c /var/www/ansibledest.local/bin/werc.rc > /dev/null 2>&1 &

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.

May 31, 2023May 31, 2023

Creating a sustainable Piratebox Alternative

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.

May 5, 2023May 5, 2023

Updates to the HackMeAP firmware

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’ve also created a dedicated page for the project. Head on over to download the latest firmware, get instructions on how to use it, and tips for those of you stuck on the first challenge of cracking the Wi-Fi password.

April 3, 2023

Empowering the Next Generation of Cybersecurity Enthusiasts: Inside Our Inaugural Wi-Fi Hacking Lab

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.

February 10, 2023May 5, 2023

Firmware for pi hack me Access Point Practice Lab

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:

https://firmware.patrickmccanna.net/Firmware/pi_hack_me_ap.img.tar.gz

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.

HOW TO GET STARTED

You need a Raspberry Pi B+3 or a Raspberry pi 4 and an 8gb or greater SD card.

Start by downloading the Pi Firmware here:

https://firmware.patrickmccanna.net/Firmware/pi_hack_me_ap.img.tar.gz

You can extract it using the command:

tar -xvf pi_hack_me_ap.img.tar.gz

You can then rip it to an SD card using the raspberry pi imaging software.

Install the raspberry pi imaging software (available here: https://www.raspberrypi.com/software/)

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.

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?

If you need more granular challenges, take a look at this post: https://patrickmccanna.net/pi_hack_me_ap-challenges/

Happy hacking! If you get stuck or run into problems, file an issue here:

https://github.com/CaptainMcCrank/Learn_Linux_Networking_And_Hacking/issues

February 7, 2023February 7, 2023

Pi_Hack_Me_AP Challenges

My Access Point firmware is a playground where you can learn by experience. You’ll have the opportunity to try on both offensive security and defensive security.

Gaining experience with offensive techniques is valuable because hacking is perceived as a magical power. If you know a spell and cast it correctly- you can do things that other people can’t. It isn’t magic. It’s logic & taste. If you know where to look, you’ll find spiders in any house. Hackers work the same way. We have an easy time gaining control of systems for four reasons.

Software quality standards are poor.
Assessing software quality requires reverse engineering experience
Humans assume usability is a proxy for measuring software quality
A defender needs to be right 100% of the time. A hacker only needs to be right once.

There are too many instances of dev education that indexes on getting a demo working quickly. Implementing AuthN/AuthZ logic that protects sensitive operations is a topic that’s typically reserved for advanced courses that not everyone takes. This means hackers tend to have an easy time discovering predictable implementation mistakes. Knowing how hackers are able to access your system forces you to learn the changes you need to make to secure it.

Gaining experience with defensive techniques is not easy. Assessing logs for evidence of attacks & compromise is pretty abstract unless you have an active attacker. When you run the attacks, you can look at the logs for evidence of attack activity. This also helps you get context on the privacy implications of accessing websites. I want to make sure ambitious kids understand that tampering with websites is easy to detect. I don’t want to see any kids getting into trouble with the law because they didn’t understand how traceable scanning is.

Below are the challenges I’ve shared with my daughter. I did quite a bit of hand-holding to get her across the line for hacking the wifi network. My objective is to have her go through these challenges on her own. Ideally, she’ll search the web for context on these questions and start learning how to work these things out on her own. It was self education that got me to this stage of my career. It’s a pattern that I know works, but it seems to be dying in certain subsets of the infosec world. If you decide to run this access point, you can use these challenges as a guide on what to try:

Easy Challenges

What is the Wifi Password?
When you are connected to the network, what is default gateway ipaddress and hostname of the default gateway? What is the IP address that was assigned to the device you were attached to? What is the DNS server’s IP address while you’re connected to the hotspot? (Need a clue? check out this video: https://www.youtube.com/watch?v=6PZp7LNKHgk)
Are you able to connect to the Internet over the hotspot in its default configuration? How did you determine this? Why does or doesn’t it work?
What possible entry points exist for gaining access to the Hotspot? Describe you tested to discover if the attack is possible? How can you gain shell access to the device? Do not continue to the next section until you have been able to gain access

Medium Challenges

How do you change the password on the Access Point?
How do you configure SSHD so that you don’t have to rely on passwords?
What is the operating system version of the device?
What services are listening on the device?
What web server is running on the device?
Describe any web page you found on the device. What was the URL? Were you able to view it?
Where are the logs for the webserver stored?
Where are the files for the webserver stored?
Can you view the web page?

Advanced Challenges

What is HostAPD?
What is an interface?
What interface is HostAPD running on?
What is the ipaddress on wlan0?
What is the ipaddress on eth0? Why?
Where are the HostAPD access logs?
What file do you need to edit to change the SSID, Password and wifi security settings?
What is IP forwarding? What is ip Masquerading?
What is a “router”?
What are the major steps for turning our Hacking hotspot into a working wifi access point that gives access to the Internet?
What is IP Forwarding? How do we enable it?
How can you change your device into a working access point?
How do you get connectivity working on the Ethernet Interface?
Plugging it into a network with DHCP
Plugging it into a network with static ip addresses
How do you turn on ip forwarding in linux?
How do you make it a permanent change?
How do you activate Network Address translation?
How do you vend IP addresses to devices that are attached to your network?

Privacy/Security Defense Challenges

What does an admin know about you while you’re attached to the device?
What do you see when running tail –f /var/log/hostapd.log while a device attaches to the wifi network?
What do you see when running tail-f /var/log/dnsmasq.log while a device attaches to the wifi network?
What do you see when running tail –f /var/log/lighttpd/access.log while a device browses to the web site?
What are the privacy implications for connecting to a wifi network?
What information does an Access Point operator have about you if you attach to that network?
What kind of attacks can an admin execute while you’re attached to the device?
What is packet sniffing? How could it be done?
What is a MITM attack? How could it be done?
What is DNS hijacking? How could it be done?
How can you harden this access point so that no one could reproduce the attacks you used?
How do you install software?
How could you configure SSHD to resist brute force password guesses?
What is Fail2Ban
What is nftables?