Skip to content

Latest commit

 

History

History
197 lines (117 loc) · 10.7 KB

PermissionsPartTwo.md

File metadata and controls

197 lines (117 loc) · 10.7 KB
Raw

Security layer testing and penetration

In this assignment you will learn how to attack a reference monitor. The reference monitor you will be testing uses the security layer framework (encasement library, etc.) for the Seattle testbed. It is possible to do this assignment separately however it is recommended that this assignment be completed after [wiki:EducationalAssignments/PermissionsPartOne PermissionsPartOne]. Either way you should already have a working security layer or access to one. Testing the security layer is done by running a series of test cases that an adversary may use to circumvent your system. This assignment is intended to prepare you for thinking about security paradigms in a functional way. The ideas of information, security and privacy have been embedded into the steps of this assignment.

Overview

In this assignment you are a tester. You have been sent a bunch of reference monitors that need testing before they are deployed. Your job will be to ensure an attacker cannot circumvent these security layers. In order to do this, you will attempt to read, write, and append data without having the proper missions enabled. If you are able to do so, then the security layer is not secure. The future of the system depends on your ability to test code thoroughly!

Three design paradigms are at work in this assignment: accuracy, efficiency, and security.

  • Accuracy: The security layer should only stop certain actions from being blocked. All other actions should be allowed.

  • Efficiency: The security layer should use a minimum number of resources, so performance is not compromised.

  • Security: The attacker should not be able to circumvent the security layer.

Within the context of this assignment these design paradigms translate to:

  • Accuracy: The security layer should only stop certain actions from being blocked. All other actions should be allowed. For example, If a user tries to overwrite data and append new data in the same write, and has permissions to write, but not append, then the corresponding data would be overwritten, but would stop at the end of the file and would not append anything.

  • Efficiency: The security layer should use a minimum number of resources, so performance is not compromised. This means you should not do things like re-read the file before each write.

  • Security: The attacker should not be able to circumvent the security layer. Hence, if the data can be written without permission, the security is compromised.

You will submit a zip file containing all of the tests you have created. You will gain points for every student's reference monitor you find a flaw in. It is okay if multiple tests of yours breaking a student's reference monitor, but you will not gain additional points.

Prerequisites

This assignment assumes you have Python2.5 or Python2.6, Repy and RepyV2 installed on your computer. If you don't already have them please go to [wiki:EducationalAssignments/PermissionsPartOne#GettingPythonRepy PermissionsPartOne] for a tutorial on how to get them.

Helpful links

The following links will aid students in becoming comfortable with Python, Repy and seattle:

Testing security layers

Hypothesis, test case, counter example

The goal of a good tester is to test hypotheses. A hypothesis is just a scientific way of asking a question. The hypothesis of this assignment is "This security layer is well designed." The questions you will ask when running your test cases will always be the same

  • "Is this reference monitor secure?"

  • "Does this reference monitor hamper performance?"

  • "Does this reference monitor prevent actions that should be allowed?"

Notice that these questions are parallels of the security paradigms: security, efficiency and accuracy, respectively.

If we can find a case where the hypothesis is false, then the security layer is not secure. Such a case is referred to as a counter example. Hence all test cases should be designed to test for these three types of flaws.

Examples of tests

Test cases are briefly described in [wiki:EducationalAssignments/PermissionsPartOne PermissionsPartOne] and [wiki:RepyV2SecurityLayers]. Below is another example of a test case you may want to consider. This test case gives the right 'style' for your all your test cases, but lacks in the number of test cases. A good attack will include many test cases.

Test case 1:

# Open a file
myfile=openfile("look.txt",True)
myfile.setwrite(True)
myfile.setappend(True)

 
myfile.writeat("SECURITY",0)

# Attempt to read data from the file
try:
  myfile.readat(1,0)
 
# It raised an Exception (as it was supposed to):
except ValueError:
  # The security layer correctly blocked the read!!!
  pass
 
