So far, we've been working using packages provided from Oracle or another place, but it would be nice if we could create and publish our own package. This recipe requires that we have basic experience with compiling and installing free software.
The first thing we need to do is install some required Oracle Solaris 11 packages, which will be necessary for the next steps:
The gcc-45
package is probably already installed on the system, and it will optionally demand the gcc-3
package; if this is the case, then we have to verify that the gcc45
software is already installed and check its dependencies by running the following two commands:
According to the last line in the previous command output, the gcc-45
package depends, optionally (type=optional
), on gcc-3
, so we can install gcc-3
with the following command:
We check the dependencies of the gcc-3
package by executing the following command:
We list the gcc-3
status and its details by executing the following command:
To make this example more attractive, we can download the socat tarball application from http://www.dest-unreach.org/socat/. Socat is an amazing tool that is similar to the Netcat tool, but socat adds many additional features, such as the possibility to encrypt a connection to evade IPS systems. After downloading the socat
tool, we're going to create a very simple, persistent backdoor to package it in the Oracle Solaris 11 format, to publish it into the secondary repository (http://localhost:8888
) and install it on our own system. After we have completed all these steps, a practical example will be displayed using this backdoor.
At the time of writing this procedure, I've downloaded socat Version 2.0.0-b6 (socat-2.0.0-b6.tar.gz
), copied it to /tmp
, and opened the tarball:
Let's create the socat
binary. The usual step is to run the configure
script to check all socat requirements on the system, so let's execute it:
Before compiling the socat application, we have to edit some source files and change some lines because the original socat files don't compile on Oracle Solaris 11. In the same socat directory, we need to edit the xioopts.c
file, go to lines 3998 and 4001, and change them according to the following illustration:
The following lines are the original content of the file:
After our change, the content looks like the following:
Now, it's convenient to make it the following:
In the next step, we modify the /root/.bashrc
profile in the following way:
All the changes we have made so far enable us to execute the socat
tool from anywhere and access its manual pages too:
Note
Socat is a command-line-based utility that establishes two bidirectional byte streams and transfers data between them.
Since the socat tool encrypts connections, we need to create a digital certificate:
At the server side, we've finished the procedure to configure socat. At the client side, it's necessary to create a key too:
For the purpose of explanation and demonstration, I'm going to use the server as a client, but when handling a real-life situation, we need to execute the same command (openssl req -new -key solaris11.key -x509 -days 9999 -out solaris11.crt
) on our client.
On the same machine (client), we create a script that starts the socat tool in a persistent listening mode on port 3333
:
Though the preceding script is extremely easy, we need to pay attention to the following deployed options:
- LISTEN:3333: This is the port where socat is listening
- reuseaddr: This allows other sockets to bind to an address even if the local port (
3333
) is already in use by socat - fork: After establishing a connection, this handles its channel in a child process and keeps the parent process attempting to produce more connections, either by listening or by connecting in a loop
- cert: This is the digital certificate that we've made
- cafile: This specifies the file with the trusted (root) authority certificates
- EXEC: This will be executed
Execute the following command to make it executable:
Now that the socat configuration is complete, the next task is executed in the Oracle Solaris domain. In the first step, we create a manifest file, which is used to create an IPS package, because this manifest file contains all the required dependencies of our backdoor IPS package. The backdoor manifest file will be created in parts:
The content from the manifest file is not so complex, and there are keywords (actions) that can be interesting to learn. Moreover, the syntax is straightforward:
Some of these actions are as follows:
- file: This specifies a file installed by the package
- set: This specifies information such as name and description
- dir: This is the directory that is installed by the package
- hardlink: This points to a hardlink
- link: This determines a symbolic link
- license: This determines what kind of license is bound to the package
- depend: This lists the dependencies that this package has on other software or tools
- legacy: This sets any required information that must be installed in the legacy package database to keep the compatibility
Certainly, there are other complex manifests, but nothing that is complex enough to worry us. The following example adopts the ready manifest of the Netcat package:
In the next step, we create a MOG file (which is a kind of metadata file):
As you will have realized, all the metadata information included in the backdoor.mog
file was added at the end of the manifest.level2
file. In the third step, we include dependencies into the manifest file and then execute the following commands:
Once the dependencies list is generated, we need to resolve the dependencies against packages that are installed on the system:
Before proceeding, we need to change the previous file (backdoor_manifest.level3.res
under /tmp
directory) to install the backdoor package in the /backdoor
directory:
We are almost there. Our final goal is to assemble the package and add it to the repository:
Wow! We've done it! A good way to test this is to install our backdoor package:
Finally, we test the functionality of the backdoor. In the first terminal, we type the following:
The second step should be performed from another Oracle Solaris 11 machine (our client). However, for test purposes, I've used the same host.
An overview of the recipe
There's no question that this recipe is very interesting and complex because we created a backdoor using an encrypted connection and used different programs to accomplish our tasks. Furthermore, we learned that the package has a manifest that describes the attributes and dependencies of the associated package. It wouldn't be an exaggeration to say that the manifest is the soul of the package.