November 19, 2024
Critical vulnerability at Palo Alto Networks: Patches and CISA warnings The latest serious security vulnerability in Palo Alto Networks products has
Offense: What is email spoofing? "The sender is real..."
E-mail spoofing or spoofing refers to the actions of a hacker, for example, when he pretends to send an e-mail in the name of a company or domain to which he does 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 upon closer inspection. So how can that be?
Since e-mail is a form of communication that enables decentralized sending and receiving of messages via protocols such as SMTP, there is no central body that can check sent messages for validity. This means that sender addresses can easily be forged. Think of it like entering the wrong sender address on a letter. It is not possible for the recipient to evaluate whether a letter was actually sent by the specified sender without further measures and checks. It's basically the same with email.
Basically, you do not need an email server to send emails. We use the tool here, for example swaks
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's e-mail address |
| --from | Email address of the sender |
| -h-From | Sender's display name or spoofed email address |
| -server | The mail server of the receiving domain |
| -headers | The header part of the e-mail can be adjusted here, primarily the "Subject" or subject field |
| -body | The content of the e-mail can be defined here |
| -ehlo | Name with which the sender registers with the receiving mail server |
The recipient of the e-mail will then see it as follows:
Technically, the sending of the e-mail looks like this in the background:
So easy?
No, it's not that simple. Certain prerequisites or misconfigurations must be met so that the hacker's mail does not end up in the spam folder or does not arrive at all.
There are two DNS records for this 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 mail servers can use to check whether a received email actually comes from an authorized server. This is a fully automatic mechanism that runs 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 stored on the DNS server of the sending domain. The first part is the hostname. This is the domain or subdomain to which the record applies. Type describes the type of entry. SPF records are entered as TXT type. Time to Live instructs the DNS server to cache the DNS record for a specified amount of time.
The value is the actual SPF syntax. The "v" parameter describes the SPF version used, in this case version 1. Then, in the example, two IPv4 addresses are given as mail server addresses. Other entries could also be made here, such as A or AAAA (“a”) mail server records (“mx”). In addition, not only individual IP addresses but also IP ranges can be specified with IP4 or IP6.
The end of the SPF syntax is a directive that gives the checking mail server recommendations on how to handle emails that fail an SPF check. In the case of the example, it is recommended that the mail server should treat all checked emails that do not meet the criteria of the SPF record as "Fail" ("-") and not deliver them at all. There is also the option of defining a "soft fail" ("~"), "neutral" ("?") or "pass" ("+").
DKIM (DomainKeys Identified Mail) is a method of email authentication. E-mails sent are signed by DKIM. 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 email is sent, DKIM adds a so-called DKIM signature to the email header. In this case, the "headers" of the sent e-mail are signed using the private key. At least the "from" header must be used as a signature, additional headers can be optionally added.
When the email is received, the receiving server asks for the public key. The signature can only be validated if the sender is in possession of the private key. The recipient can then check whether the signature matches the checksum. If there is a match, then it is proven that the sender has 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 entries. This is required if several SPF records are published for a domain
c: Canonicalization. Indicates how strict the signature verification 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 it is sent. The "simple" option states that almost no changes may be accepted. Even small changes lead to the failure of the signature verification. The "relaxed" option allows moderate changes. This can be, for example, a conversion to lower case and the removal of unnecessary spaces.
q: Query methods. Defines the procedure used to request the public key. Default is "dns/txt"
i: identity of the sender
t: Timestamp of the signature
x: Signature expiration time
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"
is divided into the parameter v, which stands for the DKIM version used, and the parameter "p", which specifies the public key. The k parameter, which specifies the signing procedure, is often found in DKIM records.
Critical vulnerability at Palo Alto Networks: Patches and CISA warnings The latest serious security vulnerability in Palo Alto Networks products has
Chinese hackers use T-Mobile and other US telecommunications systems for larger espionage campaign The giant US telecommunications company T-Mobile has confirmed that it is one of the
The challenge of permissions and non-human identities – Why managing credentials takes longer than you think With the
