Persistent XSS in PNC’s Secure Email System

PNC is a large financial services company with operations in both consumer and corporate sectors, predominantly located in the eastern and central United States. While making some account changes with them a few months ago, I had to exchange numerous sensitive documents with various employees within the organization. While most of the process was pretty straightforward, I found the way they handled secure documents to be interesting.


It started the way all secure communication does: a “*secure*” subject line:

At first glance, this seemed more like a phishing email than a secure message from my bank. Note how the message instructs the user to open the attachment and follow the directions. This might seem questionable to users who’re constantly reminded not to open suspicious attachments.

Opening the HTML attachment displays a similar looking interface:

The “Click to Read Message” button actually submits a form to The markup is a little easier to read than the raw HTTP request — here’s an example, snipped and rearranged for readability:

<form name="0.1_ZFRmain" method="post" action="" target="_blank">
   <input type="hidden" name="ZFRversion" value="3">
   <input type="hidden" name="ZFRtype" value="VoltageZFRMsg">
   <input type="hidden" name="ZFRDesignatedRecipient" value="***REMOVED***">
   <input type="hidden" name="ZFRdata" value="
      *** REMOVED ***
   <input type="hidden" name="ZFRdata2" value="
      *** REMOVED ***
   <input type="hidden" name="ZFRdata3" value="
      *** REMOVED ***
      -----END VOLTAGE SECURE BLOCK V3-----">
   <input type="submit" value="Click to Read Message">

The ZFRdata¬†values above are reminiscent of a PGP encrypted message, but it’s unclear whether the payload actually contains the message contents.

Next, the user must register his email address in the system by setting a password and clicking a validation link — another oddity given that a lengthy, “secure” form post was already made from the inbox! More on this later.

Eventually, the user is brought to a simple webmail interface displaying the received message:

The direct object reference in the URL above suggests the message is stored on the server, further calling into question the purpose of ZFRdata from above.


After getting set up in the system and viewing my message, I eventually returned to look closer at the webmail rendering. As I did in a previous post, I sent an email to myself containing all valid HTML elements with all possible attributes in order to determine potential XSS vectors. Here’s the full list. Though it’s missing some attributes for some elements, it’s a good starting point for identifying allowed tags.

Next, I opened the message in the Secure Email system and inspected the source. I immediately noticed that of the few elements that got through the HTML filter, all were stripped of any potential JavaScript event handlers. This was a good sign that a robust whitelist filter was in place.

I then clicked “Reply” and was brought to the compose message interface where the results were a bit different.

The new message body, composed using the TinyMCE editor, was loaded with the previous payload quoted — this time with a few elements unfiltered. After some testing, I came up the following PoC to demonstrate:

<iframe src="Javascript:alert(document.domain)"></iframe>

<abbr onclick="console.log(284098)" ondblclick="console.log(477370)" onmousedown="console.log(153386)" onmouseup="console.log(687310)" onmouseover="console.log(359441)" onmousemove="console.log(598217)" onmouseout="console.log(425628)" onkeypress="console.log(579383)" onkeydown="console.log(650647)" onkeyup="console.log(821763)" data-mce-style="display: block;">Test</abbr>

As you can see, the most serious element allowed through was the iFrame — this fired immediately upon loading the page. Though other elements were allowed through, they required some user action to trigger JavaScript events, e.g. mouse hovering over the element.


As always, the process of reporting vulnerabilities to an organization without a bounty program or, at minimum, a published contact can vary. Getting in touch with the right party within an organization is often the most difficult part and this experience was not much different — something projects like security.txt are attempting to solve.

I managed to reach someone at PNC by looking up security contacts on LinkedIn. After I had a handful of names, I guessed the email format and sent a message off asking for the right contact to which someone eventually replied. Here’s the timeline:

2017-09-12 Initial email sent to LinkedIn contacts
2017-09-14 I received a reply from VP of Ethical Hacking Team, PoC sent
2017-09-14 Follow-up response received, they are working on it
2017-09-15 Some back and forth on verfying the vulnerability, eventually confirmed
2017-09-19 I follow up, still working on patch
2017-10-03 I follow up again
2017-10-04 Reply received that patch timeline is unknown
2017-11-14 I follow up again, received reply that it’s been patched

Persistent XSS is dangerous, particularly in webmail clients due to the direct delivery of the payload to the victim.

Other Thoughts

There are a few other concerns regarding this mail system in general, some of which I alluded to above:

  • The initial messages and attachment process makes everything feel “phishy” — something even Google has been criticized for recently.
  • Users trust — why create unnecessary confusion by using Aren’t these the exact kind of domains that attackers would register?
  • This appears to be a 3rd party product created by Voltage IBE. What is the benefit of it over a simpler internal PNC messaging system using existing logins? Is it worth the expanded attack surface of a entire 3rd party codebase?
  • It seems the portal itself could be abused as a mail relay — a message from PNC doesn’t seem to be required in order to login and start sending mail.

While the vulnerability has been patched, the system itself remains confusing and unnecessarily complex during a time when users are increasingly unsure of who and what to trust online. Unfortunately, products like these may serve to actually encourage users to click on phishing links — or worse, malicious attachments.

Share this: Facebooktwitterlinkedin