# No Exception was raised!
else:
  log("Read without permission")
 
finally:
  # Close the file after our attempt.
  myfile.close()

Code analysis

It is important to keep in mind that only lowercase file names are allowed. So in the above code, specifically:


# Open a file
myfile=openfile("look.txt",True)

look.txt is a valid file name, however Look.txt is not. Examples of other invalid files names are, [email protected], look/.txt, and look().txt. Essentially all non-alphanumeric characters are not allowed.

In this case we are verifying the security of the reference monitor. This code attempts to append data without the proper permissions to do so. First the file is opened using myfile=openfile("look.txt",True). Next myfile.readat(1,0) tries to read from the file. The 0 refers to an offset of zero and 1 refers to number of characters being read. The try: statement tells the program to "try" this case. Notice that the except is executed if an error is raised. If the security layer fails the test then the else statement is executed. The finally: statement will always run, closing the file.

Test case 2:

# Open a file
myfile=openfile("look.txt",True)

myfile.setappend(True)
myfile.setread(True) 
myfile.writeat("abcd",0)

try:
  output=myfile.readat(4,0)
# It raised an Exception :
except ValueError:
  log("Security layer not accurate")
 
else:
  # No Exception was raised (as it was supposed to)
  pass
 
finally:
  # Close the file after our attempt.
  myfile.close()

Code analysis

In this case we are verifying the accuracy of the reference monitor. This code attempts to write "abcd" to the file directly. We assume that secure data is written in the file on the first four offset values. First the file is opened using myfile=openfile("look.txt",True), and the append and read permissions are enabled. Next myfile.writeat("abcd",0) tries to write "abcd" to the file. The 0 refers to an offset of zero. The try: statement tells the program to "try" this case. Notice that the except is executed if an error is raised. If the security layer fails the test then the else statement is executed. The finally: statement will always run, closing the file.

If this case produces anything other than "Write okay", then this layer fails the accuracy design paradigm. The security layer should only stop a file from reading the secure data not overwriting it.

More information on: Try, Except, Else, Finally

The try, except, else and finally statements are part of exception handling. For more information on exception handling please visit:

Hints and Ideas for testing

When writing your own tests it is important to test for a complete set of possible penetrations. Keep in mind, it only takes one test case to break through a security layer. Some of the things you may want to test for include:

  • threading
  • writing to multiple files

And more! Remember a good security layer can't be broken by anyone! Which is all part of the fun! It's about solving a puzzle. First you make the puzzle - write the security layer, then you solve the puzzle - try to bypass it. If your puzzle is "good enough", no one will be able to break it, no matter what.

Notes and Resources

Extra Credit

Find bugs in the extra credit reference monitors given the altered threat model. You should include more test cases in the extra credit!

How to run your tests on many reference monitors

If you are using Mac or Linux, you can do something like the following:

Create a directory that the security layers will write their files into. You need to run repy with only access to this directory. You can write a test program that does log(str(listfiles())) to see if you are in the right place.

Then you can type the following in the bash shell to execute the testcases with the reference monitors:

for referencemonitor in reference_monitor_*; do for testcase in [poy_email_id]_*; do rm testdirectory/*; cp $referencemonitor $testcase encasementlib.repy; python repy.py [path to files and arguments] encasementlib.repy $referencemonitor $testcase; done; done

This will print out the output from each program.

If you are a Windows user and you create your own solution that does the same thing, please post it on the forum.

What to turn in?

  • Turn in the test cases used to attack a given reference monitor in a zip file. The name of each testcase must start with your poly email id in lowercase. For example: jcappos_securitytest1.repy justincappos_goodaccuracytest.repy are both valid names.
  • Optionally turn in the test cases used to attack the extra credit reference monitors in a zip file. Note that in this case, you can expect that your code is run more than once. In the name of the file, say if it needs to be run multiple times. For example: jcappos_run_twice_metadata_removal.repy jcappos_run_once_threading_hack.repy.