I use Kali Linux on a regular basis inside a virtual machine (VirtualBox) and I have maintained my image for a couple of years.

Over the last months and years, the booting time got worse and worse, until it reached the following startup time:

1
2
3

└─$ systemd-analyze time                                                           
Startup finished in 34.355s (kernel) + 1min 42.261s (userspace) = 2min 16.617s 
graphical.target reached after 1min 42.261s in userspace.

In the first and second parts of the series, we covered some optimizations with regard to disk usage and potential problems with non-existing partitions.

I am using Kali Linux on a regular basis inside a virtual machine (VirtualBox) and I have maintained my image for a couple of years.

Over the last months and years, the booting time got worse and worse, until it reached the following startup time:

1
2
3

└─$ systemd-analyze time                                                           
Startup finished in 34.355s (kernel) + 1min 42.261s (userspace) = 2min 16.617s 
graphical.target reached after 1min 42.261s in userspace.

In the first part of the series, we covered some optimizations with regard to disk usage. In this part, we want to determine why the system takes so much time to start up, even though it has sufficient hardware resources.

I am using Kali Linux on a regular basis inside a virtual machine (VirtualBox) and I have maintained my image for a couple of years.

Over the last months and years, the booting time got worse and worse, until it reached the following startup time:

1
2
3

└─$ systemd-analyze time                                                           
Startup finished in 34.355s (kernel) + 1min 42.261s (userspace) = 2min 16.617s 
graphical.target reached after 1min 42.261s in userspace.

Clearly, this is extraordinarily much, compared to other operating systems. The system has enough memory and computing resources, so clearly the culprit is inside the operating system.

I am a C/C++ newbie, but occassionally I have to compile or build projects. Since make (and Makefiles) are quite prevalent and sometimes they have to be adjusted due to potential errors, I had to learn more about them and want to share my learning publicly here.

Building Blocks

First of all, what are the involved building blocks of make and Makefiles?

• make:
  • The GNU make utility. This is the executable that you actually run in order to execute a series of commands in order to modify files, typically compiling programs.
  • If you run the program without specifying an explicit input file with the -f option, make will look for the makefiles GNUmakefile, makefile, and Makefile, in that order.
  • make updates a target if it depends on prerequisite files that have been modified since the target was last modified, or if the target does not exist.
• makefile:
  • This is the input file for the make utility and consists of a series of instructions how to modify files.
  • A makefile can contain one or more rules.
• rule:
  • A rule consists of one or more targets, prerequisites and commands.
• target:
  • A target is a file name and typically, there is only one per rule.
• prerequisite:
  • The prerequisites are file names, separated by spaces. These files need to exist before the commands for the target are run. These are also called dependencies.
• command:
  • The commands are a series of steps typically to make the target. They need to start with a tab character, not spaces.

The general format of a Makefile is as follows:

After the seminal blog post by James Jardine in 2016 on XXE exploitation in .NET applications back in 2016, Microsoft seems to have implemented some additional changes regarding the default behavior of XML parsers.

We work through the different XML methods provided and their corresponding vulnerable configurations. For all experiments, .NET framework 4.6 was chosen.

In a recent engagement I was confronted with a blind path traversal vulnerability on a server running with the Microsoft Windows operating system. That is, it was not possible to display folder contents but the complete file name and path had to be guessed. Due to the lack of a comprehensive website I was forced to gather information from various different sources.

In this blog post, I want to summarize my findings and focus on the exploitation of  this kind of vulnerability.