
If you're concerned with IT security, you can't miss the OWASP Top 10. The non-profit organization Open Web Application Security
Offence: What is email spoofing? "The sender is real after all ..."
Email spoofing or spoofing refers to the actions of, for example, a hacker pretending to send an email on behalf of a company or domain to which they do not belong. A small example: An invoice is sent to companies or private individuals in the name of Telekom.de, but this invoice does not come from Telekom, but from the hacker. However, the domain looks correct on closer inspection. So how can this be?
Since e-mail is a form of communication that allows messages to be sent and received in a decentralized manner via protocols such as SMTP, there is no central body that can check sent messages for validity. As a result, it is easy to forge sender addresses. This must be thought of as putting a false sender address on a letter. For the recipient, it is not possible to evaluate whether a letter was actually sent by the specified sender without further measures and checks. The situation is fundamentally the same for e-mails.
For sending e-mails you basically do not need an e-mail server. We use the tool swaks here, for example
swaks --to y.knoll@prosec-networks.com --from spoofuser@spoofdomain.de --h-From: '"Spoof User" ' --server 104.47.7.138 -p 25 --header "Subject:Titel der E-Mail" --body ‘Guten Tag,\n\ndies ist der Start des Mailtests.\n\nMfg Spoof User’ --ehlo spoofdomain.com
-to | Recipient email address |
-from | E-mail address of the sender |
-h-From | Display name of the sender or spoofed e-mail address |
-server | The mail server of the receiving domain |
-header | Header part of the email can be customized here, primarily it is about the "Subject" field. |
-body | Here you can define the content of the e-mail |
-ehlo | Name with which the sender logs on to the receiving mail server. |
The recipient of the e-mail will then see it as follows:
Technically in the background the sending of the e-mail looks like this:
That simple?
No, it is not quite that simple. There must be certain conditions or misconfigurations so that the hacker's mail does not end up in the spam folder or does not arrive at all.
For this purpose, there are two DNS records that a domain should have stored so that such a spoofing process is not possible. These are the Sender Policy Framework (SPF) record and the DomainKeys Identified Mail (DKIM) record.
The Sender Policy Framework (SPF) is a procedure that allows mail servers to check whether an e-mail received actually originates from an authorized server. This is a fully automatic mechanism that is executed unnoticed by the end user.
Example of an SPF record
Hostname | Type | Time to Live | Value |
Example.org | TXT | 1 hour | v=spf1 ip4:192.0.0.1 ip4:192.0.0.2 -all |
Such an entry must be deposited at the DNS server of the sending domain. The first part is the host name. This is the domain or subdomain to which the record applies. Type describes the type of record. SPF records are entered as TXT type. Time to Live instructs the DNS server to keep the DNS record in the cache for a certain time.
The value is the actual SPF syntax. The parameter "v" describes the used SPF version, in this case version 1. After that two IPv4 addresses are named as addresses of mail servers in the example. Other entries could be set here like A or AAAA ("a") mail server records ("mx"). In addition, IP4 or IP6 can be used to specify not only individual IP addresses, but also IP ranges.
The final part of the SPF syntax is a directive that gives recommendations to the checking mail server on how to handle emails that fail an SPF check. In the case of the example, it is recommended that the mail server treat all checked emails that do not meet the criteria of the SPF record as "fail" ("-") and not deliver them at all. There is an additional possibility to define a "Softfail" ("~") "Neutral" ("?") or "Pass" ("+").
DKIM (DomainKeys Identified Mail) is a method of e-mail authentication. DKIM is used to sign e-mails that are sent. A key pair consisting of a public and private key is used for this purpose. The public key is stored as a DNS entry on the DNS server of the sending domain. Receiving mail servers can then use this public key to check whether the signature was made with the corresponding private key. A sender of an e-mail can thus prove that his e-mail is actually a legitimate e-mail from the corresponding domain.
When an e-mail is sent, DKIM adds a so-called DKIM signature to the header of the e-mail. Here, "headers" of the sent e-mail are signed using the private key. At least the "from" header must be used as the signature; other headers can be added optionally.
When the e-mail is received, the receiving server requests the public key. Only if the sender is in possession of the private key can the signature be validated. The recipient can then check whether the signature matches the checksum. If the match is present, it is proven that the sender is in possession of the private key of the DKIM key pair and is therefore very likely a legitimate sender.
Example DKIM signature:
v=1; a=rsa-sha256; d=example.net; s=brisbane;
c=relaxed/simple; q=dns/txt; i=foo@eng.example.net;
t=1117574938; x=1118006938; l=200;
h=from:to:subject:date:keywords:keywords;
z=From:foo@eng.example.net|To:joe@example.com|
Subject:demo=20run|Date:July=205,=202005=203:44:08=20PM=20-0700;
bh=MTIzNDU2Nzg5MDEyMzQ1Njc4OTAxMjM0NTY3ODkwMTI=;
b=dzdVyOfAKCdLXdJOc9G2q8LoXSlEniSbav+yuU4zGeeruD00lszZ
VoG4ZHRNiYzR
Source: Wikipedia
v: Version
a: Signature algorithm, in this case RSA with a SHA 256 hash
d: Domain of the sender
s: Selector. Identification of the corresponding record in the DNS records. This is required if multiple SPF records are published for a domain
c: Canonicalization. Specifies how strict the signature check is. The value "simple" or "relaxed" can be specified here for the header and body options. These potential changes are changes to the e-mail header or body that are made by the e-mail server itself when sending the e-mail. The option "simple" states that almost no changes may be accepted. Even small changes will then cause the signature check to fail. The "relaxed" option allows moderate changes. This can be e.g. a conversion to lower case and a removal of unnecessary whitespace.
q: Query methods. Defines the method by which the public key is queried. Default value is "dns/txt"
i: identity of sender
t: timestamp of signature
x: expiry time of signature
l: Body length count. Describes the number of octets in the body that are part of the signature hash
h: Signed Header Fields. Specifies the header fields for which the signature is formed. These must contain at least the "from" field. Other headers are optional
z: Copied header fields. Copies of the signed headers
bh: The hash of the message body, corresponding to the length specified by "l"
b: The hash formed from the header fields.
Example of a DKIM entry:
Hostname | Type | Time to live | Value |
Mail._domainkey.example.com | TXT | 1 hour | v=DKIM1; p=76E629F05F70 |
Under the host name we find an entry that is divided into the selector "Mail", the fixed part "_domainkey" and the domain name "example.com". A receiving server can use this name to request the public key. The entry then represents the actual DKIM syntax. "v=DKIM1; p=76E629F05F709EF665853333EEC3F5ADE69A2362BECE40658267AB2FC3CB6CBE"
splits into the parameter v, which stands for the DKIM version used, and the parameter "p", which specifies the public key. Frequently, DKIM records also contain the parameter k, which specifies the signing method.
If you're concerned with IT security, you can't miss the OWASP Top 10. The non-profit organization Open Web Application Security
Burp Suite by Portswigger and OWASP ZAP are both programs with a proxy server that run on your local device. With
Our co-founder Immanuel was a guest at Radio Bonn/ Rhein-Sieg and told the presenter team Nico Jansen and Jasmin Lenz and