├── .gitignore ├── ArchLinux.md ├── LICENSE ├── Lab1_Fuzzing ├── README.md └── misc │ ├── clienthello │ ├── example.c │ ├── openssl-1.0.1f.tar.xz │ ├── target.c │ └── unrtf-0.21.5.tar.xz ├── Lab2_Network ├── README.md ├── img │ ├── login.png │ ├── search_'user_input.png │ └── search_apple.png └── misc │ ├── SQL.md │ ├── muumitalo │ ├── README.md │ ├── build_muumitalo.sh │ ├── muumitalo.py │ └── templates │ │ └── talo.html │ └── zipslipgen.py ├── Lab3_Botnets_and_malware ├── README.md ├── img │ └── oops.png ├── misc │ ├── malware │ │ ├── WannaCry.zip │ │ ├── Your_great_reward_is_here.eml │ │ ├── boom.encrypted │ │ └── maldocs_task1.zip │ └── sandbox.py └── see │ ├── README.md │ └── disklogs │ └── WannaCry_example_diskchanges.json ├── Lab4_Introduction_to_Shellcoding ├── Info │ └── AsciiTable.md ├── README.md ├── Tutorials │ ├── Tutorial1A_Analyzing_overflow.md │ └── Tutorial3B_Radare2_and_gadgets.md ├── prog_bin │ └── task4 └── src │ ├── pwntools_example │ └── ROP_hello.py │ ├── remoteShell │ ├── remoteShell.asm │ └── remoteShell.c │ └── vuln_progs │ ├── Overflow.c │ ├── SecretPassw.c │ └── task4.c ├── Lab5_ChipWhisperer ├── README.md ├── pictures │ ├── chipwhisperer_connected.jpg │ ├── chipwhisperer_package.jpg │ ├── difference_plot_better.png │ ├── difference_plot_horrible.png │ ├── difference_plot_not_good.png │ ├── glitch1.jpg │ ├── glitch2.jpg │ ├── glitch3.jpg │ ├── glitch4.png │ ├── rsa_sample_trace.png │ └── task_2_a_2_right_example.jpg └── scripts │ ├── PASSWORD_BYPASS.py │ ├── REST.py │ ├── SETUP_GLITCH_SIMPLE.py │ ├── setup_breaking_rsa.py │ ├── setup_password_check.py │ ├── setup_password_check_delay.py │ └── setup_password_glitch.py ├── Lab6_Digital_Forensics └── README.md ├── README.md ├── help └── nonx64 │ ├── .dockerignore │ ├── README.md │ ├── create-qcow.sh │ ├── entrypoint.sh │ └── qcow-builder.Dockerfile └── lib └── images ├── oulun yliopisto_logo_eng_black_rgb.png └── ouspglogo4.png /.gitignore: -------------------------------------------------------------------------------- 1 | \.vscode/ 2 | .idea 3 | 4 | Lab3_Botnets_and_malwares/misc/anonlog 5 | 6 | Lab3_Botnets_and_malwares/commands\.txt 7 | 8 | Lab3_Botnets_and_malwares/see/screenshots 9 | 10 | Lab3_Botnets_and_malwares/see/disklogs/filesystem.json 11 | 12 | Lab3_Botnets_and_malwares/see/malware/malwares 13 | 14 | Lab3\_Botnets_and_malwares/see/hooks/__pycache__/ 15 | 16 | Lab3_Botnets_and_malwares/see/conf/imageInfo/windows7\.xml 17 | 18 | Lab3_Botnets_and_malwares/see/conf/imageInfo/windows7.xml 19 | 20 | Lab4_Introduction_to_Shellcoding/src/vuln_progs/Overflow 21 | 22 | Lab4_Introduction_to_Shellcoding/src/remoteShell/remoteShell 23 | 24 | Lab4_Introduction_to_Shellcoding/src/pwntools_example/core 25 | 26 | Lab4_Introduction_to_Shellcoding/src/pwntools_example/payload\.txt 27 | 28 | Lab4_Introduction_to_Shellcoding/src/pwntools_example/pattern\.rr2 29 | 30 | *.log 31 | !important.log 32 | *.pcap 33 | !important.pcap 34 | *.exe 35 | !LolClient.exe 36 | *.pyc 37 | !important.pyc 38 | -------------------------------------------------------------------------------- /ArchLinux.md: -------------------------------------------------------------------------------- 1 | # Arch Linux based Virtual Machine with Black Arch repositories 2 | 3 | This Linux distribution might have different package manager than many have used to, but it has *one of the greatest wikis* for possible problem situations. See [Arch Linux Wiki.](https://wiki.archlinux.org/) 4 | 5 | This virtual machine has only those tools included that are needed to do the most of the exercises in the course, in case you don't have enough space on hard drive. 6 | Package ecosystem is also much better than in Kali Linux, if you are willing to install more by yourself. 7 | 8 | ## Image Info 9 | 10 | Image is distributed in OVA format and uses Gnome Desktop Environment as default. 11 | 12 | VirtualBox 6.1 guest additions included. Use same version for the best experience. 13 | 14 | For VMware, open-vm-tools are included. 15 | 16 | * Username: **arch** 17 | * Password: **arch** 18 | 19 | ## Black Arch repository 20 | 21 | You can directly install [Black Arch](https://blackarch.org/) tools if you need some special ones. Only few which are mandatory, are preinstalled to save the space. 22 | 23 | See their [tools](https://blackarch.org/tools.html) section for available tools. 24 | 25 | 26 | ## Installing packages 27 | 28 | Update package index 29 | 30 | ```console 31 | sudo pacman -Sy 32 | ``` 33 | 34 | Install package (You can look from here https://archlinux.org/packages/ for official packages and https://blackarch.org/tools.html for pentesting tools.) 35 | 36 | ```console 37 | sudo pacman -S 38 | ``` 39 | 40 | Remove package 41 | ```console 42 | sudo pacman -R 43 | ``` 44 | 45 | Upgrade all packages 46 | ```console 47 | sudo pacman -Syu 48 | ``` 49 | 50 | Clean package cache: 51 | ```console 52 | sudo pacman -Sc 53 | ``` 54 | 55 | ## Installing AUR packages (from https://aur.archlinux.org/packages/) 56 | 57 | Arch Linux has huge user supplied package ecosystem, which is located in the different repository. See https://aur.archlinux.org/packages/. Usually you need some kind of helper for installing these packages. 58 | 59 | [`yay`](https://github.com/Jguer/yay) helper has been pre-installed for installing AUR packages. 60 | 61 | Install AUR package (Note, that sudo not included) 62 | 63 | ```console 64 | yay -S 65 | ``` 66 | Remove AUR package 67 | 68 | ```console 69 | yay -R 70 | ``` 71 | 72 | Upgrade all packages 73 | ```console 74 | yay 75 | ``` 76 | 77 | ## Special cases on labs 78 | 79 | ### Lab 1 80 | 81 | Afl test cases are in different location `/usr/share/afl/testcases/` 82 | 83 | ### Lab 2 84 | 85 | Restart apache with 86 | ```console 87 | sudo systemctl restart httpd.service 88 | ``` 89 | 90 | ### Lab 4 91 | 92 | For compiling 32-bit versions of the binaries, 32-bit support must be enabled. This is not implemented in the provided VM version by default. 93 | 94 | Edit file `/etc/pacman.conf` 95 | 96 | Uncomment the following lines: 97 | ```conf 98 | [multilib] 99 | Include = /etc/pacman.d/mirrorlist 100 | ``` 101 | 102 | Then install 32-bit development packages: 103 | ```console 104 | sudo pacman -Sy && sudo pacman -S multilib-devel 105 | ``` 106 | 107 | 108 | Task 3A might not be possible to do directly on Arch Linux (protected). It is possible to implement this in Kali based Docker image for example. 109 | 110 | ### Lab 6 111 | 112 | Some tools are missing, but this is intentional. -------------------------------------------------------------------------------- /LICENSE: -------------------------------------------------------------------------------- 1 | MIT License 2 | 3 | Copyright (c) 2018-2021 Oulu University Secure Programming Group (OUSPG) 4 | 5 | Permission is hereby granted, free of charge, to any person obtaining a copy 6 | of this software and associated documentation files (the "Software"), to deal 7 | in the Software without restriction, including without limitation the rights 8 | to use, copy, modify, merge, publish, distribute, sublicense, and/or sell 9 | copies of the Software, and to permit persons to whom the Software is 10 | furnished to do so, subject to the following conditions: 11 | 12 | The above copyright notice and this permission notice shall be included in all 13 | copies or substantial portions of the Software. 14 | 15 | THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR 16 | IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, 17 | FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE 18 | AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER 19 | LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, 20 | OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE 21 | SOFTWARE. 22 | -------------------------------------------------------------------------------- /Lab1_Fuzzing/README.md: -------------------------------------------------------------------------------- 1 | Computer Security Lab 1: Fuzzing 2 | ==== 3 | 4 | Responsible person/main contact: Juha Kälkäinen 5 | 6 | ## Preliminary tasks 7 | 8 | * Create a Github account if you don't already have one 9 | * Create your own fork of the CompSec-2021-AnswerTemplate **as instructed [here](../README.md#instructions)** 10 | * Check the instructions on how to download and use the course's Kali Linux virtual machine 11 | * If you want to use your own computer, download and install VMWare Player to run the virtual machine. Virtualbox should work also. 12 | * Get familiar with the documentation for the following tools: 13 | * [Radamsa](https://gitlab.com/akihe/radamsa) 14 | * [AFL (American Fuzzy Lop)](http://lcamtuf.coredump.cx/afl/) 15 | * [AddressSanitizer (ASan)](https://github.com/google/sanitizers/wiki/AddressSanitizer) 16 | * [Valgrind](http://valgrind.org/docs/manual/quick-start.html) 17 | 18 | 19 | ## About the lab 20 | 21 | * This document contains task descriptions and theory for the fuzz testing lab. If there are any differences between the return template and this file, consider this to be the up-to-date document. 22 | * **You can use your own computer/virtual machine if you want.** Check the chapter "Prerequisities" for information on what you need to install. This lab has been made to be completed in a Linux environment and tested to work in the provided Kali Linux virtual machine. 23 | * It is estimated that you are able to do Tasks 1-4 during a typical lab session (4 hours). 24 | * __Upper grades for this assignment require that all previous tasks in this assignment have been done as well__, so e.g. in order to get grade 4 you will have to complete tasks 1, 2, 3 & 4. 25 | * Check the deadline from Moodle and __remember that you have to return your name (and possibly people you worked together with) and GitHub repository information to Moodle before the deadline.__ 26 | 27 | 28 | ## Background 29 | 30 | This week’s theme is fuzzing. Tasks are designed to be done with the provided Kali Linux virtual machine, see the [course mainpage](https://github.com/ouspg/CompSec) for instructions on how to run the virtual machine (VM). The provided Kali VM has all the required tools preinstalled, but if you have your own computer with some other Linux distribution, you are free to use it, just install all the required tools. 31 | 32 | In a nutshell, fuzz testing a.k.a. fuzzing is a software testing method that includes feeding malformed and unexpected input data to a program, device, or system. The programs that are used to perform fuzz testing are commonly called fuzzers. The main goal of fuzzing is to make the target system behave *unexpectedly*. From the security perspective, the goal is to find and analyze those unexpected behaviors for possible exploits and figure out how to fix them. 33 | 34 | In this exercise you will learn basic usage of 2 common fuzzers; Radamsa and American Fuzzy Lop (AFL). You will also use AddressSanitizer, a memory error detection tool, and Valgrind, a debugging tool (and memory error detector as well), which are often used alongside different fuzzers. 35 | 36 | ## Prerequisites 37 | 38 | A basic understanding of the C programming language is required. 39 | 40 | Make yourself familiar with the tools used to complete the exercises: 41 | 42 | * **Radamsa** - https://gitlab.com/akihe/radamsa 43 | * **AFL** (American Fuzzy Lop) - http://lcamtuf.coredump.cx/afl/ 44 | * **AddressSanitizer** (ASan) - https://github.com/google/sanitizers/wiki/AddressSanitizer 45 | * **Valgrind** - http://valgrind.org/docs/manual/quick-start.html 46 | 47 | ## Grading 48 | 49 |
Details 50 | 51 | Task #|Grade/Level|Description| 52 | -----|:---:|-----------| 53 | Task 1 | | Mutated test case generation with Radamsa 54 | Task 2 | 2 | Analyzing a C-program with AddressSanitizer, fuzz testing with AFL 55 | Task 3 | 3 | Creating your own small C-program and fuzz testing it 56 | Task 4 | 4 | Library fuzzing 57 | Task 5 | 5 | Contribute to an existing open-source project. Set up a fuzzer and report findings. 58 | 59 | Grade 1 can be acquired by doing mini exam for the corresponding week. 60 |
61 | 62 | --- 63 | 64 | ## Task 1 65 | 66 | ### Generating mutated test cases with Radamsa 67 | 68 | **A)** Make yourself familiar with [Radamsa](https://gitlab.com/akihe/radamsa). Try it out in a terminal and print 10 malformed samples of ```Fuzztest 1337``` using *echo*. 69 | 70 | **Provide the command line you used to do this.** 71 | 72 | Radamsa can also handle various types of files. Next, you have to generate a bunch of *.txt* test samples for later usage. 73 | 74 | **B)** Create a *.txt* file that contains only the text ```12 EF``` and nothing more. Use Radamsa to generate 100 fuzzed samples of the file that are named ```fuzz1.txt```, ```fuzz2.txt```, ```fuzz3.txt```... etc. You should create a separate folder for the samples. 75 | 76 | **Provide the content of 2 different samples that radamsa created** 77 | 78 | **Command line used to create the samples** 79 | 80 | --- 81 | 82 | ## Task 2 83 | 84 | ### A) Analyzing C program with AddressSanitizer 85 | 86 | This repository contains an example C program called [example.c](misc/example.c). Your task is to analyze it using [AddressSanitizer (ASan)](https://github.com/google/sanitizers/wiki/AddressSanitizer). Compile the code with ```clang``` and appropriate [sanitizer flags](https://github.com/google/sanitizers/wiki/AddressSanitizerFlags#compiler-flags). Run the compiled program and analyze what happens. 87 | 88 | **Command line used to compile the program** 89 | 90 | **Screenshot of the result after running the program** 91 | 92 | **What is the error and what is causing it in this program?** 93 | 94 | --- 95 | ### B) Fuzzing with AFL 96 | 97 | In the following task, you will be using [American Fuzzy Lop (AFL)](http://lcamtuf.coredump.cx/afl/) to fuzz test a program called UnRTF. UnRTF is a tool that can be used to convert *.rtf* files to *HTML*, *LaTeX* etc. 98 | 99 | AFL is already installed in the provided Kali Linux virtual machine and the target program's source code is included in this repository ([unrtf0.21.5.tar.xz](misc/unrtf-0.21.5.tar.xz)). When the source code is available, you should instrument the program by using AFL's own wrappers that work as drop-in replacements for **gcc** and **clang** (NOTE: afl-gcc might not work properly in all systems, but it works with the provided Kali Linux vm). 100 | 101 | So, here's what you need to do: 102 | 103 | 1. **Extract** the source code package ([unrtf0.21.5.tar.xz](misc/unrtf-0.21.5.tar.xz)) and ```cd``` you way to the extracted directory. 104 | 105 | 2. **Configure** it to use AFL's wrappers: 106 | ```shell 107 | ~$ ./configure CC="" --prefix=$HOME/unrtf 108 | ``` 109 | The ```--prefix=$HOME/unrtf``` flag sets the installation location of the binary file to be your home directory. This is recommended, so you don't have to give it access to the root directory. 110 | 111 | 3. **Compile and build** the program: 112 | ```shell 113 | ~$ make 114 | ~$ make install 115 | ``` 116 | 117 | __Hint__: See AFL [documentation](http://lcamtuf.coredump.cx/afl/README.txt) to learn about instrumenting programs to use AFL compilers. 118 | 119 | 4. Use AFL's example *.rtf* file located at ```/usr/share/doc/afl++-doc/afl/testcases/others/rtf/small_document.rtf``` to test that your UnRTF works by converting it to HTML: 120 | ```shell 121 | ~$ ~/unrtf/bin/unrtf --html /// 122 | ``` 123 | 124 | 5. Create two folders, one for input files and one for result output. Copy the ```small_document.rtf``` into your input folder. 125 | ``` 126 | ~$ mkdir 127 | ~$ cp /// /// 128 | ``` 129 | 130 | 131 | 6. Start fuzzing UnRTF with AFL using the example ```small_document.rtf``` file as input: 132 | ```shell 133 | afl-fuzz -i -o /// 134 | ``` 135 | 136 | __Hint__: See AFL [documentation](http://lcamtuf.coredump.cx/afl/README.txt) on how to start the fuzzer. You are fuzzing the UnRTF binary, which is located at ```~/unrtf/bin/unrtf```. 137 | 138 | 7. Run the fuzzer until you get at least 50 unique (saved) crashes and observe the status window to see what is happening. A good description of the status window can be found [here](http://lcamtuf.coredump.cx/afl/status_screen.txt). 139 | 140 | **Command line used to configure unrtf** 141 | 142 | **Command line used to run AFL** 143 | 144 | **Screenshot of the AFL status screen after stopping the fuzzer** 145 | 146 | **What do you think are the most significant pieces of information on the status screen? Why are they important?** 147 | 148 | --- 149 | ### C) Reproducing crashes with Valgrind 150 | 151 | You should now have found some crashes with the AFL. Next, you need to reproduce one of them to see, what exactly went wrong. You can find the crashes from the output folder you created previously. Make your way into the ```...//crashes``` and take one of the *.rtf* files that caused a crash under inspection. 152 | 153 | Run UnRTF with this file under Valgrind: 154 | 155 | ```shell 156 | ~$ valgrind --leak-check=yes ~/unrtf/bin/unrtf --html /// 157 | ``` 158 | 159 | __Hint__: Make sure that you are actually running the UnRTF with a crash file! If you get "Error: Cannot open input file" before Valgrind's actual memory analysis output, you are trying to run the program without any input. See the Valgrind [documentation](http://valgrind.org/docs/manual/quick-start.html) for help. 160 | 161 | **Take a screenshot of the Valgrind result after running the program** 162 | 163 | **What can you tell about the crash?** 164 | 165 | --- 166 | 167 | ## Task 3 168 | 169 | ### Fuzz testing your own program 170 | 171 | In this task, you will write a small C program and fuzz test it. In task 1, you created a *.txt* file containing ```12 EF``` and 100 malformed samples of it. We will use them in this task. Your program must take a text file as an input and check the file for the following requirements: 172 | - The file contains **two and only two tokens** that are separated with a space 173 | - First token is an **integer** 174 | - Second token is a **string** 175 | - If the content of the text file is as specified above, return 1, otherwise 0 176 | 177 | Compile and link your program with AddressSanitizer using appropriate flags. 178 | 179 | Run your program with the previously generated 100 test cases. A simple shell script loop, for example, is an easy way to run the test cases. If you don't get enough ASAN outputs with the 100 test cases, try to do the test with 1 000 or 10 000 malformed inputs. 180 | 181 | **Provide the C-code of your program** 182 | 183 | **Take a screenshot of the AddressSanitizer results after running your program with the test cases. Show at least 3 ASAN outputs.** 184 | 185 | --- 186 | 187 | ## Task 4 188 | 189 | ### Fuzzing libraries 190 | 191 | [OpenSSL](https://www.openssl.org/) is a widely-used open source cryptographic software library for Transport Layer Security and Secure Socket Layer protocols. In 2014, a buffer over-read vulnerability [CVE-2014-0160](https://nvd.nist.gov/vuln/detail/CVE-2014-0160) was found in the Heartbeat Extension of OpenSSL (up to version 1.0.1f) two years after the feature was introduced. The vulnerability allowed attackers to obtain memory contents from process memory remotely, and as a result, it compromised the integrity of secure communications. 192 | 193 | Since this vulnerability is caused by a memory handling related bug, it is possible to find it using fuzzing tools like AddressSanitizer and AFL. In order to fuzz test the OpenSSL library, we have to have a binary file that uses the library as a fuzzing target. For that, we are going to use the provided [target.c](misc/target.c), which uses OpenSSL to simulate a server-client TLS handshake. 194 | 195 | Your task is to do the following: 196 | * **Download and extract the source code** for [OpenSSL 1.0.1f](misc/openssl-1.0.1f.tar.xz). 197 | * **Instrument, compile and build OpenSSL and enable the AddressSanitizer**: 198 | ```shell 199 | ~$ AFL_USE_ASAN=1 CC=afl-clang-fast CXX=afl-clang-fast++ ./config -d -g 200 | ~$ make 201 | ``` 202 | * **Instrument and compile the fuzzing target** and enable AddressSanitizer: 203 | ```shell 204 | ~$ AFL_USE_ASAN=1 afl-clang-fast target.c -o target openssl/libssl.a openssl/libcrypto.a -I openssl/include -ldl 205 | ``` 206 | * **Create a dummy certificate**. Use OpenSSL to create for example a 512 bit RSA key. The certificate is only used during fuzzing, so it doesn't matter how secure it is: 207 | ``` 208 | ~$ openssl req -x509 -newkey rsa:512 -keyout server.key -out server.pem -days 365 -nodes -subj /CN=a/ 209 | ``` 210 | * After you have tested that the target program works, **start fuzzing the target program** with AFL: 211 | ```shell 212 | ~$ afl-fuzz -i in -o out -m none -t 5000 ./target 213 | ``` 214 | The bug is rather easy to find, so you should be able to find a crash in less than 10 minutes. Use the ```clienthello``` file as seed for AFL. The file is just a standard SSL hello message that the client sends to the server to initialize a secure session. Create an input folder for AFL and place the file there. TLS/SSL handshake takes longer than just reading input from stdin, so raise the memory limit with ```-m none``` and the timeout limit with ```-t 5000``` just in case. 215 | * **Run the target program with the crash file** you got from the AFL: 216 | ```shell 217 | ./target < 218 | ``` 219 | * To see more clearly why the crash occurred, convert the crash file into a *.pcap* file using ```od``` and Wireshark's ```text2pcap```: 220 | ```shell 221 | ~$ od -A x -t x1z -v | text2pcap -T 443,443 - 222 | ``` 223 | This command can also be used to convert ```clienthello``` to *.pcap*. 224 | 225 | **What is the more widely recognized name for this CVE-2014-0160 vulnerability?** 226 | 227 | **What can you tell about the crash based on ASAN results and the pcap file? What is causing the vulnerability?** 228 | 229 | **Take a screenshot of the AFL/ASAN results** 230 | 231 | --- 232 | 233 | ## Task 5 234 | 235 | ### Contribute to an existing open-source project. Set up a fuzzer and report the whole process and possible findings. 236 | 237 | Contribute to some existing open-source software (OSS) project by setting up a fuzzing environment and documenting the total process and results. You can choose the target software by yourself and use one of the 2 fuzzers introduced during the lab exercise, or pick some other that you think serves the purpose better. **You should do all the testing inside a virtual machine in case there are potentially malicious files being handled.** 238 | 239 | You should read for example [this guide](https://github.com/ouspg/fuzz-testing-beginners-guide) to get started. Please note that in case a real bug is found in the software, it is very important to document the findings in a way that the issue can be easily reproduced. The guide has some good points about what information you should provide. It is not mandatory for the student to file a "real" bug report, but if you find something new, we highly recommend to do so. 240 | 241 | You should grab the most recent version of the source code. Few open-source projects as an example: 242 | 243 | - [Chromium](https://www.chromium.org/Home) - An open-source browser project started by Google. 244 | - [VLC media player](https://www.videolan.org/vlc/index.html) - A common open-source media player from VideoLAN. Vast attack surface as the player uses many different libraries to handle audio/video encoding. See [features](https://www.videolan.org/vlc/features.html). 245 | - [ImageMagick](https://www.imagemagick.org/script/index.php) - An open-source suite for displaying, converting, and editing images, supporting over 200 file formats. 246 | - See [American Fuzzy Lop](http://lcamtuf.coredump.cx/afl/) main page for a comprehensive list of tools it has found bugs on. Newer versions of software can spawn new bugs, but the most common tools are usually tested the most so they might not be the best to start with. 247 | 248 | You should at minimum to provide the following information in the documentation: 249 | - Which fuzzer was used 250 | - A brief explanation of the target software and why you chose it 251 | - Are you fuzzing the whole software or some specific part of it? 252 | - Is software using some libraries? Are those fuzzed as well? 253 | - Operating system and version information. Version numbers of target software, target software libraries, fuzzer and operating system are very important! Can you explain why? 254 | - Compiler and debugger flags 255 | - Initial test case(s) and the one(s) producing a possible crash 256 | - Necessary steps to reproduce the crash 257 | - It is not necessary to find any bugs. It is enough, if you can prove that you have fuzzed with good code coverage and they way how input was mutated (=what kind of input fuzzer created overall)) 258 | -------------------------------------------------------------------------------- /Lab1_Fuzzing/misc/clienthello: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/ouspg/CompSec/35525dad3f0b38d78d822624da4bc059d7bf3da4/Lab1_Fuzzing/misc/clienthello -------------------------------------------------------------------------------- /Lab1_Fuzzing/misc/example.c: -------------------------------------------------------------------------------- 1 | #include 2 | #include 3 | 4 | int main(int argc, char** argv) 5 | { 6 | char * buffer = malloc(1024); 7 | sprintf(buffer, "%d", argc); 8 | printf("%s",buffer); 9 | } 10 | -------------------------------------------------------------------------------- /Lab1_Fuzzing/misc/openssl-1.0.1f.tar.xz: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/ouspg/CompSec/35525dad3f0b38d78d822624da4bc059d7bf3da4/Lab1_Fuzzing/misc/openssl-1.0.1f.tar.xz -------------------------------------------------------------------------------- /Lab1_Fuzzing/misc/target.c: -------------------------------------------------------------------------------- 1 | /* 2 | This program is meant to be a fuzzing target for OpenSSL 1.0.1f. It 3 | creates an OpenSSL server instance, waits for client to initiate a 4 | TLS handshake and then responds to it with server hello. The message 5 | that the "client" sends is given as an input after the server is set 6 | up. 7 | 8 | To compile (enables ASAN and AFL instrumentation, must be 9 | enabled for the OpenSSL as well!): 10 | AFL_USE_ASAN=1 afl-clang-fast target.c -o target openssl/libssl.a openssl/libcrypto.a -I openssl/include -ldl 11 | 12 | Usage: 13 | * Requires a certificate! Use OpenSSL to create a dummy certificate 14 | (RSA 512-bit, not secure but it does not matter during fuzzing): 15 | openssl req -x509 -newkey rsa:512 -keyout server.key -out server.pem -days 365 -nodes -subj /CN=a/ 16 | * Run the program 17 | ./target 18 | * After the server instance is initialized, the program will wait for input 19 | 20 | Tips and tricks: 21 | * Use this to set a location for AFL. Check the 'deferred instrumentation' 22 | from AFL docs. 23 | #ifdef __AFL_HAVE_MANUAL_CONTROL //afl deferred instrumentation 24 | __AFL_INIT(); 25 | #endif 26 | * You can check what the crash packet looks like by using od, text2pcap 27 | and wireshark: 28 | od -A x -t x1z -v | text2pcap -T 443,443 - 29 | */ 30 | 31 | /* Standard headers */ 32 | #include 33 | #include 34 | #include 35 | #include 36 | #include 37 | 38 | /* OpenSSL headers */ 39 | #include 40 | #include 41 | #include 42 | 43 | /* Error handling */ 44 | void err() { 45 | ERR_print_errors_fp(stderr); 46 | exit(1); 47 | } 48 | 49 | /* Print server state */ 50 | void state( SSL *server ) { 51 | printf("server: %s / %s\n", SSL_state_string(server), 52 | SSL_state_string_long(server)); 53 | } 54 | 55 | /* Main program */ 56 | int main( int argc, char **argv ) { 57 | 58 | /* Necessary variables */ 59 | uint8_t buf[100] = {0}; //message buffer 60 | 61 | /* Initialize the OpenSSL library */ 62 | SSL_library_init(); //initialize the OpenSSL library, load libssl algorithms 63 | SSL_load_error_strings(); //load and register human readable error strings 64 | ERR_load_BIO_strings(); //load and register BIO strings 65 | OpenSSL_add_all_algorithms(); //load all algorithms 66 | 67 | /* Set up the SSL context and use 'server.pem' and 'server'key' as the dummy certificate */ 68 | SSL_CTX *sctx = SSL_CTX_new(TLSv1_method()); //create sctx as new SSL_CTX object, use TLSv1 69 | SSL_CTX_use_certificate_file(sctx, "server.pem", SSL_FILETYPE_PEM); // Use 'server.pem' 70 | SSL_CTX_use_PrivateKey_file(sctx, "server.key", SSL_FILETYPE_PEM); // Use 'server.key' 71 | SSL *server = SSL_new(sctx); //create server SSL structure 72 | 73 | /* Initialize server BIO */ 74 | BIO *sreadbio = BIO_new(BIO_s_mem()); //initialize server input BIO 75 | BIO *swritebio = BIO_new(BIO_s_mem()); //initialize server output BIO 76 | SSL_set_bio(server, sreadbio, swritebio); //connect sreadbio and swritebio for read and write operations 77 | SSL_set_accept_state(server); //set the server to wait for the connection 78 | 79 | size_t size = read(STDIN_FILENO, buf, 100); //read from stdin to message buffer 80 | if (size == -1) { //if cannot read input from stdin 81 | err(); 82 | } 83 | 84 | BIO_write(sreadbio, buf, size); //"send" data to server (write data to server input BIO) 85 | state(server); //print server state 86 | SSL_do_handshake(server); //start server part of the handshake, read the data from BIO 87 | state(server); //print server state 88 | 89 | return 0; 90 | } -------------------------------------------------------------------------------- /Lab1_Fuzzing/misc/unrtf-0.21.5.tar.xz: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/ouspg/CompSec/35525dad3f0b38d78d822624da4bc059d7bf3da4/Lab1_Fuzzing/misc/unrtf-0.21.5.tar.xz -------------------------------------------------------------------------------- /Lab2_Network/README.md: -------------------------------------------------------------------------------- 1 | Computer Security Lab 2: Networks and web security 2 | ==== 3 | 4 | Responsible person/main contact: Juha Kälkäinen 5 | 6 | ## Preliminary tasks 7 | 8 | * Read the sections ```Background``` and ```Theory``` from this document and [```SQL.md```](misc/SQL.md) 9 | * If you are not using the course's Kali VM, make sure that all of this lab's prerequisites are met on your own system 10 | 11 | ## About the lab 12 | 13 | * This document contains task descriptions and theory for the network lab. If there are any differences between the return template and this file, consider this to be the up-to-date document. 14 | * **You can use your own computer/virtual machine if you want.** Check the chapter "Prerequisities" for information on what you need to install. This lab has been made to be completed in a Linux environment and tested to work in the provided Kali Linux virtual machine. 15 | * It is estimated, that you are able to do Tasks 1-3 during a typical lab session (4 hours). 16 | * __Upper grade requires that all previous ones have been done as well.__ 17 | * Check the deadline from Moodle and __remember that you have to return your name (and possibly people you worked together with) and GitHub repository information to Moodle before the deadline.__ 18 | 19 | ## Background 20 | 21 | Most of us browse the Internet daily. We are using a wide variety of platforms and browsers to access different kinds of websites or web applications. In many cases, users can give some kind of *input* to these websites or applications, regardless of their platform or browser. A lot of things could go wrong if this user input is not properly validated or sanitized. 22 | 23 | In this lab, we will go over some basic network and web-related security issues with the help of [OWASP Juice Shop](https://github.com/bkimminich/juice-shop). 24 | 25 | This site could be just like any other website, but if we cite the developers of it: "Juice Shop is supposed to be the opposite of a best practice or template application for web developers.", we might suppose that it is not. 26 | 27 | OWASP collects a list of [top 10 security risks](https://www.owasp.org/index.php/Top_10-2017_Top_10) each year. Juice Shop contains them all, and therefore it is a great tool for demonstrating them. 28 | 29 | The intention is to learn *why* the following things on tasks are happening and how we might be able to prevent them. 30 | 31 | On a later task, we will also practice capturing and analyzing traffic with [WireShark](https://www.wireshark.org/), and further by using [Nmap](https://nmap.org/) for mapping the network. Our target will be [Example Voting App](https://github.com/dockersamples/example-voting-app) 32 | 33 | ## Theory 34 | 35 | Juice Shop is vulnerable to multiple types of [injections](https://www.owasp.org/index.php/Top_10-2017_A1-Injection). Here we are mostly focusing on [SQL injections](https://www.owasp.org/index.php/SQL_Injection). In SQL injection, the user injects SQL code to the SQL query happening on the server-side. This is usually possible because the SQL query that is happening on the server-side takes the client's input *straight* as a parameter. An attacker can modify the query and this way expose, modify or even destroy data in the database. SQL is just one example of injection - any similar way, which takes some strings or characters as input to create some kind of command, can be vulnerable. 36 | 37 | In many places, the Juice Shop is [improperly validating its inputs](https://cwe.mitre.org/data/definitions/20.html). This gives the attacker the ability to give an input that the application is not expecting. You will see this in action when you cash out with a negative amount of items or when you leave a 0-star review of the store. 38 | 39 | Usually, shops like Juice Shop are made to be used by multiple users. In these cases, different users have different privileges and are therefore able to access different places. For example, you are able to access your basket but not other users' baskets. In the same fashion, only the admin should be able to access the administration panel. However, Juice Shop's [access control is broken](https://en.wikipedia.org/wiki/Privilege_escalation) and users can access places that they should not be able. 40 | 41 | We also delve into the basics of cross-site request forgery. A short explanation of the concept taken from [OWASP](https://www.owasp.org/index.php/Cross-Site_Request_Forgery_(CSRF))."Cross-Site Request Forgery (CSRF) is an attack that forces an end user to execute unwanted actions on a web application in which they're currently authenticated. CSRF attacks specifically target state-changing requests, not theft of data since the attacker has no way to see the response to the forged request. With a little help from social engineering (such as sending a link via email or chat), an attacker may trick the users of a web application into executing actions of the attacker's choosing. If the victim is a normal user, a successful CSRF attack can force the user to perform state-changing requests like transferring funds, changing their email address, and so forth. If the victim is an administrative account, CSRF can compromise the entire web application." 42 | 43 | The final thing we focus on by using the Juice Shop is Cross-Site Scripting. A short explanation of what Cross-Site Scripting means taken from [OWASP:](https://www.owasp.org/index.php/Cross-site_Scripting_(XSS)) "Cross-Site Scripting (XSS) attacks are a type of injection, in which malicious scripts are injected into otherwise benign and trusted websites. XSS attacks occur when an attacker uses a web application to send malicious code, generally in the form of a browser side script, to a different end-user. Flaws that allow these attacks to succeed are quite widespread and occur anywhere a web application uses input from a user within the output it generates without validating or encoding it. 44 | 45 | An attacker can use XSS to send a malicious script to an unsuspecting user. The end user’s browser has no way to know that the script should not be trusted, and will execute the script. Because it thinks the script came from a trusted source, the malicious script can access any cookies, session tokens, or other sensitive information retained by the browser and used with that site. These scripts can even rewrite the content of the HTML page ". During this lab, you will see XSS in action and will create your own attack. 46 | 47 |
48 | Helpful links for learning more: 49 | 50 | https://cwe.mitre.org/data/definitions/20.html 51 | 52 | https://www.owasp.org/index.php/Data_Validation 53 | 54 | https://www.owasp.org/index.php/Top_10-2017_A1-Injection 55 | 56 | https://www.owasp.org/index.php/Injection_Flaws 57 | 58 | https://www.owasp.org/index.php/SQL_Injection 59 | 60 | http://cwe.mitre.org/top25/ 61 | 62 | https://en.wikipedia.org/wiki/Privilege_escalation 63 | 64 | https://www.owasp.org/index.php/DOM_Based_XSS 65 | 66 | https://www.owasp.org/index.php/Cross-site_Scripting_(XSS) 67 |
68 | 69 | 70 | ## Prerequisites 71 | 72 | 73 | If you are using the virtual machine provided to you by the course staff, 74 | then everything should be already installed on your machine. 75 | 76 | Below are the steps to set it up on your own system, in case you want to use your own computer, or you are otherwise unable to acquire the provided virtual machine. 77 | 78 |
By tasks (Click to collapse) 79 | 80 | ### Task 1 81 | 82 | Get [Docker](https://www.docker.com/) instance for Juice Shop v8.7.2: 83 | ```shell 84 | ~$ docker pull bkimminich/juice-shop:v8.7.2 85 | ``` 86 | 87 | All the tasks are doable using your browser's developer tools. Tasks were tested and created by using Firefox, but other browsers should work just as well. 88 | 89 | ### Task 2 90 | 91 | For the brute-forcing task, the tools vary depending on how you choose to do it. Read the instructions and proceed to get the tools you want. There are some hints in the task description. 92 | 93 | In the CSRF task, you will need to host a website locally. Course's Kali Linux VM uses apache2, but you are free to choose your own method. 94 | 95 | ### Task 3 96 | 97 | Depending on the way you choose to complete this task, you might need to set up a basic python and [flask](http://flask.pocoo.org/)/[BaseHttpServer](https://docs.python.org/2/library/basehttpserver.html) server. You are free to set up the server any way you wish. 98 | 99 | ### Task 4 100 | 101 | the example-voting app is located at 102 | ```shell 103 | ~$ git clone https://github.com/dockersamples/example-voting-app 104 | ``` 105 | 106 | Install Wireshark and Nmap. The method depends on your operating system. 107 | 108 | For the security experiment, you can use Burp, ZAP, or any other tool you wish. 109 | 110 | --- 111 | 112 |
113 | 114 | ## Grading 115 | 116 |
Details (Click to collapse) 117 | You are eligible to following grades in this exercise by doing tasks as defined. Great ideas and implementations could compensate for some poorly implemented ones. 118 | Upper grade requires that all previous ones have been done as well. 119 | 120 | It is estimated, that you are able to do Tasks 1 & 2 during the lab session (4 hours). 121 | 122 | Task| Grade/Level | Description 123 | :--:|:--:|-- 124 | 1|2|Basic SQL injections, Client-Side resource manipulation, and basics of Cross-Site Scripting 125 | 2|3|More complicated SQL injections, Cross-Site Request Forgery, and Brute Forcing 126 | 3|4| Arbitrary file upload and Cross-Site Scripting 127 | 4|5| Network traffic analysis and a security experiment 128 | 129 | Grade 1 can be acquired by doing lecture questionnaires from the corresponding lecture. 130 | 131 | ### Particularly in tasks 1 and 2: 132 | 133 | ***To be able to complete these tasks,*** you will need to explain *why things are happening*. Each answer, which is giving only pure commands or code is automatically thought of as incompleted or insufficient. 134 | 135 | We are aware, that some answers are already available out there. 136 | 137 |
138 | 139 | --- 140 | 141 | ## Task 1 142 | 143 | Start the Juice Shop v8.7.2 docker instance. Use the Network tab in your browser's developer tools to follow the traffic. 144 | 145 | If you are rusty on your SQL injections check the following before you start: https://www.acunetix.com/websitesecurity/sql-injection/ 146 | 147 | Start Juice Shop with the command 148 | ```shell 149 | ~$ docker run --rm -p 3000:3000 bkimminich/juice-shop:v8.7.2 150 | ``` 151 | The site is hosted at ```localhost:3000```. Access it with your browser. If you can't see the web page, terminate the container with ```Ctrl+C``` and try to restart docker with the command 152 | ```shell 153 | ~$ sudo systemctl restart docker 154 | ``` 155 | and run Juice Shop again. Observe and modify the traffic with your browser's developer tools while browsing the site and do the following tasks. 156 | 157 | __Note:__ In Firefox's dev tools, in the "Headers" section of packet information, there is a handy "Edit and Resend" button that can be used to modify packets. 158 | 159 | --- 160 | 161 | 162 | ### Basic SQL Injections 163 | 164 | **Noticing errors** 165 | 166 | Try to search for something from the store by using the search field and monitor the network traffic. Pay attention to how the store sends the search query to the server. You can see, that the search field is only used to apply a filter to a dataset that is requested from the server when loading the page, so the search field itself is not vulnerable to SQL injection. However, you can see the API endpoint where the requests are sent. 167 | 168 | Use your browser's developer tools to edit and resend this request, and cause an __SQL__ error by injecting some SQL as the search argument. The server will return an SQL error message if you cause one, and it is viewable from the browser's developer tools. 169 | 170 |
171 | Hint 172 | The GET request is sent to http://localhost:3000/rest/products/search?q=. Try different SQL symbols like statement terminators, comments and quotation marks. Check the network tab for the server's response. 173 |
174 | 175 | __What did you use as the search argument to cause an error?__ 176 | 177 | __Why did it cause an error?__ 178 | 179 | __Paste here the command that the SQL server attempts to execute and replace the part(s) taken from the search field with the text "SEARCHRESULT".__ 180 | 181 | --- 182 | 183 | **Deleted item?** 184 | 185 | The shop has an item that has been deleted and therefore does not show on searches. For some reason, the shop doesn't just remove the item but instead uses another way to set the item as deleted. Do an SQLi-attack that returns all the items (including the deleted one). Use your browser's developer tools to observe the response from the server. 186 | 187 |
188 | Hint 189 | Examine the SQL query that the server returned in the last part. How does this query exclude deleted items? Remove that part of the query using comments. 190 |
191 | 192 | __How are the items "deleted"?__ 193 | 194 | __How did you make the server return all the items?__ 195 | 196 | 197 | __Explain shortly the logic behind your attack. Why does it work?__ 198 | 199 | --- 200 | 201 | **A bit more concrete error** 202 | 203 | As we previously noticed, we are indeed able to inject some SQL commands to the server using search queries. How about login fields? If this area is vulnerable, it could be very dangerous, because it might enable unauthorized access. 204 | 205 | Inject some SQL into the login fields, [bypass the login](https://www.acunetix.com/websitesecurity/sql-injection/) and log in as the first user in the database. 206 | 207 | __What command(s) did you use?__ 208 | 209 | __Why it is working/what is happening?__ 210 | 211 | __What user did you login as?__ 212 | 213 | 214 | --- 215 | ### Inspecting the client resources 216 | 217 | **Scoreboard** 218 | 219 | Sometimes the HTML contains unwanted stuff. This site, for example, has a hidden scoreboard. Use your browser's developer tools and find the path to it. 220 | 221 |
222 | Hint 223 | Firefox's developer tools has a debugger that shows sources. Try to find the path by using some guessed keywords. 224 |
225 | 226 | __How did you find the path?__ 227 | 228 | --- 229 | 230 | **Administration panel** 231 | 232 | You might see some additional and interesting stuff while inspecting sources. Try to search for clues about administration and access the Juice Shop's administration panel. 233 | 234 |
235 | Hint 236 | Check task 'Scoreboard'. You have to be logged in as the admin to access the page. 237 |
238 | 239 | __What is the administration panel's URL?__ 240 | 241 | --- 242 | ### XSS attacks 243 | 244 | **Annoying pop-up** 245 | 246 | Next, we attempt some cross-site scripting attacks. While you are logged in as any user, insert the following code snippet to the "Order ID" field in the "Track Orders" tab and to the search field. This should trigger the XSS: 247 | 248 | ```js 249 |