Security

We have just published the exam results in CMS, and you can also see your total grade combined with the bonus points. To cope with the two missing points in exam exercise #1, we added two points for everyone. After this, overall 68/103 (66%) students succeeded in the exam, congratulations! Remember that you have to pass the exam to pass the course, even if you have bonus points in the projects.

Exam inspection will take place on Tue, March 6, from 2pm-5pm at CISPA in room 0.07 (ground floor).

We write the exam tomorrow in E2.2 (Günther Hotz Hörsaal) and E1.3 HS002. In the material section you find plans for both rooms. Please take a look to see in which room you have to go, and where your seat is. In case you're not on the list, please write us immediately.

Exam starts at 10:00, so be present at 09:45 latest.

Don't forget your student ID and a pen. In case of questions, write to Markus Bauer.

While you're likely busy with preparing for it, we wish you best luck for the exam tomorrow. Remember to bring your student ID, pen, and one final cheat sheet, and be there on time. We will spread further information about where to go and when to be there ASAP.

As we received several questions about the exam content, once again: prepare for all topics covered in the lecture, including those taught by guest lecturers and those at the end that were not covered by execise sheets and/or projects. And yes, you will have to understand assembly to solve some of the tasks. We will try our best to answer remaining questions in Askbot, but please understand that we will likely not be able to reply to last-minute questions.

We have just published a mock exam for Security, that you can find in the CMS materials. This exam will be discussed in two final tutorials next week, Wed 8am and Thu 2pm in HS002 in E1 3.

Note that...:

• ... the actual exam will be 120 min instead of 60 min long
• ... the actual exam will cover additional topics that are not part of this mock exam
• ... this mock exam is only additional preparation, next to exercise sheets etc., for the final exam.

We finished grading the third project, you can see your final project results in CMS. If you have questions about your report grading, please contact Giorgi. 

We also finished grading the last minitest.

 

If you passed at least 3 minitests and got at least 50% of the project points, you are admitted to take the exam / re-exam. If you want to take the exam, you have to be registered in LSF/HISPOS. That means:

• If you are admitted to the exams and want to take the first exam, register in LSF/HISPOS until 06.02.2018.
• If you are admitted to the exams and want to take only the re-exam, do not register in LSF/HISPOS. Re-exam registration will be available later.
• If you are not admitted to the exams, unregister in LSF/HISPOS until 06.02.2018. Otherwise it might be counted as a failed attempt.

You can check your LSF registration status on your personal status page (updated hourly).

Upon popular request, and to complent the existing visual slides by Stefan's lectures, we have added a few slides that describe ASLR, JIT-ROP and CFI in textual form to Chapter 08. Please use these slides as further reference to guide you through Stefan's slides, especially if you missed the lecture. It should come as no surprise that this material, including Stefan's guest lectures, are relevant for the exam. Should there be uncertainties, please use the tutorials to shoot your questions, and practice your understanding in the exercise sheets.

The final and 5th minitest will take place next week Tuesday (Jan 23rd) and will cover these topics and software security solutions in general. This time, you will need to write (very basic) assembly code yourself, so please familiarize yourself with the basic instructions. Exercise sheet 09 serves as perfect practicing session for the final minitest. The test will cover all material of the Software Security slides, especially from slide 137 onward, and will not cover Malware or other future topics. A gentle reminder: Note that you have to pass at least 3 minitests to be able to participate in the exam.

We were just informed that the projector technique in our usual lecture room is out of order. We'll have to switch to HS002 in E1 3 (CS building) for tomorrow. We'll be back to normal in our old lecture hall next week, unless you hear otherwise from us. Sorry for the short notice, but the technical people tried to fix the projector until just now but had to give up. We'll hang out posts for those that will not read this news. Please spread the word to fellow students.

The next minitest will be on Tue, Jan 9th, at 10:15am. Topics covered will be software exploitation (basically slides 117-166 in the Software Security chapter). While we will not cover assembly in great detail, it will help to (i) understand basic shellcode examples, and (ii) to know the stack layout.

