Test A-R53-10 reviews DKIM records to determine if the DKIM key is of a suitable size. As the DKIM key is part of a asymetric keypair we can infer certain properties of the corresponding private key, including the key size. Therefore using small key sizes for DKIM signatures publicly advertises that your private key must also be a small size and therefore subsceptible to cracking.
The researchers at Jedi Security successfully cracked a 512-bit DKIM key and were able to forge an email with the cracked key which successfully passed DKIM checks across a number of top email service providers.
The primary issue is the usage of a 512-bit public RSA key found configured for DKIM signing at redfin.com
. Shorter RSA keys (less than 1,024 bits) are obsolete as they do not generate a large enough set of components that can withstand brute force hacking by modern day machines. As such key sizes of less than 1,024 bits have been deprecated since January 2018 as per RFC 8301.
Jedi Security utilised a cloud server from Hertzner with 8 virtual CPU cores and 32GB of RAM and 32GB of swap disk space. After 88 hours the 512 bit key was successfully cracked.
The successfully constructed RSA private key allowed the researchers to send email communications claiming to originate from security@redfin.com
in the email’s FROM
field, however, this email was sent from a separate set of email services using the cracked RSA key.
A few email providers noted the DKIM key as insecure or failed the DKIM checks for other reasons, however, the following email providers accepted the spoofed email:
Email is too critical a communication method for it to be broken so easily. Imitating a domain does not need to meet 100% success rate for it to have catastrophic impact for an organisation.
For example, outside the usual technical threats from compromised emails such as imitating senior leadership teams, confirming domain migrations, social engineering and the like, a mass email campaign imitating a company with controversial or other problematic content could destroy a company with little effort or even a low technical success rate.
For example, should a large consumer brand be imitated and mass email sent with a cracked DKIM key containing controversial content, only some emails would need to be delivered for the controversy to take effect. Whilst the DKIM key would have been cracked, it’s not going to be accepted easily by the public at large who are unlikely to accept to technical explanation as the spoofed emails would be calculated as legitimate via the DKIM protocol.
As a comparison, under English Law there’s precedent that text signatures in the email footer can imply an agreement even if added automatically. Whilst not tested in court, a cryptographic signature is a much higher bar computationally than a configuration for a text setting, hence compromise of a cryptographic signature could be much harder to deny authenticity both legally but also in the public eye.
DKIM as a standard is useful for protecting your email legitimacy from spammers and spoofing but your organisation must meet the standards required for secure DKIM, lest it become a tool that can be used against your organisation. Whilst DKIM will help against mass spam no matter the key size, a focused and targeted attacker can utilise a badly configured DKIM key to inflict catastrophic damage if motivated and skilled enough to do so. The ancient rule applies:
If you’re going to do it, do it right first time
DKIM encryption using key sizes under 1024 bits are trivial to brute force. As DKIM DNS records are public, weak email signatures are discoverable
High route53 aws
An AWS security assessment evaluates the security posture of an AWS account, analysing the cloud resources contained in an account and their configuration. The goal of this assessment is to find any resources or vulnerabilities that can be maliciously utilised to compromise any services hosted in the AWS Account. Minimising these vulnerabilities will result in the hosted services being more resilient to attack and therefore adopting a stronger security posture.
vulnerability scan cloud aws
If you are hosting applications on Amazon Web Services (AWS), it is important to consider the impact to AWS from your penetration testing. A key aspect of this consideration is determining whether what penetration testing can be safely conducted on the AWS platform without advanced permission and which testing should be abstained from without prior agreement.
penetration testing cloud aws