Achilles’ Heel. Proofpoint.com.

The myth of Achilles starts with his mother, the Nereid, Thetis. Determined to thwart the Greek Gods, and make Achilles immortal, she dipped him into the River Styx.  However, the only place the waters did not cover him was where he was held by his mother as she dipped him – his heel. It is from her act we have the expression “Achilles’ Heel” – a mortal vulnerability in what otherwise would be an invulnerable person or situation. This vulnerability can be visible or invisible. But the vulnerability is invariably found, and is fatal.

Proofpoint got its start as a cloud service screening e-mail and blocking phishing attempts and malware. Proofpoint found success, and went public. (NASDAQ: PFPT). It has a market capitalization as of the date of this article of $6.68 billion. (Market capitalization courtesy of Yahoo Finance as of today's close.) It has since added other services. However, we are going to take a closer look at is foundational service, e-mail screening to block phishing and malware, as well as the basic (actually, lack thereof) security of its web site. 

In December of 2016, Proofpoint published a “Technical Brief” titled “How To Sign With DKIM”, an effort to encourage the use of DKIM to vastly reduce phishing attacks. The following is Proofpoint’s link to their Technical Brief PDF.

https://www.proofpoint.com/sites/default/files/how-to-sign-dkim-technical-brief-cm.pdf

 (For a somewhat less technical explanation of DKIM, please see my LinkedIn article, “Do Not Feed the Phish. Part 3 of 3.” published on August 13, 2019.) 

Proofpoint’s business model for e-mail filtering appears to have evolved since then to handle DKIM for customers, charging them per mailbox, rather than have the customers implement DKIM and possibly avoid having to use Proofpoint’s e-mail filtering service. We looked at Proofpoint’s web site, where it has posted some of its customers, and tested some of these listed customers for DKIM implementation on their own servers.  

Some of, to us, curious failures to implement DKIM on their own servers: Strook, Strook and Lavin. Grand Canyon University. Wedbush Securities. One might think that Proofpoint would encourage strengthening anti-phishing defenses everywhere possible with its customers, rather than make them 100 percent dependent on Proofpoint providing DKIM. We do not know why, but we do recommend to these customers, plus every other Proofpoint customer using their anti-phishing service, that they implement their own DKIM. They may find that they no longer need Proofpoint, and its monthly invoice. 

Turing to Proofpoint’s own public-facing cyber security, we reviewed it, starting with its web site: 

https://www.proofpoint.com/us

 For implementing website security using HTTP Headers, the www.proofpoint.com site gets a solid “F”. The following HTTP Headers are all missing, and with them, the anti-hacking protection they provide. 

·        Strict-Transport-Security

·        Content-Security-Policy

·        X-Frame-Options

·        X-Content-Type-Options

·        Referrer-Policy

·        Feature-Policy

 Also, we disagree with their exposure of their web server information. The web server probe publicly states it is being powered by “ngix”; we prefer to provide “unknown”.  Proofpoint is also exposing its Content Management System (CMS), Drupal 7, and its Content Delivery Network (X-CDN), Incapsula. All of this information could be hidden from hackers by the use of a Web Application Firewall (WAF), thereby forcing potential hackers to do recon, which increases the odds of them getting caught. 

We also note in the source code of the www.proofpoint.com home page further details on the use of bam.nr-data.net, including, and I quote:

"licenseKey":"0ae22ad83e","applicationID":"51794255","transactionName":"bgQBYERQXBBWVBFbDldOIldCWF0NGEcEVQRmDAJaV1ZXEWhZClYEZhcKUUFuQgJQUg==","queueTime":0,"applicationTime":390,"atts":"QkMCFgxKTx4=","errorBeacon":"bam.nr-data.net","agent":""}

 At Quantalytics, we believe that to successfully defend against hackers, the first step is that one must deny them any information at all that might make their efforts easier and less likely to be caught.  E.G. The above license key and application ID!  Proofpoint has saved any potential hackers the need for this reconnaissance, and as a result, has made it easier for hackers to look for security holes. 

A review of our domain (www.quantalytics.com) will show that the Web Server is “Unknown” and that all the above HTTP Headers are locked down. Quantalytics has no exposure as a result. At Quantalytics, we call this level of configuration and protection “Quantalytics Diamond-Hard?” – and expect nothing less from Proofpoint and its website. 

(For a complete explanation of HTTP Headers, please see my LinkedIn article, "Resistance is Futile." - The Borg. HTTP Headers published on September 10, 2019.) 

