Email has always been a tool of choice cybercriminals. By capitalizing on an established company’s brand reputation, they can send emails with malicious intent (links, attachments, phishing, etc.) and trick people into trusting these emails. Adobe’s own brand reputation has been leveraged in the past for such schemes.
In order to protect our customers from potential confusion or victimization, we embarked on a project to help ensure that emails you receive from Adobe are from verified and authenticated to limit the likelihood of brand impersonation that could harm our customers.
So, how exactly do we ensure that our emails appear to our customers as from an authenticated sender? We first moved to implement email authentication technologies such as SPF (Sender Policy Framework), DKIM (DomainKeys Identified Mail), and DMARC (Domain-based Message Authentication, Reporting, & Conformance) policies into our email ecosystem. To begin, we needed to identify our Adobe-owned domains. Through this process, we identified that Adobe owned a very large number of domains. After collecting traffic against these domains, we carefully analyzed this data. Next, we made necessary adjustments to SPF and/or DKIM records for each identified domain to improve our email authentication pass rate, help protect Adobe owned domains, and better ensure that emails received by customers on behalf of Adobe are genuine.
Through this journey, we identified and overcame a few hurdles:
- Integrating our third party service providers into this program;
- Managing domain owners as part of a dynamic environment;
- Implementation of a complex process to ensure emails were sent compliant with SPF/DKIM to achieve an acceptable DMARC pass rate (usually greater than 97-99%), in order to move to quarantine and finally to a reject policy.
- Developing new domain onboarding policies with multiple stakeholders.
We continue to invest in sending “takedown” notices whenever possible for domains that we find are being used to send malicious emails or host phishing websites that impersonate our brands. There has also been a recent upswing in targeted spear phishing attacks as cybercriminals evolve and try different tactics. We continue to work to protect Adobe and our customers against these next generation of threats to Adobe’s email authenticity and its deliverability. If you do receive an email that you suspect is phishing, please forward it to us at email@example.com for investigation. These external reports help us to continuously improve our approach.
Manager, Messaging Services
Every enterprise maintains a set of privileged accounts for a variety of use cases. They are essential to creating new builds, configuring application and database servers, and accessing various parts of the infrastructure at run-time. These privileged accounts and passwords can be extremely powerful weapons in the hands of attackers, because they open access to critical systems and the sensitive information that resides on them. Moreover, stealing credentials is often seen as a way for cybercriminals to hide in plain sight since it appears as a legitimate access to the system.
In order to support the scaling of our product development we need to ensure that our environments remain secure while they grow to meet the increasing demands of our customers. For us, the best way to achieve this is by enforcing security at each layer, and relying on automation to maintain security controls regardless of scaling needs. Tooling is an important part of enabling this automation, and password management solutions come to our aid here. Using a common tool for credential management is one method Adobe uses to help secure our environment. Proper password management helps make deployments more flexible. We ensure that the access key and API key needed to authenticate to the backup database is not stored on the application server. As a defense-in-depth mechanism, we store the keys in a password manager and pull them at run time when the backup script on the server is executed. This way we can have the keys in one central location rather than being scattered on individual machines when we scale our application servers. Rotating these credentials becomes easier and we can easily confirm that there are no cached credentials or misconfigured machines in the environment. We can also maintain a changeable whitelist of the application servers that need to access the password manager, preventing access to the credentials from any IP address that we do not trust.
If an attacker were able to access build machines they could create malicious binaries that would appear to be signed by a legitimate source. This could enable the hacker to distribute malware to unsuspecting victims very easily. We use two major functions of commercially available password managers to help secure our build environment. We leverage the credential management solution in order to avoid having credentials on any of our build servers. The goal here is similar to the use-case above where we want to keep all keys off the servers, only retrieving them at run-time. In order to support this, we’ve had to build an extensive library for the client-side components that need to pull credentials. This library allows us to provision new virtual machines constantly with a secure configuration and a robust communication channel with the credential manager. Adapting tooling in this way to suit our needs has been a recurring theme in our effort to find solutions to deployment challenges.
Our build environment also uses the remote access functionality provided by password managers, which allows users to open a remote session to the target machine using the password manager as a proxy. We ensure that this is the only mechanism in which engineers can access machines, and we maintain video recordings of the actions executed on the target machine. This gives us a clear audit trail of who accessed the machine, what they did, and when they logged out. Also, since we initiate the remote session, none of the users or admins need to know what the actual passwords are since the password manager handles the authentication to the machine. This prevents passwords from being written down and shared – it also becomes seamless to change them as needed.
Credential management has become a challenge primarily because of the sheer number of passwords and keys out there. Given some of our use-cases we’ve found commercially available password management tools can help make deployments easier in the long-term. Adobe is a large organization with unique products that have very different platforms – having a central location for dealing with password management can help solve some of the challenges that we face as a services company. As we look to expand each service, we will continue to adapt our usage of tools like these so that we can help keep our infrastructure safe and provide a more secure experience to all our customers.
Pranjal Jumde and Rajat Shah
ASSET Security Researchers
“JITC certified,” you say…what’s that? JITC stands for the US Department of Defense’s Joint Interoperability Test Command, which carries out extensive work on software and other systems intended to be used by the US military for mission critical purposes.
In this specific instance, Adobe Acrobat and Reader X have been certified by JITC for their compliance with the DoD’s application requirements for Public Key Enabled services, e.g digital signatures. The testing included intensive, comprehensive evaluations of Acrobat and Reader’s capabilities in:
- Certificate operations
- Signature and certificate status validation
- Path processing and validation
- Configuration and documentation
Adobe is proud to note that we have consistently been certified for JITC compliance in every version of Adobe Acrobat and Reader back to version 7 back in 2006.
Click here for a link to the official JITC list of software and solutions that have been tested for Public Key Enabled compliance.
The Dutch government today announced that DigiNotar’s subordinate Certificate Authorities (subCAs) under the Staat der Nederlanden root certificates will be revoked next Wednesday, September 28th. This follows on the Dutch government’s removal of trust from DigiNotar, DigiNotar’s removal from the Netherlands Trust List, and the company’s announcement of bankruptcy proceedings.
As discussed earlier on this blog, the Adobe Approved Trust List (AATL) has been updated to remove the DigiNotar Qualified CA root certificate. Users of Adobe Reader and Acrobat X (version 10.x) will be automatically updated to this list.
To be sure your copy of Adobe Reader or Acrobat will get the update, you can force a download of the AATL. Go to Preferences->Trust Manager->Automatic Updates and click the Update Now button. Also, be sure the “Load trusted root certificates from an Adobe server” option is checked.
A future product update of Adobe Reader and Acrobat version 9.x will enable dynamic updates of the AATL. In the meantime, users of Adobe Reader and Acrobat 9 can manually remove the DigiNotar Qualified CA using instructions provided in the blog post.
Also note that the Dutch government has published a document regarding the impact of the removal on signed PDFs. That document (in Dutch and English) can be found at the links below:
This posting is provided “AS IS” with no warranties and confers no rights.
In the past two weeks, it has come to light that Dutch certificate authority DigiNotar suffered a serious security breach in which a hacker generated more than 500 rogue SSL certificates and had access to DigiNotar’s services, including many that were relied upon specifically by the Dutch government for key citizen and commercial services. The full extent of the attack is still not clear.
Last week, many of the major browser vendors removed DigiNotar certificates from their list of trusted certificates, and in turn, the Dutch government renounced trust in DigiNotar and took over certificate operations at the company.
What Does This Mean for Adobe Customers?
The DigiNotar Qualified CA root certificate is part of the Adobe Approved Trust List (AATL) program, which we have mentioned in this space on multiple occasions. The AATL is designed to make it easier for authors to create digitally signed PDF files that are trusted automatically by Adobe Reader and Acrobat versions 9 and above, and includes many certificates from around the world.
While Adobe is not aware of any evidence at this time of rogue certificates being issued directly from the DigiNotar Qualified CA root in particular, an official report by Dutch security consultancy Fox-IT stated that there was evidence of the hacker having access to this CA, thus possibly compromising its security. (The rogue certificates known today are SSL certificates originating from the DigiNotar Public CA.)
Adobe takes the security and trust of our users very seriously. Based on the nature of the breach, Adobe is now taking the action to remove the DigiNotar Qualified CA from the Adobe Approved Trust List. This update will be published next Tuesday, September 13, 2011 for Adobe Reader and Acrobat X. We have delayed the removal of this certificate until next Tuesday at the explicit request of the Dutch government, while they explore the implications of this action and prepare their systems for the change.
Just last night, we announced the availability of updates to both Adobe Acrobat and Reader, bringing them up to version 10.1. Along with a significant list of vulnerability mitigations, these updates also bring with them substantial changes to the secure operation of Acrobat on Windows, and to the digital signature functionality across platforms.
First, Acrobat 10.1 on Windows now features the same Protected Mode operation as Adobe Reader X, protecting users from malicious PDFs. Additional information on Acrobat’s implementation of sandboxing is available on the Adobe Secure Software Engineering Team’s (ASSET) blog. For those savvy in digital signatures, note that Protected Mode (on both Acrobat and Reader) may impair the installation of PKCS#11-based tokens. Refer to the simple instructions here for a workaround.
And if you’re like me and love the nitty-gritty details of digital signatures, you’ll probably appreciate the other signature-specific changes in 10.1…
Version X of Adobe Acrobat and Adobe Reader include the RSA BSAFE Crypto-C ME 18.104.22.168 encryption module with FIPS 140-2 validation certificate #1092. To enable FIPS mode in Acrobat and Reader X and restrict document encryption and digital signatures to the FIPS approved algorithms (AES/RSA/SHA) in this library, please refer to Section 6.1.11 of the Acrobat Digital Signature Admin Guide.
Information on FIPS compliance in Acrobat and Reader 9….see this post.
Today, Adobe pushed out yet another update to its certificate trust program implemented in Adobe Reader and Acrobat. The AATL program, launched in 2009, makes it easier for users to view and rely on digitally signed PDFs by automatically displaying a green checkmark for those signature credentials which meet higher assurance requirements when opened in Reader and Acrobat 9 and X.
The update today included the Columbian A.C. Raiz Certicamara S. A. root certificate for Acrobat and Reader X.
Adobe released updates of all of the LiveCycle components when we released our “ES2” version in November 2009. As a part of this we made some significant strides to expand how you can integrate our product suite into other directory, identity management, and authentication systems.
I’d like to take this opportunity to explain some of what is new, as well as show you several videos that go into each area in more depth.
First, our integration with ActiveDirectory and LDAP directories executes substantially faster, as we have optimized the system to only pick up records that have changed recently. More info:
Second, our integration with Smartcards and PKI certificates for strong authentication is much more flexible, and supports many more types of certificates. More info:
Third, several customers have asked us to query one directory for user information, but integrated with a second instance for high performance authentication. We’ve listened and now support this — more info:
Finally, all of our web- and Flex-based components now support SAML-based federated identity for authentication. Technically, this means that LiveCycle is substantially more flexible in terms of the Single-Sign-On (SSO) and authentication facilities that be used. In practice this means that it is very easy for you to integrate LiveCycle into your processes for interacting with customers and engaging with citizens without deploying additional identity provisioning or management software. More info: