How I stumbled over a vulnerability in the Vatican
- Write Ups
- by Jacob Riggs
- 11-07-2021
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.
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.
ABOUT THE AUTHOR
