The Cybersecurity Rabbithole
Over the past couple of months, I have been diving into the goal areas I set out for myself at the beginning of the year. One umbrella covers several areas (CTF’s, cryptography, and operating systems) I am interested in - cybersecurity. After participating in a few CTF’s (Capture the Flag’s), I realized this is an opportunity to blog!
First off, what is a CTF? They are problem solving competitions often organized by companies (Square, Stripe, and G), universities (UCSB, KTH), or conferences (Defcon, BSides). They are not only fun, but are a significant way that computer security professionals learn the ropes, improve their skills, and stay involved in their community. The name of the game comes from what happens when you solve a challenge - you find a string (“the flag”) that you input into a system to prove that you have solved (“captured”) the challenge.
There are several styles of CTF’s, but one of the most popular is “jeopardy”. This type of competition involves a set of challenges that an individual or team can solve in the order that they desire. Most CTFs have a time limit ranging from several days to a week.
There are several main types of challenges in these types of competitions, all of which are designed to test your skills and knowledge. While the challenges I have seen do not represent the complete set of options for CTF designers, the ones that I have seen could be grouped into several categories:
- Web Security - flags are revealed when you find a vulnerability in a web application, like SQL injection, file inclusion, or cross-site scripting bugs. I dived into this set first because of my existing familiarty with these problems.
- Programming - find bugs in a program or write a program to solve a puzzle to reveal a flag.
- Cryptography / Math - Solve a puzzle involving some knowledge of cryptographic primitives or mathematical problem solving (for example, the Square CTF has these).
- Reverse Engineering - reveal a flag by figuring out what a program does, most of the time not being able to see the source code (for example, being given a binary file and needing to find a flag in a C program)
Of this set, cryptography and reverse engineering seem to be the most difficult. Luckily, the internet has proven to be a good source of information about where to improve (again, another future blog topic).
I’m also looking forward to digging into a type of challenge that closely aligns with my professional interests, but doesn’t show up in every set of challenges - Ethereum contract vulnerabilities. There is a wealth of information about auditing these contracts - ranging from public audits, tools to perform the audits, and publicly accessible open source contracts.
A knock-on effect of diving into computer security has been learning more about various other low-level computer components. In some sense, it converts learning into a problem-solving exercise, rather than poring over textbooks. For example, I’ve been able to practice x86, C, and other rusty skills as a result of doing CTFs.
I have several takeaways from the past several months. First off, knowledge about these topics seems to be somewhat scattered, and resources vary dramatically in terms of quality. Additionally, there doesn’t seem to be a systematized way to begin learning (although there are certifications like CEH and OSCP to do when you reach a certain threshold of knowledge). Lastly, there is a culture of forcing people to struggle through problems as part of the learning process. I’ve taken a course where I learned about C, I know what a register is, and I program professionally, but not all of those things are true for those who begin learning about computer security. Some people could start with the beginning certifications that teach about networking or Linux, but it seems like a clear path along the lines of Khan Academy would work better than what is currently out there. Additionally, I think the internet enables curious people to pursue rabbit-hole-style learning, but there is significant friction in doing so.