Nothing could be found in the user directory, but we have access to the history:
We can see an ssh -f firstname.lastname@example.org -R 6667:127.0.0.1:6667 -N line in the history, and ircd in the running processes, which both hint to a locally running irc server (6667 is the irc port).
We could try talking to it, but unfortunately there is no netcat or telnet available on this machine. However, perl is available, and sure enough here’s a one-liner replacement for netcat:
Now we can connect to the (still running) irc server and get some info:
Knowing this is an Unreal126.96.36.199 IRC server, we quickly find out about an RCE exploit:
Running this exploit confirms that we can run things and create files as the jetta user (the one that launched ircd)
The first order of things is to make our life easier and allow us to ssh as jetta directly:
We can now ssh to the machine directly as the jetta user:
Looking around we find that there’s an auth_server binary in the home directory :
The binary seems to be executing some certificates checks and output a message through cowsay.
We see that we can run the auth_server binary as root without providing any password:
We can see that the call for fortune is not absolute path, so we can change the binary by modifying the path:
We can change the path to use the “local” fortune script this way:
Now we can create a POC to test if the fortune override works:
Checking this for jetta and sudo:
Nice, we can then use this to read the content of the /passwd file:
Firstly, we run nmap against the website, to discover that (among others), the ports 80 and 22 are open.
SSH doesn’t yield any results, and we try, without luck, a possible exploit against the used version.
HTTP is a lot more interesting:
An HTTP password is asked when trying to access the main page. After a few random try on the different HTTP verbs we try to access the default index.php file, which seems to have the same security. But, making a POST request on the file returned a valid HTML page. Nice!
We can see in this web page a some useful information:
there is an image in the subdirectory images
Both directories are not protected and can be accessed and listed.
The information sent to the server is an object Info.
The scriptz folder contains the php.js script as well as a log.php.BAK file.
It seems that this file define a simple logging class in PHP. We are not sure what to do with yet…
But, we can combine this class and use it instead of the Info one in the POST request. Using the following script:
What will happen here is the following:
The Log string will be unserialized by the PHP server script.
During this step, the filename and data fields will be saved to a set of defined values.
When the object is destroyed, the content of data will be written in the file filename.
We had to figure out the directory to use. After some research, we figured out the default Apache folder is used.
The payload is a simple web shell and will be placed in the folder scriptz.
Now, we must find something to do with this shell, first of, the following script enhance the usage of the web shell:
This very simple script will get the web page, passing the command as a GET argument and display the result.
We immediately check for the /passwd file, which is, unfortunately, accessible only by the root user.
After some time looking around, we can see that the files in /home/rene/backups are constantly updated. It seems that a backup file is created every minute, and every 5 minutes the 5 backups are compressed together.
Checking the /etc/crontab file confirm this, two scripts are running, both as root, this could be the way to leverage the passwd file.
A detail that is interesting, is that both scripts are run as root, but one of them is readable:
The interesting part of the script is the line:
Indeed, there is a vulnerability concerning this *. If a file or a directory is name like a flag, the command that use the * will treat the filename as a flag.
I love fractals and I saw neat golfed examples of what you can do with the canvas (e.g. this 128 bytes dragon’s curve), so I tried to create a simple dragon’s curve generation visualisation.
My attempt displays splittings of the initial segment as it gradually turns into a curve.
Here is the full code. To make it work, you need a fixed-size canvas whose id is a (demo at the end).
Let’s break it down:
The first part create variables used during the generation:
c the canvas’s context
W the canvas’s width
H the canvas’s height
All points are vectors, the x is represented with the first element and y with the second.
The starting point of the generation is a simple line, going from the first third to the last third of the canvas.
j is a general increment value
l the length of the curve
i the current index in the curve
I use four functions of the canvas’s context: c.clearRect, c.beginPath, c.stroke and c.lineTo.
But with the following piece of code I can call c, c and so on:
Next we define our interval which will act as the rendering loop. We store it in a variable to be able to stop it later, but this can be omitted.
The first part of the loop draw the current state, all lines between the points.
This erase everything in the canvas, giving us a fresh start.
We are drawing a path, i.e. a continuous line on the canvas. Those two instructions start and finish the line.
Now the fun part, let’s start by decomposing the loop:
We are iterating through the whole point array, from last to first, creating a new line each time.
The j-- > 0 is simplified to j-- since 0 is falsy.
The c.line part is inserted in the for statement.
We are only generating a new point at a time, in order to produce the growth animation.
To insert a new element in the array at position i, we use the splice method:
We call a function that use the current and previous element to generate the new points. d is the direction of the rotation, which alternate between 1 and -1, depending on the current index.
The new element use the matrix transformation operation (defined here), but simplified to perform both rotation at the same time:
The actual formulas are:
xc = 1/2 * ( xa + ya + xb - yb )
yc = 1/2 * ( - xa + ya + xb + yb )
xc = 1/2 * ( xa - ya + xb + yb )
yc = 1/2 * ( xa + ya - xb + yb )
Using the d variable we can factor them.
Now we update our variables:
l is incremented, since we just added a new point in the array
i grow two by two and when it gets bigger than l, it goes back to one
We increment the current index by two because, as we want to proceed the next element in the array, we just added a new one. And we never proceed the first element since the matrix operations are done on the nth and nth-1 elements.
You can try it below (will only work on chrome, see below for more details):
The name to number hack for the canvas context make this works only on chrome. The other browsers does not have the same ordering.
i.e. with Chrome, Firefox and Safari:
Using the snippet:
You can change de corresponding code with the following:
One workflow I came across a lot during my programing days is the following:
I don’t usually create the best gitignore pattern on the first time, so I need to test multiple times for correctness.
Wait, that seems to be a lot of repetition ! Let’s create a vim plugin !
To check which files are considered by Vim, you can use the git ls-files command.
The options that interest us are:
--others: show files that are not tracked by git
--ignored: show only ignored files
--exclude-from=<file>: read the exclude patterns from the <file>
This will show all files normally excluded by git, as we read the exclude patterns from the .gitignore file.
The plugin is straightforward and runs as follow:
Open a new buffer
Export the first line as the excluded pattern
Insert the excluded files list in the buffer
We choose to create a file in the /tmp folder and to read/write from here. The file path is stored in the s:gitignore_file variable.
Write the pattern
This part is simple as vim provides us the getline function that fetchs the line in the current buffer.
To write it to the gitignore file, we can use the common echo method from bash along with the operator > to override the file.
Note: at first I didn’t put enclosing '' to the content of the line. But in zsh, some patterns expanded before writting to the file. e.g. * expanded to all file in the current folder.
Read the excluded files
To read an external command, vim has mutliple solutions. I tried to use the :read! command but I found out the :systemlist was better for my case.
The systemlist command runs a system command and returns its output as a list, whereas the system command returns it as a string. It is more practical to this case because we will get a list of files.
Then to insert it in the document, the setline command can take a list as second argument (the content to be inserted), it is exactly what we need. We can now insert the files at the second line to refresh the document.
Clear the file
The last step we need to complete the plugin is to clear the file between reload. The main issue here is to do so without moving the cursor.
The simplest solution is :2,$d, but it changes the cursor position. Instead, we can use the setline command to set blank lines to all lines. Then when inserting the new excluded files, we may have blank line at the end of the file, but at least the cursor don’t move.
To do so we build an array of empty strings to be inserted on all lines from the second line to the last one and insert it with setline.
I already saw some improvements I could make to speed up the process. Building only one array, adding the existing gitignore option to prevent matching files already excluded, … I will consider adding them later.
You can check an example of use here:
Please feel free to leave a comment or go see the project on github