#### Ivan Christian 1003056
Sender IP : `10.0.2.7`
Receiver IP : `10.0.2.8`
Attacker IP : `10.0.2.10`

# 2




# 3

Email Sent

From [e-mail]  Fri Jun 23 21:22:04 2023
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received-SPF: None (mailfrom) identity=mailfrom; client-ip=10.0.2.7; helo=user-1.example.com; envelope-from=[e-mail]; receiver=<UNKNOWN> 
Authentication-Results: mysmtp2;
	dkim=fail reason="key not found in DNS" (0-bit key; secure) header.d=example.com header.i=@example.com header.b="g8v0YDs9";
	dkim-atps=neutral
Received: from user-1.example.com (unknown [10.0.2.7])
	by mysmtp2 (Postfix) with ESMTP id 3169F62C08
	for <[e-mail]>; Fri, 23 Jun 2023 21:22:03 +0800 (+08)
Received: by user-1.example.com (Postfix, from userid 1002)
	id A9A1961698; Fri, 23 Jun 2023 21:22:03 +0800 (+08)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=example.com;
	s=default; t=1687526523;
	bh=ShddNa5Iek34WryBN2twtMkLxv7o90PNk4Uuh5yurPE=;
	h=Subject:From:To:Date:From;
	b=g8v0YDs9WsaGnD2c05P+8eBK6uOdugWSoodh9+dz3HK+QrwRtDTbnrGXVrxyheBOX
	 EnzxT5bZ7jpCdkGxDzbIumTUqWZA8HF9qxKF043h+g+DAUmpouFTOgmn/qVt44GXwB
	 tbGc9ppikZzTm8htZzVT4GWYYOyheCMgmfISGrG0=
Subject: Subject 1
From: [e-mail]
To: <[e-mail]>
X-Mailer: mail (GNU Mailutils 3.4)
Message-Id: <[e-mail]>
Date: Fri, 23 Jun 2023 21:22:03 +0800 (+08)

Hello from User 1

# 4
The following is the result of `dig txt google.com`:
The result of the dig shows that the next domain to dig is `_spf.google.com`
The result of the `_spf.google.com` dig shows that the permitted IP addresses are stored in

_netblocks.google.com, _netblocks2.google.com, _netblocks3.google.com

For `_netblocks.google.com`:

For `_netblocks2.google.com`:

For `_netblocks3.google.com`:

We can see that `_netblocks2.google.com` contains only ipv6 addresses so it is out of scope of the question, and therefore, we will considering only inputs from `_netblocks.google.com` and `_netblocks3.google.com`:

,Network Space, Subnet Mask, No. of Host
_netblocks.google.com, 35.190.247.0,/24,254
_netblocks.google.com, 64.233.160.0,/19,8190
_netblocks.google.com,66.102.0.0,/20,4094
_netblocks.google.com,66.249.80.0,/20,4094
_netblocks.google.com,72.14.192.0,/18,16382
_netblocks.google.com,74.125.0.0,/16,65534
_netblocks.google.com,108.177.8.0,/21,2046
_netblocks.google.com,173.194.0.0,/16,65534
_netblocks.google.com,209.85.128.0,/17,32766
_netblocks.google.com,216.58.192.0,/19,8190
_netblocks.google.com,216.239.32.0,/19,8190
_netblocks3.google.com,172.217.0.0,/19,8190
_netblocks3.google.com,172.217.32.0,/20,4094
_netblocks3.google.com,172.217.128.0,/19,8190
_netblocks3.google.com,172.217.160.0,/20,4094
_netblocks3.google.com,172.217.192.0,/19,8190
_netblocks3.google.com,172.253.56.0,/21,2046
_netblocks3.google.com,172.253.112.0,/20,4094
_netblocks3.google.com,108.177.96.0,/19,8190
_netblocks3.google.com,35.191.0.0,/16,65534
_netblocks3.google.com,130.211.0.0,/22,1022

Total of ipv4 addresses = $328918$

-----------------

After cloning the sender machine:





Add in `db.example.com` in receiver machine :

`TXT @ v=spf1 ipv4:10.0.2.7 ~all` where 10.0.2.7 is the real sender vm and 10.0.2.10 is the IP address for the attacker machine.

From the real sender, there's no failure. This txt is saved under `real_sender.email`


We can now see that the sending to receiver has soft failed, indicated by `Received-SPF: Softfail` when it receives from the attacker VM. This txt is saved under `attacker_sender.email`

# 5

Running `sudo cat /etc/opendkim/keys/example.com/default.txt`:

Copying this to receiver's `db.example.com`:

