To help students gain some additional hands-on experience, I’ll be hosting a CTF (“Capture The Flag”) of sorts on Saturday, December 3. It’s not actually competitive (at least not this year), and is designed to be more of a workshop to help students that don’t have a whole lot of knowledge about application security than an actual CTF. The goal is to make this as accessible as possible for all students, but a reasonable amount of programming experience is necessary to have a meaningful experience. This blog post will explain how the workshop will be laid out, what tools you should download and have ready before you arrive, what skills will be covered in each track and what skills you should be comfortable with for each track. The tracks can be switched between, done or not done, etc. as students see fit. Basically, work on whichever track seems like it will be within your grasp, but still challenging enough to learn something.

While I discuss what things you should know, even if you don’t know them, no harm can arise from you coming to the workshop. Even if you feel completely lost and like you wouldn’t even know where to start on any of the tracks, but you’re interested, you should still come. There will be students with a very wide range of experience levels there, and even if you can’t get past a single challenge, simply hearing explanations of these things and observing other students while they work on things independently or in teams will provide a lot of opportunities for learning.

Track 1: Basic Web Application Security

This track is designed for students with little to no experience in security. A reasonable grasp of how websites work would be very helpful (IE, assuming we’re using a standard Linux, Apache, MySQL, PHP or LAMP stack how these pieces come together with other things such as JavaScript to get the end result of what the user sees). Even if you have no web application programming experience, this track is still very likely to be accessible to you. Essentially you should understand that in the HTTP protocol (yes, I know the “p” stands for protocol, but it sounds silly to say “in the HTTP”) a user’s browser issues a request to the server hosting the web application, the server receives this response and determines if the user is requesting static content (always the same – your dentist probably has a website like this) or dynamic content (could be only slightly different for some users, or radically different – think your bank’s website).

If the content requested is static, the server simply responds with the static content. If the content is dynamic, the server will run code (often PHP, although there is no shortage of other technologies, PHP is extremely common, if not the most common) that may perform operations such as accessing a database server, validating user input, sanitizing user input, calculating things, etc. The results of this code get combined with any static assets and the combined result is then returned to the user. It’s important to note that this code executes ON THE SERVER. The user can’t see this code (or if they can, you’ve done something VERY wrong). This makes sense, because if you’re accessing a database filled with user information such as credit card numbers, passwords, etc. you don’t want to just give every user’s browser database credentials, because then they’d be able to obtain other users’ data. On the subject of databases, they’re fairly self-explanatory and I don’t think I need to explain in detail the role they play in dynamic web applications. The syntax and types of databases we’ll discuss during the actual event.

JavaScript also plays a very large, and ever increasing role in the experience of web applications. This code runs in the user’s browser (there are actually projects that use JavaScript for server tasks as well, but they’re beyond the scope of this track). The server’s first response usually includes many other elements for the user’s browser to request, often including JavaScript. The make-up of this JavaScript can also be dynamic based on the pre-HTTP executed code (in our example, coded in PHP). This allows for a more immersive and lightweight experience for the user. Instead of having to type in all of your information, submit a form, send a request to the server with the data from the form, have the server respond and cause you to download the entire page again, you can simply send the user some JavaScript that sends much, much smaller requests to the server such as “is this username taken?”. This allows the server to handle more traffic, provides a faster browsing experience for the user since they can send/receive smaller requests, and makes websites feel more like locally stored applications – basically, the page you’re viewing can change without having to re-download the entire page or even send requests (things like computations can be done in JavaScript).

Track 1 will consist of several web applications that primarily provide the user with a page with a single field, or only a few fields and explicitly tell the user what kind of vulnerability exists on that page. For example, a page may provide a single box, similar to a search engine and tell the user that “this page is vulnerable to SQL injection”, and the user will have to determine how to take advantage of the SQL injection vulnerability. This is the training wheels track, and should have the lowest barriers to entry.

Tools required: A running VM of Kali Linux with BurpSuite installed would be helpful. Many of these challenges can be done without any tools other than a browser, however.

Track 2: Memory/Logic Vulnerabilities

This track requires some knowledge of C++ at a minimum, preferably C and the ability to look at assembly code and gain even a vague understanding of what the program is doing. In Track 2 students will be given C source code and use a debugger to disassemble it and determine how the application is working in memory, if bounds of memory can be overwritten (particularly the “return address” or the location of the next instruction after a function completes) allowing you to possibly inject compiled shell-code in to the program to add your own logic/instructions to it, or point it at a different section of code already within the program. An example of this would be if in a password-checking function you could overwrite the return address of the function to the location of the first instruction that would be executed if the user entered a valid password. Essentially, you’re hijacking execution of the program. A frequent goal of these types of vulnerabilities is to open a shell and allow the attacker to connect to said shell, giving them the ability to execute commands on the server that would run with whatever privileges the compromised application or process runs with.

In terms of ESU coursework students that have taken Programming Principles/Practice (C++) and Computer Organization would struggle and probably not get terribly far, but would learn quite a bit. Students that have taken Assembler would fare better, and students that have taken Assembler and Operating Systems should be able to handle many of these challenges, with some assistance.

Tools required: We’ll be using a public CTF for this, which will require you to SSH in. For Windows users, PuTTY is a great tool for this. For Linux/OS X users, you’re already covered. The other tools you’ll be using for this challenge will be on the server you’re connecting to.

Track 3: Practical Web Application Security

This track is somewhat similar to Track 1, and is a logical extension of it, however it requires more understanding of how HTTP, possibly lower protocols such as TCP, TLS, etc. work and an understanding of how things like sessions are managed, proper password storage procedures, etc. In this track you’ll be given a “real” web application and have to find vulnerabilities in it. It won’t be laid out like Track 1 where you’re told which vulnerabilities exist where – you’ll have to test various fields to find that out on your own. You’ll have to look at the code of the application, get an understanding of how it works and anything that looks suspicious to you. This requires a broader understanding of web application design practices.

Tools required: You definitely want Kali Linux, or at a minimum an intercepting proxy, such as BurpSuite (the free version will suffice just fine). Kali will provide you with a wealth of tools to automate certain attacks and may be easier for some students than downloading/installing various tools on their primary partition/OS.

Rules of Engagement: Don’t do Anything Stupid

For tracks 1 and 3 we’ll be utilizing an isolated network in SciTech 368. This network will not be connected to the ESU network in any way, shape or form. Before performing any attacks, you MUST allow me to confirm your network settings are correct. If you start running tools like nmap, Nikto, sqlmap, etc. and are accidentally connected to ESU’s network I’m going to get several very nasty e-mails and you may end up being escorted out of the building in handcuffs. For this reason I suggest working in pairs or small groups – one user can be connected to ESU’s WiFi and conduct research, the other student can be connected to the isolated network and ONLY the isolated network to ensure that NOT A SINGLE MALICIOUS PACKET goes out to or over ESU’s network. This rule is absolutely not negotiable, and if you think you’re above it, you’ll be asked to leave. Seriously, Google “student hacker arrested”. Plenty of well-intentioned students have been arrested for pointing their attacks at the wrong thing or letting their curiosity get the best of them.

Location/Time:

SciTech 368. We may decide to all chip in and order pizzas or something like that, or make various Wawa trips throughout the day. I’d like to get started around 11 AM and I’ll hang around as long as there are students interested in working, even if it’s until 2 AM.