And two related promises: We'll update the slides of today's lecture ASAP, and publish the minitest #03 results latest tomorrow.

Hi all, and a happy new year!

We finished correcting your reports for the second project, you should be able to see the results in CMS.

There were both cases where we had to deduct points from the report, as well as cases where we gave points for partial solutions. A solution for "Database Secrets" that didn't report the 4 visible tables and their columns got half the points.

If you have questions about your report grading, please contact Markus.

Hi all,

Project 1

we have finished correcting your reports for the first project and made the results available in CMS. Under "Test and Exams", you should be able to see the final points for the first project, as well as a breakdown for each challenge. Additionally, we also provide the points you gained from the scoreboard under "(Scoreboard)", as well as the report rating under "(Report)".

There were both cases where we had to deduct points from the report, as well as cases where we gave points for partial solutions.

If your total points are less than your scoreboard points it is most likely due to one of two common mistakes:

1. A solution for task "Weak Key" that only applied the RsaCtfTool without any further explanation gave 0 points.
2. A solution for task "Weak MAC" that uses a library (hashpump, hlextend etc.) without explaining their inner working we gave half of the points for identifying the vulnerability as "length-extension" and for finding the keylength of 32.

If you have questions about your report grading, please contact Johannes.

Project 3

Project 3 will be relased today at 18:00. This means that you may build new teams until next Sunday (24.12.), should you wish to do so.

With this, all the best and have a merry christmas

Hi all,

as grading of the first project is nearing completion, we’d like to clarify a few things and give you some hints for future reports.

Why and How

As you might have already guessed, the purpose of the report is for us to see that you have understood a vulnerability/an exploit and came up with a solution on your own. This usually boils down to answering two questions:

1. Why exactly does something pose a vulnerability?
2. How can this vulnerability be exploited to do “bad things”?

 

As an example, here are two solutions for task 1 we received:

When looking at the provided cipher it was hard to gain any information, because it was obviously encoded and not readable. We decided to write a short python script which decodes the given. cipher in ascii and store the result in an array so we can simply output it. The code we used is named 1WeakCiper.py

This solution raises more questions than it answers, e.g., what is meant be “decode”? How does the script decode things? Why is it possible to write a script that simply decodes the ciphertext?

A better solution is the following:

[…] From this snippet we can easily guess that we are dealing with a monoalphabetic substitution cipher of some sort. The easiest one to try here is a Caesar cipher. It’s just a few lines of codethere’s no reason not to try it before thinking about alternatives. […] Given that we only have 255 possible keys, we can simply try out all of them and see for which keys we obtain a meaningful plaintext – for readability, it pays off to just look at a small snippet, e.g., the first 50 characters. Again, we used a different approach. Being confident that we’d find the word “flag” in the plaintext, we just checked for its occurrence.

for i in range(256):
    dec = ' '.join(map(chr, [(ord(x)+i)%256 for x in cipher]))
    if 'flag' in dec:
        print "Found possible solution for key %d:"%i
        print dec

From this solution it becomes clear that the weakness of Caesar’s cipher is the fact, that there are only 255 possible ciphertexts for a given message, which makes it feasible to just try out all possibilities (this answers a)). It also shows enough code to explain how possibilities are computed and how the correct plaintext can be identified (this answers b)).

Source Code

As stated in the project presentation slides, your report should contain a technical description of your solution. However, many submissions we received were written like this:

We first read the as described on the assignment sheet and also in our Code/Exercise3 folder. The python file is called brute-force.py. In the same file below the code for the key is the code that actually does the brute-forcing. We now run that code. This prints out loads of 2B strings on the command line and also writes it to a text document. […]

While it explains where the code that does “the brute-forcing” can be found and that it emits lots of 2B strings, it would have been much more insightful to state what “the brute-forcing” actually was, and what these 2B strings represent.

A better solution would have been