default._domainkey	IN	TXT	( "v=DKIM1; h=sha256; k=rsa; ""p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDkEiG1kbvRa1sHI1RhOW97XyGELTxcrphb33yfzNH2DPNd86/+3ktM4G25Ik2Tf22pljkeY/x45LSKBbTpPzbblvtUd0SS9I5L3f3onppk2dbg0mu50jP9e938BF5y71Mkwjmr11K3owBj2iI1SM3bh55x4cmifsUsIEdecd+6tQIDAQAB" )  ; ----- DKIM key default for example.com


The significance of all the tags in your DKIM entry (v,a,c,d,s,t,bh,h,b):

- v: indicates the version of the signature specification. DKIM1 is used here.
- h: hashing algorithm. Sha256 is used here.
- k: encryption algorithm used, rsa is used here.
- p: public key to be used for decryption of the received msg.

The following are not shown in the exercise:
- a: indicates the algorithm used to generate the signature. We have used v and h. In this case should be rsa-sha256.
- S: indicates the selector record name used with the domain to locate the public key in DNS. The value is a name or number created by the sender. • Here is an example of a DNS selector record. The tags shown in this example only appear in this record within DNS and not in the email header itself: <selector(s=)._domainkey.domain(d=)>. TXT v=DKIM1; k=rsa; p=`<public key>`
- b: the hash data of the headers listed in the h= tag; this hash is also called the DKIM signature and encoded in Base64.
- Bh: the computed hash of the message body. The value is a string of characters representing the hash determined by the hash algorithm.
- d: indicates the domain used with the selector record (s=) to locate the public key. The value is a domain name owned by the sender.
- h: list of headers that will be used in the signing algorithm to create the hash found in the b= tag. The order of the headers in the h= tag is the order in which they were presented during DKIM signing, and therefore is also the order in which they should be presented during verification. The value is a list of header fields that won’t change or be removed.

Sending from the original yields the following:

We can see that there is a DKIM-Signature in the email now. The content is sved under `dkim-signature.email` which is later changed to `dkim_verified.eml` for submission

To ensure that the local DNS contains the public key, the following is run:

`dkimverify < dkim-signature.email`


# 6

Modifying the key :

Original

Modified


`the character changed is the first capital A to a capital B`

Sending message from the original sender:

Received message:

The key is shown to be invalid:

# 7

DMARC (Domain-based Message Authentication, Reporting, and Conformance), BIMI (Brand Indicators for Message Identification), and ARC (Authenticated Received Chain) are email security extensions that aim to enhance the protection of email users.

**DMARC**: DMARC is a protocol that allows domain owners to specify how emails from their domain should be authenticated. It builds upon SPF (Sender Policy Framework) and DKIM (DomainKeys Identified Mail) to provide stronger email authentication. DMARC enables domain owners to set policies for email receivers on how to handle emails that fail SPF or DKIM checks. It also provides reporting mechanisms to inform domain owners about the usage of their domain in email messages. The DMARC record for Gmail may specify a policy like "v=DMARC1; p=quarantine; rua=mailto:[e-mail]," indicating that emails failing authentication should be quarantined, and DMARC reports should be sent to the specified email address.

Example:

`nslookup -type=txt _dmarc.gmail.com`


The policy is set to "quarantine", which means that any emails to the recipient gmail that fail DMARC authentication will be delivered to the recipient's spam folder.

**BIMI**: BIMI is a standard that allows domain owners to associate their brand logo with authenticated emails. It works in conjunction with DMARC and verifies that the sender's email is properly authenticated. When an email with a verified logo is received, the recipient's email client can display the associated brand logo next to the message, indicating its authenticity and building trust with the recipient. When Gmail sends an authenticated email to a recipient, it can include a BIMI header in the email's headers. This header can reference a URL where the recipient's email client can retrieve the brand logo associated with Gmail. The email client can fetch the logo from the specified URL and display it alongside the email, enhancing the recipient's trust in the email's authenticity.

Example:


The brand logo of the sender is displayed.

**ARC**: ARC is an extension designed to preserve email authentication results across intermediaries involved in the email delivery process. It addresses the issue of email forwarding, where the original authentication information may be lost or modified. ARC creates a chain of cryptographic signatures that validates the authenticity of the email at each intermediary, allowing the final recipient to trust the email's origin. In the case of Gmail, when an email is forwarded through intermediaries, each intermediary can add an ARC seal to the email's headers, signing the relevant authentication results. When the email reaches the final recipient using Gmail, the ARC seals are verified to ensure the email's authentication integrity throughout the forwarding process.

Example: