Web Security Ben Stock

I have just checked the list of students with sufficient points and have manually admitted all to the exam. Please check your student status page to see if you have passed the necessary points. Should the scoreboard say you passed, but the CMS does not, please drop me an email.

Also, I have imported the registration data from the CMS. As of now, little over half of the students that are admitted are also registered. Please ensure you register on time (hard deadline is February 5th). Otherwise, you will not be able to take the main exam even if you qualified.

To keep all of you happily hacking, we are releasing hints for all challenges with less than 10 solves by today. Please find them below. Remember the deadline for solving them is January 27th, 10am.

In addition, don't forget to post your topics for the Q&A lecture at https://cms.cispa.saarland/askbot/websec1920/question/183/topic-for-qa-lecture/

JINJA

• Look at the example in the lecture to see what type of page might cause an attacker-controlled string to be used as a template.
• The offset in the array of functions which are children of object varies from system to system.

PHP POP

• https://www.php.net/manual/de/function.call-user-func-array.php
• Just because a variable is by default boolean does not mean it has to be for every serialized object.
• This challenge works best if done automatically in Python (otherwise c&p might really suck)

CRIME

• In some cases, you'll have a hard time guessing a character because the compression works equally for others. If that happens, save your candidates and try the next one(s).
• It also helps to repeat the string you are testing for a second time.

Owley Madison

• Look for a way to steal a CSRF token. That should enable you to do certain things for the crawler.
• It might be a good idea to outsource most of your attack to another script.
• The way Owley works is that for privacy reasons, your favorites are only stored in localStorage, such that you can select them later for a chat.
• Remember how document.domain works: once a page has set that, any of the subdomains of the target domain can access that page.

SSRF

• The goal should be clear from the secret() function in the code.
• Figure out what happens if for some reason, name resolution doesn't work.
• The solution to the challenge is actually really easy.

My second child did not want me to sleep long today, so I will not be in the office today at all. This means that the lecture will not happen today. I have uploaded both the slides and video from last semester, please use that to study the topics. Since there is only a single new jeopardy challenge out today, this should not cause too many problems.

It seems that the service we relied on for the exercise from Tavis Ormandy was shut down. I have instead now set up rebind.websec.saarland - so, resolving ac110001.8660e137.rebind.websec.saarland will flip-flop between the internal IP and our external IP.

I have also modified our Webserver config and made sure that the challenge works properly.

... are online now. Have fun exploiting LFI, POP, and Template Injection.

Please note that while we tried to secure the challenges as best as possible, you can still cause annoyance if you drop a fork bomb or such. Please don't, that's lame.

Otherwise, merry christmas, happy new year, and see you fresh on January 6th (which is also the evaluation day - if you only watch videos and look at the PDFs, this is the one lecture you should attend, as you can complain about all the things that are shitty :-))

Hi all,

due to performance reasons, there was an unintended way of leaking the flag for blind SQLi. As this unintended code snippet was deployed after the first three students captured the flag, I have deleted the submissions for all but the first three students and changed the flag.

So, if you did the exercise properly, you can run your script again to leak the flag. If you did it in the wrong way before, you now have to actually do it correctly.

We had a small bug in Screecher (read as: we forgot to install MongoDB and set up the PostgreSQL database correctly ¯\_(ツ)_/¯), which we fixed. In addition, we added another bug, which we also fixed now. I have taken the liberty to just pull in all VMs.

On top of that, we already released two new jeopardy challenges earlier today. Happy injecting :-)

We have released three new challenges (XS-Leaks, Clickjacking, and HSTS Tracking). We are *not* releasing an update for Screecher this week.

Note that for both XS-Leaks and HSTS, you need to hash the flags with SHA3_256 (not SHA256!!!) and wrap them in SWAG{} before submissions.

Happy hacking

Since the CISPA lecture hall is needed for a talk on January 13th, we have to move the lecture. Given the fact that you were all *very* awake this Monday, we'll just start the lecture earlier: at 8:30am.

Don't worry though, since we can record the lecture if it is done in the lecture hall :)

We have just released a new challenge, namely script gadgets. Please find it in the jeopardy part of the scoreboard. This might require some more time than other challenges.

