You will find CTF Walkthroughs showcasing the exploitation of vulnerable machines coming from VulnHub, as well as general Linux administration and security stuff. By the way; my name is Christophe Tafani-Dereeper and I’m currently finishing my Master’s degree in computer science at EPFL. My main interests are software development, software security and penetration testing.
I recently worked on a small toy project to execute untrusted Python code in Docker containers. This lead me to test several online code execution engines to see how they reacted to various attacks. While doing so, I found several interesting vulnerabilities in the code execution engine developed by Qualified, which is quite widely used including by websites like CodeWars or InterviewCake. The combination of being able to run code with network access and the fact that the infrastructure was running in Amazon Web Services lead to an interesting set of vulnerabilities which we present in this post.
This post is a walkthrough of the VulnHub machine SickOs 1.2. I previously wrote one for its little sister, SickOs 1.1. I found this second version to be more challenging, but also more realistic; the author tried to mimic what one could encounter during a real engagement – and it does it pretty well.
In this post we will set up a virtual lab for malware analysis. We’ll create an isolated virtual network separated from the host OS and from the Internet, in which we’ll setup two victim virtual machines (Ubuntu and Windows 7) as well as an analysis server to mimic common Internet services like HTTP or DNS. Then, we’ll be able to log and analyze the network communications of any Linux or Windows malware, which will unknowingly connect to our server instead of the Internet. We demonstrate the setup with a real life use case where we analyze the traffic of the infamous TeslaCrypt ransomware, a now defunct ransomware which infected a large number of systemsContinue reading… Set up your own malware analysis lab with VirtualBox, INetSim and Burp
In this post I’ll talk about how I managed to exploit the SickOs 1.1 VM made by D4rk36. The fact that the author mentions it is very similar to the OSCP labs caught my eye since I’m seriously thinking about taking this certification in a few months. 🙂 Let’s get started!
I managed to find the time to play on a new vulnerable VM. This time, it will be Vulnix and will mainly be around exploiting vulnerable NFS shares. The VM was overall quite simple, but still learned me several things about NFS and how it plays with remote permissions.
It’s been a few months since I wrote my last write-up on a VulnHub vulnerable machine. Time for a new one! The VM is called Mr Robot and is themed after the TV show of the same name. It contains 3 flags to find, each of increasing difficulty.
I recently started gaining a lot of interest in security, and after reading several CTF write-ups, I decided to try to solve one by myself. I chose Droopy v0.2. In case you don’t know, the goal of a CTF is very simple: Capture The Flag! Most of the time, the flag is simply a text file that you can obtain after having gained root access on the machine. You are only provided with a virtual machine, and the rest is up to you. Let’s get started!
I recently discovered the git bisect command. At first I thought « meh, this is just another obscure git command I’ll never use » but it actually turns out I used it several times in the last week and it saved me a non negligible amount of time. I’m therefore writing this post to make a quick introduction to git bisect.
I’ll explain in this article how to properly setup a SFTP server with chrooted users being only able to access their own directory, and authenticated by public keys or a password. This is a very useful setup, which can get a bit tricky especially with the permissions. Unlike FTPS which is FTP over TLS, SFTP is a totally different protocol built on top of SSH. This especially means you don’t need any third-party software, since OpenSSH is installed by default on most linux distributions.
It’s been a while since I last wrote a post on this blog, so I’ve decided to share a simple way to quickly access the configuration files of the numerous services you may be running on your server. It is indeed quite painful to frequently edit arbitrary deep configuration files (such as /etc/php5/apache2/php.ini) that are spread out in your file system and which you don’t remember the names. The trick I am using is a directory named cfg at the root of my server, in which I create symbolic links pointing to configuration files or directories containing them, with names that are easier to remember.