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.
Background
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 secureemail.pncsecureemail.com. 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="https://secureemail.pncsecureemail.com/formpostdir/safeformpost.aspx" 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="
-----BEGIN VOLTAGE SECURE BLOCK V3-----
UEsDBBQAAAAAAAAAAABdo9VpjgAAAI4AAAASAAAASW5zZWN1cmVBdHRyaWJ1dGVz
b3dIQXdDYVdRRUZuSmhkMlZ6ZEdWeVozSmxia0JuYldGcGJDNWpiMjA9AgEBMA8G
C2CGSAGG/R4BAQIGBQAEZAMrbFNNghQwEPLfr5czqMTikZY9MN3LM6lBPurbo6lj
oOLtmf31bvVB5Iin/qEJa5mud/FivFBCUaPlYTjtabMJl1LaGWiiHg+dJYzCUF+9
*** REMOVED ***
OIUzlCwd5RAGlaI/SLa+xjhl75n1Vbypkq5IXlsHuy9p8XOd5PU9994x77F0aoHv
zpC1MK/Cv78r+qIHiENYZJXf+FW78phI4smoFkyQhygk2n+YigadY8ROSuXy8/E+
97mm0ivDl5rm5D+QyO4YmASd175vw+YR+c6OW4Cjdw7JQP4Q0rquABEKNJZUep9a">
<input type="hidden" name="ZFRdata2" value="
lIgN/KdTwBjcoWhy69Eu0nCmb8ZhjAmY+rKYrCOQXgrU9sMt+wkgYzsGAbai+22T
kkpupD3wJRFc8qA+lNcO5D+qYsH91jJYUAncsC1gRxmXdoeF6YkrrXQwd5Kwf3va
Ao69NfGeJHr3+iA2LUY6Doj+DJb/T938iQXKDsmy4DSFQPuRPs2pH0qBJtmpNScx
vEYAuRpCj38/uGm01yXJLRLXNLKGX6cNXSoNWfQjRJmlWnAvaR4jHgzeAh7XQYd2
*** REMOVED ***
sOqams968CSCG3ZoSRzIuYz6ksVK0S4R/LBICZdd822jA/v7l5wKoUddDwtyGJIw
dKeYkd+/gofi7qWt6ubST2eaHiIZ0Jkp7keX1wnJLtzFdyX26TjF6lzxdNIKQW+d
Gq0VF/KAUvcBxqx0Z8jGhQoDOwNpYgkzY8xf9JPs1jzhrU4y2kpj6+im9ADmSbRE
Zg0qnePTzt5Blcpigk4kw7rvF/a86/RpMKhIbhW1Is4/ruwLTfB8wuFYX5gnPlj5">
<input type="hidden" name="ZFRdata3" value="
JvLzILfz9OhHFjp54axoORY9uTWJvNPovXd4nhX7tQSIVM0CF3ADCJET2bb0fbjV
*** REMOVED ***
AAAAAAC+AAAASW5kZXhQSwUGAAAAAAIAAgBzAAAAWwwAAAAA
-----END VOLTAGE SECURE BLOCK V3-----">
<input type="submit" value="Click to Read Message">
</form>
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.
Vulnerability
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.
Disclosure
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 pnc.com — why create unnecessary confusion by using secureemail.pncsecureemail.com? 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:
