A while ago a broker company I was working with had an incident where a client received an email from a sender pretending to be a member of the company and demanded payments to be made to a specified bank account number. The client was not suspicious as he had some unpaid bills, so he transferred the requested amount to the bank account, just as it was detailed in the email. As it turned out the email was originating from a malicious 3rd party group, and because the client had weak email filtering they managed to get away with the fraud and with the client's money.
This incident could have been avoided if basic email protection measures were in place on the client's side.
First of all, the company had it's SPF record in place but the client's server did not run SPF record checks. If it did, the email would have gone straight into his spam folder. A little more detailed article on the SPF record is linked here in case you want to know more about the Sender Policy Framework.
While SPF takes steps to make sure an email that a client receives is originating from a legit server, it is still possible to amend the email's content in transit, for instance if a legit broker from the aforementioned company was really sending out emails demanding payments to a certain bank account number, a hacker could intercept the message, and change the bank account number in it. This way the hacker would receive the payment instead of the broker company. By the way, this is why payments should be made on a secure payment portal that both party trust.
However, there is a way for the sender to "sign" an email in a secure way, so if the message is tampered with in transit, the client would notice it straight away. This happens using DKIM. Technically, first a hash, a unique chain of characters is generated of the email message during the sending process. This hash would change if a single character in the original email was changed. After the client receives the email it quickly calculates a hash itself from the received version of the email. If the hash calculated matches the hash that was recorded by the sender server (it is saved in the header of the email), the client knows that the email content is original.
OK, but the hacker could recalculate the hash during the tampering process so the client would not notice anything when receiving the corrupted email, right? This is where PKI comes into the picture: before saving the original hash on the sender side, the hash is encrypted with the private key of the sender's DKIM private-public key pair. The encrypted hash can be decrypted by anyone with the public key which is freely accessible on the internet, but the hacker has no access to the private key to re-encrypt a re-calculated hash after their shady work.
On-premises Exchange servers have no built-in DKIM modules, so a 3rd party software is needed to implement DKIM (detailed here), but luckily in Office 365 setting up the DKIM signing process is very simple.
1. Create DKIM signing keys
Every domain will have a separate DKIM key-pair. First, check if the domain you want to protect has already got the keys generated. In our case it's alwayshotcafe.com:
PS C:\> Get-DkimSigningConfig alwayshotcafe.com Domain Enabled ------ ------- alwayshotcafe.com False
We have the keys ready, if we did not have them it's simple to generate it, keeping it disabled for now as we still need to set up the public CNAME records for the selectors. We'll enable DKIM when the records are set and properly propagated:
PS C:\> New-DkimSigningConfig alwayshotcafe.com -KeySize 2048 -Enabled:$false
2. Publish the public selector CNAME records
The clients will be able to decrypt the DKIM hashes with the DKIM public keys, those keys are published online using the selector records. To view what those records are, use the following cmdlet:
PS C:\> Get-DkimSigningConfig alwayshotcafe.com | fl selector*cname Selector1CNAME : selector1-alwayshotcafe-com._domainkey.alwayshotcafe2020.onmicrosoft.com Selector2CNAME : selector2-alwayshotcafe-com._domainkey.alwayshotcafe2020.onmicrosoft.com PS C:\>
We add the following two CNAME records to our public DNS accordingly:
First:
Type: CNAME
Host: selector1._domainkey
Points to: selector1-alwayshotcafe-com._domainkey.alwayshotcafe2020.onmicrosoft.com
Second:
Type: CNAME
Host: selector2._domainkey
Points to: selector2-alwayshotcafe-com._domainkey.alwayshotcafe2020.onmicrosoft.com
3. Enable DKIM for the domain
We test if the TXT record lookup retrieves the public key as the clients will do the same lookup upon receiving our emails to get the public key for the decryption process:
To finish our setup, we enable DKIM for the domain in the EOL shell window:
PS C:\> Set-DkimSigningConfig alwayshotcafe.com -Enabled:$true -BodyCanonicalization relaxed -HeaderCanonicalization relaxed
As messages are processed by the mail servers, whitespaces might be added or changed depending on the type of messaging service and structure the email hits. To ignore those changes, relaxed canonicalization is used during which whitespaces are standardized in the email before hashing, this way preventing issues when the client validates the hash.
🙂
Comments