The next www.proofpoint.com website cyber security problem is a misconfigured Web Application Firewall (WAF).  

Proofpoint, best case, has a misconfigured Web Application Firewall (WAF). However, we suspect that they have not deployed a Web Application Firewall (WAF) because we can see the HTTP Headers problems noted above, in addition to the exact web server software (ngnix) and Content Management System (Drupal 7) being used. These can be fixed at the web server software level, or information about their status blocked by a properly configured Web Application Firewall (WAF). Without a properly configured Web Application Firewall, even a web browser can be turned into a weapon to attack the www.proofpoint.com HTTP Header security holes. 

(For a detailed explanation of Web Application Firewalls (WAFs), please see my LinkedIn article, And the Walls Came Tumbling Down.  Web Application Firewalls, published on September 3, 2019.)  

Given our surprise and disappointment in how this erstwhile cyber security service provider is failing to protecting itself and its customers on its web site by failing to secure their web server through correct and full implementation of HTTP Headers and a Web Application Firewall, we decided to dig deeper and look at their DNSSec (DNS Security). DNSSec is used for preventing Man-In-The-Middle (MITM) attacks. These are especially worrisome if the user is going to a site such as www.proofpoint.com, where there is an implicit promise of full cyber security, given the site’s purpose, the customer base, and a login potentially susceptible to a Man-In-The-Middle (MITM) attack. 

The following is a partial map of the DNS Authentication Chain for www.proofpoint.com. It shows the end of the DNS Authentication Chain.

 The diagram shows, on the left hand side, www.proofpoint.com feeding the CNAME DNS record from NSEC3. This step is insecure. This is where a Man-In-The-Middle attack can be launched, an especially worrisome issue because the www.proofpoint.com site has a login. So a Man-In-The-Middle attack, if successful, would mean that login credentials are being harvested. 

CNAME DNS Delegation:

However, www.proofpoint.com, on the right hand side of the above DNSSec map, also feeds its DNS SOA records from NSEC3 to a third party DNS provider, incapdns.net. This is also totally insecure, providing a second attack vector for a Man-In-The-Middle attack. 

Incapdns.net SOA Record:

Compounding these errors, they have an insecure delegation from incapdns.net to x.incapdns.net – yet another potential attack vector.

Incapdns.net to x.incapdns.net Delegation:

Delegation of net. to incapdns.net:

Lastly, the delgations from incapdns.net’s SOA to the DNS A and DNS AAAA records for www.proofpoint.com, which are handled by a subdomain of incapdns.net, are both insecure.

DNS A Record:

DNS AAAA Record:

All of these DNS records are insecure, and lead to the unsurprising conclusion that DNS is completely insecure, and therefore open to Man-In-The-Middle (MITM) attacks. 

These DNSSec security holes are a combination of errors committed by Proofpoint in its effort to protect itself, and the errors committed by its vendor, which is an example of a supply chain security hole. It is clear from the DNSSec Authentication Chain for www.proofpoint.com, which has only one security hole (CNAME) as it passes to incapdns.net, that Proofpoint tried, but failed, to complete DNSSec for this URL.  

The question becomes: do they know, and deliberately chose to ignore this security hole, or did they fail to audit their own DNSSec? Since Proofpoint is a publicly held company, in addition to being a cybersecurity company offering to block security holes as a service, these security failings are surprising, and especially serious. Does the Board of Directors know? They should, if not at this technical level, then at least that all public facing Internet infrastructure has been reviewed, and any security holes found, closed. 

The net result is that www.proofpoint.com, and its related DNSSec have major failures in cyber security. This site is not even close to being “Quantalytics Diamond-Hard?”.

 We have a modest recommendation to offer Proofpoint.  Demand from your Content Delivery Network (CDN) provider, Encapsula, a properly configured Web Application Firewall (WAF), and close the HTTP Headers and DNSSec security holes by fixing them.

 This entire report is based on the publicly facing Web infrastructure for www.proofpoint.com. No laws were broken in examining the public-facing Web and Internet settings for www.proofpoint.com. Anyone with sufficient skills, and using publicly available tools, can replicate these findings.

 At Quantalytics, we have a saying we recommend for, among others, Proofpoint and its shareholders: Trust nothing. Verify everything. This is how we create “Quantalytics Diamond-Hard?” network security for our network security appliances, and for our clients. 

Achilles’ Heel. Proofpoint.com.

  Arthur Carp | Quantalytics, Inc. | [email protected] | @quantalytics