Posted on: January 2, 2025
Last modified: January 16, 2025
The “Embedded Security Challenge” is a free challenge for all embedded developers. Advance step-by-step in securing your systems.
How does it work?
You have one challenge (a question, a task) to work on every week. I post the challenge every Thursday. Those challenges are platform-neutral; you can do them on embedded Linux, most RTOSes, and any hardware platform.
You can find challenged either on this website, or on Marta’s LinkedIn profile.
How to answer?
Comment on the post with your solutions; you can include links to your blog posts, social media posts, and the like.
After a week, you will find here an example solution and comment on the interesting approaches you have posted!
Week 1 (January 2-8): Network-enabled services
This week’s challenge is:
What are your product's services (applications, daemons) communicating, or potentially communicating with the Internet? Check all network interfaces. Also, check for both applications sending data and those listening.
Why is it important? This is the easiest way attackers can interact with your device.
You can find the solution at the dedicated page Embedded Security Challenge – Solutions
Week 2 (January 9-15): Web-based administration and command injection
The application to administer an embedded device is a frequent target of attackers. It is easy to access (from the Internet), and bugs might be hiding inside.
The task for this week:
Use a web administration application on one of your embedded devices; it is better to have the source code. It needs to be a device you own and one not in production.
In various application forms, try special character combinations and check if you can escape the input parsing. Fix bugs you find.
You can try techniques like:
- Very long text
- Characters that end the string in the programming language of the application
- Unicode special characters
- Special characters line /n or /r
Strange behavior of the application after you type unusual characters might be a sign that you are on the right (buggy) track. Use the source code of the application to confirm how to trigger parsing bugs.
For examples of vulnerable sequences in Python, you can check out https://snyk.io/blog/command-injection-python-prevention-examples/
Similar guides exist for other programming languages.
Report what you have found out! (and report to upstream projects, if affected)
Week 3 (January 16-23): How do you store passwords?
Most devices store passwords. Those might be system passwords, passwords for a web interface login, or internal passwords for system services.
When you log in, the system compares the password you just typed with the password on record.
But how do we store that password on record? As-typed in a file? That looks like a bad idea if an attacker can copy that file…
We do not store passwords directly. Instead, we store a hash of a password. A hash is a cryptographic operation that generates a fixed-size value from any size of data or document. It is quite easy to calculate a hash, but it is hard to find the initial value from the hash (examples of popular hashes are SHA2 or SHA256, SHA3).
This is not all. Given enough time, if an attacker has access to the hash, they can try different combinations and figure out the passwords. Because of that, we do not hash once – but hundreds of thousands of times. You can find out more in the guide from OWASP: https://cheatsheetseries.owasp.org/cheatsheets/Password_Storage_Cheat_Sheet.html
The task for this week:
Find out where passwords are stored on your device, confirm that they are stored as hashes, and count how many times they are hashed.