Commit 7227f666 authored by Joonatan Ovaska's avatar Joonatan Ovaska
Browse files

Upload New File

parent ead2c359
# Week04 Assignment (total of 20 points)
Preparation:
* Update Wasdat to week05 level if needed. Example flow in `was-students` directory:
* `docker-compose down -v` # removes volumes (test data you created will be removed)
* `git pull`
* `docker-compose up --force-recreate`
* Force refresh the browser (CTRL+Shift+R or CTRL+F5) if needed
* Note: WasDat gives a lot of HTTP 422 Unprocessable entity when we tested developing the exploit on WasDat (not sure yet why some requests fail). Keep calm, 422's don't prevent exploitation, work your way around :-)
## First part A7:2017 Cross-site scripting (10 pts)
Assignments:
* [Reading report] RWBH Chapter 7: Cross-Site Scripting (pp. 55-70) (3 pts)
* What factors make XSS vulnerabilities more critical and why (max 2 points, 1 point per factor)
* What are the two main types of XSS and how do they differ from each other? (1 point)
* [Issue report] **Target => Juice Shop**: DOM XSS (2 pts)
* Task: https://pwning.owasp-juice.shop/part2/xss.html#perform-a-dom-xss-attack
* Complete the challenge: in score board, this is named DOM XSS
* In your report
* As usual, refer to "Issue report" from Assignment instructions (don't forget mitigation section!)
* [Issue report] **Target => WasDat**: Stored XSS w/ token capture (max 5 points)
* Tasks:
* Find a stored XSS vulnerability in WasDat (2 points)
* Demonstrate it with a payload that shows an alert
* Capture victim user JWT token using an XSS vulnerability (3 points)
* Setup a separate HTTP server (see examples below)
* Access user's token at local storage with JavaScript (1 point)
* WasDat JWT is not in cookies (that you could access with `document.cookie` if cookie properties permit it)
* Locate the token from local storage and find out how to access it with JavaScript
* Test your JavaScript snippet using Developer tool console
* Create an exploit that sends token to your HTTP server as a GET request parameter (2 points)
* Let's put XSS vulnerability, token access and attacker HTTP server together
* Exploit can activate on viewing the item, using e.g. mouse over event is fine too.
* Point is that the attacker can capture the token in e.g. their access log
* In your report:
* As usual, refer to "Issue report" from Assignment instructions (don't forget mitigation section!)
HTTP server examples
* netcat:
* nc -nvlp 6666
* listens to incoming TCP in port 6666, enough to capture incoming request (payload in URL)
* python:
* python -m http.server
* previously introduced simple Python server. shows access log in console (enough to capture payload in URL)
* anything else
* your browser needs to be able to connect to both vulnerable app and this listener (app + listener do not have to be on same network)
Notes:
* RWBH book gives a bit simplistic description of Same-Origin Policy (SOP)
* For the interested, better definition available at https://developer.mozilla.org/en-US/docs/Web/Security/Same-origin_policy
* Yes, SOP might prevent some bad things from happening
* But no, SOP does not magically prevent all XSS or CSRF
## Second part A8:2017 Insecure deserialization (10 pts)
* [Watch and answer] (3 pts)
* Watch lecture videos
* [Matthias Kaiser - Exploiting Deserialization Vulnerabilities in Java](https://youtu.be/VviY3O-euVQ?t=187)
* [DEF CON 25 Conference - Alvaro Muñoz, Alexandr Mirosh - Friday the 13th JSON attacks](https://www.youtube.com/watch?v=ZBfBYoK_Wr0)
* Based on lecture videos try to explain the terms serialization and deserialization used in computer science
* Support questions
* What are the benefits of serialization?
* Consider vulnerabilities serialization/deserialization might enable
* How serialization differs between programming languages? Offer some examples.
* [Read] RWBH Chapter 12: Remote Code Execution (pp. 119-128)
* [Issue report] WasDat Insecure Deserialization (7 pts)
Introduction:
In this week you are dealing with insecure deserialization in practice. The programming language used is Python 3 and the target application is WasDat. WasDat's backend endpoint `/api/import` performs insecure object deserialization allowing attacker to run arbitrary commands on the server remotely. For object deserialization server uses Python's Pickle module documentation of which you may want to read (https://docs.python.org/3/library/pickle.html :). Your job is to exploit the vulnerability in a way that you eventually get reverse shell to the server.
Tasks:
* Pickle (1 pts)
* Find out how Pickle module is used to serialize and deserialize Python objects
* Give some simple example to support your issue report
* Why is it insecure?
* Create Base64 encoded byte stream from Python object initialized from class that implements [__reduce__](https://docs.python.org/3/library/pickle.html#object.__reduce__) method
* Exploit insecure deserialization in WasDat's backend (`/api/import`)
* Find out what methods `/api/import` endpoint offers using `OPTIONS`
* Perform HTTP request with supported method and data created in Pickle section
* Base64 encoded payload (1 pts)
* Get flag WasFlag9_1
* Base64 encoded payload Pickle can deserialize (1 pts)
* Get flag WasFlag9_2
* Take a note of `HINT` response readers if stuck. Also, remember to follow containers log messages for possible errors
* Verify that you are able to run arbitrary command on the target server (2 pts)
* If using command that creates like a new file use `docker exec -it wasdat-backend /bin/bash` to get access to the container to prove its existence
* Remote Code Execution (RCE) for remote shell (2 pts)
* Read notes `About reverse shell creation` first
* Verify that you have active remote connection to `wasdat-backend` container
* `ps aux`
In your report:
* As usual, refer to "Issue report" from Assignment instructions (don't forget mitigation section!)
### About reverse shell creation
You might be able to utilize tools like `netcat` etc. to create reverse shell easily. However, this is not always the case. Sometimes additional tooling is not available on target system and you have to use tools coming preinstalled with the operating system. In containers this is taken even further. Docker's philosophy is that a service running on a container is built from an image size of which is as minimal as possible. This means, that the operating system running on a container should lack of all the functionality and tooling but needed to run the service. Take this as an advice to just not to look `nc` or other familiar tools to create reverse shell when you have created a working RCE exploit. Think above. How I can create a reverse shell just using `Bash` and its functionality?
Working with containers: By default containers usually and in this case opens `sh` instead of `bash`.
For reverse shell listener you can always use the tools you want, since you have the control of the system.
`nc` example: `nc -nvlp 6666`
* listens to incoming TCP in port 6666 and will pick up the target server initiated shell
Markdown is supported
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment