In the previous chapter, we downloaded and hopefully successfully installed the tool in Kali 2.0. If not, we can use an earlier version of Kali. We will now use the tool to store information from our testing. We will take advantage of this and have PBNJ deposit our scan findings into a MySQL database that we will prepare.
Type the following in the command line:
# service mysql start
The service should be started. You can also use service stop or service restart in the same manner. It is also important to note that the traditional way of using the start up commands is also good to know. For example:
# /etc/init.d/mysql start
Prepare the PBNJ database using the following steps:
# mysql Welcome to the MySQL monitor. Commands end with ; or g. Your MySQL connection id is 48 Server version: 5.5.43-0+deb7u1 (Debian) Type 'help;' or 'h' for help. Type 'c' to clear the current input statement. mysql> CREATE DATABASE BTpbnj; Query OK, 1 row affected (0.02 sec) mysql> CREATE USER 'tester'@'localhost' IDENTIFIED BY 'password'; Query OK, 0 rows affected (0.01 sec) mysql> GRANT ALL ON BTpbnj.* TO 'tester'@'localhost'; Query OK, 0 rows affected (0.01 sec) mysql> exit
We created a database named BTpbnj, added a user named tester with a password of password, granted that user full database access, and exited the database.
Now, we need to edit the PBNJ configuration file to use our newly created database. Make a directory under root named .pbnj-2.0/ (mkdir -p pbnj-2.0) and then change to that hidden directory. Perform the following command to copy your mysql.yaml configuration file to config.yaml:
root@kali:~/.pbnj-2.0# cp /usr/share/doc/pbnj/examples/mysql.yaml config.yaml
Once the file has been copied, we need to edit several items using nano:
# nano config.yaml # YAML:1.0 # # Config for connecting to a DBI database # SQLite, mysql etc db: mysql # for SQLite the name of the file. For mysql the name of the database database: BTpbnj # Username for the database. For SQLite no username is needed. user: "tester" # Password for the database. For SQLite no password is needed. passwd: "password" # Password for the database. For SQLite no host is needed. host: "127.0.0.1" # Port for the database. For SQLite no port is needed. port: "3306"
The following fields in config.yaml that are highlighted need to be changed to match the following:
- db:
mysql - database:
BTpbnj - user:
tester - password:
password - host:
127.0.0.1 - port:
3306
Exit nano by first saving your work with Ctrl + O, followed by Enter, and then Ctrl + X to exit.
Here, we scan 192.168.75.0/24:
# /usr/local/bin/scanpbnj -a "-p- -T4" 192.168.75.0/24
This command initiates scanpbnj and uses the -a flag to use one of the now familiar Nmap flags. We targeted the 192.168.75.0/24 network in this example.
Once the scan is complete, you will see something along the lines of the following output appear on your screen:
-------------------------------------- Starting Scan of 192.168.75.2 Inserting Machine Inserting Service on 53:tcp domain Inserting Service on 80:tcp http Scan Complete for 192.168.75.2 --------------------------------------
That's all there is to it. We now have a record of what is on our 192.168.75.0/24 network sitting in a database ready for our review.
The information is in the database now, but how can we review it? Well, because we decided to use MySQL, we can rely on our previous MySQL knowledge to perform any type of query we like! Here are some examples:
Log in to the database and tell it to use the BTpbnj database:
# mysql Welcome to the MySQL monitor. Commands end with ; or g. Your MySQL connection id is 52 Server version: 5.5.43-0+deb7u1 (Debian) Type 'help;' or 'h' for help. Type 'c' to clear the current input statement. mysql> use BTpbnj; Reading table information for completion of table and column names You can turn off this feature to get a quicker startup with -A Database changed
Once we are logged in, let's try some queries:
mysql> show tables; +------------------+ | Tables_in_BTpbnj | +------------------+ | machines | | services | +------------------+ 2 rows in set (0.00 sec)
There are two tables in the MySQL BTpbnj database.
mysql> describe machines; +-----------------+---------+------+-----+---------+-------+ | Field | Type | Null | Key | Default | Extra | +-----------------+---------+------+-----+---------+-------+ | mid | int(11) | NO | PRI | NULL | | | ip | text | YES | | NULL | | | host | text | YES | | NULL | | | localh | int(11) | YES | | NULL | | | os | text | YES | | NULL | | | machine_created | text | YES | | NULL | | | created_on | text | YES | | NULL | | +-----------------+---------+------+-----+---------+-------+ 7 rows in set (0.01 sec)
Now, we have some fields that we can base our next query on. Note the created_on and machine_created fields. These timestamps come in handy when performing your baselines.
mysql> select ip,os,created_on from machines where ip = "192.168.75.2"; +--------------+------------+--------------------------+ | ip | os | created_on | +--------------+------------+--------------------------+ | 192.168.75.2 | unknown os | Wed Jul 29 19:57:39 2015 | +--------------+------------+--------------------------+ 1 row in set (0.00 sec)
We selected the ip, os and created_on fields from our database. Now, let's move on to some more interesting information.
mysql> describe services; +-----------------+---------+------+-----+---------+-------+ | Field | Type | Null | Key | Default | Extra | +-----------------+---------+------+-----+---------+-------+ | mid | int(11) | YES | | NULL | | | service | text | YES | | NULL | | | state | text | YES | | NULL | | | port | int(11) | YES | | NULL | | | protocol | text | YES | | NULL | | | version | text | YES | | NULL | | | banner | text | YES | | NULL | | | machine_updated | text | YES | | NULL | | | updated_on | text | YES | | NULL | | +-----------------+---------+------+-----+---------+-------+ 9 rows in set (0.00 sec)
Looking at this information, we can see that we are now able to pull queries not just for one host, but for all hosts at once. Also, the output from this database could be in XML and then transferred to whichever tool we are using to track our penetration testing results.
Tip
MySQL commands can be run from the command line so that the output can be exported into the format of your choice. Use the -X or -H switches when invoking the MySQL command to save to each respective file type. Most penetration testers will need a good understanding of the MySQL command syntax to be fully effective.
Let's see what type of data was collected in our simple scan:
mysql> select * from services; +------+---------+-------+------+----------+-----------------| | mid | service | state | port | protocol | version | banner | machine_updated | updated_on | +------+---------+-------+------+----------+-----------------+ | 42 | domain | up | 53 | tcp | unknown version | unknown product | 1319986659 | Wed Jul 29 19:57:39 2015 | | 42 | http | up | 80 | tcp | unknown version | unknown product | 1319986659 | Wed Jul29 19:57:39 2015 | +------+---------+-------+------+----------+-----------------+
Using a database to store your findings is very efficient and highly recommended. Scan your virtual lab and test some of the different methods of extracting your data. Using this data wisely, it is possible to quickly determine the network environment, standard software versions, and other information that will be critical to determining which targets you should focus on during the next stages of the penetration test.