The memo reveals two severe security flaws which help us decrypt the captured data: Firstly, they use no padding. This has two implications on security: 1. Some message m always encrypts to the same ciphertext c as no randomization is added. 2. The size of the ciphertext space is upper-bounded by the size of the message space. Secondly, they only encrypt two bytes of plaintext at a time. Thus the size of the message space is upper-bounded by 2^16 = 65536. By putting all these observations together, we concluded that a simple dictionary attack is feasible.

Given the vulnerability, this part is pretty straight forward. The first step is to create a dictionary containing all the ciphertexts:

dic = dict()
for i in range(2**16):
    dic[pow(i, key.e , key.n)] = i

[…]

Of course, it is sometimes easier to explain something in code rather than describing it, so please don’t be afraid to include code snippets in your report. Ideally, the additional sourcecode you provide only serves as an additional resource for details, but your report should be fully understandable without looking at extra files.

Using Third-Party Tools

As already discussed on askbot (https://cms.cispa.saarland/askbot/sec18/question/74/you-can-includeuse-any-non-commercial-library/), you may use any third-party tools or libraries in your solutions, given that you understand how the tool works, and, more importantly, can explain to us, why it works. As an example, many of you found the RsaCtfTool (https://github.com/Ganapati/RsaCtfTool) helpful for task 2. Consider the following two submissions:

By looking at e and n of the publickey, we found that e is remarkibly small, so we searched for fitting attacks, one of them being the wiener-attack. […] As we looked through the descriptions of the attack, we found multiple scripts on github imple- menting this attack, so we tried them out. The first one was faulty, but the second one worked fine. We added the zip of the tool to the code folder.

While this submission clearly states that a third-party tool was used, it also becomes evident, that the submitters did not understand the attack or how the tool worked: The weak part of the key is not e. In fact, this value for e is commonly used in many RSA-keys. Further, while the wiener-attack is an attack against RSA, it is not applicable here. The weakness is rather in the fact that n is easily factorizable, by one prime being very small (53) and the other being a well-known mersenne prime (M4423), which allows to easily recompute phi(n) and obtain d. The only reason their “solution” worked was because the RsaCtfTool also implements a bunch of other attacks, one of them trying to factorize n.

In contrast, this submission which uses RsaCtfTool is perfectly fine:

After some web research, we found a tool which is able to perform many known attacks on a weak RSA scheme called RsaCtfTool. After installing and executing the tool in the commandline with the command

python2 RsaCtfTool-master/RsaCtfTool.py --verbose --publickey RSApkey.pem --private

it automatically performs one attack after another, until an attack was successfull, or all attacks were executed. In our case, the verbose option informed us, that the ”factordb attack” was suc- cessfull. Examining the sourcecode of the RsaCtfTool showed, that this attack simply checks, if a certain online database (factordb.com) has stored matching primes p and q such that p ∗ q = n and then it uses the invmod() function of the python package libnum, to compute the secret exponent d with e ∗ d = 1 mod ((p−1)(q−1)). With n, e and d, the RSA private key was computed and was displayed as the rest of the output. We saved the RSA private key in a file (RSAskey.pem) and used the decrypt() function of the Crypto.Publickey.RSA python package to decrypt the ciphertext (cipher).

This answer makes it clear that the weakness is due to factorizing n and also details how the private key d can be computed from the results.

TL;DR

• Explain why and how your exploit works
• Keep all relevant information in the pdf-report (but still submit your code)
• If you use a third-party tool/library, explain why and how it works

All the best

Johannes

P.S.: Posting this now might be related to the next project deadline on Thursday morning ;)

A gentle reminder: Tutorials this week will cover a basic buffer overflow exploitation challenge, which is a fundamental preparation for the third project. In other words, if you cannot solve this exercise sheet, you will inevitably face severe difficulties in solving the third project. We thus highly advise you to attend the tutorials this week.

