A Week in Vegas
My first time at BSidesLV and DEF CON was in 2018, and while I was adamant that I wouldn’t go again for a short while, I found myself back there this year. It was definitely worth it, and I wanted to share what I learnt along the way.
BSides LV — Pros vs Joes
Every year, BSidesLV is the host of an attack/defend, purple team styled CTF called Pros vs Joes. The Red Cell’s (red team) have access to the network for a full month before you even get to BSidesLV, understanding the infrastructure, planting beacons, and hiding backdoors. I participated as a Blue Team Joe this year, and our team, Elective Surgery, actually ended up winning!
I had the expectation of jumping into what I already know how to do. Harden Windows systems, perform analysis’ to find evidence of compromise. But to me, that’s not what this competition should be about. I came in as a Joe, so I decided to focus on an area that I wanted to improve on, which is defending Linux machines. I made it my life’s purpose within those two days to ensure that a small portion of the linux systems were kept alive; are the services that are being scored on running? Am I able to SSH in? Have the Red Cell planted things for me to find? Here’s what I took away from it all:
As shown below was an instance of me SSH’ing into a linux machine, only to find a message from the Red Cell. This is done by modifying /etc/motd/ (or “message of the day”) but they also planted a backdoor in /root/.bashrc so that any commands run will show the cake graphic and not the result of your command.
As one of my awesome teammates pointed out, you can run the first set of commands below to actually see the output of what you’re trying to do, and the second set of commands to remove the backdoor.
echo *something* && <command you want to run>
echo *something* && chattr -i /root/.bashrc && /bin/rm /root/.bashrc
At the beginning stages of the CTF, it was important to install some tools that would later be used for triage efforts. This, combined with the fact that some linux distributions tend to cause headaches with such software, there would be times when you don’t want to do a full OS upgrade, but rather upgrade security packages only. You can achieve this by running:
apt-get install unattended-upgrades
Linux Hardening Tips
Change the root password; use chpasswd if securing a larger environment
Change or create new users, change user passwords:
useradd, usermod -a -G sudo <user>, passwdAdd SSH keys to /home/<user>/.ssh/authorized_keys
The last thing you want is a DoS against your network, taking down all of your machines. Disabling IPv6 is a must:
sysctl -w net.ipv6.conf.all.disable_ipv6=1sysctl -w net.ipv6.conf.default.disable_ipv6=1
Similarly, you want to prevent ICMP floods and backdoors by adding the following iptables rules, where the last two rules accepts nettools ping and ping.exe packets based off only the data field of ICMP ECHO requests:
iptables -X; deletes all previous iptables rules
iptables -I INPUT -p icmp -j DROP
iptables -I INPUT -p icmp -m string — algo bm — string ‘abcdefghijklmnopqrstuvwabcdefghi’ -j ACCEPT
iptables -I INPUT -p icmp -m string — algo bm — string ‘+,-./01234567’ -j ACCEPT
Stop any scheduled tasks that are running:
killall -9 crond
chmod 000 /sbin/crond /usr/sbin/crond /usr/bin/crond /bin/crond
Linux Forensics
There are a few directories that you’d want to look at for evidence of compromise.
Logs on user logins, user activity, reboots, installations, USB devices, network configuration and changes can be found in:
/var/log/
/var/log/messages
/var/log/syslog
/var/log/journal
/var/lib/NetworkManager
Temporary files/storage; check the attacker hasn’t left any scripts or tools behind:
/tmp
/var
/home/<user>/
User activity; look for newly created users and command line history:
/home/<user>/.ssh/authorized_keys; check the root directory too
/home/<user>/.bashrc
/etc/passwd
/etc/group
if you have any suspicions of tools that were installed on a particular machine, look in /etc for their configuration files.
DEF CON 27
Demo
I was fortunate enough to go see an awesome demo of a tool written by @marcosd4h called memhunter, which allows you to hunt for ‘memory resident malware’ at scale. You can find the code and demo video’s yourself here: https://github.com/marcosd4h/memhunter.
The kind of suspicious activity that this tool aims to locate, which Marcos described as ‘hunter heuristics’ was split into nine separate categories:
- Modules: modules that are associated with RWX memory regions
- Threads: unbacked or floating code living in memory regions
- Memory Regions: check PE header over these regions
- Call Stack: check call stack of threads for unbacked symbols
- Base Address: if the base addr of the main module (.exe) is private, it should always be memory mapped and not marked as RWX. This also detects a technique called Process Hollowing
- Exports: such as ReflectiveLoader
- Hollowed Modules: in-memory vs on-disk comparison of modules, compare their entry points, the size of the code etc.
- Registry Persistence: common registry injection or persistence techniques
- Shellcode: looks for RWX memory regions that start with well known x64/x86 opcodes
Running memhunter alongside Process Hacker allows you to monitor the processes and threads running during an executable’s lifespan, discover network connections made by these processes, and detect malware.
DNS Rebinding Attack
Over the past few years, DNS has been a huge focus for at least one APT group and the security industry. I thought I’d broaden my horizons and attend a talk a little different to what I’d usually see. This was ‘State of DNS Rebinding: Attack & Prevention Techniques and the Singularity of Origin’ by Gerald Doussot and Roger Meyer. Here’s a brief overview:
- The ‘same-origin’ concept is where you have two webpages that consist of the same scheme (so HTTP or HTTPS), host (domain), and port.
- ‘Cross-origin reads’ are not permitted, as a webpage with one origin should not be allowed to read the contents of a webpage with a different origin. However, a malicious actor can ‘bypass restrictions imposed’ by the ‘same-origin policy’ using DNS rebinding where the victim runs a client-side script on their webpage after visiting the attacker’s web server.
- The victim browser would have unauthenticated access to the target service (127.0.0.1), yet this would be blocked if the attacker DNS attempts to connect to it. But using the rebinding technique, it exploits the fact that the ‘same-origin’ policy looks at the domain name and not the IP address. If you can get the IP address of one webpage to quickly change to that of another by modifying the TTL setting… you can successfully exploit this vulnerability. In most instances, this can be achieved in under 5 seconds:
- How can we protect ourselves against such attacks?
Block RFC 1918 IP Addresses (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16)
Block localhost addresses
Block local internal networks
Block 0.0.0.0/8
But in true DEF CON fashion, these have been bypassed too as demo’d by Doussot and Meyer. The best way of preventing these attacks would be to ensure the use of TLS *everywhere*, and use authentication.
CTFs
The Blue Team Village this year played host to their OpenSOC CTF, which actually became eligible for a Black Badge. As the hotel networks were heavily congested, I wasn’t able to dedicate the time I wanted to to compete in this contest. However, the three tools that competitors had access to were:
- Graylog: open source log management tool
- Kolide: endpoint security solution that allows you to query logs
- Moloch: ‘ Large scale, open source, indexed packet capture and search’.
In the meantime, I decided to focus on the Unofficial DEF CON DFIR CTF. This was super neat as it splits the competition into four different sections: memory forensics, dead disk forensics, linux forensics, and triaging a Virtual Machine. I’ll be uploading at least one write-up pretty soon from this as it was an awesome learning experience.
Over and out.
