Welcome, Guest User :: Click here to login

Logo 67327

67-327 :: Summary Exercise - Insecure Arbeit

In this exercise we will be working with an insecure version of the Arbeit project made specifically for 67-327: Web Application Security. Arbeit was originally conceived as an excuse to play around with the awesome Chronic gem and requires this gem to run. The Arbeit project was used in 67-272 to demonstrate some more advanced features in Rails, introduces multi-model forms, uses some jQuery and refactoring. This version of the system is different in noticeable ways (some new features, some changes to the database, some unusual coding) so that the end result is that it is more insecure than the original project. (Not that we really focused on securing the app in 67-272...) Students in 67-327 will be finding ways to exploit this application and recording their discoveries.

In 67-373 we deployed Arbeit to inthepocket.org; the insecure version is deployed there as well, but with a twist. Each student has been given his/her own version of the system under a different port. The ports were announced in class and are also listed below. Students are on their honor to only exploit their personal version of this project; do NOT access any other version of the Arbeit project other than your own. As discussed below, each student's version has some unique vulnerabilities -- reporting a vulnerability that does not exist in your version will earn an automatic zero for a score.

Finding vulnerabilities
Of course, part of the challenge is not telling you exactly where the vulnerabilities are or even how many there are, but if it is at all helpful, there are at least a dozen (very likely more) vulnerabilities for you to uncover. You can use any tool you like: Burp Suite, Live Headers, sqlmap, Firebug and the like. Of course, be careful not to overlook the obvious and the low-hanging fruit in search of only on the most difficult exploits. (There are both easy and hard exploits in this application waiting to be discovered.)

Your job is to identify each of these issues, exploit them if you are able (and take a screenshot of the successful exploit whenever possible) and record your findings on the template provided. If you wrote an external script to assist with the exploit, be sure to include that with the findings.

Submitting your findings
At some point after October 11th but prior to 3:59pm on October 15th, all students must submit their findings to a form at http://bit.ly/67327_Arbeit. The findings form and all supporting materials must be recorded and saved as a .pdf file and that file must be given the name YOUR_ANDREW_ID_arbeit.pdf – failure to follow this naming convention is an automatic 25-point penalty. There is a maximum file size of 10MB, so reduce photo resolution if you are still pushing past that size limit. Note that you may upload up to four other supporting .pdf files, but these files should also have your Andrew ID in the name of the file so there is no doubt it belongs to you (and those files are also limited to 10MB each). No late submissions will be accepted without a written excuse of a medical emergency or other extenuating circumstances.

Other notes of interest regarding this lab:

  1. As stated in the course syllabus, this lab is to be done by individuals. There is to be no collaboration between students and any collaboration will result in a failing grade for all parties involved.

  2. Additional rows can be added to the findings template if needed.

  3. There are many vulnerabilities in the application – some large and some small – record as many as you can. Note that there are multiple versions of some vulnerabilities (e.g., just because you find one type of SQL injection doesn’t mean that other types are not available). Likewise, one vulnerability might make other vulnerabilities possible.

  4. There are five variations of the Arbeit project in total and each student has been assigned a specific version. Many of the vulnerabilities go across multiple versions, but there are some unique vulnerabilities in each version. If a student reports a vulnerability that does not exist in the version they were assigned, they will be given an automatic zero for the exercise. Be sure that each vulnerability you report can be executed on your version of the project.

  5. TAs will have special office hours this week starting on Wednesday to help students with this assignment. Please see piazza for more information.

Additional Information and Supporting Materials:

List of port assignments for each student

 

Due Date: October 15, 2018

Weight: 25.0