1
00:00:00,000 --> 00:00:22,180
36C3 preroll music
2
00:00:22,180 --> 00:00:28,540
Herald: So, have you ever wondered how to
almost perfectly fake an email? Then you
3
00:00:28,540 --> 00:00:33,369
might be actually in the right talk here.
We have our next speaker. Andrew, who is
4
00:00:33,369 --> 00:00:41,180
currently working for the National CERT of
Latvia as a security researcher. And he's
5
00:00:41,180 --> 00:00:50,120
going to talk about e-mail counterfeiting
and strategies for modern anti-spoofing.
6
00:00:50,120 --> 00:00:53,356
Stage is yours.
7
00:00:53,356 --> 00:01:04,460
Applause
8
00:01:04,460 --> 00:01:14,490
Andrew: So. Greetings. I'm Andrew and I
work for Latvian National CERT. One of our
9
00:01:14,490 --> 00:01:21,440
current goals is improving the state of
email security in our country and which we
10
00:01:21,440 --> 00:01:26,400
mostly do through raising awareness about
this issue and communicating best
11
00:01:26,400 --> 00:01:30,770
practices. And of course we are not the
only organization that is doing that.
12
00:01:30,770 --> 00:01:34,420
There are many more CERTs in other
countries and there are various
13
00:01:34,420 --> 00:01:39,299
nongovernmental organizations that are
doing the same. And commercial entities.
14
00:01:39,299 --> 00:01:46,060
However, so far, frankly speaking, our
collective progress has been quite
15
00:01:46,060 --> 00:01:54,100
underwhelming. So for example, here is the
one stat which is the usage of one
16
00:01:54,100 --> 00:01:59,770
specific technology, DMARC, which as you
will learn in this talk, is quite
17
00:01:59,770 --> 00:02:06,770
important and I hope that everyone will
start using it. So on the left. There are
18
00:02:06,770 --> 00:02:11,060
twenty thousand domains across all the
world which are important domains for
19
00:02:11,060 --> 00:02:15,880
important organizations that truly should
know better. And on the right side we see
20
00:02:15,880 --> 00:02:24,799
the top 50, top 500 EU retailer domains
and across both of these groups two thirds
21
00:02:24,799 --> 00:02:29,799
haven't even configured DMARC yet. And out
of those that have configured majority
22
00:02:29,799 --> 00:02:36,350
hasn't enabled strict policy yet. So if
there is just one key takeaway from this
23
00:02:36,350 --> 00:02:41,459
talk, I hope that it will be that everyone
should start using DMARC. It is important
24
00:02:41,459 --> 00:02:49,120
to use it even for domains that are not
supposed to send email. So, one
25
00:02:49,120 --> 00:02:56,760
explanation for these low adoption rates,
I think, is that, there are seemingly too
26
00:02:56,760 --> 00:03:04,310
many competing technologies. This is the
contents for my talk. And I really tried
27
00:03:04,310 --> 00:03:12,449
to do my best to trim it down. But as you
can see, there are three abbreviations, well and
28
00:03:12,449 --> 00:03:18,739
SMTP and out of this, SPF, DKIM and DMARC
actually two are i don't even remember the
29
00:03:18,739 --> 00:03:25,570
whole name for them. But still, they are
all important. And of course, this problem
30
00:03:25,570 --> 00:03:28,949
that there are too many buzzwords, too
many technologies, and it's not clear
31
00:03:28,949 --> 00:03:34,590
which one which ones we should use, it's
not specific to email. And we have this
32
00:03:34,590 --> 00:03:39,760
across the industry and, ah, security
industry, i think by now we have found at
33
00:03:39,760 --> 00:03:47,880
least one way to solve it. And it is
penetration testing. So when the
34
00:03:47,880 --> 00:03:53,370
penetration test has been run properly and
the results have been published, then we
35
00:03:53,370 --> 00:03:58,190
can start talking. We can shift the
conversation from talking about whether
36
00:03:58,190 --> 00:04:03,510
your organization prefers technology A or
technology B we can instead start talking
37
00:04:03,510 --> 00:04:09,620
about the questions that really matter,
such like: Is it possible for someone for
38
00:04:09,620 --> 00:04:15,310
some third party to spoof your
organization's e-mails and to send such
39
00:04:15,310 --> 00:04:20,989
e-mails to your, for example, customers or
your partners or to media organizations in
40
00:04:20,989 --> 00:04:24,970
such a way that they will think that the
emails really came from within your
41
00:04:24,970 --> 00:04:31,810
organization? So that's why penetration
testers are the key audience for this
42
00:04:31,810 --> 00:04:36,020
talk. However, I hope that any blue
teamers in the audience also will find
43
00:04:36,020 --> 00:04:40,650
this talking interesting. I'm sure that
you already know all the basics about the
44
00:04:40,650 --> 00:04:43,620
email and about these technologies, but
looking at the problem from the different
45
00:04:43,620 --> 00:04:50,440
side from attacker's perspective sometimes
can really put things into perspective. It
46
00:04:50,440 --> 00:04:54,819
can help for you understand what you
should focus on when protecting your
47
00:04:54,819 --> 00:05:01,009
environment. And finally, the SMTP
protocol. The technology that runs
48
00:05:01,009 --> 00:05:07,720
underneath our e-mail conversations is
actually relatively easy to understand.
49
00:05:07,720 --> 00:05:14,061
And so. And also the lessons learned from
all of this journey from SMTP, how it
50
00:05:14,061 --> 00:05:20,979
became and how it's possible to spoof it
and all the technologies that are trying
51
00:05:20,979 --> 00:05:27,530
to prevent spoofing. I think it's a
interesting case study and it should be
52
00:05:27,530 --> 00:05:33,719
interesting to follow even for people who
are new to e-mail. Um, finally. Threat
53
00:05:33,719 --> 00:05:41,400
landscape. So email security is quite a
wide topic. And so today I will only focus
54
00:05:41,400 --> 00:05:47,650
on one small part of it, which is
successful spoofing of e-mails. Tampering
55
00:05:47,650 --> 00:05:54,689
attacks. And I know that many, penetration
testers already, incorporate some part of
56
00:05:54,689 --> 00:06:01,250
phishing or spear phishing, emulation
into their engagements and. But as far as
57
00:06:01,250 --> 00:06:07,070
I know, they mostly do it from the, social
engineering perspective using such tools
58
00:06:07,070 --> 00:06:13,090
as a social engineering toolkit, for
example. And it's, uh, I don't want to
59
00:06:13,090 --> 00:06:16,949
argue, though, that it's important to do
that and to demonstrate to the customer
60
00:06:16,949 --> 00:06:23,860
that what risks are in regards with social
engineering. However, I think you're doing
61
00:06:23,860 --> 00:06:28,099
a disservice to the customer if that's the
only thing that you are testing from the
62
00:06:28,099 --> 00:06:32,650
email perspective, because from the
customers, from managers perspective that
63
00:06:32,650 --> 00:06:38,870
are reading your reports, if they only
mention social engineering attacks, then
64
00:06:38,870 --> 00:06:44,650
the logical conclusion is, that the best
way to mitigate these threats is by
65
00:06:44,650 --> 00:06:51,590
educating your personnel, especially those
that are least technical, as you will see
66
00:06:51,590 --> 00:06:55,379
in this talk. There are quite a lot of
attacks and many organizations are
67
00:06:55,379 --> 00:07:00,230
susceptible to them, which are much better
than that. And no amount of user education
68
00:07:00,230 --> 00:07:03,889
will help here because we can't expect
users to check headers, for example,
69
00:07:03,889 --> 00:07:10,699
manually. So we actually need to improve
our e-mail infrastructure. No way around
70
00:07:10,699 --> 00:07:17,009
it. And finally, before we move on to
actual technical stuff, there's a little
71
00:07:17,009 --> 00:07:21,889
secret, which I think might help people
that are not working in the email industry
72
00:07:21,889 --> 00:07:28,159
understand why we have such problems and
is that, for email admins historically,
73
00:07:28,159 --> 00:07:38,040
um, they value availability of their
system and reliable reliability much more
74
00:07:38,040 --> 00:07:44,680
than security. And that's because that's
not an ideological decision. It's a very
75
00:07:44,680 --> 00:07:50,469
pragmatic one. So, for example, if you are
an e-mail an email admin in an
76
00:07:50,469 --> 00:07:56,090
organization and some of your customers
stop receiving invoices, your management
77
00:07:56,090 --> 00:08:01,470
will find you and will inform you about it
and will ask you a really nicely to fix it
78
00:08:01,470 --> 00:08:06,210
as soon as possible, even if it's not your
fault, if it might happen that the problem
79
00:08:06,210 --> 00:08:13,509
is on the other side of the email. Not on
your server. And the for example, if,
80
00:08:13,509 --> 00:08:20,449
other example, if you, if some of your,
some of your employees can't receive
81
00:08:20,449 --> 00:08:24,969
e-mail soon enough, for example, to
restore the password or to verify the
82
00:08:24,969 --> 00:08:30,190
email or to use multi factor
authentication token and they can't log
83
00:08:30,190 --> 00:08:33,969
into some important systems again, they
will find you on though you will need to
84
00:08:33,969 --> 00:08:39,539
solve that. But if your system is has some
security vulnerabilities, if it's assessed
85
00:08:39,539 --> 00:08:45,540
susceptible to spoofing attacks and so on,
then not users, no management will
86
00:08:45,540 --> 00:08:50,670
normally notice it. You might not not
notice it, but you are. You have this
87
00:08:50,670 --> 00:08:55,930
vulnerability. So that's why obviously
penetration testers are important. Okay.
88
00:08:55,930 --> 00:09:01,250
Now we can finally start talking about the
technical stuff. So and we will start with
89
00:09:01,250 --> 00:09:07,190
the short introduction to SMTP protocol.
SMTP is the protocol that underlies all
90
00:09:07,190 --> 00:09:12,360
email communications and it's actually
pretty easy to follow. So here's a data
91
00:09:12,360 --> 00:09:18,370
flow of what's happening when one person
sends e-mail to another person. For
92
00:09:18,370 --> 00:09:21,269
example Alice is sending to Bob and
they're using different they are working
93
00:09:21,269 --> 00:09:24,970
for different companies. They use
different domains. So what's happening
94
00:09:24,970 --> 00:09:29,290
here is that both of them would say use
email clients such as Outlook or
95
00:09:29,290 --> 00:09:34,580
Thunderbird. And Alice is sending email.
It's going through this protocol SMTP to
96
00:09:34,580 --> 00:09:41,740
Alice's mail server. But important to note
is that this is an outgoing e-mail server.
97
00:09:41,740 --> 00:09:44,790
Usually organizations will have two types
of servers, one for incoming transactions
98
00:09:44,790 --> 00:09:48,680
and one for outgoing and for smaller
organizations it might be one server, but
99
00:09:48,680 --> 00:09:52,470
again, it's important for penetration
tester to think of this as different
100
00:09:52,470 --> 00:09:56,680
systems because they will have even if
it's physically one machine, it will have
101
00:09:56,680 --> 00:10:00,620
different configuration for outgoing mail
and for incoming mail. So as a penetration
102
00:10:00,620 --> 00:10:04,899
tester you need to check both of them.
Okay. Now, when Alice's server tries to
103
00:10:04,899 --> 00:10:11,940
send email to Bob's server, there is sort
of a problem in that the server needs to
104
00:10:11,940 --> 00:10:16,480
somehow automatically find what is the
other server to send the email and it is
105
00:10:16,480 --> 00:10:25,220
done through this blue box MX which is DNS
specific DNS record type MX. So that's
106
00:10:25,220 --> 00:10:29,680
something that is maintained by Bob's
organization. So Bob's organization, if
107
00:10:29,680 --> 00:10:35,360
they want to receive e-mail, they create
this DNS record. And I say that. Okay. If
108
00:10:35,360 --> 00:10:38,830
you want to send e-mail to us, please use
this particular server. So it should point
109
00:10:38,830 --> 00:10:44,290
to Bob's server. And Alice's outgoing
server knowing Bob's incoming server
110
00:10:44,290 --> 00:10:50,670
address can communicate to that. And then
later, Bob, will receive its e-mail. So
111
00:10:50,670 --> 00:10:54,970
the part that we as penetration testers
will be trying to breach is actually
112
00:10:54,970 --> 00:10:59,839
between Alice's server and between Bob
Server. And then we need to think about
113
00:10:59,839 --> 00:11:03,511
the second example, which is the opposite
way. And you might think that it's a
114
00:11:03,511 --> 00:11:07,110
pointless example because we are just
basically changing the direction of
115
00:11:07,110 --> 00:11:11,449
traffic. But the important part here is
for us as penetration testers to
116
00:11:11,449 --> 00:11:17,220
understand that our client only controls
part of this transaction. If our client,
117
00:11:17,220 --> 00:11:20,760
let's say, for the rest of this
presentation is Alice or Alice's
118
00:11:20,760 --> 00:11:26,750
organization, then in the second example
when we are sending mail from Bob to
119
00:11:26,750 --> 00:11:34,600
Alice, then we'll be sending emails only.
Basically, part of this transaction will
120
00:11:34,600 --> 00:11:40,980
go through Alice's servers. In the first
example, if we were sending email from
121
00:11:40,980 --> 00:11:45,940
Alice to Bob, it wouldn't be so. So if
it's a bit confusing, that's okay. We will
122
00:11:45,940 --> 00:11:51,600
return to that a bit later. And finally,
there is a third example which looks
123
00:11:51,600 --> 00:11:56,260
similar, but not quite. And that's if
Alice is communicating. Alice is our
124
00:11:56,260 --> 00:12:01,070
customer. And if she is communicating with
her coworkers, which are using the same
125
00:12:01,070 --> 00:12:04,320
organization, same e-mail server, same
domain. In that example, again, there will
126
00:12:04,320 --> 00:12:09,000
be to at least logically two email
servers, outgoing server and incoming
127
00:12:09,000 --> 00:12:15,850
server. But both of them will belong to
our customer. So right now, if you are not
128
00:12:15,850 --> 00:12:20,149
familiar with e-mail, you can. It's
just interesting to try to think which of
129
00:12:20,149 --> 00:12:27,740
these scenarios, three scenarios, which of
them are easier to protect? And a bit
130
00:12:27,740 --> 00:12:31,769
later we will see how it's actually
happening. Okay. And then we need to look
131
00:12:31,769 --> 00:12:38,410
at what actually is being sent, when email
is being sent. So again, it's using SMTP
132
00:12:38,410 --> 00:12:44,790
protocol and it's really nice protocol you
can. As you can see, it's just text. So
133
00:12:44,790 --> 00:12:48,029
it's plain text protocol and it's very
easy to play around because you can just
134
00:12:48,029 --> 00:12:54,410
open telnet connection to the right server
and you can try writing down the commands
135
00:12:54,410 --> 00:12:58,680
just with your hands. So you can try
mangling something or modifying or trying
136
00:12:58,680 --> 00:13:05,149
different, different, different types and
see in real time how it was going on. So
137
00:13:05,149 --> 00:13:11,209
on the left side we see here two parts
which are defined by SMTP. So first of
138
00:13:11,209 --> 00:13:14,720
all, there comes SMTP envelope, which
basically you connect the server, say
139
00:13:14,720 --> 00:13:22,070
hello, then you say what. Specify the
sender of email and recipient. "mail from"
140
00:13:22,070 --> 00:13:26,980
is sender. Recipient is Bob, for example.
And then the second part starts with data
141
00:13:26,980 --> 00:13:32,160
and ends with quit. And that's the part
which is called Content/Message. So just
142
00:13:32,160 --> 00:13:35,480
if you want to play around with it, a bit
more, this is defined by a different
143
00:13:35,480 --> 00:13:38,029
standard, which is not that important for
penetration testers but if you want to
144
00:13:38,029 --> 00:13:43,890
look into details and it might be
important. And this internal message,
145
00:13:43,890 --> 00:13:49,069
which is called either Content or SMTP
message, it again, it contains two parts.
146
00:13:49,069 --> 00:13:53,300
One is headers and another is body. And I
think some people might not be familiar
147
00:13:53,300 --> 00:13:57,569
with email, but probably everyone is
familiar in this audience with HTTP and
148
00:13:57,569 --> 00:14:02,600
this looks quite, quite the same. So easy
to understand. But the interesting part
149
00:14:02,600 --> 00:14:08,550
here is that you might have noticed that
we have Alice's and Bob's addresses twice.
150
00:14:08,550 --> 00:14:14,350
Right. For example, Alice's is specified
on the second line "mail from". And then
151
00:14:14,350 --> 00:14:19,709
we have the same address. alice @ her
organization in "From" header. The red
152
00:14:19,709 --> 00:14:26,810
ones are the headers. And the same goes
for Bob. So why is that? Well, it comes
153
00:14:26,810 --> 00:14:33,471
down to how we see e-mail. I as a normal
regular person who has used email in
154
00:14:33,471 --> 00:14:39,139
past quite a lot, i usually see them as
described on the left side, which is a
155
00:14:39,139 --> 00:14:44,980
sort of postcard. So on a postcard there
is someone who has sent it. The sender.
156
00:14:44,980 --> 00:14:48,980
There is the recipient. That's usually me.
I'm receiving. And then there's some
157
00:14:48,980 --> 00:14:53,569
message. So at least that's how I
perceived it before I learned a bit more
158
00:14:53,569 --> 00:14:58,670
about it. But email admins and the
standard bodies, they see this situation
159
00:14:58,670 --> 00:15:04,610
as the one which is shown on the right,
which is. There is an envelope and inside
160
00:15:04,610 --> 00:15:10,480
the envelope then there is this message or
a postcard maybe. So you have two
161
00:15:10,480 --> 00:15:15,350
addresses in this scenario. You specified
the address from and to whom you are
162
00:15:15,350 --> 00:15:20,730
sending the envelope, which is the part
that post office, for example, will look.
163
00:15:20,730 --> 00:15:24,589
But post office won't look generally
inside your envelope and inside the
164
00:15:24,589 --> 00:15:28,880
envelope there is another message, and
that is the internal message is actually
165
00:15:28,880 --> 00:15:33,889
meant for a recipient. So actually, you
could do even more and you could even put
166
00:15:33,889 --> 00:15:40,060
the whole envelope with the message of the
postcard inside another envelope. And this
167
00:15:40,060 --> 00:15:46,500
sounds crazy to me as a regular person,
but actually e-mail allows that. And in
168
00:15:46,500 --> 00:15:50,029
the RFC the standard document, there are
some examples why that would be necessary.
169
00:15:50,029 --> 00:15:56,939
Why why such why such things are allowed.
But but they are confusing. And so as a
170
00:15:56,939 --> 00:16:03,009
result, it is the here in this first
example, we see that we generally we are
171
00:16:03,009 --> 00:16:07,940
specifying the same address twice. But as
a penetration tester the question that
172
00:16:07,940 --> 00:16:12,170
we should be asking is: So is that
required, actually? Is that always true or
173
00:16:12,170 --> 00:16:17,120
is it just like a wishful thinking? And
it's actually wishful thinking. So
174
00:16:17,120 --> 00:16:20,870
standards specifically do not say that you
should be specifying the same address for
175
00:16:20,870 --> 00:16:27,140
recipient or for "From" from the sender on
the envelope and inside a message. So you
176
00:16:27,140 --> 00:16:32,300
could actually tweak them and send
different, different stuff. So, actually,
177
00:16:32,300 --> 00:16:38,519
there are much more headers than what I
showed. The ones I showed I think are just
178
00:16:38,519 --> 00:16:42,850
the ones that we all have experience
because even if you are just using e-mail,
179
00:16:42,850 --> 00:16:45,920
that's usually the stuff that you see or
see the date, you see the subject, you see
180
00:16:45,920 --> 00:16:52,680
who has who sent you something and to whom
it was sent. Usually yourself. And there
181
00:16:52,680 --> 00:16:57,800
might be, of course, more recipients. Oh,
yeah. And the question then another
182
00:16:57,800 --> 00:17:03,769
question is: Which one is actually, if we
have specified for some reason by accident
183
00:17:03,769 --> 00:17:07,300
or especially if we have specified
different addresses in this envelope in
184
00:17:07,300 --> 00:17:11,890
the message which one the user will see
the recipient, it's actually the header.
185
00:17:11,890 --> 00:17:18,010
So inside that the message is the one
which is intended for the user. OK. So and
186
00:17:18,010 --> 00:17:22,510
as I was saying, there are actually
standards allow a bit more headers. And
187
00:17:22,510 --> 00:17:25,880
actually 3 headers "From", "Sender",
"Reply to" which are semantically really
188
00:17:25,880 --> 00:17:31,080
close and in the standard it's actually
explains when you should be using which
189
00:17:31,080 --> 00:17:34,040
one. And the funny thing for me is that,
for example "From" header, which is
190
00:17:34,040 --> 00:17:39,310
usually the one with that we see it might
contain . By reading the RFC you will see
191
00:17:39,310 --> 00:17:44,450
that you shouldn't have more than one such
header, but the header itself might
192
00:17:44,450 --> 00:17:48,020
contain multiple addresses. Personally,
I've never received an email which would
193
00:17:48,020 --> 00:17:53,110
come from different people, but that's
allowed. But the important thing to
194
00:17:53,110 --> 00:17:57,530
understand here again is the backwards
compatibility that I mentioned before. So
195
00:17:57,530 --> 00:18:02,480
even though standards explain how you
should use the each header and that you
196
00:18:02,480 --> 00:18:07,130
shouldn't have more than one of each of
these headers in practice actually can
197
00:18:07,130 --> 00:18:12,480
send malformed email. You could send email
with multiple headers, the same header
198
00:18:12,480 --> 00:18:17,040
"From" header multiple times, or you could
send header which does not contain "From"
199
00:18:17,040 --> 00:18:21,240
but contain "Sender" according to RFC
that's incorrect. But in practice it will
200
00:18:21,240 --> 00:18:27,550
work. Most organizations, most e-mail
service will try their best to pass your
201
00:18:27,550 --> 00:18:33,720
completely malformed email because they
really are concerned about lowering the
202
00:18:33,720 --> 00:18:37,580
support costs. So if something does not
work, then you will come to them. So it is
203
00:18:37,580 --> 00:18:42,160
better to make that everything is working
most of the time. Of course, for
204
00:18:42,160 --> 00:18:45,670
penetration testers that means that you
can play around with this because there
205
00:18:45,670 --> 00:18:49,480
are different implementations and it's
exactly which header, for example, if you
206
00:18:49,480 --> 00:18:53,830
have two headers, will be shown or will be
used for some algorithm. It depends on the
207
00:18:53,830 --> 00:18:59,150
particular implementation. So because
there are so many implementations, they
208
00:18:59,150 --> 00:19:03,720
are interconnected in different ways. You
could and you should as a penetration
209
00:19:03,720 --> 00:19:09,270
tester try various things, for example,
add the same header multiple times. OK.
210
00:19:09,270 --> 00:19:13,990
Now that we have covered these basics,
let's actually look into how you would try
211
00:19:13,990 --> 00:19:18,360
to spoof an e-mail, for example. Yeah. And
here we are again, we are coming back to
212
00:19:18,360 --> 00:19:23,930
this diagram that we have seen before. And
for example, in the first example about
213
00:19:23,930 --> 00:19:29,960
Alice is sending email to Bob. Let's say
we are, Chuck. So we are a third party. We
214
00:19:29,960 --> 00:19:33,700
are penetration tester licensed, we have
an arrangement that we are allowed to do
215
00:19:33,700 --> 00:19:38,920
this and we are trying to send spoofed
e-mail to Bob. And in this example, we are
216
00:19:38,920 --> 00:19:44,440
trying to spoof Alice's message. So our
intention is that Bob wants Bob receives
217
00:19:44,440 --> 00:19:52,580
email. It should look to them, to the Bob,
that email was sent by Alice. So risk for
218
00:19:52,580 --> 00:19:57,580
this. Okay. I will not cover the risk. I
think you can imagine that. So, for
219
00:19:57,580 --> 00:20:01,430
example, you could do fake news is one of
the problems that we have seen in Latvia.
220
00:20:01,430 --> 00:20:06,330
It's one this was used against government
bodies. And when someone sent a fake news
221
00:20:06,330 --> 00:20:13,660
e-mail to other people, organizations and
so on, and were trying to impersonate some
222
00:20:13,660 --> 00:20:19,510
some government person. And of course, you
could could imagine yourself how it's not
223
00:20:19,510 --> 00:20:23,710
a good thing if you if it's possible. But
the interesting thing here is that even
224
00:20:23,710 --> 00:20:28,450
though Chuck is doing attack, it depends
on your perspective. It might look like
225
00:20:28,450 --> 00:20:32,480
attack on Alice or on Bob. But in this
case, email won't go through Alice's
226
00:20:32,480 --> 00:20:37,590
systems. As you can see, Chuck is sending
e-mail directly to Bob's incoming
227
00:20:37,590 --> 00:20:44,490
server. Now, there is a second type of
attack that will be looked at. If we are
228
00:20:44,490 --> 00:20:48,540
sending e-mail in other direction from Bob
to Alice. And our customer is Alice. So we
229
00:20:48,540 --> 00:20:52,900
are testing Alice's server. And in this
case, we are trying, again we are Chuck.
230
00:20:52,900 --> 00:20:58,570
We are sending e-mail. In this case,
e-mail will go through Alice's systems. So
231
00:20:58,570 --> 00:21:03,790
interesting question is, which is easier
to protect. It might seem that since in
232
00:21:03,790 --> 00:21:07,270
the second example, e-mail is actually
going through Alice's systems, that means
233
00:21:07,270 --> 00:21:11,880
that Alice has more power to do something,
to do some additional checks and balances
234
00:21:11,880 --> 00:21:16,190
and so on. But actually, as you will see
in the future, it's easier to protect the
235
00:21:16,190 --> 00:21:21,710
first example. So even though our customer
is Alice, we're trying to protect Alice,
236
00:21:21,710 --> 00:21:26,540
but it's easier to protect in practice
this example where someone is selling,
237
00:21:26,540 --> 00:21:32,800
sending e-mail, trying to impersonate
Alice. Okay. Oh, yeah. That there is the
238
00:21:32,800 --> 00:21:37,690
third example, which is if Alice is
communicating with her colleagues inside
239
00:21:37,690 --> 00:21:41,821
the same organization. Again, we are Chuck
in this case. Again, we will only send the
240
00:21:41,821 --> 00:21:47,590
e-mail to Alice's incoming server. Not to
outgoing server. Right. So important thing
241
00:21:47,590 --> 00:21:54,460
to note. And again, in principle, this
third example is the easiest to notice,
242
00:21:54,460 --> 00:21:59,790
because Alice's organization presumably
knows that her e-mails always should come
243
00:21:59,790 --> 00:22:03,790
from this particular outgoing server.
Right. Like if we are sending e-mail from
244
00:22:03,790 --> 00:22:08,780
Alice's colleague, then incoming server in
principle should have all the power, even
245
00:22:08,780 --> 00:22:15,610
without any standards and stuff like that.
But in practice, sometimes actually quite
246
00:22:15,610 --> 00:22:24,140
often there will be a specific whitelist
for Alice's own organization. So some
247
00:22:24,140 --> 00:22:28,880
checks won't happen if incoming server for
Alice is receiving email, which is coming
248
00:22:28,880 --> 00:22:34,610
from, again, Alice. And by the way,
there's this example. We've seen that for
249
00:22:34,610 --> 00:22:38,730
the past few years. I think it's not
specific to Latvia. So here, for example,
250
00:22:38,730 --> 00:22:43,590
is Canada and others,if you can see. This
are these emails which are fake like
251
00:22:43,590 --> 00:22:48,290
ransomware stuff. Basically, they are
telling you that they have hacked your
252
00:22:48,290 --> 00:22:53,820
computer or your email. In this case, and
they have arranged all sorts of financial
253
00:22:53,820 --> 00:22:59,160
activity or have some blackmailing you.
And please send them the money. Your
254
00:22:59,160 --> 00:23:04,520
money. I mean, your money in bitcoins to
their address. So, these e-mails.
255
00:23:04,520 --> 00:23:08,920
Interesting part about these e-mails is,
that they are usually in order to prove to
256
00:23:08,920 --> 00:23:13,210
you that they have access to your e-mail
account. They are sending e-mail from your
257
00:23:13,210 --> 00:23:20,100
address to your address. So and for many
people, that works. So they see that
258
00:23:20,100 --> 00:23:22,730
someone has hacked their account,
obviously, because they've received e-mail
259
00:23:22,730 --> 00:23:28,620
from themselves. So as you will see a bit
later, it's actually easy to spoof such
260
00:23:28,620 --> 00:23:34,100
e-mails if there haven't been any
protections, haven't been put in place. So
261
00:23:34,100 --> 00:23:38,120
the important thing, I hope that now no
one in this audience is falling for such
262
00:23:38,120 --> 00:23:43,910
scam. But if you have some friends or
colleagues that have contacted you and
263
00:23:43,910 --> 00:23:48,230
told you about such e-mails that they have
received. But one of the things besides
264
00:23:48,230 --> 00:23:53,110
checking the passwords is starting using
more effective authentification on is a
265
00:23:53,110 --> 00:23:57,770
just maybe you could tell them that they
should contact their email administrators
266
00:23:57,770 --> 00:24:03,470
or IT team and ask them about anti
spoofing protection, because obviously if
267
00:24:03,470 --> 00:24:09,020
they are able to receive such e-mail and
it's not filtered, something is wrong.
268
00:24:09,020 --> 00:24:16,990
Okay, and now let's see a spoofed SMTP
conversation, so that's example similar to
269
00:24:16,990 --> 00:24:22,090
previous one. But in this now we are
actually Chuck. So this is sent by Chuck
270
00:24:22,090 --> 00:24:25,920
to Bob, but we are pretending to be Alice.
The question is, can you see the
271
00:24:25,920 --> 00:24:30,110
difference how this is different from from
the previous one? And it's hard to see the
272
00:24:30,110 --> 00:24:33,230
difference because there is none
difference. That is the same conversation.
273
00:24:33,230 --> 00:24:39,540
So the point here is that SMTP protocol by
itself it actually it doesn't have any
274
00:24:39,540 --> 00:24:43,640
protection. So, yeah, you could just for
example, if you are that guy that is
275
00:24:43,640 --> 00:24:49,580
sending the fake ransom letters, you can
just write down this text and just dump it
276
00:24:49,580 --> 00:24:55,830
to telnet and it will work for many
organizations. Not for all. And of course,
277
00:24:55,830 --> 00:25:01,210
the email admins know this stuff, know
that SMTP is not very reliable in this
278
00:25:01,210 --> 00:25:05,070
regard. That's easy to spoof and so on.
And there have been many attempts to add
279
00:25:05,070 --> 00:25:11,520
some protection, just like ad hoc way. So
no standards just to ransom, add some
280
00:25:11,520 --> 00:25:15,950
additional filters and stuff into your own
mail. And some of these protections
281
00:25:15,950 --> 00:25:20,640
actually break RFC. If you read it, but
who cares? Like RFC is not a sacred text
282
00:25:20,640 --> 00:25:26,260
or it's. I absolutely approve this, for
example. So yeah, go on. But the problem
283
00:25:26,260 --> 00:25:31,640
is that there is not enough information.
So if you think back here, if we are Bob
284
00:25:31,640 --> 00:25:35,100
and we are trying to protect our systems.
So we are Bob, some system administrator
285
00:25:35,100 --> 00:25:39,730
probably or Bob is a sys admin and we are
trying to add some additional rules and
286
00:25:39,730 --> 00:25:44,590
stuff, then what actually can we do? So
one example that I listed here is doing
287
00:25:44,590 --> 00:25:49,980
this SMTP callback, and that means that we
are just the when we receive e-mail from
288
00:25:49,980 --> 00:25:56,970
Alice, we actually check does that email
exist at all? Because many spammers, what
289
00:25:56,970 --> 00:26:02,000
they will do, they will just send e-mail
from non existing emails and it will work
290
00:26:02,000 --> 00:26:08,640
by if you are just running raw SMTP
server. So SMTP callback is basically you
291
00:26:08,640 --> 00:26:13,300
are when you are receiving email from, for
example. Alice, you are trying. You are
292
00:26:13,300 --> 00:26:17,220
running, spawning a separate process which
will try to connect back to Alice, etc.
293
00:26:17,220 --> 00:26:24,500
And it will try to send email her. If a
server says that. Yeah, that's okay. Such
294
00:26:24,500 --> 00:26:27,540
email exists and so on. You are not like,
you actually stop the conversation. You
295
00:26:27,540 --> 00:26:31,290
don't continue with sending email, but
then your system can automatically find
296
00:26:31,290 --> 00:26:36,570
that actually this e-mail really exists.
So another way to do this is through
297
00:26:36,570 --> 00:26:42,030
checking this "Hello". And this is the
first line and the first line, it's,
298
00:26:42,030 --> 00:26:48,000
normally it should tell you the hostname
of the server that is sending email.
299
00:26:48,000 --> 00:26:52,580
Interesting part. So according to RFC
again, you shouldn't check it that you
300
00:26:52,580 --> 00:26:56,540
shouldn't verify. And if it doesn't, if
it's a random thing, you should accept
301
00:26:56,540 --> 00:27:04,520
email still. But what many servers will do
is they will try to verify that. First of
302
00:27:04,520 --> 00:27:07,800
all, this hostname, which you are telling
that you have this hostname. First of all,
303
00:27:07,800 --> 00:27:12,800
that it really points to the same IP
address and then they do the opposite. So
304
00:27:12,800 --> 00:27:18,880
they will take IP address and try to run a
reverse DNS PTR query and they will try to
305
00:27:18,880 --> 00:27:23,150
find whether that IP address really
responds to this hostname. So again, as a
306
00:27:23,150 --> 00:27:26,520
penetration testers we should be aware of
these protections, ad hoc protections,
307
00:27:26,520 --> 00:27:31,040
because they are if you don't know about
them, you will try running something and
308
00:27:31,040 --> 00:27:34,700
it won't work for you. But they are easy
if you are aware of them and if you have
309
00:27:34,700 --> 00:27:40,470
to identify that this organization uses
them. They are easy to bypass so that they
310
00:27:40,470 --> 00:27:44,530
don't offer good protection. They are
meant to protect from mass abuse from
311
00:27:44,530 --> 00:27:52,910
spam. OK, so SMTP, as we've seen, by
itself does not do does not offer any
312
00:27:52,910 --> 00:27:59,380
protection. So which additions to the
protocol actually can we use to protect
313
00:27:59,380 --> 00:28:06,860
ourselves? One of such protocols is SPF.
And what SPF does is it's trying to be
314
00:28:06,860 --> 00:28:12,870
like mirror MX system. MX system is the
one which basically Alice can use to
315
00:28:12,870 --> 00:28:18,150
Alice's server can use to automatically
find the server that belongs to Bob and
316
00:28:18,150 --> 00:28:24,580
its incoming server. So. SPF is the
opposite of that. So that's an idea is
317
00:28:24,580 --> 00:28:30,270
here to run the system automatically on
the Bob's incoming server. And now when
318
00:28:30,270 --> 00:28:35,720
Bob receives the e-mail, they can run
again DNS query and they can find what IP
319
00:28:35,720 --> 00:28:41,820
addresses actually should belong to
Alice's outgoing server. Right. So it's I
320
00:28:41,820 --> 00:28:45,780
think it's easy to understand it's
actually a meaningful way. It sounds
321
00:28:45,780 --> 00:28:52,570
meaningful addition. And the one field
that is checked in this example is this
322
00:28:52,570 --> 00:28:59,360
envelope sender. OK. And here's an example
of minimal SPF syntax and the as we can
323
00:28:59,360 --> 00:29:04,610
see. I think it's easy to understand, even
if you don't know the syntax is it lists
324
00:29:04,610 --> 00:29:08,470
IP address, which is IP, should be IP
address of outgoing server, legitimate
325
00:29:08,470 --> 00:29:12,780
outgoing server. And then it says this
"-all" which again, is easy to understand.
326
00:29:12,780 --> 00:29:18,700
In this case, it means that that's the
only one. So if you receive a message,
327
00:29:18,700 --> 00:29:22,980
message comes from this IP address. That's
cool. I accept it. If it's something else,
328
00:29:22,980 --> 00:29:27,190
then just drop it. And there are multiple
ways to specify the IP address. You could
329
00:29:27,190 --> 00:29:31,610
just specify the IP address. You could
specify IP subnet, you could specify DNS
330
00:29:31,610 --> 00:29:37,070
hostname. So it's just for admin. So
basically for a penetration test, it
331
00:29:37,070 --> 00:29:44,750
doesn't do much different, for admins it's
just easier to maintain these systems. And
332
00:29:44,750 --> 00:29:49,620
then there are these qualifiers,
qualifiers. This is what's something which
333
00:29:49,620 --> 00:29:56,160
you put before the methods. For example,
here in this example, IPv4 before doesn't
334
00:29:56,160 --> 00:30:00,100
have any qualifier. There's no plus or
minus or something. That's because plus is
335
00:30:00,100 --> 00:30:03,910
assumed by default. So by default,
everything that is listed in SPF record
336
00:30:03,910 --> 00:30:12,600
will should the match some legitimate SMTP
server, outgoing server. However. There
337
00:30:12,600 --> 00:30:15,850
are other options you could use minus
which is fail. And that means if something
338
00:30:15,850 --> 00:30:20,380
matches this record, for example, minus
all is the one which is the most often
339
00:30:20,380 --> 00:30:26,710
used, it means if it matches this one, so
that's usually the last one, then please
340
00:30:26,710 --> 00:30:32,090
drop the mail. It's not real. It's it's
fake mail. And then there's this third
341
00:30:32,090 --> 00:30:37,150
option, which is softfail, and that's
meant for testing period. So when you are
342
00:30:37,150 --> 00:30:42,690
just starting to implement SPF, there
might be some. So the problem is that you
343
00:30:42,690 --> 00:30:47,730
might forget, for example, to add some
SMTP servers. So because you haven't done
344
00:30:47,730 --> 00:30:52,750
it before, maybe you think you have only
one SMTP actually outgoing server. But in
345
00:30:52,750 --> 00:30:56,360
fact, you have multiple of them or
multiple ways to send e-mail. So in that
346
00:30:56,360 --> 00:31:03,600
case, if you were to start set that SPF
record with "fail" strong policy, then
347
00:31:03,600 --> 00:31:07,230
your users won't be able to send the
message anymore. So that's why testing is
348
00:31:07,230 --> 00:31:13,460
good. However. Here are some other
examples, a bit more complicated. One of
349
00:31:13,460 --> 00:31:16,400
them is was include. So instead of
defining the policy yourself because
350
00:31:16,400 --> 00:31:19,270
you're using third party, for example,
Google in this example, and then you will
351
00:31:19,270 --> 00:31:24,720
just include whatever Google has
published. And the interesting thing is
352
00:31:24,720 --> 00:31:31,530
this usage of SPF. If we just if we just
look at the amount of domains that have
353
00:31:31,530 --> 00:31:36,890
defined some sort of policy, that the
number looks pretty okay. I guess that's
354
00:31:36,890 --> 00:31:42,290
for example for most popular domains
that's around 70 percent. But the problem
355
00:31:42,290 --> 00:31:45,710
is that the majority of them are either
poorly configured or they just use the
356
00:31:45,710 --> 00:31:51,790
softfail option. And what softfail
practically does is nothing. You still can
357
00:31:51,790 --> 00:31:56,700
even if there is policy with softfail, you
can in most cases you can spoof your email
358
00:31:56,700 --> 00:32:00,720
and it will still go because the recipient
side will think that it's just in the
359
00:32:00,720 --> 00:32:07,940
testing mode. You shouldn't drop e-mail
automatically. Yeah. So. Actually, the
360
00:32:07,940 --> 00:32:13,910
percentage isn't that great. However, the
most important thing for us as penetration
361
00:32:13,910 --> 00:32:18,420
testers is to understand. So what do we do
when we see this SPF. That means that now
362
00:32:18,420 --> 00:32:24,670
we can't spoof mail and. No, it does not.
That it's game over for us. We can do some
363
00:32:24,670 --> 00:32:30,060
stuff. So first of all, is this softfail
that I mentioned. And that's basically you
364
00:32:30,060 --> 00:32:33,830
have some rules, rules, rules, and then in
the end, you are putting typically just
365
00:32:33,830 --> 00:32:41,460
this softfail at all. So if we as a
penetration testers will try spoofing from
366
00:32:41,460 --> 00:32:46,330
some unknown IP address that hasn't been
listed in the previous rules. Then do
367
00:32:46,330 --> 00:32:51,520
nothing. Do nothing. I mean, don't drop
email. That is good for us, right? That
368
00:32:51,520 --> 00:32:56,720
means that we can actually spoof just in
the same old way and it will mostly go. So
369
00:32:56,720 --> 00:33:02,250
the one great one note here is that some
systems are you are not using just this
370
00:33:02,250 --> 00:33:06,590
binary classification, whether something
is good or bad, but they are trying to run
371
00:33:06,590 --> 00:33:11,320
some scoring. And then it might be that
even if you have this soft fail, they
372
00:33:11,320 --> 00:33:16,370
won't automatically drop your e-mail, but
maybe they will add some like suspicious
373
00:33:16,370 --> 00:33:22,540
level to it. But important thing is that
it's not automatically a game over.
374
00:33:22,540 --> 00:33:29,970
Another thing is this include. So include
is it very convenient when you are using
375
00:33:29,970 --> 00:33:36,330
third parties. But the problem is that
it's not what it sounds to some people, at
376
00:33:36,330 --> 00:33:43,100
least even in the standard, it mentions
that it was a poorly chosen name. And the
377
00:33:43,100 --> 00:33:48,110
reason for that is that it's not a macro.
So to understand what's happening when
378
00:33:48,110 --> 00:33:52,720
this included, you shouldn't just copy
paste everything from inside recursively
379
00:33:52,720 --> 00:33:58,340
to the top level. It's not how it works.
It will try running all the checks inside
380
00:33:58,340 --> 00:34:05,480
this include. But then if it fails, it
won't automatically drop the message. It
381
00:34:05,480 --> 00:34:10,250
will go to the one level top and it will
try running the other rules. So the
382
00:34:10,250 --> 00:34:14,510
problem with that is that two cases that
are the most common is that either if you
383
00:34:14,510 --> 00:34:20,570
just forget to add this minus all to , or
your system administrator who has
384
00:34:20,570 --> 00:34:26,470
forgotten to do that. In that case, even
if they include has minus all, it won't
385
00:34:26,470 --> 00:34:34,089
work because I mean, it would because when
the recipient will be checking it minus
386
00:34:34,089 --> 00:34:39,569
all inside include does not mean the same
as it does on the top level. And the
387
00:34:39,569 --> 00:34:43,799
second would be if they have added all but
did softfail all. And some admins might
388
00:34:43,799 --> 00:34:47,809
think that. But that's okay because I'm
including GMail and GMail has this hard
389
00:34:47,809 --> 00:34:54,409
fail. Doesn't work that way. And then one,
which actually is I think maybe the most
390
00:34:54,409 --> 00:35:00,000
common case, is that something often you
actually see this type of SPF records, but
391
00:35:00,000 --> 00:35:03,569
there is lots of stuff inside there is IP
addresses. There are these A records,
392
00:35:03,569 --> 00:35:07,890
there is a MX. There is a pointer.
Basically, everything that the admins
393
00:35:07,890 --> 00:35:12,990
could think of and the reason is that the
most commonly, they are just not sure how
394
00:35:12,990 --> 00:35:17,100
it works. They're not sure what they
should put inside. So, for example, one
395
00:35:17,100 --> 00:35:24,840
thing that the point that out is if there
is a MX record inside the SPF, most
396
00:35:24,840 --> 00:35:27,930
commonly most organizations, unless they
are very small and just have one server,
397
00:35:27,930 --> 00:35:31,059
they will have different servers,
different IP addresses for outgoing mail
398
00:35:31,059 --> 00:35:34,500
and for incoming mail. That means there is
no practical for this organization,here is
399
00:35:34,500 --> 00:35:41,109
no practical reason to include MX into SPF
because no, no mail should go out through
400
00:35:41,109 --> 00:35:45,900
their incoming mail server. And another
case might be that the admins understand
401
00:35:45,900 --> 00:35:51,470
how it works, but it's really, truly their
architecture is really messy and they are
402
00:35:51,470 --> 00:35:55,730
sending emails from many, many different
points, which is good for penetration
403
00:35:55,730 --> 00:36:03,359
testers. That means that they are not well
organized. OK. And then there's another
404
00:36:03,359 --> 00:36:09,220
flaw, which is that granularity isn't very
well suited. So the only thing you can.
405
00:36:09,220 --> 00:36:13,799
There are multiple this record types. But
all they do basically are resolve the IP
406
00:36:13,799 --> 00:36:19,650
address. But the as you can imagine, in
many cases, IP is not linked just to mail
407
00:36:19,650 --> 00:36:24,230
server. So on one IP, there might be mail
server and web server or database or
408
00:36:24,230 --> 00:36:28,069
something else. And that means that as a
penetration tester, you can exploit this
409
00:36:28,069 --> 00:36:32,339
something else. Not mail server itself,
because mailserver usually is pretty like
410
00:36:32,339 --> 00:36:36,740
low key. There's not many vulnerabilities
there. You just patch them and that's it.
411
00:36:36,740 --> 00:36:42,740
But those other systems, for example, web,
it's easy to exploit. In most cases. So
412
00:36:42,740 --> 00:36:46,680
then you can elevate like in some sort
elevate privileges by gaining access
413
00:36:46,680 --> 00:36:50,809
through some other server on that IP
address or IP range. You can start sending
414
00:36:50,809 --> 00:36:59,859
mails. They will pass all SPF filters. OK.
So one example is shared hosting, which is
415
00:36:59,859 --> 00:37:04,950
the very common case and the problem with
shared hosting is that. In this case.
416
00:37:04,950 --> 00:37:10,359
Okay. You have IP address of SMTP server.
Maybe that's server only used for sending
417
00:37:10,359 --> 00:37:15,900
mails. But the server itself works not
just for you. It works for many domains,
418
00:37:15,900 --> 00:37:18,849
maybe hundreds of thousand domains. That
means as an attacker, again, you can
419
00:37:18,849 --> 00:37:24,289
exploit at least one of them, or for
shared hosting you can just buy. You can
420
00:37:24,289 --> 00:37:26,940
become a customer of that shared hosting.
You don't even need to exploit anything.
421
00:37:26,940 --> 00:37:31,750
And then you can potentially start sending
email, which will look good as far as SPF
422
00:37:31,750 --> 00:37:38,140
is concerned, just like their own. So. And
the another one is this checking wrong
423
00:37:38,140 --> 00:37:44,960
identifier. And this is probably the
worst, worst problem with SPF. It is that,
424
00:37:44,960 --> 00:37:49,640
as I mentioned before, the one there are
at least two identifiers. Typically
425
00:37:49,640 --> 00:37:53,740
envelope sender, the outer one, which
lists the sender, and then there is
426
00:37:53,740 --> 00:37:58,589
internal one, which is usually "from"
header. But out of those two SPF only
427
00:37:58,589 --> 00:38:03,140
checks, if SPF is the only technology that
you are using, SPF only checks the first
428
00:38:03,140 --> 00:38:09,059
one: envelope sender. And as I mentioned,
in most cases, actual users that will
429
00:38:09,059 --> 00:38:13,279
receive the mail, they won't see envelope
senders. They will see this and this other
430
00:38:13,279 --> 00:38:17,559
one "from" for example, or one of the
other headers they mention. So this
431
00:38:17,559 --> 00:38:22,830
behavior is fixed actually by DMARC, which
is the technology that I mentioned. But
432
00:38:22,830 --> 00:38:27,319
the majority of SPF installations, domains
that are using SPF do not have DMARC, so
433
00:38:27,319 --> 00:38:31,329
they are not protected by this. So even if
their SPF is completely great for
434
00:38:31,329 --> 00:38:36,630
attacker, it means that you only need to,
what you need to do to pass SPF is a to
435
00:38:36,630 --> 00:38:40,430
set envelope sender to something else. For
example, your own controlled address,
436
00:38:40,430 --> 00:38:49,010
which will pass all SPF checks. But then
inside the "from" you can show the header
437
00:38:49,010 --> 00:38:56,776
that will match this organization that you
want to pretend to be. Okay. So then there
438
00:38:56,776 --> 00:39:02,309
is another technology which is supposed to
fix this and it's DKIM. As we have seen,
439
00:39:02,309 --> 00:39:11,450
SPF is not enough. So DKIM. Sorry, the
wrong letters, Domainkeys identified mail.
440
00:39:11,450 --> 00:39:15,099
That's the DKIM and you don't need to
remember the long name, just the short
441
00:39:15,099 --> 00:39:20,223
name. And what it does, basically, it uses
cryptography, which is nice, right? It's
442
00:39:20,223 --> 00:39:24,640
math. It's hard to break for attackers.
And what it does is it signs every mail so
443
00:39:24,640 --> 00:39:29,870
every mail that is going out through the
DKIM enabled server will get signature,
444
00:39:29,870 --> 00:39:35,059
which you can, as a recipient, you can
cryptographically verify. So as you can
445
00:39:35,059 --> 00:39:39,940
see, how it looks is actually pretty hard
to see because it's not meant to be
446
00:39:39,940 --> 00:39:44,160
processed by humans. It's cryptography.
It's meant to be processed by computers.
447
00:39:44,160 --> 00:39:48,300
But the important part here is basically
the yellow stuff is this cryptographic
448
00:39:48,300 --> 00:39:55,880
signature. But the green part is what's
called domain identifier. And the red part
449
00:39:55,880 --> 00:40:02,269
is what's called. I don't remember how
it's called laughs. But basically it's
450
00:40:02,269 --> 00:40:07,160
idea is that you can have multiple keys
for your organization, for example, your
451
00:40:07,160 --> 00:40:12,390
organization might be sending mails from
your original SMTP server, then you might
452
00:40:12,390 --> 00:40:17,650
have a backup one or you might have might
be sending some messages from Google or
453
00:40:17,650 --> 00:40:21,759
some marketing campaign and so on. And
then each of them might have different
454
00:40:21,759 --> 00:40:26,970
"red", this parameter. The problem is and
then the recipient will need to run DNS
455
00:40:26,970 --> 00:40:32,532
query, which is the second example using
this combination of green and red one. And
456
00:40:32,532 --> 00:40:36,993
then they will get the public key and they
can use this public key to verify the
457
00:40:36,993 --> 00:40:43,799
signature. So it's sounds really nice. The
problem here is no, another problem yet.
458
00:40:43,799 --> 00:40:48,730
So how to use it? I think it's easy if you
understand the public cryptography. So on
459
00:40:48,730 --> 00:40:52,440
the sender side, you need to first
generate public and private keypairr. Then
460
00:40:52,440 --> 00:40:56,270
you publish the public part in the DNS.
Then you use private key to sign each
461
00:40:56,270 --> 00:41:00,480
message. Now recipient does sort of the
opposite. They once they receive the
462
00:41:00,480 --> 00:41:04,380
email, they figure out from this red and
green part they figured out the correct
463
00:41:04,380 --> 00:41:09,000
DNS record to run, run it, get the public
key and then compare whether this public
464
00:41:09,000 --> 00:41:12,526
key corresponds to the signature. So it
sounds really nice, right? What's the
465
00:41:12,526 --> 00:41:19,170
problem? So customers. Selectors, that's
the name. So the problem with that is that
466
00:41:19,170 --> 00:41:27,309
the selectors there might be multiple
selectors as a DKIM when you are doing
467
00:41:27,309 --> 00:41:31,670
configuration, you can select as many of
this custom selectors as you want, and the
468
00:41:31,670 --> 00:41:37,170
recipient doesn't know whether you
actually should have used a selector and
469
00:41:37,170 --> 00:41:41,599
what selector you should have used. So the
problem is that while, if we are talking
470
00:41:41,599 --> 00:41:48,690
just about the vanilla DKIM, modifying
existing signature is hard for penetration
471
00:41:48,690 --> 00:41:52,630
tester or for an attacker. But it's easy
to just remove it because if you have
472
00:41:52,630 --> 00:41:57,619
removed DKIM at all the header, the
recipient doesn't know that it should have
473
00:41:57,619 --> 00:42:03,550
been there because in order to check, they
need to. So here, for example, in order to
474
00:42:03,550 --> 00:42:08,640
check the signature, I need to know this
green part. This domain identifier and the
475
00:42:08,640 --> 00:42:14,712
selector which are part of this header.
Right. So that's a huge problem. And that
476
00:42:14,712 --> 00:42:20,818
means that. Yeah. That means that we can
actually while we can't spoof DKIM itself,
477
00:42:20,818 --> 00:42:26,700
we can just trim DKIM, send the message
without it. And if the DKIM was the only
478
00:42:26,700 --> 00:42:31,499
thing which protected this system, it will
work. So it might not get the green
479
00:42:31,499 --> 00:42:37,310
checkmark or whatever, but it will get to
the recipient. So. And another thing is
480
00:42:37,310 --> 00:42:43,040
this domain selector. Why do we even need
to set that? Because the best practice, of
481
00:42:43,040 --> 00:42:48,280
course, is that you have envelope sender
equal to "from" header equal to this DKIM
482
00:42:48,280 --> 00:42:52,430
domain selector. Right. So if you are if I
am sending from Alice, then all three
483
00:42:52,430 --> 00:42:59,029
should be Alice.org or whatever. The
problem is that it's not mentioned in RFC
484
00:42:59,029 --> 00:43:04,029
that that should be the case. So what
exactly happens when it is not that way?
485
00:43:04,029 --> 00:43:09,619
For example, on the right side there is
some real domain which was using Gmail,
486
00:43:09,619 --> 00:43:17,470
Google Apps, Google suite, and in that case
the default by default Google suite will
487
00:43:17,470 --> 00:43:22,430
sign all messages. But if you do not do
your own configuration, it will sign them
488
00:43:22,430 --> 00:43:28,369
with domain it controls, which is this
"gappssmtp". And what it means is that
489
00:43:28,369 --> 00:43:32,579
although technically something has been
signed with DKIM, it wasn't signed in the
490
00:43:32,579 --> 00:43:36,406
way that you can trace back to your
organisation. It's something completely
491
00:43:36,406 --> 00:43:40,069
else. What exactly recipient should do in
that case? Should they just ignore it?
492
00:43:40,069 --> 00:43:43,859
Should they reject the message or
something? So the correct way would be not
493
00:43:43,859 --> 00:43:49,380
to reject it, but just consider it not
valid, at least not not a valid DKIM, but
494
00:43:49,380 --> 00:43:53,829
it actually depends. So some validators
will just see any DKIM, will validate it
495
00:43:53,829 --> 00:44:01,228
and will say that's cool that matches RFC.
So but now the interesting part. Modifying
496
00:44:01,228 --> 00:44:06,710
DKIM, which I don't have time for. But the
idea is that in some cases this is not
497
00:44:06,710 --> 00:44:11,339
always but sometimes you actually can
modify. The easiest part to modify in the
498
00:44:11,339 --> 00:44:17,190
messages are headers because DKIM, since
it's placed in headers itself, it does not
499
00:44:17,190 --> 00:44:21,304
automatically sign old headers. There's
like a chicken and egg problem. So by
500
00:44:21,304 --> 00:44:26,170
default it only signs one or two headers
and you can specify more headers that need
501
00:44:26,170 --> 00:44:30,910
to be signed, but it doesn't happen
automatically. So the easy part for
502
00:44:30,910 --> 00:44:35,569
attacker is to add another header. If
that's somehow helps you in your like
503
00:44:35,569 --> 00:44:40,400
plan, then that's easy to do. You just add
another header. An interesting part is,
504
00:44:40,400 --> 00:44:43,940
although the RFC, as I mentioned before,
mentions that some headers such as
505
00:44:43,940 --> 00:44:49,180
"subject" or "from" should only be present
in one copy. Actually you could add more
506
00:44:49,180 --> 00:44:53,093
than one for example "from" header, and
what happens in that case is pretty
507
00:44:53,093 --> 00:44:59,367
interesting. DKIM will match if you have
told to DKIM that "from" header should be,
508
00:44:59,367 --> 00:45:04,150
for example, signed, then it will match
and sign first "from" header from the
509
00:45:04,150 --> 00:45:11,279
bottom. But quite a lot of software in our
software email clients will actually only
510
00:45:11,279 --> 00:45:16,807
display to the user first from the other
side, from the up side. So what it means
511
00:45:16,807 --> 00:45:23,940
is that the attacker can mangle or
overwrite headers by just adding new
512
00:45:23,940 --> 00:45:29,546
headers to the top. And the this actually
problem is mentioned in the DKIM RFC and
513
00:45:29,546 --> 00:45:33,089
the protection that they propose is this
code Over-Signing or you can go and read
514
00:45:33,089 --> 00:45:38,885
the RFC. But not everyone is doing that
actually. And however, that only goes to
515
00:45:38,885 --> 00:45:44,919
the headers. So sometimes that is good.
Sometimes that's not good. Modifying
516
00:45:44,919 --> 00:45:49,499
message body is actually much harder to
do. Basically the naiv way do it through
517
00:45:49,499 --> 00:45:54,069
cryptography, which we don't want to do.
And another way is through this one
518
00:45:54,069 --> 00:45:58,140
parameter, which is body length, and
that's actually like questionable
519
00:45:58,140 --> 00:46:05,118
functionality that DKIM has. Sometimes you
can specify that the hash like. For
520
00:46:05,118 --> 00:46:08,789
signing purposes, we shouldn't consider
the whole body, but only first something
521
00:46:08,789 --> 00:46:13,790
bytes. So that's actually useful in some
cases regarding was a mailing list, but
522
00:46:13,790 --> 00:46:18,866
for the most part that's not useful. And
in practice, most email software does not
523
00:46:18,866 --> 00:46:24,500
do this. If it does, then it is
susceptible to potentially to this
524
00:46:24,500 --> 00:46:28,869
overwriting body as well. You could add
another mime type and then then modify
525
00:46:28,869 --> 00:46:34,245
headers to show that different mime type
and it will pass DKIM. So in this case, it
526
00:46:34,245 --> 00:46:37,569
actually will show, for example, the green
button or whatever, because DKIM, it will
527
00:46:37,569 --> 00:46:42,634
be valid. So now there's the third
technology, which is called DMARC. And
528
00:46:42,634 --> 00:46:47,640
again, there is the full name, which is
long, but in this case actually it means
529
00:46:47,640 --> 00:46:52,424
something. There are two key words:
reporting and conformance. Reporting is
530
00:46:52,424 --> 00:46:56,660
the one which most admins are familiar
with because that's how DMARC I think
531
00:46:56,660 --> 00:47:01,619
often is being sold to them. Reporting
means that when you have some problems in
532
00:47:01,619 --> 00:47:08,390
this case, you actually get get to tell
other side what to do in that case. So
533
00:47:08,390 --> 00:47:13,309
basically you tell them to send you
reports either once per day or every time
534
00:47:13,309 --> 00:47:16,886
and so on. So for penetration testers,
it's not that useful. Potentially we could
535
00:47:16,886 --> 00:47:20,509
use that to understand what sort of
configuration is running on the other
536
00:47:20,509 --> 00:47:25,000
side. But the currently this functionality
actually is not that widely implemented.
537
00:47:25,000 --> 00:47:30,309
However, the other part conformance, it's
actually really, really, really powerful.
538
00:47:30,309 --> 00:47:35,251
What it does, that it corrects these major
flaws that I mentioned in SPF and DKIM. So
539
00:47:35,251 --> 00:47:39,381
first of all, DKIM had this massive
problem that if you just strip down the
540
00:47:39,381 --> 00:47:43,109
header, then the recipient has no way of
knowing whether you whether there was
541
00:47:43,109 --> 00:47:49,377
should have been DKIM in first place. If
you are using DKIM alongside with DMARC
542
00:47:49,377 --> 00:47:55,269
that fixes the problem, because DMARC
specifies just that you have DMARC itself.
543
00:47:55,269 --> 00:47:59,220
It means that you're automatically at
least one of the SPF or DKIM should pass.
544
00:47:59,220 --> 00:48:03,576
So automatically DKIM is like measure
problem solved. The other thing that
545
00:48:03,576 --> 00:48:08,599
changes is, it changes the semantics for
SPF. Now, SPF, if you have both SPF and
546
00:48:08,599 --> 00:48:13,150
DMARC, it means that SPF should be checked
against "from" header. And as I mentioned,
547
00:48:13,150 --> 00:48:17,319
that was the major flaw with SPF, because
if you're using SPF itself, even, it is
548
00:48:17,319 --> 00:48:21,440
the hard to fail mode and so on, it means
that attackers can modify "from" headers
549
00:48:21,442 --> 00:48:26,710
still and the recipient won't know any
better. So a minimal example of DMARC is
550
00:48:26,710 --> 00:48:31,210
really, really small. And I think it's
easy to understand. You have just a DMARC
551
00:48:31,210 --> 00:48:36,890
reject. You need to like find out the
right place to specify. But it's easy and
552
00:48:36,890 --> 00:48:40,740
all you have to do is create this one DNS
record. And the benefit for that is even
553
00:48:40,740 --> 00:48:46,190
if you don't have DKIM and DMARC, if you
have created. Sorry if you don't have SPF
554
00:48:46,190 --> 00:48:50,680
and DKIM, but you have created DMARC,
effectively what it means is that this
555
00:48:50,680 --> 00:48:57,550
domain should not send any mail because
for recipient to consider a mail valid at
556
00:48:57,550 --> 00:49:02,279
least SPF or DKIM should be valid as well.
If they are not, then they can't be valid.
557
00:49:02,279 --> 00:49:07,480
So in fact what it means is that most
domains out there should consider enabling
558
00:49:07,480 --> 00:49:15,471
DMARC. That's just the right thing to do.
OK. So there are more tags. So in the
559
00:49:15,471 --> 00:49:22,019
wild, these DMARC records might be much
longer, but it's not of much use to
560
00:49:22,019 --> 00:49:26,009
penetration testers. So important part
here is again, this is this policy which
561
00:49:26,009 --> 00:49:31,184
can be three values "none", "quarantine"
and "reject". And if it is "quarantine",
562
00:49:31,184 --> 00:49:39,109
that means if the, if there is a failure,
the message should go to the spam folder.
563
00:49:39,109 --> 00:49:42,619
If it's "reject", it should be rejected
outright. And if it's "none", it means
564
00:49:42,619 --> 00:49:47,960
it's in investing mode. So and this is the
picture that I showed in before, which
565
00:49:47,960 --> 00:49:52,400
shows that actually even though DMARC is
really like the best technology out of
566
00:49:52,400 --> 00:49:59,655
these three, it's not really widely used,
unfortunately for defenders. Quite a nice
567
00:49:59,655 --> 00:50:05,070
fact for all penetration testers out
there. That means that you can, in fact
568
00:50:05,070 --> 00:50:14,550
spoof most of the mails out there. Okay.
So how do we work around it? Sorry. So.
569
00:50:14,550 --> 00:50:18,480
What happens if actually someone has
implemented DMARC? Does that mean that now
570
00:50:18,480 --> 00:50:23,526
penetration testers can't do anything? You
don't don't even need to do any research?
571
00:50:23,526 --> 00:50:29,039
No, it doesn't. So in practice, if someone
has implemented both DKIM and DMARC, but
572
00:50:29,039 --> 00:50:33,859
not SPF, so they have only two of them.
That's a really cool combination. DKIM is
573
00:50:33,859 --> 00:50:38,470
pretty powerful and the major flaw that it
had DMARC solves. So this combination is
574
00:50:38,470 --> 00:50:44,680
really cool in theory. In practice, the
problem is that in order to protect your
575
00:50:44,680 --> 00:50:49,751
own mails, the recipient side should
validate both DKIM and DMARC and
576
00:50:49,751 --> 00:50:53,932
unfortunately, quite a lot of software
still does not do that. One such software
577
00:50:53,932 --> 00:50:57,920
is Microsoft Exchange. And even if you are
not running Microsoft Exchange, chances
578
00:50:57,920 --> 00:51:02,049
are good that some of the partners that
you are communicating with are running
579
00:51:02,049 --> 00:51:05,700
Microsoft Exchange, and by default it
doesn't have any functionality to parse
580
00:51:05,700 --> 00:51:12,619
DKIM. So in fact, most systems still need
to enable SPF just for practical purposes,
581
00:51:12,619 --> 00:51:16,609
which is good for penetration testers
because if SPF and DMARC as enabled by
582
00:51:16,609 --> 00:51:21,502
default together, then again that fixes
one of the major problems with SPF, but
583
00:51:21,502 --> 00:51:25,864
does not automatically fix other problems
because there's not enough granularity and
584
00:51:25,864 --> 00:51:32,119
the potential for misconfiguration. So.
And the interesting fact is that DMARC
585
00:51:32,119 --> 00:51:37,970
only requires that one of the other
technologies SPF or DKIM is passed in
586
00:51:37,970 --> 00:51:42,749
order to consider email valid. There is no
way in DMARC, even though there are many
587
00:51:42,749 --> 00:51:45,680
others like selectors. There is no way to
specify that both of them should be valid
588
00:51:45,680 --> 00:51:50,019
or that DKIM should be preferred to SPF.
In practice, what it means is that for
589
00:51:50,019 --> 00:51:54,950
most systems that enable all three of
them, which is a good practical solution
590
00:51:54,950 --> 00:51:59,849
from penetration tester side we can just
ignore DKIM outright and just focus on SPF
591
00:51:59,849 --> 00:52:05,170
because the SPF is the weakest link in
this situation. Okay. So just a minute for
592
00:52:05,170 --> 00:52:11,559
recap. I'm not sure if I have any more
time. Not many time I have. Okay. So
593
00:52:11,559 --> 00:52:17,140
sorry. Yeah. So one really important note
is, when you are testing the systems,
594
00:52:17,140 --> 00:52:22,270
consider both scenarios. So don't focus
just on send. If you are, for example,
595
00:52:22,270 --> 00:52:27,599
testing Alice. Alice is the organisation
that is your customer. Don't just focus on
596
00:52:27,599 --> 00:52:33,569
testing emails sent impersonating Alice,
but also as the other side. Because in
597
00:52:33,569 --> 00:52:38,670
this here you can see that it's easy to
implement for example, SPF and DMARC
598
00:52:38,670 --> 00:52:43,961
because for both of them only you only
need DNS configuration. Just one record
599
00:52:43,961 --> 00:52:48,779
per each. However actually testing them
like well validating them properly is
600
00:52:48,779 --> 00:52:52,643
harder. For the first you need the
software support, you need to configure it
601
00:52:52,643 --> 00:52:56,585
correctly as well. So in practice it might
be that many of organisations that have
602
00:52:56,585 --> 00:53:01,500
enabled DMARC or SPF on the DNS side for
outgoing mails, they are not actually
603
00:53:01,500 --> 00:53:07,960
properly validating it. Yeah. Okay. Sorry,
I don't have time for that. So probably.
604
00:53:07,960 --> 00:53:16,009
That's it. Sorry. Maybe some questions.
605
00:53:16,009 --> 00:53:24,601
applause
606
00:53:24,601 --> 00:53:29,719
Herald: Thanks, Andrew, for this nice
talk. Sure. We have time for a couple of
607
00:53:29,719 --> 00:53:33,839
questions. So there I already see one
person, microphone number two.
608
00:53:33,839 --> 00:53:40,150
M2: Hey, thanks a lot. Do you know some
good tools to monitor DMARC reports that I
609
00:53:40,150 --> 00:53:44,339
get sent by my recipients?
A: Yeah. So this is a really good
610
00:53:44,339 --> 00:53:49,940
question. We as a CERT, we are really
suggesting everyone to enable this tool,
611
00:53:49,940 --> 00:53:55,190
but unfortunately, as far as I know, all
the tools that are popular on the
612
00:53:55,190 --> 00:53:59,670
Internet, they are collecting some data on
you. So they are using it for marketing
613
00:53:59,670 --> 00:54:04,412
purposes, do they are not very good for
privacy, if you are concerned about that.
614
00:54:04,412 --> 00:54:07,880
So you need to implement something
yourself or you need to look at some,
615
00:54:07,880 --> 00:54:12,180
start some open source project maybe.
Herald: OK. Microphone number one, please.
616
00:54:12,180 --> 00:54:16,428
M1: Thank you for the good talk. Me
myself, I would consider myself an mail
617
00:54:16,428 --> 00:54:23,609
administrator. I sometimes get advised to
shorten your SPF record because if it's
618
00:54:23,609 --> 00:54:28,859
too long, it gets dropped anyway. For
that, I sometimes get advised to drop the
619
00:54:28,859 --> 00:54:34,930
PTR record. But in your talk, you say the
PTR record is useful for reverse DNS
620
00:54:34,930 --> 00:54:39,549
checking, which I find very useful as
well. How are you about shortening your
621
00:54:39,549 --> 00:54:42,920
SPF and how are you about the PTR record
in general?
622
00:54:42,920 --> 00:54:47,530
A: Well, it really depends on your
particular use case. So it might be the
623
00:54:47,530 --> 00:54:51,230
case that some organizations really need
this longer SPF and there's not no way
624
00:54:51,230 --> 00:54:55,799
around that you could do. What you could
do is include this, include use includes
625
00:54:55,799 --> 00:55:01,479
because they won't be they are not macros,
so they won't get expanded. They do not
626
00:55:01,479 --> 00:55:07,755
like your record doesn't become longer if
you include and use many includes. But the
627
00:55:07,755 --> 00:55:12,119
problem, which I would suggest to you is
actually reconsider whether it's a really
628
00:55:12,119 --> 00:55:16,970
whether you really need that many records
if it's still long, because they're a very
629
00:55:16,970 --> 00:55:20,499
common problem, is that unless you are
Google or something like that, you don't
630
00:55:20,499 --> 00:55:26,660
really need that long SPF. It's probably
some problem with some. Yeah. So it's
631
00:55:26,660 --> 00:55:36,489
probably an error for most organizations.
Herald: OK. Well, very. Just briefly.
632
00:55:36,489 --> 00:55:40,496
Number 1
M1: On the PTI rocker record. I heard that
633
00:55:40,496 --> 00:55:43,489
it's dropped. Not dropped from the
standards, but it's not in the standards.
634
00:55:43,489 --> 00:55:48,859
A: It is in the standard. No. PTR record
by itself is if it's really your use case.
635
00:55:48,859 --> 00:55:53,599
I don't I'm not aware that it will be
automatically dropped somewhere. Shouldn't
636
00:55:53,599 --> 00:55:56,380
be a problem.
Herald: We have a couple of more
637
00:55:56,380 --> 00:55:59,349
questions here. So number six in the very,
very back.
638
00:55:59,349 --> 00:56:07,420
M6: Thank you for your talk. That's not
directly related, but even it should be
639
00:56:07,420 --> 00:56:13,800
related. If mail server accepts because
DKIM, DKARC and SPF, everything is fine,
640
00:56:13,800 --> 00:56:18,779
but especially Google for a lot of
organizations, the mail is delivered but
641
00:56:18,779 --> 00:56:24,089
classified as spam. It means on the inbox
of the recipient, it is not displayed.
642
00:56:24,089 --> 00:56:28,069
Have you a solution to solve this problem
against Google?
643
00:56:28,069 --> 00:56:33,630
A: Yeah. OK. So I have like different
opinions about that because one thing
644
00:56:33,630 --> 00:56:38,787
which actually enables which we actually
should be doing. Thank you Google. Is
645
00:56:38,787 --> 00:56:42,859
that they are so strict because that's the
only reason that we even have this high
646
00:56:42,859 --> 00:56:47,879
percentage of even improperly configured
SPF. The only reason there are 70 percent
647
00:56:47,879 --> 00:56:52,829
websites are using SPF is because that
they need to communicate with Google. And
648
00:56:52,829 --> 00:56:56,690
Google won't accept your mail if it
doesn't have even SPF on the baseline. So.
649
00:56:56,690 --> 00:57:04,269
I actually I enjoy it as a job that I do.
I've. I would prefer that Google does what
650
00:57:04,269 --> 00:57:09,527
it does. But I understand the real admins
which have this problem. Google has the
651
00:57:09,527 --> 00:57:15,239
tool. You probably know about it. Where
you can check what it considers about your
652
00:57:15,239 --> 00:57:19,323
domain. So you need to consider this
problem on a case by case basis. Quite
653
00:57:19,323 --> 00:57:23,559
often what happens is that even though you
have this DKIM, DMARC and so on, it's not
654
00:57:23,559 --> 00:57:28,576
configured correctly. So that's what the
talk was about. So you have it. You
655
00:57:28,576 --> 00:57:31,259
probably think that you have configured it
correctly, but there are some errors.
656
00:57:31,259 --> 00:57:35,249
Herald: Okay, let's give priority to the
Internet.
657
00:57:35,249 --> 00:57:40,170
Signal Angel: We have one question from
the Internet. Well, attempting to verify
658
00:57:40,170 --> 00:57:43,819
and address how to handle no reply email
addresses.
659
00:57:43,819 --> 00:57:49,999
A: No reply, I'm sorry. Can you read it
again, please?
660
00:57:49,999 --> 00:57:55,170
Signal Angel: When attempting to verify an
address, how to handle noreply Email
661
00:57:55,170 --> 00:58:04,529
addresses.
A: Maybe it was about the noreply header ?
662
00:58:04,529 --> 00:58:10,650
Or not existing IP addresses ?
Signal Angel: How to handle email. No
663
00:58:10,650 --> 00:58:14,809
reply email adresses.
A: I will try to get an answer to how I
664
00:58:14,809 --> 00:58:21,532
understand it. So what often happens is
that what often happens is that the email
665
00:58:21,532 --> 00:58:25,294
will be sent from nonexisting addresses.
So maybe that's what the question was. For
666
00:58:25,294 --> 00:58:29,789
example, there is "no reply", and it's not
the problem itself. No reply. The problem
667
00:58:29,789 --> 00:58:34,339
is that it's not an real address. There is
no such address. Right. And so I don't
668
00:58:34,339 --> 00:58:38,816
have an answer for that because according
to RFC, you should you should still accept
669
00:58:38,816 --> 00:58:43,627
it. Practically, as I said, lots of mail
systems already are dropping this
670
00:58:43,627 --> 00:58:46,420
addresses if you're sending from not
existing unless you are Google or
671
00:58:46,420 --> 00:58:50,150
something large, so you have been put into
whitelist. You just won't be able to do
672
00:58:50,150 --> 00:58:54,779
that. You won't be able to send email from
non-existing address. So if that's your
673
00:58:54,779 --> 00:59:00,309
situation, create the address, make it
like a remove all the email that comes
674
00:59:00,309 --> 00:59:03,640
there, but create the real address so that
your acceptable. If you are on the other
675
00:59:03,640 --> 00:59:08,269
side. So you are receiving this email. It
depends on this particular use case. So
676
00:59:08,269 --> 00:59:12,099
just check what's going on. If you can
contact them, contact them. If you can't
677
00:59:12,099 --> 00:59:16,220
contact them, then you should decide what
is the risk, if you are dropping these
678
00:59:16,220 --> 00:59:23,920
addresses, are they important for you? So
according to RFC you should receive and
679
00:59:23,920 --> 00:59:28,660
process this addresses.
Herald: Okay. Microphone number four,
680
00:59:28,660 --> 00:59:33,040
please.
M4: Hey, thank you for this talk. Do you
681
00:59:33,040 --> 00:59:40,630
know about effort to solve problems with
big email senders like online booksellers,
682
00:59:40,630 --> 00:59:47,450
which are very great because they don't
seem to have their own SPF records, for
683
00:59:47,450 --> 00:59:53,253
example, in in control.
A: Yeah. So in many cases you can just
684
00:59:53,253 --> 00:59:56,711
contact them. So it's just the question
that they haven't thought about it. Or
685
00:59:56,711 --> 01:00:01,770
maybe no one told them what to do or maybe
they don't know how to do better. Right.
686
01:00:01,770 --> 01:00:05,249
So that's one of the parts that we as a
CERT we are doing. If you have some some
687
01:00:05,249 --> 01:00:10,619
this problem with some large company in
particular country, I would suggest to
688
01:00:10,619 --> 01:00:14,470
contact CERT. Even if it's not a
government organization, for example, in
689
01:00:14,470 --> 01:00:18,700
Latvia, if that will be a latvian company.
We would do the triage. We would try to
690
01:00:18,700 --> 01:00:21,892
try to talk to them, explain to them why
they need to change and so on. So that's
691
01:00:21,892 --> 01:00:26,289
maybe one option for you. But the
practices that if something looks to you
692
01:00:26,289 --> 01:00:30,060
as a third party, as a wrong
configuration, that is one I couldn't
693
01:00:30,060 --> 01:00:34,400
mention in this talk. If something isn't
perfectly secure, it doesn't mean that
694
01:00:34,400 --> 01:00:39,460
it's wrong. There might be actually
business case why it should be this way.
695
01:00:39,460 --> 01:00:42,229
Right. Because, for example, if it's a
large I don't know, Amazon and some for
696
01:00:42,229 --> 01:00:46,700
something like that. And if they have
tested and they know that when they enable
697
01:00:46,700 --> 01:00:51,697
very strict configuration, some percentage
of their emails just doesn't come. Not
698
01:00:51,697 --> 01:00:55,762
because of their problem, because of
someone else's problem. Right. But then
699
01:00:55,762 --> 01:00:59,759
there is actually a real business case
that they they are not. It would be stupid
700
01:00:59,759 --> 01:01:04,489
for them to enable this, you know, to
strict configuration, knowing that it will
701
01:01:04,489 --> 01:01:08,970
damage their business. That makes sense,
right?
702
01:01:08,970 --> 01:01:13,479
Herald: Okay. We are unfortunately running
out of time for those who are on the
703
01:01:13,479 --> 01:01:17,755
microphones. please just line up with the
speaker next to the desk. He's gonna talk
704
01:01:17,755 --> 01:01:21,195
to you. Perfectly sure. And.
705
01:01:21,195 --> 01:01:25,159
applause
706
01:01:25,159 --> 01:01:40,959
36C3 postroll
707
01:01:40,959 --> 01:01:53,000
Subtitles created by c3subtitles.de
in the year 2020. Join, and help us!