Having said this, if you want learn something from this week's tutorials, you will have to prepare for it. At the very least, try to solve the first three questions on the sheet and configure/test your working exploitation environment (either download the VM mentioned in the sheet, or set up your own Linux with gcc/nasm/gdb) prior the tutorial. As already predicted last week, and confirmed by experience from today's tutorial, you will otherwise have no time left to work on the actual exploit, raising frustration for both you and us.

Find the VM configuration in CMS, and we also uploaded the vulnerable code/program there. Again, please be prepared, otherwise attendance is not of much value. If despite all preparation you cannot finish the exercise during the tutorial, we will be happy to help you in any questions that remain. Please just post uncertainties or questions to Askbot and we will take care of them.

Two notes about today's lecture:

• For time reasons, we skipped over slides 125--136. Please still go over these slides, as they contain valuable hints on writing shellcode and mention several practical advice that assist in exploiting software (cf. Exercise #07, Project #03).
• We updated the string format vulnerability example. As presented today, the example was not coherently using 32b or 64b code. Now the example is on 64b only, which also means that the 1st to 6th parameter are assumed to be in registers. The first five %p (plus one parameter is the formatter itself) thus print register contents, which might contain dormant values. As discussed, printf wrapper functions (cf. -D_FORTIFY_SOURCE) might require one or more additional arguments, which slightly changes the picture. The slide now also tells the exact gcc compiler flags used to create the program so that you can reproduce the example.

The final exercise sheet for this year will be discussed next week and is an applied hands-on task for software exploitation. We urge you to attend the tutorials as preparation for project #03 (which starts right after) if you don't have any exploitation experience yet. We highly advise to bring your laptops to this tutorial. We have prepared a VM that you can use to solve the challenges with a handful of preinstalled tools. Given that the tutorial timeslot is very tight for this task, if you want to finish this sheet, you will have to start working on this sheet prior to the tutorial.

We'll launch the second Security project on Web Security today (Thu) at 6:00pm CET. Following the democratic vote in today's lecture, we'll again follow the same rules as the previous project and will give bonus points to teams solving challenges first (we were asked to change this by some of you, but the majority prefers the bonus the way they are). Good luck and enjoy the 2nd project!

About teams: Your old teams stay in place if no further action is taken. However, we allow that you change/build new teams in CMS until Sun Dec 3rd at 23:59.

This is a gentle reminder that your report for project #1 is due on Thursday 08:29am (just before the lecture). Remember that you will only get points for challenges that you also described in your project report, so the report is a mandatory submission. Each team should upload one report (no need to submit two per team) via CMS, submissions via email will not be accepted.

The next minitest will be on Tue, Dec 5th, at 10:15 and will cover Authentication (Chapter 04), Anonymity (Chapter 05) and Web Security (Chapter 06). Same concept as for the last minitest. You can bring a cheatsheet that will be collected before the test, and the test will be 15 min.

We also finished planning of the minitests. In total, there will be 5 tests, which means you have to pass at least 3 tests to participate in the exam.

The dates of the tests are as follows:

1. Test: Tue, Nov 21st.  Topics: Crypto & Protocols
2. Test: Tue, Dec 5th.  Topics: Authentication & Anonymity & Web Securtiy
3. Test: Tue, Dec 19th.  Topics TBA
4. Test: Tue, Jan 9th.  Topics TBA
5. Test: Tue, Jan 23rd.  Topics TBA

This is a gentle reminder for the minitest tomorrow at 10:15 that will take place in the regular Security lecture hall (GHH). Be there on time, we cannot guarantee that late showups can still participate in the test. Also, remember to bring your first cheat sheet (optional). We will collect the cheat sheets before the minitest and will not grant submissions later.

We have uploaded three chapters of Stuttard / Pinto: The Web Applications Hacker’s Handbook (2nd edtn.) that capture the main three topics that we discuss during classes: XSS, CSRF and SQLi. This isn't mandatory reading, but highly recommended to those of you that aren't familiar with Web (security) yet.
 

Hi everyone,

after some discussion we came to the conclusion that "Hidden Messages" from project01 was pretty much unsolvable and would require too much guessing. To stop you from wasting further time on something so futile we consequently removed bonus task "Hidden Messages" from project01.

We hope you still enjoy the other tasks!

Best

Johannes

 

P.S.:

Should you still wish to solve this task, here are two hints for you:

1. It can be solved in a single line in bash using only four different tools

2. Hello olleH Uryyb SGVsbG8= 48656c6c6f

You may submit flags for this task to johannes.krupp@cispa.saarland (you won't get any points for it though).

The first week has shown that the vast majority of students has not prepared for the tutorials (in many cases not even having looked at or having printed the exercise sheet), which is not in the interest of the learning effect meant for the exercises. Please note that exercises are the best way to prepare for the exams (in contrast to the practical work of the projects), so an active participation is highly recommended. We will thus change the scheme in which tutorials operate. To foster a lively and helpful discussion during the tutorials, we will hand out slightly less time-consuming exercise sheets. At the same time, we expect everyone to prepare for the tutorials and actively participate in them. I have urged the tutors to spur lively discussion for an exercise. Please use this chance to test your understanding of the course material. However, if no such activity can be seen (e.g., because nobody prepared anything), I asked the tutors to skip over and not further discuss an exercise task. Thus, even if you do not have a complete solution to a task yet, and just have a slight idea how an exercise can be solved, actively participate in the tutorials to develop a solution with your fellow students.

• The first minitest on Cryptography and Cryptographic Protocols will be on Tue, Nov 21st, at 10:15. Be there on time and do not forget to bring your hand-written cheat sheet that we will collect before the minitest. To remind you: You can bring one cheat sheet to each minitest, plus one to the final exam. We will not accept or allow any other cheat sheets.
• We will announce the story and rules of the Security '17/'18 projects in tomorrow's (Thu, Nov 9th) lecture. Please be present to learn what the projects are about, what rules to follow and how to get a good start.
• Project #1 will start tomorrow at 6pm and last for almost 3 weeks. Find a team partner and sign up as a team by Sunday latest. All relevant project materials will be published in CMS tomorrow at exactly 6pm.
• If you have completed the Security projects in previous years' editions, you can get credits for them. In case you want to claim those credits, please forward the original email with the grade summary to Markus Bauer markus.bauer@cispa.saarland. Note, however, that skipping this year's projects will not allow you to earn precious bonus points for the exam. We thus encourage all students to participate in the newer projects, which is even possible if you already claimed credits. Details for the last two Security lecture editions:
  • Security '14/'15: Project P#1 '14/'15 maps to P#2 this year, and P#2 '14/'15 maps to P#1 this year. P#3 still needs to be completed.
  • Security '16: Project P#1 '16 maps to P#2 this year, and P#2 '16 maps to P#1 this year. P#3 still needs to be completed

Upon popular request, we have published a working document that outlines the course contents and the approximate date when each topic will be discussed. This document will be updated frequently, but can still serve you as a rough guideline. Find this Security '17/'18 timeline here:

https://docs.google.com/spreadsheets/d/1GBGSGEcvMlwQWspsZou6KM0k8N1FIxDjv27jUmfGdZE/edit?usp=sharing

We will include project dates, deadlines and minitests there soon (and let you know).

Please sign in to CMS and check your tutorial preferences ("Personal Status"). We will offer four disjoint tutorial time slots:

• Tue 12-14
• Wed 08-10
• Wed 10-12
• Thu 14-16

Choose your preferences no later than Wed, Nov 1st. We will assign tutorials on Thu, Nov 2nd.

Another note: We'll upload slides usually latest a few hours after the lecture and exactly those slides we covered in the lecture. Please note that we will update existing slides (instead of creating a new Materials entry in CMS) if the topic has not changed between two dates (e.g., we updated the slide deck on Cryptography after it was finished, and some of you missed that). Please monitor the revision numbers for changes.