Given this and also the fact that certain challenges are just harder than others, we have decided to change the scoring system (for the scoreboard only, not for the admission to the exam!). In particular, certain challenges (we'll not tell you which though :)) give more points than others (default is 128 points, the harder ones yield 256). Furthermore, there is now a first blood bonus for the first three students to solve each challenge (+20%, +10%, and +5%). Again, this is only for the scoreboard, not the admission. We have already retroactively updated your scores for the previous challenges.

We have also added another hint for base href, where it was not clear how to get to the flag (unless you had done unsafe hashes before, as it is basically the same application).

And, finally, if you liked the challenges thus far and want to spend more time hacking stuff, our local CTF team saarsec is playing ruCTFe (https://ructfe.org/) on Saturday. It's not all Web, but all hack, so you are welcome to join. If you want to, join us in 0.01 from around 10am (CTF starts at 11am) and bring a LAN adapter (if need be) for your laptop.

 

 

I have seen that some students struggled with exfiltration sensitive information out of screecher, e.g., because they run into issues with encoding of payloads and such.

An alternative approach to this is to have a "landing page" on your attacker domain to which you can redirect the crawler and pass the information you want to extract via the URL fragment. You can then use that "landing page" to do the heavy lifting of posting your to leak endpoint. That has the benefit of having that boilerplate code only once.

Just a quick clarification about the RSXSS exercise: We are crawling these URLs with a Chrome with version < 78. 
This means in particular, that the XSSAuditor is still enabled by default. 

You do not need to specifically bypass the Auditor(in contrast to the RCXSS exercise), however, you should take this into account when building your payload. Otherwise, you might accidentally trigger the Auditor. 

Submitted URLs were not guaranteed to be displayed in the correct order. This lead to confusion, since seemingly no new URLs were being added by the crawler after URL submission (while they were displayed somewhere in the page rather than at the top).
This issue has been resolved, and the submitted URLs should be displayed in the correct order now.

We have deployed a seemingly working fix today for the functionality checkers on the postMessage task. This was a race condition which only occured in about 4/100 attempts which made it incredibly hard to debug. Marius was nevertheless brave enough to slay that particular dragon. Should you still encounter an issue, please let us know via the Askbot. More generally speaking, please use the askbot as much as possibly. Otherwise, if three students have the same question, we (mostly Marius) has to reply to three individual requests. Hence, only use that channel if you are sure that your question would leak parts of the answer.

Apart from that, based on the questions we have received, I wanted to provide a couple of hints regarding the exercises. Before reaching out to use about your fixes breaking your application, please use your instance of Screecher yourself. This is best achieved with the developer tools open, as you'll see both JavaScript errors and failed requests in the console. Virtually all questions thus far could have been answered by yourselves by following these steps.

Additionally, there seemed to be a bit of confusion about what the crawler does when you submit a URL. This is specific on the task at hand, yet follows an easy pattern: set up the state correctly in the browser and then visit your link. That is, e.g., when the task is related to Screecher, our crawler will log in with the appropriate account to team0 and then visit your attacker URL. Hence, you can assume that the browser visiting your attacker page has valid authorization cookies for team0.screecher.de. Your task in then to conduct the necessary attack and leak the secret to the feedback URL at the gameserver.

Furthermore, if you are receiving this email, yet plan to not do the exercises / drop the course, please let us know. This allows us to disable the VMs and conserve some resources.

Due to some students accidentally leaking their secrets in the index.html file of their attacker folders, we decided to reset all credentials issued so far. This means in particular that old credentials including Gameserver Secrets, SSH keys and Gitlab credentials will no longer work. We have issued new Gameserver Secrets and SSH keys and adjusted the CMS and your machines and the Gitlab accordingly. Please note that once you login at Gitlab again you will prompted with a password reset form. You can simply enter your NEW gameserver secret. Your CMS already has the updated Gameserver secret. We plan on not resetting any credentials again in the future so keep your secrets secret by choosing filenames in the attacker directory with sufficiently large entropy.

We have released a new jeopardy challenge. Your goal is quite easy: gain access to the startpage of the 172.17.0.1 from the crawler's browser. The solution is not as easy :-)

To achieve that, you must run a DNS rebinding attack against the crawler. To that end, you must leverage the rbndr service (for details see https://github.com/taviso/rbndr). The service will randomly return one of the two IP addresses specified in the hostname.

We have set up our infrastructure such that if the IP points to the websec server (134.96.225.55), you can access your attacker directory. In particular, the following URL will point to user 1's attacker directory: http://7f000001.8660e137.rbndr.us/1/. Naturally, this only works for 50% of all requests as the rbndr service will either return 127.0.0.1 or 134.96.225.55.

This also means that your solution is not necessarily deterministic. When you provide a URL to the crawler, it will remain on the page for 2 minutes. In that time, find a way to rebind. Our proof-of-concept works in around 50s, so you should be fine. Use your gameserver endpoint to leak the data. Note that since the attack is non-deterministic, you may need to submit the same URL multiple times. Based on pure chance, there should not be a need to submit the same URL more than ~4 times.

As a final hint: for flushing the DNS cache, we suggest you ensure that the lookup points to 127.0.0.0/8. If you use any other range, Chrome will attempt to establish a connection which times out. This will cost you important time (recall the 120s timeout).

With that, happy rebinding!

Just as a quick note, the checkers for this week will be started tomorrow. There is a bug in Chrome 77 which requires preflight requests for all requests. We are working on a solution and will likely push updates to your git repositories.

Note that also the crawler for URLs you have submitted might not work just now. We will release another jeopardy challenge soon, though, to keep you entertained.

Hey,
usually, we will present the solutions for last week's practical exercise sheets in the tutorials. However, due to lasts week's exercise being only theoretical, we will use tomorrow's tutorial to help you with infrastructural problems or problems with the current exercise. You can also drop by and ask questions about the sample solution of the first exercise sheet or any content that has been presented in the lecture so far.

See you tomorrow,
Sebastian & Marius

For the theoretical exercises(those that do not involve attacking/defending a system), there is no need to hand in anything. In particular, this means that you do not have to hand in anything for exercise sheet 1. If you have any questions that do not leak solutions to exercises, we ask you to place them in the Askbot, a StackOverflow like forum in the CMS. This way, your fellow students can help you with your questions and any answer will be public.

Hi all,

for one of the XSS-related tasks, you will need Chrome/Chromium in a version less than 78 (which will be released shortly). Please make sure to download an installer of version 77 now, as otherwise you'll have to rely on some third-party sites to download it.

Thanks :)

The recordings of this week's Lecture and Tutorial are now online! The slide set uploaded for the Django 101 was not presented in the Tutorial and is intended to be a supplementary source of information. If you were unable to attend, you might want to have a look at the recording of the Tutorial.

Between my cold and the content of today's lecture, I totally forgot to ask the "shall we have a break?" question.

As I have a teaching commitment right after the Web Security lecture, I cannot make the lecture run longer. Instead, we'd have to start at 10:10.

Please fill out the Doodle at https://doodle.com/poll/xnrcs29xrxaxxz2k until Friday. Based on this, I will let you know if Monday's lecture (and all following ones) will start earlier or not.